BPMN-XML-File versa the Oryx-File

[wir33658]

Hi, a question on the two stored files from the Signavio-Modeler.

The modeler creates two files

- a …bpmn20.xml - file and
- a …oryx.xml - file.

As much as I can see from your source-code. You're only using the …bpmn20.xml - file. If I add some constraints on some edges from a gateway-node, they only will show up in the …oryx.xml - file, but not in the …bpmn20.xml - file. How do you handle those constaints in the engine if this is not read ?

I am confused. Maybe you can help me out. Thanks.

Cheers, Rob.

[wir33658]

Went back to this one and simply started a new diagram, setting the edges right away being conditional, stored it and its there (in the bpmn-file).

Going back to my first diagram (where my first entry in this post derived from) fouling around with the edges, but nothing helps to make it show up in the bpmn-file (its only in the oryx-file).

Looks like there is a bug in the modeler.

P.S. The edges in the first diagram I stored them first as "standard" and not "conditional" and changed it later on. Maybe that helps.

[jbarrez]

What do you mean with constraints on the sequence flow?

Because, as far as I remember, adding conditions to the sequence flow are added to the bpmn20.xml file, which is the only file that is used by the Activiti engine.

Could indeed be that there is a bug when you store them first as standard and later change them to conditional. I'll verify it.

[jbarrez]

I just verified what you said, and indeed it's a bug. The conditions on the sequence flow are not saved to the bpmn 20 file if you add them to an existing model.

I created a Jira issue for it to fix it: http://jira.codehaus.org/browse/ACT-57

[chrisadam12]

BPMN is a quite young notation for expressing business processes as it were first introduced in 2002. However, it is already widely accepted among modeling experts and several tool supporting this notation were introduced in the last years. Therefore the need of a standardized interchange format emerged. A possible candidate for this purpose is the XML Process Definition Language (XPDL). The current version 2.1 is capable of representing all constructs of BPMN 1.1 respectively BPMN 1.2.

Architecture

The XPDL export/import functionality of Oryx is implemented in Java as a server-side plug-in. The user accesses it via a client-side JavaScript? plug-in which only handles the data transfer. Figure 1 shows an overview of the architecture and the mentioned plug-ins.


The basic architecture underlying import/export in Oryx.
Implementation

But now we are going to inspect the interesting parts – what is under the hood of the XPDL plug-in. Every tag of the exported language needs to have its own class in the Java project. The member of this class map to the according attributes, content or children of this tag and their appearance can be specified by adding Java annotations to the declaration. E.g.:

@RootElement("WikiTag")
public class WikiTag extends XMLConvertible {

  @Attribute("IsVisible")
  private boolean isVisible;

  @Text
  private String content;

  @Element("ReferenceLink")
  private ArrayList<String> referenceLink;
}
This is already enough to export an object of this class to XML. A programmer can do this by executing this code:

WikiTag newWikiTag = new WikiTag();
StringWriter writer = new StringWriter();

Xmappr xmappr = new Xmappr(WikiTag.class);
xmappr.setPrettyPrint(true);
xmappr.toXML(newWikiTag, writer);
     
System.out.println(writer.toString());
As you may noticed the WikiTag-class extends the XMLConvertible-class. This is NOT necessary but highly recommended as it already supports the parsing/writing of JSON-objects as wells as the mapping of unknown attributes and children to generic container classes. In fact this is also the reason why every XPDL-tag needs to have its own class in the project as it is the only way to remap unknown attributes and/or children. The functionality for this is encapsulated in the XML-Convertible class in the methods writeUnknowns() respectively readUnknowns(). A programmer just needs to invoke this method with the key from where to read or where to write the unknowns elements. Currently the implementation of the XML-Convertible uses the Java object serialization mechanism in combination with a Base64 encoding. Considering this only Java programs are able to modify the “unknowns”.

Dependencies

org.json library (already present)
org.xmappr v. 0.9.2. (introduced, customized in the way that DomElement is serializable)
Resources

XPDL at the WFMC (general information, examples, specification)
BPMN at the OMG (general information, specification)
BPMN 1.2 Poster





_____________________________________________________




Want to get-on Google's first page and loads of traffic to your website? Hire a SEO specialist from Ocean Groups seo specialist