Business Objects
Overview
A Business Object is a reusable bundle of scripted, system-driven steps that you build yourself, so you can drive integration scenarios the built-in test types do not cover. Think of it as a small, named recipe: you declare the parameters a tester will supply, and you arrange a set of ordered connections — each one an RFC call, an HTTP request, a database selection, or a script-only step — under five fixed actions.
The typical job a Business Object solves is provisioning bespoke test data. Where the built-in test types capture and replay an interface message, a Business Object scripts the calls that recreate a real business document — a Sales Order, Purchase Order, Delivery, or Material Master — repeatably in a test system, based on a reference document. In practice this lets you turn, say, a production Sales Order into a test case that reconstructs the same order on demand. The five actions are that provisioning lifecycle: list the candidate documents, build the input and the reference output, execute the creation, then fetch the result so it can be compared against the reference.
The five actions describe what a Business Object can do during a test run: Get List, Create Input, Execute, Reference Outputs, and Result Outputs. Each action runs its connections in order. You do not run a Business Object directly from this screen; instead you reference it by name from a Business Object automation object, which runs its actions while a test executes.
Business Objects are named, versioned, and scoped to a project. The name must be unique among the Business Objects that are currently active, and every change you save creates a new version while keeping the old ones available to view and restore. Each Business Object can also point each action at a SUT VMap, so the concrete system a step talks to is resolved late — at run time, from the active SUT Group — rather than being hard-wired here.
This screen lists every Business Object you can see; from it you open, create, edit, copy, delete, and review the version history of each one.
Tasks
How to create a Business Object
- Click Create New. (If the button is greyed out, you do not have Write permission — see Prerequisites & permissions.)
- On the General tab, enter a Name (1–40 letters, digits, or underscores) and an optional Description.
- Choose a Project Scope, or leave it global. The scope controls who can later read, edit, and delete this Business Object.
- Optionally set a Default SUT VMap (fallback for all actions) — this is the fallback system mapping used by any action that has no mapping of its own.
- Optionally edit the JSON Config — free-form configuration in JSON that your scripts can read at run time. It must be valid JSON.
- Add Parameters and Connections as described below.
- Click Save. The new Business Object opens in view mode.
How to add parameters
Parameters are the inputs your Business Object exposes to the test that uses it. On the Parameters tab:
- Click Add Parameter.
- Fill in the Parameter ID (1–40 letters, digits, or underscores — must be unique within this Business Object) and an optional Description.
- Pick a Type: Text, Checkbox, Date, or List.
- Set the Default. For a List parameter, enter the allowed choices as a comma-separated list (for example
val1,val2,val3); the test that uses this Business Object then picks one of those choices. - Turn on Dynamic if the parameter should appear only on the Message Selector at test time, rather than on the automation-object screen.
- Use the remove control to delete a parameter row.
How to add connections
Connections are the individual steps that run inside each action. On the Connections tab you will see one section per action.
- In the section for the action you want (for example Execute), optionally set the Action default SUT VMap — the system mapping that every connection in this action uses unless it overrides it.
- Click Add Connection to add a step.
- Choose a Connector:
- Pass-through (scripts only) — runs only the before/after scripts, no protocol call.
- RFC — calls an SAP function module. Enter the Function Module, and optionally tick Commit or Skip Client Role Check.
- HTTP — issues an HTTP request to the system's HTTP destination. It takes no extra fields here; the request is shaped by the destination and your scripts.
- DB Selection — runs a database selection. Pick a DB Ruleset.
- Optionally set a SUT VMap override to point this one step at a different system mapping than the action default.
- Optionally set a Delay before (s) to pause before the step runs.
- Optionally pick a Before-Transform Script ID and/or After-Transform Script ID to transform data immediately before and after the step.
- Reorder steps within an action with the move-up and move-down controls, and remove a step with the delete control. Use Expand all / Collapse all to manage long lists.
Field reference
General
| Field | Description |
|---|---|
| Name | The business identifier, 1–40 letters, digits, or underscores. Used to reference this Business Object from an automation object. Must be unique among currently active Business Objects (older versions may reuse a freed name). Cannot be changed after creation. |
| Description | Free-text label. |
| Project Scope | The project scope that governs who can read, edit, and delete this Business Object. May be left global. |
| Default SUT VMap (fallback for all actions) | The system mapping used by any action that does not set its own. The concrete system is resolved at run time from the active SUT Group. |
| JSON Config | Free-form configuration in JSON, made available to your scripts at run time. Must be valid JSON. |
| Version Description | Optional note describing what changed in the version being saved. |
Parameter fields
| Field | Description |
|---|---|
| Parameter ID | The parameter's name, 1–40 letters, digits, or underscores. Must be unique within this Business Object. |
| Description | Free-text label for the parameter. |
| Type | Text, Checkbox, Date, or List. |
| Default | The default value. For List, this is the comma-separated set of allowed choices instead of a single default. |
| Dynamic | When on, the parameter is shown only on the Message Selector at test time; otherwise it also appears on the automation-object screen. |
Connection fields
| Field | Description |
|---|---|
| Connector | The kind of step: Pass-through (scripts only), RFC, HTTP, or DB Selection. |
| Action default SUT VMap | The system mapping every connection in the action uses unless it overrides it. |
| SUT VMap override | A per-step system mapping that takes priority over the action default and the Business Object's default mapping. |
| Delay before (s) | Seconds to wait before the step runs. |
| Before-Transform Script ID | An optional script run just before the step, to transform its input. |
| After-Transform Script ID | An optional script run just after the step, to transform its output. |
| Function Module | (RFC only) The SAP function module to call. |
| Commit | (RFC only) Issue a commit after the call. |
| Skip Client Role Check | (RFC only) Skip the client role check. Only takes effect on the Execute action; setting it on other actions is silently ignored. |
| DB Ruleset | (DB Selection only) The database ruleset to run. Referenced by name. |
Tips & edge cases
- Names are unique only among active Business Objects. If you delete or rename a Business Object, its old name becomes free for a new one. Saving a name that another current Business Object already uses is rejected.
- The name is locked after creation. To change it, copy the Business Object under the new name.
- Connection order matters and is set by the list. Steps run top-to-bottom within each action; use the move controls to arrange them. You cannot type an explicit position number.
- References are by name, not by identity. A Business Object is attached to a Business Object automation object by name, and a DB Selection step references its database ruleset by name. Renaming or deleting the referenced item breaks the link silently — it only fails when a test is saved or run.
- Systems are resolved late. Each action and step references a SUT VMap, not a concrete system. The actual system is chosen at run time from the active SUT Group, so the same Business Object can run against different landscapes. A non-Pass-through (scripts only) step with no resolvable mapping is a configuration error at run time.
- Deletion is permanent. Deleting removes the Business Object and all its versions with no recovery.
- A Business Object produces test cases; it is not one. It sits on the reusable-configuration side of Int4 Suite, the same side as automation objects — its purpose is to create the documents that become test cases, not to be executed on its own. That is why you never run it directly from this screen: a Business Object automation object references it by name and drives its actions while a test runs.
- The before/after scripts keep test-execution data apart from test-data collection. Each connection's optional before-transform and after-transform scripts let you shape the data going into a step and the data coming out of it independently. This is what lets one Business Object present a clean, unified interface to the test while the connector-specific details (the function module, the HTTP destination, the database ruleset) stay hidden inside the step.
Related features
- Automation Objects — the Business Object automation-object type references a Business Object by name and runs its actions during a test.
- Systems Under Test — the connection profiles that a Business Object's steps ultimately target.
- Value Mappings (SAP PO) — related landscape mapping configuration.
Prerequisites & permissions
Access to this screen is controlled by the Business Object resource permission:
- Read — required to open the list and any Business Object's detail or version history. Read is also re-checked against each Business Object's project scope.
- Write — required to enable Create New and to edit, copy, or restore. Creating or moving a Business Object also requires Write on the target project scope.
- Delete — required to remove a Business Object and its versions.
The list itself is unscoped, but opening a specific Business Object re-checks your permission against that object's project scope, so you may see fewer details than the list count suggests.
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.