In terms of KDB footprint, which one is recommended for (set of script task + 1

nikhilh0001 over 13 years ago

In terms of KDB footprint, which one is recommended for (set of script task + 1 user input task) which re occurs many times throughout a process model:
1. Individually copy pasting the script task and the the User input task in the main process
2. Creating sub process for the set and calling this sub process throughout the main process. In this case, we cannot archive this sub process since we have to show the task details in reporting.

Even if, for maintenance purpose, the 2nd option is better, for Performance or KDB getting loaded, which one is recommended? Please let us know...

Discussion posts and replies are publicly visible

Parents

0 nikhilh0001 over 13 years ago

Hi Michael,
Thanks for the response.
We have following constraints though (should ve mentioned it earlier)
- The user input task has different assignees. So the set of Scrpt Task+UI Task have different parameters throughout the process.
-Creating a quick task was ruled out as this task will not be reflected in Assignees My To Do.
- Looping around the same set was ruled out because the flow conditions differ for each time the flow comes to that task.

Please do let us know if there is any other way to handle this scenario.

Also, from Option2, we feel that the tasks from the main process will be moved out to the sub process. So even if the KDB footprint increases due to the sub process, correspondingly the footprint would be reduced from the Master as the master process would be lighter. (Not sure how much extra meta data a sub process would load into the KDB)
Let us know if we are thinking in the right direction.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 nikhilh0001 over 13 years ago

Hi Michael,
Thanks for the response.
We have following constraints though (should ve mentioned it earlier)
- The user input task has different assignees. So the set of Scrpt Task+UI Task have different parameters throughout the process.
-Creating a quick task was ruled out as this task will not be reflected in Assignees My To Do.
- Looping around the same set was ruled out because the flow conditions differ for each time the flow comes to that task.

Please do let us know if there is any other way to handle this scenario.

Also, from Option2, we feel that the tasks from the main process will be moved out to the sub process. So even if the KDB footprint increases due to the sub process, correspondingly the footprint would be reduced from the Master as the master process would be lighter. (Not sure how much extra meta data a sub process would load into the KDB)
Let us know if we are thinking in the right direction.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data