Custom service task type, loaded through Java SPI

[cdeneux]

Hi all,

I'm working on the contribution mentionned here: http://forums.activiti.org/content/how-extend-activiti-my-own-service-task-implementation.

I have successfully updated the engine. I do the same thing for the send task type. And it works fine with Mule, Camel and Shell service task and send task types.

Now, trying to use my own service task type, I have an error on validation of the process definition because of unknown service task type. Indeed, an XSD model defines the values accepted by 'activti:type'.
Can I remove the enumeration of 'activti:type', so it becomes a simple xsd:string, or is it used by other components for generation as the Eclipse Designer ?
I saw several model resources in 'org/activiti/impl/bpmn/parser' of the project activiti-bpmn-converter. Can you explain how the different versions are used ? Should I create a version 5.17.0 of 'activiti-bpmn-extensions' ?

Thanks for your help,
Christophe

[jbarrez]

> Should I create a version 5.17.0 of 'activiti-bpmn-extensions' ?

If the type is enumerated, yes. It's nice for users to be able to select it if they want.

However, that XSD isnt used when using the engine itself. Where did you get the exception?

[cdeneux]

Hi,

Please find below the stack trace where the exception occurs. It's when validating the process definition. FYI the service task 'archiverLaDemandeService' is declared as following:

<serviceTask id="archiverLaDemandeService"
                name="Petals service invocation #1"
                activiti:type="petals">
      <extensionElements>
         <activiti:field name="interfaceName">
            <activiti:string>{http://petals.ow2.org/samples/se-bpmn/archivageService}archivage</activiti:string>
         </activiti:field>
         …
      </extensionElements>
</serviceTask>

The error is expected because 'petals' is not a valid value for 'activiti:type'. 'petals' is my own implementation of a service task type loaded through java SPI. If I disable the validation on deployment, this error disappear.
To be able to propose to few expert users/projects to write their own service task type implementation, 'activiti:type' should be defined as a simple 'xsd:string' without enumeration constraint.

——–


GRAVE: Service Unit 'BpmnComponentTest' failed to deploy
org.activiti.engine.ActivitiException: Errors while parsing:
[Validation set: 'activiti-executable-process' | Problem: 'activiti-servicetask-invalid-type'] : Invalid or unsupported service task type - [Extra info : processDefinitionId = vacationRequest | processDefinitionName = Vacation request |  | id = archiverLaDemandeService |  | activityName = Petals service invocation #1 | ] ( line: 83, column: 4)
at org.activiti.engine.impl.bpmn.parser.BpmnParse.execute(BpmnParse.java:215)
at org.activiti.engine.impl.bpmn.deployer.BpmnDeployer.deploy(BpmnDeployer.java:112)
at org.activiti.engine.impl.persistence.deploy.DeploymentManager.deploy(DeploymentManager.java:50)
at org.activiti.engine.impl.cmd.DeployCmd.execute(DeployCmd.java:106)
at org.activiti.engine.impl.cmd.DeployCmd.execute(DeployCmd.java:1)
at org.activiti.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:24)
at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:57)
at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:31)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:40)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:35)
at org.activiti.engine.impl.RepositoryServiceImpl.deploy(RepositoryServiceImpl.java:78)
at org.activiti.engine.impl.repository.DeploymentBuilderImpl.deploy(DeploymentBuilderImpl.java:156)
at org.ow2.petals.activitibpmn.ActivitiSuManager.deployBpmnModels(ActivitiSuManager.java:431)
at org.ow2.petals.activitibpmn.ActivitiSuManager.doDeploy(ActivitiSuManager.java:143)


[jbarrez]

Well, yes and no. I do see your use case. But I don't think custom service tasks need the type.

The activiti:type is just a shorthand for the activiti:class anyway, so why would users need that, instead of using the class approach directly?

[cdeneux]

You are right, I think that the 'activiti:type' is not the right approach. Perhaps can you help me to choose the best one? I'm also investigating a way similar to 'implementation="##WebService"'.

My goal is to be able to invoke natively Petals ESB services from Activiti. A Petals ESB service is similar to a web-service but without the SOAP layer, requests and replies are XML messages, not Java beans.

On the same model as 'activiti:type', I think to implement a dynamically load of 'implementation' based on Java SPI. Now, only '##WebService' should be loaded like this. So, I can write another implementation value: 'implementation=##PetalsService' that can be run into an Activiti running in Petals ESB. I think that the same validation problem should occurs because of the enumeration defined for "tImplementation" in Semantic.xsd.

What do you think about this ?

Thanks again for your help.
Christophe

[cdeneux]

I have just discovered that the implementation of SyncWebServiceClientFactory could be configured at process engine configuration level. So, if I write my own implementation of SyncWebServiceClientFactory, I will be able to invoke my Petals services as '##WebService'.

I think that this is the best way. Moreover, the process definitions will be more portable. They can be deployed to use real web-services or to use Petals services. Only the configuration of the process engine will be to update, and put the right JARs in the classpath.

Note: The process engine configuration must be completed to be able to set the implementation of SyncWebServiceClientFactory to use.