SOA 12c - Managed File Transfer Hands On

MFT (Managed File Transfer) is out of box functionality introduced in Oracle SOA 12c. By using MFT we can securely exchange the files between two internal or external points. In this post, we will see how to transfer one sample file from one local folder to another local folder. You can also transfer the file to any other point like FTP, SFTP etc but for simplicity we took local folders.

Let’s start with the exercise, first open the MFT console by going to (http://host:port/mftconsole) link. You will see below screen, at the top you can see three links. Design link is used by developer to do define required parameters to transfer the file. Monitoring link is used to monitor the file transfer and administration link is used for administration purpose.

Click on Design link and now we define the source parameters where we place the sample file and MFT pick it from here. As mentioned earlier we are using local folder for source so we give source a name and choose “File” from drop down list. You also need to specify folder path.

As shown in below screen shot, you can also set advance properties for source.

Now as we define the source, define the target as well. We again choose file from drop down list and provide the folder path. As mentioned above again we use local folder for target so MFT will pick the file from source path and place it at target folder.

As shown in below screen shot, you can set advance properties for target.

Once you define the source and target, next step is to define the transfer. In ransfer, first provide the transfer name, note that transfer name should be meaningful, it should be like , we can easily recognize what are source and target points involved in this transfer. Click on create, you will see transfer definition screen pops up. In this screen we choose required source and target.  

In above screen, click on add source link and choose above created source. Now we need to specify the file name which we need to read from source folder. To do that click on content filters and choose wildcard from dropdown and specify file wildcard pattern.

Now we choose target, to do that click on add target link and choose before created target.

Now we need to define the schedule, this schedule triggers the MFT transfer from source to target. To define the schedule click on add schedule link and fill required scheduling details. 

Once done click on save, now next step is to deploy newly created MFT transfer to server. This will enlist all the artifacts which will get deployed to the server.

Now place the file at source folder and this file should be picked by MFT to transfer it to target folder. You can also monitor this file transfer, to do click on Monitoring tab as shown in below diagram and choose the transfer instance which you want to monitor.

As you can see in below screen shot , file transfer got failed and below screen show the file transfer status. There is also one option to re-submit the file transfer.

SOA 12c - Design Fault Policy from Fault Policy Wizard

Fault handling framework is used to handle faults using fault policy and fault binding files. In earlier version of SOA suite which was 11g, we have to create these files manually. There was no provision to create these files from any wizard. Manual process is always error prone and it is quite difficult to remember all fault names and actions which we need to use in fault policy file. Oracle came up with fault policy wizard in SOA 12c, we can use that fault policy wizard to create fault policy file to handle faults in composite. This makes it less error prone and more productive. In this post, we will see how to create fault policy file from fault policy wizard and how to link it to fault binding file.

For this post, we have created a sample composite which invokes one target service. When we shutdown the target service then remote fault gets generated in sample composite which invokes target service. We will handle that remote fault in fault policy file and using alert send that message to JMS queue.

To create fault policy file, right click on the project and click on New àFrom Gallery. Choose Faults option under SOA Tier and select Fault Policy Document to create new fault policy file.

You can change the fault policy name from default “policy1” to any name as per your naming standards. You can choose the Fault Name which you need to handle in this fault policy, you can handle multiple faults in one policy, to add additional fault name you can click on Green plus sign. You can also change the default action from drop down list. We renamed the policy file and choose remoteFault as a fault name as we are going to handle this fault using fault policy file.

Now we will choose the alert which gets triggered when that fault occur. This is the additional feature provided in fault policy file. There are three types of alerts (email, JMS and Log) provided. We will create JMS alert for this post so choose JMS from the list. Provide the alert name and click on “Create Required Properties” tab to create required property set for JMS alert. Provide the property set name and specify required properties for JMS queue, once done click on Ok.

Now we link above created alert to default action so whenever remote fault occur, process get terminated as a default action and message gets populated to JMS queue as JMS alert.

With the above step you are done with fault policy creation from fault policy wizard, now we will create fault binding file and link this fault policy file to composite, components, services and references.

Click on highlighted icon and bind the fault policy file to required components, services and references.

Now deploy your composite and test it. Make sure target service is down so that remote fault gets generated. That remote fault will be handled by fault policy file, it terminate the instance and send the message to JMS queue.

SOA 12c - Encryption and Decryption of Sensitive Data

Oracle SOA Suite is used for reliable transfer of information, it stores whole the message in SOA_INFRA schema. We can see incoming and outgoing messages in audit trail from EM console. That means user which has access to EM console can see all the messages coming and going through middleware, sometimes some of the information which is flowing through Oracle SOA Suite is very critical and SOA Suite user should not have access to see that critical piece of information. In this post we will discuss how to fulfill this requirement using Oracle SOA Suite.

In previous version of Oracle SOA Suite (11g) there were no out of box provision to encrypt and decrypt sensitive data so user can see the data which is flowing through fusion but in current version of Oracle SOA Suite which is 12c, Oracle provided out of box functionality to encrypt specific fields in the message which is flowing through middleware. Below is sample encrypted message field.

In Oracle SOA 12c, encryption policy is used to encrypt and decrypt the message, message encryption happens at component binding that means message get encrypted before it come to component (BPEL or Mediator) and we see only encrypted message in audit trail. Message decryption happens at reference binding level that means message fields get decrypted before it is sent to target service/system.

Let’s see in detail how to encrypt and decrypt a specific field in message.  For this post we have created a target service which is noting a SOA composite, we also created another SOA composite (Sales Order Composite) where we perform data encryption and decryption. Sales Order composite invokes target service. Sales Order composite receives message from source system and it contain below shown fields in the message. From these fields “Quantity” field is critical and we don’t want to show actual value for this field in EM console so we encrypt this field in this post.

How to encrypt sensitive field

To do encryption, right click on the source bindings and choose “Encrypt Sensitive Data”. This open another pop-up where you can see out of box policy used for the encryption. Click on the edit button so that we can define the message field which we want to encrypt.

 

Once you click on the edit button, this opens another window. Click on plus sign to choose the required field which we need to encrypt. For this post, we encrypt quantity field. Once done click on next, now we need to provide CSF-key value, by default it choose “pii-csf-key”. Click on finish.

Make sure pii-csf-key should exist, if it does not exist then you will not be able to encrypt the message and see error message. Click here to see how to create csf-key.

How to decrypt sensitive field

As mentioned earlier in the post, field decryption happens at reference binding level. To perform decryption, right click on the reference binding and choose “Decrypt Sensitive Data”. This open another window where you can see the out of box policy used for decryption, click on edit sign and choose the field which you need to decrypt. Also choose the default csf-key.

Save your composite and deploy it to the server.

Testing Results

Now test your sales order composite, once you open the sales order composite instance and open the audit trail for receive activity, you see quantity field is encrypted.

Now let’s open the target service instance. As you can see in below screen shot, field decryption happens at sales order composite reference binding level and quantity field is passed to target service in plain text.

Download sample code from here.