Performance report
LicenseInt4 Shield Lite (2 of 3) · Custom add-on (1)Details
| Feature or limit | Int4 Shield Lite |
|---|---|
| Performance testing | Add-on |
| Test reporting | Included |
| SAP Integration Suite testing | Included |
Anything a license model does not include can be added through a custom license. The license installed for you is shown in the app under Profile → License. All features by license
Overview
A performance report tells you how long the integration platform took to process the messages a test run caused. You switch it on when you start the run. After the run, Int4 Suite reads the processing times that the system under test itself recorded and summarises them per measured object — for SAP Cloud Integration, per iFlow: how many messages were measured, and the minimum, average, median and maximum processing time.
The measurement does not change the test. Test cases run, retrieve their results and are compared exactly as without the report, and no payload is read for it; the times are collected from the platform's processing logs only after the run has finished.
Combined with more than one iteration, a performance report becomes a simple load test: each selected test case is sent as many times as you ask for, and the report shows how the processing time behaves across all those messages.
Today the report measures test cases of SAP CI Injection automation objects. Other test types run as usual but contribute no processing times.
Tasks
How to start a run with a performance report
- Select the test cases in the Cockpit, open the menu next to Execute and choose Execute w/ Parameters.
- Under Performance Testing, switch on Performance Report.
- Leave Measure success only on to count only messages the platform processed successfully, or switch it off to include failed messages in the figures as well.
- To repeat every test case, set Iterations to more than 1.
- Click Execute.
If the fields are unavailable, the dialog shows Performance testing requires a license that includes this feature. A performance report can also be part of a scheduled run or of a rerun with parameters.
How to read the performance of a run
- Open the run. Further down the page, Performance lists every measured object with its role, the number of messages measured, and the minimum, average, median and maximum processing time. A chip states whether the figures count Successful messages only or All finished messages.
- While the run executes and for a few minutes after it, the section says Processing times are read from the systems under test once the run has finished… The figures fill in as the times arrive.
- Select an object to open its own report.
How to analyse one object
- On the object's page, the tiles show Messages measured, Minimum, Average, Median and Maximum, plus Failed messages and Incomplete when there are any.
- In Processing time, switch the chart between:
- Distribution — how many messages took how long. This view opens first.
- Timeline — every message at its start time, with a line at the median, to spot slow periods during the run.
- By test case — each test case's messages as dots, with its median and average, slowest first.
- In Test cases, the test cases are listed slowest median first. Expand one to see each of its messages with iteration and duration, and select a message to open the test case's results.
The chart view you choose is kept in the page address, so a shared link opens the same view.
How to see the processing times of one test case
Open the test case from the run. When the run has a performance report, its results page shows a Performance card with every message the test case caused: the object, its role, start, end and duration.
Field reference
| Field | Description |
|---|---|
| Object | What was measured — for SAP Cloud Integration, the iFlow — with the automation objects it belongs to. |
| Role | Inject: the iFlow the test case sent its message to. Output: an iFlow that processed the message further, measured when the automation object reads its result through an output automation object. |
| Messages | How many messages entered the figures. |
| Failed | Messages the platform did not process successfully. Counted in the figures only when Measure success only was off. Shown only when there are any. |
| Incomplete | Messages found without a final status in time; they never count in the figures. Shown only when there are any. |
| Min, Avg, Median, Max | Processing time from the start to the end of the message's processing, as the platform reports it. |
| Range | The four figures side by side, drawn as a bar. |
Tips & edge cases
- Times come from the platform. Int4 Suite does not stop a clock itself: it reads the start and end the system under test logged for each message. Network time between Int4 Suite and the platform is not included.
- Collection takes a few minutes. Times are read right after the run and then again every 10 seconds, for about five minutes, for messages that are missing or still being processed. A message that has not finished by then stays incomplete; one that never shows up is not counted, and the test case's log names it in a warning.
- The report never changes the test result. A slow or failed message affects only the performance figures, not whether the test case passed.
- No timeline without start times. When the platform reported a duration but no start time, the message counts everywhere except the timeline, and the Timeline view is not offered.
- Very long runs are bucketed. With more than 2,000 messages the timeline groups messages into time slots instead of drawing each one.
- A message can count for several objects. When one message passes through more than one measured iFlow, each iFlow records its own processing time.
Related features
Prerequisites & permissions
Starting a run with a performance report or with more than one iteration needs a licence that includes performance testing, in addition to what starting any run needs (Test Case: Execute and a licence that includes test execution). Reading a performance report needs only what opening the run needs: Test Case: Read in the run's project scopes and a licence that includes test reporting.
About permissions. What you can see and do is decided by the roles assigned to your user. Each role bundles permission groups, and each permission group allows activities — Read, Write, Delete, Execute and, for schedules, Change owner — on a kind of record (for example Test Case, Automation Object, System Under Test). A role grants its groups per project scope, so you may be allowed to change records in one project but only view, or not see, those of another.
If a button is disabled, a page says you don't have access, or a list comes back empty, missing permissions are the most likely cause — or, for whole product areas, the installed licence. You can review your own access under Profile → My access; an administrator can change your roles under IAM → Users.