[Design of JBoss jBPM] - Re: oryx and jbpm
by 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, eiki(a)idega.com
Chief Software Engineer
Idega Software
http://www.idega.com
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210712#4210712
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210712
16 years, 8 months
[Design of JBoss jBPM] - Re: task assignee vs owner
by tom.baeyens＠jboss.com
"KrisVerlaenen" wrote : I believe a task component would probably be one of the easiest component to collaborate on (as it can be completely decoupled from the internals of the execution engine). We have expressed our interest in collaboration on this over half a hour ago and I have repeated this numerous times. What disappoints me is that the you guys now apparently decided to start creating something entirely custom without any communication whatsoever.
|
| Kris
i don't see it the same way.
we had a task component in jbpm 3 and we are building an improved version for jbpm 4.
in the meantime, i saw that you have also build a task component as well.
first of all, our time constraints don't allow us to endeavour on a unified task component. it takes *a lot* of time to understand each others goals, implementation, merge and work like that. we simply don't have the time to go through that process at this stage. i assume that you are aware of this as you also point us to your code without working with us on our project. no offence intended, just pinpointing that the hard part is the merging of ideas and requirements into a single unified implementation.
also, i don't think it is good to spend energy on building a "unified" task component for 2 engines which should have be one in the first place.
we don't have time enough to consider the merge-components strategy. but you are welcome to join our development efforts if you're interested.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210680#4210680
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210680
16 years, 8 months
[Design of JBoss jBPM] - Strongly type assignment and pooled tasks
by Johan.Parent
Hi all,
I'd like to ask for some clarification regarding some of the pooled task internals of jbpm.
I'm working for a large university hospital. We us jbpm-3.1.4 for 2 years already. We've got plently processes in the air thank to jbpm. Supporting clinical pathways with workflow comes with its sets of challenges. The task assignment in particalur is difficult since it needs combine what is essentially a patient-centric view on one hand with other nitty gritty details of the internal organization.
Fortunately jbpm allows using an alternative TaskInstance implementation. I used this to its fullest extent to introduce custom changes in the assignment code. For two reason (which I hope to (in)validate with this post):
1) inspection of the pooled actors entries revealed a large amount of duplicate values. In practice what is conceptually a many-to-many relation between taskinstances and pooled actors (cfr hibernate mapping) is reduced to a 1-to-many by the code. This relates with this post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=146959
2) the engine uses a String value to represent an assignment. As hinted above our assignment scheme/logic is complex and the use of String values is bursting at it seams. Furthermore we found that the lack of distinction between direct assignments and pooled assignments can lead to 'lost' tasks. So I added types for each kind of assignment to the API. These started of as a simple wrapped String but became more to meet our needs. With the appropriate helper-class the use of these types turned out the be less unwieldy than it may sound.
The value of the seperate assignment types end up in a seperate table each. This in turns allowed me to address the 'problem' mentioned in (1). First, the pooled actor entries now refer to entries in the pooled assignment table. They now longer represent the assignment directly. The second step was to rewrite PooledActor.createPool() to check for duplicates. Overall this was fun to do. The join table used for the pooled actors is now used as it should be. We have fewer pooled actor entries and all our unit tests are still green too ;)
Why the long story then? I could make all these changes simply by pluging in the alternative TaskInstanceFactory and providing the necessary queries. All this thanks to the nice design of jbpm. The problem showed up when I looked at the swimlanes. The overall logic largerly duplicates that of the task assignments. No big worry either except for ONE thing: the relation between a pooled actor and a swimlane instance! I had to provide an alternative swimlane implementation as well, and that's not simply pluggable as far as the engine is concerned.
I may of course be completely wrong here, hence this post, but a pooled actor does not strictly need a swimlane field. I think this could be avoided by using a seperate many-to-many relation (just like for taskinstance-poolactor case) between a swimlane instance and pooled actors. Is this correct or am I forgetting something here? I'm about to go ahead and try this but as it goes I'm getting closer and closer to forking from the original jbpm code. And that's exactly what I want to avoid. So again, am I going about this in the right way?
I'm not sure whether I am getting the message across clearly. Based on my recent work I would to advocate for a design with more explicit task assignment types. I think this API can prevent mistakes in the implementation of the assignment handlers. While at the same time make it possible make the actual assignment type pluggable as well. Using a String based implementation the default allowing custom type where needed.
Much looking forward to your input in this matter.
Best regards,
Johan
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210679#4210679
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210679
16 years, 8 months