Virtualization Objects
LicenseCustom add-onDetails
| Feature or limit | Int4 Shield Lite |
|---|---|
| Messenger | Add-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
Messenger is Int4 Suite's service virtualization. It stands in for a partner system that is not available in your test landscape — a system that is not built yet, not connected to the test environment, or too expensive to involve in every test. Messenger catches the messages your integration sends to that partner and answers them the way the real partner would, so the integration can be tested end to end without it.
A virtualization object is the reusable definition of one such stand-in. It answers two questions:
- How is a message caught? This is the object's trigger. With Synchronous HTTP, the integration calls Messenger over HTTP and waits for the answer on the same connection, as it would wait for the real partner. With Asynchronous listener, Messenger watches the message monitoring of SAP PI/PO or SAP Cloud Integration and picks up every new message that matches your filter.
- What happens to it? This is the object's flow: a line of stations that transform the message, wait, branch on its content, and finally answer the caller or send one or more new messages back into the middleware.
Like a test case, a virtualization object never names a concrete system. It names system lines from the System Landscape — "the order backend", "the CI tenant" — and stays independent of the stage it runs in. To make it work you bind it to a group (an environment such as QA) as an instance; the group decides which concrete systems the system lines point to. The same object can run in several environments at once, one instance per group. See Instances.
Objects are versioned. Every change you save becomes a new version, earlier versions can be opened and restored, and every collected message remembers the version that processed it.
Tasks
How to create a virtualization object
- Open Messenger → Virtualization Objects and select Create New.
- In General, enter a Name and optionally a Description, a Project scope and Tags.
- In Flow, choose the trigger: drag Synchronous HTTP or Asynchronous listener from the Trigger group of the palette onto the Start station. With the keyboard, select the palette entry and press Enter.
- Select the trigger station to open its card and fill in its settings (see Trigger settings).
- Add stations: drag them from the Transform, Route and Deliver groups onto the line, or select a station on the map and press Enter on a palette entry to insert after it. Open each station and complete its card. Chips on the stations point out what is still missing, such as a system line or a script.
- Select Save. Int4 Suite checks the whole flow — for example that every system line and script exists and fits the station — and shows any problem above the form.
How to answer a synchronous caller
Use this when the integration calls the partner over HTTP and expects an immediate reply, for example a price or availability check.
- Choose the Synchronous HTTP trigger. On its card, list the accepted Methods (POST by default), optionally a Path pattern, and the Response timeout (seconds) (1–120 seconds, default 25).
- Build the answer from the request with XSLT, Aster Script, Set Headers or Generate stations.
- Add a Sync Response station and set the Status code, Body, Content type and any Headers. Without this station the caller gets status 200 with the message as it stands when the flow ends.
- Optionally add stations after the response — for example a Send Message that sends a follow-up message. They run in the background after the caller has its answer.
The caller reaches the object through an instance published on an external channel; see Instances and External Channels.
How to react to messages in the middleware
Use this when the integration delivers messages asynchronously and the partner would answer with messages of its own, for example an order confirmation for every incoming order.
- Choose the Asynchronous listener trigger. On its card, pick the Listener type (SAP PI/PO or SAP Cloud Integration) and the System line to watch. Switching the listener type clears the system line and resets the parameters.
- Under Listener parameters, describe which messages to pick up: for SAP PI/PO at least the Interface Name, for SAP Cloud Integration the Integration Flow and where its payload is read.
- Adjust Poll interval (seconds) (at least 30, default 60) and Lookback overlap (seconds) (default 120) if needed.
- Add stations that turn the caught message into the partner's answer, then one or more Send Message stations. On each, choose the Adapter, the System line to send to, the Adapter parameters and the Send mode.
How to send different answers depending on the message
- Add a Condition station where the decision is made.
- Drag a station from the palette below the condition. This starts a new branch line leaving the condition. Repeat for every alternative.
- Open the condition. For each branch, fill in its test: the Source (message part, exchange property or header), an expression or name, the Operator and the Value. Give the branch a Branch label so the map is easy to read.
- Order the cases with Try earlier and Try later. Cases are tried from the top; the first match takes its branch. When nothing matches, the flow carries on along the line the condition sits on.
A condition cannot be removed while branches still leave it; delete the branches first.
How to edit the flow as JSON or start from a template
The JSON tab shows the same flow as the document it is stored as. Switching tabs carries your changes across; invalid JSON keeps you on the JSON tab.
- When creating an object, Synchronous template and Asynchronous template fill in a working starting point.
- Format JSON tidies the indentation.
- What to do when a station fails (On error: Stop and fail or Carry on with the next station) is set in the JSON only.
On the Map tab, Undo, Redo and Fit help while you build.
How to change an object
- Open the object and select Edit.
- Make your changes and optionally describe them in Version description.
- Select Save Changes. The change is stored as a new version.
Instances that are switched on use the new version immediately, without being switched on again. If the change makes a running instance read from or send to a system it did not reach before, you need the permission to execute against that system.
How to view or restore an earlier version
- Open the object and go to Versions.
- Open a version from the list. A banner shows which version you are looking at.
- To make it current again, select Restore This Version, adjust the Version description if you like, and confirm with Restore. The old content is copied into a new version; nothing is overwritten. Back to Current Version leaves the version view.
How to run an object
Open the object and select Create instance. The instances page opens with the object already chosen; pick the group to run it in. See Instances.
How to delete an object
Open the object and select Delete, then confirm. All versions are removed. The button stays disabled while any instance exists for the object, whether it is switched on or not — delete those instances first.
Field reference
General
| Field | Description |
|---|---|
| Name | Unique name, 1–40 characters: letters, digits, ., - and _. Unique regardless of case. Used as the default endpoint name of synchronous instances. |
| Description | Free text, up to 200 characters. |
| Project scope | Controls who may see and change the object. |
| Tags | Free labels for filtering. Changing only tags does not create a new version. |
| Version description | Optional note stored with the version you save (up to 128 characters). |
Trigger settings
| Trigger | Field | Description |
|---|---|---|
| Synchronous HTTP | Methods | HTTP methods the endpoint accepts. Other methods are refused. |
| Path pattern | Optional pattern for the part of the URL after the endpoint name, with * as wildcard (for example orders/*). Empty accepts any path. | |
| Response timeout (seconds) | How long the caller is given an answer, 1–120 seconds. Fixed delays before the response must be shorter. | |
| Asynchronous listener | Listener type | SAP PI/PO or SAP Cloud Integration. The system line must hold systems of that type. |
| System line | The system line whose system is watched. Each instance's group decides the concrete system. | |
| Poll interval (seconds) | How often the monitoring is read, at least 30 seconds. | |
| Lookback overlap (seconds) | How far each read reaches back before the previous one, so late-arriving messages are not missed. Messages are never picked up twice. | |
| Listener parameters | SAP PI/PO: Interface Name (required), namespace, sender and receiver party/component, receiver interface, Statuses, Payload Versions, Read Parent Message / Ignore Parent Message (not both). SAP Cloud Integration: Integration Flow (required), Payload Source with Block in iFlow or Attachment Name, Status. |
Stations
Every station has a Label that is shown on the map.
| Station | What it does | Settings |
|---|---|---|
| Aster Script | Runs a global Aster script over the message. What the script returns becomes the new payload. The script can also read and change headers and exchange properties and read the original incoming message. | Script — must be an Aster script. |
| XSLT | Transforms the payload with an XSLT script. | Script — must be an XSLT script. |
| Set Headers | Sets headers or exchange properties. Each rule takes its value from a Fixed value, an Expression on a message part (XPath, JSONPath or regular expression) or an Exchange property. | Rules, added with Add rule. |
| Generate | Produces a value — a sequence number, a date, a constant, a UUID or a random number — and stores it for later stations. | Generator, Target, Name. |
| Condition | Sends the message down the branch of the first matching case. | One case per branch; see above. |
| Delay | Waits before the flow carries on, so the receiver has time to process what it was sent. | Seconds (0–86400) or Seconds from property. |
| Send Message | Sends the message to the system the instance's group holds on a system line. | Adapter: SAP PI/PO injection, SAP Cloud Integration injection or HTTP call. System line, Headers, Send mode: Send automatically, Hold for a manual trigger, or Follow the instance setting (default). |
| Sync Response | Answers the synchronous caller. Only in synchronous flows, and only once per path. | Status code (default 200), Body (The working message or An empty body), Content type, Headers. |
Adapter parameters
| Adapter | Parameters |
|---|---|
| SAP PI/PO injection | Injector (System default, PIT or XI SOAP adapter), Keep the receiver from the header, Stop receiver processing (PIT only), Sender channel (business component and channel name; naming one always uses the XI SOAP adapter). |
| SAP Cloud Integration injection | Target integration flow (recorded with the call; the endpoint itself comes from the system), Forward headers, Store the reply. |
| HTTP call | Method, Path (relative to the system's URL), Headers, Fetch a CSRF token first with CSRF token path, Timeout in seconds (up to 300, default 60), Treat an error status as a failed send, Store the reply. |
List columns
| Column | Description |
|---|---|
| Name | The object's name; opens the object. |
| Trigger | Synchronous HTTP or Asynchronous listener. Also available as a filter. |
| Updated | When the current version was saved. |
| Description | The object's description. |
| Instances | How many instances run the object. |
| Version | Number of the current version. |
| Project scope, Tags | Hidden by default; add them from the column menu. |
The search box also finds objects by the name of a group they run in.
Tips & edge cases
- Messenger never sends to production. A Send Message station whose system line resolves to a system flagged as production is refused when you switch the instance on, and again at send time.
- Scripts are referenced by name. Aster and XSLT stations use the current version of a global script from Scripts. Changing the script changes the behaviour of every flow that uses it, without a new object version.
- Hold for a manual trigger lets a tester inspect a prepared message before it goes out. In a synchronous flow a held send is only allowed after the Sync Response station, because the caller cannot wait for a person.
- Long delays are fine. Delays of more than a few seconds pause the message and resume it later, so many messages can wait at the same time. In a synchronous flow the delays before the answer must fit the trigger's timeout.
- Properties starting with
int4.are set by Messenger itself (for example the source message id or the HTTP path of a call) and can be read but not written. - Two answers in one flow. A synchronous flow can answer the caller first and then continue with sends in the background — useful for an acknowledgement followed by a business response.
- A system line must exist before you use it. The flow refers to system lines by name; create them on the System Landscape first and fill them in the groups you want to run in.
Related features
- Instances — run an object in a group, switch it on, and work with the messages it collects.
- External Channels — the entry points synchronous callers use.
- System Landscape — groups and system lines.
- Systems Under Test — the concrete systems behind system lines.
- Scripts — Aster and XSLT scripts used by stations.
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.
Messenger must be included in your licence. To see the list you need Virtualization Object: Read; opening an object needs Read in its project scope. Virtualization Object: Write enables Create New, editing and restoring versions; Virtualization Object: Delete enables deleting. Editing an object that is running additionally needs System Under Test: Execute on any system the change newly reaches. Create instance needs Virtualization Instance: Write.