Skip to main content

Crawler Configurations

LicenseInt4 Shield Lite (1 of 3) · Custom add-on (2)Details
Show for
Feature or limitInt4 Shield Lite
SAP PI/PO crawlerIncluded
SAP Integration Suite crawlerAdd-on
Business object crawlerAdd-on

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 crawler builds test cases for you out of messages that already flowed through your integration platform, so you do not have to create each test case by hand. A crawler configuration is a saved recipe that says what to look at and how to turn what it finds into test cases: which platform and system to read from, which interfaces (automation objects) to inspect, which time window to search, and which folder the new test cases land in.

A test case can always be built by hand, one at a time. The crawler is the bulk alternative: a robot that scans the platform, collects the historical messages that match your criteria, and turns them into many test cases in one pass — each one linked to the automation object it came from and filed into its folder. Its value is breadth of regression coverage gathered from real, production-like traffic with very little manual effort. Because interfaces are listed one per item, the results land in a tidy folder structure organised by interface rather than as one undifferentiated heap.

A crawler can read from four kinds of sources: SAP PI/PO, SAP Cloud Integration, SAP CI Trading Partner Management (B2B business documents), and Business Objects (documents listed by one of your Business Objects). The settings common to all of them are described under Tasks and Field reference; what differs is described under Platform types.

This page lists every crawler configuration. From here you search and filter the list, open a configuration to view, run, copy, edit or delete it, and start a new one.

Tasks​

How to create a crawler configuration​

The configuration page is one long form with a section navigator on the left and a Checklist panel on the right. The checklist marks each required field as soon as you fill it in, and flags problems such as a missing time range or a system that does not fit the chosen platform, so you can see what is left before you save.

  1. Click Create New in the toolbar.
  2. Pick the platform first. In General, choose Platform Type. This is the one choice you cannot change later: it decides which systems and automation objects you can pick and which extra options appear. Save stays disabled until a platform is chosen, and changing the platform clears any system, SUT group or system line you had already picked.
  3. Fill in the rest of General: Name, an optional Description, the crawl target — System Under Test for the SAP platforms (only systems of the matching type are offered) or SUT Group for Business Objects — an optional System Line, the Target Folder, an optional project scope, and the Active switch.
  4. In Period, choose the time window to search.
  5. In Creation, decide how messages become test cases: preview mode, the folder limit, duplicate handling, ordering, and the naming template.
  6. (SAP PI/PO only) In Platform Parameters, tune how the message store is queried. See SAP PI/PO.
  7. In Items, click Add Item once per interface. Pick its Automation Object (only types the platform can crawl are offered), an optional Subfolder Name, and leave Enabled ticked. Further columns hold the platform's per-item filters — see Platform types.
  8. (Optional) In Scheduling, set up automatic runs — see How to schedule a crawler.
  9. Click Save. The configuration opens in view mode.

How to run a crawler​

  1. Open the configuration.
  2. Click Execute at the top of the page. The run starts in the background and the message Crawler run started successfully appears with a Crawler run link that opens the run, where you can follow its progress live.

Execute appears only when the configuration has at least one item. It is disabled unless you may run the crawler and use its system, folder and automation objects (see Prerequisites & permissions). Make sure at least one item is enabled before you run. While Test Run Mode is on, a run only counts what it would find — switch it off when you want test cases created.

How to schedule a crawler​

  1. Open the configuration and click Edit, then go to Scheduling.
  2. Switch on Schedule Enabled, choose a Schedule Type (Single or Recurring) and fill in the start, recurrence and end settings.
  3. Click Preview Schedule to check the Next scheduled runs.
  4. (SAP Cloud Integration only) Switch on Automatically manage trace if the crawler should keep iFlow traces on before each scheduled run — see SAP Cloud Integration.
  5. Click Save Changes.

The schedule runs with its owner's permissions; you become the owner when you create it. Only the owner can change or switch off a schedule, unless you may reassign it, in which case Schedule Owner can be changed. In view mode the section also shows the schedule's Status, Next Run, Last Run and Occurrences Completed. A schedule only fires while the configuration is Active.

How to copy a crawler​

  1. Open the configuration and click Copy.
  2. A new configuration form opens with every setting, item and schedule of the original, named after it with _COPY added. Adjust it — for example point it at another system or folder — and click Save.

Copying is also the way to move a crawler to another system, SUT group or target folder: those three can be chosen only when the configuration is created.

How to delete a crawler​

  1. Open the configuration and click Delete.
  2. Confirm in the Delete Crawler Configuration dialog.

Deletion is refused while a run of the configuration is pending or running. Past runs stay in the crawler run history. Test cases the crawler created are not affected.

Platform types​

The platform decides where the crawler reads from, which crawl target it needs, which automation objects it accepts, and which extra options appear. You choose it once, in General.

PlatformReadsCrawl targetAutomation objectsExtra options
SAP PI/POThe platform's message storeAn SAP PI/PO systemSAP PI/PO typesQuery tuning; sender/receiver filters per item
SAP Cloud IntegrationiFlow message processing logs and tracesAn SAP Cloud Integration systemSAP Cloud Integration types (not TPM)Custom header and business filters per item; automatic trace management
SAP CI Trading Partner ManagementB2B monitoring business documentsAn SAP Cloud Integration systemTPM inbound and outbound typesTrading partner, adapter, interchange and agreement filters per item
Business ObjectsDocuments returned by a Business Object's listAn SUT groupBusiness Object typesDate parameters and fixed parameter values per item

SAP PI/PO​

Pick SAP PI/PO when the messages live on an SAP Process Integration / Process Orchestration system.

Query tuning — Platform Parameters. Both fields are optional; leave them blank to use the defaults. They change only how the search window is read, never which messages match.

FieldDescription
Time Slice (minutes)Controls how the selected time window is divided into individual requests. Each request reads one slice of the specified length (1–1440 minutes). For example, a 60-minute window can be read as a single 60-minute request, two 30-minute requests, or sixty 1-minute requests. Smaller slices keep each request lightweight on a busy system, while larger slices reduce the total number of requests over a long window.
Max Results Per Search CallThe largest number of messages the system returns per request (1–10000). Lower it if a single request would otherwise pull back too much at once.

Per-item message filters. Each item row has extra columns that narrow the messages that item picks up. All are optional free text; a blank filter means "do not restrict on that attribute".

FilterDescription
Sender PartyMatch only messages from this sender party.
Sender NameMatch only messages from this sender component.
Receiver PartyMatch only messages to this receiver party.
Receiver NameMatch only messages to this receiver component.
Receiver Interface NameMatch only this receiver interface name.
Receiver Interface NamespaceMatch only this receiver interface namespace.

What the crawl can find. A PI/PO crawl only sees messages the platform still has: message logging for the chosen interfaces must be retained over the window you search.

SAP Cloud Integration​

Pick SAP Cloud Integration when the messages run through iFlows on an SAP Cloud Integration tenant. Each item names the iFlow through its Automation Object. An item can read at most 10,000 messages per run; if a window holds more, the run log warns you to narrow it.

Crawling by custom headers. Turn on Use Custom Headers Filter next to Add Item to collect only messages that carry given custom header properties. The Custom Header column then becomes editable. Type the filter as name=value, joining several with & when all must match (OrderType=Standard&Region=EU) or with | when any may match (Region=EU|Region=US), or click the pencil to edit the pairs in a dialog, where Any may match switches between the two. A filter can be up to 100 characters long. While the switch is on, an enabled item without a filter fails. Switching it off disables the column and crawls every message again; the filters stay visible and are kept for later.

Crawling by business content. The Business Filters column keeps only messages that carry given business dimension values. Pick the item's automation object first, then click the pencil: each row of the Business Filters dialog is a business dimension of that automation object and each column a group of values.

  • A message is kept when every filled cell of one group matches; empty cells add no condition. Use Add group for alternatives, and remove a group with its ×.
  • + next to a dimension adds another row for it: in one group, all its values must then occur in the same payload, for example two materials of one invoice.
  • Each candidate message is read once and nothing is stored for it. Filtering happens before messages are counted, so a preview reports filtered counts. A message that cannot be read counts as no match; the run log says how many there were.
  • A dimension is read through the locators defined on the automation object (see Automation objects and Business dimensions). A dimension that cannot be read that way — for example one extracted by a script — matches nothing, and the run log warns about it.
  • Values must equal the extracted value exactly.
  • When the item's folder already holds Max Test Cases Per Folder test cases, the item is skipped before any message is read.
  • Custom header filters and business filters combine: a message must pass both.

Tracing must be on. The crawler captures payloads from the iFlow trace, and SAP Cloud Integration switches tracing off after a few minutes and discards trace data after about an hour. A message processed while tracing was off cannot be captured. There are two ways to keep tracing on:

  • For a scheduled crawler, switch on Automatically manage trace in Scheduling. The switch appears only while the schedule is on. From about an hour before each scheduled run, the crawler re-enables tracing on the iFlows it needs every 9 minutes. Only iFlows whose payloads are read from Block in iFlow need this; if none of your items does, a hint says trace management stays inactive. To keep this running, you need permission to write trace configurations. The crawler maintains a hidden trace configuration named [crawler] <crawler name> for it; its runs show up under Trace scheduler runs. Deleting or deactivating the crawler, switching off its schedule or switching off the option stops it.
  • For manual runs, set up a Trace scheduler for the iFlows you intend to crawl before you crawl them.

If an SAP Cloud Integration crawl finds fewer messages than you expected, missing traces are almost always the reason.

SAP CI Trading Partner Management​

Pick SAP CI Trading Partner Management to build test cases from B2B business documents in the tenant's B2B monitoring rather than from iFlow messages. It runs against an SAP Cloud Integration system, accepts only TPM inbound and outbound automation objects, and needs no tracing. It requires the Trading Partner Management add-on in your licence.

Each item can narrow the documents it picks up. All filters are optional; a blank filter means "do not restrict":

FilterDescription
Sender Trading PartnerOnly documents from this trading partner.
Receiver Trading PartnerOnly documents to this trading partner. Overrides the receiver set on an outbound automation object.
Sender Adapter TypeOnly documents received through this adapter type.
Receiver Adapter TypeOnly documents sent through this adapter type.
Interchange NameOnly this interchange.
Direction (IN/OUT)IN or OUT.
Agreement TypeOnly documents of this agreement type.
Transaction TypeOnly documents of this transaction type.

One inbound document always becomes one test case. An outbound document that was sent as several payloads becomes one test case per payload, and the counts, the preview and the folder limit count those test cases, not documents.

Business Objects​

Pick Business Objects to build test cases from the documents one of your Business Objects lists — for example orders or invoices in a backend system. For every listed document the crawler captures its input and its reference outputs, exactly as when you save a single document from the message selector.

  • Crawl target. Choose a SUT Group instead of a system: a Business Object can reach several systems, and the group decides which ones. No system line is used.
  • Items accept only Business Object automation objects.
  • Date From Parameter / Date To Parameter — pick which of the Business Object's date parameters receive the start and end of the crawl window. The window is passed as dates. Leave both at (none) and the list runs without a window: the period settings then have no effect and the Business Object's own defaults decide what is returned.
  • Dynamic Parameters — click the pencil to give fixed values to the Business Object's other dynamic parameters, as you would type them in the message selector. A parameter that receives the crawl window cannot also have a fixed value.
  • The date parameters are checked when the crawler runs, not when you save. If one no longer exists or is not a date, that item fails with a message naming the problem.
  • A list can return at most 10,000 documents per item; if it returns that many, the run log warns you to narrow the window or filters. A document whose capture fails is skipped and logged, and the rest of the run continues.
  • The target folder, or one of its parent folders, must have an SUT group assigned. Otherwise the test cases are created but cannot be run.
  • Two extra naming placeholders are available: \{\{BUSINESS_OBJECT\}\} and \{\{DOCUMENT_NUMBER\}\} (see Tips & edge cases).

Field reference​

Platform-specific fields are documented under the matching platform in Platform types above.

The list shows these columns:

ColumnDescription
NameThe configuration's unique name. Click it, or the row, to open the configuration.
DescriptionOptional note describing what the configuration is for.
PlatformWhere the crawler reads from (see Platform types).
System / SUT GroupThe system the crawler reads from, or the SUT group for a Business Object crawler.
ActiveWhether the configuration is active. A schedule only fires for an active configuration.
ScheduledWhether a schedule is set up.
Test RunWhether the configuration is in preview mode (it counts messages without creating test cases).
Last RunWhen the configuration last ran, as a relative time. Empty if it has never run.
Created ByThe user who created the configuration.
Created DateWhen the configuration was created, as a relative time.

The configuration form holds these shared settings:

SettingSectionDescription
NameGeneralUnique name, up to 100 characters.
DescriptionGeneralOptional note, up to 255 characters.
Platform TypeGeneralWhere the crawler reads from. Cannot be changed after saving.
System Under TestGeneralSAP platforms only. The system to read from; only systems of the matching type are offered. Chosen at creation.
SUT GroupGeneralBusiness Objects only. The SUT group that decides which systems the Business Object reaches. Chosen at creation.
System LineGeneralSAP platforms only, optional. The column of the System landscape stored on every created test case, so the test case finds the right system when an environment holds several systems of this type. Only columns that hold the chosen system are offered. Left empty, each test case gets the column that holds the system — or none if the system sits in several columns or in none.
Target FolderGeneralThe folder where created test cases are filed. Each item can use a subfolder beneath it. Chosen at creation.
Project Scope IdGeneralOptional project scope that governs who may read, edit and run the configuration.
ActiveGeneralA schedule only fires while this is on.
Period TypePeriodThe time window to search, worked out when the run starts: Today, Yesterday (default), Last Hour, Last 24 Hours, Last 7 Days, Relative Period, or Custom Range. "Today" and "Yesterday" are calendar days in UTC.
Relative Value / Relative UnitPeriodFor Relative Period: how far back from now to search, as a positive number of Minutes, Hours or Days.
Date From / Date ToPeriodFor Custom Range: the fixed start and end of the window. The end must be after the start.
Test Run ModeCreationPreview mode, on for new configurations: a run reports how many messages match and creates nothing. Switch off to create test cases.
Max Test Cases Per FolderCreationThe most test cases the item's folder may hold, counting the ones already there. A run fills only the free places: with a limit of 10 and 8 test cases already in the folder, it creates at most 2. New configurations start with 10; clear the field for no limit.
Duplicate Check ModeCreationHow repeated messages are skipped, compared with the test cases already in the item's folder: None (No Duplicate Check); Document Number (default) skips a message whose message or document number is already in the folder; Description skips a message whose test case name is already in the folder.
Message OrderCreationWhich messages are processed first, and so which ones win when the folder limit is reached: Random, Latest First (default), or Oldest First.
Test Case Description PatternCreationTemplate for naming each created test case, up to 500 characters, with \{\{...\}\} placeholders filled in per message. The default, \{\{INTERFACE\}\} \{\{MSG_DATE\}\} \{\{MSG_TIME\}\}, names each test case after its interface plus the message date and time. See Tips & edge cases.
Automation ObjectItemsThe interface to crawl, one per item. Each created test case is linked to it.
Subfolder NameItemsOptional subfolder under the target folder for this item's test cases. It is created on the first run that needs it. Duplicate checks and the folder limit then apply to that subfolder.
EnabledItemsOnly enabled items are crawled.

The Admin section, shown for saved configurations, lists who created and last changed the configuration and its change history.

Tips & edge cases​

  • Opening a configuration needs access to its project scope. The list shows all configurations, but you can open only those in project scopes where you may read crawlers.

  • The crawl target and folder are fixed. Platform, system or SUT group, and target folder are chosen when the configuration is created. To point a crawler elsewhere, copy it and change them in the copy.

  • A preview counts, but does not judge. In preview mode every matching message is reported as found and as skipped. Duplicate checks and the folder limit are only applied by a real run, so a real run usually creates fewer test cases than the preview found.

  • Skipped is usually expected. In a real run, duplicates, messages beyond the folder limit and messages that could not be turned into a test case count as skipped.

  • The folder limit counts what is already there. Once a folder is full, later runs create nothing in it. Raise the limit, clear it, or use a new subfolder to collect more.

  • Make sure at least one item is enabled. A run of a configuration whose items are all disabled has nothing to do and may stay in the running state.

  • Scheduled runs need the owner's permissions. If the schedule owner loses permission to run the crawler or to use its system, folder or automation objects, scheduled runs stop.

  • Your licence must cover the platform when the crawler runs. You can save a configuration for any platform, but starting a run checks that your licence includes the crawler for that platform — plus the Trading Partner Management add-on for TPM crawlers and the Business Objects module for Business Object crawlers.

  • The crawler can only find what the platform kept. A crawl reads historical messages, so it can only build test cases from traffic the platform retained over your window. For SAP Cloud Integration this means tracing must have been on while the messages were processed; for SAP PI/PO, message logging must still hold them.

  • Production traffic may be sensitive. A crawl pulls in real messages, which can contain confidential business data. Plan to scramble or mask it through the automation object's data-handling rules before the test cases are replayed or shared.

  • Naming created test cases. The Test Case Description Pattern is plain text; any text you type is kept as-is, and these placeholders are replaced for each message:

    PlaceholderReplaced withExample
    \{\{INTERFACE\}\}The interface or iFlow name of the message, falling back to the automation object's interface name. TPM: the interchange name. Business Objects: the automation object's interface name, falling back to the Business Object name.Order_Replication
    \{\{MSG_DATE\}\}The date the message was processed, as YYYY-MM-DD.2026-06-16
    \{\{MSG_TIME\}\}The time the message was processed, as HH:MM:SS (24-hour).14:32:05
    \{\{BUSINESS_OBJECT\}\}Business Objects only: the Business Object's name.SalesOrder
    \{\{DOCUMENT_NUMBER\}\}Business Objects only: the document number from the list.4500012345

    TPM crawlers also offer \{\{INTERCHANGE\}\}, \{\{SENDER\}\}, \{\{RECEIVER\}\}, \{\{MSG_TYPE\}\}, \{\{DOC_STANDARD\}\}, \{\{CONTROL_NUMBER\}\} and \{\{STATUS\}\}, taken from the business document.

    • Placeholders are case-sensitive and must be upper-case. \{\{INTERFACE\}\} works; \{\{interface\}\} does not.
    • A mistyped placeholder is left in the name as-is — it is not flagged. \{\{INTERFAACE\}\} would appear literally in every name, so double-check spelling.
    • A missing value leaves its placeholder blank, which can leave a double space or a trailing separator.
    • Names are not guaranteed to be unique. Two messages on the same interface within the same second get the same name from the default template — which also matters if you skip duplicates by Description.

Prerequisites & permissions​

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.

To open this page you need the Crawler: Read permission. Opening a configuration needs it in the configuration's project scope. Additional permissions unlock specific actions:

  • Crawler: Write — create, edit and copy configurations. Saving also checks that you may use the configuration's parts: System Under Test: Execute on the system (for a Business Object crawler, on every system its SUT group reaches), Folder: Write on the target folder, and Automation Object: Execute on each item's automation object.
  • Crawler: Execute — run a configuration. Running re-checks the same component permissions.
  • Crawler: Delete — delete a configuration.
  • Crawler Schedule: Write / Delete / Change Owner — create or change, switch off, and reassign a schedule. Creating a schedule also requires everything needed to run the crawler.
  • Trace Configuration: Write — needed when you save a scheduled SAP Cloud Integration crawler with Automatically manage trace switched on.

Creating, editing, deleting and running configurations require a valid licence; running additionally requires the crawler feature for the configuration's platform.

Was this page helpful?Send a quick note to the documentation team.
0 / 2000 characters