How Granular Should My Microprocesses Be?
By: Jan Kettenis

As with all modularization principles, finding the right granularity is not always trivial and the more important. Some of us have seen complete projects fail because of getting this wrong. The Microprocess Architecture is no exception to this rule and in the following I discuss this topic, hoping to guide you in getting it right.

As explained in the article introducing the Microprocess Architecture the rationale for applying it consists of a combination of reducing impact when implementing new features and bug fixes, ease applying them to an already deployed business process, supporting parallel development and few others. Said differently and in one word: agility.

To correct the mistake made in the introducing article of not defining what a microprocess stands for:

A microprocess is a subprocess of a larger business process, where the subprocess spans the execution of one or more activities to reach a business significant state change of the business process, and which can be developed and deployed as a stand-alone component.

This definition implies that the scope of a microprocess has business visibility. However, as such that does not yet clarify the right granularity. Too course-grained and there is a risk of not delivering on the core value of agility, too fine-grained and you risk issues with performance and scalability.

So, what is the right granularity? First let me try to illustrate by example. I then capture some of the main characteristics that should give you guidance on how to apply it for your use case.

Order handling example:

An order handling process of a bank, that starts with a customer submitting an order form and ends with invoking one or more back-end systems to handle the delivery, could consist of the following micro-processes: Read the complete article here.


Use Oracle Integration to Add Attachments to a Process Instance
By: Bogdan Eremia

The other day it came to my attention that it’s not really straightforward to add attachments to an Oracle Process Instance using the REST API.

One reason for this is that it requires multipart/mixed media type for the request body message format, and producing this kind format is not so common for JavaScript clients. The JS clients are more used to working with multipart/form-data, the de-facto standard for form-based file upload in HTML.

One way of overcoming this is to use Oracle Integration Cloud (OIC) between the JS client and Process REST API. OIC has a REST Technology Adapter that supports sending/receiving attachments in both multipart/mixed and multipart/form-data media types. The goal is to shape in OIC a REST interface that accepts multipart/form-data, to do a translation into multipart/mixed (alongside with other transformations/actions if required) and to call the Process REST API. Below are the main steps for achieving this.

1. Create a REST Connection in OIC for Process REST API.

Go to OIC Homepage > Designer > Connections to create a new connection by selecting the REST Adapter.
Read the complete article here.

My private corner – Congratulations to 1 million page views