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