topic Re: Extending Activiti with Custom Properties in Alfresco Archive

Extending Activiti with Custom Properties

rhafner — Tue, 04 Nov 2014 14:08:29 GMT

We are migrating from a (non-bpmn) proprietary workflow system which support "attributes" on various workflow objects such as UserTask, SequenceFlow, and DataObject. The attributes are classified in to two types: mutable and immutable. Mutable attributes are key/value pairs that can be modified on a

Re: Extending Activiti with Custom Properties

rhafner — Tue, 04 Nov 2014 14:11:16 GMT

Forgot code tag around bpmn snippet for item 1. Adding again.

<code>
<userTask id="usertask1" name="Task A">
        <extensionElements>
            <xyz:attributes>
                <xyz:attribute xyz:id="1" xyz:name="Attr1" xyz:value="1" />
                <xyz:attribute xyz:id="2" xyz:name="Attr2" xyz:value="2" />
            </xyz:attributes>
            <xyz:i18ln>
                <xyz:labeledEntityIdForName xyz:entityID="6c7826fb-effd-45c2-8097-2bb59e7ba8b9" xyz:defaultlocale="en">
                    <xyz:locale xyz:name="en">leifn-1</xyz:locale>
                    <xyz:locale xyz:name="it">itleifn-1</xyz:locale>
                </xyz:labeledEntityIdForName>
                <xyz:labeledEntityIdForDescription xyz:entityID="f8a34a02-5d57-4a7d-90bb-1116f4304b97" xyz:defaultlocale="en">
                    <xyz:locale xyz:name="en">leifd-1</xyz:locale>
                    <xyz:locale xyz:name="it">itleifd-1</xyz:locale>
                </xyz:labeledEntityIdForDescription>
            </xyz:i18ln>
            <xyz:resourceBundleKeyForName>rbkfn-1</xyz:resourceBundleKeyForName>
            <xyz:resourceBundleKeyForDescription>rbkfd-1</xyz:resourceBundleKeyForDescription>
        </extensionElements>
    </userTask>
</code>

Re: Extending Activiti with Custom Properties

jbarrez — Wed, 05 Nov 2014 12:31:05 GMT

Wow - that's a lot of text

Personally, I would go for Spring transaction management and jdbc / hibernate for your custom stuff to let the transactions behave properly.

"1) Can extension code invoke DbSqlSession.flush()? Should it in this case?"

It could. You can get the current DbSqlSession, but I'm not sure if this would have consequences which you cannot see yet now.

"2) Is there a way to hook the Custom MyBatis Mapper into flush lifecycle of DbSqlSession?"

Yes, you can, you can always do Context.getCurrentXXX to get to those things. But im not sure if it's a good idea.

"1) Are there any concerns with defining foreign key constraints between Activiti tables and custom Extension tables?"

It can only go wrong if you don't delete your stuff before activiti stuff is deleted.

"2) Is Option 3 the recommended path for implementing extensions that need referential integrity with Activiti tables? Due to the optimizations made in DbSqlSession which eliminates the need to execute statements that insert and delete a PersistentObject with the same id I don’t see another alternative for the reason stated earlier."

It would for sure fit nicely, but it also does mean you are very dependent on Activiti internal code. Which in theory, will not change that much, but it could happen of course.

Why the need for 'real' foreign keys? Isn't a 'soft' reference enough?

Re: Extending Activiti with Custom Properties

rhafner — Wed, 05 Nov 2014 13:18:40 GMT

Thanks for the quick response! I wasn't expecting one so fast since the thread is quite lengthy .

This morning I tracked down the cause of the referential integrity issue I'm seeing with Option 3. For reference here is the behavior:

1) Start Process Instance.
2) Modeled DataObjects and our Extension Attributes are initialized. (put in DbSqlSession.insertedObjects but not flushed).
3) Our Service Task runs and updates the value of one of the Modeled DataObjects but not its attributes. This results in a call to VariableScopeImpl.updateVariables() which performs a VariableInstanceEntity.touch() call on the updated VariableInstanceEntity. The touch call removes the existing VariableInstanceEntity from the insertedObjects list and appends it to the end of the list. This results in the VariableInstanceEntity being after our custom extension (VariableAttributeEntity) entry which results in the constraint violation.

It's unclear to me why the touch call reorders the updated VariableInstanceEntity in the insertedObjects list. Can you explain why the reordering occurs?

For now, I have been able to workaround this issue by calling touch on the attributes after the VariableInstanceEntity has been updated to correct the order.

I don't see any choice but to be very dependent on the Activiti internal code due to the insert/delete optimizations that occur in the DbSqlSession flush method (assuming we choose to use referential integrity).

We are still evaluating whether we want to use referential integrity at the moment. For now we are attempting to use it to ensure our extension attributes are cleaned up when the related activiti object no longer exists since we have run into cases where the attributes were not being cleaned up and our tests were still passing.

Re: Extending Activiti with Custom Properties

jbarrez — Mon, 10 Nov 2014 10:28:16 GMT

I think the reorder happens for exactly the problem you state: referential constraints, if a change was made to that object we put it at the end of the list so we are sure any dependent objects are inserted before.