Validating the configuration

The configuration that we have described in the previous section does not yet involve the start-up of outbound communication tasks. At this time, dropping a message in the outbox queue will not result in an actual transmission. To start-up this outbound transmission task, we’ll need to include a send command in the configuration file. But before we do that, we would like to perform a manual send to allow us to step through the whole flow and validate that the setup so far is correct.

The send command can have many parameters to perform different functions. Here, in Example 2-9 on page 59, the command initiates a send from partner SUP1 to partner RETAILER1. The data to be sent is stored in the current directory in a file called test.txt (-fN parameter). We ask to try to send only once (-n parameter) and we request an unsigned MDN (message disposition notification) receipt. This command can be entered in the interactive session, as shown below in Example 2-9 on page 59. The output also shows that the P2PAgent program has twice stored data in MQ. The first entry maps to the creation of a notice message in the queue notices, as configured in the configuration file. The second entry maps to the arrival of an MDN receipt by SUP1. This receipt is stored in the queue receipts as it was set in the configuration file.

Note: The steps above did not expand in detail how certificates are exchanged. It should

be mentioned that the P2PAgent program contains a sendcert command to send certificates to trading partners. This might be a sufficient solution for your security requirements. However, it might very well be that you require a more formal exchange procedure where both partners acknowledge that certificates have been received. Procedures can vary from a simple e-mail attachment to a delivery by a courier. For the purposes of this redbook, it is sufficient to assume that an exchange procedure can be set up and that certificates become available for the P2PAgent program.

Example 2-9 Perform an initial send

send http SUP1 RETAILER1 -fNtest.txt -n1 -r ok

2003.01.27 14:34:40.372 73957 HPOS OK Outbound session started - mbox=[0] batch=[0] attempt=[1 of 1] 2003.01.27 14:34:41.313 35014 STMQ OK Data stored

2003.01.27 14:34:41.333 11530 STMQ OK Data stored

2003.01.27 14:34:41.333 73957 HPOS OK Outbound session stopping - batch=[0]

The output of the P2PAgent program at the receiving side is shown below in Example 2-10. The arrival of an inbound connection request is logged, together with the IP address that originated the connection request. This is followed by a two log entries indicating that information was stored in MQ. The first entry maps to the storage of the incoming data as an MQ message in the queue inbox. The second entry is for the notice message. The setup for RETAILER1 is similar to the setup of SUP1. Queue names, outbox and inbox configuration is exactly the same.

Example 2-10 Receiving a message at RETAILER1

2003.01.27 14:34:05.789 44452 HPIS OK HTTP inbound session started 2003.01.27 14:34:05.789 44452 HPIS OK HTTP client: 9.24.104.158:1087 2003.01.27 14:34:05.829 44452 STMQ OK Data stored

2003.01.27 14:34:05.859 58670 STMQ OK Data stored

2003.01.27 14:34:05.869 44452 HPIS OK HTTP inbound session stopping

The previous send command resulted in a number of MQ operations, at both the sending and receiving side. But it did not yet validate access to the mailbox, which is also hosted by MQ. Therefore, we use a utility such as RFHUTIL to load the same file text.txt into the queue outbox. The send command in Example 2-11 will pick up this message and send it out to REATILER1.

The parameter -ds indicates to the P2PAgent where to find the data. This is set to be a mailbox, with identifier outbox. Note that in this case, we have not asked to request a MDN receipt of RETAILER1. As a result, there is only one MQ message stored as a result of the transactions (the notice).

Example 2-11 Validating the mailbox implementation

send http SUP1 RETAILER1 -dsMAILBOXID=outbox -n1 ok

2003.01.27 16:41:54.118 22768 HPOS OK Outbound session started - mbox=[outbox] batch=[0] attempt=[1 of 1] 2003.01.27 16:41:54.148 22768 EXMQ OK File extracted - [1533] bytes

2003.01.27 16:41:54.369 30639 STMQ OK Data stored

2003.01.27 16:41:54.379 22768 HPOS OK Outbound session stopping - batch=[0]

The above tests validated the whole setup with respect to MQ and Internet communication. We should also do a number of tests to validate encryption, digital signatures and possible compression. The following commands can be executed for these purposes.

򐂰 Sign outbound EDI file

send http SUP1 RETAILER1 -fNtest.txt -n1 -s -r1

Note: Time stamps in Example 2-9 and Example 2-10 do not match completely, since the

clock of both computers was not synchronized. However, the logging in Example 2-9 does match the logging in Example 2-10.

The -s parameter signs the document using the default SHA-1 algorithm. If you would need an MD5 algorithm, use the option -s5. When you would like to use Base64 encoding for the signature, add B to the parameter (-sB and -s5B).

Previously, we had used -r to request a receipt. Here, we used -r1, to indicate that we request a signed receipt, using the SHA-1 algorithm.

򐂰 Encrypt and sign the outbound EDI file

send http SUP1 RETAILER1 -fNtest.txt -n1 -e -s -r1

The option -e is used to indicate that the outbound EDI document needs to be encrypted using the Triple DES algorithm. You can also use the RC2 algorithm by specifying the option -e2.

򐂰 Encrypt, sign and compress the outbound EDI file

send http SUP1 RETAILER1 -fNtest.txt -n1 -e -s -oZ -r1

The option -oZ indicates that the message payload needs to be compressed using the ZLIB compression algorithm. This compression is then followed by encryption and signing of the payload.

򐂰 More options to control the receipt.

So far, we’ve seen the options -r and -r1 or requesting an unsigned or signed receipt. You can also use the option -r5, to request a MD5 signed receipt, instead of the default SHA-1. For each of these three cases, you can add the option A to the parameter to indicate that the receipt may be sent asynchronously (thus, -rA, -rA1, -rA5).