Monday, June 6, 2016

Innovation and the state of the Dutch economy

When I moved back to The Netherlands from Turkey in 2014, I thought that the crisis would be over and life would be better here than in Istanbul. Now, almost two years later, I found out that I'm wrong. I'm seeing too many people merely surviving, burdened by mortgages, divorces, unemployment and other problems. Personally, I think it's very sad that such a rich country has so many people buying second-hand things or even having to rely on charity to get a meal.

So, what is this country doing to get out of the crisis? Cutting expenses and nothing else. However, this is where things are getting problematic in the long run. Last week, I spent two days at the amazing AMIS conference about Oracle technology. Heard many inspiring stories about the latest developments in IT and realized that none of them are happening in The Netherlands. It's not because we don't have the technological skills: with an incredibly high amount of Oracle ACEs, we're rather the object of envy in the rest of the Oracle world.

In my opinion, the main problem is in the "bookkeeper" mindset. When I was working abroad, companies were using IT to enhance and renovate their businesses. After all, the economic struggle has also become a technical struggle and you need to be on top of things in order to survive.
So I've worked on a project for a Turkish company to enter the digital marketplace and on another project in Australia where IT was moved to the Cloud in order to free up resources, so they can deliver business goals, instead of doing maintenance. In the meantime, in The Netherlands I've been working on a project with the main purpose of taking work out of people's hands, so they can be fired. Also, when I look at disruptive businesses, they are hardly ever from my home country: we're stagnating.

When you look at technical innovation, it's obvious that it has to be driven by business innovation. If you're not going to do anything different with your company, why take the risk of jumping into some new and unproven technology? Why not just optimize what you have and see if you can cut some more expenses?

I have the opinion that innovation is the only way to get out of a crisis. You need to take some risks to have a competitive edge and with the fast developments that are going on, you can't risk waiting too long. You need to have a vision, invest in it and make modern technology the cornerstone of your future business. There are amazing possibilities out there in the Cloud with Internet of Things, Big Data, Analytics etc... and if you don't seize those opportunities, it will be game over sooner rather than later. It's time to start building on the future and the future begins today.

Best practice for calling web services from Oracle Process Cloud Service

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:
  1. If you have a WSDL with XSD imports, you need to upload a zip file with the WSDL and all the XSDs in it. All these XSDs will be imported as schema files in PCS.
  2. If you want to update your WSDL, you need to remove it together with all the imported XSDs and do a full upload again, otherwise it will fail. This is currently a bug and will hopefully be fixed soon.
  3. Once you promote your WSDL to a “Connector” in PCS, Business Types will be created for every type in the WSDL (and associated XSDs).
  4. Imported XSDs can’t have the same name as XSDs already existing in your PCS application.
  5. Auto-created Business Types can’t have the same name and namespace as already existing Business Types in your PCS application.
  6. For mapping the process data to your interface, you can only use BPM data associations.

Creating the interface – requirements

Considering the list above, there’s a clear set of requirements:
  1. Your WSDL shouldn’t have imports. All types should be defined in the WSDL itself.
  2. Your WSDL schema should have a different namespace from the schemas used in your process. For example, you could name one and the other
  3. Your interface should be a direct reflection of your process data.
  4. The amount of services exposed to PCS should be limited to avoid the creation of hordes of useless Business Types.

Recommended approach

The approach that I have chosen in my PCS project is the following: I have created one Requester Service in Service Bus (on Oracle SOA Cloud Service) for the entire Home Loan Application Process.  This service has multiple operations: one for each integration that needs to be made and each operation would call a business service that takes care of further processing. The interface of the service is the same as the main process data object, which contains the home loan application, copied directly into the WSDL with a difference namespace. Then I added the WSDL that I’ve created to my PCS application and promoted it to a Connector. 84 Business Types got created, because I’ve used a lot of complexType and simpleType components. Alternatively, you can nest everything into elements, but that approach would require a lot of re-work and doesn’t exactly make maintenance efficient.
Now I could map my data easily with a data association in the process, I could make changes to the data model and all complexities regarding integration are pushed to the Service Bus. The result is a tightly coupled integration between the process and its specific Requester Service, but from there on, I have all tools available to me to make proper integrations, including XSLT, WS-Addressing and whatever else I need. No unnecessary XSD imports have taken place in the process and when it comes to Business Types, the process is a lot cleaner compared to a scenario where every integration point would have its own Requester Service.

Basically, you can apply all your SOA best practices with the aforementioned approach, because you’re pushing all the technical complexity from PCS to the Service Bus. Even when PCS becomes more enhanced with integration possibilities, this will probably still prove to be a good approach, although I hope that WSDLs with XSD imports will be a good option in the future, for example by letting me choose whether I want to import all the XSDs into PCS or not.

Creating reusable Business Rules for SOA & BPM

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.


Now let’s have a look at the internal architecture of the Business Rule Engine (see picture above). Since we have the same Facts in all our RuleSets, we’ll get matches for all of them, so all RuleSets will be activated, including those that are not being called by your Decision Service! When a RuleSet fails to activate, an error will occur, so make sure that your Rules have the right conditions to make sure that this doesn’t happen. For example, a Rule that checks if reasonOfEmploymentTermination is of a certain value can have a very nasty impact on an Enrollment process that doesn’t contain this element. To avoid this, I’ve established the practice of using the pre-populated IF part of any Rule to check for the conditions of applying the Rule (f.e. employmentEndDate != null) and entering the actual Rule logic in the THEN part with a nested expression. This way, you have a consistent Rule design and since activation of RuleSets is incredibly fast, performance is not really an issue here.
So, to summarize what should be done in the Business Rule component, we have multiple Decision Services, all based on the same Fact, that call one or more reusable RuleSets.
Organizing your SOA landscape
So, you’ve decided to reuse your Business Rules and separate them from your processes. Your next step will be to think about the granularity of those Business Rule composites. Since we want both flexibility and reusability, I recommend a domain based structure, so, by example of my latest project, there can be an Employment Rules composite, an Employee Rules composite, Employer rules composite etc…
Since validations and process logic don’t always depend on one functional domain, I have also created a reusable Business Service (Employment Rules Business Service) that calls the domain based rule composites, wraps the responses together and exposes a canonical interface. This way, the number of integrations needed for Business Rule execution can be limited and some orchestration can be done in a centralized way. Additionally, this Business Service can take care of gathering additional information required to execute the Business Rules, so you don’t have to do that in each process or service.
How to keep things Loosely Coupled
Basically, my processes and services don’t really care which rules are being executed exactly. They just want to tell to the Rules Business Service “execute the rules that are applicable to me and give me the outcome”. So, when we take the Enrollment Process for example, it will send its relevant payload to the Business Service, together with an element to identify which rules should be executed. For example: EnrollmentProcessRules or EnrollmentValidationRules. Based on this information, the Business Service will do its orchestration and the Rules Services do some Content Based Routing to use the right Decision Service. Click the picture below to understand how it all hangs together.


When you look at the picture, Process A will call the Employment Rules Business Service with some payload and the identifier “EnrollmentProcessRules”. The Business Service does its orchestration and calls the Employment Rules Provider Service. This Provider Service then uses Content Based Routing in a Mediator to go the right Decision Service, which then calls the relevant RuleSets (defined with drag & drop in BRE) that execute the Rules within. The result will be sent back to the Business Service, that gathers all the results and returns a response to the process. Now, if an additional rule needs to be added for this process, how do we do this? We just go into the Business Rule component, add a Rule to a RuleSet or create a new RuleSet with the new Rule and add this RuleSet to the Decision Service that’s being used by the process, depending on the situation. Now we can just deploy the Provider Service again and the process can use its new rule without being changed. Same logic applies for modifying or deleting rules, so things are perfectly loosely coupled this way.
With this solution, I have managed to make Business Rules reusable and create a loosely coupled system for maximum business flexibility with a minimum amount of modifications and deployments required upon changes. Let's hope it will be useful for you and your clients. If you have any additional questions, you’re more than welcome to write to me and I’ll do my best to help you out.

Sunday, June 5, 2016

Basic integration of Process Cloud Service with Document Cloud Service

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 (click on the picture to enlarge):


Note that the revision number of the process is in the name of the folder, so when you deploy to a new revision number, a new main folder will be created.
In a follow-up article, I will tackle the issues of access rights and folder structures.


From the main page, I start my Insurance Claim application. It opens the Web Form that I’ve created for this task and a small blue document icon has appeared on the right side of my screen.


After filling in the details, you can click on the blue icon, navigate through any folders (if applicable) and upload a file. In this case, I have chosen to upload a Word document and enter an Amount of $1250, which leads to the management approval step.
Now let’s have a look at the manager’s task screen (through Work on Tasks). He will see the details that I’ve entered, as well as the same blue icon.


When clicking on the blue icon, the manager can see the document uploaded by the employee and watch in the Process Cloud environment. No downloads are needed, although downloading is obviously possible. It’s even possible to upload a new version of this document. This option will be elaborated upon in the follow-up article.



Integrating Process Cloud with Document Cloud is remarkably easy. No restarts or complex configurations are necessary: it’s really just entering the basic connection details and it works immediately. This is a very smooth offering from Oracle and living up to their promise of keeping things simple in Process Cloud. For those who want things a little bit less simple, my follow-up article will dive deeper into the extra options that integrating Process Cloud with Document Cloud has to offer. However, it looks like the basic integration is already a great addition to Process Cloud and no advanced options are needed to get started.