Message filtering and validation

Answer

Refer to the IBM Rational Test Workbench (RTW) Knowledge Center in conjunction with this technote.

Filter

The Filter tab is used to test the received message for structure and value before any further processing can take place.

If all filter rules fail, the message is ignored. Filtering is used under the covers in stubs and in the Message Switch action. If a filtering rule fails, the message is passed to the next message processor. This is the next Event of the same type in a stub, or the next Message Case in a Message Switch.

If filtering passes, further processing can take place and this can include validation.

Filtering is used when more than one type of message is to be received on the same transport. For example a single message queue receives both Add and Subtract messages for the IBM Rational Test Control Panel (RTCP) Calculator example service. You configure filtering to detect specific structures and values in a matching message type, and then take appropriate action such as validation, store or further test steps.

The following screen capture shows a stub that is configured to receive both Add and Subtract requests.



The stub filtering mechanism first checks for the Add type of message structure by looking at the HTTP header (SOAPAction) and resource (URL). If the headers match the Subtract message it is passed to the Subtract event handler

Further message filtering is then possible as shown below:


In this case the message must be of type Add and the values to add must be 10 and 20.
Note the filter icon showing enabled fields.

The equivalent message filter configuration in a test action is shown below:


It is possible to configure a stub to receive multiple messages that are very similar in content. Consider this stub that receives Add requests:



The message matches the Add request so is tested against the filtering in the first Event. In this case it is checking for the data fields to be 10 and 20.
If this filter match fails it is passed to the next Event to check for 30 and 40.
If this fails, the message falls through to the final Event where action can be taken to process the message or pass it through to the real system.

Assert

The Assert tab is also used to validate message content and structure. However the difference is that if Assertion fails the test will fail.

The settings in the Assert tab are used when there is no filtering, or when filtering has already passed the message. You now have the correct message to work with and can test the contents of the message for structure and value. If one or more of these conditions fails, the test action will fail. This will fail the test unless can take appropriate action using the Failure Path.

Using the above example in a test, filtering has succeeded and the Add message is to be validated. You want to check if the "Token" field is equal to "Y".




Notes:

• While it is possible to apply Assert rules to messages in stubs, it is not possible to take action using the Failure Path.
  In this case the message is silently discarded.
  
  
• Queue messages are consumed before filtering is applied. So if the filtering rules fail you might need to put the message back onto the queue. This mechanism is called sift and pass through.
  Sift and pass through is also available with HTTP/HTTPS messaging.