SOA-Suite 12c: inbound REST Adapter konfigurieren

Seit dem Release 12c bietet die Oracle SOA Suite auch Adapter für REST-Services an. Dieses Tutorial zeigt, wie man einen inbound REST Adapter für XML und JSON Payload konfiguriert.

In diesem Beispiel geht es los mit einer neuen SOA Application, Option 'Empty Composite' auswählen.

Im Composite wird auf der linken Seite bei den Exposed Services ein neuer REST-Adapter angelegt.

REST-typisch kann man hier einen Resource-Path (NOUN) definieren, dieses einfache Beispiel funktioniert aber auch ohne. Dann muss mindestens eine HTTP-Operation gebunden werden, was über das grüne Plus (+) unter 'Operation Bindings' erfolgt. Die beiden unteren Optionen sind vorgefertigte Schablonen, die aber auch weniger Einstellmöglichkeiten bieten. Deswegen geht es hier weiter mit dem ersten Punkt 'Add operations binding'

Als Payload am besten JSON und XML, als HTTP Verb für dieses Beispiel POST auswählen. Dann zum Definieren des XML-Schemas das Zahnrad 'Define Schema for Native Format' anklicken.

Den Native Format Builder durchklicken mit 'Next' ...

... und 'Next' ... 

... und 'Next' ... 

... bis zu dieser Stelle, wo man eine JSON-Beispieldatei vorgeben kann. Sofern vorhanden, kann man diese via 'Browse' laden oder im Freitextfeld unten einfach eingeben, z.B.

{

"Event" : "asdf",

"Payload" : "dfgh"

}

Der JDeveloper liefert einem dafür ein fertiges Schema, das im folgenden verwendet werden kann. Den Wizard dann mit 'Next', 'Finish' bis zu Ende durchklicken.

Für eine POST-Operation nicht unbedingt notwendig, aber zum Testen praktisch kann für die Rückgabe ebenfalls XML und REST Payload angekreuzt werden. Das eben erzeugte Schema kann mit der Lupe neben 'Schema URL' ausgewählt werden.

Dann beide Dialoge mit 'OK' schliessen.

Der REST Service ist damit angelegt. Als nächstes wird ein BPEL Prozess benöigt, z.B. via rechter Maustaste|Insert|BPEL Process.

Im Create-Dialog den Prozess umstellen auf 'Synchronous BPEL Process' und den Haken bei 'Expose as a SOAP service' wegnehmen. Der Rest kann so bleiben, beenden mit 'OK'.

Das Interface vom BPEL-Process passt noch nicht zu unserem Service und muss entfernt werden. Dazu das Symbol vom Interface anklicken, so dass die der Kreis gestrichelt dargetstellt wird und die 'ENTF'-Taste drücken. Die beiden Nachfragen mit 'OK' wegklicken.

Jetzt kann der RestService mit mit BPEL-Process verbunden werden. Die Rückfrage nach der Transaction mit 'OK' bestätigen.

Weiter geht es im BPEL Prozess. Die Ein- und Ausgabevariablen für das alte Interface sind immer noch vorhanden und können gelöscht werden.

Dann umschalten auf die Source-Ansicht. Die Referenz auf die alte WSDL, die wir gerade gelöscht haben, muss noch entfernt werden. Dazu einfach die Zeile <import ui:processWSDL... löschen.

Alles vom alten Interface ist gelöscht, jetzt kann die receiveInput Activity mit dem RestService verbunden werden.

Hier muss zunächst der Port Type auf den RestService umgestellt werden.

Dann wird eine neue Eingangsvariable erzeugt. Im Create Variable Dialog einfach gleich OK klicken.

Im nächsten Schritt wird dann die replyOutput Activity mit dem RestService verbunden und entsprechend wieder eine Variable angelegt.

Damit der Prozess irgend etwas tut, wird noch ein File-Adapter angelegt, um die Nachrichten zu speichern.

Den Wizard mit Standardwerten durchklicken. Bei Operation 'Write File' auswählen, 'Add Output Header' kann man auch dazu nehmen um die Ausgabe etwas gesprächiger zu machen.

Dann ein Ausgabeverzeichnis und einen Dateinamen auswählen, dem Dateinamen eine Sequenz (%SEQ%) anhängen.

Jetzt das Root-Element des eingangs erzeugten Schemas auswählen.

Danach den Wizard bis zum Ende durchklicken.

Jetzt hinter receiveInput eine Invoke-Aktivität platzieren und mit dem fileOutput verbinden.

Die Input- und Output-Variable jeweils über das grüne Plus (+) erzeugen und den Dialog schließen.

Vor der Invoke1-Aktivität eine Assign-Aktivität ablegen.

Das Assign öffnen und hier das Root-Element von receiveInput...InputVariable auf Invoke1_Write_InputVariable mappen.

Für den Rückweg zwischen Invoke1 und ReplyOutput eine weitere Assign-Aktivität anlegen und entsprechend von Invoke1_Write_OutputVariable auf replyOutput_BpelOperation_OutputVariable mappen.

Damit wäre das Beispiel fertig. Zum testen auf die SOA-Suite Instanz der Wahl deployen und das FMW Control öffnen.

Im FMW Control das Projekt auswählen und bei Test den entsprechenden Service auswählen.

Hier die beiden Media Types auf application/json umstellen. Den Request dann in der RAW View eingeben und starten.

Wenn bis hier alles geklappt hat, sollte als Response das Verzeichnis und der Dateiname des File Adapters zurück gegeben worden sein und die Nachricht in der Datei stehen.

Beim Deployment erstellt die SOA-Suite automatisch eine passende WADL. Diese kann man z.B. von der Test-Seite oben kopieren um den Service auch im JDeveloper zu testen.

Dazu öffnet man den HTTP Analyzer via Tools/HTTP Analyzer und klickt auf das 'Open URL...' Symbol.

Hier wird die eben kopierte WADL-URL reinkopiert, mit RETURN abschliessen.

Wenn der Service erkannt wird, kann der Test-Client über den Button 'Test' aufgerufen werden.

Das Testformular des JDeveloper tut sich aktuell noch etwas schwer mit JSON, deswegen sollte hier als Content-Type application/xml genutzt werden. Per 'Send Request' wird dieser ausgeführt. Weil die Rückgabe jetzt auf 'fileName' und 'directory' geändert wurde, kann der JDeveloper das Ergebnis nicht parsen. Aber hätte ich das sauber umgesetzt, wäre das Beispiel unnötig kompliziert geworden.

In der RAW-Darstellung sieht man aber, dass der Aufruf mit dem korrekten Ergebnis zurück kommt.

Wie das Beispiel zeigt, ist die REST/JSON-Umsetzung in JDeveloper und SOA-Suite 12c absulut benutzbar und es spricht nichts dagegen, diese in Zukunft in Projekten einzusetzen.