Currently, I am building a UI based on ADF 11 for a SOA Suite 10.1.3 BPEL Worklist. What should have been quite straight-forward has taken up quite a lot of time. The main issues are related to class-loading and multiple versions of a class in different libraries. The libraries have to be in a particular order for the custom worklist application to work.
The SOA suite ships a bpm-services jar that contains APIs that the client can use to interact with the BPEL worklist. The APIs provide for SOAP, REMOTE, LOCAL and JAVA clients. The SOAP client does not work for the simple reason that the SOAP messages (which is obviously an XML) misses some namespace declarations that are required. After decompiling and scouring through the code, I had to give up and look at the other approaches. The LOCAL and the JAVA clients were not feasible options because the worklist application would run on a different OC4J instance, so the REMOTE client had to be the only way out.
OC4J 11g ships with its own versions of the BPM worklist services and so the web application should be explicitly told to load its own jars first. Search OTN for the whitepaper on oc4j classloading.
Of course, on the BPEL PM side, there are web-service endpoints or servlets deployed to expose the various services that the BPEL worklist provides. The TaskQueryService is what I am after. Using the REMOTE client I have been able to ping the service correctly and a lookup for a particular task number works. However the queryTasks operation returns an empty resultset.
Update 1: I figured that the error in the SOAP message was due to the wsclient_extended.jar. I removed the jar from the classpath and let the application use whatever webservices classes that Jdeveloper ships under the “J2EE 1.4” library. Merely removing the wsclient_extended jar resulted in a Signer error for some classes. Solved this be removing some classes (javax, apache, etc.) from orabpel.jar.
Update 2: The queryTasks operation required the identity context (in my case jazn.com) to be set correctly when creating the workflow context.