Dienstag, 17. November 2015

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.

Freitag, 29. Mai 2015

Oracle Enterprise Scheduler Service (ESS) Handson Tutorial

Der Enterprise Scheduler Service (ESS) wurde ursprünglich aus Eigenbedarf entwickelt und stammt aus der Oracle Applications Entwicklung. Seit einiger Zeit ist der ESS aber auch Bestandteil der Oracle SOA Suite und steht somit Anwendern für eigene Aufgaben zur Verfügung.
Wie der Name andeutet, dient der ESS dem zeitgesteuerten Ausführen von Jobs. Im Gegensatz zu einfachen cron-Jobs bietet der ESS aber viele zusätzliche Funktionalitäten, welche im Enterprise-Umfeld benötigt werden. Der ESS kann in einen Cluster deployed werden um Hochverfügbarkeit herzustellen, es können Abhängigkeiten zwischen Jobs definiert und aufgelöst werden, Resource-Management kann betrieben werden und die Verwaltung sowie das Monitoring können direkt aus der Enterprise Manager Console erfolgen. Komplexere Szenarien können programmatisch über die ESS API's (Java, Web Services) umgesetzt werden.
Der ESS ist damit gut gewappnet auch für komplexeste Szenarien im Enterprise Umfeld. Dieses schlägt sich auch im Umfang der ESS Dokumentation wieder, die in Summe über 800 Seiten auf die Waage bringt. Wer die vielfältigen Möglichkeiten des ESS in Gänze nutzen möchte, kommt um die umfangreiche Lektüre wohl nicht herum. Oftmals wird in Projekten aber auch nur ein einfacherer Scheduler benötigt. In der umfangreichen Dokumentation einen Einstieg zu finden, ist nicht leicht. Dieses Handson-Tutorial soll über die ersten Schritte hinweghelfen.

Überprüfen der Installation

Der ESS wird typischerweise mit der SOA installiert, ist aber nicht zwingend in der Domain-Konfiguration enthalten.


Über den Domain Configuration Wizard ($MW_HOME/soa12103/wlserver/common/bin/config.sh) wird die vorhandene Domain aktualisiert. Wichtig ist, dass die beiden Punkte Oracle Enterprise Scheduler Service Basic und Oracle Enterprise Manager Plugin for ESS angehakt sind. Falls diese fehlen, müssen sie hier nachinstalliert werden.


Wichtig ist auch, dass auch das Datenbank-Schema bereits angelegt ist.


Und schliesslich muss die ESSAPP auf einen Managed Server deployed sein, typischerweise wie hier auf einen eigenen ess_server1 oder mit auf dem soa_sever1.
Wenn alles installiert ist, sollte sich die ESS Health Check Seite aufrufen lassen unter server:port/EssHealthCheck.


Die Verwaltung für den ESS ist in den Enterprise Manager integriert. Wichtig: solange der Managed Server mit dem ESS noch nicht gestartet wurde, wird auch die Auswahl Scheduling Services links nicht angezeigt, auch wenn alles bereits richtig installiert wurde. Erst nach dem ersten Start taucht die Option auf.
Zum Testen wird ein kleines Script benötigt, z.B. dieses test.sh im Homeverzeichnis des Oracle-Users:
date >> /home/oracle/ess.txt
Hiermit wird einfach die Ausführungszeit an die Datei ess.txt angehängt.

Um das Script über den ESS laufen zu lassen, muss zunächst eine entsprechende Job-Definition erstellt werden.

Auf der Job Definitions Seite wird über Create ein neuer Job erstellt.


Hier wird das Script jetzt dem ESS bekannt gemacht. Wichtig ist, den Job Type auf ProcessJobType umzustellen. Danach kann der vollständige Pfad zum Script eingegeben werden. Abschliessen mit OK.

Die Job Definition ist jetzt zwar im System bekannt, wurde aber noch nicht zur Ausführung vorgesehen. Hierzu muss ein Job Request erstellt werden.


Die bestehende Job Definition kann über die Suche (Lupe) ausgewählt werden. Gibt man keine weiteren Parameter an, wird die Ausführung sofort und genau ein Mal vorgesehen.
Auf der Hauptseite des ESS sollte kurz danach ein erfolgreicher Job Request angezeigt werden.
Die Ausführung kann auch durch Blick in die Ausgabedatei ess.txt bestätigt werden.

Nun kann der ESS die Jobs natürlich nicht nur sofort, sondern auch zu festgelegten Zeiten ausführen. Hierfür muss ein Schedule definiert werden.
Über den Create Button kann ein neuer Schedule angelegt werden.

Hier können auch Intervalle eingegeben werden, z.B. alle zwei Minuten.

Nachdem der Schedule angelegt ist, kann damit ein neuer Job Request erstellt werden.

Hier werden jetzt links der bestehende Job Request und rechts der gerade erstellte Schedule eingetragen und das ganze per OK abgeschlossen.
Nach zwei Minuten sollten dann auch die Rückmeldungen in der Ausgabedatei eintreffen und mit etwas Zeitverzug auch auf der ESS-Hauptseite des Enterprise Manager auftauchen.
Trotz der komplexen Möglichkeiten und der Dokumentation im hohen dreistelligen Bereich lassen sich also trotzdem einfache Scheduling-Aufgaben schnell mit dem ESS umsetzen.

Dienstag, 24. Februar 2015

Oracle Managed Files Handson Tutorial



Dieses Tutorial soll durch die ersten Schritte mit dem neuen Oracle Managed File Transfer (MFT) helfen. Als Voraussetzung wird eine installierte SOA-Suite mit MFT benötigt, der grundsätzliche Umgang mit der SOA-Suite sollte bekannt sein. Betriebssystemseitig wurde Oracle Linux benutzt, das Ganze funktioniert aber analog auch unter Windows.

Freitag, 20. Februar 2015

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]