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 http://www.amis.nl/processes and the other http://www.amis.nl/services.
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 BPEL 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 different 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 most of 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 valid option in the future, for example by letting me choose whether I want to import all the XSDs into PCS or not.