Step 2: Accessing the CRM System

My excursion into the "real" world of SOA has already been a learning experience. As mentioned in my original post in this series (The Beginning), the intent is to move away from the vendor propaganda and canned tutorials and implement a business process from the ground up using different SOA products. This way I can understand first hand what it takes to service enable existing applications, the implications of various system interfaces that can be encountered in an Enterprise, and the challenges to deal with when trying to build a composite application with pre-existing systems. In order to do this, several of my colleagues and I have created a Virtual Enterprise (described here).

So far, we have encountered the need to introduce a new service into our Virtual Enterprise due to the granularity of some of our Enterprise Applications (specifically the IVR and Email systems). We also began to realize that SOA products don't always support some of the deployed technologies within an Enterprise. As described in my previous post (Receive a JMS Message), I had to workaround the fact that Cape Clear did not support our Virtual Enterprise messaging standard of ActiveMQ. Also, Cape Clear expects all messages to be SOAP messages our Alert system doesn't communicate via SOAP.

This is all good stuff. I am starting to accomplish exactly what I set out to....experience SOA in the real world. Now on to the next challenge....invoking a web service (RPC encoded style) to retrieve a set of participants in my event.

This task seems pretty straightforward. Call a web service, get a set of people back and use this set to send out some notifications. Cape Clear likes everything to be a web service, so what could be easier. Just define the partner in your BPEL process using the WSDL from the CRM web service, drag and drop....and now you can use the CRM system in my process.

Cape Clear has a very easy way to define a partner within a BPEL process. Simply walk through a wizard which requests a WSDL (either file, URL, or Cape Clear Server based), asks you to define the partner type (in this case I will be invoking this partner), and like magic it creates the necessary variables to be used in your BPEL based on the schemas defined in the WSDL. Based on the operations exposed within the WSDL, the appropriate actions also become available to your BPEL process. From there it's good old drag and drop the action onto the BPEL process, use the variables created during the partner definition......and viola, you just included this external system in your business process.

Here is where I encountered my next challenge. Recall that this web service is using RPC encoded style SOAP and returns an array of people. The variable that Cape Clear (and I learned later any current BPEL engine) creates is a simple variable type. Well, I am trying to work with a complex array of people. Something isn't right here. After much research, struggles, research, struggles and a submission to the Cape Clear forum I decided I needed a work around.

While waiting to hear back from the Cape Clear folks, I decided to wrap the CRM systems RPC style web service with a document/literal style web service. Then I could use the document/literal web service in my BPEL process. Sounds like a good bit of overhead, but that is for a later topic.

So, I attempted to create a simple web service that calls another web service. This is great....Cape Clear allows me to create a project for exactly this purpose. So, first I create a schema that will represent the return type of my new wrapper web service. This schema essentially defines an element containing an unbounded number of people elements.

Now, I fire up the Cape Clear wizard to create a web service that invokes another web service. I point at my RPC style web service and.....low and behold....the wizard cannot handle the WSDL. Great....now what. I decide to try create a web service client in a standard Eclipse IDE I have installed (BTW....the Cape Clear IDE is Eclipse with some plugins) and everything worked fine. So now I submit my second post to the Cape Clear 7.0 Beta forum (I was still waiting on a response to the earlier post).

In the mean time, I create a WSDL based on the schema I created earlier for my new wrapper web service. If you never created a WSDL from scratch before....it's a good learning experience. Once I had the WSDL defined, I created a Java Web service to implement the WSDL. I then had to copy in the classes from my external Eclipse project that would allow me to call the RPC style web service into my new Cape Clear project. I now had one project that represented a web service that would call another web service. I deployed this to the Cape Clear Server and was now able make the call out to the CRM web service through my new wrapper web service.

After this was completed and functional, I got my reply from Cape Clear. They informed me that "RPC/encoded style of WSDL is not supported by BPEL. The problem is that according to the rules of SOAP encoding, the messages does not conform to the structure defined by the XML Schema". Their recommendation was to do exactly what I ended up doing...create a web service that wraps the RPC/encoded style web service (although they recommended RPC/literal). They also indicated that "The local call to the new web service will be very efficient, so it shouldn't cause any performance problems". Again, that is for a later topic.

Good thing these tools make it so easy to build a business process :)