Storing meta data for camunda:inputParameters

Developers Modeler
1

Hallo,
I am setting camunda:inputParameter. This is my example output. As you can see, I additional add an own meta-attribute “type”. The problem is that after reloading/reopening via ElementRegistry, the attribute “type” is lost. But I need this meta-data for further actions… Im exporting the xml in an own database table. The “type” attribute is still avaiable in the xml but as said, the ElementRegistry (BusinessObject) is loosing it.

<bpmn:serviceTask id="Task_1u33tcu" camunda:asyncBefore="true" camunda:delegateExpression="${aDelegate}">
	<bpmn:extensionElements>
		<camunda:inputOutput>
			<camunda:inputParameter type="atype" name="akey">${avalue}</camunda:inputParameter>
		</camunda:inputOutput>
		<camunda:properties>
		...
		</camunda:properties>
	</bpmn:extensionElements>
</bpmn:serviceTask>

So what is the best way for storing meta data of input parameters? The plan was like above to set it straight as an attribute cause I easily want to read it.

Now I can do the following:

  • set the meta data as properties. This has the disadvantage that I need to connect it after reading manual with the input parameter (may over the name). Then I have to read/write - both - inputparameters and properties every time.
  • set the value and metadata as a list or hashmap. Problem is that I need to split it later manual in my camunda delegate.
  • set the meta data as described above and read it via xpath or iterate the xml manual. But here I dont know, if this is the right way and if its faster or slower than using the ElementRegistry. I guess that using natual operation with the javascript lib of bpmn is a way better?

May someone have a good advice or can tell me what the best practise is.

Thanks!

2

How are you setting the attribute type? Can you share some code?

3

This is how we create the Input Parameter

var moddle = modeler.get('moddle');
var inputParameter = moddle.create('camunda:InputParameter', {
	type: 'atype',
	name: 'akey',
	value: 'avalue'
});

var inputOutput = moddle.create('camunda:InputOutput', {
	inputParameters: [ inputParameter ]
});

This is how we read the parameters

var elementRegistry = modeler.get( 'elementRegistry' );
var elementRegistryEntry = elementRegistry.get( pElement.element.id );
var elementRegistryEntryBO = elementRegistryEntry.businessObject;
var inputPar = elementRegistryEntryBO.extensionElements.values[0].inputParameters

This is what we expect in JSON (inputPar)

...,{"$type":"camunda:InputOutput","inputParameters":[{"$type":"camunda:InputParameter", "type":"atype", "name":"akey", "value":"avalue"}]}...

This is what we get

...,{"$type":"camunda:InputOutput","inputParameters":[{"$type":"camunda:InputParameter", "name":"akey", "value":"avalue"}]}...
4

Where are you adding the created elements to the business object?

5

We use two ways.

Adding the first parameter by:

var extensionElements = moddle.create( 'bpmn:ExtensionElements', {
 	values: [ inputOutput ]
} );
				
elementRegistryEntryBO.extensionElements = extensionElements;
				
modeler.get( 'modeling' ).updateProperties( elementRegistryEntry, { 
 	extensionElements: extensionElements 
} );

Adding more parameter, if at least one exists…

elementRegistryEntryBO.extensionElements.get( 'values').push( inputOutput );
8

I’d advice you to add your own attributes under your own namespace to avoid collisions with the Camunda Namespace. The meta-model of Camunda is well defined, adding extensions to it is not easily possible outside your own namespace. This is due to the nature of XML and defined extension mechanisms that we enforce.

That said, what you need to end up is something like this:

<bpmn:definitions ... xmlns:mycompany="http://mycompa.ny/ns/camunda">
  ...
  <bpmn:serviceTask id="Task_1u33tcu" camunda:asyncBefore="true" camunda:delegateExpression="${aDelegate}">
    <bpmn:extensionElements>
      <camunda:inputOutput>
        <camunda:inputParameter mycompany:type="atype" name="akey">${avalue}</camunda:inputParameter>
      </camunda:inputOutput>
    </bpmn:extensionElements>
  </bpmn:serviceTask>
</bpmn:definitions>

Because of the fact that the type attribute is unknown (and invalid) in the camunda schema it is added to the el.$attrs holder for generic / unknown properties instead.

You may verify that post import:

bo.$attrs; // { type: 'BAR' }

In the future we’ll improve the model validation to warn if you try to monkey-patch your extension into well-known namespace attributes (cf. moddle-xml issue).

1 Like
9

plz do you have the full code ?