Oracle Fusion ERP and SCM is part of Oracle Cloud Application that is a complete cloud suite of SaaS applications brings consistent processes and a single source of truth across the most important business functions—from enterprise resource planning, supply chain management, and human capital management to advertising and customer experience. The applications help you improve your customer engagements, increase your business’s agility, and react to change faster than ever before.
In an Oracle Fusion ERP and SCM (Fusion) implementation there is a need to get data in and out of Fusion. While Fusion provides UI interface to interact with it, most often than not there are scenarios where data must come from heterogenous data sources such other applications, files etc.
This blog explores different ways to create data in Fusion, with a focus on mechanis to create large data objects in Fusion. For example, create a large order of 500 lines in Fusion.
There are many ways to create objects in SCM. There are mainly 3 broad approaches –
FBDI is one of the many ways in Oracle Fusion Cloud to do conversions. FBDI stands for File Based Data Import. In cloud environment, FBDI is the best way to get mass conversions done in shortest time. All entities are not provided with FBDI currently in Oracle Cloud.
The use of FBDI is not only in conversions but also loading bulk or batch data into Fusion. Imagine if you had to load a General Ledger file which is 100MB then FBDI is the best way to go.
Initially Fusion developed a whole bunch of Simple Object Access Protocol (SOAP) web services to integrate different applications within the enterprise or expose business functions to Oracle Cloud partners and customers.
Business Object Services
Work with business objects, such as an opportunity or a marketing campaign. You can perform the standard CRUD operations to create or modify the exposed business objects. These services are implemented using the Application Development Framework (ADF).
Manage business processes that are not centered around any particular business object. These services are typically implemented using Service-Oriented Architecture (SOA) composites.
Note: Currently, there is no additional investment on developing new SOAP Webservices.
Over time, REST APIs has become the standard for exposing APIs on Fusion. REST APIs has functional parity with most of its SOAP counterparts however there is still some gaps. The long-term direction of Oracle is to functionalities built into REST APIs.
With the above mechanism for data creation, the next question is when to use what mechanism for data creation in and fetch fromFusion.
The following table gives a cheat sheet on when to use what –
For eg: Import bulk invoices sent
SOAP Webservice / REST API
When we think of webservice and APIs, we think of mostly synchronous interaction i.e you send in a request and get a response back. By synchronous interaction I mean, that the caller application (caller) waits for the response the webservice or API. Broadly the common actions performed with webservice/API is to create, update, query or delete in Fusion. These are quite self-explanatory –
All above actions renders a response. For example: a Create action on sales order may return an Order Number back as response, a Query action on sales order returns sales order details as response. These are all synchronous interactions where a caller is waiting for a response from Fusion.
Such synchronous interactions are great for use cases which need realtime data, for example: populating a user interface. Synchronous interactions typically are used to handle smaller data objects, for example: creating a sales order with 10 order lines. But how small is small? This is quite subjective, and this must determined based on testing results on individual webservice/API.
So, what happens when a synchronous webservice/API is used for larger data objects? For example, let’s say one must create a sales order with 100-line items. The synchronous service in such a scenario can still be used but however the response time from the webservice/API will generally be higher than creating 10-line order, just because there is lot of processing to do on Fusion. Some consequence of using a synchronous webservice/API that takes longer time to response are following –
So, what can be used to create larger objects in Fusion? This is where the asynchronous webservices in Fusion come in handy. Asynchronous invocation does not block the caller. There is no response returned except at confirmation that Fusion received the request. This way the caller is unblocked and not waiting on a response. Caller will receive an asynchronous callback, to know what happened to the request when Fusion finishes processing the message.
Since the caller is unblocked after the webservice call, there will be no timeouts or thread blocks on the caller.
Note: Asynchronous invocation on Fusion is currently available as SOAP webservices. Asynchronous invocation is not currently supported with REST APIs
Every WSDL exposed in Fusion has a synchronous and asynchronous implementation of webservice. For example, let’s take an example of OrderImportService.
The OrderImportService has a wsdl of format - https://servername/fscmService/OrderImportService?WSDL
As seen above, the OrderImport Service WSDL has operations such as stageOrder, createOrder and submitDraftOrder. Each of these operations have a synchronous and asynchronous interface. The asynchronous interface has an additional callback operation. The callback operation can be used for Fusion to callback the caller application after the processing has finished.
So, as an example if I were to use createOrder operation, operations to be used for synchronous and asynchronous operations will be the following –
Synchronous: createOrders (For both Request and Response)
Asychronous: createsOrdersAsycn (For Request)
createOrderAsyncResponse (For Receiving Response)
In this blog we saw, the different mechanisms to create/query data in/from Fusion. We learnt FBDI is mainly used for Batch and Conversion loads while SOAP webservices/REST APIs are more used for realtime. It was pointed out that SOAP webservices and REST APIs are synchronous is nature and should be used to more smaller messages/business objects. For larger messages/business object which still realtime/near realtime response, asynchronous SOAP webservices must be used rather than synchronous SOAP webservices or REST APIs.