Automation Objects

Automation Objects contain configuration for each test execution. Automation Objects define the interface under test, test conditions, and necessary data manipulation. Automation Objects can also point to other objects, UI scripts, database validation definitions, and more.

Open

Automation Objects Management

To start working with Automation Objects go to the Fiori launchpad and select the Automation Objects tile.

Open

Fiori Launchpad with Int4 Suite tiles, Automation Objects highlighted

Automation Objects list will open, with typical list filtering features available.

Elements of Automation Objects list

• Automation Obj. - technical name of automation object

• Description - user friendly free form description

• Type - Type of test case supported by the Automation Object

• Interface - Interface name as defined in the Automation Object

Automation Object list features

• List filtering

• Create new Automation Object

• Copy selected Automation Objects

• Delete selected Automation Objects

• Export selected Automation Objects to file

• Import Automation Objects from file

• Export Automation Objects lists to spreadsheet file

Working with Automation Objects

Clicking an Automation Object from the list or creating a new one will open Automation Object edition screen.

Automation Object edit screen sections

First items from top are the automation object name, description and assigned test type. Then the screen is divided in several sections. Navigation between these sections is possible by scrolling or clicking the section names.

Basic Information

This section contains the basic information about the integration being tested. Depending on selected test type this section will contain different fields, relating to the specific integration technology - e.g. for SAP IS (CPI) these would be the iFlow name.

Backend Systems

Backend Systems allows to specify the system lines for database validation. The specified systems lines are read from the configuration and, together with landscape on which the test case is executed, map to a RFC connection. Int4 Suite uses this RFC connection to execute dedicated function modules and reading data from the system’s database for comparison.

Two system lines need to be specified. The current doc. system line points to the system where we expect to find data from current test execution. The reference document will be read from the system specified by reference doc. system line.

Database Validations

Database Validation ruleset points to a specific Database Validation object. Its settings are read and used for execution of the database tables and fields comparison. This allows for single database validation ruleset to be used with multiple Automation Objects.

Persist reference DB Data parameter, allows user to decide when the DB Reference Data should be fetched. If it’s switched on, it will be done during test case creation and stored as a test case payload named Reference DB Data. Otherwise, it will happen during test case execution.

In Test Case Details screen in Payloads section user can refresh this data using button or manually edit it by clicking on the Reference DB Data row in edit mode.

Option for refreshing Reference DB Data for many test cases at once is available in Int4 API Tester Cockpit main screen. This action can be performed for all test cases in the folder or for the selected items.

Variables

Variables in Int4 Suite represents a complex feature that allows for data manipulation in the processed test cases. There are various scenarios where Variable processing can be useful:

• Updates of document / message content before test execution

• Capturing of data from document / message content after execution

• Matching documents based on the Variable content

• Passing data between test cases

In this section You can add, remove and edit Variable settings.

Payload Validations

Payload Validation enables additional checks on message content and structure. In this section You can create, edit and delete these rules. Use the “Create” button or the “X” icon for creation and deletion respectively.

Int4 Suite basic test execution will compare the messages (reference and current execution) and report any difference as error, and fail the test. While this might be OK for some migration scenarios, not all message differences are errors, some differences are even expected.

Definition of Payload Validation rule consists of

• Description - free form text describing the purpose of the rule

• Expression type - XPath or Flat File expression

  • XPath is a standardized way of locating nodes and data in XML messages. For JSON messages, JSONPath syntax is accepted as expression if XPath type is selected.

  • Flat File expressions language is developed by Int4 and allows for matching text patterns in flat file processing. Please read here for more details: Expression language for flat files

• Expression - the XPath, JSONPath or Flat File expression

• Rule - specifies the behaviour if data differs at the point specified by the Expression

  • Ignore - the difference has no impact on test result

  • Warning - the difference will trigger a warning and will be highlighted in the test report

  • Warning when different based on Variable replacement - the difference will trigger a warning, if the data matches data in a Variable, otherwise the difference will trigger an error

  • Warning when different based on Value Mapping - the difference will trigger a warning, if the data matches the definition in the Value Mapping, otherwise the difference will trigger an error

• Parameter - additional parameter for processing - Variable name OR Value Mapping name for comparison

Payload Matching

In scenarios with multiple outputs for the same receiver, there is a need to compare them based on the same order as reference documents used for test case creation. Integration Platforms don’t guarantee that outputs will always be sent in the same order control; therefore, the solution is to sort the messages before comparison.

Please see the detailed pages for specific test types for more information.

IDoc Status Validations

IDOC Status Validation parameters are used to override default status handling rules for Inbound and Outbound IDOC test types. Please see the relevant test type (IDoc Inbound, ) manual page for more details.

Execution Settings

For each test type, there are various settings for detailed control of test case execution. While more details can be found on the manual pages referring to specific test types, these are some general types usually found in the Automation Object.

Debug Log

Enables additional debugging messages in the test execution log. This is normally not enabled, as the execution log with debug will contain many details not needed for normal test execution. It is very useful for early stages of work with Int4 Suite, as it explains the details of each unsuccessful run and helps to track down and resolve connectivity problems and security issues.

Display wait popup before validation

In certain scenarios, between the message injection by Int4 Suite and readiness for test validation, manual steps must be taken. Imagine a scenario where XML message is injected into SAP CPI, where it’s mapped to an IDoc and transferred to SAP S/4. Such an IDoc might be processed automatically by the backend, but certain configurations might prevent that from happening. In such case, the tester will have to log into S/4 and manually request IDoc processing. This can be handled using the wait popup. Int4 Suite will send the message and display popup, before starting to validate backend data. Thanks to this, the tester can go to the system, complete IDoc processing, get back to Int4 Suite and confirm the popup. Only then Int4 Suite will do the data validations

Delay between execution and validation

Similarly to the wait popup, these options introduce a delay between starting the test run and/or between injecting test case data and result validation. If we know that backend processing or integration platform mapping could take a significant amount of time, in this section such a delay can be configured. Thanks to this Int4 Suite will wait before trying to validate integration platform and/or the backend - depending on the test type.

Number Ranges

Int4 Suite uses private number ranges for data processing needs. Quite often, when sending test data to test systems again and again, the message can’t be exactly the same. For example, sending the same purchase order to generate sales order in S/4 could result in an error, if the system is configured to treat such situations as duplicates. Also, having a specific data field in the document might be mandatory to find another document - e.g. by generating an unique PO number for the Sales Order, we can find the newly created Sales Order in the database. The actual mechanics for such replacements is described in the section Variables & Variable processing.

Number range definition consists of:

• Number range name - a technical code identifying the number range

• Prefix - string of characters added before the resulting number

• Low value - starting value of the number range

• High value - final value of the number range

• Current value - value which will be assigned when the number range is next used

• Suffix - string of characters added after the resulting number

• Add zeroes - check to add leading zeroes so that the number has always the same length

• Incr. per Test Run - normally the number is increased each time the test case is executed. If this is not desirable, the number range will advance only once per test run if this is checked

Data Scrambling

Data scrambling enables to reduce or remove any GDPR, privacy and security concerns when it comes to testing. When Int4 Suite is extracting the test data from existing messages or reports testing results, the visibility and availability of sensitive data could be an issue. To avoid this issue, sensitive data can be scrambled. Scrambling can occur at test case creation time and during the test execution. Actual behaviour of the scrambling engine is configured by a set of rules.

Data scrambling rule settings

• Rule type - decide when the rule needs to execute, at Test Case Creation or at Runtime

• Rule - free form text description of the rule

• Method - actual scrambling method

• Expression type - XPath or Flat File. See the Payload Validation section for more details on these Expressions

• Expression - actual expression that points to specific data object in the message

• Parameters - additional parameters for specific Methods\

Available scrambling Methods

• CONSTANT - replace data with a constant text, provided in the first Parameter

• CUSTOM - calls a custom ABAP code for scrambling - takes both Parameters as input

• GUID - generates an unique ID based on the scrambled value

• HASH - generates a numerical shortcut (using one-way hash function) that represents the scrambled value

• MASK - replace each character in the value with a character specified in the first Parameter

• RANDOM - generates a random number value

Parameters

Parameters control interface technology specific behaviour of the testing program. They vary significantly, based on the selected test type for the specific Automation Object. Please see the manual pages for specific test types for details on these parameters.