cancel
Showing results for 
Search instead for 
Did you mean: 

Centralized User/Group Management - best practices?

udoderk
Champ in-the-making
Champ in-the-making
Hi everybody,

we have a native business process m. system, that manages our employees' units (and has different database as activiti, but same DBMS as activiti), that are equivalent to user and user groups in activiti. On basis of such units, the user and user groups, that are relevant for the business process, will be a) assigned to it's user-tasks b) transmitted to activiti via REST API.

If user settings or assignments to user groups will be changed in native business process m. system, so the settings of users/user groups must be updated (Because currently activiti not supports updates, patch was created).

to eliminate such Syncs, the following ideas were discussed:

1. migrate the activiti database to database, that used by native business process m. system and realize the mapping our employees' units - activiti user and user groups
2. Don't migrate the activiti database to database, that used by native business process m. system nd realize the mapping our employees' units - activiti user and user groups
3. Realize the centralized User/Group Management - in this case both native business process m. system
and activiti would be use the same extra database, that hold the user/user groups/assignments tables. The extra (UI) application would be developed to manage that.

If more as one database is used, more as one db-connection pools must be have (Or recalculation db-connection pool depending on use-case (aa) user-user-groups bb) other entities/tables) needed.

Right now i can not estimate exactly, how many changes in activiti-engine must be done, to realize the 1., 2. and 3 possibilities.
At first glance at the activiti engine API i can only assume that the 1. is simpler as 2. and 3.

My question is whether the best practices is to realize that (centralized )User/Group Management ?

Thank you for answers
9 REPLIES 9

jbarrez
Star Contributor
Star Contributor
Of course 3 would be the 'cleanest' solution, but also the most complex one. Also technical, as you'd need two-phase transactions and all that if you want to do it cleanly…

But I'm wondering, what exactly is being stored in the other processes? Why can't you just store the userId in Activiti, and store the other details somewhere else. Whenever you need them, just do a call to that external system for the details?

udoderk
Champ in-the-making
Champ in-the-making
Of course 3 would be the 'cleanest' solution, but also the most complex one. Also technical, as you'd need two-phase transactions and all that if you want to do it cleanly…

But I'm wondering, what exactly is being stored in the other processes? Why can't you just store the userId in Activiti, and store the other details somewhere else. Whenever you need them, just do a call to that external system for the details?
Hi,
the storage of only userId in Activiti is nice idea Smiley Happy Thank you very much!
But the sync between activiti and our native system is just in such case also needed:
If an user, related to business process, was created in our system, it must be created in activiti too.
If an user, related to business process, was "reordered" from user group 1 to user group 2  in our system, it must be "reordered"  in activiti too.
If an user, related to business process, was "deactivated" /deleted in our system,  it should be deleted in activiti too, if no references by userId exist on business process (and other places).

frederikherema1
Star Contributor
Star Contributor
I guess all those requirements (when you choose sync) can be fixed if your user-management allows plugging in code when these events occur, so you can call the Activiti API to perform the required actions.

udoderk
Champ in-the-making
Champ in-the-making
I guess all those requirements (when you choose sync) can be fixed if your user-management allows plugging in code when these events occur, so you can call the Activiti API to perform the required actions.
Thanks for this idea, but we have a old legacy application, that API not allows plugging in code Smiley Surprisedops:
Now we are going to analyse the following possible solution:
Mapping of existed tables in our legacy application, that are relevant for user/user group building, to activiti users/(user)groups. I hope, that mybatis helps to realize it. The troubles can be occured because of
    more as one database (also database connection/DataSource) will be existed.
    In addition the transaction handling must be extended (we use the managed by spring transaction hadling)
    We have the hierarchical structure of ours user/user groups (an user group can have  sub usergroups etc.), so the mapping will be not just pretty simply

jbarrez
Star Contributor
Star Contributor
Damn those legacy systems! 😉

Is it a regular old db? Shouldn't be an issue then?

udoderk
Champ in-the-making
Champ in-the-making
Damn those legacy systems! 😉

Is it a regular old db? Shouldn't be an issue then?
we have anlegacy application, but not a legacy dbms;-)
The legacy application can be running with:
    sql ms server 2000-2008 (and i suppose with ms sql 2012 also)
    oracle 11g
and…and..and..with
MS ACCESS :ugeek:

jbarrez
Star Contributor
Star Contributor
Poor you .. but still, Access has a jdbc driver (or is it OCDB?) right?

Dang, when I was a student I had to fetch stuff from access using jdbc…. brings back memories.

udoderk
Champ in-the-making
Champ in-the-making
Poor you .. but still, Access has a jdbc driver (or is it OCDB?) right?

Dang, when I was a student I had to fetch stuff from access using jdbc…. brings back memories.

The Microsoft not supports the jdbc driver for Ms Acsess for Java (with goal to ban it from markt;-)) ?)
The commercial solutions exist (like Easysoft JDBC-Access Gateway is a type 2 JDBC driver), but i use the "oldy" Sun solution using
sun.java.odbc.JdbcOdbcDriver like this description

But this dbcOdbcDriver (or Ms Acsess self?) has some strange restrictions: for example, no BLOB support

Btw. Visual J# has also own driver  com.ms.jdbc.odbc.JdbcOdbcDriver

jbarrez
Star Contributor
Star Contributor
Doesn't sound good…. Smiley Sad
I think I used the JDBC-ODBC bridge http://docs.oracle.com/javase/1.3/docs/guide/jdbc/getstart/bridge.doc.html , but it's a really long time ago so I assume you have a better sight on these things.