BPMN Application und Project anlegen

Weiter geht es mit dem BPMN-Teils des Workshops. An dieser Stelle vielen Dank an Bernhard Fischer-Wasels vom SOA und Logistik Blog, von dem der BPM-Teil stammt.
Im JDeveloper wird eine Application angelegt über 'New Application' oder File|New|General|Applications.

Application Name auf 'Urlaubsantrag' setzen, Application Template: aus der Liste "BPM Application" auswählen, Next.

Project Name 'Urlaub' eingeben, Technologies SOA und BPM sind bereite ausgewählt, dann Next.

Composite With BPMN Process auswählen -> Finish.
Etwas (ein paar Sekunden) warten... dann erscheint der "Create BPM Process Wizard"

Name 'UrlaubsProcess' eingeben, bei 'Type' bitte auswählen: 'Manual Process'.

Default übernehmen, Finish.

Das Ergebnis sieht dann wie folgt aus.

Anmerkung: Falls der 'Create BPM Process'-Wizard nicht erscheint, links im BPM Project Navigator (separater Reiter) Projekt 'Urlaub' expandieren [+] und rechte Maustaste auf 'Processes' -> New -> Process -> Create BPMN Process. Links auswählen: 'From Pattern: Manual Process' weiter -> 'UrlaubsProcess' -> Finish.

--> Nächster Schritt: BPMN Rollen & User anlegen

Oracle Enterprise Repository "User is locked out"

Es kann passieren, dass der User im OER gelockt wird. Beim Login bekommt er dann nur die Meldung "User is locked out" und kommt nicht über das Anmeldefenster hinaus. Wenn man noch andere User im System hat, kann man sich mit diesen einloggen und den Benutzer wieder freigeben. Hat man aber nur den Admin-User, z.B. nach einer frischen Installation, kommt man hier nicht weiter.
In diesem Fall kann man sich als Repository-Benutzer auf der Datenbank anmelden und den Benutzer mit dem folgenen Script entsperren:

1 2 3 4 5 6 7 8 9 10 11 12

set serveroutput on DECLARE oeruserid integer; BEGIN select id into oeruserid from DEV_OER.ENTSECUSERS where username='&1'; update DEV_OER.ENTSECUSERS set ACTIVESTATUS=0 where USERNAME='&1'; dbms_output.put_line( CHR(13)||CHR(10)|| 'The ID of user ' || '&1' || ' is >>>' || oeruserid || '<<<' ); update DEV_OER.CMEEUSERS set ACTIVESTATUS=0 where ENTSECUSERID=oeruserid; commit; END; / exit

Zur Wiederverwendung kann der Aufruf in ein Shellscript, z.B. oerunlock.sh verpackt werden:

sqlplus / as sysdba @oerunlock.sql $1

Der Aufruf wäre dann mit mit zu entsperrenden User als Parameter, z.B.

./oerunlock.sh admin

Es kann sein, dass die Daten noch gecached sind. In dem Fall hilft es, den WLS durchzustarten. Danach sollte das Login wieder funktionieren.

--- UPDATE 16.6.2015 -----------------------------------------------

Mit Oracle Enterprise Repository 12c funktioniert dies nicht mehr, hier sind zusätzliche Schritte notwendig.

Zunächst müssen die Diag Pages freigeschaltet werden wie in der Dokumentation beschrieben.  In der setStartupEnv.sh muss hierzu der Parameter -DdiagPagesEnabled auf true gesetzt und der OER werden. Danach muss der Managed Server, auf dem das OER läuft, neu gestartet werden.
Danach lassen sich die beiden folgenden URL's aufrufen:

http://<hostname>:<port>/oer/cachediag/CacheClear?cacheName=com.flashline.enterprise.secureuser.SecUserFactory.secUsers

Die Zeile cache com.flashline.enterprise.secureuser.SecUserFactory.secUsers cleared zeigt an, dass der entsprechende Teil des Caches gelöscht wurde.

http://<hostname>:<port>/oer/cachediag/CacheDetail?cacheName=com.flashline.cmee.secureuser.CMEESecUserFactory.secUsers

Wenn hier noch der Eintrag für die id des betreffenden Accounts angezeigt wird, kann hier per Klick auf den clear Link der Cache-Eintrag gelöscht werden.

Danach sollte das Lock für den User aufgehoben und ein Login wieder möglich sein.

Einladung BPM/SOA-Governance Workshop: Anmeldeseite jetzt verfügbar

Der BPM/SOA-Governance Workshop ist jetzt auf der Anmeldeseite für interssierte Kunden und Partner verfügbar. Nachdem die Anleitungen zum SOA-Governance Teil hier schon in den letzten Wochen zur Verfügung gestellt wurden, haben Sie nun die Gelgenheit die Inhalte zusammen mit mir und meinem Kollegen Bernhard Fischer-Wasels in einem Workshop selbst durchzuführen.

Die Agenda ist wie folgt:

09:30	Vorstellung BPM, SOA, Governance Lösung Parallel Setup Oracle VM VirtualBox
10:30	BPM Lab Erläuterung Einführung in den JDeveloper und das BPMN-Modelling
11:00	Hands-on: BPM Lab 1. Praktische Übung: Modellierung und Ausführung eines BPMN-Prozesses
12:30	Mittagspause
13:15	Oracle Enterprise Repository Lab - Erläuterung
13:45	Hands-On: Oracle Enterprise Repository Lab 2. Praktische Übung: Konfiguration Repository, Deployment von WebServices, Ablage im Repository
15:15	Der Governance Roundtrip mit BPM und OER - Erläuterung Das komplette Bild: SOA Governance als Bindeglied zwischen Fachabteilung und IT
15:30	Kaffeepause
15:45	Hands-On: Der Governance Roundtrip mit BPM und OER 3. Praktische Übung: zum Schluß wird alles zusammen gefügt
16:30	Schluß der Veranstaltung

Bezüglich weiterer Informationen wie Hardware-Anforderungen folgen Sie bitte dem Anmeldelink. Wir freuen uns auf Ihr Kommen.

Fusion Middleware Patchset 3 (PS3) verfügbar

Oracle hat soeben das Patchset 3 (11.1.1.4) für verschiedene Komponenten wie WebLogic Server, JDeveloper, SOA- und BPM-Suite freigegeben. Einige der Neuerungen sind

• Unterstützung für BPEL 2.0
• Lauffähigkeit auf Websphere
• Vereinfachte Installation in den Administrations-Server für Entwicklungssysteme

Sehr schön zusammengefasst wurden die Informationen auf dem SOA Partner Community Blog. Der kommende BPM/SOA-Governace-Workshop wird auch bereits auf 11.1.1.4 durchgeführt werden, hier lassen sich also gleich praktische Erfahrungen sammeln.

Tip: BPM-Suite und JDeveloper mit OPatch patchen

Bei der Installation des Patch 9958661 für BPM-Suite und JDeveloper via OPatch bin ich gerade über ein kleines Problem gestolpert. Der Patch besteht aus zwei Teilen: einen für die BPM-Suite und einen für den Server, die separat mittels OPatch installiert werden müssen.

Der Patch für die BPM-Suite verhält sich wie erwartet: wenn JAVA_HOME und ORACLE_HOME gesetzt sind und opatch im Pfad ist, genügt es im Patch-Verzeichnis opatch apply auszuführen und der Patch wird installiert.

Der Versuch, das gleiche mit dem JDeveloper-Home zu machen führt zu der folgenden Meldung:

Fusion Middleware Home is corrupted (WebLogic Home is not found)!
/home/oracle/app/Middleware/jdeveloper/jdk/bin/java is not a valid executable for this platform. OPatch cannot proceed!
OPatch returns with error code = 1

Die Lösung: der Pfad zum JDK muß opatch als Argument mitgegeben werden, also

opatch apply -jdk $JAVA_HOME

und schon klappt es wieder.

Workshop: Überarbeiteten Service im Repository hinterlegen

Der Portfolio-Verantwortliche kann das Repository nach neuen Anfragen zu Webservices durchsuchen.
Hierzu wird gesucht nach Type 'Request for Service' und Registration Status 'Unregistered'. Auf der rechten Seite wird dann die gefundene Anfrage für den Webservice für Informationen zu Urlaubstagen angezeigt.

Wird der Service in der Trefferliste mit der Maus angewählt, erscheint unten der Klartext der Anfrage. Der Portfolio-Manager erfährt hier den Zweck des benötigten Webservices und kann jetzt überprüfen, ob es bereits einen bestehenden Service gibt, der diesen Zweck erfüllt.

Vorher öffnet er den Asset Editor und akzeptiert die Anfrage mit dem Button Accept).

Auch der Request for Service wird jetzt in den Status 'Registered' überführt, damit er im weiteren im Repository zur Verfügung steht.
Jetzt könnte z.B. gesucht werden nach Search String 'Urlaubstage' und Type 'Service'

Allerdings liefert diese Suche keine Treffer, weil noch kein Webservice zu Urlaubstagen im Repository vorhanden ist. Jetzt könnte der Portfolio-Manager überprüfen, ob es überhaupt Webservices gibt die Informationen zu einer Personalnummer liefern z.B. mit einer Suche nach Type 'Service' und Search String 'personaln'.

Jetzt findet die Suche natürlich den zuvor angelegten Webservice, der von den benötigten Rückgabeparametern Vor-, Nachname und verbleibende Urlaubstage zumindest die ersten beiden liefert. Unser Portfolio-Manager beschließt daher, von dem bestehenden Webservice eine neue Version entwickeln zu lassen, welche auch die benötigten Urlaubstage zurückliefert.
Der gesamte Prozess, bis der neue Serivce zur Verfügung steht, lässt sich auch vom Repository unterstützen. Z.B. könnte jetzt zunächst der neue Service im Repository definiert werden, mit Status auf Entwicklung. Dann könnte er einem Entwickler zugewiesen werden, später könnten die Tests im Repository dokumentiert werden. Für diesen Workshop soll es aber ausreichen, wenn der Service einfach erstellt und in das Repository eingestellt wird.

Dazu bekommt die HRService Anwendung im JDeveloper ein neues Projekt.

Das Generic Project reicht aus.

Es wird wieder die Web Service Technologie ausgewählt, welche Java nach sich zieht. Das Projekt bekommt dann den Namen HRService2. Im nächsten Schritt dann den Dialog beenden.
Jetzt wird im neuen Projekt HRSerivce2 wieder ein PL/SQL-Webservice erstellt. Die Schritte zur Erstellung des Webservices sind im wesentlichen die selben wie im Kapitel Serviceerstellung mit folgenden Änderungen:

Der Service bekommt einen neuen Namen, hier 'HrInfoService2'

Dieses Mal wird die Prozedur GETHRINFO2 verwendet. Den Rest des Wizards dann einfach mit den Defaults durchklicken.

Zur Sicherheit sollte der neue Webservice kurz im JDeveloper getestet werden. Diese neue Version liefert jetzt neben Vor- und Nachnamen auch die verbleibenden Urlaubstage zurück.
Ist der Test erfolgreich gelaufen, kann der Webservice genau wie der vorherige auf den WLS deployed werden, wie im Kapitel 'Webservice deployen' bereits beschrieben.

Danach sollte der neue Webservice unter dem alten HRService in der Weblogic Console unter Deployments angezeigt werden.

Auch auch dem WLS sollte der Webservice kurz getestet werden.
Als nächstes wird der neue Service über den Harvester in das Repository übernommen.

Dazu wird in der HarvesterSettings1.xml (~/app/Middleware/repository111/harvester/) der Eintrag remoteQuery so modifiziert, dass jetzt Hrservice-HRservice2-context-root abgefragt wird. Die Datei wird danach unter einem neuen Namen gespeichert, z.B. HarvesterSettings2.xml.
Jetzt ist wieder der Harvester ,wie bereits im Kapitel 'Webservice ins Enterprise Repository übernehmen' beschrieben, an der Reihe. Also wieder mit

./harvest.sh -settings HarvesterSettings2.xml

den Harvester aufrufen. Wenn der Harvester wieder erfolgreich durchgelaufen ist, steht der neue Service im Repository zur Verfügung.

Über eine Suche nach 'hrservice' werden jetzt sowohl der hrInfoService, als auch der HrInfoService2 gefunden.

Weiter geht es im Asset Editor als admin. Dort kann über den 'Advanced Search' Button oben links neben dem 'Search' Button eine erweiterte Suche nach Typ 'Service' durchgeführt werden.

Der Service kann jetzt im Repository etwas ausführlicher Beschrieben werden. Die Version ist 2.0, er bekommt eine Beschreibung und das Projekt wird zugewiesen.
Auf der Seite Administration kann der Service im Schnelldurchlauf die Schritte zur Registrierung durchlaufen, wie im Kapitel "Webservice ins Enterprise Repository übernehmen" beschrieben.

Weitere Attribute können gesetzt werden, z.B. auf der Seite Support kann das Häkchen für 'Supported', oder entsprechend bei 'Management Review'. Dies sind für einen potentiellen Service-Konsumenten wichtige Informationen, er wird typischerweise eher einen Service wiederverwenden, der supported ist.
Auf der Seite Taxnomy sind noch die Verbindungen ganz unten bei 'Relationships' über den Button 'Add' hinzuzufügen.

Der HrInfoService2 bekommt die Relation 'Previous version is' zu HrInfoService. Die umgekehrte Relation 'Next version is' wird automatisch gesetzt. Mit OK wird der Dialog geschlossen.
Als zweites wird eine 'Implements' Relation zum Antrag 'Webservice für Informationen zu Urlaubstagen' hinterlegt.

Somit sind die Relationen zur Anfrage und zur Vorversion im Repository hinterlegt.
Jetzt wo der neue Service lauffähig deployed und registriert ist, kann der Prozessentwickler diesen nutzen. Dazu kann er im OER z.B. nach hrservice suchen und findet jetzt beide Versionen.

Wird der neue Service im Navigator aufgerufen, zeigt er jetzt alle Relationen an. Sowohl die automatisch mit dem Harvester gesammelten, als auch die manuell nachgetragenen Verbindungen zur Vorgängerversion und der Anfrage.
Somit steht der neue Service dem Prozess jetzt zur Verfügung und kann entsprechend eingebunden werden.

Nächster Schritt ---> BPM-Suite und Oracle Enterprise Repository im Zusammenspiel

Workshop: Antrag auf neuen Webservice ins Repository stellen

Wenn der Designer eines Prozesses nun einen neuen Service benötigt, kann er grundsätzlich im Repository nachsehen ob er dort einen geeigneten Serivce findet. Allerdings muss der Prozessentwickler nicht zwingend auch ein SOA-Experte sein, so dass er mit der Menge der Assets im Repository möglicherweise nicht viel anzufangen weiß. Selbst wenn er einen grundsätzlich geeigneten Webservice findet, ist er möglicherweise nicht in der Lage zu bewerten ob ein Serivce wirklich für die Verwendung in seinem Prozess geeignet ist.
Eine Kommunikation zwischen den beteiligten Parteien ist hier Grundvoraussetzung, diese kann auch nicht durch ein Werkzeug ersetzt werden. Das Oracle Enterprise Repository kann den Prozess aber unterstützen und dafür sorgen, dass die Ergebnisse nutzbar und nachvollziehbar sind.

Hierzu soll der Prozessentwickler die Möglichkeit bekommen, im Enterprise Repository eine Anfrage nach einem benötigten Service zu hinterlegen. Diese wird abgebildet über einen neuen Asset-Typen 'Request for Webservice', der im Asset Editor angelegt werden kann.

Den Type Manager erreicht man aus dem Asset Editor über den Menüpunkt 'Actions|Manage Types'. Hier werden alle aktuellen Asset-Typen aufgeführt

Über File|New lässt sich ein neuer Service anlegen. Dieser soll hier 'Request for Service' heißen und wird von dem normalen Service abgeleitet.

Zurück im Type Manager lässt sich der 'Request for Service' weiter anpassen. Da er z.B. niemals in der UDDI-Registry auftauchen wird, lässt sich der Punkt auf 'None' setzen.  Über die Einstellmöglichkeiten zu Tabs und Elements lässt sich weiter konfigurieren, welche Attribute überhaupt im Asset Editor für den 'Request for Service' angezeigt werden sollen. Das OER lässt sich hier stark an die jeweiligen Bedürfnisse anpassen, aber für den Workshop soll erst einmal mit den Standardeinstellungen verfahren werden.
Die getätigten Einstellungen werden über den Menüpunkt File|Save dauerhaft gesichert.

Als nächstes wird ein Repository-Benutzer für den Prozessentwickler benötigt. Dieser kann im Repository Frontend unter 'Admin|Users|Create New' angelegt werden.

In diesem Dialog kann der User Peter Prozessbauer angelegt werden mit den Rollen businessAnalyst, projectAdministrator und projectArchitect. Die Rolle user ist standardmässig vorhanden. Mit 'Save' (runterscrollen) wird der Dialog beendet.

Analog dazu wird ein Projekt angelegt unter Projects|Create New.

Hier kann das HR-BPMN Projekt angelegt werden. Ein User muss als Project Leader eingetragen werden, den Dialog hierzu erreicht man über den Edit-Button rechts neben 'Users'.

Hier kann der neu angelegte User dem Projekt als Leiter zugewiesen werden. Über 'List All Users' bekommt man die Auflistung der User, hier kann der Anwender 'peter' ausgewählt und über den Doppelpfeil (>>) den 'Projekt Leaders' zugewiesen werden. Der Dialog wird ganz unten über 'OK' verlassen (ggf. scrollen), der Dialog für das Erstellen des Projekts wird ebenfalls unten über 'Save' geschlossen.
Jetzt kann Peter Prozessbauer seinen 'Request for Service' eintragen. Hierzu kann der Administrator ausgeloggt werden, oder alternativ ein zweiter Browser geöffnet werden.

Hier kann sich der neue Projektleiter anmelden.

Seinen Wunsch nach einem neuen Webservice kann er direkt auf der Startseite erfassen über den Link 'Submit an Asset'.

Hier kann der 'Request for Service' jetzt wie jedes andere Asset eingetragen werden. Wichtig ist nur die Auswahl des Type 'Request for Service'. In den Feldern 'Description' und ggf. 'Comments' kann der benötigte Service jetzt beschrieben werden. Die 'File Location URL' ist ein Pflichtfeld, hier kann z.B. die URL einer Feinspezifikation angegeben werden, die im lokalen DMS liegt. Der Link wird aber an dieser Stelle nicht automatisch überprüft, so dass hier auch ein Platzhalter eingegeben werden kann. Per Doppelklick kann dann noch das Projekt 'HR-BPMN Projekt' ausgewählt werden. Via 'Submit' wird der Dialog beendet. Es folgt eine Bestätigung und mit 'Close' wird der Dialog geschlossen.

Damit ist der Request für den Webservice im Repository abgelegt. Überprüfen lässt sich dies auf der Seite 'Assets' über die Suche. Hier wird als 'Type' der 'Request for Service' eingetragen und der 'Registration Status' sollte auf 'All Assets' stehen. Über den 'Search'-Button wird die Suche ausgeführt und rechts der Request für den 'Webservice für Informationen zu Urlaubstagen angezeigt'.

---> Nächster Schritt: Überarbeiteten Service im Repository hinterlegen