JDeveloper per SSH-Tunnel an SOA Cloud Service anbinden.

Nachdem im letzten Teil beschrieben wurde, wie der SSH-Tunnel zum SOA Cloud Service (SOACS) aufgebaut wird, geht es in diesem Teil darum, den Tunnel zu nutzen um vom lokal installierten JDeveloper eine Verbindung herzustellen.

Zu beachten ist hierbei, dass der standard Network Channel des WLS des nicht tunnelbar ist. Daher muss hierfür ein eigener Channel angelegt werden. Dazu geht es los in der WebLogic Console per Klick auf den Management Server.

Unter Protocols / Channels findet sich beim Admin Server bereits ein Channel auf Port 9001. Dieser wird im Java Cloud Service immer angelegt, da der Developer Cloud Service diesen ebenfalls für das Deployment benötigt.

Für das SOA-Deployment wird  genau so ein Channel auch für den Managed Server benötigt. Da dieser standardmässig nicht vorhanden ist, muss er noch angelegt werden.

Da es sich ja um eine produktiv-Instanz handelt, muss zunächst per Lock & Edit eine Session angefordert werden, dann kann per New-Button ein neuer Channel angelegt werden.

Hier einen Namen vergeben, Protokoll ist t3.

Für den Listen Port kann ein beliebiger freier Port genommen werden. Da der Admin-Server Channel auf Port 9001 ist, wird in diesem Beispiel die 9002 genommen. Die External Listen Address ist die Public-IP des Servers.

Hier ganz wichtig, den Haken bei Tunneling Enabled zu setzen, dann beenden mit Finish.

Der neue Channel sollte dann wie oben angezeigt werden.

Jetzt muss noch der default Channel abgeschaltet werden. Dazu wird der Haken bei Listen Port Enabled entfernt. Dann per Save und hinterher Activate Changes die Konfiguration übernehmen. Unten ist auch noch der SSL Listen Port aufgeführt (8002). Damit ist die Konfiguration WebLogic-seitig abgeschlossen.

Damit die Channels auch durch den SSH-Tunnel kommen, müssen die drei Ports 8002, 9001 und 9002 entsprechend weitergeleitet werden.

Im JDeveloper wird jetzt eine neue Verbindung angelegt.

Standalone Server auswählen, Namen vergeben und weiter ...

Nach Benutzername und Password werden hier die Verbindungsdaten für den SOACS eingegeben. Hostname ist localhost, den Rest erledigt der Tunnel. Und wichtig: also Port die 9001 und nicht 7001 wählen, weil der tunnelbare Channel benutzt werden soll. Den Namen der Domain kopiert man am besten als der WLS Console.

Ein Mal testen und fertig.

Im Applications-Window wird der neu hinzugefügte Server angezeigt. Damit ist der SOACS für die weitere Verwendung im JDeveloper fertig konfiguriert.

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] 

Oracle Business Rules: Verbal Rules und BPM handson

Oracle hat mit SOA/BPM 12c die Oracle Business Rules um die sog. Verbal Rules erweitert. Damit ist es möglich, Regeln umgangsprachlicher zu formulieren um Fachanwender besser in das Regeldesign einzubinden. Dieses Tutorial zeigt den Umgang mit Verbal Rules, die grundsätzliche Bedienung der BPM-Suite sollte hierfür bekannt sein.

Los geht es im JDeveloper mit einer neuen BPM Application. Diese sollte gleich ein Projekt mit einem leeren BPM Process bekommen.

Wenn der Prozess geöffnet ist, lässt sich der Busisness Catalog anzeigen (Window|Catalog). Per Rechtsklick|New|Module wird zunächst ein neues Modul erstellt.

Auf dem Modul wird dann per Rechtsklick|New|Business Object das erste BO erstellt. 

Namen vergeben und fertig.

Es bekommt zwei Attribute (price:decimal, discount:int).

Ein zweite BO namens ApprovalOutBO wird angelegt, mit einem einzigen Attribut approval (String).

Zu den Business Objects werden jetzt entsprechende Process Data Objects benötigt. Erzeugt werden diese in der Structure-Darstellung via Rechtsklick|New.

Ein sinnvoller Name sollte vergeben werden, der Typ wird ausgewählt via Browse.

Hier dann das jeweils passende BO auswählen

Das Ganze wird für beide BO's durchgeführt, so dass jetzt zwei entsprechende Process Data Objects angezeigt werden sollten.

In der Prozessdarstellung wird nun eine Rules Task im Prozess platziert.

Auf dem Reiter Implementation wird zunächst per Klick auf das grüne Plus (+) ein neues Ruleset erstellt. Wieder per Klick auf das grüne Plus können die Parameter aus dem Fenster per Drag&Drop zugeordnet werden. Die Richtung wird oben in der Combobox eingestellt. Alle Dialoge werden danach mit OK verlassen.

In der Composite Darstellung ist jetzt auch die neue Rules-Komponente vorhanden. Diese kann per Doppelklick geöffnet werden.

Im Reiter Facts finden sich dann auch die beiden Parameter wieder. In der Spalte Alias können die Namen vereinfacht werden, z.B. auf Order und Approval.

Im Reiter Globals werden zwei Konstanten angelegt. 'minimal discount' mit dem Wert 1 und 'maximal discount' mit dem Wert 10.

Das Ergebnis sollte dann wie oben aussehen.

Damit können jetzt die ersten Business Phrases erstellt werden. Diese sind die umgangsprachlichen Bausteine für die Verbal Rules. Als erstes wird eine Test Phrase namens 'Discount is valid' angelegt. Das Mapping wird dann wie abgebildet erstellt, so dass ein gültiger Rabatt abgebildet wird.

Entsprechend wird noch eine zweite Test Phrase benötigt, die genau auf das Gegenteil testet, also einen Nachlass der niedriger als der Mindest- oder höher als der Maximalwert ist.

Zusätzlich werden noch zwei Action Phrases benötigt. Create Approval erstellt mittels assert ein neues Approval mit dem Text "APPROVED"

Analog dazu wird die Action Phrase Disapprove mit dem String "DISAPPROVED" erstellt.

Die Verbal Rules lassen sich auch mehrsprachlich nutzen. Dazu wird zunächst auf dem Reiter Translations ein neues Resource Bundle für Deutsch erstellt.

Danach können hier dann passende Übersetzungen eingetragen werden.

Jetzt sind alle Bausteine komplett und die Verbal Rules können erstellt werden. Hierzu geht es weiter auf dem jeweiligen Ruleset unter dem Reiter Verbal Rules. Die Regeln können hier aus den Test- und Action-Phrases zusammengestellt werden.

Neben dem Bottom-Up Ansatz, bei dem erst wie oben alle Komponenten erstellt werden um daraus die Verbal Rules zu erstellen, ist auch ein Top-Down Ansatz möglich. Hier werden die Verbal Rules einfach frei definiert, die entsprechenden Phrases erstellt der JDeveloper im Hintergrund.

Somit könnte zunächst ein fachlicher Anwender die Regeln umgangsprachlich formulieren, und erst später werden diese von einem Entwickler auf die Technik abgebildet. Und bis das geschehen ist, befindet sich die Verbal Rule im Zustand Draft.

Bei den Business Phrases werden dann auch die automatisch angelegten Phrases angezeigt. Auch diese sind bis zur Ausformulierung im Status Draft.

Um die neu angelegten Regeln zu testen, wird eine neue Test Suite auf dem Reiter Test erzeugt.

In der Testsuite werden zwei Testfälle über das grüne Plus (+) angelegt.

Der erste Test 'Approve correct discount' testet z.B. auf einen Discount von 5 und erwartet das Ergebnis "Approved".

Nach dem gleichen Schema wird ein zweiter Test erstellt, der für einen zu hohen Discount auf das Ergebnis "DISAPPROVED" testet.

Dann geht es wieder hoch auf Ebene der Test Suites, am schnellsten per Combobox 'Test Component'. Hier wird der Test mit dem grünen Pfeil gestartet.

Wenn bis hier nichts schiefgelaufen ist, sollten die beiden Tests durchlaufen.

Somit wurde aus BPM die Business Rules Engine aufgerufen, es wurden Verbal Rules definiert und diese wurden auf korrekte Funktion getestet.