Update Feb 2018 : Please note that this blog was written in 2014 with the On-Prem Fusion R8 in mind. The current SCM SaaS version is R13.
Although most of this blog is still applicable, please refer to the SCM Order Management documentation or whitepapers for the latest information.
One of the core features of the Oracle Fusion Distributed Order Orchestration (DOO) is its ability to integrate with external applications for routine orchestration tasks such as invoicing, shipping, etc.
In this blog I’ll explain how to achieve this, using an example of invoicing. Such an integration would be required if, for example, the invoice generation is performed by an external application.
It is assumed that the basic DOO functional setup has already been done. For the purposes of this post, I used the default ShipOrderGenericProcess for orchestration. If you are new to DOO and its setup, then the Oracle Cloud documentation of Product Value Chain and Order Orchestration are a great starting point. They do a very good job of simplifying what needs to be done and why; from a functional angle.
In order to understand how the Fusion DOO talks to external applications, we need to know about the Enterprise Integration Layer (EIL) and Task Layers:
To configure the external invoice system, the following are the necessary (but not complete) functional steps, the complete set of function steps can be found here, Product Value Chain and Order Orchestration:
The whitepaper here describes DOO Cross-referencing in further detail.
At a high level, DOO has a cross-referencing engine that maintains cross-references for functional entities such as currencies, Units of Measure etc across various source systems. It’s called the Order Orchestration and Planning Repository (OOPR).
Also, Items and Customer cross-reference data are ‘referenced’ from the Customer Data Management and Product Hub modules, and are not maintained by OOPR.
Now we are ready for the technical part. Some of the details in this section are inspired from another DOO whitepaper here.
DOO extensively uses the oracle AIA Foundation Pack objects for integrating with external systems. The WSDL used in the step 1 above is an AIA Enterprise Business Service, Also, the XSD used by the WSDL operation is an Oracle AIA EBM, specifically the CreateInvoiceEBM.
So far we have configured DOO to call out the external Invoice connector. But the invocation is an asynchronous one, and now we’ll discuss how the callback happens.
The composite that invokes the custom connector is DOOTaskInvoiceExternalRequestComposite, whose callback port is configured with oracle/wss11_username_token_with_message_protection_policy. This implies that the connector callback must be configured with the csf keys and certificates as needed.
A Few caveats here :
Once the callback path is correctly configured; upon receiving a message the DOOTaskInvoiceExternalRequestComposite process updates the invoice state of the order to AWAIT_BILLING, as shown in the screen shot below:
Further updates to the Invoice status are done when the Invoice Application invokes the service DOOTaskInvoiceExternalResponseComposite (this service is also OWSM secured using the same service policy as above). For example, the following payload invocation changes the status from AWAIT_BILLING to COMPLETE.
Payload :
<v2:ProcessInvoiceNotificationEBM xmlns:v2="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V2" xmlns:v21="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2" xmlns:ebo="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V2" xmlns:add="http://schemas.xmlsoap.org/ws/2003/03/addressing" xmlns:urn="urn:oasis:names:tc:xacml:2.0:context:schema:cd:04" versionID="?" languageCode="en-US"> <corecom:EBMHeader xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"> HEADER DETAILS </corecom:EBMHeader> <v2:DataArea> <v21:Process/> <v2:ProcessInvoiceNotification> <corecom:Identification xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"> <corecom:ID schemeID="InvoiceNumber" schemeAgencyID="OPS2">GENERATED INVOICE NUMBER</corecom:ID> </corecom:Identification> <v2:InvoiceDateTime>INVOICE GENERATION DATE TIME</v2:InvoiceDateTime> <ebo:InvoiceLine> INVOICE LINE DETAILS </ebo:InvoiceLine> </v2:ProcessInvoiceNotification> </v2:DataArea> </v2:ProcessInvoiceNotificationEBM>
After successful invocation, the Orchestration state changes to the following:
In this blog I have demonstrated how flexible DOO is and how it can be tailor-made to fit to your organization’s order orchestration requirements. We learnt about the EIL and the Task Layer, and how they help extend DOO in a seamless manner.
http://docs.oracle.com/cloud/farel8/scmcs_gs/FAPIQ/title.htm#zzbegin
http://docs.oracle.com/cloud/farel8/scmcs_gs/OAORO/index.html
https://support.oracle.com/epmos/faces/DocumentDisplay?id=1536633.1
http://docs.oracle.com/cd/E28280_01/doc.1111/e17363/toc.htm
Next Post