Specifying handler parameters in the PROCESS DEFINITION

[joelkoz]

I've been working with the jBPM 3.1 intetegration code, and I came across an issue. I've submitted a JIRA issue (MOD-115) (http://opensource.atlassian.com/projects/spring/browse/MOD-115), along with patch, but I thought others here may be interested so I'm posting in the forum:

The original purpose of jBPM's "action delegate" functionality was to allow properties in an action handler to be set to values specified in the process definition. The Spring-Jbpm integration takes advantage of this to specify the Spring bean name the JbpmHandler delegates to. However, this moves the "wiring" of action handler properties exclusively to Spring. It is sometimes desireable to allow the PROCESS DEFINITION to specify the values of certain properties of an action handler. This allows, among other things, the creation of reusable handler components, where the process definition specifies certain parameters to handler.

I have created a patch that re-enables the process definition to pass in parameters IN ADDITION to using Spring IoC, giving us the best of both worlds. Spring IoC can be used to wire the handler with infrastructure code (like data access objects, service objects, etc.). The Process Definition can contribute to the handler by specifying certain run-time parameters.

The patch centers around adding an optional <targetProperties> to the action handler definition. An action can now optionally be defined such as this:

<action config-type="bean" class="org.springframework.workflow.jbpm.JbpmHandler">
<beanName>SpringJbpmAction</beanName>
<factoryKey>myFactoryInstance<factoryName>
<targetProperties>
<somePropertyInSpringJbpmAction>the new value for the property</somePropertyInSpringJbpmAction>
<someIntegerProperty>5</someIntegerProperty>
...
</targetProperties>
</action>

The JbpmHandler implements <targetProperties> by passing the contents of <targetProperties> to the jBPM code that normally handles "action delegate" configuration as described in section 16.2.3 of the jBPM docs (http://docs.jboss.com/jbpm/v3/userguide/jpdl.html#configurationofdelegations). Thus, anything that formerly could have been specified for the configuration of an action delegate can now be specified by putting the configuration inside of <targetProperties>

Use of this feature requires that the target handler (in the example, "SpringJbpmAction") NOT be declared as a singleton, since each instance can have a different configuration (that is the whole purpose of the patch!)

[Costin Leau]

Thanks for the patch joelkoz. I had such requests in the past but the feature was not implemented since it is a bit confusing. It is not a good idea to have two engines doing injection of control over the objects.
As you noted, this feature works only if the beans from Spring are prototypes and the injection works only for simple projects. The only advantage that I see is that jbpm process definition can be (re)used - still the configuration of the bean is split between Spring xml and jbpm xml.

[joelkoz]

The only advantage that I see is that jbpm process definition can be (re)used

Umm... Isn't that the whole point of OOP in general? At least, it seems to me that a big goal would be to allow for the reuse of action handlers as much as possible.

the feature was not implemented since it is a bit confusing. It is not a good idea to have two engines doing injection of control over the objects.

I respectfully disagree. For my app, at least, the process definition is actually considered an end-user artifact. So, the way I view it, Spring bean definitions are for programmers to configure as much of the action handler as they can with service objects and such. Seperately the process designer uses the process definition to "configure" the object with the information it needs to carry out its mission. Its not that any one person in a particular role(like a programmer) would arbitrarily put configuration in BOTH/EITHER config files.

Take for example the need for an action to send an email to someone. Say you wanted to have an action handler that would send an email to some address. The Spring configuration certainly couldn't be used to specify the email address. So, perhaps we have the action handler look up the address from some data table. But what if the name of the table is not known when the application is first deployed? One use case would be where the data table(s) in question are dynamically created.

One could create a reusable component that would look up the email address in some data table, with that data table being specified in the process definition. The data SOURCE (or some Dao that is used to lookup the information) could be configured in the Spring beans, but the table NAME may or may not be able to depending on how the app is architected.

There are a variety of other examples I could probably come up with: my specific use case is for the feature was prompted by a way for the process designer to specify which form is to be displayed to the end user for data entry. The action handler that launches the form needs the services of some objects to assist in looking up the data to populate the forms, and those objects ARE configured in Spring. The forms themselves, however, can be dynamically created by the end user, and thus are not known when the app is first deployed.

[Costin Leau]

I agree with your comments Joelkoz, point proven. I will implement the issue as soon as I have some spare time (hopefully sometime in the near future). Thanks again for the feedback.

[chawax]

Hi.

I am very interested with this patch, but it seems it is not compatible with Springmodules 0.8. Did anyone write it for 0.8 release ?

Thanks

Olivier