Thursday, 15 November 2007
Learn a new thing every day .....
I've spent an interesting few days getting to grips with WebSphere Integration Developer and WebSphere Process Server, in the context of Human Tasks.
Currently, we have two or three options: -
Sadly, I was not able to get the Human Task models/builders to work, most likely because: -
a) WebSphere Portal ( on which the models were being executed ) was secured against WMM/DB2, whereas WebSphere Process Server was secured against a Custom User Registry ( using property files )
b) A classpath conflict due to the fact that I was using WebSphere Portal Express 6.1 beta
When I get some free time ( in the next week or two ), I'm going to rebuild my demonstration environment and configure both WebSphere Portal and WebSphere Process Server against the same LDAP, in order that I can achieve single sign-on between the two environments using LTPA ( alternatively, I may install WebSphere Portal onto WebSphere Process Server - giving me one JVM rather than two ).
On a related note, I'm also going to explore the beta of WebSphere Integration Developer 6.1, as I'm keen to look at the Lotus Forms integration options - as far as I can establish, that'd allow me to generate a XForms/XFDL user interface, alongside the existing JSF and WSDL/XSD interfaces.
I've already been exploring a demonstration built by my colleagues that shows a form initiating a Human Task, against via WSDL. This mostly works, although the Lotus Forms Viewer does generate an error or two.
More to come ..............
Currently, we have two or three options: -
- Use the oob My Tasks portlet - this only works if WebSphere Portal can automatically authenticate to WebSphere Process Server e.g. if they are sharing the same LDAP, or if Portal is running on Process Server.
The portlet allows the SCA endpoints to be defined against a remote Process Server instance, but doesn't provide inputs for user ID / password or Credential Vault. - Use WebSphere Portlet Factory's web services builders to initiate a new Human Task, using a (currently alpha) plugin to WebSphere Integration Developer to export the WSDL and XSD files from an exported Human Task
- Use WebSphere Portlet Factory and a set of (currently alpha) models/builders to interact with WebSphere Process Server at the SCA layer, allowing portlets to initiate AND consume Human Tasks
Sadly, I was not able to get the Human Task models/builders to work, most likely because: -
a) WebSphere Portal ( on which the models were being executed ) was secured against WMM/DB2, whereas WebSphere Process Server was secured against a Custom User Registry ( using property files )
b) A classpath conflict due to the fact that I was using WebSphere Portal Express 6.1 beta
When I get some free time ( in the next week or two ), I'm going to rebuild my demonstration environment and configure both WebSphere Portal and WebSphere Process Server against the same LDAP, in order that I can achieve single sign-on between the two environments using LTPA ( alternatively, I may install WebSphere Portal onto WebSphere Process Server - giving me one JVM rather than two ).
On a related note, I'm also going to explore the beta of WebSphere Integration Developer 6.1, as I'm keen to look at the Lotus Forms integration options - as far as I can establish, that'd allow me to generate a XForms/XFDL user interface, alongside the existing JSF and WSDL/XSD interfaces.
I've already been exploring a demonstration built by my colleagues that shows a form initiating a Human Task, against via WSDL. This mostly works, although the Lotus Forms Viewer does generate an error or two.
More to come ..............
Subscribe to Posts [Atom]