Let’s look at examples of RunList queries using the fields listed above.
Example 1: Viewing RunList relationships in a Payout
In this example, we want to investigate the RunList for a single Payout process. In the image below, we used the SQL Workbench to display a RunList for a Payout. To return only the records for a single process, we filtered by the RunListNoRoot. The query looks like this:
SELECT RunListNo, RunListNoRoot, RunListNoTaskParent, RunListNoWuParent, RecType, ProSta, Name, RecIn, RecUpd, RecRej, ElapsedTime
FROM RunList
Where RunListNoRoot = 14525498240650000
First, note that the RunListNo and the RunListNoRoot (1) on the first row are the same. This record is the root of the RunList; in other words, it is the record on the Process level.
Next, note that the records below all have the same RunListNoRoot (2). This shows they are dependent on the Process, or root, level record.
Finally, note that some, but not all, records have a RunListNoWuParent value (3). These are Work Level Units, or Threads.
To the right, we can see the Record Type (shown as RecType), the Status (shown as ProSta), and the Name. The status of 3 means the task is complete.
Finally, the RecIn, RecUpd, and RecRej columns show the number of records read, processed and rejected, followed by the time elapsed. This can be very useful for performance troubleshooting. In the image below, it looks like we have no rejected records, and the elapsed time for the entire Payout process is 61103 ms, or about 61 seconds.
Example 2: RunList Relationships in a Partially Reversed Payout
In this example, we want to see the RunList details for a payout that has been partially reversed. For this, we used the following SQL query:
SELECT RunListNo, RunListNoRoot, RunListNoTaskParent, RunListNoWuParent, RecType, Reverse, ProSta, Name
FROM RunList
WHERE RunListNoRoot = 16848658402850000
Notice the Reverse column in the table above. The N means this is not a reversal; in other words, it’s a regular "forward" payout. The Y indicates the task associated with the reversal. The horizontal line shows the delineation between these two.
Notice that the RunListNoRoot value is the same for both. It seems like the reversal would have a different RunListNoRoot than the original payout since it’s a separate process, but APM assigns the same RunListNoRoot to the reversal in order to associate the reversal with the original payout.
Example 3: RunList Number Spawner (RunListNoSpawner)
Some Process Tasks are capable of starting other top level Processes. For example, a File Sweep task can start an InFileImportRequest, InFilePost and InEntityPost Process. The RunListNoSpawner marks those top level processes with the RunListNo of the Task which started them. This is a convenient way to trace which processes start another process.
Why is this helpful? Let’s say you are looking at a task level process with the type InFilePosting that is encountering an error, and you’d like to see which process is initiating this task. The query and result below shows that the RunListNoSpawner field matches the RunListNo field of the FileSweep process. This tells us the FileSweep initiated, or spawned, this task.
Let’s look at an example. We first ran a simple query to find the RunListNoSpawner value for the record:
SELECT RunListNo, RunListNoSpawner, RecType, ProSta, Name
FROM RunList
From the result, we found the InFilePosting task we want to trace.
Noting the RunListNo and the RunListNoSpawner, we can create a SQL query that finds a record with a RunListNo that matches the RunListNoSpawner:
SELECT RunListNo, RunListNoRoot, RunListNoSpawner, RecType, ProSta, Name
FROM RunList
WHERE
(RunListNo = 15240689446860000
OR
RunListNoSpawner = 15240689446860000)
This returns a result that includes the spawner; in this case, we can see that this is a FileSweep.
