Adapter Notifications

In addition to the request (and reply) field selection, a listener notification contains the following fields:

• A flag that indicates if incoming IDocs should be tracked to later ALE monitoring from the calling system.
• A flag that indicates whether the Confirm event should be forwarded to the receiver.

All ALE listener notifications and routing notifications that have an ALE message type assigned support the Monitor IDocs feature. For more information, see Using the ALE Monitoring Features Via Adapter for SAP.

All synchronous adapter notifications (the RFC listener notification, ALE listener notification, and the routing notification) support the forward Confirm event feature. This is a useful feature in scenarios where a transactional request is received by Adapter for SAP and then forwarded to an SAP system via tRFC, and where the client wants to achieve transactional behavior from end to end.

If the Forward Confirm event flag is activated, Adapter for SAP tries to forward the Confirm TID event, which is triggered by the tRFC protocol, to the same destination where the document went. What happens then depends on the transport used.

Transports that have an SAP system or other Integration Servers as the destination confirm the TID on the destination system. This may become important in those cases where the final receiver of the message is another SAP system. For each tRFC it receives, an SAP system keeps an entry in a check table (ARFCRSTATE) to protect against duplicate processing of the same document. Only after the sender has indicated via Confirm TID that this document will never again be posted, the receiving system can safely remove this entry from its check table.

Up to IBM webMethods Adapter 4.6 for SAP, the adapter would not forward this Confirm TID event, so the check table in the receiving SAP system would keep growing. This feature enables a clean-up of this check table in scenarios like:

• SAP system A->Adapter for SAP A ->Internet->Adapter for SAP B->SAP system B or
• external client->Adapter for SAP->SAP system

if the external client uses the service pub.sap.client:confirmTID.

The following two simplified dynamic model diagrams show how Adapter for SAP handles requests differently depending on the setting of the $action parameter. They show a combined view of three possible scenarios:

• A listener notification is directly assigned to the RFC listener.
• No listener notification is assigned to the RFC listener, and the message is forwarded to the routing listener.
• The message is sent directly to the routing listener by calling one of the pub.sap.transport.*:InboundProcess services.

You can view listeners and each listener's parameters from Integration Server Administrator or from Designer. You can also view the notification order of a listener.

You use Integration Server Administrator to edit the listener in the following situations:

• If you need to select a newly configured connection, or if you need to change any listener properties you can update the listener parameters.
• If you need to change the order of the notifications that are associated with the listener, see Editing the Notification Order of a Listener.

The following table lists other objects you must configure or tasks you must complete to use listener notifications:

You can test a publishable document type that is associated with an asynchronous notification in Designer . When you test a publishable document type, you provide input values that Designer uses to create an instance of the publishable document type. You also specify a publishing method (such as publish, publish and wait, deliver, or deliver and wait). Designer then publishes a document and displays the results of the publish in the Results dialog box. Testing a publishable document type provides a way for you to publish a document without building a service that does the actual publishing. If you select a publication action where you wait for a reply document, you can verify whether reply documents are received.

For instructions to test a publishable document type, see the IBM webMethods Service Development Help for your release. Also, for a complete description of the envelope parameters located in the WmPublic folder, see the IBM webMethods Integration Server Built-In Services Reference. The envelope parameters define the sender's address, the time the document was sent, password and certificate information, and other useful information for routing and control.

You can view listener notifications from Integration Server Administrator, and Designer.

The following tutorial explains how to assign inbound RFCs to services on Integration Server. It describes an application in which the SAP system requests a service to retrieve information about a product.

If you need to use the information contained in an IDoc in documents of another format, you build a service that "maps" the information from fields in the IDoc to the variables used by the other application. For example, to transfer a purchase order from an ORDERS02 IDoc to an EDI system, you create a flow service that maps information from the IDoc fields to fields within the EDI system's purchase-order document. Then, you define a routing notification that triggers this flow service.

To create a sample synchronous ALE listener notification, perform the following:

1. Create an Empty Flow Service Called mapOrders02
2. Create an Asynchronous ALE Listener Notification for IDoc Type Orders02
3. Define the Input and Output Signatures for the mapOrders02 Service
4. Map Fields from Orders02RequestDocument to PurchaseOrder Document
5. Testing the Listener Notification from the SAP System