Trace Scheduler Runs
Overview
A trace scheduler run is the record of a single execution of a trace configuration. Each time a configuration runs — whether you trigger it by hand or it fires on its schedule — it re-enables traces on the iFlows it lists, and Int4 Suite saves the outcome as a run. Together these runs give you a history of when traces were actually kept on.
This page is the read-only history of all those runs across every configuration you can see. Use it to confirm traces were enabled successfully, to see how many iFlows succeeded or failed, and to spot when a configuration stopped itself because its test-case limit was reached. You cannot start, edit, or cancel a run from this page — it shows what already happened.
Each row summarises one run: which configuration it belonged to, its current status, whether it was a test (dry) run, how many iFlows had traces enabled, how many failed, whether the auto-stop limit was reached, and when the run started and finished. Select a configuration name to open the full run detail, where you can read the per-iFlow results and the run's log lines.
Tasks
How to find a specific run
- Type part of a configuration's name into the search box (Search by config name...). The list narrows as you type.
- To narrow by outcome, open the status drop-down and pick one of Pending, Running, Completed, Failed, or Cancelled. Choose All to see every status again.
- Use the pager at the bottom to move through older runs. The list is sorted with the newest runs first.
Field reference
| Field | Description |
|---|---|
| Configuration | The trace configuration this run belonged to. Select it to open the run detail. If the configuration was deleted after the run finished, this may be blank — the run survives but loses its link to the configuration. |
| Status | Where the run is in its lifecycle: Pending (queued, not started), Running (in progress), Completed (finished, no iFlow failures), or Failed (one or more iFlows could not have traces enabled). Cancelled is reserved and not currently produced by any run. |
| Test Run | Whether this was a test (dry) run. A test run counts the iFlows it would have processed but does not actually call SAP Cloud Integration, so no traces are changed. This reflects the configuration's setting at the time the run fired. |
| iFlows Enabled | How many iFlows had trace logging successfully re-enabled during the run. |
| iFlows Failed | How many iFlows could not have traces enabled. When this is above zero the run is marked Failed; open the run detail to see which iFlows failed and why. |
| Limit Reached | Whether the run stopped early because the configuration's auto-stop guard fired — the monitored folder had reached its test-case limit. When this is set, the run did no trace work and the configuration was switched off. A run can therefore show Completed with no iFlows enabled; always read this column to understand why. |
| Started | When the run started. |
| Completed | When the run finished. Blank while a run is still pending or running. |
Tips & edge cases
- A "completed" run is not always a working run. When the auto-stop limit is reached, the run finishes as Completed but enables no iFlows and turns the configuration off. Check the Limit Reached column before assuming traces were enabled.
- A failed iFlow can cost you messages later. Each iFlow that did not have its trace re-enabled is a window during which its messages were not retained — so failures here can quietly explain why a later crawl finds nothing for that iFlow. Treat repeated failures on the same iFlow as something to fix before relying on a crawl over that period.
- Test runs change nothing in SAP. A run flagged as a test run only counts the iFlows it would have touched. Use it to validate a configuration without affecting the live tenant.
- Runs cannot be cancelled. There is no way to abort a run that is already running — it will finish on its own. The Cancelled status exists but is never set today.
- Deleted configurations leave orphaned history. Deleting a configuration keeps its past runs in this list but clears the configuration link, so the configuration column may be empty and the run detail may no longer open. (unlocalised: behaviour flagged as an open question in FUNCTIONAL.md — confirm with product whether orphaned runs should remain browsable)
- The auto-stop count can be slightly behind. The test-case count that triggers auto-stop is read from a periodically refreshed view, so a run that fires right after a burst of test-case ingestion may act on a count that is a little stale.
Related features
Prerequisites & permissions
About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.
If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.
To view this list and open run detail you need the Trace Configuration: Read permission on the project scopes of the configurations whose runs you want to see. Runs whose configurations sit outside your scopes will not appear.
Starting and scheduling runs happens on the trace configuration screens, not here, and needs additional permissions (Trace Configuration: Execute, plus execute rights on the target system and write rights on any monitored folder).