Skip to main content
Kinetic Community

Subtrees and their Parent Executions

Goal

After completing this how-to you will be able to navigate between subtrees and their parent executions as part of the task troubleshooting process.

GUI

From a KSR#

Someone will call, sometimes with a KSR# and ask what is up with the execution. Why hasn't it moved along? When the execution contains a subtree, the entire flow isn't listed in the first execution. It may look something like this, where the execution stops at an instance/node with and Id that starts tree_ and an icon next to the description in the instances list:

Clicking this will take you to the subtree execution and you can, in this case, see the error and start troubleshooting exactly as you normally would. 

Note that there might be a subtree within the subtree and you'd have to dig deeper again. 

One other interesting feature that can help in troubleshooting the subtree is that the Instance Details of the start node for the subtree contains the tree inputs, which always includes the Parent Execution Id. This can help when you need to see what was actually passed into the subtree for it to work with. 

 

From an Exception

When working from the exceptions menu, sometimes the exception will be within a subtree. It can be of interest to know what the KSR was that spawned this request and what data it had to work with. Firstly, the subtree only has the data to work with that it has in the start node or looks up within itself, since it is not directly tied to a base record. You can see what was passed in to the tree in the start node Instance Details.

 

But say you want to see what the KSR# is, perhaps because this subtree is shared among many and you want to be able to report the error to the correct service owner. In this case, click on the icon next to Parent Execution Details at the top of the execution information:

This will take you to the parent execution, which may be another subtree and you may need to do so again, but will eventually be a tree with a KSR# (this is assuming trees in your system are all Request based, if you have trees triggering another way, this may not be the case). 

Clicking on that KSR will display it in review, though in the base review, perhaps not in the desired theme.

From the Forms

Perhaps you want to report on the execption and, if it has a parent execution with a KSR, include that originating ID. This is simple enough to write. Take the "Source ID" (DB name SourceID) from the KS_TSK_Exceoption_Tree_join or KS_TSK_Exception_Handler forms and put it in the "token" field on KS_TSK_CUSTSRV_TaskInstance_join.

When the exception was a subtree within a subtree, there is a little more work. You need to take he "Source ID" (DB name SourceID) from the KS_TSK_Exceoption_Tree_join or KS_TSK_Exception_Handler forms and put it in the "token" field on KS_TSK_Trigger_tree_join to find the source_id of that record, then use that in the "token" field on KS_TSK_CUSTSRV_TaskInstance_join. If it still isn't found, it was likely another subtree, so rinse and repeat.