Populating in/out parameters using CallActivityParseHandler

[gokceng1]

Hello,
Till this day, I've used parse handlers to assign listeners to the different types of activities. I've tried to add some io parameters to a call activity while parsing:

@Override
protected void executeParse(BpmnParse bpmnParse, CallActivity callActivity) {
   super.executeParse(bpmnParse, callActivity);
   initInOutParameters(callActivity);
}
‍‍‍‍‍‍‍

The code above is ok. I saw the inParameters list populated. But in DefaultActivityBehaviorFactory.java class, the parameter of createCallActivityBehavior method doesn't have any ioParameter in it. Because, this method(createCallActivityBehavior) is called beforehand(by the super). When I've populated the io parameters, it has already assigned the io parameters.
What I want to ask is, do I need to change my approach and by-pass super call and do whatever super does. Like this:

@Override
protected void executeParse(BpmnParse bpmnParse, CallActivity callActivity) {
   //super.executeParse(bpmnParse, callActivity);
   ActivityImpl activity = createActivityOnCurrentScope(bpmnParse, callActivity, BpmnXMLConstants.ELEMENT_CALL_ACTIVITY);
   activity.setScope(true);
   initInOutParameters(callActivity);
   activity.setActivityBehavior(bpmnParse.getActivityBehaviorFactory().createCallActivityBehavior(callActivity));
}
‍‍‍‍‍‍‍‍‍‍

What do you think about this? How can I solve this because this is not a good solution I think. I need to have a hook for this, like a postParse method.

[jbarrez]

What you could do alternatively, is override the default parse handler

see http://activiti.org/userguide/index.html#advanced_parseHandlers

<code>
It is possible (but less common) to replace the default BpmnParseHandler instances that are responsible for the parsing of the BPMN 2.0 elements to the internal Activiti model. This can be done by following snippet of logic:

<property name="customDefaultBpmnParseHandlers">
  <list>
    …
  </list>
</property>        
</code>

This effectively allows you to replace the default parse handler with your own. Which, if I understand your use case, is probably what you want/need.

[gokceng1]

Hi Joram,
In fact I'm following that path currently:


public class CallActivityParseHandler extends org.activiti.engine.impl.bpmn.parser.handler.CallActivityParseHandler {
…
@Override
protected void executeParse(BpmnParse bpmnParse, CallActivity callActivity) {
  super.executeParse(bpmnParse, callActivity);
  initInOutParameters(callActivity);
}
}
…


<bean id="parserProcessEngineConfiguration" parent="mailDisabledProcessEngineConfiguration">
<property name="customDefaultBpmnParseHandlers">
  <list>
   <bean class="my.pkg.CallActivityParseHandler">
   </bean>
  </list>
</property>
</bean>

Though this is not working for me. because super.executeParse(bpmnParse, callActivity); populates the io parameters beforehand.   Even I update/create io paramaters in initInOutParameters(callActivity);, they aren't reflected to the CallActivityBehavior's dataInputAssociations.

What do you think?

[jbarrez]

I'm still not 100% sure if I understand you correctly.

But the code for call activity parse handler is this:

<code>
  protected void executeParse(BpmnParse bpmnParse, CallActivity callActivity) {
   
    ActivityImpl activity = createActivityOnCurrentScope(bpmnParse, callActivity, BpmnXMLConstants.ELEMENT_CALL_ACTIVITY);
    activity.setScope(true);
    activity.setActivityBehavior(bpmnParse.getActivityBehaviorFactory().createCallActivityBehavior(callActivity));
  }
</code>

Isn't it easier to just copy paste that in your custom one, store the result of the

<code>
bpmnParse.getActivityBehaviorFactory().createCallActivityBehavior(callActivity)
</code>

locally and do the adjustments?

Other angle to this problem might be both customizing the parse handler and the activityBehaviourFactory.

[gokceng1]

Hi Joram,
Thank you for reply. I did it just like you said. It is working now. The thing that I don't like is being on guard against changes that can happen in next versions. If you change the internal mechanism, I will have to update it accordingly.
The problem is solved on my side but you may think the custom bpmn parse handlers for your next versions.

Thank you again.

[jbarrez]

You are correct. Altough i don't see yet how that could be done generically and easily … yet