"Private" BPEL Processes

When developing any BPEL based solution, good practice dictates that you take a modular approach to process design, which allows the sharing of sub-processes among higher level processes. For example a payment process may be used by both the Expenses Process and Order Process.

As a result you will often end up with BPEL processes that you only intend to be called by other BPEL processes, and typically BPEL processes with at least some knowledge about the underlying process. So how do you prevent other ‘clients’ from directly invoking these processes?

Now initially this may sound like a security issue, and Oracle BPEL Process Manager provides a number of ways of securing BPEL Processes; in addition Oracle Web Services Manager provides a comprehensive solution for adding policy-driven security to all Web services (not just BPEL Processes).

However security is typically intended for enabling controlled secured access to a BPEL Process (or Web Service) by authorized clients. However in this case we don’t actually want any client directly accessing the process. Now admittedly we could take a standard based security approach to this, but is there a simpler way?

Now many programming languages such as Java provide the concept of private or protected methods that control what has access to them. For example, in Java a class may declare some of its methods as being protected; indicating that only other classes in this package can access these methods. The great thing about this approach is that the developer is actually signalling a level of intent, i.e. this method should not be called directly except by related classes (or sub-classes) that can be trusted to use the method correctly.

Ideally it would be great if BPEL provided similar functionality, however unfortunately it doesn’t. So is there a way of achieving something similar?

Well it turns out there is a fairly straight forward way of getting close to the desired effect. The approach makes use of the Oracle HTTP Server embedded within the Oracle Application Server (as such this won’t work for the Developer install) to prevent access to a specific URL pattern, plus the use of domains with Oracle BPEL PM to enable us to create a simple URL pattern for all “private” processes.

Configuring Oracle HTTP Server

Oracle HTTP Server is the Web server component of Oracle Application Server and is based on the Apache infrastructure.

Any one familiar with Apache administration is aware that it provides Allow and Deny directives which let you either allow or deny access to a particular URL (or pattern) based on the host name, IP address (or partial IP address) or a fully qualified domain name (or partial domain name).

By specifying a <LocationMatch> parameter in the httpd.conf file we can create a directive to only allow access to a URL which matches the specified pattern from the host on which the Oracle Application Server itself is installed.

For example the following directive will only allow access from the host to any URL which contains the string “/orabpel/private/”:

   <Location /orabpel/private/>
      Order deny, allow
      Deny from all
      Allow from localhost
   </Location>

Note: The httpd.conf file can be found in the directory:

   <ORACLE_HOME>/Apache/Apache/conf

Configuring Oracle BPEL PM

Now the trick is here to be able to provide a simple URL pattern on which to place the restriction. This is actually rather straight forward.

Oracle BPEL PM has the concepts of domains into which a BPEL process is deployed. A BPEL domain allows a single instance of Oracle BPEL Process Manager to be partitioned into multiple virtual BPEL sections (each identified by an ID and protected by a password). When Oracle BPEL Process Manager is installed, an initial domain named 'default' is created.

If you inspect the location of any deployed process, you will see that the domain makes up part of the URL, for example:

   http://[hostname]:[port]/orabpel/[domain]/[process name]/[process version]

So using this approach we can create a domain called “private”. By doing this we can define a directive to Apache to prohibit access to any URL that contains the pattern “/orabpel/private/”.

You can create a new domain from the BPEL console. From the initial login screen, instead of login into a particular domain, select the link Goto BPEL Admin (the default password is oracle). From here select the ‘BPEL Domains’ tab and then ‘Create New BPEL Domain’.

Then any process we want to make private we simply deploy to this domain. This obviously makes it very simple to make a process “private” with the added benefit is that it also indicates that the process itself is intended to be private.

Additional Considerations

Now this approach only works when you call the BPEL process via the SOAP stack. Oracle BPEL PM also provides a Java RMI interface; requests made via this interface don’t go via the Oracle HTTP Server. However access via RMI tends to be more tightly controlled so this should not present a serious problem.

It doesn’t prevent other clients on the same box from calling the BPEL Process, however again if the client is hosted on the same box then I would hope you have a reasonable handle on what its doing.

Finally it doesn’t prevent you from submitting the BPEL process from the BPEL Console as the invocation is made from the BPEL Server itself; however each domain is password protected so this shouldn’t really be an issue.

We also mentioned that this approach doesn’t work for the developer install of Oracle BPEL PM as it doesn’t embed the Oracle HTTP Server. However as a default this is probably a good thing as if the process was secured then it would prevent the BPEL Designer in JDeveloper from actually being able to read the WSDL which is required in order to develop the BPEL processes which calls the “private” processes.

Of course you can come up with variations of this approach, for example you could conduct developments against a mid tier install and configure the http directive to only allow certain developers (or at least there boxes) to be able to access processes deployed to a particular domain.

Conclusion

On its own this isn’t a perfect approach to securing a BPEL process, but then it’s not intended to be. But as a relatively simple approach to creating “private” BPEL processes where it is clear that this is the intention, then I believe this is certainly one way of achieving that.

However I would be interested in hearing any comments or suggestions on this approach or any alternatives.

Writing a Recursive BPEL Process

Recently I was working with a client who wanted to implement a recursive process (i.e. one that calls itself). Now Recursion is a classic programming pattern, and in theory it should be pretty straight forward for a process to call itself. However at first sight it’s not so obvious.

The issue here is that the way a BPEL Process calls out to another process is to drag a Partner Link on to your BPEL Process and then use the Service Browser to select the deployed process that you wish to call.

Of course with our scenario, the first issue we hit is that we haven’t yet deployed the process as we’re still writing in it! The obvious thing to do here is create a stub process, with just the basic receive and reply operations defined and then deploy the stub. This works great, we can now select the process within the ‘Service Browser’ and finish implementing the process.

However the next problem occurs when we try and re-deploy the completed process. Here the deployment fails with an error that it is unable to validate the WSDL for the Partner Link. The issue here is that as part of the deployment process we are “over-writing” the old stub version of the process, with a new version (as we want to keep the version number the same).

The way BPEL PM achieves this, is to un-deploy the old version of the process, before deploying the new version. As part of the deployment, the BPEL engine validates the WSDL for all Partner Links including our recently un-deployed version of the process and as a result fails!

Fortunately there is a simple work around. First create and deploy the sub process as before, then once deployed go to the BPEL Console and select the process from the dashboard. Then select the WSDL tab and click on the URL for the WSDL Location.

This will open a browser containing the WSDL for the BPEL Process, save the file to your local file system (File-> Save As in IE) as .wsdl file. Now when you create your Partner Link in the process, instead of using the ‘Service Browser’ use ‘Browse WSDL files from your Local File System’ and select the WSDL file you just saved.

Note: When prompted to make a local copy specify ‘yes’.

From here you will be able to implement and deploy your BPEL process without any problems.

Example

I’ve created a simple example process, based of course on the classic Factorial example. You can download this here.

Deployment Considerations

The one drawback with this approach is that the WSDL file will now contain the Endpoint location for the service within in it. Thus is you were to deploy the process on a different server it would fail at run-time.

So you need to modify the WSDL file at deployment time so that the endpoint reflects the hostname and port number of where the process is actually being deployed. The simplest way to do this is update your build script so that ant will automatically do this for you.

Final Thought

Now in theory you could have incredibly nested processes using this approach, however I would advise is bad practice and is likely to have performance implications.

For example; if we ran the Factorial process to work out 50 Factorial, that would result in 50 process instances. Now if we expected to handle 1000 process running in parallel, this would result in 50,000 process instances – so the actual number of process instance could increase very dramatically.

So I would recommend using this approach with caution to ensure that it doesn’t result in a dramatic increase in the overall number of process instances.

Using Analytics to Modify In-Flight Processes

I recently had the pleasure of presenting the Oracle Key Note at the Butler Business Process Management & Integration symposium. The subject of the keynote was to look at how we can use business analytics to enable us modify processes already in-flight.

When you consider the traditional closed loop BPM Lifecycle, as illustrated below, the emphasis has always been very much on using analytics about how processes have performed in the past, in order that we can modify the actual process definition in order to improve / optimize future versions of the process.



Whilst this approach has many benefits, the challenge was how we could modify processes already in-flight. In order to achieve this we need to overcome a number of challenges; firstly we need to collect analytics in (near) real time in order to base our decisions on up to date information; secondly we need a controlled way of modifying the in-flight process based on the data.

Collecting Real Time Business Analytics

Business Activity Monitoring (BAM) provides us with the tool to collect the near time analytics on which we can base our decision on how we wish to modify our in-flight processes.

For those of you who are not familiar with Oracle BAM, it enables the business to gain a real-time view of what’s happening with the business. To achieve this it provides the following key components:

• Capture Real Time Data - Within a BPEL process you can place a sensor on any activity with a process, when triggered this generates an event which is picked up by BAM in real time.
  
  Note: You can actually use events generated pretty much by any event based system (e.g. database triggers, messaging systems, etc), it’s just that BPEL makes it very easy.
  
• Analyze Processes, Trends, and Context - Next Oracle BAM is able to correlate all these events and synthesize them into meaningful data objects within it’s active data cache
  
• Interface for Business Users - The business can then build interactive real-time dashboards and proactive alerts on top of this active data to enable them to monitor the business processes.

For more information on BAM see http://otn.oracle.com/bam.

Modifying In-Flight Processes

Once we have the real time analytics, the next challenge here is to use the data to modify the processes already in flight.

Now when we talk about modifying In-Flight Processes; most people assume that this involves quickly writing a new version of the process, testing it, deploy it, and then migrating the existing in-flight processes to this new improved version. The reality is that is rarely as quick as required!!!

Rather what’s really required from a business perspective is to be able to modify the flow through a process (and its sub-processes) in order to obtain the desired business outcome. There are three basic patterns here which provide a way of achieving this, these are:

• Modify Process Flow – This uses business rules, which can be modified externally to the process to change the flow through a process instance.
• Exception Management – This uses BAM to launch a process to manage an exception which is (typically) occurring across multiple processes.
• Dynamic Process Assembly – Here we use BAM as source of real time data against which to evaluate Business Rules and use the results to dynamically call sub processes and assemble the end to end process on the fly.

Modify Process Flow

With this approach we are not looking to modify the actual process, rather modify the “path” through the process. If we look at any process, then at various points the process will hit a decision point which will determine which route it should take the through the process. Rather than building these decision points directly into the process we can externalise them in a rules engine such as Oracle Business Rules or iLog JRules, as illustrated below.



This then enables the business to modify the rules based on what’s currently happening within the business (as indicated through BAM) and thus get the process to take a different route.

An excellent case study for this is Cattles (a UK company which lends money to the secondary market), which uses a combination of BPEL, BAM and Rules for this purpose.

Exception Management

BPEL already provides a comprehensive way to handle exceptions, within the context of a process. However on some occasions we want to take a more holistic view to managing exceptions. This is certainly the case where we are suddenly “hitting” a common exception across multiple processes.

For example, if we have a loan flow process that’s going out to an external credit rating agency, and for some reason that credit rating check fails. Within the individual process BPEL process, we could have built in a simple re-try mechanism that simply waits a period of time before re-trying the service.

However if we start having a high number of failures (e.g. we may 1000’s of these processes running at any time), rather than handle the same exception multiple times (at least the same root cause) we can use BAM to detect that we have an issue and kick-off a single process to handle that exception (as illustrated below).

Dynamic Process Assembly

Rather than use BAM to feed a Dashboard, we can use it as a real time data source. A BPEL process can then query this real time data and pass this to the rules engine; enabling us to evaluate rules based on real time data.
At this point we could just use the result from the rules engine to dictate the flow through a process (as we did with the first example – Modify Process Flow).

However (as the title implies) we can take it a step further and dynamically assemble the process. The trick here is to have multiple “sub” processes all with the same WSDL definition. The rules engine rather than returning a “decision” now returns the end-point of the sub process to call, which the main BPEL process can then call dynamically (as illustrated below).



For more details on how to implement dynamic routing, see my previous blog; Using BPEL to Implement Dynamic Content Based Routing.

Final Thoughts

You can download a pdf of the full presentation from here. In the mean-time I would be curious to learn of any other strategies that are being adopted for modifying in-flight processes.