Hi Celina,
are you executing the action inside a for each loop or outside? If iit's inside a foreach, it would be executed twice. At least this is the only explanation I have if there's one row creates one sub workflow but two rows creates 4 rows.
Off topic:
- I would use the DET_WFCONID condition inside the join. This could make a small performance improvement
- I would recommend to switch Designer Studio to English. This will help others and yourself to find information with the correct terms.
Best regards,
Daniel
Hi Celina,
are you executing the action inside a for each loop or outside? If iit's inside a foreach, it would be executed twice. At least this is the only explanation I have if there's one row creates one sub workflow but two rows creates 4 rows.
Off topic:
- I would use the DET_WFCONID condition inside the join. This could make a small performance improvement
- I would recommend to switch Designer Studio to English. This will help others and yourself to find information with the correct terms.
Best regards,
Daniel
Hi Daniel,
yes exactly I have the subworkflow action in a for-each, but I need it to start a subworkflow for each datarow?
Thanks for the tips, I will implement them
Hi Daniel,
yes exactly I have the subworkflow action in a for-each, but I need it to start a subworkflow for each datarow?
Thanks for the tips, I will implement them
Hi Celina,
with the Start subworkflow (SQL) action you will start one workflow for each row in the result set.
If you have no other actions in the for each loop, than you can simply "move" the action outside of the for each loop and delete the loop.
If you have other actions in the for each loop or you want to store the started workflow instance id in the current row, you would need to use the "simple" start subworkflow action. This action will allow you to save the instance id of the created workflow to an automation parameter which in turn can be used to store the value in a column of the item list.
Best regards,
Daniel
Hi Celina,
with the Start subworkflow (SQL) action you will start one workflow for each row in the result set.
If you have no other actions in the for each loop, than you can simply "move" the action outside of the for each loop and delete the loop.
If you have other actions in the for each loop or you want to store the started workflow instance id in the current row, you would need to use the "simple" start subworkflow action. This action will allow you to save the instance id of the created workflow to an automation parameter which in turn can be used to store the value in a column of the item list.
Best regards,
Daniel
Hi Daniel,
but with the simple "start subworkflow action" I can't access the item list values?
Hi Daniel,
but with the simple "start subworkflow action" I can't access the item list values?
Hi Celina,
if the for each operator uses the "Collection type" item list, than you can access the values of the current item list row inside all actions.
Best regards,
Daniel
Hi Celina,
if the for each operator uses the "Collection type" item list, than you can access the values of the current item list row inside all actions.
Best regards,
Daniel
Hi Daniel
but my problem was that the subworkflows were started twice.
When I only did the subworkflow start (sql) without for each (as you said) they were only started individually - which was great but I have a businessrule in the query 'if MAQUALIF to respective MA = 0 then true else false' which accesses the value of the item list - So I must have the possibility to access the item list.
Hi Daniel
but my problem was that the subworkflows were started twice.
When I only did the subworkflow start (sql) without for each (as you said) they were only started individually - which was great but I have a businessrule in the query 'if MAQUALIF to respective MA = 0 then true else false' which accesses the value of the item list - So I must have the possibility to access the item list.
Hi, we noticed a similar behaviour when upgrading to version 2023.1.3.289, where SQL procedure action triggers two entries into the database, instead of one. It is a bug.
We cannot upgrade to 2024 as there is no migration path between versions.
Best regards
Marjan
Hi, we noticed a similar behaviour when upgrading to version 2023.1.3.289, where SQL procedure action triggers two entries into the database, instead of one. It is a bug.
We cannot upgrade to 2024 as there is no migration path between versions.
Best regards
Marjan
Ok i understand, thanks for the info.
Best regards
Celina