3.5 Example 5: Branch Office Order Processing

This example demonstrates branch office order processing as described in the Send Message to Queue – Application (section 2.5.3) use case.

Prerequisites

  • See the common prerequisites defined in section 3.

  • The queue exists.

  • The application is authorized to send messages to the queue.

  • If a Directory Service is not being used, the application is configured with the address of the queue prior to the send operation.

Initial System State

At least one Message Queuing System in each MSMQ site is designated as an MSMQ site gate, as specified in [MS-MQBR]. The In-Routing Servers and Out-Routing Servers are configured on all the MSMQ site gates. The Directory Service contains sufficient information to build a routing table, including:

  • The available machines in the enterprise.

  • The connected networks for each of the machines.

  • The MSMQ sites in the enterprise.

  • All available routing links and the associated costs for each link.

The directory server has the public keys of all the machines in the enterprise. On startup, the queue manager servers on the MSMQ site gates compute the routing tables containing the most optimal routes.

One queue is configured in the company headquarters (HQ) server to receive sales data.

Final System State

The final state of the Message Queuing System in the company HQ contains the sales data sent from the branch office server. The final states for all other Message Queuing Systems in this example are the same as their initial states.

Sequence of Events

The following figure shows the sequence of events for branch office order processing.

Sequence diagram for Example 5

Figure 23: Sequence diagram for Example 5

  1. To get the routing data, the branch office server calls the S_DSGetProps ([MS-MQDS] section 3.1.4.7) method, providing a dwObjectType input parameter value of MQDS_ROUTINGLINK ([MS-MQDS] section 2.2.8), a pwcsPathName input parameter value of NULL or a null-terminated 16-bit Unicode string, and an aProp[] input parameter array containing a single entry value of PROPID_L_ID (see [MS-MQDS] sections 2.2.9, 2.2.10.1, and 2.2.10.8). On success, the S_DSGetProps method returns an apVar[] output parameter array populated with routing link properties ([MS-MQDS] section 3.1.4.21.8.1.9) and a return code of MQ_OK (0x00000000).

  2. The branch office server initializes its RoutingTable ([MS-MQBR] sections 3.1.1.2 and 3.1.3.1) ADM element and computes a collection of RoutingLink ([MS-MQDMPR] section 3.1.1.8) ADM element instances by invoking the GetDirectoryData ([MS-MQBR] section 3.1.5.9) method, providing a DataElementType parameter set to the string "RoutingLink" and an empty FilterArray parameter.

    In case an MSMQ site is not reachable, the GetNextHopsForSiteGate ([MS-MQBR] section 3.1.5.3) event is invoked to get a list of alternate next hops from which the least-cost alternate route to the ultimate destination is constructed using Dijkstra's algorithm.

  3. The regional HQ1 server follows step 1 to request routing data.

  4. The regional HQ1 server follows step 2 to compute the routing table.

  5. The regional HQ2 server follows step 1 to request routing data.

  6. The regional HQ2 server follows step 2 to compute the routing table.

  7. As specified in [MS-MQQB] section 3.1.7.1.5, the branch office server encrypts the message by requesting the public key of the company HQ server from the Directory Service. Next, the branch bffice server generates the Create Directory Object ([MS-MQDSSM] section 3.1.6.1) event, providing an iAttributeList argument value set to mSMQEncryptKey, as specified in [MS-MQDSSM] section 3.1.6.1.1.2, to get an MQDSPUBLICKEYS ([MS-MQMQ] section 2.2.2) structure.

  8. Using the key length and provider information in the company HQ server's public key information to ensure that the company HQ server can decrypt the message, the branch office server dynamically generates a symmetric key. Next, the branch office server server encrypts the symmetric key with the company HQ server's public key obtained in step 7, encrypts the message with the symmetric key, and attaches the encrypted symmetric key to the message. The message format is specified in [MS-MQMQ] section 2.2.20.6.

  9. The branch office server generates the Send User Message Event ([MS-MQQB] section 3.1.7.1) to send the encrypted message to the Regional HQ1 Server.

  10. The regional HQ1 server invokes the GetNextHopsForSiteGate ([MS-MQBR] section 3.1.5.3) event to get the next route to send the message.

  11. If the message transfer fails on this route, an alternate route is selected by invoking the GetNextHopsForSiteGate event.

  12. The regional HQ1 server generates the Send User Message Event to send the encrypted message to the regional HQ2 server.

  13. The regional HQ2 server performs steps 10 through 12 to find the next correct route and send the message to the company HQ server.

  14. The queue manager of the Company HQ server decrypts the message as specified in [MS-MQQB] section 3.1.5.8.3, using the following high-level steps:

    1. Extract the encrypted symmetric key from the message.

    2. Decrypt  the encrypted symmetric key with a private key from implementation-dependent local storage.

    3. Decrypt the message with the decrypted symmetric key.