How do we package workflows to deliver them in phases

[chimu]

We need to deliver multiple BPMN based workflows to a client at different periods. We also plan to give a Task explorer application(similar to Oracle BPM worklist) to the client which will serve as Inbox for all the user tasks. We will be using Activiti, JSF, JEE CDI to build these applications.
Can we deliver workflows as seperate war files(BPMN+ UI +Java classes) such that they work seamlessly with the Task explorer( assuming Task explorer itself will be war file). We are also looking for single login/authentication at the Task explorer level and authorization at workflow level. Do we need any SSO or OSGi concepts to achieve this kind of deployment ??.

If the above approach doesn't looks feasible then what are the alternatives. If we keep a common war file for task-explorer and all the workflows then everytime we need to deliver a new workflow, we will have to remove older deployments from client environment even for the workflows which we haven't changed. And also having a common codebase for totally unrelated workflows doesnt looks correct. Pls suggest.

[jbarrez]

Did you look into the default strategy of Activiti already? This basically boils down to having processes stored in the database. Whenever a new process is deployed to the engine, the old process is 'phased out'. This means that new processes will be started using the newest process and the old running instances keep running in the old on.

Regarding UI there is also a default answer: use form properties embedded into the process bpmn xml, and let your UI technology use those forms to display to the user. That way, whenever you deploy a new process, the ui is also changed.

Is it that what you are looking for?

[chimu]

Nopes, this is not what I am looking for. We are looking to decouple Task-explorer(a.k.a worklist, Inbox) with the workflows such that we are able to add new workflows in the future without disturbing the older deployed workflows. Initially we thought to package them separately as multiple war files but then session sharing and authentication/authorization could become a challenge. Activity repository DB is not the only glue between Task-Explorer and workflows, but to make them work seamlessly they need to communicate via http.  Now keeping in mind that new workflows will keep on adding in the future, how to we design the Task explorer such that it is able to display/communicate/invoke those future workflows. All these workflows have different business logic but they need to authenticate/authorize with single Identity provider(say AD). So once a user is authenticated at task explorer stage, we need to pass the group/roles info to workflows for authorization. If we package all of them in single war file, then we will have to repackage them every time we deliver new workflows. repackaging/redeploying the older running workflows may run into possibility of injecting defects in code which we never intend to change.

[trademak]

Hi,

I think what you are looking for is what you get by default by using the JBoss server.
Camunda fox provides a community edition with an integrated Activiti and JBoss installation (https://app.camunda.com/confluence/display/foxUserGuide/Getting+Started)
That makes it possible to install WARs with a process definition and the corresponding class separately.
And the common Task explorer will be able to see all process definition as they become available.

Best regards,

[chimu]

Hello,
   The task explorer which we are building is highly customized as per clients needs, and we
   might have to upgrade it from time to time as client demands, so we will have to build it ourselves to have full control on its functionality. So we were looking at multiple approaches for packaging the workflows and explorer. Will OSGi help in that case for deploying a work-flow dynamically as a jar bundle or maybe as a war bundle ??

[trademak]

Hi,

It's perfectly fine to build a highly customized task explorer.  Like I said, JBoss provides all the capabilities you are asking for and you can download the Activiti integration easily with the camunda fox community edition.
Then you can install workflows in different WARs. Yes, OSGi would also be a solution to do a similar thing. Activiti provides an OSGi module that easily integrates with for example Apache Karaf. Then you can install processes in different OSGi bundles.

Best regards,

[chimu]

We have chosen non-osgi approach to deploy our workflows as separate war files. As per the documentation of camunda fox tasklist, we need to give a call back URL(as GET parameter) to every open task in the tasklist so that we can redirect to the tasklist once user is done with the task form. Now to build the complete URL of user task, I need to know the formKey(which will have JSF page name) and the context path of the web application which I will be invoking. formkey can be obtained from Java API i.e.  FormService.getTaskFormData(String taskId).getFormKey(). But how do I get the web context path since all I have is a task_Id and the process_definition_id in the tasklist. Do I hardcode the web context path in the formKey itself or there are better ways. Below is the snippet suggested by camunda to build the URL for each tasks in the tasklist :-

"../.." + contextPath (of process application) + "/" + formKey (from BPMN 2.0 XML) + taskFormUrlSuffix (configured in web.xml, default is .jsf) + "?taskId=" + taskId + "&callbackUrl=" + callbackUrl;

[chimu]

Activiti team,
  Pls provide your inputs to the post above. Basically I need to find out the context root of the web-app(.war) which holds the web-page of my user task. The user task is only giving me formKey i.e. the JSP/JSF page, but to invoke that page I need to construct a URL, and to build that URL I need to store context root somewhere in my BPMN file. So what I need is a way to map all my deployed BPMN's to the deployed war's which holds the forms.

[frederikherema1]

What about making the war-file the same as the process-definition key or some arbitrary value that can be deducted from either the process-definotion or task-definition…

[chimu]

Even we thought of doing some hack similar to what you suggested and we also explored the Java docs of Process definition but that is not very convincing. Integrating workflows to tasklist should ideally be a trivial task for a BPM application and shouldn't be a workaround. We want to know what Activiti has to offer to achieve this.