Oracle MFT (Managed File Transfer) is a new component introduced with the release of Oracle FMW 12c. Oracle MFT provides several mechanisms to transmit files, including very big ones, in a managed way; transfers can be monitored, paused and resubmitted. One of the many advantages of Oracle MFT is the ability it offers to provide and consume services from other FMW components. In the following example we are going to demonstrate how to integrate MFT with a SCA composite.
This scenario will simulate the transfer of a consolidated report from a company’s headquarters into several of its regional offices. But before the transfer gets executed, it will have to be approved by a reviewer.
For this implementation we will need two MFT transfers, one for sending the file from the headquarters to the SCA composite and another to send the file to the respective regional offices. In the middle the SCA composite will be in charge of interconnecting both transfers and the approval process. The following diagram shows the scenario.
A MFT process consists of one or more sources, one or more targets and one transfer that interconnects the sources with the targets. This scenario will need the following elements:
- Two MFT sources. One will use a file channel to obtain the report and the other one will receive the report from the SCA composite.
- Four MFT targets: one for sending the report to the SCA composite and one for each of the regional offices (three in total).
- Two transfers: one for sending the report the SCA target and another one for ending the report to the regional offices target.
- An SCA composite that will have a Human Task for the approval process and will use the MFT adapters to receive and send the reports.
MFT comes with a web interface that allows the definition and management of sources, transfers and targets. The MFT console can be reached in the following url: http://<host>:<port>/mftconsole/faces/login, where the host and the port are the ones from the managed server where MFT is installed.
The MFT console has three different views, the design view for the definition of sources targets and transfers, the monitoring view for managing and tracking the current instances and the administrative view for configuring MFT.
To create a new source, go to design mode and then select the sources item. Then click on the green ‘+’ to create a new source
The first source will be polling a directory for files and it will be called HQ-Reports
Once it is created, MFT allows you configure some specific parameters for this source, like the polling interval or some filters that restrict the files that are going to be processed.
MFT also allows you to define some processing steps that will be executed before the file is sent to the target. We will define for our scenario an action that compresses the file before sending it, in order to optimize the transfer of large reports.
Once this is done, the source is ready to be deployed. Click on save and then click on the deploy icon at the top right corner.
The second source will be called SOAReportApprover, will be of type “SOA” and we will set “RegionalDispatcher” in the url field. This url is the one that the SCA will use to send the report back. The part that is being defined on this screen represents only the last part of the url; MFT is going to append the server and context information afterwards so that at the end the definitive url looks like this: http://localhost:7001/mftapp/services/transfer/RegionalDispatcher
The first MFT target will be responsible for sending the report to the SCA composite. To create a target, select the targets elements on the design mode and click on ‘+’
We will named it “SOAHQDispatcher”, select SOA as type and leave the URL as localhost. Here we have to put the url of the SCA composite we want to communicate with, but we will have to wait until we deploy the SCA composite to know it’s value.
For the moment we can only save this target and we will deploy it when we configure the definitive SOA url.
The next target is going to send the report to a regional office. We will simulate this by saving the file into another directory on our host. It will have the name RegionalCenterPartner, will be of type “File” and it will have a dedicated folder on the local host where the file will be saved.
After this target has been created, it can be saved and deploy. The next two targets, RegionalNorthPartner and RegionalSouthPartner are very similar. They will only have different directories in the local host.
Transfers are created the same way as targets and sources. We will create two targets, one called HQMainReportSoa and the other one called RegionalReportTransfer.
In HQMainReportSoa we will define HQ-Reports as the source and SOAHQDispatcher as the target.
In the delivery properties, MFT allows you to configure how to send the file to SOA. The reference mode sends a link to file inside the internal MFT FTP server. The inline mode will send the binary code of the file inside the SOAP payload. In reference type, File, FTP and secure FTP can be chosen. For our sample we will send the reference and then we are going to choose FTP as reference type. We are going to save this transfer for now and we will deploy it when we deploy the SOA target
In the RegionalReportTransfer we will choose SOAReportApprover as source and RegionalCenterPartner, RegionalNorthPartner, RegionalSouthPartner as targets.
Here we can define pre-processing actions for each target. We are going to decompress the report that we previously compressed in the HQReport source. This target is ready now for deployment.
The SOA Composite will use two MFT adapters, one will be used as a service and the other will be used as a reference. It will also contain a human task for the approval of the transfer and a BPEL process to integrate all this components in a process. The service MFT adapter only needs a new name, whereas the reference MFT adapter requires a WSDL or a reference to an existing MFT source. For this example, we will use our existing MFT SOA source.
In order access the existing MFT sources, JDeveloper needs a connection to the MFT server
Afterwards, the wizard is able to identify the available SOA MFT sources. We will choose the SOAReportApprover:
The first thing the BPEL process will do is to receive the file information from the MFT adapter. It will assign the input parameter to some internal variables and it will send the response back to the service MFT adapter. The service MFT adapter defines a synchronous interface, meaning that it is expecting a reply. We will send the reply to the service MFT adapter before starting the HumanTask.
After the HumanTask is completed, the reference MFT adapter will be invoked in order to send the file to the regional offices. The interface from the MFT adapters is divided into two main parts: header and payload. The header contains the metadata from the file, including the name, the size and the MFT components involved in the transfer. The payload contains the file itself or the reference to it.
The input arguments of the reference MFT adapter are the same output arguments of the service MFT adapter. Therefore we will only copy these values in order to transfer the file to the regional offices.
At the end, our BPEL process will looks like this
After the SCA composite is deployed we can proceed to finalize the configuration of the SOAHQDispatcher. In the MFT console, in design mode, navigate to the targets and select the SOAHQDispatcher. Enter the url, save it and deploy it.
Go to the HQMainReportSOA transfer and deploy it if you haven’t done this previously.
Executing the demo
To execute the demo we will copy a large file into the folder we configured for the HQReports source. After copying it, MFT will read it after a couple of seconds. This pooling interval can be configured differently for each MFT source.
In the monitoring view we will get a dashboard with the last transfers.
If we click on the instance, we will get the detailed view of the transfer.
Here we can see that the file got transferred successfully from the HQReports source to the SOAHQDispatcher transfer and it got compressed along the way.
If we logon into the Worklistapp, we can see that a task was generated and the user can approve it or rejected. Furthermore MFT provides a link to the FTP server so we can access the file. This is possible because we passed the file as a reference.
After we approved the task we can now take a look at the MFT console again to see what happened to the second part of the transfer.
The monitor shows us the details for the transfer and also the details for every target.
Bonus Track: cleaning the instances
MFT stores records of all executed instances in order to allow users to monitor and resubmit transfers. It also stores the sent files so that an administrator can access them after the transfer took place. Similar as with the SOA Suite, strategies have to be developed in order to delete or archive instances and free up some space on the server.
MFT provides a series of WLST commands that allow the deletion of executed transfers. To execute this commands the wlst application located in <ORACLE_HOME>/mft/common/bin.
2) connect(‘weblogic’,’welcome1’,’t3://localhost:7001’) // connect with the admin user credentials
3) purgeInstanceData(’01-02-2013 00:00:00:00′, ’31-03-2015 00:00:00:00′, testMode=’FALSE‘) // we are deleting instances that were completed (default status) between the 1 of February 2013 and the 31 March 2015.
4) purgePayloads(batchId=’197639′) // this will delete the payloads that are stored in the file system. The batch id was obtained from step 3.