JpdlXmlWriter bug?

[fmuhlenberg]

After creating and loading a process definition that contains
a task-node which includes a task, the method

JpdlXmlWriter.toString( procDef )

returns XML that doesn't contain all the elements in the
loaded process definition. Specifically, it drops the
< task > elements.

I also see that it drops < swimlane > elements too.

Am I crazy or is this the way it's supposed to work?


For example:

I load this process definition,


<?xml version="1.0" encoding="UTF-8"?>

<process-definition
xmlns="http://jbpm.org/3/jpdl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jbpm.org/3/jpdl http://jbpm.org/xsd/jpdl-3.0.xsd"
name="Task">
<start-state name="start">
< transition name="tr1" to="MyTaskNode"></ transition>
</start-state>
<end-state name="end"></end-state>
<task-node name="MyTaskNode">
< task name="MyTask"></ task>
< transition name="tr1" to="end"></ transition>
</task-node>
</process-definition>

and JpdlXmlWriter.toString( procDef ) returns

<?xml version="1.0" encoding="UTF-8"?>

<process-definition name="Task">

<!-- START-STATE -->
<start-state name="start">
< transition to="MyTaskNode" name="tr1"/>
</start-state>

<!-- NODES -->
<end-state name="end"/>
<task-node name="MyTaskNode">
< transition to="end" name="tr1"/>
</task-node>

</process-definition>

[koen.aers]

The JpdlXmlWriter has been deprecated and it will be removed in one of the subsequent versions. So it will not be possible anymore to revert from an object model to the xml. On the contrary, it will be possible to save the xml definition in the database when deploying. This way you can always get back to the (versioned!) xml definition.

Regards,
Koen

[hsf]

I also have a question regarding the JpdlXmlWriter and the GPD...

When deploying a process definition we can deploy a jpdl xml file with the process modeled in GPD. If JpdlXmlWriter has been deprecated how do you plan to generate the xml process definition in the GPD? How do you plan to do it?

Thanks.

[nick_nickolov]

Dropping JbdlXmlWriter would also affect my project.
We are using it at application startup to decide whether the process definition structure has changed and we need to redeploy. We are fetching the pd as an object graph from the db, then converting it to xml, and comparing the xml to the original xml bundled with our app.
In case you really abandon it, I would suggest that you include a field in ProcessDefinition, representing a hash of the .par archive which it was parsed from (or include the full .par as a blob). It would make the comparison much easier.
Is anybody who's aware of jbpm's internals willing to provide a patch? Or should we do it ourselves and later share it? Do you think this solution is appropriate for the redeployment decision?
-- Nick

[kukeltje]

scary.... I would not use the JpdlXmlWriter for this.

I'd use the versionnumber of the latest processdefinition in the db and compare it to the one in the supposedly new one. If they match it 's the same, if they differ, look if the about to deploy version is newer. If so deploy it, if not report an error.

[nick_nickolov]

I'm afraid versionnumber wouldn't help.
Of course, the par which we haven't yet deployed does not have a version number (afaik, version numbers are not described in the process archive). And after deploying it, its versionnumber will become MAX(VERSIONNUMBER_) + 1.
The question is should we deploy the par at all.

[ralfoeldi]

Hi Nick,

you have a valid problem there and I do think the jBPM Team is aware of this.

Since I'm deploying in a J2EE env in a far, far away hosting I have the exact same problem. My solution was to add a version.properties file to the par, to parse that and explicitly set the version of the parsed processDefinition (thanks to Koen for the tip).

That way you can always get the 'version' of the par you have and compare that to the version in the database.

...
 String processName = processDefinition.getName();

 ProcessDefinition existingProcessDefinition = jbpmSession
 .getGraphSession().findLatestProcessDefinition(processName);

 if ((existingProcessDefinition == null)
 || (existingProcessDefinition.getVersion() < version))
 {
 LOG.info("Deploying processDefinition:'" + processName
 + "', version:" + version + " from par archive '" + parName
 + "'");

 processDefinition.setVersion(version);

 jbpmSession.getGraphSession().saveProcessDefinition(
 processDefinition);
 }
 else
 {
 LOG.info("ProcessDefinition:'" + processName
 + "' from par archive '" + parName
 + "' is alread deployed in version "
 + existingProcessDefinition.getVersion()
 + ". Not deploying version " + version);

 continue;
 }

...

You do have to keep track of your version though. By convention we use a 'timestamp' ymmddhhmm'. Works out ok.

Hope this helps you.

Greetings

[nick_nickolov]

Hi Rainer,

Good idea. But how and when do you calculate that "version" variable in your code? As far as I understand you calculate it from a timestamp, is it the timestamp when the build procedure is run?

In our team the build timestamp would be inappropriate. We are using a central db, local j2ee servers and local builds. If two developers do local builds consequtively, even without doing any changes to our business processes, the second one will always cause redeployment.

Sorry to bother you again.

-- Nick

[ralfoeldi]

Hi Nick,

no problem.

The 'timestamp' is manually set by whoever edits the workflow. That's why 'timestamp' was in quotes. (This approach does require some thinking by whoever does the editing.)

I guess you could use some kind of cvs macro/var for this, if you don't trust your business analysts :-)

Greetings

[nick_nickolov]

Business analysts are thinking about other stuff when they are editing pd-s. It's the frameworks responsibility to detect changes.
We want to make it as automated as possible, so we'll try a comparator implementation, and suggest it to the community if it proves successful.
Thanks :)

[jbpm2011]

Hi,

so there is no other solution to write in the processDefinition.xml