Monday, September 21, 2015

Oracle BPM 12c Subprocesses (Part 1 of 3): Reusable Subprocess

In this three part series we will explore an additional BPMN flow object, the subprocess. By definition, a subprocess is another type of process that can either reside within the main process or it is called by another process.

A subprocess, just like a normal process has its own start and end events and can accept data object, update data objects and return data objects. There are three types of subprocesses, “Reusable” subprocesses, “Embedded” subprocesses and “Event” subprocesses. In this first part we will dive into the “Resuable” process.

A “Resuable” processes, as the name implies is an independent process that is often used to group common and repeated flows (and activities) so that they can be reused (as opposed to re-implemented every time where needed) and which can be invoked by multiple parent processes within the same BPM project. And it’s imperative to stress here the last part, “within the same BPM project”, as a “Resuable” process cannot be used/invoked from other BPM projects. To achieve the latter you will need to use templates (feature that I will be blogging later).

As opposed to a normal process where can you use a variety of events to start and end a process (for example, message start event, timer start event, signal start event, message end event, signal end event, etc.), a “Reusable” subprocess can only start with a none start event and can only end with a none end event.

Furthermore, to invoke a “Reusable” subprocess from a main process, you will need to use a “Call” activity that by implementation allows you to call a reusable process synchronously. What this means is that when the parent process invokes a “Reusable” process it will wait until the “Reusable” child process completes execution before the parent continues its flow.

However, even though the token is passed from the parent process to the subprocess, the child subprocess does not share the parent context, meaning that the data objects of the parent process are not available to the “Reusable” child process.

So to pass data objects from the parent process to the “Reusable” child process (and vice versa), your subprocess will need to define data object of its own and using the data association mappings of the call activity you can pass data objects from the parent process to the subprocess and backwards. Data objects defined in a subprocess are only accessible within the subprocess.

Let’s see in practice how you can create a subprocess and how to invoke a subprocess from a main process. For the sake of simplicity and easiness we will build the “Quote” process depicted above but “Save Quote” service call.

Create the basic BPM application and BPM project with an asynchronous BPMN process that takes a simple string input argument (for example bidId) and returns a string argument (for example status).

Create two string process data objects to store the process input and output arguments for reference throughout the process.

Next assign the process input and output arguments to the respective process data objects. On the "Start Message" select "Properties", "Implementation", "Data Associations" and drag source argument (bidId) to target data object (pBidId). Do the same for the output argument, mapping status to pStatus.

Drag and drop two interactive human task activities onto the default transition line from start to end naming the first “Enter Quote Details” and the second one “Finalize Quote”. You process should look like below.
Notice how the human task activities are marked as incomplete. That’s because they haven’t been implemented yet. So let’s create a single human task definition to serve both human tasks.

Double click on the “Enter Quote Details” human task and from the “Properties” window go to the “Implementation” tab and click on the green “Add” button to create a new definition. Specify a name, (for example SingleOutcomeHT) and just select a single outcome, “OK”.

Open the properties of the second human task (“Finalize Quote”) and select the human task definition you created above. Both warnings should disappear since both human tasks have been implemented.

Let’s now create our reusable subprocess. This subprocess will just serve as a validation sub process and will include a single human task.

Right click the "BPMN Processes" folder and from the context menu select new "BPMN 2.0 Process" . Give your process a name and ensure you select "Reusable Process" from the process type selection list.

To demonstrate context isolation between the main process and the sub process let's create an input and an output argument (quoteId as an input string argument and an outcome as an output string argument).

Create two process data objects to store the input and output arguments for reference throughout the sub-process.

Next assign the sub-process input and output arguments to the respective sub-process data objects. On the "Start None" select "Properties", "Implementation", "Data Associations" and drag source argument (quoteId) to target data object (pQuoteId). Do the same for the output argument, mapping pOutcome to outcome.

Drag and drop an interactive human task activity onto the default transition line from start to end, name it "Validate Quote" and create a new definition for the interactive human task activity. Specify a name, (for example DualOutcomeHT) and ensure that both "APPROVE" and "REJECT" outcomes are selected.

In the human task title ensure that you use the sub-process input data object to see how data objects are passed (via assignments) from the parent process to the sub-process.

One last thing is to assign the human task outcome to the sub-process data object you've created to store the sub-process return argument (pOutcome). To do so open the interactive human task activity properties, go to the implementation tab and using the data associations ensure that you copy the human task outcome argument value to the pOutcome data object.

With the sub-process complete we can now go to the main (parent) process and call the "ValidateQuoteSubProcess". To invoke a reusable sub process from a main process you will need to use a "Call" activity.

Therefore drag and drop a "Call" activity just between the two interactive human task activities. Give your "Call" activity a name (for example "Call Validate Quote Sub Process") and from the implementation tab, in the process drop down list ensure you select your reusable sub process.

As already stated above, the main process does not share its context (therefore its data objects) with a reusable sub process. To pass data objects from the main process to a sub process you need to use data associations.

Therefore using the data associations of the "Call" activity ensure that, from the input tab, you copy the pBidId main process data object to the quoteId input argument of the reusable sub process and from the output tab you copy back the outcome from the reusable sub process back to the main process.

We are now ready to deploy and test our process (and sub process). From the EM (Enterprise Manager) invoke a new instance of your process and open on the flow trace. Your instance should be waiting at the first human task activity.

Go to the BPM Workspace and you should see a new task in your inbox (weblogic given that you mapped weblogic as the process owner). Submit the task and go back to the flow trace. You should see that your instance has invoked your reusable sub process and is waiting for review.

Approve (using the BPM Workspace) the new task that has been created and assigned and go back to the flow trace. You instance should have resumed execution of your main process and should be pending at the third step.

Approve the third and last step and your instance should be completed. If you inspect the audit trail of the end activity of your main process you should notice that review human task outcome from the reusable sub process has been passed back to the main process and copied to the return argument of the main process.

Download sample application: Reusable Subprocess

Tuesday, August 25, 2015

Suppress Approval Controls from BPM Workspace 12c - Hidden Feature

I recently came across a very interesting discussion on the Oracle BPM forum which stimulated my interest for investigation; how to suppress the human task custom outcomes from the action bar in the BPM Workspace application in 12c!

When you deploy a BPM process or a BPEL service that includes a human task component, the BPM Workspace will automatically include in its action bar the custom outcomes that you have defined on your human task.

In the image above it's assumed that a composite has been deployed that includes a human task component that defines a custom outcome "Submit".

There are cases though that you might want to suppress this default behavior and not have your custom actions appearing in the actions list but just have them displayed in the task details.

In 11g this was "officially" supported with a checkbox option ("Show approval controls in task details only") in the advanced human task properties.

Such option is not anymore available in 12c human task editor. However I discovered that the human task engine still "unofficially" supports this feature. And even though there is no way to define this option via the human task editor, you can define it in source view.

So go to your human task definition file (.task file), switch to source view and insert into the "preActionMandatoryUserSteps" element the following  


Your human task definition should look like below.

Thursday, August 20, 2015

Oracle ACE Director Confirmation!

Oracle ACE Director Confirmation!

Finally, the coveted email arrived.

"I’m pleased to inform you that your Oracle ACE Director nomination has been accepted."

I cannot be more happy and proud to be part of such an elite group, I feel really honored.

I would like to take this opportunity to express my heartfelt thanks to the ACE Program and everyone who supported me into this wonderful journey, which I can say with certainty that it’s only the beginning.

Special thanks go to my sponsor, Bob Rhubart, an incredible person and an inspiring mentor, which without his support I wouldn’t have made it.

My Oracle ACE Director profile is available here.

Friday, August 14, 2015

Using ADF BC Declarative Built-in Rules (Part 10 of 10): Method validator

The last part of my tenth part series on declarative build-int rules is on the "Method" validator, an option where you can write more complex validation rules on your business domain layer.

Method validators can be defined at either the entity level or at the individual attribute level and are coded using the Java programming language that are called automatically during the validation cycle.

Method validators have three unique characteristics; they must be defined as public, they must return a boolean value and the method name must begin with the keyword "validate", for example, "validateDepartmentManager".

Let's see this validator type in an example. In the demo that will follow I will implement a validation constraint on the HR.Departments table to ensure that an employee cannot be defined as a manager of more than two (2) department.

I have created an ADF Fusion Web Application and created the basic business components that I will be using in this demo; an entity object based on the Departments HR table, a default view object for the departments entity object and a default application module.

Because my validation rule will have to count the number of departments a specific employee is a manager of, I will create a view criteria in the DepartmentsView view object to filter departments using an employee id that will be passed as a parameter.

Next let’s define an entity level validation. From the “Business Rules” tab of the Departments entity object, click the green plus button. Give a meaningful name to your validation rule (for example, "DepartmentsManagersValidationRule") and select "Method" from the "Type" drop down.

Ensure that the "Create and Select Method" check box is selected and if needed you can customize the method name. Please make sure that your customized method name begins with the keyword "validate".

Go to the "Failure Handling" tab and define your failure message. In my example I have used a message token expression to construct a dynamic error message, passing to the failure message the department id.

When you click "OK" you should get a popup message, informing you that the entity java file does not exist and whether you want to create a default java file for the selected entity object. Click "Yes".

Before we go into the entity implementation class and define the logic for our method validator, we need to create a view accessor. Why do we need this? Well, do you recall the view criteria we created above, "findDepartmentsByManagerIdViewCriteria"? We will use this to count the number of departments a manager is assigned to.

From the "Departments" entity object, go to "View Accessors" and click on the green plus button to create a new accessor. From the available view objects select the "DepartmentsView" view object and shuttle it to the right pane.

Ensure that the "DepartmentsView" view object is selected in the right pane and click on the "Edit" button to edit the view object's accessor. Move the "findDepartmentsByManagerIdViewCriteria" view criteria to the selected pane and map the "ManagerId" attribute to the "pManagerId" bind parameter.

Click "OK" to apply your changes and close the windows. Now we are nearly ready to implement our custom validator.

Go to the "Java" tab of the "Departments" entity object and click on the edit pencil icon to edit the implementation class that was automatically generated for you when you defined your custom method validator and select the "Accessors" check box. This will generate accessors for all entity attributes and view accessors into your entity implementation class which we will use in a bit.

Now we are ready to implement our validation logic. Click on the entity implementation link to open the Java class and at the end of the class you should locate your custom method validator method. The logic should look like below:

    public boolean validateDepartmentManager() {
        RowSet departmentsView = this.getDepartmentsView();
        if (departmentsView.getRowCount() > 2) {
            return false;
        } else {
            return true;

I am using the view accessor defined on the Departments entity object to get a hold of the view criteria to fetch the number of departments the currently selected manager is assigned to.

Run the Application module to test the "Method" validator. Open the "DepartmentsView" view object and create a new department, assigning it one of the existing managers, for example manager with manager id 200. The record should be validated successfully.

Now try creating another department using the same manager id. The method validator should return false now and you should get your custom error displayed.

Download sample application: Method Validator

Tuesday, July 7, 2015

OTN ArchBeat Podcast: BPM Challenges and Changes

I had the honor to be part of a great team of speakers and discuss the latest BPM challenges and changes in an OTN ArchBeat podcast that was moderated by Bob Rhubart.

Our OTN ArchBeat Podcast is a four-part series focused on Business Process Management.

The Conversation
  • Listen to Part 1:Take a seat at the virtual table as a panel of experts talks about how organizations are meeting some of the biggest BPM challenges.
  • Listen to Part 2: The expert panel panel shares insight into the Oracle BPM features they find the most useful, and how those features are being used to deal with real-world BPM problems.
  • Listen to Part 3: How does the new Oracle Process Cloud Service compare to Oracle BPM? The panelists talk it out.
  • Listen to Part 4: What’s the one thing you should know before starting your first Oracle BPM project? Advice you can use from people who know.
For the podcast show notes and additional and useful resources please consult the OTN ArchBeat Podcast page here.

Monday, July 6, 2015

Oracle BPM 12c Events (Part 3 of 3): Intermediate Events

The third and last set of events are referred to as "Intermediate Events" and as the name implies they can occur between the start events and end events.

"Intermediate Events" are sub-classified into two groups, "Catch Events" and "Throw Events".

"Catch Events" can occur anywhere in the middle of the process and what they do is that they block the process for specific conditions. We do have a variety of "Catch Event" activities such as a "Catch Message", a "Catch Timer" and a "Catch Signal" activity.

The "Catch Timer" event provides a delay mechanism in a process flow. The delay can be based on a specific date and time or on a recurring interval, for example, every day at a specific time.

The "Catch Message" activity is also used to model a request-response and receive-reply patterns. It is equivalent to a BPEL receive, so instead of having a "Send Activity" to call a service or a process and a "Receive Activity" to receive the response from a service or a process, you can use a "Throw Message" and a "Catch Message" respectively.

"Catch Events" also have a really nice capability as they can be attached as boundary catch events. What this means is that you can configure a task or a sub-process to listen to internal or external triggers.

For example, if a specific service does not respond back within a specified time frame to resume process execution.

Boundary events are either interrupting or non-interrupting. In the case of an interrupting boundary event the normal flow is interrupted and the exception path is taken. In the case of a non-interrupting boundary event then both normal flow and exception paths are executed. We usually use boundary events to handle exceptions.

"Throw Events" on the other hand can throw a message or a signal to another participant or process.

The "Throw Message" activity is used to send a message and is typically used to invoke an other BPMN process, a BPEL process, a SOA service adapter or a mediator that is exposed as a service.

The "Throw Signal" event activity is used to publish or broadcast a signal. You can use a combination of signal throw and signal start events to invoke multiple processes simultaneously.

So let's see how you can use a boundary event, more specifically the timer catch event as a boundary event, to wait for a service response. If the service doesn't reply back within a specified time-frame the process should terminate (but I will also be showing the non-interrupting feature of a boundary event).

For this demo I will need a service to simulate the order validation service. So i created a Java method to mock the order validation service and exposed it as a web service.

The order validation service is really simple; it accepts two parameters, an order id and another int representing the thread delay. The service just returns a boolean. The process will call this service and will pass it the delay. The service will wait for the supplied delay and return back a boolean based on the supplied order id.

Create the basic BPM application and BPM project with an asynchronous BPMN process that takes two integer parameters, orderId and serviceDelayInSeconds.

Create two integer process data objects to store the process arguments for reference throughout the process.

Assign the process arguments to the process data objects (on the "Start Message" select "Properties", "Implementation", "Data Associations" and drag source argument to target data object).

Next we will have to call the "Validate Order" service and to do so we need to first include an external reference to the service. To do so I will use a "SOAP Adapter" and I will drop it onto the "External References" swim-lane.

Enter a name for your service reference and in the "WSDL URL" enter the WSDL URL of your service.

In the "Localize Files" screen uncheck both copy options.

We will next use a "Service" activity in our BPMN process to call the service via the reference created above. So drop a "Service" activity between the "Start" and "End" events and give your service activity a name (i named it " Validate Order Service").

In the "Implementation" tab, from the "Type" drop down select "Service Call" and using the browse button next to the "Service" field select the validate order service.

The "Validate Order Service" requires two parameters to be passed; the order id and a delay in seconds. So using the "Data Associations" map the orderId and serviceDelayInSeconds data objects to the service's arguments.

Let's assume that if the service responds back in less than 5 seconds then the process should follow the normal path, otherwise the process should follow a different path. To simulate this alternative path I will use a script task.

The script activity is marked as error-ed; that's because it doesn't have an incoming or outgoing sequence flow.

Next we will define the timer boundary activity. Select the "Catch Timer" event and drop it onto the service task. Give your boundary event a name (for example; "Response SLA") and in the implementation tab define an appropriate timer definition (in my case I defined a timer expression of 5 seconds).

Please note that just below the "Implementation Type" there are two checkboxes; "Interrupting Event" and "Suspending Event". I chose the "Interrupting Event" option, meaning that when this event fires the token will leave the main process and follow the flow the timer defines.

Next add a default sequence flow from your "Catch Timer" boundary event to the script task and a default sequence flow from the script task to the "Message End" activity.

Deploy your process and instantiate a new instance of your process using the Enterprise Manager. Enter an order id (for example 12345) and in the serviceDelayInSeconds enter a number that is less than the configuration of your "Catch Timer", for example, 2.

Go to the flow instances and inspect your instance; the "Catch Timer" boundary event didn't fire and the process followed the normal path.

Run another test but this time enter a delay that is greater than the configuration of your "Catch Timer", for example 7. Inspect your instance, you should notice that the boundary event fired and that the process left the main path and followed the path defined by the boundary event.

Download sample application: Intermediate Events

Wednesday, June 24, 2015

FMW Updates: Oracle Integration Cloud Service (ICS)

Oracle Integration Cloud Service (ICS) is a simple and powerful integration platform in the cloud to maximize the value of your investments in SaaS and on-premise applications. 

It includes an intuitive web based integration designer for point and click integration between applications and a rich monitoring dashboard that provides real-time insight into the transactions, all running on a mature runtime platform on Oracle Public Cloud.  

ICS will help accelerate integration projects and significantly shorten the time-to-market through it's intuitive and simplified designer, an intelligent data mapper, and a library of adapters to connect to various applications.