Oracle SOA Cloud Service (SOACS): 12.2.1.1 Instanz anlegen

Zwischenzeitig ist auch der SOA Cloud Service (SOACS) in der Version 12.2.1.1 freigegeben worden. Dieses Tutorial ersetzt damit die Erstellung des SOACS-Teils für die Version 12.1.3.

In diesem Teil des Tutorials wird eine Instanz der Oracle SOA-Suite über den SOA Cloud Service (SOACS) aufgesetzt. Die vorherigen Teile zum Erstellen der Storage-Container und der Datenbank-Instanz sind hierfür Voraussetzung.

Los geht es in der Service Console des SOACS per 'Create Instanze'

Für die weiteren Tutorials benötigen wir einen SOA und Service Bus Cluster

Als Version wird die 12.2.1 ausgewählt.

Hier werden die Konfigurationsinformationen erfasst. Neben Compute Shape, SSH Key und Benutzername/Password wird hier die vorher angelegte Datenbank ausgewählt. Wichtig: hier werden nur Datenbanken angeboten, für die auch ein Backup konfiguriert ist. Dann benötigt der SOACS noch einen Storage Container. Der Name ist, wie auch beim Storage für die Datenbank, anzugeben im Format Storage-[Identity Domain]/[Container-Name]. In diesem Tutorial ist dies der zuvor erstellte SOACScontainer.

Zusammenfassung und weiter.

Bei Klick auf 'In Progress' gibt es detailierte Informationen über den Fortschritt

Wenn die Erstellung abgeschlossen ist, landet man per Klick auf den Instanznamen auf der jeweiligen Übersicht. Per Klick auf das Menüsymbol oben rechts gelangt man in die von der on-premise Variante bekannten Tools, alle in der 12.2 Version mit dem neuen Look&Feel:

WebLogic Console

 Enterprise Manager

SOA Composer

Worklist Application

Oracle Service Bus Console

In der Instanz-Übersicht im Bereich Administration gibt es Zugriff auf das zusätzliche Cloud-Tooling, welches es in dieser Form on-premise nicht gibt.

Neben der Konfiguration des Load Balancers, der in diesem Tutorial nicht genutzt wird, kann hier das Backup konfiguriert werden.

Hier kann ausgewählt werden, ob die Datenbank gleich mit gesichert werden soll.

Wenn das Backup erstellt ist, kann es hier direkt wieder eingespielt werden. Nützlich, falls im Laufe des Tutorials etwas schief geht.
Damit ist die SOACS Instanz für die weiteren Schritte fertig konfiguriert.

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.

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.