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

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...

OriginalPostID-28897

OriginalPostID-28897

  Discussion posts and replies are publicly visible

  • Since you are not going to kick off the subprocess and immediately archive or delete it, then option 1 is better. You don't need to copy and paste the script task and user input task x times. If it needs to be repeated, then you can loop around to this part of the flow or make it a quick task if needed.
  • 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.
  • It sounds like you have a concrete set of steps which will occur in your flow. Placing all these user input tasks and script tasks in the main model is fine. The biggest thing you will want to consider is duration of process. How long is it going to take to complete each step (tasks and unattended activity)? If this is something that will take a long time, then you might want to consider using sub-processes. This will give you flexibility to update parts of the flow which have not yet been encountered yet in a process.

    If the tasks are all completed very quickly, then changing various tasks/script tasks won't really be a concern.