oryx and jbpm

[tom.baeyens]

original: http://processdevelopments.blogspot.com/2007/06/is-bpmn-solution-for-all-process.html

"Eiki" wrote:
We are looking into extending the Oryx editor to support JPDL since our XForms+JBPM platform uses that and I've been looking for the offical recommendation of Jboss on this. JPDL is excellent although the Eclipse editor is pretty limited (not showing graphically for example the actors/pools). Oryx already seems to have a BPMN editor so I was wondering if we should switch to that or not, but it seems you are saying that it isn't a runtime process language and needs to be ported always? What is the official jboss jbpm teams view on this?

Oryx home page: http://bpt.hpi.uni-potsdam.de/Oryx/
Oryx google project: http://code.google.com/p/oryx-editor/

Oryx license is MIT.

[heiko.braun]

That's interesting. I just got in touch with one of the oryx lead developers regarding the export to jPDL. There is no "official recommendation", but i currently see three interesting approaches:

a) Export oryx to jpdl
b) leverage a central process repository to boost callaboration
c) leverage the xform editor in conjunction with orbeon

If you are interested we can have a brainstorming IRC session. IMO prototyping around a) would be a good start to get a better understanding of oryx itself and the amount of work it would require.

[camunda]

Hi all. Very interessting move!

We (camunda) have quite good contacts with the oryx guys as well, since we both are located in Berlin. And we work together with them sometimes for example to discuss BPMN stuff. One output was the BPMN poster: http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf...

I am very interested in which direction this is going even if I don't have too much time at the moment to have a deeper look into it or to participate :-( But please keep us informed!

[kukeltje]

Funny enough, I've been in contact with them as well (ok, just one mail).

I have two remarks though on two points from Heiko
b) Imo there is already a central process in many environments... cvs/svn that is needed anyway for most development processes. It would be harder, gouvernance wise to keep, two in sync regarding versioning etc...
c) I compared the orbeon editor and oryx and for my system I think I go for oryx. The reason for this is that I do not use orbeon for rendering the forms, but Chiba. The orbeon xforms editor is imo more mature and usable then the oryx one, at least for now. The orbeon one is html/form oriented and the oryx one is (ab)using an originally process/graphical oriented to 'try' to design form. So if you decided to go with orbeon for rendering xforms (if the choice is made to use xforms which I would applaude), then why not go with their editor.

My personal favourite is even a different direction. The JBoss VPE can be extended to display any type of html when a specific tag is encountered. See the Docbook example So also display xforms

[eikish]

Hi, I'm that "Eiki" :)

We are also using Chiba for our display needs (modified a little) but we have already a working but not polished XForms browser based editor we developed in house and we connect that to JBPM. We can for example see all tasks in a process version as xforms and edit them even for running processes (older versions) and add and remove variables (set access (read,write,required)) and easily map them to inputs. This is part of our CeSM platform (Customer eServices Management , a new buzzword you heard it here first :p )

Unlike the Orbeon editor ours isn't itself based on xforms just web2.0 magic and right now it's closed source although we are planning to make our platform available for other developers and are open to suggestions ;) The oryx xforms editor is a little strange to me as well as many of the other editors out there. It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....anyway that's off topic

About Oryx, it's very well made but I agree with kukeltje the built in repository and even openid support is something we probably won't use because we already have our own authentication and repo. Also we want to build a jpdl designer with handy extensions for our custom actionhandlers to make it truly possible for a newbie (non programmer) to design and test a complete process.

The requirements in our case in other words are being able to draw and export the xml. But when we have that we will integrate it with our form designer so we can jump right to a task and edit it.

Looking at the JPDL4 editor (only seen the alpha1) I see jboss is taking the road of integrating the positioning of the elements into the xml instead of the gpd.xml file. This is a smart move in my view and will make it easier to create designers/exporters for jpdl. I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well...

Will JPDL4 work on 3.3?



cheers
Eirikur Hrafnsson, [e-mail]
Chief Software Engineer
Idega Software
http://www.idega.com

[kukeltje]

"eikish" wrote:
Hi, I'm that "Eiki" :)

Welcome

"eikish" wrote:

Unlike the Orbeon editor ours isn't itself based on xforms just web2.0 magic and right now it's closed source although we are planning to make our platform available for other developers and are open to suggestions ;)

Web 2.0.... That I know.... there I can contribute.... hahaha

"eikish" wrote:

The oryx xforms editor is a little strange to me as well as many of the other editors out there. It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....anyway that's off topic

It's not realy off topic... it makes it easier or more difficult for e.g. others to extend it if they want/need.... see my remark about your version

"eikish" wrote:

Looking at the JPDL4 editor (only seen the alpha1) I see jboss is taking the road of integrating the positioning of the elements into the xml instead of the gpd.xml file. This is a smart move in my view and will make it easier to create designers/exporters for jpdl.

@Tom: yeeehaaa.... hahahaha

"eikish" wrote:

I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well...

July 1st is the target date

"eikish" wrote:

Will JPDL4 work on 3.3?

No

Maybe Chiba and your editor should become JBoss projects :-)

btw, I just use chiba/xforms for the tasks, not tasklists... tasklists are plain jsf

[tom.baeyens]

"eikish" wrote:
Hi, I'm that "Eiki" :)

Hi Eirikur, nice to meet you with your real name :-)

"eikish" wrote:
It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....

i don't and i would like to know. can you explain that a bit more ?

"eikish" wrote:
I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well...

Will JPDL4 work on 3.3?

we aim to supply migration support including a tool for translating jbpm 3 processes to jpdl 4.

jbpm 4 will not be backwards compatible with jbpm 3. though the basic structure would be the same. if you have the jpdl 3 plugin, it should not take a big effort to port it to 4.

if you're willing to lead it, we'ld like to host and maintain the oryx extension to import/export oryx to jpdl 4. we can help with setting up the module in our codebase.

what kind of dependencies are involved in creating an oryx extension ? is that development maven based ?

[kukeltje]

"eikish" wrote:
It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....

i don't and i would like to know. can you explain that a bit more ?

I think what he means is the following (correct me if I'm wrong)

XForms is xhtml, meaning that you have the full set of html elements and css available to design a form. Tables, divs, you name it and it is available. Within this xhtml, there are specific xforms elements (namespaces again :-)) for the behaviour of the form (e.g. is an element from the original xsd conditionally required or not) and there are elements for e.g. input (types), label, grouping etc... If you just look at these xforms elements and display them in a really rudimentary way (like oryx does), you ignore all the html, css etc... That is why they almost look the same in the browser in the lower screenshout, it is a realy simple form. This way you are in fact doing nothing more then semi visually editing the syntax of the xform.

Most you can do is re-order some elements visiually by dragging and dropping besides editing properties of elements like you can in the gpd. It's better then nothing and it is a start, but it is not really desiging forms. Dragging and dropping in an xml tree would be comparable one customer told me. Not quite, but he meant to indicate the real benefits. I wanted to look into extending the Oryx editor, but what I want would take way to much time and so I currently go for editing the xhtml forms myself in the JBoss Tools html editor and in the same time look into making VPE templates for the xforms input elements.

The Orbeon editor goes further, and is way more usable, but is tied to orbeon.

[heiko.braun]

Guys, should we have a open discussion about xforms, task management, etc in the jbpm chat room next week? I had xforms+task management on my plate for the next release cycle. Would be nice you could join a kickstart discussion. What do you think?

[kukeltje]

Yes, sounds interesting. But I think more important than the technology is what we want to support in the forms, what are the requirements. How easy do we want the generated forms to be used outside the console etc... Next thing would be choosing the technology.

[kukeltje]

oh... btw, for those who missed it: http://planetjbpm.wordpress.com/2009/02/25/xforms-editor-with-jboss-vpe-and-some-jbpm/

[kukeltje]

sorry Heiko, not directed at you... just saw your comment on the blog :-)

[tom.baeyens]

Guys, should we have a open discussion about xforms, task management, etc in the jbpm chat room next week? I had xforms+task management on my plate for the next release cycle. Would be nice you could join a kickstart discussion. What do you think?

yes. +1. just say when.

[eikish]

Ronalds description of the XForms editors is right on the money. Our own form editor is built from the perspective of an end user not a developer.
However when we edit "process" forms which basically are jbpm tasks the only added complexity is that the developer must bind process/task variables to the inputs. But everything is done visually so that's not hard to do. We haven't released it to other developers other than our partners yet because we want to improve it substantially but it's used in production already.

Just for fun here are some screenshots:

The list of deployed jBPM processes and their "human" tasks
[img]http://www.idega.is/content/files/public/formbuilder/80.png[/img]

One jBPM process opened (in that particular version) and we see the editable tasks (forms are also versioned so we can change old running tasks and variables)
[img]http://www.idega.is/content/files/public/formbuilder/81.png[/img]

"Start task" in the design mode (also have source and preview).
On the right are the used and unused variables from jbpm.
[img]http://www.idega.is/content/files/public/formbuilder/83.png[/img]

You can have sections as well
[img]http://www.idega.is/content/files/public/formbuilder/84.png[/img]

Binding a variable and setting its access attribute (changing the definition and running process instances).
[img]http://www.idega.is/content/files/public/formbuilder/79.png[/img]

Final form displayed in chiba (the css is of course customisable). "Custom" component at the buttom (done in source view)
[img]http://www.idega.is/content/files/public/formbuilder/87.png[/img]

Lastly here what our "task list" looks like for one of our clients (viewed as a case handler). This mixes it all together: roles supply the tasks from jbpm (custom actor resolution), we make documents out of everything (read only xforms or generate pdf), the system auto attaches emails related to the case, we support eSignatures and we access control the contacts. The handlers can access control everything to different roles:
[img]http://www.idega.is/content/files/public/formbuilder/case.png[/img]

Our reason for doing an Oryx extension is so we can visually reuse our reusable (sub)processes that we are using all the time in new processes for clients. As well as to be able to control some metadata about the process for example if a task should become a document or not and if it is signable or not. We then want to automatically jump to the xforms editor while developing processes to make it faster to develop solutions.

We would be happy to work on a jboss hosted extension of Oryx. So go ahead and set it up. We have planned to start in march/april on it.


A side note about the forms:
We are a little dependant on Chiba at the moment but in the future I can see supporting other "renderers" like this new Google project:
http://code.google.com/p/ubiquity-xforms/
Especially because Chiba is heavy on the memory resources in the current production version.

Cheers
Eiki, Idega.

[heiko.braun]

OK, I've setup a doodle. Please take your pick:
http://doodle.com/eichevkdygcxpp7f