In today's world of complex business processes and systems, it is a common scenario for an application to initiate a complex processing routine based on user action and allow user to move on to another operation without waiting for output from the processing routine.
This approach provides better user experience where real-time output of a complex process is not-relevant for user journey / process flow; especially when the processing time is considerably high.
In a recent implementation, we had similar scenario where an external webservice was supposed to be invoked from Oracle Sales Cloud based on a user action (On click of Save button - Groovy script), however real-time output of the webservice was not necessary for further user actions. The external webservice needed 60+ seconds to respond.
With the inherent nature of Oracle Sales Cloud, any transaction / operation initiated by user action on UI completes in the UI transaction context itself and control is give back to the user only after the transaction is complete.
This limitation of Oracle Sales cloud meant user has to wait on UI for 60+ seconds to get the control back (webservice call needed 60+ seconds to respond). As you would agree this was not a good user experience and understandably business was not happy with it.
So what would be the solution for this issue?
Discussions
with Oracle support covered the following options:
- Explore possibility of asynchronous webservice. However Oracle Sales Cloud didn't support any way to invoke asynchronous webservice.
- Change the webservice implementation to improve the response time. However this was not feasible as this was existing webservice on Customer side being used by other applications.
- Change the business process. However the webservice still needed to be invoked on user action and the wait time issue couldn't be avoided.
Finally we came up with a work around that was agreed by Oracle Support as well.
The approach:
The code to execute external webservice call was part of a Groovy script that was supposed to be executed after "Before Insert" trigger script (covering real-time operation) on click of Save button on UI.
We needed to way to execute Groovy script (for the webservice call) outside UI context, though the trigger point is from UI.
Object Workflow was leveraged to achieve this.
Object Workflow is an OOB feature provided by Oracle Sales Cloud , that can execute an action when Workflow condition is satisfied.
The Workflow actions can include preliminary operations such as
- Field Updates
- Email Notification
- Task Creation
- Outbound message (Allows sending object field values to an End point)
- Business Process Flow
Workflow in itself does Not support complex operation such as executing a Groovy script, however the Update Field action helped achieve this.
Application Composer changes:
- Groovy script to execute the webservice call was on a custom object "Quote". New fields "Invoke_WF"and "Invoke_BS" added to Quote object.
- Groovy script code added on Before Insert trigger of Quote Object to set "Invoke_WF" = 'Invoke' (after the script that was supposed to be executed real-time).
- Object Workflow created on Quote object with condition as Invoke_WF = 'Invoke' (When a record is created) and with Field Updates action to set "Invoke_BS" to value 'InvokeBS'
- Field trigger added on Quote object "Invoke_BS" field to execute Groovy script to invoke external webservice when field value is 'InvokeBS'.
Sequence of events with the workaround:
- Click of Save button on Quote object executes "Before Insert" trigger to perform the real-time operations and then set the Invoke_WF field. This ends the UI transaction and returns control to user instantaneously.
- In the background, Object Workflow is executed satisfying the condition for Invoke_WF field value.
- Workflow action updates field Invoke_BS.
- Field trigger on Invoke_BS field on Quote object executes the Groovy script that calls external webservice and processes the response. Since workflow executes in background mode, so does this Groovy script.
Below diagram briefly explains the sequence of steps.
Thus this approach helped meeting the business requirement overcoming product limitation. What more, this also opened up an opportunity to extend the workaround to other scenarios where complex Groovy script needs to be executed in background on Oracle Sales Cloud.
e.g. This approach was also leveraged to meet another complex business requirement that involved updates for 100+ child Quote records through script based on a user action. Oracle Sales cloud limitation of 60 seconds time out for scripts, restricted the ability to process more than 20 Quote records in a single transaction. However background processing approach helped breaking the transaction in smaller chunks that could be processed in parallel avoiding the time out.
Hope this approach would be helpful for Oracle Sales Cloud implementations involving similar scenarios. Happy to help in case any queries.