Orchestration Layer

Your orchestration layer is the software [such as Oracle's SOA BPEL or BPM Studio] you currently already use, to wire together Fusion HCM Loader/Extract programs to other apps. 

What is HCM Connect?
  • HCM Connect is an orchestration engine being built by Fusion HCM. 
  • If you are already using BPEL or some other orchestration engine, HCM Connect is not as relevant.
  • HCM Connect V1 transfers files from customers server to Fusion and invokes the customers loader program. It's hosted on PaaS. It is now closed to new entrants. 
  • HCM Connect V2 will also offer transformation capabilities. It will be hosted on SaaS (as well as PaaS), but is roadmap, so release not known.
What about ICS (Integration Cloud Service)?
What about Encryption?
HCM Loader & Extract Tools, as well as BI Publisher, have the capability to encrypt & decrypt files. This means that you can encrypt files on generation from your side and during upload into Fusion, pass a parameter to the HCM Loader program that instructs the Loader prograrm to decrypt on import. Similarly when you submit an extract from Fusion HCM, you can specify that the output should be encrypted on generation. See the "Encryption" tab above for further details.


HCM Integration patterns: Batch vs Real Time
  1. If Core HR deployment is On-Premise
    1. Co-existence Pattern
  2. If Core HCM deployment is in the Cloud
    1. New Hire Flow - Taleo/3rd Party Recruiting to Fusion
    2. HR Master Data Flow 

       Fusion Core HCM to Downstream Systems (including ERP), with updates back (LDAP - email/username, LMS - certifications, Other Providers - Stock Plan Details, Loan info etc

       ADP/Benefit Providers

    1. Downstream Systems Triggered Read & updates back into Fusion (Mobile)

       Employee Directory - Reads employee info from Fusion > Update own info into Fusion. 

       Time/Absence Tracking - Read remaining vacation from Fusion > Record absence > Update into Fusion. 


SOA/BPEL
Companies already using SOA/BPEL can just add Fusion HCM into the mix.  Diagrams below show BPEL leveraging HCM batch programs (above) & REST services / Atom feeds (below that).

Pattern #1.1 & 2.1
Co-existence/New Hire Flow - Implementation Details
  1. BPEL's "File Adapter" to read the data in.
  2. BPEL's Transform Activity with Domain Value Maps to transform the data.
  3. You need to get the UCM Service exposed externally (In Rel10 it will be exposed, but on Rel9, you'll need to do the following):
    1. File an SR requesting Fusion HCM to perform a Key Exchange - Aside from allowing you to send "encrypted" files into Fusionthis step will also result in the UCM Service being exposed externally.
      • Ensure you file the SR under Oracle Cloud Global Human Resources Cloud Service. 
      • Choose Hosting Services – Application -> Encryption Key Exchange
  4. Use BPEL to Invoke the UCM Soap Service to write the File into UCM. 
    • If your Fusion HCM home page is: https://<Hostname>/homePage/faces/AtkHomePageWelcome 
    • The UCM Service wsdl will be: https:// <Hostname>/idcws/GenericSoapPort?wsdl
    • More information on the UCM Web Services
  5. Invoke the HCM Loader Programs passing them the encryption parameter along with other required parameters.
    • FBL wsdl is the following form: https:// <Hostname>/LoaderIntegrationService?WSDL
    • HDL wsdl is the following form: https:// <Hostname>/hcmCommonDataLoader/HCMDataLoader?wsdl
  6. Find out which user privileges you must assign to the users who call these web services in OER: https://fusionappsoer.oracle.com
  7. Sample Payloads for the above services are available here. [You can enter comments into the sample payloads doc if you find any issues].
  8. Later when REST Services are available (Release 9 Patch Bundle 7 under "controlled availability" most likely), for your lighter weight inbound integrations, such as Fusion/Taleo, you will have the option to switch #3/4/5 to a REST service call to create/update the employee in Fusion. NOTE: Co-existence scenarios should continue to use batch loaders because:
    • Performance Reasons - services won't perform as well under heavy loads
    • The breadth of data needed for co-existence isn't covered (or intended to be covered) by the REST Services.
***  RIDC Blog

REST / Atom vs FBL/HDL for Co-existence

Since this question comes up a lot, I thought I should address it here..

If the customer has Core HR in EBS or Peoplesoft - they should use FBL/HDL for co-existence. Reasons against using REST Services for bringing employee/work relationship data across are the following:

  • REST services support 2 tier creation of employee (not pending/contingent workers/contacts etc). Also they only cover heavily used attributes, so it’s not clear if all the attributes they need are included in the employee/assignment service.
  • FBL/HDL have been used successfully by several customers in co-existence scenarios, so they are less likely to run into issues.
  • Performance considerations as the REST Services are intended for light usage (10-15 emps/day or so), as there is currently no bulk load functionality.

Pattern # 2.2



Downstream Apps Flow - Implementation Details

  1. Create a SOA composite for a "source object" such as "Employee" and schedule it to execute at the max periodicity expected by the downstream systems (subject to performance constraints).
  2. The composite will invoke BI Reports or HCM Extract using SOAP Services and include a superset of all changed employee fields needed by downstream systems. Details on how to invoke and retrieve extract results from HCM Extract.
  3. Poll for resulting file in UCM. Pick up file and read details into a schema.
  4. Branch for each destination system based on data attributes & use BPEL's transform activity with Domain Value Maps to transform the data.
  5. Use the File Adapter to append to each file destination using the "append to existing file" option [wherever each of your downstream systems are expecting it].
  6. Downstream systems process files at the periodicity they need (which vary by system).
    • Process independent object files before dependent one's.
    • Move processed files into an archive database for weekly reconciliation against Fusion HCM.
  7. Later when Atom is available (Release 9 Patch Bundle 7 under "controlled availability" most likely), switch #2/3** from using BI Reports or HCM Extract, to calling the Atom URL - main advantage of switching to Atom is going to be significantly quicker performance.
    • Flexibility is available around polling frequency & you can specify that only new Atom entry's since last time polled are returned. Examples:
**NOTE -  Question was raised on point 6 above, that shouldn't Atom replace steps 1, 2 & 3 above, instead of just 2 & 3.  The reason it does not replace #1 is that "lstening to the events” still involves some form of “polling”. Once an ATOM adapter is made available by the SOA team, the “polling” aspect will be built into it. 

The next question that arises is that what’s the advantage of Atom over just executing a BIP report which pulls the differences? The major advantage is performance & it’s simpler. You don’t have to worry about finding the “incremental differences” since the last time the BIP report ran, and you’re polling the Atom Server which stores only “changed data”, significantly faster than reading from a 120K person table
Comments