Entering content frame

Procedure documentationSimple Publish/Subscribe Scenario Locate the document in its SAP Library structure

Use

Besides supplying the production units, the warehouse management is also responsible for triggering required new deliveries. For this purpose, requirement notifications based on fixed minimum stock levels are sent to the purchasing department. The purchasing department is divided into operative and strategic purchasing:

·        Operative purchasingplaces purchase orders for the required materials based on the requirement notifications.

·        Strategic purchasingplans long-term procurement strategies. For this task, too, the data reported by the central warehouse management is of significance (which materials are required how often and in what amounts, for example).

Since there are multiple interested parties for one message in this scenario, albeit for different reasons, it makes sense to use a publish/subscribe solution. The warehouse management sends its material requisitions to one topic called Material Requirements. All receivers who are interested in material requirement information can access the relevant messages from this topic. This means that the warehouse management has to send the message to one destination only (that is, the topic). It is still possible, however, for all interested to receive the messages. Each interested receiver can decide whether to receive messages regarding a particular topic, and when.

This graphic is explained in the accompanying text

For this scenario, a message sender is required for the warehouse management, and message receivers are required for the purchasing departments.

For each program run, the message sender sends exactly one requirement notification to the Topic. The parameters for the message are transmitted to the program in the command line.

The sender object is generated as part of the known procedure by using the classes NamingContext, TopicConnectionFactory, Topic, TopicConnection, and TopicSession. The session is generated without a transaction and with an automatic confirmation of the messages when they are sent (AUTO_ACKNOWLEDGE).

This graphic is explained in the accompanying text

topicSession = topicConnection.createTopicSession(false,

                    Session.AUTO_ACKNOWLEDGE);

topicPublisher = topicSession.createPublisher(topic);

A message of the type MapMessage is then generated from the input parameters and sent.

This graphic is explained in the accompanying text

message = topicSession.createMapMessage();

message.setString(Constants.MAT_ID_KEY, args[0]);

message.setString(Constants.MAT_AMOUNT_KEY, args[1]);

message.setString(Constants.MAT_REQ_DATE_KEY, args[2]);

 

topicPublisher.publish(message);

The purchasing departments receive messages asynchronously in an endless loop and return a relevant message for each message received. To receive the messages asynchronously, an implementation of the MessageListener interface is required. The incoming messages are processed in the onMessage method of this class.

This graphic is explained in the accompanying text

public void onMessage(Message message) {

   MapMessage msg = null;

 

   try {

      if (message instanceof MapMessage) {

         msg = (MapMessage) message;

         System.out.println("Reading message with content: ");

         System.out.println(Constants.MAT_ID_KEY+": "+

            msg.getString(Constants.MAT_ID_KEY));

         System.out.println(Constants.MAT_AMOUNT_KEY+": "+

            msg.getString(Constants.MAT_AMOUNT_KEY));

         System.out.println(Constants.MAT_REQ_DATE_KEY+": "+

            msg.getString(Constants.MAT_REQ_DATE_KEY));

      } else {

         System.out.println("Message of wrong type: " +

            message.getClass().getName());

      }

   } catch (JMSException e) {

      System.out.println("JMSException in onMessage(): " +

         e.toString());

   } catch (Throwable t) {

      System.out.println("Exception in onMessage():" +

         t.getMessage());

   }

}

The receiver object is generated as part of the known procedure by using the classes NamingContext, TopicConnectionFactory, Topic, TopicConnection, and TopicSession. The session is generated without a transaction and with an automatic confirmation of the messages when they are received (AUTO_ACKNOWLEDGE).

This graphic is explained in the accompanying text

topicSession = topicConnection.createTopicSession(false,

                    Session.AUTO_ACKNOWLEDGE);

topicSubscriber = topicSession.createSubscriber(topic);

The message receiver described above is then generated and registered.

This graphic is explained in the accompanying text

topicListener = new RequirementListener();

topicSubscriber.setMessageListener(topicListener);

Before the connection is started, a separate thread is started for interaction with the user.

This graphic is explained in the accompanying text

Thread stop = new Thread(new Commandline(this));

stop.start();

System.out.println("Now receiving, enter q and" +

                   "<Return> to end the program");

Finally, the connection for receiving the messages is started.

This graphic is explained in the accompanying text

topicConnection.start();

Procedure

...

       1.      Generation and registration of a new topic

Using the Visual Administrator tool of the SAPJ2EE Engine, generate a topic named WarehouseRequirements.

       2.      Starting the receiver

Make sure that the J2EE Engine is running. In the directory of the compiled example packages, open two windows for the command line, and start one receiver for each purchasing department with the following command:

java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario3.PurchasingSubscriber

       3.      Starting the sender

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

java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario3.WarehousePublisher P-100 2 06.03.2003

Result

The sender sends a message to the topic with the parameters that were specified when the program was started. Both receivers see the following message:

Reading message with content:

MaterialID: P-100

MaterialAmount: 2

MaterialRequirementDate: 06.03.2003

Unlike the point-to-point scenario type, here one message reaches multiple receivers, until in the point-to-point scenario, the first receiver “wins”.

Stop one receiver now and send an additional message. This message is displayed as expected by the current receiver. Now restart the second receiver. This receiver does not display a message. A receiver of this type can therefore receive messages only if it is activated.

 

See also:

 

Source Code of JMS Scenarios

 

 

Leaving content frame