Asynchronous Webservices in Fusion ERP and SCM

Introduction

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.

Mechanism to import data into Fusion SCM

There are many ways to create objects in SCM. There are mainly 3 broad approaches –

1. FBDI:

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.

2. SOAP Webservices:

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.

Note: Currently, there is no additional investment on developing new SOAP Webservices.

3. REST APIs:

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.

Where to use What?

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 –

Synchronous and Asynchronous Webservices

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 –

• Create action is to create an object for example create a sales order
• Update action is to update an object for example update a sales order maybe with new quantity for an item
• Query action is to update an object for example retrieve a single or all sales order in Fusion
• Delete action is to delete an object for example delete a sales order in Fusion

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 –

1. Timeouts: Since the webservice/API takes longer time to respond the caller may time. Typically, the caller entities have timeout built into it. It varies based on who is the caller. The timeouts typically seen are between 60s to 300s. However, the timeouts can be smaller or larger than these value since there is not standard.
2. Thread Build Up: Now, let’s say the caller had larger timeout or hypothetically speaking an infinite timeout to call any webservice/API. If this was the case, since the response from webservice/API would take longer time to respond, one can see the caller threads build up since the caller threads are waiting for longer period time to get a response back. We all know that every application has finite number of threads. So, if this scenario was to occur, we can imagine that the caller would run out of threads leading to slower throughput in caller or worst having severe slowness on the caller side.

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

How to find the Asynchronous Web Service?

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)

Conclusion

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.