Oracle Fusion Middleware Deutsch

Freitag, 29. Mai 2015

Oracle Enterprise Scheduler Service (ESS) Handson Tutorial

Der Enterprise Scheduler Service (ESS) wurde ursprünglich aus Eigenbedarf entwickelt und stammt aus der Oracle Applications Entwicklung. Seit einiger Zeit ist der ESS aber auch Bestandteil der Oracle SOA Suite und steht somit Anwendern für eigene Aufgaben zur Verfügung.
Wie der Name andeutet, dient der ESS dem zeitgesteuerten Ausführen von Jobs. Im Gegensatz zu einfachen cron-Jobs bietet der ESS aber viele zusätzliche Funktionalitäten, welche im Enterprise-Umfeld benötigt werden. Der ESS kann in einen Cluster deployed werden um Hochverfügbarkeit herzustellen, es können Abhängigkeiten zwischen Jobs definiert und aufgelöst werden, Resource-Management kann betrieben werden und die Verwaltung sowie das Monitoring können direkt aus der Enterprise Manager Console erfolgen. Komplexere Szenarien können programmatisch über die ESS API's (Java, Web Services) umgesetzt werden.
Der ESS ist damit gut gewappnet auch für komplexeste Szenarien im Enterprise Umfeld. Dieses schlägt sich auch im Umfang der ESS Dokumentation wieder, die in Summe über 800 Seiten auf die Waage bringt. Wer die vielfältigen Möglichkeiten des ESS in Gänze nutzen möchte, kommt um die umfangreiche Lektüre wohl nicht herum. Oftmals wird in Projekten aber auch nur ein einfacherer Scheduler benötigt. In der umfangreichen Dokumentation einen Einstieg zu finden, ist nicht leicht. Dieses Handson-Tutorial soll über die ersten Schritte hinweghelfen.

Überprüfen der Installation

Der ESS wird typischerweise mit der SOA installiert, ist aber nicht zwingend in der Domain-Konfiguration enthalten.

Über den Domain Configuration Wizard ($MW_HOME/soa12103/wlserver/common/bin/config.sh) wird die vorhandene Domain aktualisiert. Wichtig ist, dass die beiden Punkte Oracle Enterprise Scheduler Service Basic und Oracle Enterprise Manager Plugin for ESS angehakt sind. Falls diese fehlen, müssen sie hier nachinstalliert werden.

Wichtig ist auch, dass auch das Datenbank-Schema bereits angelegt ist.

Und schliesslich muss die ESSAPP auf einen Managed Server deployed sein, typischerweise wie hier auf einen eigenen ess_server1 oder mit auf dem soa_sever1.

Wenn alles installiert ist, sollte sich die ESS Health Check Seite aufrufen lassen unter server:port/EssHealthCheck.

Die Verwaltung für den ESS ist in den Enterprise Manager integriert. Wichtig: solange der Managed Server mit dem ESS noch nicht gestartet wurde, wird auch die Auswahl Scheduling Services links nicht angezeigt, auch wenn alles bereits richtig installiert wurde. Erst nach dem ersten Start taucht die Option auf.

Zum Testen wird ein kleines Script benötigt, z.B. dieses test.sh im Homeverzeichnis des Oracle-Users:
date >> /home/oracle/ess.txt
Hiermit wird einfach die Ausführungszeit an die Datei ess.txt angehängt.

Um das Script über den ESS laufen zu lassen, muss zunächst eine entsprechende Job-Definition erstellt werden.

Auf der Job Definitions Seite wird über Create ein neuer Job erstellt.

Hier wird das Script jetzt dem ESS bekannt gemacht. Wichtig ist, den Job Type auf ProcessJobType umzustellen. Danach kann der vollständige Pfad zum Script eingegeben werden. Abschliessen mit OK.

Die Job Definition ist jetzt zwar im System bekannt, wurde aber noch nicht zur Ausführung vorgesehen. Hierzu muss ein Job Request erstellt werden.

Die bestehende Job Definition kann über die Suche (Lupe) ausgewählt werden. Gibt man keine weiteren Parameter an, wird die Ausführung sofort und genau ein Mal vorgesehen.

Auf der Hauptseite des ESS sollte kurz danach ein erfolgreicher Job Request angezeigt werden.

Die Ausführung kann auch durch Blick in die Ausgabedatei ess.txt bestätigt werden.

Nun kann der ESS die Jobs natürlich nicht nur sofort, sondern auch zu festgelegten Zeiten ausführen. Hierfür muss ein Schedule definiert werden.

Über den Create Button kann ein neuer Schedule angelegt werden.

Hier können auch Intervalle eingegeben werden, z.B. alle zwei Minuten.

Nachdem der Schedule angelegt ist, kann damit ein neuer Job Request erstellt werden.

Hier werden jetzt links der bestehende Job Request und rechts der gerade erstellte Schedule eingetragen und das ganze per OK abgeschlossen.

Nach zwei Minuten sollten dann auch die Rückmeldungen in der Ausgabedatei eintreffen und mit etwas Zeitverzug auch auf der ESS-Hauptseite des Enterprise Manager auftauchen.
Trotz der komplexen Möglichkeiten und der Dokumentation im hohen dreistelligen Bereich lassen sich also trotzdem einfache Scheduling-Aufgaben schnell mit dem ESS umsetzen.

Dienstag, 24. Februar 2015

Oracle Managed Files Handson Tutorial

Dieses Tutorial soll durch die ersten Schritte mit dem neuen Oracle Managed File Transfer (MFT) helfen. Als Voraussetzung wird eine installierte SOA-Suite mit MFT benötigt, der grundsätzliche Umgang mit der SOA-Suite sollte bekannt sein. Betriebssystemseitig wurde Oracle Linux benutzt, das Ganze funktioniert aber analog auch unter Windows.

Freitag, 20. Februar 2015

Oracle Managed File Transfer (MFT) Handson - Teil 4: Integration mit der SOA Suite

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Nutzt man sowohl MFT, als auch die SOA-Suite, dann macht es Sinn diese miteinander zu integrieren. So kann die SOA-Suite Daten auch direkt an MFT übergeben und dieses kümmert sich dann um die Weiterverteilung im Dateisystem. Umgekehrt kann die SOA-Suite auch Ziel einer MFT-Transaktion sein und die Inhalte direkt entgegennehmen.
Für dieses Beispiel wird eine Domain mit MFT und SOA Suite benötigt. Der grundsätzliche Umgang mit beiden Produkten sollte bekannt sein.

Los geht es auf der Design-Seite der MFT-Console. Hier wird eine neue Source vom Typ SOA angelegt, z.B. mit dem Namen service-source (Wichtig: der Name soa wie abgebildet führt später zu Problemen und sollte nicht verwendet werden).

Als nächstes wird ein Transfer angelegt und die eben erstellte service-source als Quelle eingetragen. Als Target wird ein beliebiges File Target genommen, z.B. das file-target aus Kapitel 3.
Zum Abschluss werden mit Klick auf Save und Deploy die beiden neuen Artefakte deployed.

Weiter geht es im JDeveloper mit einem neuen SOA-Projekt.

In das Composite wird rechts bei den References ein MFT-Adapter gezogen.

Der Default kann übernommen werden.

Hier auch einfach den Default belassen.

Hier wird die bestehende Application-Server Connection angegeben, oder ggf. neu angelegt. Der MFT Server wird dann automatisch gefunden. Per Klick auf Test MFT lässt sich die Verbindung überprüfen.

Die service-source wird automatisch gefunden, beenden mit Finish.

Um den MFT Adapter anzusprechen, wird ein BPEL-Prozess in das Composite gezogen. Dieser wird auf Synchronous BPEL Process umgestellt, der Rest kann so bleiben.

Der BPEL-Prozess wird mit dem MFT-Adapter verbunden und hinterher per Doppelklick geöffnet.

Im Prozess wird mittig eine Invoke-Aktivität platziert und diese mit dem MFT Partner Link verbunden.

Die Input- und Output-Variable wird jeweils über das grüne Plus (+) angelegt. Dann mit OK schließen.

Es wird noch eine Assign-Aktivität benötigt, die vor das Invoke gezogen wird. Diese wird per Doppelklick geöffnet.

ns1:InlinePayload bekommt per Rechtsklick eine Expression zugewiesen.

Passend zum jeweiligen Bundesland kann hier eine angemessene Begrüßung zusammengeklickt werden, in meinem Fall:
concat("Moin, Moin ", $inputVariable.payload/client:input)

Das gleiche wird wiederholt für ns1:TargetFilename. Da sich hier um den Namen der Zieldatei handelt, sollten Sonderzeichen vermieden werden. Z.B.
concat("Hello-",$inputVariable.payload/client:input)

Das Composite ist damit fertig und wird deployed (Rechtsklick auf Projektname|Deploy). Danach wird der Enterprise Manager geöffnet und das Projekt ausgewählt. Auf der Testseite wird ein Teststring eingegeben und der Test gestartet.

Wenn alles geklappt hat, kann hier der Flow Trace aufgerufen werden.

Im Flow Trace wird MFT mit angezeigt, weiter geht es mit einem Klick darauf.

Von hier wird man in die MFT Console weitergeleitet und bekommt hier direkt den Transfer angezeigt.

Auch im Filesystem ist das Resultat zu finden.

Damit ist das MFT-Tutorial abgeschlossen.

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Dienstag, 10. Februar 2015

Oracle Managed File Transfer (MFT) handson - Teil 3: Custom Callouts in Java

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Über Custom Callouts in Java lässt sich die eingebaute Funktionaltität von MFT durch eigenen Code erweitern. Dabei lässt sich feingranular steuern, wann im Prozess dieser Code ausgeführt werden soll. Grundsätzlich werden drei Dinge benötigt: der eigentliche Java Code, eine XML-Datei welche MFT beschreibt, was sie mit diesem Code anfangen soll und ein WLST-Call mit dem das Callout bei MFT bekannt gemacht wird. Die komplette Dokumentation findet sich auf OTN, dieses Tutorial soll an einem simplen Beispiel das Erstellen und Einbinden von Custom Callouts demonstrieren.
In diesem Beispiel wird ein Custom Callout entwickelt, welches den Dateinamen durch die aktuelle Systemzeit ersetzt. Als Voraussetzung sollte man wissen, wie man eine Java-Klasse erstellt und übersetzt sowie den Teil 1 dieses Tutorials abgeschlossen haben.

package com.oracle.callout.sample;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.Map;
import java.util.Date;

import oracle.tip.mft.engine.processsor.plugin.PluginContext;
import oracle.tip.mft.engine.processsor.plugin.PluginOutput;
import oracle.tip.mft.engine.processsor.plugin.PreCalloutPlugin;


public class FilenameCallout implements PreCalloutPlugin {

 @Override
 public boolean isPayloadChangeRequired(PluginContext context,
   Map<String, String> calloutParams) {
  return false;
 }

 @Override
 public PluginOutput process(PluginContext context, InputStream input,
   OutputStream out, Map<String, String> calloutParams) {
  String type = calloutParams.get("Type");

  return null;
 }

 @Override
 public PluginOutput process(PluginContext context, InputStream input,
   Map<String, String> calloutParams) {

  PluginOutput pOutput = new PluginOutput();
  pOutput.setNewFileName("MFT " + new Date() );
  return pOutput;
 }
}

Alle Imports bis auf java.util.Date werden für jedes Callout benötigt. Mit isPayloadChangeRequired() wird unterschieden, welche der beiden folgenden Methoden aufgerufen wird. Da in diesem Beispiel nur der Dateiname, nicht aber der Inhalt geändert wird, gibt isPayloadChangeRequired() false zurück und die zweite process() Methode wird aufgerufen. Die erste Variante wird nicht benötigt und gibt einfach null zurück.

[oracle@oel6ab src]$ javac -classpath "/home/oracle/Oracle/Middleware/soa12103/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar" com/oracle/callout/sample/FilenameCallout.java 
[oracle@oel6ab src]$ jar cf FilenameCallout.jar com/oracle/callout/sample/FilenameCallout.class 
[oracle@oel6ab src]$ ll
total 12
drwxr-xr-x. 3 oracle oinstall 4096 Feb  6 15:23 com
-rw-r--r--. 1 oracle oinstall 1187 Feb  9 16:42 FilenameCallout.jar

Die Klasse wird dann einfach wie oben übersetzt, hier sind ggf. nur die Pfadnamen anzupassen. Im zweiten Schritt wird ein jar-File erzeugt, welches damit auch schon fertig ist.
Im nächsten Schritt wird die XML-Datei erzeugt, damit MFT weiss, was es mit dem JAR anfangen soll.

<?xml version="1.0" encoding="UTF-8"?>
<mft:Callouts xmlns:mft="http://xmlns.oracle.com/mft" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://xmlns.oracle.com/mft callout.xsd ">
 <mft:Callout description="Filename conversion"
  helpText="File name conversion"
  groupName="Source-pre,Target-pre,Target-post" 
  timeout="300" 
  implementationClass="com.oracle.callout.sample.FilenameCallout"
  libraryName="FilenameCallout.jar" 
  name="Filename conversion">
 </mft:Callout>
</mft:Callouts>

Das XML-File dazu ist recht gradlinig. Wichtig ist der Name, welcher in einem MFT-System eindeutig sein muß. Die Attribute libraryName und implementationClass sind selbsterklärend.

Die beiden Dateien müssen jetzt in das mft-Verzeichnis der jeweiligen WLS-Domain kopiert werden. Falls der Unterordner callouts noch nicht vorhanden ist, wird er manuall erstellt. Danach werden FilenameCallout.jar und FilenameCallout.xml in das callouts-Verzeichnis kopiert.

CLASSPATH=:/home/oracle/Oracle/Middleware/soa12103/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect("weblogic","welcome1","t3://localhost:7003")
Connecting to t3://localhost:7003 with userid weblogic ...
Successfully connected to managed Server "mft_server1" that belongs to domain "soa_domain".

Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.

wls:/soa_domain/serverConfig> crtCalls("/home/oracle/Oracle/Middleware/soa12103/user_projects/domains/soa_domain/mft/callouts/FilenameCallout.xml")
Callout Filename conversion created.

wls:/soa_domain/serverConfig> listCallouts() 
Callouts
-----------
[Name:Filename conversion, Library:FilenameCallout.jar, Impl Class:com.oracle.callout.sample.FilenameCallout, Description:Filename conversion, Group:Source-pre,Target-pre,Target-post]
wls:/soa_domain/serverConfig>

Um MFT mit seinem neuen Callout bekannt zu machen, wird das WLST benötigt. Damit es die spezifischen Kommandos von MFT kennt, wird es gestartet über das wlst.sh aus dem MFT-Verzeichnis unter $MW_HOME/mft/common/bin. Dass man das richtige Skript benutzt hat, erkennt man dann wie oben in der ersten Zeile am CLASSPATH Ausdruck.
Als erstes ist es mit dem WLST notwendig, sich auf den betreffenden Server zu verbinden. Dann wird über crtCalls(...) mit einem Parameter, der auf die XML-Datei zeigt, das Callout registriert. Via listCallouts() kann man sich alle registrierten Callouts anzeigen lassen, deleteCallout(...) entfernt es wieder.

Jetzt werden wieder zwei Verzeichnisse für Quelle und Ziel benötigt. Das können z.B. die Verzeichnisse aus dem ersten Teil sein, oder man legt einfach zwei neue an.

In der MFT-Console werden die beiden Verzeichnisse, analog zu Teil 1, wieder als Source und Target bekannt gemacht. Dann wird ein Transfer mit diesen beiden Verzeichnissen erstellt.

Nach Klick auf <add pre-processing actions> kann im Dialog jetzt auch 'Filename conversion' ausgewählt und mit Add to List hinzugefügt werden.

Das Ergebnis sollte dann wie oben abgebildet aussehen. Speichern mit Save, danach abschließen mit Deploy.

Nach kurzer Zeit sollte der erfolgreich verlaufene Transfer im Dashboard angezeigt werden.

Auch im Dateisystem sollte die übertragene Datei mit dem geänderten Dateinamen jetzt auftauchen. Damit ist das Handson-Tutorial zu Custom Callouts in Java abgeschlossen.

Teil 4: Integration mit der SOA Suite

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Freitag, 30. Januar 2015

Oracle Managed Files handson Tutorial - Teil 2: ftp-Transfer

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Nachdem im ersten Teil nur Dateien transferiert wurden, die im direkten Zugriff liegen, werden in diesem Teil Dateien per ftp übertragen. Da MFT eine Anwendung auf einem Weblogic-Server ist und dessen Berechtigungskonzept nutzt, müssen die Berechtigungen zunächst in der Weblogic-Console (http://HOSTNAME:PORT/console, z.B. http://localhost:7001/console) vergeben werden.

In der Weblogic Console geht es los bei Security Realms, dann rechts auf myrealm klicken.

Dort geht es weiter unter ‚Users and Groups', dann ‚New' klicken um einen neuen Benutzer anzulegen.

Name und Password vergeben, beenden mit ‚OK'

Der Benutzer ist jetzt zwar im Weblogic bekannt, hat aber noch keine Rechte im MFT. Hierzu geht es weiter in der MFT-Console. Unter Administration links im Baum unter Embedded Servers den Eintrag User Access auswählen.
Dann den User suchen, dazu im Suchfeld die ersten drei Zeichen ‚ftp' tippen und den vollständigen Namen aus der Auswahlbox übernehmen. Mit dem Rechtspfeil daneben wird der User übernommen.
Für den standardmässig vorhandenen Folder /ftptransfer dann die beiden Haken bei Write und bei List setzen und mit Save beenden.

Den ftp-Port kann man sich auch unter Embedded Servers unter Ports anzeigen lassen.

Mit dieser Information lässt sich jetzt ein erster Verbindungstest zum internen ftp-Server durchführen. Hierfür kann jeder ftp-Client genutzt werden, z.B. via Shell: ftp localhost 7021. Aus Bequemlichkeit sollte der ftp-Client dort gestartet werden, wo eine gezippte Testdatei (z.B. das hjkl.zip aus Teil 1) liegt.
Die ftp-Session kann offen bleiben, wir brauchen sie gleich noch.

Damit die Dateien vom internen ftp-Server weitergeleitet werden, wird eine weitere Quelle benötigt. Diese wird genau wie im ersten Teil angelegt unter Design, Sources. Dieses Mal wird der Typ FTP Embedded ausgewählt und der Pfad via Browse ausgewählt. Das Verzeichnis ist schon vorhanden, da MFT für jeden ftp-User gleich ein Verzeichnis anlegt.

Passend zu der Quelle wird auch ein neuer Transport angelegt.

Als Source wird die neue ftp-source eingetragen, die Ziele sind wieder die selben wie im ersten Teil. Das only-txt Target bekommt noch ein Decompress als post-processing Action.
Und wichtig: Beenden wieder mit Save und Deploy.

Um den ftp-Transfer zu testen, kann die vorher geöffnete ftp-Session genutzt werden. Die Kommandos hierfür sind bin (Binary, für zip) und put hjkl.zip, zur Überrprüfung gefolgt von ls. Die Datei sollte dann angezeigt werden.

Wie auch im vorigen Beispiel sollten die beiden gelieferten Dateien im Monitoring Dashboard unten rechts nach kurzer Zeit auftauchen.

Das Ergebnis läßt sich auch auf Dateiebene überprüfen. Wenn die Dateien entsprechend angekommen ist, ist dieser Tutorial-Teil zum integrierten ftp-Server abgeschlossen.

--> Oracle Managed File Transfer (MFT) handson - Teil 3: Custom Callouts in Java

[Teil 1] [Teil 2] [Teil 3] [Teil 4]