Creating reusable Business Rules for SOA & BPM by Lykle Thijssen

image

 

This article dives into the Business Rules Engine (BRE) of Oracle SOA Suite and how to create reusable Business Rules for your SOA services and BPM processes. Basic knowledge of the BRE is assumed.

In many cases, when you work with SOA or BPM, Business Rules are involved. They are important for decision logic, validations and process routing. The Business Rule Engine (BRE) that comes with Oracle SOA Suite is a logical choice for modelling such Business Rules, but how do you make sure that those rules can be reused over different services and processes? And how do you isolate the Business Rules logic, so you don’t need to redeploy any other components upon changes?
In one of my projects, I’ve faced the situation of needing to address these issues and have come up with a flexible solution. This blog is the result of further finetuning of that solution, mainly by using the KISS approach.

Business Rule Engine (BRE)

First things first: let’s talk about the Business Rule Engine. It’s a powerful tool for executing if-then rules or rules in decision tables, but it’s not always too business friendly for modelling. If that’s a major problem for your client, you should consider Oracle Policy Automation instead. However, if you decided to use the BRE, then reusability becomes an issue pretty quickly. It’s very tempting to just create a BPM process and have the Business Rule component generated from there, but then those rules will only be exposed to that particular composite. There is no central repository for reusable Business Rules (like MDS), so your only real option is to put your Business Rules in a separate SOA composite.

When we dive deeper into the Business Rule Engine, we see four major components:

  1. Decision Services
  2. RuleSets
  3. Rules
  4. Facts

Decision Services are the interfaces of the Business Rule component. One BRE component can have multiple Decision Services and one Decision Service can call multiple RuleSets.
RuleSets are groups of rules that can be called by different Decision Services. They should generally contain rules that should always be executed together.
Rules are being executed by the BRE. A rule can only exist in the context of one RuleSet, so rules are not reusable on their own.
Facts are the input objects for your Rules. Since our objective is to create reusability, I recommend to stick to one input fact, which can then be used by all the Rules. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Best practice for calling web services from Oracle Process Cloud Service by Lykle Thijssen

clip_image002

 

More often than not, you will want your processes to interact with other services or processes inside or outside your enterprise. Since integration options are rather typical in Oracle Process Cloud Service, this article will help you to apply best practices for creating and managing your connections in a sustainable fashion.

Process Cloud integration points

Let’s say you have modelled a process in Oracle Process Cloud Service (PCS) for a private home loan application. Chances are quite high that this process will need some extra information to make the right decisions, like a credit check or a risk assessment and you will want to store the result of the application somewhere, for example in a database.
This requires several integration points in your PCS application. Now if you would directly import the WSDLs of those web services that you need to integrate with, it’s most likely not going to work. For example, Oracle Policy Automation, which you can use for risk assessment, has a highly generic interface and without XSLT support in PCS, you can’t make a proper request. Other services might require WS-Addressing or other technical aspects that PCS doesn’t support, so you need to put something in between. For this something, you can use various SOA and Service Bus products or Oracle’s Integration Cloud Service, once it has matured some more to deal with web services properly.

Creating the interface – challenges

So, you have decided to put one or more layers of services between PCS and the web services that you need to invoke. Regardless of your architecture, you need to keep some considerations in mind: Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Basic integration of Process Cloud Service with Document Cloud Service by Lykle Thijssen

clip_image001

 

Recently, Oracle had released a new version of Process Cloud Service. It mainly contains some minor improvements, but also has one major update: Oracle Process Cloud Service can now use Oracle Document Cloud Service for working with documents in business processes. This blog will show you how to make it happen.

Establishing the connection

In the main page of Oracle Process Cloud Service, click on your user in the right-top corner and select “Administration”. On the Administration page, you click “Settings” under Configuration, which will get you where you want to be. Here you can fill in the URL of your Document Cloud Service, as well as username and password of the admin user. You can test the configuration immediately and click “Save” in the upper right corner when the integration was successful.

Once the connection has been established, we can proceed to using documents in our processes immediately!

Developing the process

For this blog, I have created a small sample process for insurance claims. An employee of an insurance company will enter some details through a web form and attach a bill sent by a client. Then, if the bill is over $1000, a manager needs to approve or reject the claim. After this, the process will end. The small sample process looks as follows:

During development of the process, I have done nothing related to documents, this comes automatically! Of course, it is possible to work on document settings: for example, you can set access rights while implementing the human task. You can also create document folders on the application level of Process Cloud, but for now, I have decided to go with the default setting of one folder for my application, which will automatically be created in Document Cloud. For every instance of the process, a subfolder is automatically created too, so from Document Cloud side, it looks as follows: Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Synchronizing databases through BPEL services by Lykle Thijssen

 

clip_image002Introduction

This blog post is about how to synchronize two databases through BPEL, focusing on transaction, rollback and fault handling.

During a project, I’ve encountered a situation where we wanted to migrate from an old database to a new one. However, in order to gradually move external systems from the old to the new database, it was required that both databases would be kept in sync for a limited amount of time. Apart from the obvious database tools, for example Oracle Golden Gate, this can be done through the service layer as well and that’s what this article is about. I will explain how I have done it with a strong focus on fault handling, since that’s the most complicated part of the deal. In this case, since keeping things in sync is what we’re aiming for, a rollback needs to be performed on one database when the other fails to process the update.

One of the requirements is that it should be easy to throw the synchronization code away, as it has no place in our future plans. Another requirement is that the service layer should return faults in a decent manner.

Preparation

In order to enable out-of-the-box rollback functionality, make sure that the data sources connecting to both databases are XA enabled. As there is plenty of information about this subject, I will not get into detail about it in this blog.

Now we will be developing two services:

  • SalesOrderBusinessService: a BPEL process that receives messages from a BPM process and forwards them to our integration service
  • UpdateSalesOrderIntegrationService: a BPEL process that receives messages from SalesOrderBusinessService and updates two databases through adapters

We need to make sure that both services have a fault specified in their wsdl operation in order to return the recoverable fault. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki