RFC Check
RFC Check is a test that will verify RFC Destinations. It can perform validation of the connectivity, authorizations, logon data and properties like host, port etc.
Top of the screen with Automation Object (AO) ID, description and test type.
Basic Information
Parameter name | Description | Example |
Execution system line | System line where the RFC Checks will be performed. Used during execution to determine system based on system line / landscape combination. Actual RFC Connection to be tested is stored in Test Case an Document Number. | S42CLNT100 |
|---|
Parameters
Parameter name | Description | Example |
RFC Connection Test | This flag needs to be checked in the case of connectivity tests. By default only RFC existence check is execute. With this flag connection is also verified. | Yes/No |
|---|---|---|
RFC Authorization Test | This flag needs to be checked in the case of logon data tests. | Yes/No |
Validate RFC Properties | This flag needs to be checked in the case of RFC properties tests. When selected RFC data is stored in test case during save. It is possible to use wildcard '*' to skip validation of certain properties. | Yes/No |
HTTP Operation for connection test | Used in connection tests for destinations type G or H to change default http method (GET) | HEAD |
Expected HTTP Return Code | Used in connection tests for destinations type G or H to validate expected HTTP response code | 200 |
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.
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.
