Interoperability test case detail

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

INTERB1.5

Send an IRER message with correct data

As above plus the Receiver replies with a IRER message which the Sender of the original message processes

Tests the generation, sending, receiving, routing, validation (if provided by the gateway) of initiate rollover request & outcome response messages

Originators of IRR message should receive appropriate IRER message

INTERB1.6

Fund A v2 and Fund B v1 - incorrect versioning - IRR sent by fund A to fund B in v2

Sender application generates an IRR in v2, however receiving fund is still on v1 so sending solution gateway rejects and does not send the message

Tests that incorrect version does not get sent to receiving application

Receiver application does not receive IRR

B2B – Existing gateways

INTERG1.1

Establish https connection between endpoints Note: ATO has already established connectivity for EPF, however for USM, connection also needs to go the other way (because of USMOR) so tests are to be repeated

Use telnet, wget or curl etc., to establish that appropriate ports are open. Curl can be used to submit a file containing an ebMS3 message and should display the signal message reply

The two parties performing the interoperability testing exchange endpoint URLs, certificates and username and password. Each party configures their ebMS3 / AS4 MSH to register the other party. It is recommended that any messages received by the MSH during this phase should not be submitted to the application for processing

Both parties have configured their infrastructure to allow the flow of ebbs messages from the internet to their MSH. It is not required that any signal message returned to the sender is a success message

INTERG1.2

Send a simplified message from the sender MSH to the receiver MSH

Sender MSH pushes uncompressed, unsigned, single payload message with arbitrary payload contents using Username/Password authentication. Receiving MSH should receive the message if no MSH errors. Sender reviews signal message response. Receiver reviews received message, ignoring payload

A simple message with any payload is sent from each party to the other party. This test verifies that to/from PartyId header fields have been set correctly and that the sender and receiver have been configured correctly to send and receive messages to and from the other party. The payload included with 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 allow https to work

Sender should receive a success receipt. Receiver should receive message without error. Note: as the payload is arbitrary this may cause failures in your application layer if it is connected to the MSH at this time. In this phase of testing it is expected that you will ignore application layer failures

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 other 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 above 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 compression/decompression functionality

Payload should be compressed across the wire but be uncompressed by the receiving MSH and make an uncompressed payload available to the application

INTERG1.6

Multiple payloads - non compressed

As above, no compression but with more than one payload.

Tests support for multiple signed, uncompressed payloads.

Multiple payloads should be received without any ebms errors. Any application layer on the receiving end should receive uncompressed payloads

INTERG1.7

Multiple payloads – compressed

As above but with compressed payloads

Tests support for multiple signed, compressed payloads

Both parties have configured their infrastructure to allow the flow of ebbs messages from the internet to their MSH. It is not required that any signal message returned to the sender is a success message

INTERG1.8

Send a USM Rollover message with correct data

ATO generates a USM 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 ATO 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 USM message

INTERG1.9

Send a USM Rollover Outcome Response message with correct data

As above plus the Receiver replies with a USMOR message which the ATO processes

Tests the generation, sending, receiving, routing, validation (if provided by the gateway) of USM and USMOR

ATO should receive appropriate USMOR message

INTERG1.10

Send an Electronic Portability Form message with correct data

ATO 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

INTERG1.11

BIP4 - check routing is consistent with BIP4

Check To and From values

Values are ABN of message sending and receiving parties

To and From values are correctly set

INTERG1.12

ATO sends EPF v1 and Fund B is v1

Check gateway is correctly filtering messages according to sender and receiver version

Sender and receiver implementation versions are compatible so message should be sent

Message is transmitted

INTERG1.13

ATO sends EPF v1 and Fund B is v2 (INCORRECT)

Check gateway is correctly filtering messages according to sender and receiver version.

Sender and receiver implementation versions are not compatible so message should not be sent

Message is not sent

INTERG1.14

ATO sends EPF v2 and Fund B is v2

Check gateway is correctly filtering messages according to sender and receiver version

Sender and receiver implementation versions are compatible so message should be sent

Message is transmitted

INTERG1.15

ATO sends EPF v2 and Fund B is v1 (INCORRECT)

Check gateway is correctly filtering messages according to sender and receiver version

Sender and receiver implementation versions are not compatible so message should not be sent

Message is not sent