Point-to-Point Scenario with Client Confirmation 

Use

In this scenario, the reliability of the process flow that is described in the simple point-to-point scenario is increased using client confirmations on the side of the central warehouse management. Here it is assumed that an error can occur when processing the requirement notification in the central warehouse management (for example, when accessing the database). Therefore, a delivery cannot be triggered for this requirement notification at this time. Without additional backup measures, the requirement notification that has already been received would be lost. The JMS API provides the simple option of using an extended confirmation mode called client confirmation. Unlike the automatic confirmation as it is used in the first point-to-point scenario, a message in this confirmation mode is removed from the queue only if it is explicitly confirmed by the receiver. If, therefore, the receiver is unable to process the message when it is received the first time, the message can be held in the queue by not sending a confirmation. At the next receiving time, the message is then resent to the receiver.

It makes sense to use client confirmations only on the receiver side since the sender side has full control over the time at which the message is sent. A recall function is not possible in this confirmation mode.

For this scenario you require a message sender for the production units and a message receiver for the warehouse management.

For this scenario, the message sender from the simple point-to-point scenario is used, whose functions remain the same.

The warehouse management receives messages synchronously in an endless loop and returns a relevant message for each message received. By using a random number mechanism, an error in the message processing is simulated. In this case the message is not confirmed.

The receiver object is generated as part of the known procedure by using the naming context, the queue connection factory, the queue, the queue connection, and the queue session. The session is generated without a transaction and with an explicit confirmation of the message when it is received (CLIENT_ACKNOWLEDGE).

queueSession = queueConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE); queueReceiver = queueSession.createReceiver(queue);

Then the queue is checked for messages synchronously in an endless loop. When a message is received, a random number mechanism is used to simulate occasional errors in the message processing. If the message is successful, the fields in the message are output and the message is confirmed. If errors occur, a warning appears, and the unprocessed message can be received again by calling queueSession.recover(). The receiving process can be terminated by entering q.

queueConnection.start(); while (!(key == 'q')) {    Message m = queueReceiver.receive(1);    if (m != null) {       if (m instanceof MapMessage) {          // simulate processing problem for every second message          if (failure.nextInt(2) == NO_FAILURE) {             message = (MapMessage) m;             System.out.println("Reading message with content: ");             for (Enumeration e = message.getMapNames();                e.hasMoreElements();                ) {                String key = (String) e.nextElement();                System.out.println(key + ": " + message.getString(key));             }             message.acknowledge();          } else {             System.out.println("Processing failure, no acknowledgement");             // recover the session to receive the non-acknowledged message again             queueSession.recover();          }       }    } }

Procedure

...

       1.      Generate and register a queue

Using the Visual Administrator tool of the SAP J2EE Engine, generate one queue named ProductionUnitRequirements.

You can also use the queue that was generated in the simple point-to-point scenario.

       2.      Start the receiver

Make sure that the J2EE Engine is running. In the directory of the compiled example packages, open a window for the command line, and start the receiver for the warehouse management with the following command:

java .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario2.WarehouseReceiver

       3.      Start the sender

In the directory of the compiled example packages, open a window for the command line, and start the sender for the production unit with the following command:

java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario1.ProductionUnitSender REQ1 PU1 P-100 2 06.03.2003

Result

The sender then sends a message to its queue with the parameters that were specified when the program was started. The following are examples of messages that are output on the receiver side:

Processing failure, no acknowledgement Processing failure, no acknowledgement Reading message with content: RequirementID: REQ1 ProductionUnitID: PU1 MaterialID: P-100 MaterialAmount: 2 MaterialRequirementDate: 06.03.2003

After two (simulated) processing errors, the message can be processed. Since no confirmation is sent if processing errors occur, the message is automatically received as many times as necessary until processing is possible. If a receiver confirmation was not used, the receiver would require an additional logic for buffering and processing these messages in parallel to processing the queue. With a receiver confirmation, the queue itself (that is, the JMS provider) takes on this task.

 

See also:

 

·        Source Code of JMS Scenarios