nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

BpmnParser is not extensible

cstettler

Extending the default BpmnParser (e.g. for handling custom XML elements / attributes) is currently not possible (as of beta 1) as the underlying BpmnParse class has package/default visibility only. Extending the parser is often the only mean to introduce custom behaviour or values, e.g. if one wants to create a custom activiti or activiti behavior for a certain BPMN element.

I think providing support for extending the parsing mechanism is crucial. Minimum would be to allow developers to provide custom implementations, nicer would be a way to register a kind of parse handlers for specific elements in a specific namespace and to override parse handlers for default element types.

What do you think is the right approach to follow here?

Thank you & regards,
Christian

Find more posts tagged with

Comments

cstettler

Addendum: also, the BpmnParser instance gets created "inline" in the BpmnDeployer.configurationCompleted() method without any factory/hook method to create and return one's custom BpmnParser implementation.

I think as a test, it would be useful to have an "end-to-end" sample for replacing a specific activity implementation (e.g. create and return a custom UserTaskActivity for the userTask element) that would proof and "secure" extensibility.

jbarrez

I created http://jira.codehaus.org/browse/ACT-178 for this.

falko_menge

The ServiceTask already allows the use of custom ActivitiBehavior implementations, which can at least provide a custom outgoing behavior.

Another option for dealing with custom elements is to transform them into standard BPMN elements using Activiti Cycle. This approach has the advantage that it doesn't require much knowledge of engine internals and is therefore less error-prone.

cstettler

@Falko: this sounds a bit like building a custom DSL based on BPMN 2.0 elements which is a really interesting thing for non-BPMN-experienced people. Does Activiti Cycle provide support for creating such custom elements and for mapping those to BPMN 2.0 standard elements? And if so, is this mechanism extensible?

Having a development process that starts with custom elements in Activiti Modeler and then uses Activiti Cycle to transform those custom elements to standard BPMN 2.0 would definitely be a sound thing.

Nevertheless, having the possibility to extend/customize the parsing process is still a major requirement on our side, also because there is no longer a built-in mechanism for firing events via a process event bus for certain events (e.g. like whenever a task gets created or assigned).

falko_menge

@Falko: this sounds a bit like building a custom DSL based on BPMN 2.0 elements which is a really interesting thing for non-BPMN-experienced people. Does Activiti Cycle provide support for creating such custom elements and for mapping those to BPMN 2.0 standard elements? And if so, is this mechanism extensible?

Many of our customers asked for some kind of custom language elements and technically the Activiti Modeler supports extensions to existing stencil sets. However, the BPMN 2.0 XML export, which transforms the JSON representation internally used by the Activiti Modeler into XML, does not support such extensions. Therefore, Activiti Cycle contains a framework for performing transformations directly on the JSON model as demonstrated by the developer-friendly BPMN 2.0 transformation. These transformations are highly extensible to allow all kinds of project-specific customizations.

iravanchi

I've refactored the BPMN parser into an extensible one, and will contribute it to the project, if the leaders like it, in the next week.
It will be in a branch at first, probably, but I'm not sure how long will it take to be merged with the Trunk.