Inhibit alteration of the same record in a parallel Workflow
S
Sebastian AGNVALL
started a topic
almost 1 year ago
I have a case where a customer wants to in-phase product records using the new data-driven workflows.
The idea is that a few attributes will be populated by an external load and that data stewards then manage the rest of the attributes in the workflow.
The data stewards consist of a group of end users which theoretically means that all of these can start a workflow and alter the same record. I need to avoid this by setting up some type of startup context stating that if a specific record is already being altered in a workflow instance, then another user should not be able to start an additional workflow instance on the same root record.
I have not been able to find a good way to accomplish this.
Hi Sebastian, for the new workflows there are two tables that you can use instead of dl_batch.
Here is a sample query to test. The query is written for Postgres but it should have all of the tables required.
select sp.id from
sa_person sp
inner join wf_step_instance wsi
on sp.b_loadid =wsi.curr_dataset_load_id
inner join wf_workflow_instance wwi
on wwi.initial_data_set_loadid = wsi.prev_dataset_load_id
where wwi.status ='IN_PROGRESS'
Thanks for raising this question in the forums and for having a look at the existing answer!
Did you try the proposed solution provided in the other forum? I think it should work in your case as well as whenever the first user has to run an enricher or change the step of the workflow, data will be saved into SA in any case. If it doesn't work, I'll find the other tables to look at.
Thanks for confirming!
Stéphanie.
S
Sebastian AGNVALL
said
almost 1 year ago
Hi Stéphanie, thank you for the reply.
You are correct in that changing steps adds a new row in the SA table. However, compared to the solution in the other thread, changing steps in data-driven workflow does not add a new row in the dl_batch table. That means that I have no way of checking if the new row in the SA table has the status "RUNNING" or not.
Achive my goal by using any of the new "WF_" tables instead of dl_batch?
BR,
Sebastian
F
Fathia Jama
said
12 months ago
Answer
Hi Sebastian, for the new workflows there are two tables that you can use instead of dl_batch.
Here is a sample query to test. The query is written for Postgres but it should have all of the tables required.
select sp.id from
sa_person sp
inner join wf_step_instance wsi
on sp.b_loadid =wsi.curr_dataset_load_id
inner join wf_workflow_instance wwi
on wwi.initial_data_set_loadid = wsi.prev_dataset_load_id
where wwi.status ='IN_PROGRESS'
S
Sebastian AGNVALL
said
7 months ago
After the latest 2024.2 initial_data_set_loadid is no longer present in the wf_workflow_instance table. The query therefore needs to be changed to:
select sp.id from
sa_product sp
inner join wf_step_instance wsi
on sp.b_loadid =wsi.curr_dataset_load_id
inner join wf_workflow_instance wwi
on wwi.id = wsi.workflow_instance_id
where wwi.status ='IN_PROGRESS'
Sebastian AGNVALL
I have a case where a customer wants to in-phase product records using the new data-driven workflows.
The idea is that a few attributes will be populated by an external load and that data stewards then manage the rest of the attributes in the workflow.
The data stewards consist of a group of end users which theoretically means that all of these can start a workflow and alter the same record. I need to avoid this by setting up some type of startup context stating that if a specific record is already being altered in a workflow instance, then another user should not be able to start an additional workflow instance on the same root record.
I have not been able to find a good way to accomplish this.
Is there a way to accomplish the above by for example utilizing the "wf_" metadata tables and a custom database script similar to what is discussed in the following thread: https://support.semarchy.com/en/support/discussions/topics/43000532026
Hi Sebastian, for the new workflows there are two tables that you can use instead of dl_batch.
Here is a sample query to test. The query is written for Postgres but it should have all of the tables required.
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstStéphanie FOURRIER
Hi Sebastian!
Thanks for raising this question in the forums and for having a look at the existing answer!
Did you try the proposed solution provided in the other forum? I think it should work in your case as well as whenever the first user has to run an enricher or change the step of the workflow, data will be saved into SA in any case. If it doesn't work, I'll find the other tables to look at.
Thanks for confirming!
Stéphanie.
Sebastian AGNVALL
Hi Stéphanie, thank you for the reply.
You are correct in that changing steps adds a new row in the SA table. However, compared to the solution in the other thread, changing steps in data-driven workflow does not add a new row in the dl_batch table. That means that I have no way of checking if the new row in the SA table has the status "RUNNING" or not.
Achive my goal by using any of the new "WF_" tables instead of dl_batch?
BR,
Sebastian
Fathia Jama
Hi Sebastian, for the new workflows there are two tables that you can use instead of dl_batch.
Here is a sample query to test. The query is written for Postgres but it should have all of the tables required.
Sebastian AGNVALL
After the latest 2024.2 initial_data_set_loadid is no longer present in the wf_workflow_instance table. The query therefore needs to be changed to:
-
Deployment History Date
-
Username in Tomcat Access Logs
-
Is It Possible to Perform Automatic Authentication with The User's Windows Account?
-
Where is the documentation for Version 5.2.5?
-
On Prem Semarchy Authentication using Azure AD?
-
Delete old models
-
Sync production model version with dev
-
Recreate a dev environment. Any side effect?
-
Indexes on xDM database tables
-
What logging technology is used in the Semarchy xDM platform?
See all 64 topics