OIC: The Micro Process Feature Making Life Easier

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:

• Microprocess Consequences
  

Microprocess Consequences

In a previous blog article I introduced the Microprocess Architecture. The article below discusses the consequences of maintaining, managing and running applications that are build according to this architecture.

We are applying the Microprocess Architecture to some 4 Dynamic Process applications that are being built with the Oracle Integration Cloud (OIC) for some one and a half year already, but none of them went production so far. We can clearly see the benefits of applying the Microprocess Architecture, but also realize the consequences. I have addressed most of these with some pointers for dealing with them in a follow-up article on the subject.

As the go-live date slowly but inevitably is nearing, people obviously start wondering what the consequences regarding maintaining, managing and running such applications mean in the context of OIC. The below discusses this, referring to a “business process” as the main application that is made up by a collection of microprocesses.

The following picture shows the core concepts of the Microprocess Architecture in the context of a case application:

 

The case application with its activities is separated from the components that do the "actual work": the microprocesses. The case application does only the choreography and therefore is restricted to rule logic. The microprocesses are relatively small and simple stand-alone process application doing service calls and handling human tasks.

As summary of the negative side of microprocesses compared to a monolith:

•          Impact analysis will be more complex
•          Deployment is more complex
•          Analysis of an issue in the flow of a business process is more complex     

As summary of the positive side of microprocesses compared to a monolith:

•          Impact of change tends to be smaller 
•          They are easier to maintain in process composer
•          Changes can be brought quicker to production
•          Multiple developers can work on the same business process application
•          The flow of a single microprocess instance is easier to analyze
•          The memory footprint is smaller
•          Little to no need for process instance migration
•          Fewer revisions (versions) deployed
•          Risk of issues with OIC upgrades is smaller
•          Need to scale OIC instances will be less

The consequences are determined by three different aspects that are discussed first:

1. Number of applications
2. Complexity and size
3. Passthrough time

After that these aspects are discussed regarding:

a) Design-time consequences 

b) Run-time consequences (for individual applications) 

c) Consequences on the infrastructure

1. Number of Process Applications

One obvious consequence of the Microprocess Architecture is that you will have many more components to deploy than for monolith process applications. Clearest example is that the top-level process is only doing orchestration (or as we should say in case of a Dynamic Case application: choreography), delegating all the ‘real work’ to multiple microprocesses that each concern a process application of its own.

One of the applications we create already consists of some 30 microprocesses, and still counting. At the end we plan to have some 5 applications and a couple of reusable “utility” applications (most of them consisting of just 1 microprocess). The current estimate is that we will end up with some 150 to 200 individual process applications, the majority of them being microprocesses.

 

2. Complexity and Size of Process Applications

Another obvious consequence is that each individual component is relatively simple and small. A microprocess can have many process activities in a complex flow with many gateways and so on, but should support one single business capability only.

For example, instead of one big sales process that starts with a customer request and only ends after the product has been delivered, you will end up with many smaller processes where one covers the intake of the customer request, another offers the quote, a third handles the signature and so on. The signature microprocess may support different scenarios, from getting a signature of one customer up to a whole board of directors, with approval patterns, reminders and escalation, and therefore can be quite complex. But in the end it has one single responsibility which is to get a contract signed. So, a microprocess is not necessarily always simple but by definition limited in scope.

 

3. Throughput Time of Process Instances

The fact that a microprocess is relatively small, implies that the passthrough time of its instances will be relatively short. The only instance that runs from start to end is the top-level process orchestrating it all. However, in some cases even that can be chopped up, like into a few smaller successive steps, where each step covers a major phase that triggers the next one and then stops.

For example, the top-level process of a sales process could be chopped up in one part covering the intake and quotation, which then triggers one or even more instances that cover the delivery of the products.

Longer running microprocesses that are typically those involving human activities, or activities handling asynchronous interaction with other applications or external parties. But there will not be many of this kind of activities in one single microprocess. For the case applications we are building, most of the instances live only a few minutes or less, and some up to a couple days, and only a few may run for a longer period (typically while waiting for a response from an external party).

 

In the following a monolith process application is compared with one that is completely build using the Microprocess Architecture. In practice you probably don’t have either one of the extremes.

a) Consequences Design-Time (Process Composer)

OIC currently has no out-of-the-box support for identifying relationships between process applications (let alone to visualize them), other than offering an API that exposes process definitions. For example, /ic/api/process/v1/dp-definitions/{id}/metadata shows all stages and activities in those stages (“plan items” are they called, but not which microprocess an activity is calling).

In case of a monolith application, the main and all subprocesses involved are in one and the same process application. It may not always be clear which (sub)process is calling which other, but you don’t have to look far. There also is only one single process application to deploy a business process to production.

On the negative side

In case of microprocesses it quickly becomes difficult to understand how a process application is constructed, as: which microprocesses make up the total application and how do they call each other. This complicates impact analysis.

Because a business process application is split into multiple microprocesses, you also deploy multiple process applications to production. This complicates overall deployment of one single business process.

On the positive side

Each individual microprocess application will be less complex and therefore easier to maintain than a monolith would be. Among others, a microprocess is expected to open quicker in Process Composer and activation will be faster.

This comes on top of the advantages mentioned before:

• In many cases a change is localized to one microprocess, so impact of a change tends to be less. 
• As a change is applied to a component with limited functionality you typically can bring changes much quicker to production, making you time-to-market quicker. 
• You can work with more than one developer at the same time on one business process application (only one person can modify a process application at the same time).

 

b) Consequences Runtime

OIC currently has no out-of-the-box support where one can easily navigate from one process instance to the other, let alone a way to show the overall flow of a business process. When a process instance is paused its state is persisted in a database (this is called dehydration) and the runtime memory consumed is released. As soon as it resumes the state is retrieved from the database (this is called hydration) and will start consuming memory again.

In case of a monolith application with decomposition done using reusable subprocesses, the execution of a business process is presented as one flow from front to end. You can review a sub-flow execution by expanding the call node of the invoke to the subprocess.

On the negative side

In case of microprocesses an end-to-end flow of what functionally concerns one business process, may involve many individual running instances interacting with each other. Because there is no simple navigation from one instance to another, issues with performance or other runtime issues can become very difficult to analyze, taking considerably more time. It should also be noted that starting an instance of the next process is expected to cost more bootstrapping time than activating a subprocess in the same instance.

On the positive side

The simpler a process application is, the easier it will be to analyze its flow. It therefore will be easier to pinpoint an issue in an instance of a microprocess. The process payload of a monolith instance will be bigger, and it will be hydrated more often and longer. In contrast, the memory footprint of all the hydrated instances of microprocesses for one business process flow is expected to be smaller.

Due to the shorter passthrough time, on top of the advantages mentioned before comes the following:

• Except for the top-level process, there will be little to no need for microprocess instance migration (i.e. migration of a runtime instance from one version of the application to the next one).

 

c) Consequences on Infra

The more process revisions (versions) of applications to deploy, the longer it takes the OIC instance to start up as each individual revision will have to be (re)deployed. While CPU and memory consumption of an OIC instance continues to increase, you may reach a point where the instance may have to be scaled up by adding more nodes to it.

On the negative side

Especially in the beginning there will be many more application revisions to deploy in case of a Microprocess Architecture. In case of an upgrade of OIC that involves a change of the process application code in the background, there will be many more application revisions to upgrade.

On the positive side

In case of a monolith all changes are applied to the same application, instances run much longer, and may not always be migratable. You therefore should expect you must keep many more revisions deployed. As pointed out in the article introducing the Microprocess Architecture, the small passthrough time of a microprocess implies that obsolete revisions can be decommissioned pretty quick. Except for the top-level one, it is expected you typically need to keep 1 to 2 activated revisions per microprocess (*). It is difficult to predict if rebooting an OIC instance after a while would take more or less time than in case of a monolith.

As the individual microprocess applications are relatively simple, it is expected that the risk of issues with a code upgrade as the result of an OIC upgrade is smaller. And when there is an issue it probably is easier to fix.

Because the smaller footprint of microprocesses, the need to scale up the infra is expected to be limited. Performance issues with one microprocess impacting the other ones can be addressed by distributing microprocesses over different OIC instances.

(*) Currently OIC has a limitation that forces you to keep a revision deployed if it was part of the execution of any running business process flow. If you deactivate it while that is the case, the complete flow will be aborted.