Inhibit alteration of the same record in a parallel Workflow
S
Sebastian.agnvall
started a topic
12 months 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'
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'
F
Fathia Jama
said
11 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
12 months 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
S
Stéphanie FOURRIER
said
12 months ago
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.
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 Newest FirstSebastian.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:
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
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
Sté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.
-
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 63 topics