OSB 12c: Einfaches Tutorial mit Throttling

Im folgenden ein einfaches Tutorial, um einen simplen SOAP-Service durch den OSB zu routen und dafür ein Throttling zu konfigurieren.

Hierfür benötigen wir einen simplen SOAP Service wie den HelloWorld-Service aus dem OBTM-Tutorial.

In der WebLogic Console, auf der der Service läuft, bekommen wir die WSDL URL.

Ein Klick auf den Link öffnet die WSDL in einem neuen Tab. Diese WSDL wird lokal im Dateisystem abgespeichert, ebenso die verlinkte XSD Datei geöffnet.

Weiter geht es in der Service Bus Console, in der ein neues Projekt 'Throttling' angelegt wird. Nicht notwendig, aber zur Übersicht empfehlenswert sollten noch zwei Ordner WSDL und XSD angelegt werden.

Im XSD-Projekt wird dann ein neues Schema angelegt.

Hier einen Namen vergeben und die gespeicherte Datei auswählen.

Auf die gleiche Art wird die WSDL im entsprechenden Ordner angelegt.

Jetzt wird noch ein Fehler angezeigt, weil die WSDL ja noch das externe XSD referenziert. Um das zu korrigieren, auf den View/Edit Button klicken.

Die Zeile

<xsd:import namespace="http://helloservice/" schemaLocation="http://192.168.56.101:7007/HelloServiceApp-HelloService-context-root/HelloWorldServicePort?xsd=1"/>

muss geändert werden auf

<xsd:import namespace="http://helloservice/" schemaLocation="../XSD/HelloXSD.xsd"/>

damit statt dessen die im OSB hinterlegte XSD referenziert wird.

Jetzt kann damit ein neuer Business Service erstellt werden.

Hier wird die eben angelegte WSDL ausgewählt. Weiter mit 'Next' und auf der nächsten Seite mit 'Create' abschließen.

Dann ein Mal mit 'Activate' die Session abschließen und Per 'Launch Test Console' den Business Service testen.

Wenn bis hier alles geklappt hat, sollte die richtige Antwort zurück kommen.

Mit dem 'Create'-Button dann wieder eine neue Session anfordern und im 'Throttling'-Ordner eine Pipeline erstellen. WSDL Based Servivce auswählen, die eben angelegte WSDL auswählen und 'Expose as Proxy Service' auswählen, ggf. noch den Namen ändern.

Damit die Pipeline jetzt auch mit dem Business Service spricht, muss die Pipeline geöffnet und geändert werden.

Im Flow-Editor wird per Klick auf die Pipe eine Route hinzugefügt.

Dann per Klick auf die Route das Menü aufrufen und 'Edit Route' auswählen.

Dann Klick auf 'Add an Action' und Communication|Routing auswählen.

Dort den Service und die Operation auswählen. Dann beide Dialoge mit 'Save' verlassen.

Dann die Session aktivieren und noch einmal die Test Console aufrufen, dieses Mal für den Proxy Service.

Wenn alles geklappt hat, geht es weiter im Fusion Middleware Control. Dort navigiert man unter SOA|service-bus in das Throttling Projekt. Auf der Seite 'Operations' geht es denn weiter per Klick auf den Business Service.

Hier können unter Properties die Parameter für das Throttling eingestellt werden. Über den Test-Knopf oben kann der Service gleich mit Throtting getestet werden. Weitere Informationen zum Throttling gibt es in der Dokumentation.

Oracle Managed Files handson Tutorial - Teil 2: ftp-Transfer

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

Nachdem im ersten Teil nur Dateien transferiert wurden, die im direkten Zugriff liegen, werden in diesem Teil Dateien per ftp übertragen. Da MFT eine Anwendung auf einem Weblogic-Server ist und dessen Berechtigungskonzept nutzt, müssen die Berechtigungen zunächst in der Weblogic-Console (http://HOSTNAME:PORT/console, z.B. http://localhost:7001/console) vergeben werden.

In der Weblogic Console geht es los bei Security Realms, dann rechts auf myrealm klicken.

Dort geht es weiter unter ‚Users and Groups', dann ‚New' klicken um einen neuen Benutzer anzulegen.

Name und Password vergeben, beenden mit ‚OK'

Der Benutzer ist jetzt zwar im Weblogic bekannt, hat aber noch keine Rechte im MFT. Hierzu geht es  weiter in der MFT-Console. Unter Administration links im Baum unter Embedded Servers den Eintrag User Access auswählen.
Dann den User suchen, dazu im Suchfeld die ersten drei Zeichen ‚ftp' tippen und den vollständigen Namen aus der Auswahlbox übernehmen. Mit dem Rechtspfeil daneben wird der User übernommen.
Für den standardmässig vorhandenen Folder /ftptransfer dann die beiden Haken bei Write und bei List setzen und mit Save beenden.

Den ftp-Port kann man sich auch unter Embedded Servers unter Ports anzeigen lassen.

Mit dieser Information lässt sich jetzt ein erster Verbindungstest zum internen ftp-Server durchführen. Hierfür kann jeder ftp-Client genutzt werden, z.B. via Shell: ftp localhost 7021. Aus Bequemlichkeit sollte der ftp-Client dort gestartet werden, wo eine gezippte Testdatei (z.B. das hjkl.zip aus Teil 1) liegt.
Die ftp-Session kann offen bleiben, wir brauchen sie gleich noch.

Damit die Dateien vom internen ftp-Server weitergeleitet werden, wird eine weitere Quelle benötigt. Diese wird genau wie im ersten Teil angelegt unter Design, Sources. Dieses Mal wird der Typ FTP Embedded ausgewählt und der Pfad via Browse ausgewählt. Das Verzeichnis ist schon vorhanden, da MFT für jeden ftp-User gleich ein Verzeichnis anlegt.

Passend zu der Quelle wird auch ein neuer Transport angelegt.

Als Source wird die neue ftp-source eingetragen, die Ziele sind wieder die selben wie im ersten Teil. Das only-txt Target bekommt  noch ein Decompress als post-processing Action.
Und wichtig: Beenden wieder mit Save und Deploy.

Um den ftp-Transfer zu testen, kann die vorher geöffnete ftp-Session genutzt werden. Die Kommandos hierfür sind bin (Binary, für zip) und put hjkl.zip, zur Überrprüfung gefolgt von ls. Die Datei sollte dann angezeigt werden.

Wie auch im vorigen Beispiel sollten die beiden gelieferten Dateien im Monitoring Dashboard unten rechts nach kurzer Zeit auftauchen.

Das Ergebnis läßt sich auch auf Dateiebene überprüfen. Wenn die Dateien entsprechend angekommen ist, ist dieser Tutorial-Teil zum integrierten ftp-Server abgeschlossen.

--> Oracle Managed File Transfer (MFT) handson - Teil 3: Custom Callouts in Java

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

Handson: Basic Authentication zwischen OSB und SOA-Suite (Teil 3)

In den letzten beiden Kapiteln wurde ein Web Service im Oracle Service Bus mit Basic Autentication abgesichert, der Zugriff darauf aus dem JDeveloper getestet und die WSDL lokal abgelegt. In diesem Teil wird der Web Service in das Composite eingebunden.
Aktuell kann der JDeveloper auf keine WSDL's zugreifen, die per Basic Authentication abgesichert sind (s. z.B. auch hier). Neben der WSDL wird auch das XML-Schema lokal benötigt (sofern man es nicht ohnehin schon irgendwo liegen hat).

Die URL für das Schema bekommt man in der WSDL unter dem Attribut schemaLocation. Diese wird im Browser geöffnet.

Auch das Schema wird lokal abgespeichert, bitte auch hier auf die Dateierweiterung achten.

Jetzt soll der Web Service in das SOA Composite eingebunden werden. Hierzu wird ein Web Service aus der Component Palette in den Bereich für die External References der SOA Suite gezogen.

Im 'Create Web Service' Wizard wird die WSDL über den 'Find existing WSDLs' Button hinzugefügt.

Hier wird die lokal gespeicherte WSDL ausgewählt.

Über die Option 'Localize external references' wird das XML-Schema gleich mitkopiert.

Die WSDL und das Schema werden damit in das Projekt übernommen.

Um den Service jetzt im Composite zu nutzen, wird ein Mediator eingesetzt. Hierzu wird ein Mediator von rechts aus dem Bereich 'Service Components' in dem Components-Bereich des Composites gezogen.

Der Mediator soll ja das gleiche Interface umsetzen wie der ursprüngliche Web Service, als .'Interface Definition from WSDL' auswählen und 'OK'.

Weiter mit dem 'Find existing WSDLs' Button

In der oberen Combobox 'Application' auswählen, dann unten das Projekt aufklappen und die importierte WSDL auswählen.

Fertig, abschliessen mit 'OK'

Das Serviceinterface links wurde damit automatisch erzeugt. Jetzt wird der Mediator mit dem Web Service auf der rechten Seite verbunden.

Per Doppelklick wird der Mediator geöffnet. Hier müssen noch die Mapper für die beiden Richtungen definiert werden. Hierzu auf das 'Select an existing mapper file or create a new one' Icon klicken.

Weil noch kein Mapper-File existiert, muss zunächst ein neues erstellt werden. Hierzu 'Create New Mapper File' auswählen, ein Dateiname wird automatisch vergeben, und mit 'OK' bestätigen.

Das Mapping ist an dieser Stelle trivial: einfach die beiden arg0-Parameter miteinander verbinden. Anschliessen zur Sicherheit ein 'Save all' durchfürhren und das Mapper-Fenster wieder schliessen.

Jetzt bitte für 'Synchronous Reply' noch einmal genau so verfahren und die beiden 'reply'-Werte miteinander verbinden. Hinterher kann das Mediator-Fenster wieder geschlossen werden.

Jetzt muss noch die Basic Authentication über den Oracle Web Services Manager (OWSM) konfiguriert werden, die Details dazu gibt es z.B. im Blog von Edwin Biemond.

Im nächsten Dialog klickt man unter Security auf das grüne Plus (+) Symbol und wählt dort die 'oracle/wss_http_token_policy' aus. Danach mit 'OK' schliessen.

Jetzt muss die SOA-Suite, auf die das Composite deployed werden soll, noch entsprechend konfiguriert werden. Hierzu per Rechtsklick auf die WebLogic Domain das Popup-Menü öffnen und 'Security|Credentials' auswählen.

Sofern nicht bereits vorhanden, muss hier die Map 'oracle.wsm.security' erstellt werden. Hierzu auf '(+) Create Map' klicken und mit 'OK' bestätigen.

In der Map wird dann via '(+) Create Key' der Key basic.credentials vom Typ Password angelegt und die Zugangsdaten für den Service eingegeben.

Das Ergebnis sollte dann wie oben aussehen. Damit ist die Konfiguration abgeschlossen.

Zum Testen wird das Composite deployed (s. z.B. hier).

Zum testen dann im Enterprise Manager das Composite auswählen und auf Test klicken ...

... hier einen möglichst sinnvollen Testwert eintragen und auf 'Test Web Service' klicken ...

... und fertig. Wenn alles richtig gelaufen ist, sollte hier jetzt das Ergebnis zu sehen sein.

Somit kann also der Web Service durch den OSB per Basic Authentication abgesichert werden und aus der SOA-Suite per OWSM-Credential aufgerufen wird. Dabei kann z.B. in der Entwicklung die Basic Authentication abgeschaltet werden und erst beim Deployment auf das Testsystem aktiviert werden.