Freitag, 19. Dezember 2014

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.

Freitag, 17. Oktober 2014

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.