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.

Wednesday, May 27, 2015

Oracle BPM 12c Advanced Error Handling and Recovery - Part 2

The second part of my two series article on "Oracle BPM 12c Advanced Error Handling and Recovery - Part 2" has been published by OTN.

The second part explores the important error recovery changes and improvements that Oracle made from an operations and management perspective in Oracle BPM 12c.

Please do read it and give me your feedback.