Lesson 6 of 7
Alerting and AIF propagation
8 min
Listen to this lesson
A well-handled error still needs a person, and the right person is often not in Cloud Integration at all. Maria, Contoso's order-to-cash key user, lives in SAP S/4HANA. She already works IDoc errors in SAP Application Interface Framework (AIF). If the unknown part number error stays in the Cloud Integration monitor, she never sees it. This lesson covers how to push errors to where the owner works, and how alerting is wired.
Forwarding Cloud Integration errors to AIF
SAP documents two ways to show Cloud Integration errors in AIF (the AIF integration guide, "Error Forwarding from Cloud Integration"):
| Method | How it works | Notes |
|---|---|---|
| Exception subprocess (push) | The exception subprocess builds an error message and calls a SOAP web service in SAP S/4HANA through Cloud Connector | Service Error_Propagation_Request_In (service definition /AIF/ERROR_PROPAGATION_REQUEST), configured in SOAMANAGER |
| Transfer job (pull) | A transfer job in S/4HANA reads errors from Cloud Integration at regular intervals | Error propagation integration set up in /AIF/CUST (view /AIF/V_EP_CONF) with an RFC connection |
Two documented ways to bring Cloud Integration errors into AIF.
For the push method, the exception subprocess sets four exchange properties in a Content Modifier (AIF_Interface_Name, AIF_Interface_Version, AIF_Namespace and Cloud_Integration_Tenant_Name), builds the Error_Propagation_Request body, and sends it with an External Call. SAP's instructions replace the subprocess's default end with an Error End so the message still shows as Failed in Cloud Integration. The technical user in S/4HANA needs the role SAP_INTNW_WEBSERVICE, and its credentials are deployed as User Credentials in the tenant's security material.
On the S/4HANA side, Kenji's team defines custom engines in /AIF/CUST (for IDoc interfaces the classes /AIF/CL_APPL_ENGINE_CPIIDOC and /AIF/CL_PERSIST_ENGINE_CPIIDOC) and assigns them to the interface. The errors then appear next to the interface's other messages in Monitoring and Error Handling (/AIF/ERR), and for business users in the launchpad's Message Dashboard (a Web Dynpro app, shown only for the recipients a user is assigned to), with the tenant, integration flow ID, message ID and error text. Know the limits before you promise anything to the business:
- Errors can be forwarded only to IDoc and web service interfaces in AIF. Contoso's ORDERS05 interface qualifies; an OData-based flow would not.
- Cloud Integration errors arrive as technical errors (status A).
- They cannot be restarted from AIF, only cancelled. Reprocessing still happens in Cloud Integration: the parked message is moved back to the queue (lesson 3).
- Error in the flowThe exception subprocess classifies it as functional: unknown part.
- ParkMessage written to CMC_GLFS_ORDERS_PARKED with custom status Parked.
- ForwardError_Propagation_Request to AIF with PO number GLFS-4471 and the part number.
- FixMaria asks master data to map GLF-ALT-24X, then cancels the AIF entry.
- ReplayTheo moves the parked order back to CMC_GLFS_ORDERS.
Alerting
Three SAP tools cover alerting for this interface, each with a different audience:
- SAP Cloud ALM, Integration and Exception Monitoring, for the cross-system view. For Cloud Integration it offers the categories SAP Integration Suite Messages and Integration Content (artifacts that are not operational). It only sees messages that have an MPL, and it raises alerts by email, chat, ticket or operation flow. sap-int-205 covers setting up the rules and ownership.
- SAP Alert Notification service for SAP BTP, which AIF can call when a message monitoring alert fires. In an on-premise or private cloud system this needs an SM59 HTTP destination to the service and the OAuth profile
/AIF/CP_ANS_OAUTH_PROFILE. - The Cloud Integration Monitor itself, for the developer: filter on status Escalated or a custom status such as Parked, and add a tile for it.
Push or pull?
Choose the AIF method per interface. The push method sends the error the moment it happens and lets the flow decide what to forward: Contoso forwards only functional errors and parked messages, so Maria never sees a timeout that healed itself. It costs a call from every exception subprocess and a Cloud Connector route to the service. The pull method needs no change to the flow and collects errors on a schedule, but it brings whatever failed, including transient failures that a later retry fixed, and it arrives with a delay. For Contoso's fleet orders, where the business must react within the hour and noise must stay low, Theo and Kenji chose push.
Design the signals together with the alert rules. If Cloud ALM alerts on status Failed, every retry attempt in Error End can raise an alert; Contoso therefore alerts on the custom status Parked and on permanent failures, and leaves retries quiet. Escalated is useful when you want a third bucket that monitoring can treat separately from Failed; test how your alert rules and any JMS retry behave with it in CMC_TEST before you use it in production.
- Push errors to where the owner works: business errors to AIF in S/4HANA, technical ones to the integration team.
- AIF accepts forwarded Cloud Integration errors by push (exception subprocess calling Error_Propagation_Request_In) or by a pull transfer job.
- Forwarded errors are technical (status A), only for IDoc and web service interfaces, and can only be cancelled in AIF.
- Cloud ALM sees only messages with an MPL; align custom status and end events with its alert rules.
Check your understanding · not graded
Lesson check
1. Which interface types can receive forwarded Cloud Integration errors in AIF?
2. Maria sees a forwarded Cloud Integration error in /AIF/ERR. What can she do with it there?
3. Why does the push method end the exception subprocess with Error End?
4. Theo sets Cloud Integration log level None to reduce noise. What happens in SAP Cloud ALM?