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.

ServiceTask discrepancy in Designer & Modeler

m2spring · 2013-01-26T02:14:47+00:00

Designer generates my ServiceTask as launchee …

m2spring

Designer generates my ServiceTask as

    <serviceTask id="jtID" name="jenkins task" activiti:extensionId="com.cisco.step.jenkins.plugins.jenkow.designer.JenkinsTask">
      <extensionElements>
        <activiti:field name="jobName">
          <activiti:string>launchee</activiti:string>
        </activiti:field>
        <activiti:field name="isManualJobLaunchMode">
          <activiti:string>false</activiti:string>
        </activiti:field>
      </extensionElements>
    </serviceTask>
‍‍‍‍‍‍‍‍‍‍‍‍

Modeler generates it as

    <serviceTask id="jtID" name="jenkins task" activiti:exclusive="false" activiti:class="com.cisco.step.jenkins.plugins.jenkow.JenkinsTaskDelegate">
      <documentation>docs</documentation>
      <extensionElements>
        <activiti:field name="jobName" stringValue="launchee"></activiti:field>
        <activiti:field name="isManualJobLaunchMode" stringValue="true"></activiti:field>
      </extensionElements>
    </serviceTask>
‍‍‍‍‍‍‍‍‍

Note the difference how the values of the extension fields are encoded.
Designer does child elements, Modeler does attributes.
Is this a problem?

The additional 'exclusive' attribute on the serviceTask element on the Modeler side I haven't chased down yet.
Might have something to do how I extended Modeler.

-Max

Find more posts tagged with

Comments

ronald_van_kuij

Is this a problem?

Have you tried to see if it makes a difference?

tiesebarrell

I don't think this makes a difference. Actually, the userguide states (here: http://activiti.org/userguide/index.html#serviceTaskFieldInjection😞

"Alternatively, for longs texts (e.g. an inline e-mail) the 'activiti:string' sub element can be used…"

For what it's worth, please note that the classes generated in the XML refer to two entirely different things. The activiti:extensionId attribute is the id of the extension to the default service task you are using. This is the fully qualified name of the class for the extension. The activiti:class attribute refers to the Delegate class that is instantiated and invoked when the process reaches the service task in the runtime.

m2spring

Thanks for the pointer to the userguide. This clarifies a lot.

I'll be looking more into the discrepancy of the activiti:extensionId vs. activiti:class.
Interestingly, the Designer-generated XML does work as intended.

I'm currently working in adding the same extension (a "Jenkins Task" type) into Modeler.
I feel I'm pretty close.

Unfortunately, Modeler doesn't seem to have a generic extension mechanism.
So, I'm basically adding what I need into the source code.
I'll probably ship my own Modeler with my Jenkins plugin.
Maybe once I understand all what's needed I will think about adding an extension mechanism which I then would contribute back to Modeler.

-Max

trademak

Hi Max,

When we release a new version of the Activiti Modeler the generated XML will be exactly the same as the Activiti Designer 5.11.2 version.
They use the same library (activiti-bpmn-converter) to generate the XML now.
There's the wish to also add a similar plugin mechanism for the Activiti Modeler, but if we are able to add it to the 5.12 release I'm not sure.

Best regards,