Show TOC

Function documentationMessage Flow Monitoring

 

In an SAP NetWeaver Process Integration (PI) landscape, Message Flow Monitoring (MFMon) monitors the status of business-critical message-based transactions, centrally. You can monitor

  • Application-to-application (A2A) message flows within your PI system landscape

  • Business-to-Business (B2B) message flows between systems of your organization and PI systems of your business partners.

Message Flow Monitoring covers the following use cases:

  • As a business power user, you can check the status of B2B or A2A processes without needing to access a PI system. You can, for example,

    • verify that an order was received by your business partner

    • check whether the confirmation of the order was sent from the business partner’s system back to your system

    • if an error occurred, send a notification to the application supporter responsible

  • As an application supporter you monitor the message flows, for example, to identify the root cause of failed message flow instances and resolve issues (correct an incorrect mapping value, for example).

Message Flow Monitoring is an interface between

  • the view of business power users who think in terms of, for example, order numbers or IDoc IDs

– and –

  • the technical view of application supporters who think in terms of technical systems (middleware components)

Integration

Message Flow Monitoring

  • uses information provided by the Integration Visibility Component of SAP NetWeaver Process Integration.

  • is in the SAP Solution Manager Technical Monitoring work center.

Prerequisites

You have

  • SAP NetWeaver Process Integration 7.31 SP07 or higher

  • SAP Solution Manager 7.1 SP09 or higher

Activities

The following roles and activities can be involved in the conception and implementation of Message Flow Monitoring scenarios:

  1. Application supporters and business power users identify relevant (the most business-critical, for example) business transactions they support or own (sending purchase orders and receiving order confirmations, for example).

  2. The solution architect conceives the monitoring views and the corresponding roles and users.

  3. The integration architect

    • identifies the message flows which correspond to the business transactions to be monitored.

    • if applicable: defines mapping rules for related message flows, such as purchase order and order confirmation (the attribute Order of the order message flow is to be mapped to the attribute Order no. of the order confirmation message flow, for example).

      Note Note

      To match varying number formats (“Order 123”in one system is “Order 00123” in the other system, for example), the Integration Architect can create a custom BAdI implementation (enhancement spot E2EEM_RELATED_FLOW_CALCULATOR).

      End of the note.

  4. The system administrator

    • sets up message flow scenarios

    • implements the mapping rules for related message flows

    • assigns process supporters as contact persons

    • creates personal object worklists (POWL) and the corresponding roles and users, and assigns them to message flow groups.

    For more information, see Setting up Message Flow Monitoring.

  5. The business power user checks the status of a business transaction. If an error occurs, the business power user notifies the application supporter. For more information, see Checking the Status of a Business Transaction.

  6. The application supporter identifies failed transactions and the root cause of errors. For more information, see Monitoring Message Flows and Handling Errors.

  7. The system administrator runs and manages the monitoring solution. If, for example, PI integration scenarios were changed, or new message flows were added, the time stamp of the data collection runs can be checked, to verify that the data extractors are running correctly.