A – Test number v1 v2 Test Action Description Expected Results B2B – Existing gateways INTERB1.1 Send a RTR message with correct data Sender application generates a RTR payload that is sent as an AS4/ebMS3 message via the MSH to the receiver MSH which passes it onto the receiver application for processing Tests the chain of communications links between sender and receiver application layers. Also tests the formatting and validation code of each application layer (if applicable to that gateway) Receiver application should have received and processed a RTR message eb:To and eb:From set correctly, INTERB1.2 Send a RTOR message (if applicable to gateway) As above plus the Receiver replies with a RTOR message which the Sender of the original message processes Tests the generation, sending, receiving, routing, validation (if provided by the gateway) of rollover transaction request & outcome response messages Originators of RTR message should receive appropriate RTOR message INTERB1.3 Optional Optional Repeat above test with mismatched payload (if applicable to gateway) Exercise a negative scenario where payloadInfo part properties contain a target fund ABN/USI that is serviced by the destination gateway but where the XBRL payload data does not match the target fund ABN/USI provided in the PayloadInfo part properties. Tests behaviour of application layer in regard to how it deals with mismatched payload and payloadInfo part properties data Receiver should send an RTOR back to the sender with an error explaining that the mismatch. INTERB1.4 Send an IRR message with correct data Sender application generates an IRR payload that is sent as an AS4/ebMS3 message via the MSH to the receiver MSH which passes it onto the receiver application for processing Tests the chain of communications links between sender and receiver application layers. Also tests the formatting and validation code of each application layer (if applicable to that gateway) Receiver application should have received and processed a IRR message
Receiver reviews received message, ignoring payload the message is ignored by the other party Any complexities in relation to certificates used for signing, compression etc., are eliminated by this simple test. It will, however, be necessary to have the SSL certificate configured to https to work INTERG1.3 Send a simplified message from the sender MSH to the receiver MSH with PayloadInfo part properties configured for a particular source / target fund combination As above plus the receiver checks that the received message has PayloadInfo part properties correctly configured for a target fund that their application knows about. This is just a manual check as the MSH is not required to perform this type of validation of application layer entities Parties must communicate to each the desired target ABN and target USI that they would like in the payload info part properties. Proper values are not strictly required for this test but setting them correctly during this test means that they will not need to be changed in subsequent tests where they are required to match particular entities in application layer As above with manual verification that the target/source ABN/USI values in the partinfo properties are as requested INTERG1.4 Test message signing and signature validation As above plus configure MSH to sign messages targeted at the partner you are testing with and validate the signature of messages received from that partner Tests that message signing and validation works for positive scenarios Messages should be signed and be successfully validated As plus configure an incorrect certificate for outgoing messages. Send a message and confirm that receiver responds with a SOAP fault Tests that message validation fails for negative scenarios Messages should be signed and fail validation INTERG1.5 Test message compression As above plus message compression turned on Tests the sender/receiver MSH's message functionality Payload should be compressed across the wire but be uncompressed by the receiving MSH and