I've implemented an extensible BPMN parser for Activiti

[iravanchi]

As a part of my project, I needed to extend BPMN parser to support my own activities in the process definition.
I imported a few of the source codes of Activiti into my project and implemented the following solution:

BpmnParser supports multiple xmlns definitions, and each element / attribute is delegated to a handler class depending on its xmlns. Handlers can be added in the BpmnParseListener implementations. So, by implementing custom deployers, a developer can easily extend the activities and BPMN notation.

I refactored the current parser to my new design, and it passes the initial tests. I think it's pretty good support for extensibility. It passed the few tests that I did. For example, I could successfully run the following process:

<definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
          xmlns:activiti="http://activiti.org/bpmn-extensions"
          xmlns:io="http://my/custom/namespace"
             xsi:schemaLocation="http://schema.omg.org/spec/BPMN/2.0 BPMN20.xsd"
             typeLanguage="http://www.w3.org/2001/XMLSchema"
             expressionLanguage="http://www.w3.org/1999/XPath"
             targetNamespace="http://www.activiti.org/bpmn2.0">

   <process id="fileCopyTest" name="File Copy Test">

      <startEvent id="theStart"/>

      <sequenceFlow id="flow1" sourceRef="theStart" targetRef="readFromSource"/>

      <io:readFile id="readFromSource" sourceFile="D:\new.txt" targetVariable="fileContent" />
      
      <sequenceFlow id="flow2" sourceRef="readFromSource" targetRef="writeToTarget" />
      
      <io:writeFile id="writeToTarget" sourceVariable="fileContent" targetFile="D:\new-copied.txt" />

      <sequenceFlow id="flow3" sourceRef="writeToTarget" targetRef="theEnd" />

      <endEvent id="theEnd"/>

   </process>
</definitions>

Now I want to contribute the code to the original project, so that I can give you a hand, and plus if the custom code is included in the JAR files, the maintenance would be easier for me too. I have already created the accounts, and will send the form to you too, but here are a few questions:
1. What's your idea about the whole thing?
2. Do you think that it can be included in the 5.0.rc? or GA? (I think a few other people are waiting for this feature too)
3. I have different coding style setup, and my code will look a bit different. Should I change it, or can you reformat the code to match yours when merging with Trunk?

-Hamed

[iravanchi]

I'm not getting any feedback on this in the forum, or in the email.
Would you let me know if I should follow-up on this or not?
Or let me know what to do about this?

I think if I'm ever going to merge my code with the actual code, the sooner is the better.
Because as the trunk changes, there's more changes to be merged.

-Hamed

[farrukh_najmi]

Hi Hamed,

As a newbie user my opinion may not be of much significance but… FWIW your proposed extensibility features seem to be very desirable from a end-user perspective.

I suspect the dev team is very busy to comment on your proposed idea in the abstract but may be more helpful if you did further due diligence. Here is what I suggest based on experience with other OS projects:

1. Send a signed contributors agreement (Just saw that you already did that):

  http://docs.codehaus.org/pages/viewpage.action?pageId=163872771

2. File an RFE issue in ACT JIRA requesting the features you propose:

  http://jira.codehaus.org/browse/ACT

3. Attach your proposed changes as a patch diff file to the issue and then post an update on this thread with link to the issue

This will hopefully help the dev team be able to understand what your proposal is all about and respond to it.

[iravanchi]

Hi,

Thanks for your comments.

1. Yes, I've sent the signed agreement (scanned version, using email). I'm not sure if I need to send a hard-copy by mail too. And Tom didn't tell me what to do next (I asked him if I need to do anything else)

2. There is already a JIRA issue for this: http://jira.codehaus.org/browse/ACT-178
I will add a comment in the issue now.

3. I've done my changes in the classes in my own project, not in a check-out of the Activiti code.
It will take me some time to do the changes on the Activiti code (for check-in / creating a patch) which I'm totally willing to do.
But since there's no response on this from the team, I'm thinking that creating a branch or replying to a post is much easier that reviewing and pallying a patch (which affects several files). So if they don't have time (or intention) for that, they won't look at my patch either. So why spend the time? If i have heard as much as "Send us a patch" sentence from them, I would have prepared and sent it two weeks ago.

-Hamed

[tombaeyens]

i'm processing my backlog after having been on vacation.  please bear with us for a moment.  sorry for the delay.

from a first incomplete glance, i would be concerned with 1) i don't think your proposal is valid bpmn.  it's not allowed to define custom activities like that.  2) changing and extending the parser would take us a long time to discuss.  then we need to think and agree on how we actually want to build in this extensibility.  that's not a priority for us atm.  the better we understand what you want to do, how and why the easier it is for us to accept a contribution.  and also we need to see how this is generic enough so that it serves the community at large.  hopefully i'll be able to process my backlog soon so that i can look deeper into this proposal

[iravanchi]

I know it's not valid BPMN, but it's the same as what you've done with "activiti:" attributes and elements.
Actually it is possible to exactly separate the Activiti extensions from the pure BPMN in the parser that I've done with simple re-arrangements.

Anyway, let me know what to do, if you're interested.

[frederikherema1]

The activiti-extentions are actually valid BPMN, since the serviceTask's attributes may be extended (with for example activiti:type).

Also, it allows custom elements under the tag '<extensionElements>', like:
<serviceTask id="sendMail" activiti:type="mail">
  <extensionElements>
    <activiti:field activiti:name="from" activiti:string-value="order-shipping@thecompany.com" />
    <activiti:field activiti:name="to" activiti:string-value="${recipient}" />
    <activiti:field activiti:name="subject" activiti:string-value="Your order ${orderId} has been shipped" />
    <activiti:field activiti:name="html">
      <activiti:string>
        <![CDATA[
          <html>
            <body>
              Hello ${male ? 'Mr.' : 'Mrs.' } ${recipientName},<br/><br/>
                
              As of ${now}, your order has been <b>processed and shipped</b>.<br/><br/>
                 
              Kind regards,<br/>
                 
              TheCompany.
            </body>
          </html>
        ]]>
      </activiti:string>
    </activiti:field>     
  </extensionElements>
</serviceTask>               


[farrukh_najmi]

On a related note, as previously discussed on other threads the actviti parser currently supports a small subset of BPMN 2.0:

http://forums.activiti.org/en/viewtopic.php?f=4&t=298

One issue I am encountering is that it does not provide warnings when it encounters unsupportred types leaving users to stumble upon limitations (since they are not documented explicitly anywhere yet).

Also, I am wondering what are the latest plans for BpmnParser to use a set of data binding classes generated from JAXB or Eclipse BPMN2 EMF project. This would be really a great improvement to the robustness and spec coverage within the parser.

[iravanchi]

Let me re-phrase my original message:
I've refactored the BPMN parser inside the activiti that:
* Makes it easier to extend the BPMN coverage in future developments
* Makes it possible to add valid extensions (like Activiti extensions) without the need to modify the original parser code, and in a clean way
* Makes it easy to intercept / override PVM code generation from BPMN
* Makes it possible to incorporate existing BPMN parser for creating new custom languages

What I originally wanted to do was the last one (create my own lang based on BPMN) but I wasn't aware of the explicit extensibility specification in the BPMN spec. I should review the specs to see what is exactly considered valid and what is not valid in BPMN. Maybe I can use the valid extensions and don't need to extend it the way I did.

And I wasn't proposing that my way was the right way. And I also know that my code can be improved. I am expecting discussions and feedback so that I can do the right thing, considering the core developers' experience.

Also, I'm willing to spend time and develop in Activiti, since I already know the engine code to some extent. If the core developers assign tasks to me, I'd be happy to contribute my time.

About warnings on unsupported BPMN elements, I think the current Activiti parser produces warnings on the log output, but I'm not sure. But in my refactored code, each unsupported element inside the scopes, are reported as a WARNING on the log output.

[farrukh_najmi]

About warnings on unsupported BPMN elements, I think the current Activiti parser produces warnings on the log output, but I'm not sure. But in my refactored code, each unsupported element inside the scopes, are reported as a WARNING on the log output.

I just switched to latest trunk bits (5.0.rc1-SNAPSHOT) and I see a lot more warnings now. Thanks dev team!

One missing warning I can spot still is when there is a sendTask in a process. Since sendTask is unsupported in parser AFAIK, I think there should be a warning on its usage.