Java Clients for Workflow services

You can build clients for workflow services using the APIs exposed by the workflow service. The APIs enable clients to communicate with the workflow service using local and remote EJBs, SOAP, and HTTP. Worklistapp is one such Client which uses the local EJBs to access the services. When we access worklfow services from bpel it uses the WSIF bindings which is nothing but native Java wrapped as WSDL. From any Java client code we can use either Remote or SOAP client types.

Good example from Oracle is here, however this is for OC4J based, for weblgic there will be slight changes in the wf_client_config.xml and the JAR files. In wf_client_config.xml we can use t3:// instead of ormi and weblogic.jndi.WLInitialContextFactory. For JAR files better to put all the ones mentioned also in specific order, a good discussion here

Another useful link here

API Java DOC rerference here

Very useful discussion here if you are getting Nullpointer while trying to update task outcomes obtained using ITaskQueryService here

update-2/june/10
While using the java client code from portal, for a logged in user, we were getting
java.lang.SecurityException: [Security:090398]Invalid Subject: principals=[dasha
02, BusinessUnitController, SoaGroup]
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:234)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef
.java:348)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef
.java:259)
It turned out, the portal server and soa server weblogic domains needed to be enabled for global trust. And it worked by setting same credential at the Domain/Securty/Advanced page.

Weblogic Custom-Authenticator

While creating the SSO solution between weblogic portal server and soa server, we used the OAM/Webgate approach, very well explained here and here.

However we realized that integrating with webgate was not enough, the user has to be authenticate in the weblogic container also, in order that different deployed web applications can use the same container authentication/authorization services.

Interesting posts on this here and here

The options for us was to use SSPI connector to OAM, however we couldn't use that as the enterprise-wide OAM deployment was not supporting it yet.

So the other option was to use weblogic custom identity assertion and authentication. To understand identity assertion good post here

so we got the sample code from here

After making necessary code changes to read our header variable (Please check the readme.pdf to build/deploy the jar), we were ready to go. We didn't use token or cookie decryption and for authentication we used a LDAP authenticator. This is a bit of duplication on authentication but we need the roles/groups that the user belongs. And for creating a LDAP authenticator very good entry here

Next is to build the portal and see how it performs with these users/groups.


update:may17
I had to SSO ruleauthor applictaion which is on SOA10.1.3.4/Weblogic9.2. So easiest way to SSO weblogic applications was to use the Identity assertion. The Default weblogic identity assertion would work fine, only requirement was to use as CLIENT-CERT in the web.xml for the ruleauthor. However I had to do SSO with the OAM/WebGate infrastructure. So as per the OAM policy we configured the ruleauthor URL, and when its accessed through the Apache OAM sends the header variables and obSSOCookie, Using a custom identity asserter built using as described above, we could SSO ruleauthor.