OIC: Somewhat "Hidden" Feature: Reusable Subprocess

This blog article describes how to configure input and output parameters for Reusable Sub-processes (BPMN Call Activity) in OIC Structured Process

It's more than once that I have see that OIC Process developers are not using the Reusable Subprocess in Structured Process, simply because they are not aware that you can pass on arguments to the Start event and from the End event, like you can for processes that start and end with Message Events.

I will not discuss the benefits of and when to use a Reusable Subprocess, I will save that for a blog posting soon to come.

The thing is, the parameters are somewhat hidden. You create a Reusable Sub-process by creating a process with a None Start and None End event, as in the picture below. To add parameters to both events you can do it like this:

1. Click on the Start Event.
2. From the hamburger menu choose Open Properties. This will show you the propertie of the Start Event, where (probably to your surprise) you cannot find the input parameters.
3. With the Properties tab of the Start Event still shown, click anywhere on the process canvas as long as it is not another component (event, activity, flow, gateway). Ta-da!!

 

You can now use the Reusable sub-process in any other process using the Call Activity:

As you can see you can pass on argument to it on the Input tab of the mapper, as well as pass on arguments from it on the Output tab.

That easy ;-)

OIC Process Correlation: Take Good Care of Your Properties

The other day we had an issue with correlating process instances which turned out to be caused by some "mistake" we made. Took quite some time to figure it out so I thought I share it with you, hoping it can safe you some time.

First I will explain what correlation is about (you may want to check out a much more elaborate blog article on how to use it in OIC-Process by Martien van den Akker, or another one from Anthony Reynolds explaining the concept in the context of BPEL). Correlation is in OIC-Process not really different from what it is in Oracle BPM Suite so if you already know that or when you have done it before in OIC you can skip the next paragraph.

When one process instance is calling another one and of the latter there may be multiple instances, you need a way to make sure the second process calls back the right instance of the first process. That is done by making that the instance to call can uniquely be identified, or "correlated" as it is called. In many cases correlation is out-of-the-box, like for synchronous calls or asynchrounous calls using WS-Addressing. When there is no out-of-the-box correlation, you need to configure it explicitly using what is called "message-based correlation". That means that instances are correlated using a key (value or combination of values) which is (part of) the message that is send from one instance to the other. In OIC that key is called (not surprisingly) the "correlation key" (same as "correlation set" in BPEL). The correlation key has one or more "properties" for which the (combination of) values must be unique in such a way that at any time there cannot be two or more instance flows of the calling process using the same correlation key value(s).

The issue we ran into is that we had to call the same child Structured Process from a parent Structured Process in parallel and that we made a "mistake" with defining the correlation key. The mistake being that we defined 2 correlations keys for 2 parallel flows, calling the same Structured Process but using different properties. When using 2 correlation keys sharing the same property it worked.

The actual process model is similar to the following:

Both parallel flows call the same process. In the example the child process takes a string input argument and performs a callback using that same value. The child is started in the Send activity. To make that the proper flow is being called back in the Receive activity, correlation must happen in the callback. The way to do so is to set up 2 different correlation keys, 1 for each flow and then initiate a unique correlation in the Send activity and in the Receive activity correlate on that unique value. In the example the way to do so is like the following:

 

This shows how two correlation keys, "ck1" and "ck2" are defined, both having the same "property1". The next picture shows how correlation is initiated in the Send activity: 

 

 The correlation happens in the Receive activity as show in the next picture:

 

What could possibly go wrong, right? Well, you could define your correlation keys like this:

 

The difference being that the correlation keys have a different property. Net effect being that after either one or both the sub-processes finished without any issue, the parent still waits for the callback that never will come:

 

When setting up correlion with the same process, there should be no reason to have different properties in the correlation keys, so other than being an inconvenience when you accidentally do it wrong, it should not be a practical problem. I do hope though that with some next release this issues goes away either by that having different properties is supported (might be a reason why that is not a feasible solution) or that you are blocked from configuring it wrong.

By the way, another easy to make mistake is to use "Initialize" instead of "Correlate" in the activity that should correlate. Happens to the best.

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 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.