In this article I discuss the Micro Process feature in the Oracle Integration Cloud (OIC). With some pride I can take credit for being the name giver of this feature, which makes applying the Microprocess Architecture in OIC a bit simpler. But even when you are not applying that architecture, it still is a feature worth being aware of.
Update: due to some limitation with this feature (it only works for synchronous processes) it has been deprecated and will not return in Oracle Process Automation (OIC 3). You are therefore discouraged to use this feature, and if you have been using it, refactor to use the combination of Send and Receive activities instead.
A few releases ago the Micro Process feature has been introduced in the Oracle Integration Cloud (OIC). Simply put, it provides a convenience for calling a Structured Process from a different process application.
"What a great feature that sounds, why did you not write about it before?", I can hear you thinking. Well, there were a few issues with it which mostly have been fixed since OIC release (20.2.3.0.0 (200705.0200.36413)). That's why.
"What is this "Microprocess Architecture?", I hear some others thinking. In short, the Microprocess Architecture is about constructing a process application by having (typically but not necessarily) 1 main process that orchestrates / choreographs activities of which each of them is implemented as separate, decoupled process applications. It is not the same but inspired by many of the solid principles behind the Microservices Architecture, hence the name.
When applied to the Oracle Integration Cloud, every activity in the main process is implemented by an (asynchronous) Structured Process called a "Delegator" that does nothing but start some other Structured Process using a Send activity and then wait for the outcome in a Receive activity. There are a few deviations, but basically that's it and what the "Use Micro Process" feature supports.
Before this, you as a developer first had to configure the external process as External SOAP Integration and provide the URL to the WSDL (or upload it), and secondly you had to create the Delegator yourself. Now you just point and click and off you go. When using it in a Dynamic Process, a Delegator is automatically created and hidden in the background.
Microprocesses are configured from the Processes tab.
You select the Structured Process to use from a picklist. Be aware that only Structured Processes are shown from activated Process Applications. For bigger Microprocess applications there can be many of them, so it is good that you can filter them with a Search box. Also mind that it shows Structured Processes from all the default revisions of the Process Applications containing them.
Once selected, it shows up next to existing Dynamic Processes and Structured Process in the same process application, and other already configured Microprocesses.
You can use a Microprocess in both a Dynamic as well as a Structured Process. In a Dynamic Process you add a Micro Process activity and then select the one you want to use from a drop-down.
As said, in the background a Delegator with a Send and Receive activity has been generated for you, but you won’t see that here. You can map Input and Output data to its auto-generated start and endResponse arguments.
Although hidden from a design-time perspective, you can see the automatically generated Delegator in action in Workspace.
Currently using a Microprocess in a Structured Process is somewhat different. There is a Micro Process activity available in the Component Palette, but that does not work the same as when using it in a Dynamic Process.
When you drag that in the process model, then:
- In case of an asynchronous Structured Process (typically more than 90% will be asynchronous) it works as a fire & forget call. This is equivalent to only using a Send activity to call the Microprocess.
- In case of a synchronous Structured Process it works like a Service activity.
However, you can still call a configured Microprocess as an asynchronous process using the good old Send and Receive pair. To use it you must implement it as a Process Call.
Personally I would like to see this changed in such a way that you can use the Micro Process activity for all 3 cases (asynchronous request / response, fire & forget, synchronous), where OIC introspects the WSDL to determine if it is a synchronous or not, and if not then offers the option to call it as request / reply or fire & forget.
Another improvement I hope to see, is that OIC automatically detects when the interface of the Micro Process has changed and offers to refresh the imported WSDL. Now you have to keep track of that yourself, and manually upload a new version of the XSD of the interface.
Nevertheless, the Micro Process feature is already very useful as it is, being a productivity booster when creating a Process Application based on the Microprocess Architecture.
Further readings:
No comments:
Post a Comment