Integration

Get Involved. Join the Conversation.

Topic

    Moon Ray Lo
    Integration with HCM Extract Run & Retrieve Flow
    Topic posted December 15, 2018 by Moon Ray LoSilver Medal: 2,000+ Points, tagged Adapters, Agent, API, Cloud, Connection, Database, Integration, Mapping, Orchestration, PaaS, SAP, SOAP, Web Services 
    264 Views, 2 Comments
    Title:
    Integration with HCM Extract Run & Retrieve Flow
    Summary:
    This is to take note the best practices to observe when integrating OIC with HCM's Extract Run-Retrieve Flow
    Content:

    Hi Team,

     

    I'd like to ask for inputs from the group with regards to integrating HCM's Run-Retrieve Extract Flow with Oracle Integration Cloud. I have attached the sample OIC flow (initial design) we've come up with. Here are the requirements:

    1) Integrating HCM Core HR Data through Extract with SAP Payroll

    2) Sending data every 10minutes (OIC's limit for scheduled integration) from HCM to SAP for data synchronization.

    3) Extract Data sent are 'Changes Only' data, we are only sending changes in HCM to SAP within the 10-minute period (not master data).

     

    The attached initial design works fine for above requirements, as far as we've tested it (unfortunately we only have few test data available as of this writing). But there are still concerns though and I'd appreciate any inputs from the group to enhance the design:

    1) What if we process a full, master data extract run and takes longer time than the current delta-only run? (Will it raise timeout issue on OIC side? What's the runtime limit on OIC for every integration run?)

    2) Anyone have tried the callback option for SOAP WS? How does it work for Extract RunRetrieve Process?

     

    We want to consider a design that can handle both master and delta-only extract data in OIC. Appreciate all your inputs.

     

    Thanks ahead,

    Moon

    Image:

    Comment

     

    • Paula Yang

      Hi Moon,

       

      1) What if we process a full, master data extract run and takes longer time than the current delta-only run? (Will it raise timeout issue on OIC side? What's the runtime limit on OIC for every integration run?)

      Paula> You are right, Extract run will take time when you have big volume data. I built a similar integration as you, I added a "wait" action into the flow, I tested how long an extract run took, and define the wait time, for example, 5 mins. In your case, you can test the full extract run time and define the wait time.

      Anyway, I'm not sure how you could make one integration working for both Full Extract mode and Changes Only mode ... In your first "Assign" node, guess you defined a "Changes Only" parameter, you need to change its value for Full mode or Changes Only mode.

       

      FYI - this is my integration https://cloudcustomerconnect.oracle.com/posts/28cad4876f

      The difference with yours is after get the extract output XML, I used a mapping to transfer the XML to a text which required by third-party Payroll. My xsd schema is for the XML generated by Changes Only mode. The xsd schema for XML generated by Full extract mode will be different.

      Good luck!

       

      Regards,

      Paula

       

    • Ravi Sankaran

      Hi,

       

      Assuming you have a single OIC flow for handling the initial load and change data (which I think you can ), your concern #1 is being addressed by OIC scheduler. OIC scheduler will ensure that the new instance is not started until the existing run is completed

      I also have comments about your existing flow. I see that you use the flow to schedule the execution of HCM extract - and continuously poll the HCM server until the extract is complete before downloading the extract. 

      We are working with HCM Cloud team on providing a callback once the job is completed 

      But until then, I would strongly suggest that the scheduling of data extract is done within HCM cloud - and have the OIC scheduled orchestration flow start with retrieval of data extract from HCM Cloud (UCM). With this, we will significantly reduce the unnecessary polling as well as holding the thread as hostage. 

       

      regards,

       

      Ravi