-
1. Users in task server
salaboy21 Feb 28, 2011 8:50 AM (in response to rushproject)Hi Alex, inside jBPM5 you only need to keep a small representation of what an user or a group represent for you, in order to be able to do the look up to your external data source like LDAP. What jBPM5 stores is only a way to retrieve that reference in your external system. If you think about it this is a good practice because jBPM5 internally don't need to know about your LDAP repository at all. As you mention, yes you need to keep the relationships and can be considered as duplicate information towards to have your LDAP repository totally decoupled from jBPM5. It's also good to notice that if you describe your business processes and assign tasks to different groups and users, you will have the information about the users and groups that will need to be available in the mappings. We can think a way to automate that mappings.
Greetings. Hope it helps.
-
2. Users in task server
rushproject Feb 28, 2011 11:26 AM (in response to salaboy21)Hi Mauricio,
Thanks for prompt reply.
Mauricio Salatino wrote:
Hi Alex, inside jBPM5 you only need to keep a small representation of what an user or a group represent for you, in order to be able to do the look up to your external data source like LDAP. What jBPM5 stores is only a way to retrieve that reference in your external system.
Yes, task server stores only user or group id, which is supposed to be a "small representation". Unfortunately, the way it interprets this id assumes the server "knows" if any given id is valid, thus it keeps whole lot much more info than just a handle to lookup external data source.
If task server kept merely IDs (for users and groups), adding a task would never fail assuming Task.createdBy.id contains any non empty string.
But the above transaction fails the very moment server encounters an id, which is not yet in its local database.
It's also good to notice that if you describe your business processes and assign tasks to different groups and users, you will have the information about the users and groups that will need to be available in the mappings.
So what?
First, I like the (much advocated) idea of decoupling bpm engine and task server. Ideally, decoupling means that I can use any 3rd party task server (assuming, it complies to jBPM task server protocol). As a matter of fact, now I use jBPM demo task server and my implementation (that uses MySQL database) interchangeably, assuming user id is krisv. But unfortunately(?) the protocol does not allow pushing user and group id's to the task server.
Second, I can't afford offering solution that uses unnecessary data replication.
We can think a way to automate that mappings.
Yes, I know you did I have seen the org.jbpm.userprofile package. Unfortunately I see no way how it could be used at the moment...
Well, as long as I need solution rather quickly, I am going to either patch the TaskServiceSession or build "addTask" rules to automatically create missing users and groups prior to persisting the task. Any comments on this approach (do you see any side effects?) or any alternate workarounds are highly appreciated.
Thank you,
Alex
-
3. Users in task server
rushproject Feb 28, 2011 1:32 PM (in response to salaboy21)Also, what is the reason the task server requires existence of users/groups referenced by a task being submitted? Why not just accept any syntactically correct user/group ID?
Thanks,
Alex
-
4. Users in task server
slelarge May 23, 2011 6:47 PM (in response to rushproject)Hi Alex,
I am asking me the same question about the restrictions in use for users/groups management.
Do you know how to manage group membership or swimlane usage ?
thanks
-
5. Users in task server
rushproject May 23, 2011 7:47 PM (in response to slelarge)Hi Sebastien,
I have no idea.
We do not try to employ jBPM in our projects any more. During last 6 months I have tried multiple open source BPMN engines just to discover that every product forces me to engage into composing a puzzle made of plugins, property dialog boxes and code snippets written in scripting languages. Finally, we had to develop in-house solution, which works pretty well for us.
Sincerely,
Alex