Instances
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
An instance runs one virtualization object in one group of your System Landscape. The group decides which concrete systems the object's system lines point to, so the same object can run in DEV and in QA as two independent instances. An instance is the switch that turns virtualization on and off: while it is switched on, Messenger listens for messages (or accepts calls), runs them through the object's flow and sends the answers.
Every message an instance catches is kept with everything the flow made of it — the original request, the working message, each message sent to a receiver and the receiver's reply — so you can see exactly how the stand-in behaved during a test.
An instance also decides who presses send. With the response mode Automatic, answers go out on their own. With Manual, Messenger prepares every answer and waits until a tester releases it — useful when a test needs to control the timing, inspect a response before it reaches the integration, or let only some answers through. Synchronous objects always answer automatically, because the caller is waiting.
Tasks
How to create an instance
- Open Messenger → Instances and select Create instance. To add another group to an object already in the list, select Add group on the object's row instead; Create instance on an object's page does the same.
- Choose the Virtualization Object and the SUT group it should run in. An object can run only once per group.
- For a synchronous object, choose the External channel callers come through and optionally an Endpoint name. Left empty, the endpoint name is the object's name. For an asynchronous object, choose the Response mode.
- Optionally set a Project scope, then select Create.
The instance is created switched off, and its page opens.
How to switch an instance on
- On the instance page select Enable, or turn on the State switch of its row in the list.
- Int4 Suite first checks everything the instance needs. If something is missing, the Instance cannot be enabled dialog lists every problem at once — for example a system line the group has no system for, a system line that points to a production system, a system type your licence does not cover, or a synchronous instance whose external channel is disabled or has no credentials. Fix them and select Re-check.
- When everything is in place the instance switches on. An asynchronous instance listens from this moment on; messages that arrived in the middleware before are not picked up.
How to switch an instance off
Select Disable (or turn off the row's switch) and confirm. Listening stops and collected messages are kept. Messages that are already being processed are finished — to stop answers from going out, switch to manual instead.
How to hold answers for manual release
- On an asynchronous instance select Switch to manual, or turn off the Response mode switch in the list, and confirm.
- From now on, every Send Message station set to Follow the instance setting prepares its message and stops. The message shows the status Waiting to be sent and the instance counts it as pending.
- To release one message, expand it in Messages and select Send on the outbound message. To release everything at once, select Send all waiting on the instance and confirm.
Selecting Switch to automatic affects only messages collected from then on; messages already waiting stay held until you send them. A station set to Hold for a manual trigger always waits, and one set to Send automatically never does, whatever the instance's mode.
How to see what happened to a message
- Open the instance and go to Messages. The newest message is on top. Filter by Status, External ID or the received date.
- Expand a message. Outbound messages lists everything the flow sent or prepared, with its status, target system, send mode and any error.
- Under Messages, select a part — payload or headers — of the Request, the Working message, a Sent message or a Receiver reply to read it.
How to move a synchronous instance to another channel or endpoint
- Switch the instance off — the address callers use cannot change while it is live.
- Select Edit endpoint, choose the External channel and Endpoint name, and select Save.
- Switch it on again and give callers the new Endpoint URL.
How to give a caller the endpoint address
Open the synchronous instance. Endpoint URL in Overview shows the full address; copy it with Copy URL. The address has the form https://<your Int4 Suite host>/messenger/v1/<channel>/<endpoint>; the caller may append a further path if the object's path pattern allows it. Callers authenticate with the channel's username and password (HTTP Basic).
How to delete an instance
Select Delete on the instance page and confirm. The instance is removed together with all messages it collected.
Field reference
Overview
| Field | Description |
|---|---|
| Virtualization Object | The virtualization object the instance runs — always its current version. |
| SUT group | The group whose systems the object's system lines resolve to. |
| Trigger | Synchronous HTTP or Asynchronous listener, taken from the object. |
| State | Whether the instance is on, and since when and by whom. |
| Response mode | Automatic or Manual. |
| Project scope | Controls who may see and operate the instance. Set when the instance is created. |
| Messages | How many messages the instance has collected and still keeps. |
| Waiting to send | Messages whose answers are held for manual release. |
| Retention | How long finished messages are kept before they are deleted automatically (by default 30 days). Messages still waiting to be sent are kept longer (by default at least 90 days). |
| External channel, Endpoint URL | Synchronous instances only: the external channel and the address callers use. |
Poll health
Shown for asynchronous instances.
| Field | Description |
|---|---|
| Watermark | The point in time the listener has read up to. |
| Last poll | When the middleware was last read. |
| Last success | When a read last succeeded. |
| Seeded | When the listener was last (re)started — on switching on, on a new object version, or after it stalled. |
| Consecutive failures | Reads that failed in a row. After failures the listener waits longer between reads (up to ten times the poll interval) until a read succeeds again. |
| Last error | What went wrong on the last failed read. |
Messages
| Column | Description |
|---|---|
| # | Running number of the message within the instance. |
| Status | New, Running, Waiting for a delay, Waiting to be sent, Responded (the synchronous caller has its answer and stations after the response are still running), Completed or Failed. |
| Received | When Messenger picked the message up. |
| External ID | The message's ID in the middleware it came from. |
| Origin | Listener or Synchronous call. |
| Outbound | How many outbound messages are still to send or have failed. |
| Source time | When the message was processed in the middleware. |
| Completed | When the flow finished. |
| Error | Why the flow failed, if it did. |
Outbound messages have a delivery status of Ready (prepared and held), Scheduled, Sending, Sent, Failed or Skipped.
Tips & edge cases
- One object, many environments. Create one instance per group. Each has its own switch, response mode and message history.
- Answers never reach production. An instance cannot be switched on while one of its Send Message system lines points to a system flagged as production.
- Changes to the object apply at once. A running instance always uses the object's current version. Each collected message remembers the version that processed it.
- No duplicates. A message the middleware lists twice is picked up only once.
- The page does not refresh by itself. Reload it to see newly collected messages and the latest poll health.
- Interrupted sends are not repeated. If Int4 Suite is restarted while a message is being sent, that send is marked failed rather than sent again, because a duplicate message in the middleware is worse than a visible failure.
- What a synchronous caller sees. A wrong username or password gets
401; an endpoint that is not switched on, does not exist or does not match the path pattern gets404; a method the trigger does not accept gets405; a flow that takes longer than its timeout gets504; a failed flow gets500— the details are on the message in the instance. Credentials the caller sends are never stored with the message. - Endpoint names are unique per channel. Two instances on the same channel cannot share an endpoint name, regardless of case.
- Retention and project scope are fixed in the app. The page shows the retention period in force but offers no field to change it, and the project scope can only be chosen when the instance is created.
Related features
- Virtualization objects — define what an instance catches and how it answers.
- External Channels — entry points and credentials for synchronous callers.
- System Landscape — the groups instances run in.
- Systems Under Test — the systems an instance reads from and sends to, and their production flag.
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. Seeing instances needs Virtualization Instance: Read; opening one needs Read in its project scope. Creating one needs Virtualization Instance: Write plus Virtualization Object: Read on the object, and External Channel: Read when you choose a channel. Switching on needs Virtualization Instance: Execute and System Under Test: Execute on every system the instance reads from or sends to. Switching off, changing the response mode and sending held messages need Virtualization Instance: Execute; sending also needs System Under Test: Execute on the receiving systems. Virtualization Instance: Write allows changing the endpoint, and Virtualization Instance: Delete deleting.