File Inbound
File inbound is a test that will upload the file to specified location in SAP Backend via RFC interface.
Top of the screen with Automation Object (AO) ID, description and test type.
Test Case Creation
Parameter name | Description | Example |
Inbound file: Search path (logical)
| Logical path where the source files are stored. File with name defined in document number field will be downloaded via RFC and stored in test case as “Inbound File backend” payload. | ZTESTPATH_ARC |
---|---|---|
Inbound file: Search pattern
| Search pattern for files in in search path. | *.csv |
Test Case Execution
Parameter name | Description | Example |
Inbound file: target path (logical) | Logical path where the source files will be uploaded. | ZTESTPATH |
---|---|---|
Inbound file: target file name | Name pattern for uploaded file. Name accepts variable placeholders. | New_{NEXTNUM}.csv |
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: | ? |
Other
Parameter name | Description | Example |
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 |
---|---|---|
File encoding | Code page of the file. The parameter is used to provide code page information to expression handlers and parses in case code page cannot be determined e.g. from metadata or file header. SAP Code page number is expected as a value. Possible values can are available in the table TCP00. | 1100 (1100 corresponds to ISO 8859-1) |
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) |
Execute XSLT on input payload (req. TC number with XSLT) | Run XSLT Transformation on input payload before any other execution steps. Test Case number of type XSLT Transformation is expected as an input. | 12345 |
Execute XSLT on input payload after variable replacement | Run XSLT Transformation on input payload after variables are replaced with new values. Test Case number of type XSLT Transformation is expected as an input. | 12345 |
Execute XSLT on ref. output payload(req. TC numb. with XSLT) | Run XSLT Transformation on output reference message (output stored in Test Case as reference). Test Case number of type XSLT Transformation is expected as an input. | 12345 |
Execute XSLT on cur. output payload(req. TC numb. with XSLT) | Run XSLT Transformation on current output message (output generated during Test Case execution). Test Case number of type XSLT Transformation is expected as an input. | 12345 |
Flag for Flat File interfaces | Used to mark interface input as Flat File | X |
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. |
|
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 |
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
|
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. |
|
Backend Systems
Parameter name | Description | Example |
Backend system line for current doc. | This parameter points out the system where the tested 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 the reference documents are 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) | 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. |
|
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) |
© 2017 - 2022 Int4 AG All rights reserved