...
Top of the screen with Automation Object (AO) ID, description and test type.
...
Basic Information
...
Parameter name | Description | Example |
Integration flow | SAP CPI integration flow ID | PurchaseOrder_Out |
|---|
...
Parameters
...
...
Debug Log
...
Int4 Suite will provide additional, more technical information in Test Execution Report during the running of the test cases if this parameter is set. Therefore, it is recommended to set this option initially and deactivate it when object definition is confirmed after executing the first test cases
...
Display wait popup before validation
...
Wait Flag indicating if Int4 Suite should stop test case execution after sending test case message to middleware. Int4 Suite will show the confirmation box, and the user will decide to continue. This setting can execute manual follow-up actions before running the next test case or checking the validations.
This setup works only with Execute via SAP GUI option of execution
Delay between execution and validation
...
Parameter name
...
Description
...
Example
...
For each test case
...
Delay (in seconds) between test case execution ( sending message) and checking the results.
...
10
...
Once per test run
...
Delay (in seconds) between test run execution ( sending messages) and checking the results.
...
60
Number Ranges
...
The number ranges allow generating new values for variables. Those values are used to substitute original document numbers or other values in reference messages.
The number range used to replace the source system document number should always be configured to not overwrite the original number. 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 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.
Data Scrambling
...
A scramble list is a part of an automation object. For compliance purposes, for example, GDPR purposes, it's required to hide some of the test case fields. Thanks to the anonymizer feature, it's possible to select fields that hold sensitive values and decide what action should be taken to prevent them from being compromised.
Parameter name
Description
Example
Rule Type
Rule type. Available options:
Test Case Creation - in case you want to scramble data during the creation of a test case
Runtime - in case you want to scramble data during runtime - when the interface is executed, and additional data is loaded to test case data.
Test Case Creation
Rule
Specify scrambling rule name for identification.
NAME
Method
Choose a scrambling method from a list. Available methods:
CONSTANT Replace value with constant
The current value will contain the constant passed in the parameter. The constant should be provided as is without any brackets.GUID Generate GUID
Generate random value in a GUID format.
RANDOM Generate a random value
Generates a random value. The value of the parameter defines the upper limit of the range. It is also possible to generate negative numbers. For example, passing -100 in parameter will generate random numbers from -1 to -100
HASH create a hash based on value
Calculates a hash based on the given value using algorithm passed in parameter (default 'SHA1').MASK - replace each character with constant
Replace each character with a constant passed in parameter. For example, passing X in the parameter will replace scrambled data with X signs.CUSTOM - create custom method
create a CUSTOM method (implementing an interface /INT4/IFTT_IF_DATA_SCRMBL_METH).
HASH
Expression Type
Parameter name | Description | Example |
Backend system line for current 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.
Note:
If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in:
a) the original environment of the reference document (for instance, production system)
b) the environment where the current test case execution takes place (for instance, development system)
If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA)
ECC
SAP_ERP
Backend system line for reference doc.
This parameter points out the system line where Int4 Suite should create test documents during test case execution. In most cases, reference documents and documents created during current test execution are stored in the same system line. However, suppose Int4 Suite is used in a migration scenario (for example, migration from ECC to S4/HANA). In that case, the documents might be created in the new system and then compared with the references from the old system.
The value should be a system line described in the landscape configuration.
Note:
If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in:
a) the original environment of the reference document (for instance, production system)
b) the environment where the current test case execution takes place (for instance, development system)
If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA)
S4HANA
Database Validations
...
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
DB Validation Rulesets
...
GENERIC_SO
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.
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
...
Scope determines the processing of procedures that generate unique values like, e.g., GUID or NUM_RANGE.
Test Case Scope - variable is replaced with new values considering values from the currently processed test case. The variable value, which occurs multiple times in the test case payload, is replaced with the same new value. The variable value in different test cases from the currently processed test run is replaced with a new value for each test case.
Test Run - variable is replaced with new values considering values from the currently processed test run. The variable value in different test cases from the currently processed test run is replaced with the same new value.
...
Test Case
Test Run
Payload Validations
...
Output payloads after processing by SAP PI/PO are validated against previously stored references. This configuration enables adding rules with exceptions that will allow for differences.
...
File Type
...
Processing
...
XML
...
...
JSON
...
...
Flat Files, X12, EDIFACT
...
Int4 Flat File Syntax or REGEX
...
Parameter name
...
Description
...
Example
...
Description
...
Free text for the exception rule
...
Field1
...
Expression Type
...
Expression type. Available options:
unspecified
XPath
Flat expression
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)
REGEX(BGM\+220\+(.*)\+) (REGEX expression)
...
Rule
...
Rule to be applied to the field.
...
Warning
...
Marks the compared fields with yellow color as a "warning".
...
Warning when different based on variable replacement
...
In case compared values are different Int4 Suite compares them with specified variable. If reference/current value pair from comparison matches variable values result is marked as "warning".
Variable name used for checking the values has to be specified in the Processing Parameter column.
...
Warning when different based on value mapping object
...
In case compared values are different Int4 Suite compares them with specified values in the Mapping Object. If reference/current value pair from comparison matches mapping values result is marked as "warning".
Mapping Object name used for checking the values has to be specified in the Processing Parameter column.
...
Ignore
...
Even if it is different in the content, it is not highlighted.
...
Parameter
...
Used in correlation with Warning Rules.
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.
...
Parameter name
...
Description
...
Example
...
Rule
...
Free text for rule name
...
Rule1
...
Expression Type
...
Expression type. Available options:
unspecified
XPath
Flat expression
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)
REGEX(BGM\+220\+(.*)\+) (REGEX expression)
Execution Settings
...
Parameter name
...
Description
...
Example
Test Case Creation | ||||
CPI: Block in iFlow to get input payload | ID of the block in iFlow that can be used to get payload before processing from iFlow trace | CallActivity_2 | ||
|---|---|---|---|---|
CPI: Block in iFlow to get output payload | ID of the block in iFlow that can be used to get payload after processing from iFlow trace. Multiple IDs can be specified to support one to many scenario or validate multiple processing steps in iFlow | EndEvent_2 | ||
CPI: Attachment Name to get input payload | Attachment Name from which input payload can be fetched | Source_Attachment | ||
CPI: Attachment Name to get output payload | Attachment Name from which output payload can be fetched | Target_Attachment | ||
CPI: Store ID used to persist message | The name of the store used to persistence the payload. Recommended approach is to use Block IDs instead of Store | BeforeMapping | ||
Output Automation Object | Automation Object(s) used to read the output payloads. This parameter allows for testing scenarios where message is injected into one iFlow and results are compared on a different one. | |||
Child Test Case Automation Object | Automation Object(s) used to link and create child test cases. This parameter allows for automatic creation of linked outbound test cases during save. Following Automation Object types can be used as child: 5 PI E2E Outbound | |||
CPI: Read CPI Headers | Tells the Int4 Suite to read additional technical CPI headers for the response. Default value is ' ' (false). | X | ||
Test Case Execution | ||||
CPI: Adapter type | Sender adapter type in tested iFlow. Int4 Suite supports only HTTP, IDOC, SOAP, PROCESSDIRECT, SFTP. It is strongly recommended to move the sender channel logic to separate iFlow and connect it via ProcessDirect with main integration logic. | HTTP, IDOC, SOAP, PROCESSDIRECT, SFTP | ||
CPI: Variable name as application ID | The variable name to fetch the value for an application ID. In case not provided, the value will be generated automatically. | BUKRS | ||
HTTP Header | Add custom HTTP header sending to CPI. There are two methods to use this parameter:
| Header1=123 (Method 1) or Header2={Variable2} (Method 2) | ||
CPI: Externalized Parameter | Int4 Suite can change value of the externalized parameter before triggering a test case and revert the change back after test case execution. For example you can change your regular PROCESSSDIRECT outbound connection to dummy one and prevent sending message to the receiver. Many parameter can be provided for single automation object in form of <ParameterName>=<ParamterValue>
| Receiver1=IFTT_Default_Out | ||
Flat File Line Separator | The character used for end-of-line determination in Flat File messages: for example, CLRF - Unix. The parameter is used to display the comparison report better and display the reference and new message line by line. "Carriage Return and New line" character should be stored as CRLF "Line Feed" should be stored as LF (Unix based files) Separator can be also specified using hexadecimal representation of Numeric Character Reference (NCR). There is no default value, so the parameter is obligatory for CSV files Use || to enter multiple alternative separators e.g. CLRF||' | CLRF
NCR Example: | ||
Line Separator Escape Character | Escape character for line separator. Used to avoid line breaks in case separator is used in the file content. Source: Split: | |||
Flat Files Compare with payload validations applied | If this checkbox is checked, Payload Validation rules are applied before files comparison and the match content is replaced by the placeholders. This can in some cases result in better flat file comparison results, especially in case of many missing lines. | |||
File Type - Input | Determines processing of input files ( variable extraction & replacement). Possible values:
| |||
File Type - Output | Determines processing of output files ( variable extraction & payload comparison). Possible values:
| |||
Show XML in the original order (unsorted) | This flag determines if the lines of the file in the XML Comparison Report should be displayed in the original order or should be sorted alphabetically for a specific nodes. | Checked or 'X' - payload will not be sorted on the report Unchecked or '' - payload will be sorted alphabetically (default value) | ||
Do not fail TC if DB reference not found | If this checkbox is set TC won’t fail if no reference document is found in by DB Validation rules | |||
SOAP Adapter | ||||
SOAP Action | The SOAP action if the tested integration flow has a SOAP sender channel | |||
HTTP Adapter | ||||
CPI: HTTP Method | HTTP method if the tested integration flow has a HTTP sender channel | POST, GET | ||
CPI: HTTP Query | HTTP query if the tested integration flow has HTTP sender channel (optional) | param1={MYPARAM}¶m2={MYPARAM2} | ||
CPI: Fetch CSRF Token | If this checkbox is set Int4 Dispatcher will try to call CSRF Token URL to get CSRF token | |||
CPI: CSRF Token Fetch HTTP Method | Methods used by Int4 Dispatcher when calling CSRF Token URL endpoint | HEAD, GET | ||
CPI: CSRF Token URL | URL endpoint used to get CSRF Token | |||
ProcessDirect Adapter | ||||
CPI: ProcessDirect endpoint | ProcessDirect sender channel endpoint | /iftt_pdirect | ||
SFTP Adapter |
| |||
CPI: SFTP Directory | SFTP Directory (folder) where the file should be placed | Tests/Files/Test1 | ||
CPI: SFTP File Name | SFTP File Name that should be used, variable usage is possible like with other parameters | test{MY_VAR} | ||
CPI: SFTP Address | URL of the SFTP server | |||
CPI: SFTP Credential Name | Alias to the CPI credentials from Security Material | |||
CPI: SFTP Private Key Alias | Alias to the private key from Keystore | |||
CPI: SFTP Proxy Type | Proxy Type - default value is “internet” | internet onPremise | ||
CPI: SFTP Location ID | Location ID defined in destination configuration for Cloud Connector. Relevant only for Proxy Type onPremise. | DP1_ERP | ||
AMPQ Adapter | ||||
CPI: SAP Event Mesh Host | SAP Event Mesh host as in the channel under test | |||
CPI: SAP Event Mesh Queue | Queue name from SAP Event Mesh | test/demo/em/int4suitedemo | ||
CPI: SAP Event Mesh OAuth2 Credential Name | OAuth2 Credential Name used in the channel under test. Those should be credentials deployed on Cloud Integration tenant Security Material | EMOAuth2cred | ||
CPI: SAP Event Mesh Content-Type | SAP Event Mesh Content-Type. By default it can be application/xml. | application/xml application/json text/plain | ||
JMS Adapter | ||||
CPI: JMS Queue | JMS Queue name, as in iFlow under test | JMS_QUEUE | ||
CPI: JMS Content-Type | MIME Content-Type | application/xml application/json text/plain |
Backend Systems
...
Parameter name | Description | Example |
Backend system line for current 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. Note: If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in: a) the original environment of the reference document (for instance, production system) b) the environment where the current test case execution takes place (for instance, development system) If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA) | ECC SAP_ERP |
|---|---|---|
Backend system line for reference doc. | This parameter points out the system line where Int4 Suite should create test documents during test case execution. In most cases, reference documents and documents created during current test execution are stored in the same system line. However, suppose Int4 Suite is used in a migration scenario (for example, migration from ECC to S4/HANA). In that case, the documents might be created in the new system and then compared with the references from the old system. The value should be a system line described in the landscape configuration. Note: If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in: a) the original environment of the reference document (for instance, production system) b) the environment where the current test case execution takes place (for instance, development system) If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA) | S4HANA |
Database Validations
...
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 fetched during test case execution. |
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.
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 | Scope determines the processing of procedures that generate unique values like, e.g., GUID or NUM_RANGE.
| Test Case Test Run |
Payload Validations
...
Output payloads after processing by SAP PI/PO are validated against previously stored references. This configuration enables adding rules with exceptions that will allow for differences.
File Type | Processing |
XML | |
JSON | |
Flat Files, X12, EDIFACT | Int4 Flat File Syntax or REGEX |
Parameter name
Description
Example
Test Case Creation
CPI: Block in iFlow to get input payload
ID of the block in iFlow that can be used to get payload before processing from iFlow trace
CallActivity_2
CPI: Block in iFlow to get output payload
ID of the block in iFlow that can be used to get payload after processing from iFlow trace.
Multiple IDs can be specified to support one to many scenario or validate multiple processing steps in iFlow
EndEvent_2
CPI: Store ID used to persist message
The name of the store used to persistence the payload.
Recommended approach is to use Block IDs instead of Store
BeforeMapping
CPI: Read CPI Headers
Tells the Int4 Suite to read additional technical CPI headers for the response.
Default value is ' ' (false).
X
Test Case Execution
CPI: Adapter type
Sender adapter type in tested iFlow. Int4 Suite supports only HTTP, IDOC, SOAP, PROCESSDIRECT, SFTP.
It is strongly recommended to move the sender channel logic to separate iFlow and connect it via ProcessDirect with main integration logic.
HTTP, IDOC, SOAP, PROCESSDIRECT, SFTP
CPI: Variable name as application ID
The variable name to fetch the value for an application ID. In case not provided, the value will be generated automatically.
BUKRS
HTTP Header
Add custom HTTP header sending to CPI.
There are two methods to use this parameter:
Directly filling the header name and header value in format "HeaderName=HeaderValue".
Indirectly by filling the header value using a value from Variable d
defined for this purpose (e.g., named Variable1) in the format
"HeaderName={Variable1}":
please remember to use curly braces ( {} ) while using this method
we recommend using this method for header values containing such characters as: {, =, }.
Header1=123 (Method 1)
or
Header2={Variable2} (Method 2)
CPI: Externalized Parameter
Int4 Suite can change value of the externalized parameter before triggering a test case and revert the change back after test case execution. For example you can change your regular PROCESSSDIRECT outbound connection to dummy one and prevent sending message to the receiver.
Many parameter can be provided for single automation object in form of <ParameterName>=<ParamterValue>
| Info |
|---|
Changing externalized parameter requires deployment of the iflow so the execution time is longer comparing to regular execution |
Receiver1=IFTT_Default_Out
General: Flat File Line Separator
The character used for end-of-line determination in Flat File messages: for example, CLRF - Unix. The parameter is used to display the comparison report better and display the reference and new message line by line.
"Carriage Return and New line" character should be stored as CRLF
"Line Feed" should be stored as LF (Unix based files)
There is no default value, so the parameter is obligatory for CSV files
CLRF
Flat Files Compare with payload validations applied
If this checkbox is checked, Payload Validation rules are applied before files comparison and the match content is replaced by the placeholders. This can in some cases result in better flat file comparison results, especially in case of many missing lines.
Show XML in the original order (unsorted)
This flag determines if the lines of the file in the XML Comparison Report should be displayed in the original order or should be sorted alphabetically for a specific nodes.
Checked or 'X' - payload will not be sorted on the report
Unchecked or '' - payload will be sorted alphabetically (default value)
Do not fail TC if DB reference not found
If this checkbox is set TC won’t fail if no reference document is found in by DB Validation rules
SOAP Adapter
SOAP Action
The SOAP action if the tested integration flow has a SOAP sender channel
http://www.abc.org/po/NewOperation
HTTP Adapter
CPI: HTTP Method
HTTP method if the tested integration flow has a HTTP sender channel
POST, GET
CPI: HTTP Query
HTTP query if the tested integration flow has HTTP sender channel (optional)
param1={MYPARAM}¶m2={MYPARAM2}
ProcessDirect Adapter
CPI: ProcessDirect endpoint
ProcessDirect sender channel endpoint
/iftt_pdirect
SFTP Adapter
| Info |
|---|
CPI: SFTP Directory
SFTP Directory (folder) where the file should be placed
Tests/Files/Test1
CPI: SFTP File Name
SFTP File Name that should be used, variable usage is possible like with other parameters
test{MY_VAR}
CPI: SFTP Address
URL of the SFTP server
CPI: SFTP Credential Name
Alias to the CPI credentials from Security Material
CPI: SFTP Private Key Alias
Alias to the private key from Keystore
CPI: SFTP Proxy Type
Proxy Type - default value is “internet”
internet
onPremise
AMPQ Adapter
CPI: SAP Event Mesh Host
SAP Event Mesh host as in the channel under test
test-example.example.eu10.hana.ondemand.com
CPI: SAP Event Mesh Queue
Queue name from SAP Event Mesh
test/demo/em/int4suitedemo
CPI: SAP Event Mesh OAuth2 Credential Name
OAuth2 Credential Name used in the channel under test. Those should be credentials deployed on Cloud Integration tenant Security Material
EMOAuth2cred
CPI: SAP Event Mesh Content-Type
SAP Event Mesh Content-Type. By default it can be application/xml.
application/xml
application/json
text/plain
JMS Adapter
CPI: JMS Queue
JMS Queue name, as in iFlow under test
JMS_QUEUE
CPI: JMS Content-Type
MIME Content-Type
application/xml
application/json
text/plainParameter name | Description | Example |
Description | Free text for the exception rule | Field1 |
|---|---|---|
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) REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Parameter
Specify Processing Parameter suitable for a chosen scrambling method.
X (for Mask method), SHA1 (for HASH Method)
Parameters
Rule | Rule to be applied to the field. | |
|---|---|---|
| Marks the compared fields with yellow color as a "warning". | |
| In case compared values are different Int4 Suite compares them with specified variable. If reference/current value pair from comparison matches variable values result is marked as "warning". Variable name used for checking the values has to be specified in the Processing Parameter column. | |
| In case compared values are different Int4 Suite compares them with specified values in the Mapping Object. If reference/current value pair from comparison matches mapping values result is marked as "warning". Mapping Object name used for checking the values has to be specified in the Processing Parameter column. | |
| Even if it is different in the content, it is not highlighted. | |
Parameter | Used in correlation with Warning Rules. |
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.
Parameter name | Description | Example |
Rule | Free text for rule name | Rule1 |
|---|---|---|
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) REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Rule Type | Rule type. Available options:
|
|
Parameter | Depending on Rule type:
or
|
|
Group | Free text grouping field. All rules with from the same group have to be fulfilled to match payloads. At least one group has to be fulfilled to match payloads.
Rules within group are linked with AND operator. Groups are linked with OR operator. |
Execution Settings
Parameter name | Description | Example |
Debug Log | Int4 Suite will provide additional, more technical information in Test Execution Report during the running of the test cases if this parameter is set. Therefore, it is recommended to set this option initially and deactivate it when object definition is confirmed after executing the first test cases | |
|---|---|---|
Display wait popup before validation | Wait Flag indicating if Int4 Suite should stop test case execution after sending test case message to middleware. Int4 Suite will show the confirmation box, and the user will decide to continue. This setting can execute manual follow-up actions before running the next test case or checking the validations. This setup works only with Execute via SAP GUI option of execution |
Delay between execution and validation
Parameter name | Description | Example |
For each test case | Delay (in seconds) between test case execution ( sending message) and checking the results. | 10 |
|---|---|---|
Once per test run | Delay (in seconds) between test run execution ( sending messages) and checking the results. | 60 |
Number Ranges
...
The number ranges allow generating new values for variables. Those values are used to substitute original document numbers or other values in reference messages.
The number range used to replace the source system document number should always be configured to not overwrite the original number. 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 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. |
Data Scrambling
...
A scramble list is a part of an automation object. For compliance purposes, for example, GDPR purposes, it's required to hide some of the test case fields. Thanks to the anonymizer feature, it's possible to select fields that hold sensitive values and decide what action should be taken to prevent them from being compromised.
Parameter name | Description | Example |
Rule Type | Rule type. Available options:
| Test Case Creation |
|---|---|---|
Rule | 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) REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Parameter | Specify Processing Parameter suitable for a chosen scrambling method. | X (for Mask method), SHA1 (for HASH Method) |
XSLT Transformations
XSLT Transformation can be applied on both Input and Output payloads and it 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.
Parameter name | Description |
Execute XSLT on input payload | Run XSLT Transformation on input payload before any other execution steps |
|---|---|
Execute XSLT on input payload after variable replacement | Run XSLT Transformation on input payload after variables are replaced with new values |
Execute default oData XSLT on input payload | If this checkbox is set, the predefined XSLT transformation is executed to change XML input into oData JSon format |
Execute XSLT on ref. output payload | Run XSLT Transformation on output reference message (output stored in Test Case as reference) |
Execute XSLT on cur. output payload | Run XSLT Transformation on current output message (output generated during Test Case execution) |
Example usage of XSLT transformations can be found here https://int4support.atlassian.net/wiki/spaces/IUM/pages/1230602260/XSLT+transformation+examples#Different-order-of-XML-nodes-in-a-new-solution.
...