In this article I discuss the Micro Process feature in the
Oracle Integration Cloud (OIC). With some price 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.
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.