You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we stumbled over the problem that we would like to allow workflow changes to already existing processes. There is already an issue for that: #4840
It is outlined there, that part of the conception would be, what kind of later changes to process workflows should be allowed at all. After looking a little bit into the problem, it seems to me that the general assumption of those considerations is, that it is actually possible to compare a new workflow with the workflow tasks of an existing process, to then decide which changes should be allowed and which not.
One question for me however would be, if this is possible at all.
The way the procedure is right now (in Master), a workflow could be changed multiple times using the BPMN editor. And those changes could include the deletion or the addition of tasks. Theoretically a workflow template could be completely different from the workflow steps of existing processes.
If this should be possible it could lead to the significant diverging of workflow steps in old processes and the currently active workflow for a template.
There is a mechanism to theoretically compare steps by their workflowId (more on that in: #1423, #4691), but I am not sure wether that is a reliable instrument to compare an old process task list with the tasks of the changed workflow.
In order to make sophisticated decisions as described in #4840 (comment) one would need reliable instruments to actually identify the nature of the change. I am wondering if those instruments exist in the current architecture of the workflow system.
These complications make it rather difficult to implement a feature, which is needed for doing even just very small changes to existing processes.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
we stumbled over the problem that we would like to allow workflow changes to already existing processes. There is already an issue for that: #4840
It is outlined there, that part of the conception would be, what kind of later changes to process workflows should be allowed at all. After looking a little bit into the problem, it seems to me that the general assumption of those considerations is, that it is actually possible to compare a new workflow with the workflow tasks of an existing process, to then decide which changes should be allowed and which not.
One question for me however would be, if this is possible at all.
The way the procedure is right now (in Master), a workflow could be changed multiple times using the BPMN editor. And those changes could include the deletion or the addition of tasks. Theoretically a workflow template could be completely different from the workflow steps of existing processes.
If this should be possible it could lead to the significant diverging of workflow steps in old processes and the currently active workflow for a template.
There is a mechanism to theoretically compare steps by their
workflowId
(more on that in: #1423, #4691), but I am not sure wether that is a reliable instrument to compare an old process task list with the tasks of the changed workflow.In order to make sophisticated decisions as described in #4840 (comment) one would need reliable instruments to actually identify the nature of the change. I am wondering if those instruments exist in the current architecture of the workflow system.
These complications make it rather difficult to implement a feature, which is needed for doing even just very small changes to existing processes.
For reference:
The Goobi workflow has a very pragmatic approach to deal with that problem implemented in 2018, by basically overriding all the old tasks with the new tasks.
https://github.com/intranda/goobi-workflow/blob/9ac738a64d1605d4606b462410751689d7c7e8ec/Goobi/src/org/goobi/managedbeans/ProcessBean.java#L2738
which has not really changed until today
https://github.com/intranda/goobi-workflow/blob/c3d0370aad5965c4716b0edf41847e93f912db14/Goobi/src/main/java/de/sub/goobi/helper/BeanHelper.java#L298
The question for me would be: Are the any fundamental issues with that approach and what could be achieved with a more sophisticated approach?
Beta Was this translation helpful? Give feedback.
All reactions