Oracle Managed File Transfer (MFT) Handson - Teil 4: Integration mit der SOA Suite

[Teil 1] [Teil 2] [Teil 3] [Teil 4] 

Nutzt man sowohl MFT, als auch die SOA-Suite, dann macht es Sinn diese miteinander zu integrieren. So kann die SOA-Suite Daten auch direkt an MFT übergeben und dieses kümmert sich dann um die Weiterverteilung im Dateisystem. Umgekehrt kann die SOA-Suite auch Ziel einer MFT-Transaktion sein und die Inhalte direkt entgegennehmen.
Für dieses Beispiel wird eine Domain mit MFT und SOA Suite benötigt. Der grundsätzliche Umgang mit beiden Produkten sollte bekannt sein.

Los geht es auf der Design-Seite der MFT-Console. Hier wird eine neue Source vom Typ SOA angelegt, z.B. mit dem Namen service-source (Wichtig: der Name soa wie abgebildet führt später zu Problemen und sollte nicht verwendet werden).

Als nächstes wird ein Transfer angelegt und die eben erstellte service-source als Quelle eingetragen. Als Target wird ein beliebiges File Target genommen, z.B. das file-target aus Kapitel 3.
Zum Abschluss werden mit Klick auf Save und Deploy die beiden neuen Artefakte deployed.

Weiter geht es im JDeveloper mit einem neuen SOA-Projekt.

In das Composite wird rechts bei den References ein MFT-Adapter gezogen.

Der Default kann übernommen werden.

Hier auch einfach den Default belassen.

Hier wird die bestehende Application-Server Connection angegeben, oder ggf. neu angelegt. Der MFT Server wird dann automatisch gefunden. Per Klick auf Test MFT lässt sich die Verbindung überprüfen.

Die service-source wird automatisch gefunden, beenden mit Finish.

Um den MFT Adapter anzusprechen, wird ein BPEL-Prozess in das Composite gezogen. Dieser wird auf Synchronous BPEL Process umgestellt, der Rest kann so bleiben.

Der BPEL-Prozess wird mit dem MFT-Adapter verbunden und hinterher per Doppelklick geöffnet.

Im Prozess wird mittig eine Invoke-Aktivität platziert und diese mit dem MFT Partner Link verbunden.

Die Input- und Output-Variable wird jeweils über das grüne Plus (+) angelegt. Dann mit OK schließen.

Es wird noch eine Assign-Aktivität benötigt, die vor das Invoke gezogen wird. Diese wird per Doppelklick geöffnet.

ns1:InlinePayload bekommt per Rechtsklick eine Expression zugewiesen.

Passend zum jeweiligen Bundesland kann hier eine angemessene Begrüßung zusammengeklickt werden, in meinem Fall:
concat("Moin, Moin ", $inputVariable.payload/client:input)

Das gleiche wird wiederholt für ns1:TargetFilename. Da sich hier um den Namen der Zieldatei handelt, sollten Sonderzeichen vermieden werden. Z.B.
concat("Hello-",$inputVariable.payload/client:input)

Das Composite ist damit fertig und wird deployed (Rechtsklick auf Projektname|Deploy). Danach wird der Enterprise Manager geöffnet und das Projekt ausgewählt. Auf der Testseite wird ein Teststring eingegeben und der Test gestartet.

Wenn alles geklappt hat, kann hier der Flow Trace aufgerufen werden.

Im Flow Trace wird MFT mit angezeigt, weiter geht es mit einem Klick darauf.

Von hier wird man in die MFT Console weitergeleitet und bekommt hier direkt den Transfer angezeigt.

Auch im Filesystem ist das Resultat zu finden.

Damit ist das MFT-Tutorial abgeschlossen.

[Teil 1] [Teil 2] [Teil 3] [Teil 4] 

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.