topic Re: Centralized User/Group Management - best practices? in Alfresco Archive

Centralized User/Group Management - best practices?

udoderk — Sun, 10 Mar 2013 08:57:49 GMT

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 busine

Re: Centralized User/Group Management - best practices?

jbarrez — Mon, 11 Mar 2013 10:50:00 GMT

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?

Re: Centralized User/Group Management - best practices?

udoderk — Mon, 11 Mar 2013 15:16:23 GMT

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 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).

Re: Centralized User/Group Management - best practices?

frederikherema1 — Tue, 12 Mar 2013 08:30:16 GMT

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.

Re: Centralized User/Group Management - best practices?

udoderk — Sat, 16 Mar 2013 09:18:40 GMT

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 ops:
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

Re: Centralized User/Group Management - best practices?

jbarrez — Mon, 18 Mar 2013 15:50:40 GMT

Damn those legacy systems! 😉

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

Re: Centralized User/Group Management - best practices?

udoderk — Wed, 20 Mar 2013 12:49:03 GMT

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:

and…and..and..with
MS ACCESS :ugeek:

Re: Centralized User/Group Management - best practices?

jbarrez — Thu, 21 Mar 2013 11:18:19 GMT

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.

Re: Centralized User/Group Management - best practices?

udoderk — Fri, 22 Mar 2013 13:31:45 GMT

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

Re: Centralized User/Group Management - best practices?

jbarrez — Mon, 25 Mar 2013 12:43:52 GMT

Doesn't sound good….
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.