Follow Us on Twitter

Managed File Transfer (MFT)

December 2014 - Bij het automatiseren van bedrijfsprocessen zien we steeds vaker dat documenten een belangrijke rol spelen. Deze documenten zijn een belangrijk onderdeel van de informatiestromen die binnen de bedrijfsprocessen geautomatiseerd worden. De manier waarop bedrijfsprocessen geautomatiseerd worden, ondersteunt echter het uitwisselen van, met name grote, bestanden niet goed. Daarnaast is het ook niet verstandig om deze documenten telkens over en weer te sturen. Dit belast de infrastructuur onnodig en maakt versiebeheer van documenten onmogelijk. Daarom is het van belang om de documenten zo snel mogelijk bij binnenkomst in je IT landschap op een centrale plek op te slaan. Vervolgens hoef je alleen een referentie naar het document op te nemen in je informatiestromen. Voorheen had Oracle binnen de Fusion Middleware (FMW) stack hiervoor geen goede oplossing. Met de komst van de SOA Suite 12c heeft Oracle een nieuw product geïntroduceerd, namelijk Managed File Transfer (MFT).

Met dit Whitebook wil ik laten zien wat MFT is en hoe je het kunt inzetten binnen je Oracle Fusion Middleware landschap. Daarbij laat ik in het tweede deel van dit Whitebook een voorbeeld-implementatie van MFT zien.

Managed File Transfer

Managed File Transfer (MFT) is een product van Oracle waarmee het mogelijk is om op een eenvoudige wijze bestanden uit te wisselen. Daarvoor biedt het enkele standaardprotocollen zoals (embedded) FTP/SFTP en SOAP. Hiermee is het mogelijk om niet alleen bestanden te verplaatsen tussen verschillende directories maar om MFT te integreren binnen de FMW stack. Door gebruik te maken van het SOAP protocol kun je vanuit je proces MFT aanroepen of MFT gebruiken als start voor je proces.

Hoe werkt het

De configuratie en monitoring van MFT gebeurt volledig in een web interface. Daarin kun je zowel MFT configuratie (design) aanmaken/wijzigen en de reeds actieve configuratie monitoren.

Een nieuwe transactie binnen MFT configureer je in drie stappen:

  • Source;
  • Destination;
  • Transaction.

Source

Allereerst moet je de bron van het document configureren, de "Source". De source configuratie is de start van een MFT transactie. Hierin configureer je de type trigger. MFT ondersteunt zowel een push als een pull mechanisme. Het pull mechanisme wordt doormiddel van polling op filesystemen gerealiseerd. Zodra er een nieuw bestand geplaatst wordt pakt MFT dit middels (S)FTP/File adapter op. Hoewel MFT draait op een Weblogic server maakt het voor (S)FTP helaas geen gebruik van de mogelijkheden van de Weblogic server. Zo kun je geen reeds geconfigureerde FTP adapter of File adapters selecteren.

Het push mechanisme wordt gerealiseerd met behulp van een SOA (Composite), OSB, B2B of een SOAP interface. In essentie zijn deze gelijk aan elkaar, ze gebruiken allemaal het SOAP protocol en bieden de mogelijkheid om met een SOAP call een bestand naar MFT te sturen. In het bericht kan de inhoud van het bestand (base64binary) of een referentie (URL) naar het bestand staan. De URL kan vervolgens weer een FTP of een file locatie zijn.

Tijdens het schrijven van dit Whitebook is het niet duidelijk geworden wat de verschillen tussen de verschillende SOAP protocollen zijn. De configuratie van een SOA Source biedt dezelfde mogelijkheden als de SOAP Source.

Destination

In de Destination configuratie geef je aan waar het bestand naar toe verplaatst moet worden en hoe dit gedaan moet worden. Net als bij de Source configuratie heb je hier de keuze uit FTP, SFTP, File, SOAP/SOA, OSB en B2B.

Indien je voor een SOAP/SOA Destination kiest heb je de mogelijkheid om de payload inline mee te sturen. Daarbij kun je een threshold opgeven. Zodra het bestand groter is dan de gestelde threshold zal MFT een referentie van het bestand meesturen. Hierbij kun je kiezen uit file, embedded (S)FTP. De bestanden worden daarbij lokaal (bij de MFT server) opgeslagen. Hiermee kun je eenvoudig voorkomen dat de payload te groot wordt en je de middleware laag onnodig belast. Het is tevens mogelijk om er voor te kiezen om altijd een referentie mee te sturen. Ongeacht de grootte van het bestand.

Transformation

Met de Transformation configuratie koppel je de eerder geconfigureerde Source en Destination aan elkaar. Hoewel je maar één Source kunt configureren is het wel mogelijk om meerdere "Destinations" te specificeren. Daarnaast kun je aangeven of er nog extra acties tijdens de transactie uitgevoerd moet worden. Zo is het mogelijk om compressie of decompressie uit te voeren en biedt MFT nog encryptiemogelijkheden. Door deze modulaire opzet (scheiding van de drie stappen) is het mogelijk om je Source en Destination configuratie te hergebruiken.

Om een transactie te gebruiken dien je hem te deployen naar de MFT server. Dit kan eenvoudig vanuit de web interface met "een druk op de knop". Na het deployen kun je de configuratie direct gebruiken. MFT stelt je ook in staat om configuratie te exporteren en vervolgens in een andere omgeving te importeren.

MFT Dashboard

Logging

De transactie logging van MFT kun je bekijken in dezelfde web interface. In de monitoring tab kun je per transactie kijken wat er met het bestand is gebeurd. Waar het document vandaan kwam, of er een transformatie heeft plaatsgevonden en waar het document naar toe is gegaan. Eventuele fouten worden per transactiestap gelogd zodat je kunt zien wat de oorzaak van de fout was.

Transactie Logging Dashboard

Gezien de positie van MFT binnen de FMW stack is het niet meer dan logisch dat de logging van MFT is gekoppeld aan de logging van FMW. Hierbij maakt MFT gebruik van de sinds 12c geïntroduceerde Correlation Flow Id. Dit ID gebruikt Oracle om logging van verschillende FMW componenten (bv. de OSB en de SOA Suite) aan elkaar te koppelen. Indien MFT gestart wordt vanuit een Composite (FMW component) of het een Composite aanroept zie je MFT als een aparte stap in de logging van de Composite (Audit Trail). Daarmee kun je vanuit de Audit Trail van je proces direct doorklikken naar de betreffende MFT transactie.

MFT met SCA Logging

Ontwerppatronen

Met de gestelde technieken, type Sources en Destination, biedt MFT een aantal mogelijkheden waarop het gebruikt kan worden. Zo is het mogelijk om MFT op een directory te laten pollen op specifieke bestanden. Daarnaast zijn er nog andere patronen mogelijk. Oracle heeft er een aantal van in zijn documentatie verder uitgelegd.

Case uit de praktijk

Binnen een recente klantcase kwam nog een ander patroon aan bod. Met een B2B koppeling worden berichten ontvangen met daarin zowel procesdata als bestanden (bijlage). De procesinformatie werd onder andere gebruikt om beslissingen te nemen binnen de orkestratielaag (in dit geval BPEL). De bijlagen moesten, zodra het proces was afgerond, opgeslagen worden in een content systeem. Dit betekent dat, totdat het proces is afgerond, de bestanden tijdelijk opgeslagen moeten worden. Hiervoor wilden we MFT als "Claim Check" service inzetten. Bij ontvangst checken we de bijlagen in. Hierbij krijgen we een referentie terug van MFT die we later kunnen gebruiken om het document op te slaan in het content systeem.

Claim Check Pattern

Dit betekent dat het proces een B2B referentie moet omzetten naar een MFT referentie. Dit patroon wordt niet direct door Oracle ondersteund. MFT biedt namelijk de mogelijkheid om een bestand met SOAP aan te bieden, het geeft dan geen referentie terug enkel een ontvangstbevestiging.

Met de Destination configuratie kun je aangeven waar de referentie (met een SOAP call) naar toe moet. Dit maakt het een vorm van asynchrone configuratie waarbij de correlatie tussen het verzoekbericht en het uiteindelijke antwoord niet is geregeld. Dit moet je zelf doen.

Hiervoor kun je de Correlation Flow Id gebruiken. Dit ID kun je met een property meegeven aan MFT en MFT stuurt het ook weer terug. Vervolgens kun je met een correlatie set de inkomende call weer aan het juiste proces koppelen.

Coorelation

Helaas stuurt MFT de meegestuurde ID niet mee terug in de property maar in een, niet gespecificeerde, headervariabele. Dit betekent dat je niet direct kunt correleren op de ID. Om deze toch te gebruiken binnen de correlatieset kun je een OSB proxy tussen MFT en SOA plaatsen. Met de OSB proxy kun je eenvoudig de headervariabele uit het bericht halen en vervolgens meegeven aan je BPEL proces. Op deze manier kun je het Claim Check patroon met behulp van MFT realiseren.

Conclusie

MFT is in essentie een eenvoudig product dat snel te gebruiken is. De eenvoudige web interface zorgt ervoor dat je snel aan de slag kunt. Binnen enkele klikken heb je een file poller staan die bestanden van de ene locatie naar de andere locatie verplaatst. Het is meer dan bestanden verplaatsen, want dankzij de web service mogelijkheden kun je MFT eenvoudig integreren binnen je Middleware landschap. Dit moet je ook al snel doen gezien de mogelijkheden van MFT die zich enkel en alleen beperken tot het verplaatsen van bestanden. Gezien de aard van het product is dit natuurlijk geen probleem. Het was alleen mooi geweest wanneer het, in de case uitgewerkte, claim check patroon "out of the box" zou werken.

Het grootste probleem van MFT zit hem echter niet in de techniek. Hoewel het duidelijk als onderdeel van FMW stack, specifiek de SOA Suite, wordt gepositioneerd is het geen onderdeel van de standaard licentie. Om MFT te gebruiken moet je het product dus apart aanschaffen. Waarbij de prijs per processor, gezien de functionaliteit die MFT biedt, erg hoog is. Daarmee loont het al snel om zelf een oplossing te schrijven in bijvoorbeeld Java.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.