Best practices for designing business process

[soaguy]

Hello folks,
                I am new to Activiti and I have installed v5.18. I have some specific question around how to accomplish certain things in Activiti.

1. Is it a best practice to declare Spring beans and use them as global variables to pass around in the context of a process?
2. How do I gain visibility into what gets passed around (like for e.g. auditing trail) for an object from the explorer? This is valuable for supporting the processes from a production standpoint. Do I need to convert objects to xml model and make them available from the explorer to accomplish this?
3. Once an instance in completed, there is no visibility into the variables. Is that something that can be turned on/off?
4. For making an integration using REST, SOAP, JMS etc, the java delegate service task must be used I guess. With every integration comes the transformation effort to map to target format the request/response.  How is this accomplished? Is java XSLT api approach preferred over java binding approach?
5. What is the standard practice to pass data from parent BP to a standalone BP? Like lots of data. It is cumbersome to declare input/output parameters for all data that needs to be passed.
6. How do I handle faults in a more generic manner at engine level (not the process-centric error handling) i.e. can i catch the faults at engine level and then bubble to a process instance which raised it in the first place?
7.  How do I externalize artifacts that might be environment specific? For e.g. xsd, external wsdl etc. I guess you can always serve them up as http resource from a directory. Is there a better approach?
8. We have huge investment in XML based workflow (Oracle Fusion) and have lots of wsdls, xsds, XSLTs etc.  How best can we leverage that with Activiti which seems to be very java-centric?

Like I said, I am new, so please forgive me if I misstated anything.
Keep up the good work…
Thanks much
Clint

[pmsevestre]

Hi,

I´ve been using Activiti for about three year now in a couple of systems that now have around 20 processes.
The answers I´ll give below are solely my thoughts based on that experience, so you should _not_ take them
as anywhere close as a "best practice".

1. Is it a best practice to declare Spring beans and use them as global variables to pass around in the context of a process?

I would try to avoid that. Each bean you use creates a runtime dependency and this can quickly create maintanainbility problems
as you process definitions are updated. In my case, I´ve settled for a just a very small number of spring beans that
are not process-specific and are used only for


2. How do I gain visibility into what gets passed around (like for e.g. auditing trail) for an object from the explorer?
This is valuable for supporting the processes from a production standpoint. Do I need to convert objects to xml model
and make them available from the explorer to accomplish this?

While you don´t _need_ to do this, I would strongly recommend that you use XML or JSON as the stanrdard serialization
method for complex datatypes. Activiti provides extension points that make this conversion transparent to process-level
code. Check the javadocs on custom form types and custom variable types for more information on that.

3. Once an instance in completed, there is no visibility into the variables. Is that something that can be turned on/off?

This is not correct. If you use default settings, the final values for process variables are available for
querying through the java and REST apis. If you change the audit level for the engine, you´ll also be able to query
for all variable value changes too. Please check the javadocs for the HistoricVariableInstanceQuery interface for more
details on this topic.

4. For making an integration using REST, SOAP, JMS etc, the java delegate service task must be used I guess.
With every integration comes the transformation effort to map to target format the request/response. How is this accomplished?
Is java XSLT api approach preferred over java binding approach?

In my case, I´ve settled for the given practice:

1. All integration tasks are modeled by "system tasks"
2. All system tasks use an "activiti expression" that invokes a helper spring bean which, in turn, delegates the execution
   to a Groovy script.
 
Since the second step is always the same, I´m looking forward to simplify this by adding the appropriate invocation logic
at deploy time and adoptiong a convention-over-configuration approach (eg: a system task called "LookpCustomerData" would automatically
call a Groovy script called LookpCustomerData.groovy)

As for the mapping effort, I´ve also stablished that all integrations must go through an ESB (WSO2´s ESB in my case), which is in charge
for all data conversion tasks.


5. What is the standard practice to pass data from parent BP to a standalone BP? Like lots of data. It is cumbersome to declare
input/output parameters for all data that needs to be passed.

You can pass complex structures as input/output parameters, which make calling subprocesses less cumbersome. If you use JSON and/or
XML data types this becomes quite easy to do but you must take into account that you may run into versioning issues. Eg, you may have
a "customer" variable that is a complex datatype (meaning one with many fields and collections). If at some point you decide to add new
fields to this structure, then the receiving process must be able to handle this. The problem is that you may have to support both
versions, since older process instances have an associated customer instance that was created before your change.


6. How do I handle faults in a more generic manner at engine level (not the process-centric error handling) i.e.
   can i catch the faults at engine level and then bubble to a process instance which raised it in the first place?
 
In Activiti there are two types of faults:

a) Exceptions that inherit from BpmnError: those are handled as process exceptions and receive an special handling see Activiti´s guide for a detailed explanation).
 
b) Other exceptions (eg: runtime errors due to a backend service that is unavailable): Those will bubble up to the caller or will end up as a "failed job", depending on the way you´ve set the "asynchronous" flag on BPMN elements that are part of the particular trail of activities that preceded the point where the exception was thrown.
 
In general, what I´ve been doing is to define all system tasks as "asynchronous" so, in the event of an error,
I can retry the failed activity later. In order to to that, I use the ManagementService interface which allow you to query for failed
jobs and resubmit them.

 
7. How do I externalize artifacts that might be environment specific? For e.g. xsd, external wsdl etc.
   I guess you can always serve them up as http resource from a directory. Is there a better approach?
 
Not much to say here. In my case I only use this kind of artifact in the ESB, which provided its own repository.

8. We have huge investment in XML based workflow (Oracle Fusion) and have lots of wsdls, xsds, XSLTs etc. How best can we leverage
that with Activiti which seems to be very java-centric?

I think you can reuse much of those artifacts, as long as they´re related to services consumed my a given workflow. Activiti supports
calling web-services (see Web Service Task), but tooling support for that is weak. Im my case, I´ve found that doing the required calls
in Groovy is quite simple, so I´m sticking with that approach for now.