Azure Service Bus
Azure Service Bus is a test that will inject the message to the Microsoft Azure Service Bus queue. It will perform validation of the middleware platform outbound message as well as validate database entries created by the message processing in the backend ABAP based system.
Payload for this test type has to be manually provided in the APITester Cockpit.
Basic Information
Parameter name | Description | Example |
Queue name | Microsoft Azure Service Bus queue name | queue1 |
|---|
Parameters
Parameter name | Description | Example |
HTTP RFC Destination | Type G RFC destination pointing to server where Service Bus queue is deployed | AZURE_SB1_HTTP_DEST |
|---|---|---|
Authorisation request (TC) | ||
HTTP Header | Optional list of HTTP headers to be added to the request | x-custom-header=12345 |
Do not fail TC if DB reference not found | This flag determines if in the situation when DB validation for reference messages have not been found whether it should be treated as Error or Successful message. | Checked or 'X' - if reference document is not found test case will not be failed Unchecked or '' - if reference document is not found test case will be failed (default setting) |
File Type - Input | Input File Type | Auto-detect, XML, Flat file, JSON |
File Type - Output | Output File Type | Auto-detect, XML, Flat file, JSON |
Execution Settings
In this section there are common execution settings for all test cases.
Debug Log
This feature enables additional debugging messages to be included in the test execution log. Typically, this option is disabled, as a log with debugging information can become cluttered with details unnecessary for standard test execution. However, it proves invaluable during the initial phases of working with Int4 Suite, as it provides insights into each unsuccessful run and aids in identifying and resolving connectivity and security issues.
Display Wait Popup Before Validation
In specific scenarios, there may be a need for manual intervention between the message injection by Int4 Suite and the readiness for test validation. For instance, when an XML message is injected into SAP CPI, mapped to an IDoc, and subsequently transferred to SAP S/4, the IDoc may be processed automatically by the backend. However, certain configurations could hinder this automatic processing. In such cases, the tester must log into S/4 to manually request IDoc processing. The wait popup feature facilitates this by allowing Int4 Suite to send the message and display a popup before commencing backend data validation. This gives the tester time to complete the IDoc processing, return to Int4 Suite, and confirm the popup. Only after this confirmation will Int4 Suite proceed with data validations.
Delay Between Execution and Validation
Similar to the wait popup feature, these options allow for a delay to be configured between the initiation of the test run and/or between the injection of test case data and the validation of results. If it is anticipated that backend processing or integration platform mapping may require a considerable amount of time, this section allows for the configuration of such delays. As a result, Int4 Suite will pause before attempting to validate the integration platform and/or the backend, depending on the type of test being executed.
Variables
Variables are the container for values that can be used during testing. Each variable contains two values, the one that is calculated based on the reference message/document and the one that is calculated ad-hoc during test case execution.
There are various scenarios where variable processing can be beneficial:
Updating document/message content before test execution
Capturing data from document/message content after execution
Matching documents based on variable content
Passing data between test cases
For more details on Variables and their processing, read here: Variables & Variable processing
Create button allows variable creation.
Parameter name | Description | Example |
Name | Variable technical name | VARIABLE_1 |
|---|---|---|
Description | Free text for variable description | Variable One |
Type | Type of variable processing | Read & Replace Find message Custom |
Scope | Variable scope
| Test Case |
Private | Specifies that the variable is not accessible to child test cases |
Local Scripts
Local Scripts enable you to define custom scripts that are available within the context of the current Automation Object.
These scripts can be utilized in the following areas:
Variable Processing
Payload Processing
Custom Validations
Please consult the Int4 Aster Documentation for details on the scripting language.
Custom Validations
Custom Validations offer enhanced flexibility for evaluating test case results by allowing the implementation of custom logic using ASTER Scripts.
Within the script, you can access test execution data using built-in Int4 Suite functions such as:
GET_TC_VAR– to retrieve test case variablesGET_VALIDATION_PAYLOADS– to access payloads used during validation
For the test case to be marked as successful, the script must return a _TRUE_ value.
Number Ranges
Int4 Suite uses own 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 of original document numbers or other values is described in the section Variables & Variable processing.
Below you will find information how to create a new number range.
The number range used to replace the source system document number should always be configured to not overwrite the original numbers. It means that documents generated by Int4 Suite should have their own subset of the original document number. Usually, it might be a subset of the upper limit of the original number range.
It is essential that automated testing with Int4 Suite doesn’t consume numbers that the source system will generate during manual testing. Additionally, if testing environment data is refreshed from the production system, more documents would be created in the testing environment. If the Int4 Suite number were configured in the same range, it would start creating duplicates.
For example, the original number range for document numbers from the source system is 560000 - 590000. It would be wise to set the Int4 Suite number range from 590000 to 600000. However, suppose the SAP backend system uses an external number range. It is essential to stay in the original range. In that case, the Int4 Suite number range may be set as 585000-590000, which gives space for 5000 testing documents. Using range from upper interval reduces the risk that the number will be overwritten.
Additionally, the good practice is to use prefixes or suffixes that will quickly separate source system documents and the ones created by Int4 Suite. It should always be used when there is no document number validation by the SAP backend.
Each Object Definition can contain an unlimited number of number ranges. This way, each variable declared in an object can use its specific number range.
Parameter name | Description | Example |
Number range | Provide a name for the number range. This name would be passed as a parameter in variable processing for actions that will generate values from it. | NUM_RAN |
|---|---|---|
Prefix | The alphanumeric characters to be appended at the beginning of the document number to separate original documents from source systems and the one created during Int4 Suite testing (optional). | INT4_ |
Low value | The first number of our range. | 1 |
High value | The last number of our range. | 999999 |
Current value | When the number range is used during testing, it would increment per each use. | 23 |
Suffix | The alphanumeric characters to be appended at the end of the document number to separate original documents from source systems and the one created during Int4 Suite testing (optional). | _TEST |
Add zeros | If this box is checked, zeros will be automatically appended to the beginning of the document number, such as 000500. |
|
Incr. per Test Run | If this indicator is selected, the number range is incrementing once per test run. If multiple test cases with the same Automation Object exist in the test run, they will receive the same value. |
|
Backend Systems
Backend systems in an Automation Object specify the SAP backend system (S/4HANA, ECC, or other ABAP-based systems) where to read a new document created by interface processing during test case execution. It also defines where the reference document was posted, serving as the source. The two documents will be compared in the test case results.
The given system line and source and target environment will be translated to the RFC destination in the runtime. Int4 Suite uses this RFC connection to execute dedicated function modules and retrieve data from the system’s database for comparison.
Find out more at Int4 Suite Internal Organization | Environments-and-System-Lines.
Depending on your testing scenario, both the current and reference system lines can be the same or different. For regression testing, they are typically the same, such as S/4HANA. The testing landscapes, however, may differ, e.g. Test and Production, where the system reads the reference from Production and the current document from Test. For migration scenarios, such as ECC to S/4HANA, the reference would usually be ECC, and the current would be S/4HANA.
Parameter name | Description | Example |
Backend system line for current doc. | This parameter points out the system line where the test interface processing triggered by Int4 Suite will create test document during test case execution. | S/4HANA |
Backend system line for reference doc. | This parameter points out the system where the reference backend document is stored. The value should be a system line described in the landscape configuration. | ECC |
External Links
External Links enable linking from Test Results and from Process Flow chart to business and system objects in external systems.
To link to external documents, the document reference (e.g. a number) must be captured by a Variable. The Variable number may be then used in link title and URL Template to construct a link to the document view. Based on Your Configuration , System Line might be specified, to create a link in the context of a specific business system.
Possible document links:
Regular URL definition
SAP Web GUI - following the template:
/sap/bc/gui/sap/its/webgui?~transaction=*VA03 VBAK-VBELN={SO};DYNP_OKCODE=ENT2SAP GUI link - generated by Int4 Suite service:
/sap/bc/int4/iftt/launcher/gui?~transaction=*VA03 VBAK-VBELN={SO};DYNP_OKCODE=ENT2
To generate SAP GUI/WebGUI links, the transaction code (e.g. VA03), selection screen parameters (e.g. VBAK-VBELN) and DynPro OK Code (e.g. ENT2) must be know. They are dependent on the specific SAP transaction. This information can be obtained from a functional expert or directly from SAP GUI by analyzing the fields on transaction screen.
Database Validations
This feature is available only in APITester.
Int4 Suite enables reading and comparing documents posted in SAP Backend systems (like S/4HANA, ECC or any other ABAP based systems). In such case Automation Object require selection of https://int4support.atlassian.net/wiki/x/AYCmew. DB Validation Ruleset represents a document in SAP like a sales order, an invoice or any other transactional document. The rulesets can be re-used across multiple Automation objects.
Find more how such comparision look like inTest Case Execution and Reporting | SAP-Backend-Document-Validation .
Parameter name | Description | Example |
Database validation ruleset | Reference database validation ruleset object name. Database validation ruleset specify how related backend validation should be performed. Specify tables, fields and join conditions for the backend validation. Buttons allow navigation to the chosen database validation ruleset and creation of a new database validation ruleset | GENERIC_SO |
|---|---|---|
Persist reference DB Data | When switched on, DB reference data will be fetched from backend system during test case creation. Otherwise, it will be dynamically fetched during test case execution. if there is a need to refresh stored DB references in existing test cases please refer to Persist reference backend documents |
Payload Processing
This capability is particularly useful in migration projects and the Test Driven Development approach, where the payload structures of new solution interfaces may differ but contain similar content.
Following processing methods are available:
XSLT Transformation
ASTER Script
Payload processing can be applied on both Input and Output payloads.
XSLT Transformation is stored in a reference test case of type XSLT Transformation. To call XSLT Transformation during Test Case execution, Test Case number that is of type XSLT Transformation needs to be provided as an input to one of the below parameters.
Example usage of XSLT transformations can be found here XSLT transformation examples | Different-order-of-XML-nodes-in-a-new-solution.
ASTER Script for Payload Processing can read current payload using GET_CONTEXT_PAYLOAD function and should return updated payload as a result of evaluation
Parameter name | Description |
Processing Type |
|
|---|---|
Method |
|
Parameter |
|
Data Scrambling
Data scrambling enables to reduce or remove 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.
Parameter name | Description | Example |
Rule Type | Rule type. Available options:
| Test Case Creation |
|---|---|---|
Rule | Free text to specify scrambling rule name for identification. | NAME |
Method | Choose a scrambling method from a list. Available methods:
| HASH |
Expression Type | Expression type. Available options:
This field is optional for all interfaces where there is a single type of output. However, for interfaces that output might be both XML and flat file, it is mandatory to specify the expression type. | XPath |
Expression | Path pointing to the field/node where the exception should be applied. | //ORDER/DATE/text() (XPATH expression) or START_TAG(BGM+220+)&&END_TAG(+)&& (Flat file expression) or $.order.date (JSONPath expression) or REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Parameter | Specify Additional Parameter suitable for a chosen scrambling method like X (for Mask method), SHA1 (for HASH Method) |