Montag, 13. Dezember 2010

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.

Montag, 1. November 2010

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

Donnerstag, 28. Oktober 2010

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

Mittwoch, 20. Oktober 2010

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

Montag, 11. Oktober 2010

Workshop: PL/SQL-Webservice erstellen, Webservice deployen

Nachdem in den vorhergehenden Übungen der Webservice erstellt wurde und die Datenbank sowie der Weblogic Server vorbereitet wurden, kann jetzt der Webservice deployed werden.

Hierzu mit Rechtsklick auf das Projekt das Menü aufrufen und Deploy|WebServices auswählen.

'Deploy to Application Server wählen' und 'Next'

Den Application Server wählen, hier 'SOABPM' und 'Next'

Hier kann der Ziel-Server angegeben werden, was der gleiche sein sollte auf dem auch die Data Source angelegt wurde.

Noch einmal die Zusammenfassung und 'Finish'

Wenn alles geklappt hat, zeigt das Deployment Log unten '--- Deployment Finished ---'

Das Testen des Webservices erfolgt dann aus der Weblogic Server Administration Console. Links in der Domain Structure finden sich die Deployments, rechts muss ggf. über 'Next' geblättert werden bis die Hrservice-HRservice-context-root angezeigt wird. Durch Aufklappen des Baumes darunter findet man den hrInfoService, über den man weiter gelangt.

Auf dem Reiter 'Testing' befindet sich der Link zum Test client.

Bei einem Aufruf eines WLS in einer VM kommt es normalerweise zu einer Fehlermeldung, weil der WLS den Hostnamen aus seiner Sicht auflöst, was ausserhalb der VM typischerweise keine sinnvolle IP-Adresse ergibt. Ersetzt am die IP-Adresse aber durch den Hostnamen oder wahlweise durch die korrekte IP-Adresse, bekommt man den Test client, kann eine gültige empid eingeben und den Service über den gethrinfo-Button starten.

Sofern bis hier alles geklappt hat bekommt man die Daten zu der empid zurück, bei empid 100 ist das Ergebnis Steven King. Damit ist der Service fertig deployed und lauffähig.

---> Nächster Schritt: Webservice ins Enterprise Repository übernehmen