BI-Publisher für OER im WLS installieren

Der Oracle BI-Publisher 10.1.3.4.1 kommt standardmässig noch mit einem eigenen oc4j. Nutzt man bereits das Oracle Enterprise Repository (OER) 11.1.1.x, möchte man den BI-Publisher aber mit auf dem Weblogic-Server des OER betreiben, um nicht zwei unterschiedliche JEE-Container für ein Produkt betreiben zu müssen.

Der BI-Publisher kann wie folgt manuell im WLS installiert werden:

1. Download BI-Publisher
Der BI-Publisher 10.1.3.4.1 ist auf OTN. erhältlich. Das zip-File wird in ein beliebiges temporäres Verzeichnis entpackt, unter Linux/Unix wird auch gleich noch das tar-File entpackt.

2. BI-Publisher installieren

• Ein Verzeichnis xmlpserver wird erstellt im applications-Verzeichnis der OER-Domain, wie z.B.
  
  /home/oracle/Oracle/Middleware/user_projects/applications/oer_domain/applications/xmlpserver
• Aus dem entpackten zip-File im Temp-Verzeichnis wird der Inhalt der Datei
  
  bipublisher.10.1.3.4.1/manual/generic/xmlpserver.war
  
  entpackt (nicht die Datei kopiert!) in das neu erzeugte Verzeichnis xmlpserver
• Im OER Homeverzeichnis befindet sich die Datei BIP-Oracle.zip unter
  
  $OER_HOME/core/tools/solutions/reports
  
  In diesem Archiv befindet sich der Ordner XMLP. Dieser wird in das gleiche Verzeichnis kopiert wie xmlpserver, also
  
  /home/oracle/Oracle/Middleware/user_projects/applications/oer_domain/applications/XMLP
• Die Datei xmlpserver/WEB-INF/xmlp-server-config.xml wird angepasst, so dass diese auf den Ordner XMP verweist, z.B.
  
  <?xml version="1.0" encoding="UTF-8"?>
  <xmlpConfig xmlns="http://xmlns.oracle.com/oxp/xmlp">
    <resource>
      <file path="/home/oracle/Oracle/Middleware/user_projects/applications/bpm_domain/applications/XMLP"/>
    </resource>
  </xmlpConfig>
• Die Fonts aus dem temporären Verzeichnis unter manual/fonts müssen in das fonts-Verzeichnis der benutzten JRE kopiert werden, z.B. nach
  
  /home/oracle/Oracle/Middleware/jdk160_24/jre/lib/fonts
• Die xmlpserver-Anwendung wird über die WLS-Console deployed und gestartet.

• Auf der Deployments-Seite klickt man ggf. auf 'Lock &amp; Edit' und dann rechts auf einen 'Install'-Button

• Hier wird zum Verzeichnis xmlpserver navigiert -> Next

• 'Install this deployment as an application' wird hier ausgewählt -> Next

• Auswahl 'I will make the deployment accessible from the following location' -> Finish
  Ggf. 'Activate Changes', danach links wieder auf 'Deployments klicken.

• Die Anwendung wird gestartet durch Setzen des Hakens und Start/Servicing all requests. Danach mit 'Yes' bestätigen und der Status wechselt auf 'Active'.

• Getestet werden kann die Installation über die entsprechende URL, z.B.
  
  http://oel5r5:7101/xmlpserver/servlet/report
  
  Benutzername und Password sind beide 'Administrator'

3. Oracle Enterprise Repository für BI-Publisher konfigurieren

• Im BI-Publisher Web-Frontend wird im Bereich Admin die JDBC-Connection ausgewählt

• Hier die Data Source 'OER' auswählen

• Dann die Verbindungsinformationen anpassen und per 'Test Connection' überprüfen. Beenden mit 'Apply'

• Jetzt noch im Bereich Admin unter 'Users' das Password von oer setzen

• Diese Konfiguration muss jetzt noch dem OER bekannt gemacht werden. Hierzu werden im OER auf dem Admin-Reiter unter 'System Settings' die folgenden Parameter entsprechend gesetzt:
  - Enable Reports = True
  - Report Server URL = http://oel5r5:7101/xmlpserver/OER
  - Report Server Endpoint URL = http://oel5r5:7101/xmlpserver/services/PublicReportService
  - Report Server Username = oer
  - Report Server Password = wie oben gesetzt

• Im Reports-Bereich des OER kann die Integration mit dem BI-Publisher überprüft werden. Tauchen hier im oberen Bereich rote Fehlermeldungen auf, ist bei den letzten Schritten etwas falsch gelaufen und diese sollten überprüft werden. 

Sofern alles richtig gelaufen ist, können die Reports ausprobiert werden, wie hier z.B. der 'Policy Status Report'.

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.

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