In Part 1 of MFT to HCM integration, we configured MFT to perform a batch upload of employees from an SFTP folder to HCM and informed HCM to import the data.

Once the file is placed in the source folder, its picked automatically by Oracle MFT and then transferred to the Target. After the target has successfully received the file, MFT again takes care of invoking any dependent actions. These post-processing actions include items such as decompressing, decrypting, renaming, calling a downstream action, and notifications.

MFT provides default activities, as well as a flexible callout extension framework built in Java that can utilised to call any action you wish.

Here in Part 2, we will talk about design and deployment of the Post-Processing Java Callout that is utilised to trigger the HCM Cloud ImportAndLoadData service.

This blog utilises sample code developed by Pandurang Parwatikar. Grab it from our public GIT!

Quick Refresher on HCM Data Loading

Batch Upload to HCM is a 2-step process:

1. Upload the file into WebCenter Content / UCM

   https://[HCM_Base_URL]/cs/idcplg

2. Make a SOAP call with the WebCenter ContentID to load the file

   https://[HCM_Base_URL]/hcmCommonDataLoader/HCMDataLoader?WSDL

The Callout Framework

MFT provides 2 scaffolds to utilise for pre-processing and post-processing actions. More information can found at: Processing Transfers with Custom Callouts

The high-level steps for creating a custom callout are:

1. Create the Java source code based on the appropriate interface and package it in a JAR file.
2. Create a callout definition XML file based on the callout schema.
3. Copy the JAR file and the XML file into the callout directory.
4. Run the createCallouts WLST command to configure the callout in MFT.
5. Test the callout by using it in a file transfer.

Reviewing the Sample Callout Code

Our sample is a single file called PostInvokeHCM.java, which must implement PostCalloutPlugin interface (oracle.tip.mft.engine.processsor.plugin.PostCalloutPlugin).

The main requirement of this interface is a function called process, defined as:

From this point on you can do anything in your code. In our sample, we specifically have a few sub-functions that:

• Update MFT Dashboard with Protocol Headers (providing visual tracking info on the MFT Dashboard)
• Create a SOAP Payload
• Perform a POST to HCM
• Prints the SOAP response into log

Deploying the Sample into MFT

Drop the 2 file into the MFTCS server (alternatively you can grab the core.jar file from MFT server and compile locally):

SSH into the MFT server.

Compile the code using MFT’s core.jar file:

javac -classpath $MW_HOME/mft/modules/oracle.mft/core.jar PostInvokeHCM.java

WHERE in my case for MFTCS it is: $MW_HOME = /u01/app/oracle/middleware

Create a jar file, which includes only the .class file, which we get in the above step:

jar cf PostInvokeHCM.jar PostInvokeHCM.class

Create the PostInvokeHCM.xml file which describes the Callout and the input it takes, as shown below. These file is required inform MFT of the callout’s existence and what fields to pass into it.

Copying the JAR and the XML file to the folder which holds all the Callouts:

By default your user is “opc” so change your user to “oracle”: sudo su – oracle

Once copied then we should Register the Callout, using the WLST Script. This is because, only registered callouts will be visible in the MFT console, and then which can be attached to either source or target.

Access WLST console:

/u01/app/oracle/middleware/mft/common/bin/wlst.sh

Connect to MFT server

connect(“weblogic”,”Welcome1#”,”t3://mftsvr-jcs-wls-1:9073″)

Note: Make sure you have the port for the MFT server rather than the Weblogic Admin Server. You can check this through the MFT server’s Weblogic Console (https://%5BMFT_Server_URL%5D:%5BPORT%5D/console). You can find the URL from the SOACS Dashboard.

Create the Callout:

createCallouts(‘/u01/data/domains/MFTSvr-j_domain/mft/callouts/PostInvokeHCM.xml’);

Delete Previous Callouts:

deleteCallout(‘PostInvokeHCM’);

Update Callouts:

updateCallouts(‘/u01/data/domains/MFTSvr-j_domain/mft/callouts/PostInvokeHCM.xml’);

Note: Below highlighted text in Yellow shows an error, as we tried to registering a callout which is already being used. In such cases, we should delete the Callouts used from any source or targets.

In order to see the newly registered callout, we need to logout and re-login into the MFT console. We can then see our Post-Processing callout listed under Target.

You can see 3 parameters listed in the popup, as shown above. These are the ones which are mentioned in the XML file.

Testing and Debugging the Callout

See Part 1 of this blog to create an SFTP to HCM transfer, attaching the PostInvokeHCM callout.

Transfer the file using SFTP and the file will be received at WebCenter.

System.outs will be contained in: /u01/data/domains/[YOUR_MFT_DOMAIN]/servers/[YOUR_MFT_SERVER]/logs/[YOUR_MFT_SERVER].out

In addition logs will be written to: /u01/data/domains/[YOUR_MFT_DOMAIN]/servers/[YOUR_MFT_SERVER]/logs/[YOUR_MFT_SERVER].log

Consume and enjoy!

* Content in post is thanks to: Rakesh Singh, Pandurang Parwatikar and Dave Berry