Re: AW: Changing Flowable workflows for existing objects

[Lionel SCHWARZ]

Hi Clemens, 
Here is a script I have tested on my DEV instance (not in production yet 
though) to upgrade all users to the latest workflow def. 

SET @ WfDefId = ( 

SELECT ID_ 

FROM ACT_RE_PROCDEF 

WHERE KEY_ = 'userWorkflow' AND VERSION_ = ( SELECT MAX ( VERSION_ ) FROM 
ACT_RE_PROCDEF ) 

) ; 

UPDATE ACT_RU_EXECUTION SET PROC_DEF_ID_ = @ WfDefId WHERE ID_ IS NOT NULL ; 

UPDATE ACT_RU_TASK SET PROC_DEF_ID_ = @ WfDefId WHERE ID_ IS NOT NULL ; 

UPDATE ACT_RU_ACTINST SET PROC_DEF_ID_ = @ WfDefId WHERE ID_ IS NOT NULL ; 

My feeling is that when you update the workflow you have to keep the 
compatibility with previous version, from the variables point of view I mean. 
Regards 
Lionel 

- Le 18 Jan 24, à 9:23, Clemens Bergmann  
a écrit : 

> Hello Samuel,

> thanks for this hint. I tried to find out which database tables I would have 
> to
> update but I am not sure.

> If I understand it correctly ACT_RE_PROCDEF contains the versions of the 
> defined
> workflows. ACT_HI_PROCINST seems to contain the instances of these workflows
> and I would suspect that I would have to change the PROC_DEF_ID_ table to 
> match
> the ID_ value from ACT_RE_PROCDEF. The first thing that seems to be strange is
> the fact that we have 9 entries in this database but only 8 users.

> I was not able to find the link between the workflow instances and the users.
> There seem to be two tables (ACT_HI_VARINST and ACT_RU_VARIABLE) but I am not
> sure which one is used.

> A hint in the right direction would be appreciated.

> Kind regards

> Clemens (Bergmann)

> --

> Clemens Bergmann

> [er/ihm; he/him]

> Gruppe Nutzermanagement und Entwicklung

> Technische Universität Darmstadt

> Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt

> Tel. +49 6151 16 71184

> [ http://www.hrz.tu-darmstadt.de/ | http://www.hrz.tu-darmstadt.de/ ]


smime.p7s
Description: S/MIME Cryptographic Signature

AW: Changing Flowable workflows for existing objects

[Bergmann, Clemens]

Hello Samuel,

 

thanks for this hint. I tried to find out which database tables I would have to 
update but I am not sure.

If I understand it correctly ACT_RE_PROCDEF contains the versions of the 
defined workflows. ACT_HI_PROCINST seems to contain the instances of these 
workflows and I would suspect that I would have to change the PROC_DEF_ID_ 
table to match the ID_ value from ACT_RE_PROCDEF. The first thing that seems to 
be strange is the fact that we have 9 entries in this database but only 8 
users. 

I was not able to find the link between the workflow instances and the users. 
There seem to be two tables (ACT_HI_VARINST and ACT_RU_VARIABLE) but I am not 
sure which one is used.

A hint in the right direction would be appreciated.

 

Kind regards

Clemens (Bergmann)

 

-- 

Clemens Bergmann

[er/ihm; he/him]

Gruppe Nutzermanagement und Entwicklung

Technische Universität Darmstadt

Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt

Tel. +49 6151 16 71184

 <http://www.hrz.tu-darmstadt.de/> http://www.hrz.tu-darmstadt.de/

 

Von: Samuel Garofalo  
Gesendet: Mittwoch, 17. Januar 2024 14:47
An: user@syncope.apache.org
Betreff: Re: Changing Flowable workflows for existing objects

 

Hello Clemens,

in general when you create a user it's associated to the instance of the 
workflow actually presents for all its lifecycle, although you change the 
workflow definition the first workflow remains associated to the user. If you 
create a new user the second workflow is used. But is possible to set the new 
workflow instance to all users updating on the DB, in flowable's tables, the 
value of the associated workflow, in this way also existing users will be 
subject to the new workflow.

Before performing this step you have to approve all users who are under 
approval.

 

HTH,

Best regards,

Samuel

Il 16/01/24 13:19, Bergmann, Clemens ha scritto:

Hi,

 

we are currently evaluating syncope as a replacement for our proprietary IAM 
system.

 

We think that modelling internal processes with BPMN would allow better 
communication of our processes. Therefore we are looking into using the 
flowable functionality. After testing some things out it seems that the 
configuration of a flow is instantiated when it is started and then never 
changed for the lifetime of this workflow instance. For the user process tis 
would mean that we will not be able to change the user management flow after 
initial importing of an user. Our User management process is not changing 
rapidly but there are some changes here and there. Some of these changes are 
minor and could be implemented by changing the serviceTask implementation 
classes. Some of them are bigger and we would want to reflect them in the BPMN 
representation. If I am not mistaken that would mean that we would have to 
reimport all 30k+ Users and move them into the right state so that they would 
benefit from the new process in the future. 

I understand that applying a new version of the workflow to an existing 
instance would be a challenge. For example the new version could depend on flow 
variables that are not available in the current state of the current instance. 
Nevertheless I think this is a main impediment when using the flowable 
functionality.

 

Do I understand this restriction correctly or is there a way to “migrate” a 
given user to a new workflow variant?

 

Mit freundlichen Grüßen

Clemens (Bergmann)

 

-- 

Clemens Bergmann

[er/ihm; he/him]

Gruppe Nutzermanagement und Entwicklung

Technische Universität Darmstadt

Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt

Tel. +49 6151 16 71184

 <http://www.hrz.tu-darmstadt.de/> http://www.hrz.tu-darmstadt.de/

 



smime.p7s
Description: S/MIME cryptographic signature

Re: Changing Flowable workflows for existing objects

[Samuel Garofalo]

Hello Clemens,

in general when you create a user it's associated to the instance of the 
workflow actually presents for all its lifecycle, although you change 
the workflow definition the first workflow remains associated to the 
user. If you create a new user the second workflow is used. But is 
possible to set the new workflow instance to all users updating on the 
DB, in flowable's tables, the value of the associated workflow, in this 
way also existing users will be subject to the new workflow.


Before performing this step you have to approve all users who are under 
approval.



HTH,

Best regards,

Samuel

Il 16/01/24 13:19, Bergmann, Clemens ha scritto:


Hi,

we are currently evaluating syncope as a replacement for our 
proprietary IAM system.


We think that modelling internal processes with BPMN would allow 
better communication of our processes. Therefore we are looking into 
using the flowable functionality. After testing some things out it 
seems that the configuration of a flow is instantiated when it is 
started and then never changed for the lifetime of this workflow 
instance. For the user process tis would mean that we will not be able 
to change the user management flow after initial importing of an user. 
Our User management process is not changing rapidly but there are some 
changes here and there. Some of these changes are minor and could be 
implemented by changing the serviceTask implementation classes. Some 
of them are bigger and we would want to reflect them in the BPMN 
representation. If I am not mistaken that would mean that we would 
have to reimport all 30k+ Users and move them into the right state so 
that they would benefit from the new process in the future.


I understand that applying a new version of the workflow to an 
existing instance would be a challenge. For example the new version 
could depend on flow variables that are not available in the current 
state of the current instance. Nevertheless I think this is a main 
impediment when using the flowable functionality.


Do I understand this restriction correctly or is there a way to 
“migrate” a given user to a new workflow variant?


Mit freundlichen Grüßen

Clemens (Bergmann)

--

Clemens Bergmann

[er/ihm; he/him]

Gruppe Nutzermanagement und Entwicklung

Technische Universität Darmstadt

Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt

Tel. +49 6151 16 71184

http://www.hrz.tu-darmstadt.de/ 

Changing Flowable workflows for existing objects

[Bergmann, Clemens]

Hi,

 

we are currently evaluating syncope as a replacement for our proprietary IAM 
system.

 

We think that modelling internal processes with BPMN would allow better 
communication of our processes. Therefore we are looking into using the 
flowable functionality. After testing some things out it seems that the 
configuration of a flow is instantiated when it is started and then never 
changed for the lifetime of this workflow instance. For the user process tis 
would mean that we will not be able to change the user management flow after 
initial importing of an user. Our User management process is not changing 
rapidly but there are some changes here and there. Some of these changes are 
minor and could be implemented by changing the serviceTask implementation 
classes. Some of them are bigger and we would want to reflect them in the BPMN 
representation. If I am not mistaken that would mean that we would have to 
reimport all 30k+ Users and move them into the right state so that they would 
benefit from the new process in the future. 

I understand that applying a new version of the workflow to an existing 
instance would be a challenge. For example the new version could depend on flow 
variables that are not available in the current state of the current instance. 
Nevertheless I think this is a main impediment when using the flowable 
functionality.

 

Do I understand this restriction correctly or is there a way to “migrate” a 
given user to a new workflow variant?

 

Mit freundlichen Grüßen

Clemens (Bergmann)

 

-- 

Clemens Bergmann

[er/ihm; he/him]

Gruppe Nutzermanagement und Entwicklung

Technische Universität Darmstadt

Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt

Tel. +49 6151 16 71184

  http://www.hrz.tu-darmstadt.de/

 



smime.p7s
Description: S/MIME cryptographic signature