Solace PubSub+ Outbound

Solace PubSub+ Outbound is a test that will listen for messages coming to tested queue or topic and will search for the message based on conditions specified in the Variables of Automation Object. It will check the outbound message triggered by other test case or manual action.

Top of the screen with Automation Object (AO) ID, description and test type.

Basic Information

Parameters

Parameter name	Description	Example
Solace PubSub+ Fetch From	Fetching from Queue or Topic. When Fetching from Queue, program will do the following: Create Queue Binding - connect tested queue with Int4 Suite REST Delivery Point specified in other parameter (and created during technical preparation phase) Wait for messages to arrive in buffer table Match the messages based on variables configuration Delete Queue Binding When Fetching from Topic, program will do the following: Subscribe tested topic to Int4 Suite technical queue (created during technical preparation phase) Wait for messages to arrive in buffer table Match the messages based on variables configuration Delete topic subscription for Int4 Suite technical queue	Queue, Topic
Solace PubSub+ Queue	Solace PubSub+ Queue ID, where the message should be published. Value help will show Queues available in the Selected Message VPN. Applicable only if Queue was selected in Solace PubSub+ Post to parameter.	TestQueue1
Solace PubSub+ Topic pattern	Topic name or topic pattern where the message should be published. Value help will show Topics that selected Queue subscribes to. More about topic patterns can be found at Solace PubSub+ Topic Patterns Applicable only if Topic was selected in Solace PubSub+ Post to parameter.	int4suite/demo12/s4/beh/us/salesorder/Created/v1 int4suite/demo15/s4/beh/us/salesorder/> int4suite/demo*/s4/*/us/salesorder/Created/v1
Solace PubSub+ REST Delivery Point	Rest Delivery Point id created for Int4 Suite Applicable only if Queue was selected in Solace PubSub+ Fetch From parameter.	rdp_TestSystem

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.

In outbound test types, variables play a crucial role in identifying the correct message leaving the system under test. The Find message type facilitates this process and consists of two steps:

• Read: Specifies the value we are searching for.

• Find: Indicates where the value should appear in the payload.

Apart from that 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

• Passing data between test cases

For more details on Variables and their processing, read here: Variables & Variable processing

Example variable definition:

Variable details:

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.

Payload Validations

Output payloads after processing by integration platform are validated against previously stored references.

The basic test execution in Int4 Suite will compare the messages (reference and current execution) and report any differences as errors, causing the test to fail. While this may be acceptable for some migration scenarios, not all message differences are errors; some discrepancies are even expected.

This configuration enables adding rules with exceptions that will allow for differences like document numbers, current time and date and others.

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, then it would be only apply to specific file format (XML/JSON or flat file)	XPath
Expression	Path pointing to the field/node where the exception should be applied. Available syntaxes: XPath, JSONPath, Int4 Flat File Syntax or REGEX JSONPath and XPath are well-known and popular standards for structured data manipulation. You can find a lot of references and educational material on-line. Worth noting are the testing tools that allow You to experiment with XPath or JSONPath definitions. See here: https://jsonpath.com/ http://xpather.com/ Please note that Int4 does not maintain these tools and can’t guarantee for their accuracy.	//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)
Rule	Says how the difference should be marked 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. Change Request The difference will be highlighted green in the test report. Change Request rule are active only when Test Case is run within Test Run type: Change Request Test
Parameter	Additional parameter for rules

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 variables

• GET_VALIDATION_PAYLOADS – to access payloads used during validation

For the test case to be marked as successful, the script must return a _TRUE_ value.

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.