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

Workshop: Webservice ins Enterprise Repository übernehmen

Jetzt wo der Webservice deployed ist, soll er in das Repository übernommen werden. Um diese Arbeit nicht manuell erledigen zu müssen, liefert Oracle mit dem Repository auch das Harvester Tool.
Der Harvester ist im Workshop-Image bereits konfiguriert, die Anleitung wie der Harvester aufgesetzt wird findet sich auch auf FMW-Deutsch. Falls sich der Harvester nicht starten lässt, bitte die folgenden Schritte beachten:

• das harvest.sh Skript muss ausführbar sein, hierzu: chmod +x harvest.sh im gleichen Verzeichnis ausführen.
• Die Variable JAVA_HOME muss auf ein passendes JDK gesetzt sein, z.B. für Version 11.1.1.5 wie folgt: export JAVA_HOME=/home/oracle/Oracle/Middleware/jdk160_24

Die Konfiguration, welche dem Harvester mitteilt was er sammeln soll und wohin er das Ergebnis schreiben soll, findet sich in der Datei ~oracle/Oracle/Middleware/repository111/harvester/HarvesterSettings1.xml. (ggf. abweichende repository-Version beachten). Alternativ lässt sich die Datei hier (Link anklicken) herunterladen.
Diese enthält die folgenden Einträge:

<!--Connection info to OER-->
<repository>
<uri>http://localhost:7101/oer</uri>
<credentials>
<user>admin</user>
<password>v2_1.qxO4nSjgNEDgcGNqdjE01A==</password>
</credentials>
<timeout>30000</timeout>
</repository>


<remoteQuery>
<serverType>WLS</serverType>
<projectName>HRservice-HRservice-context-root</projectName>
<uri>http://localhost:7001/</uri>
<credentials>
<user>weblogic</user>
<password>v2_1.G+NTr3az8thaGGJBn0vwPg==</password>
</credentials>
</remoteQuery>
</query>

Gestartet wird der Harvester als Shell Script harvest.sh im  Verzeichnis ~oracle/app/Middleware/repository111/harvester/ über das Kommando harvest.sh -settings HarvesterSettings1.xml.

Die Fehlermeldungen zum OSB-Plugin kann man hier ignorieren. Wichtig ist am Ende das Ergebnis „Successfully completed the harvest“.
Der erfolgreiche Harvest-Vorgang kann in der Web-Oberfläche des Oracle Enterprise Repositories überprüft werden. Diese findet sich in der Workshop-Umgebung unter der URL http://oel5r5:7101/oer/

Der Username ist admin und das Password wie überall im Workshop Oracle123

Auf der Hauptseite des OER kann jetzt nach den neuen Einträgen gesucht werden. Dazu sollte der 'Registration Status' links auf 'Unregistered' gesetzt und die Suche ausgeführt werden. Auf der rechten Seite werden dann die gefundenen Artefakte aufgelistet: Service, Interface, Endpoint und WSDL.

Wählt man die Zeile mit dem Service aus, lässt sich über den Linken Button der Navigator aufrufen.

Über den Button mit dem schrägen Doppelpfeil lässt sich die Darstellung vergrössern. Dieses sog. Spiderweb-Diagramm zeigt die gesammelten Verbindungen zwischen den Artefakten.

Details zu den Assets und Änderungsmöglichkeiten gibt es im Asset Editor, der über den Menüpunkt 'Edit / Manage Assets' aufgerufen wird.

Der Asset Editor basiert auf der Java WebStart-Technologie. Abhängig vom Browser (hier Firefox wie im Workshop-Image). Falls sich hier keine Java-Webstart Anwendung öffnet, ist möglicherweise das Java-Plugin für den Browser nicht korrekt installiert.

Sofern alles richtig aufgesetzt ist, erscheint der Asset Editor. Hier können die Details für den Service und die gesammelten Artefakte eingesehen werden.

Allerdings sind die Services noch im Status 'Unsubmitted'. Zur Unterstützung einer SOA-Governance durchläuft die Registrierung von Assets einen Prozess. Um im Schnelldurchlauf die Assets zu registrieren, werden die nächsten Schritte zur Vereinfachung direkt nacheinander vom Administrator durchgeführt.

Dazu wird jedes Asset zunächst einzeln submitted, dies geschieht auf dem Reiter 'Administration' über den Button 'Submit'.

Daraufhin befinden sich die Assets im Status 'Pending Review' unter 'Submitted', aufgeschlüsselt nach ihrem jeweiligen Typen.

Weiter geht es von hier aus über den Button 'Accept'

Damit befinden sich die Assets im Status 'Under Review'

Jetzt kann das jewelige Asset mit dem Button 'Register' im Repository registriert werden

Somit stehen die über den Harvester hinzugefügten Assets im Repository registriert zur Verfügung. Das Log des Registrierungsprozesses kann auf der rechten Seite unten eingesehen werden.

Damit der Service später auch wiedergefunden wird, sollte er im Repository ordentlich verschlagwortet werden. Für den Workshop reicht eine kurze Beschreibung: „Liefert zu einer übergebenen Personalnummer den Vor- und Nachnamen des Mitarbeiters“. Die Änderung wird gespeichert mit File|Save.

Über die Verbindung aus dem JDeveloper ist der Service jetzt auch auffindbar.

Damit steht der Webservice jetzt nicht nur auf dem Weblogic Server zur Verfügung, sondern kann auch aus dem JDeveloper im Enterprise Repository gefunden werden.

Über rechte-Maustaste/View in Repository lassen sich die Daten des Webservices auch im Jdeveloper anzeigen.

---> Nächster Schritt: Antrag auf neuen Webservice ins Repository stellen

JDeveloper Workshop Setup für BPMN und Enterprise Repository

Für den Handson-Workshop kann der JDeveloper sowohl innerhalb der VM, als auch im Gastsystem benutzt werden. Diese Beschreibung geht von einer Installation im Gastsystem aus, aber der JDeveloper in der VM verhält sich analog.
Für den Workshop benötigt werden die Plugins für SOA, BPM und das Enterprise Repository sowie die Server-Verbindungen zu Datenbank, Application Server und Repository.
Bei bestehender Internet-Verbindung und mit einem OTN-Account können die Plugins direkt aus dem JDeveloper heruntergeladen werden. Wichtig hierbei ist, die Proxy-Einstellungen zu beachten unter Tools|Preferences|Web Browser and Proxy.

Falls in diesem Dialog Änderungen vorgenommen werden, ist es wichtig den JDeveloper danach neu zu starten damit diese auch aktiviert werden.

Über den Menüpunkt Help|Check for Updates gelangt man in den entsprechenden Wizard. Hier 'Next' klicken.

Die korrekten Update-Center sind bereits voreingestellt. Die Workshop-Teilnehmer bekommen die Extensions mit den Kursunterlagen und können hier auch 'Install From Local File' auswählen (aktuell lassen sich die benötigten Jdeveloper-Erweiterungen auch manuell von OTN herunterladen).

Hier werden die folgenden Erweiterungen ausgewählt:

• Oracle BPM Studio 11g
• Oracle Enterprise Repository Adapter
• Oracle Enterprise Repository Harvester
• Oracle SOA Suite Composite Editor

Ein OTN-Account wird benötigt...

... und die neuen Erweiterungen werden angezeigt.

Ein Neustart ist notwendig.
Sind alle Erweiterungen installiert, können die Verbindungen eingetragen werden.

Über File|New|Database Tier lässt sich die neue Database Connection anlegen.

Hier werden die Verbindungsdaten eingegeben, über den 'Test Connection' Button lässt sich die Verbindung überprüfen.

Über View|Database|Database Navigator lässt sich die Verbindung im JDeveloper anzeigen.

Über View|Application Server Navigator gelangt man in die entsprechende Ansicht. Hier ist bereits der intgrierte WLS eingetragen. Auf Rechtsklick erscheint die Auswahl zum Anlegen einer neuen Verbindung.

Standalone Server ist bereits voreingestellt.

Jetzt wird der Name vergeben, z.B. SOABPM

Das Admin-Password wird benötigt (standardmässig 'welcome1', im Workshop 'Oracle123')

Hier sind die korrekten Zugangsdaten einzutragen. Für den Workshop sind dies oel5r5 als Hostname und bpm_domain als Weblogic Domain.

Wie gewohnt lässt sich die Verbindung hier testen und der Wizard mit Finish abschliessen.

Der Application Server wird daraufhin im Navigator angezeigt und kann jetzt aus dem JDeveloper genutzt werden.
Zum Abschluss wird noch die Verbindung zum Enterprise Repository benötigt.

Wiederum über File|New, dann über General|Connections kann die Oracle Enterprise Repository Connection ausgewählt werden.

Auch hier wieder die Parametereingabe (Password Oracle123) mit entsprechender Testmöglichkeit, die URL ist http://oel5r5:7101/oer.

Über View|Resource Palette können alle eingetragenen Verbindungen angezeigt werden.

Speicherzuteilung erhöhen

Für die Wizards der BPM-Extension benötigt der JDeveloper mehr Speicher, als für den reinen Java-Betrieb. Daher sollte ihm mehr RAM zugestanden werden, zu konfigurieren ist dies in der Datei (Windows)

d:\Oracle\Middleware\jdeveloper\jdev\bin\jdev.conf

Darin wird die Zeile mit dem Parameter AddVMOption  wie folgt geändert:

AddVMOption  -XX:MaxPermSize=512M

Nach einem Neustart steht dem JDeveloper dann auch das benötigte RAM zur Verfügung.


Damit ist das Basis-Setup für den Workshop abgeschlossen.

--> Nächster Schritt: BPMN Application und Project anlegen