- Teil 1: Grundlagen
- Teil 2: ftp-Transfer
- Teil 3: Java Custom Callouts
- Teil 4: MFT Integration mit SOA-Suite
Posts mit dem Label MFT werden angezeigt. Alle Posts anzeigen
Posts mit dem Label MFT werden angezeigt. Alle Posts anzeigen
Dienstag, 24. Februar 2015
Oracle Managed Files Handson Tutorial
Freitag, 20. Februar 2015
Oracle Managed File Transfer (MFT) Handson - Teil 4: Integration mit der SOA Suite
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.
Dienstag, 10. Februar 2015
Oracle Managed File Transfer (MFT) handson - Teil 3: Custom Callouts in Java
Ü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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 | <?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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | 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
Freitag, 30. Januar 2015
Oracle Managed Files handson Tutorial - Teil 2: ftp-Transfer
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
Donnerstag, 29. Januar 2015
Oracle Managed File Transfer (MFT) handson - Teil 1: Grundlagen
Dieses Tutorial zeigt die ersten Schritte mit Oracle Managed File Transfer. Voraussetzung ist ein installiertes und laufendes System, die Installationsanleitung findet sich auf OTN unter http://www.oracle.com/technetwork/middleware/mft/documentation/index.html. Dieses Tutorial wurde unter Oracle Linux 6 erstellt, für andere Plattformen müssen die Betriebsystem-Kommandos entsprechend angepasst werden.
Los geht es in der MFT-Console, zu finden unter [servername]:[MFT-Server Port]/mftconsole, in diesem Beispiel http://localhost:7003/mftconsole. Die UI ist dreigeteilt in Design, Monitoring und Administration. Wir beginnen im Bereich Design, um zunächst die Strukturen festzulegen.
Zu Beginn werden drei Ordner im Dateisystem benötigt: File-Source, only-txt und only-zip. Um auch etwas Payload zu bekommen, benötigen wir noch zwei Textdateien mit aussagefähigen Dateinamen (unter Linux z.B. touch asdf.txt), eine davon wird anschliessend gezipped (zip hjkl.txt).
Diese Verzeichnissse müssen MFT zunächste bekannt gemacht werden. Hierzu öffnet ein Klick auf Sources im linken Teil den Create Source Dialog. Neben einem Namen wird hier der Type File und der eben angelegte Source Folder eingetragen. Beenden mit ‚Create'.
Analog werden per Klick auf Targets die beiden Ziele definiert.
Link sollte der Baum jetzt die Quelle und die beiden Ziele darstellen. Klickt man ein Element an, werden rechts Detailinformationen angezeigt.
Nun kann per Klick auf Transfers im der erste Transfer im Create Transfer Dialog definiert werden. Weitere Parameter lassen sich hier noch nicht eingeben.
In der Detailansicht des Transfers lässt sich via add source, oder alternativ per Drag&Drop aus der Baumansicht links, die vorhandene Quelle zuweisen.
Danach werden die Ziele zugeordnet. Via add target lassen sich hier auch mehrere Ziele auswählen, also können hier gleich beide Targets auf die rechte Seite verschoben werden.
Damit im only-zip Target die .txt Dateien gezipped ankommen, wird beim only-zip Target per <add pre-processing actions> eine Compress-Action hinzugefügt.
Das Ergebnis sollte dann wie oben abgebildet aussehen. Eine File-source als Quelle mit Wildcard *.txt. Beide Ziele, only-txt und only-zip, eingetragen. Bei only-zip gibt es noch eine Compress Pre-Processing Action.
Bislang ist der Transfer aber nur definiert, läuft aber noch nicht auf dem Server. Um das zu erreichen, wird oben auf die Buttons ‚Save' und danach auf ‚Deploy' geklickt. Der Dialog wird mit Deploy abgeschlossen und mit OK bestätigt. Der Button zeigt dann Deployed wie oben abgebildet.
Im Bereich Monitoring kann man unter Deployments sehen, dass die Quelle und die beiden Ziele ebenfalls mit deployed wurden, da diese vom Transfer benötigt werden.
Zum Testen wird auf Dateiebene eine Datei, z.B. die asdf.txt in den Ordner file-source kopiert.
Im Monitoring-Bereich lassen sich unter Dashbord die Transfers überwachen. Der Bereich Active Deliveries unten rechts lässt sich auf auto-Refresh stellen. Nach kurzer Zeit sollten unten rechts die beiden erfolgreichen Transfers angezeigt werden.
Im Dateisystem kann man sehen, dass die Datei in das only-txt Verzeichnis einfach kopiert wurde, während sie für das only-zip Verzeichnis noch komprimiert wurde.
Als Übung kann ein weiterer Transfer für die gleichen Ordner erstellt werden, der genau gegenteilig arbeitet. Zip-Dateien werden dann in only-zip kopiert, währen txt-Dateien vor dem Transfer gepackt und übertragen werden.
--> Teil 2: ftp-Transfer
Abonnieren
Kommentare (Atom)