Instant Messaging with Intalio, openESB, GlassFish, PSI and OpenFire XMPP Server

If you are interested in deploying an Instant Messaging component in your Intalio process, read on.  I recently was involved in a project in which a telecommunications company wanted to send instant messaging notifications when certain events where triggered (usually timers).  The architecture that was chosen was using a php script that accepted a post and then relayed the information to XMPP server.  In this scenario OpenFire XMPP server was used. I was only responsible for developing the REST call from within Intalio which was pretty easy and straight forward.  However not being a php developer, I wanted another solution I could use in other environments.

In a previous blog, I noted how I used openESB to create an LDAP web service Intalio could call to query for users and then send email notifications.  I have not been back to openESB in sometime, but I came across their new XMPP Binding Connector (BC).  I read some documentation and figured I could use the same design with XMPP that I did with LDAP.  Create a web service in openESB using NetBeans and then deploy the service to Glassfish Server and let Intalio call the web service.

So, here are the basic components.  Create a project with two WSDLs and one BPEL diagram.  The first WSDL I usually call trigger, since Intalio will call this end point and trigger the invocation of the XMPP WSDL.  The WSDL will be SOAP document literal and just pass in two parameters, jabber id (jid) and message.  The BPEL process will receive the message and then assign the variables for the XMPP WSDL.  Then invoke the XMPP WSDL and you are done.  You have to add the XMPP jar files to openESB but the documentation is on openESB for you to read.

Next take the WSDL for the trigger (SOAP document literal) and put it in your Intalio project.  Also take the schema you had to create for the WSDL and place that in Intalio.  Wire up the WSDL in the intalio mapper, deploy and test.

I installed OpenFire XMPP server locally and used PSI XMPP Client.  Installation and set up is easy.

Any questions, contact me at btmsoftwaresolutions.com.  Any other good XMPP uses in BPM let me know.

Intalio BPM - Intermediate Timers and Task Management

Use Case: Police electronically file a criminal complaint in which a summons is issued and the defendant has not been processed (electronically fingerprinted with LiveScan and Photographed). The Chief law enforcement officer of the jurisdiction wants to be able to track fingerprint compliance to monitor who has and who has not been processed. In the current model, we are able to capture those defendants who have been processed, but have no way of updating the KPI dashboard on fingerprint compliance for those who have not been fingerprinted once the complaint has been electronically filed with the Court.

Proposed Solution: Using BPM, extend the current model to track those defendants not processed and incorporate any rules of criminal procedure within the process that pertain to fingerprinting following the issuance of a summons.

In the diagram below, a message is received after electronically filing a criminal complaint if the defendant was not processed. A task is sent to the officer filing the complaint - 'Fingerprint Pending'. Since the defendant has 5 days to report for processing, an intermediate timer between the creation of the task and the completion of the task is set to 5 days and 1 minute. An intermediate timer placed on the sub process is set to 5 days. If the defendant reports for fingerprinting within the court ordered time frame of 5 days, the officer will complete this task and the Key Performance Indicator (KPI) for the fingerprint compliance dashboard will be updated. However, if 5 days passes and the task is not completed by the officer the following occurs:

1. The task is deleted from the officer's task list. This is accomplished by calling two (2) different services within Intalio - task manager service and token service. In the task manager service, there is an operation called delete and this operation will delete a given task. The delete operation takes two (2) parameters, taskID and participantToken. The taskID is obtained within the process from the create task response message. The participantToken has to be retrieved using the Token Service. The token service takes two parameters, username and password. The administrator account has the authority to delete a task so those values are passed into the service. The response message from the token service provides the participantToken which can be passed into the delete operation. This will then delete the task from the officer's task list.
2. In case the officer forgot to complete this task, and the defendant was fingerprinted, we send an email from the process using an email web service informing the officer that this task was deleted and if the defendant was fingerprinted to contact the District Attorney's office immediately before bail revocation documents are forwarded to the Court.
3. A task is sent to the District Attorney's office informing them that Bail Revocation may be required due to non-compliance with a fingerprint order as a condition of bail. If the DA determines from their own investigation or from the officer that the defendant was processed, they can enter the name of the booking center and the KPI will be updated and reflected in the fingerprint compliance dashboard. If the defendant was not processed, information retrieved from the complaint can pre-populate a bail revocation web form to reduce redundant data entry. Any additional information required may be entered by the District Attorney staff. A pdf of the bail report can be printed from the web form and submitted to court. In the future it is possible that the document be electronically submitted to the court.
4. Finally, the KPI is updated to reflect that a bail revocation has been filed on this defendant.

Below is a diagram of the proposed work flow.

Diagram:

















More info at http://btmsoftwaresolutions.com