> ## Documentation Index > Fetch the complete documentation index at: https://docs.germainux.com/llms.txt > Use this file to discover all available pages before exploring further. # Prevent and Trace Failed Orders Across Salesforce, MuleSoft and SAP ERP > Catch broken order flows before customers do, and find the exact layer where any order failed, from the app where it starts to SAP ERP. Components [`Engine`](https://docs.germainux.com/deploy/germain-ux-engine) [`RUM JS`](https://docs.germainux.com/deploy/germain-ux-rum-js) [`RUM Extension`](https://docs.germainux.com/deploy/germain-ux-rum-extension) > [card] [Prevent Failed Orders](#prevent-failed-orders) > > Synthetic orders and early warnings > [card] [Connect the Layers](#connect-the-layers) > > One ID from app to ERP > [card] [Find Where Orders Fail](#find-where-orders-fail) > > One order or all orders > [card] [Set It Up](#set-it-up) > > What to deploy per layer ## Overview An order often passes through four systems before it's real: the app where the customer places it, Salesforce, MuleSoft and SAP ERP. When it fails, each team sees only its own layer. The customer sees an order that never arrived. The order can also start inside Salesforce Lightning, when a sales or service rep enters it for the customer. GermainUX monitors every layer of that flow and connects them with the order's own identifiers. You test the full order path before customers use it, and you see early warnings on each layer. When an order fails, you open its full trace and see which layer broke, what the customer saw, and how many other orders hit the same problem. App (Web, Mobile, Portal, Salesforce Lightning) Salesforce MuleSoft SAP ERP The same approach works for any order flow that runs from a front end through a CRM and an integration layer to an ERP. This page uses Salesforce, MuleSoft and SAP ERP as the example. MuleSoft publishes ready-made integrations for this flow, such as the [order-to-cash use case of the MuleSoft Accelerator for SAP](https://anypoint.mulesoft.com/exchange/org.mule.examples/mulesoft-accelerator-for-sap/). ### Questions It Answers * Can a customer place an order right now, end to end? * Where did order 4711 stop: in the app, Salesforce, MuleSoft or SAP? * Which orders were submitted but never confirmed by SAP? * Did today's failures start in one layer, one API or one release? * How many customers and how much order value did the problem affect? * What did the customer see when their order failed? ## How Each Layer Is Monitored GermainUX monitors each layer with the components that fit it. All the data lands in one place, where GermainUX correlates it. | Layer | What goes wrong | What GermainUX monitors | | - | - | - | | **App where the order starts** | Errors at checkout, slow or failed requests, abandoned orders, crashes | User sessions, clicks, errors, network requests and Session Replay. GermainUX monitors [many front-end platforms](https://docs.germainux.com/integrations/monitoring.md), such as [web applications](https://docs.germainux.com/integrations/browser-monitoring.md), [ReactJS](https://docs.germainux.com/integrations/react-js-monitoring.md), [mobile apps](https://docs.germainux.com/integrations/mobile-monitoring.md), [Salesforce Experience Cloud](https://docs.germainux.com/integrations/salesforce-experience-cloud-monitoring.md) portals, [Salesforce Lightning](https://docs.germainux.com/integrations/salesforce-monitoring.md) apps used by sales and service reps, and [Windows applications](https://docs.germainux.com/integrations/windows-monitoring.md). | | **Salesforce** | Apex exceptions, failed callouts, API limits, platform incidents, configuration changes | [Salesforce event logs](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-log-monitoring.md), including Apex callouts and exceptions, [Apex exceptions](https://docs.germainux.com/integrations/salesforce-monitoring/apex-exception-monitoring-for-salesforce-cloud-configure.md), [platform statistics and limits](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-stats-monitoring.md), [instance status](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-instance-status-monitoring.md) and [setup audit changes](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-audit-monitoring.md) | | **MuleSoft** | Failed or slow API calls, unreachable downstream systems, stopped flows, growing queues | One transaction per API call with status, error type and downstream service, plus runtime logs, JVM health and Anypoint Platform data. See [MuleSoft Observability](https://docs.germainux.com/integrations/mulesoft-monitoring.md). | | **SAP ERP** | Rejected orders, slow or unavailable services, failed jobs, database problems | Whatever the SAP landscape exposes: [SAP Fiori and other browser UIs](https://docs.germainux.com/integrations/sap-erp.md), REST, OData and SOAP endpoints, application and job logs, databases, hosts and services | ## Prevent Failed Orders The cheapest failed order is the one no customer places. GermainUX tests the order path on a schedule and watches the conditions that come before failures. ### Test the Order Path Before Customers Do A [synthetic user scenario](https://docs.germainux.com/automation/user-click-synthetic-user-scenario.md) places a test order the way a customer does: it opens the app, adds a product, checks out and confirms the result. Run it every few minutes, from the locations your customers use. When a step fails or slows down, GermainUX alerts you, with a screenshot of the step that failed. Add one [HTTP check](https://docs.germainux.com/automation/synthetic-http-execution.md) per layer next to it: * The Salesforce API or Apex REST service the app calls * The MuleSoft order API * The SAP OData or REST service that MuleSoft calls When the test order fails, the layer checks show where: if only the SAP check fails, the problem is in SAP or the connection to it. ### Watch the Early-Warning Signals Orders often fail after a layer has been degrading for a while. GermainUX watches these signals, and alerts you when one breaches its [SLA](https://docs.germainux.com/analytics/slas.md) or behaves as an [outlier](https://docs.germainux.com/analytics/outlier-detection.md): | Layer | Early-warning signals | | - | - | | **App** | Rising error rate or response time on the order requests, more abandoned checkouts | | **Salesforce** | API and platform limits close to their maximum, Apex exceptions, slow callouts, instance incidents | | **MuleSoft** | Rising failure rate or response time on the order API, Anypoint MQ queue depth, JVM memory and threads | | **SAP ERP** | Slow or unavailable services, errors in application and job logs, database locks and capacity, host resources | ### Catch Changes and Silent Stops Two kinds of failure raise no error, so they need their own checks: * **A configuration change.** [Salesforce audit monitoring](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-audit-monitoring.md) shows the setup change that came right before the failures. * **A flow that stopped.** [Missing-activity detection](https://docs.germainux.com/integrations/mulesoft-monitoring/configure-monitoring-for-mulesoft.md#configure-missing-activity-detection) alerts you when the order API receives fewer calls than expected. ## Connect the Layers To trace one order across four systems, every layer has to report something that links its data to the same order. GermainUX uses two links, and the most complete traces use both: | Link | What it is | What it connects | | - | - | - | | **Tracking header** | The `germain-apm-sequence` header that GermainUX RUM JS adds to the app's requests | The customer's click to every monitored call it triggers | | **Order ID** | The order number, or another business ID the order keeps in every system | Every record about the order, in any layer, even when no header reaches it | The diagram shows what each layer passes on and what GermainUX records: ```mermaid theme={null} sequenceDiagram participant App as App (RUM JS) participant SF as Salesforce participant Mule as MuleSoft participant SAP as SAP ERP participant GX as GermainUX App->>SF: Order request + GermainUX tracking header App-->>GX: Click, request, order ID (metadata) SF->>Mule: Apex callout + GermainUX tracking header + X-Correlation-ID (order ID) SF-->>GX: Event logs: callouts, exceptions, request ID Mule->>SAP: Create sales order (order ID in payload) Mule-->>GX: API transaction: sequence, correlation ID, downstream, status SAP-->>GX: Logs, endpoint checks, database, Fiori sessions ``` ### Pass the Tracking Header Through Every Layer The tracking header links the data only as far as it travels. Each layer must forward it to the next one: | Hop | What to do | What GermainUX records | | - | - | - | | **App to Salesforce** | Turn on request tracking in RUM JS for the Salesforce endpoints the app calls. Salesforce must accept the header in its CORS settings. See [Front-End-to-Back-End Correlation](https://docs.germainux.com/integrations/browser-monitoring/network-requests-monitoring.md#front-end-to-back-end-correlation). | The click and the request, with the header value | | **Salesforce to MuleSoft** | The Apex code that calls MuleSoft reads `germain-apm-sequence` from the incoming request and sets it on the callout. Salesforce doesn't forward headers on its own. | The Apex callout, from [Salesforce log monitoring](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-log-monitoring.md) | | **Inside MuleSoft** | The GermainUX monitoring sub-flows read the header automatically. See [What the Monitoring Flow Sends](https://docs.germainux.com/integrations/mulesoft-monitoring/deploying-germainux-monitoring-for-mulesoft-a-step-by-step-guide.md#what-the-monitoring-flow-sends). | The MuleSoft API transaction, under the customer's request in the trace | | **MuleSoft to SAP** | Set the `germainuxDownstream` variable in the flow to the SAP service it calls. | Which downstream SAP service each call went to, and whether it failed there | When the app calls an Apex REST service, the callout to MuleSoft can forward the header and pass the order number on in one place: ```java Apex theme={null} public static HttpResponse sendOrderToMuleSoft(Order ord, String payload) { HttpRequest req = new HttpRequest(); req.setEndpoint('callout:MULESOFT_ORDERS/api/orders'); req.setMethod('POST'); req.setHeader('Content-Type', 'application/json'); // Forward the GermainUX tracking header from the app's request RestRequest inbound = RestContext.request; String sequence = inbound != null ? inbound.headers.get('germain-apm-sequence') : null; if (sequence != null) { req.setHeader('germain-apm-sequence', sequence); } // Pass the order number on as the MuleSoft correlation ID req.setHeader('X-Correlation-ID', ord.OrderNumber); req.setBody(payload); return new Http().send(req); } ``` Replace `MULESOFT_ORDERS` with the named credential of your MuleSoft API. ### Carry the Order ID on Every Layer The order ID links data that the header doesn't reach, such as SAP logs, scheduled jobs and retries. Each layer must either send it to GermainUX or let GermainUX extract it: | Layer | How the order ID reaches GermainUX | | - | - | | **App** | A [metadata extractor](https://docs.germainux.com/integrations/browser-monitoring/metadata-extractors.md) reads the order number from the page, the application state or an API response, and adds it to the session and its requests. | | **Salesforce** | The Apex callout sends the order number as the `X-Correlation-ID` header, as in the example above. [Salesforce log monitoring](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-log-monitoring.md) also records the Salesforce request ID of each request and callout. Salesforce lets the caller set that request ID with the `X-SFDC-REQUEST-ID` header. See [Set Up Cross-System Observability with Correlation IDs](https://developer.salesforce.com/blogs/2026/03/set-up-cross-system-observability-with-correlation-ids). | | **MuleSoft** | MuleSoft uses an incoming `X-Correlation-ID` header as the event's [correlation ID](https://docs.mulesoft.com/mule-runtime/latest/correlation-id). The GermainUX monitoring sub-flows send that correlation ID with every API transaction, and Mule writes it to its runtime logs. | | **SAP ERP** | SAP keeps the order number as a reference on the sales order. [Log file analysis](https://docs.germainux.com/automation/log-file-analysis.md) extracts it from application, job and integration logs, and [SQL execution](https://docs.germainux.com/automation/sql-execution.md) can read order status from the database. | | **Any other system** | Extract the order ID from its [logs and files](https://docs.germainux.com/integrations/file-log-monitoring.md), or send it with your own data through the [Data Ingestion API](https://docs.germainux.com/management/data-analysis/data-ingestion-api.md). | ### Join the Records for Each Order With the order ID on every layer, GermainUX joins the records: * **[ID-Based Correlation](https://docs.germainux.com/analytics/correlation-and-tracing/id-based-correlation.md)** builds the trace from the tracking header: click, request, Salesforce callout and MuleSoft call. * **[Exact-Match Correlation](https://docs.germainux.com/analytics/correlation-and-tracing/exact-match-correlation.md)** groups records from any layer that share the same key, such as the order number. * **[Stream Correlation](https://docs.germainux.com/analytics/correlation-and-tracing/stream-correlation.md)** pairs records by time and attributes where no shared ID survives a hop. * **[Business Process Monitoring](https://docs.germainux.com/analytics/business-process-workflow-monitoring.md)** follows each order through its milestones: submitted, created in Salesforce, sent by MuleSoft and confirmed by SAP. An order that misses a milestone in time shows up as an overrun. ## Find Where Orders Fail Once the data is correlated, the [Analysis Dashboard](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md) answers both questions: what happened to this order, and what is happening to all orders. ### One Order: Instance Analysis and Full Trace Open a failed order from an alert, a search by order number, or a dashboard. [Instance Analysis](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md#aggregate-view-vs-instance-view) shows the order's transaction with its status, attributes and identifiers. The [Trace Timeline](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md#trace-timeline) portlet shows every correlated step of the order on one timeline. Turn on **Full Trace** to also see the related transactions and events that happened before and after it. The trace shows: * Which layer received the order last * Which call failed or slowed down, and its error * How long each layer took * Whether a retry succeeded later From the trace, open [Session Replay](https://docs.germainux.com/analytics/user-monitoring-and-replay.md) to see what the customer saw: the error message, the retry, or the moment they gave up. ### All Orders: Aggregate Analysis and Relationships A single order shows where it broke. [Aggregate Analysis](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md#aggregate-view-vs-instance-view) shows whether it's one order or a pattern, across every order in the period: * **Leading Factors** show where failures concentrate: one MuleSoft API, one downstream SAP service, one error type, one app version or one region. * **[Relationships](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md#relationships)** overlay the order failures with related KPIs, errors, alerts and changes on the same timeline, such as an SAP job error or a Salesforce limit reached at the same time. * **[Related KPIs](https://docs.germainux.com/analytics/kpis/kpi-relationships.md)** surface the signals from other layers that moved with the failures. The investigation moves from the population to one order and back: Alert Aggregate Analysis Leading Factor Failed Order Full Trace Session Replay ### Ask Your AI Assistant The [GermainUX MCP Server](https://docs.germainux.com/integrations/mcp-server.md) gives AI assistants such as Claude or Copilot access to the same data. Ask "Why did order 4711 fail?" or "Which orders failed in SAP this morning?", and the assistant answers from the correlated KPIs, sessions and traces, with links to the analysis in GermainUX. [AI Insights](https://docs.germainux.com/analytics/ai-driven-insights.md) also summarizes failed sessions and recurring issues for you. ## Alert and Act Each signal on this page can raise an alert and start a response: * **[Alerts](https://docs.germainux.com/automation/notifications/alert-email-and-sms.md)** by email, SMS, [Microsoft Teams](https://docs.germainux.com/automation/notifications/microsoft-teams-notification.md) or [Slack](https://docs.germainux.com/automation/notifications/slack.md), with the failed order and a link to its trace * **Incidents** in [ServiceNow](https://docs.germainux.com/automation/servicenow.md), routed to the team that owns the failing layer * **[Automated actions](https://docs.germainux.com/automation/automated-actions.md)** that run a script or HTTP call, for example to resubmit a stuck order to MuleSoft * **[Scheduled reports](https://docs.germainux.com/automation/notifications/reporting-automatic.md)** on failed and delayed orders, by layer and by cause ## Set It Up Deploy monitoring layer by layer. Each layer adds value on its own, and the trace gets more complete with each one. **1. Monitor the app where orders start** Deploy GermainUX on the front end: [RUM JS](https://docs.germainux.com/deploy/germain-ux-rum-js.md) for web and mobile web apps, or the integration for your platform. Turn on [request tracking](https://docs.germainux.com/integrations/browser-monitoring/network-requests-monitoring.md#front-end-to-back-end-correlation) for the Salesforce endpoints, and add a [metadata extractor](https://docs.germainux.com/integrations/browser-monitoring/metadata-extractors.md) for the order number. **2. Monitor Salesforce** Deploy [Salesforce monitoring](https://docs.germainux.com/integrations/salesforce-monitoring/salesforce-monitoring-deployment.md) with log monitoring turned on. Update the Apex callout to MuleSoft so that it forwards `germain-apm-sequence` and sends the order number as `X-Correlation-ID`. **3. Monitor MuleSoft** Add the [GermainUX monitoring sub-flows](https://docs.germainux.com/integrations/mulesoft-monitoring/deploying-germainux-monitoring-for-mulesoft-a-step-by-step-guide.md) to the order API, and set `germainuxDownstream` in the flows that call SAP. Add [runtime](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-runtime-monitoring.md) and [Anypoint Platform](https://docs.germainux.com/integrations/mulesoft-monitoring/mulesoft-anypoint-platform-monitoring.md) monitoring. **4. Monitor SAP ERP** Add the sources your SAP landscape exposes: [browser monitoring](https://docs.germainux.com/integrations/sap-erp.md) for Fiori and other browser UIs, [HTTP checks](https://docs.germainux.com/automation/synthetic-http-execution.md) for the OData and REST services, [log file analysis](https://docs.germainux.com/automation/log-file-analysis.md) with order-ID extraction, and monitoring for the database and hosts. **5. Correlate and test** Configure [exact-match correlation](https://docs.germainux.com/analytics/correlation-and-tracing/exact-match-correlation.md) on the order number, and an order [business process](https://docs.germainux.com/analytics/business-process-workflow-monitoring/configure-a-business-process.md) with one milestone per layer. Record a [synthetic order scenario](https://docs.germainux.com/automation/user-click-synthetic-user-scenario/record-a-synthetic-scenario.md), and set [SLAs](https://docs.germainux.com/analytics/slas/configure-sla.md) and [alerts](https://docs.germainux.com/automation/notifications/create-an-alert.md) on the order KPIs. ## Additional Resources > [card] [Correlation or Tracing](https://docs.germainux.com/analytics/correlation-and-tracing.md) > > The three correlation methods > [card] [MuleSoft Observability](https://docs.germainux.com/integrations/mulesoft-monitoring.md) > > API, runtime and Anypoint monitoring > [card] [Use Cases](https://docs.germainux.com/use-cases/overview.md) > > More Use Cases ## Get Help Every order flow has its own systems, identifiers and failure points. The GermainUX team can help you choose the order ID to correlate on, instrument each layer and set up the business process, SLAs and alerts for your flow. > [card] [Contact GermainUX Support](https://docs.germainux.com/getting-started/support.md) > > The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes. > [card] Can't Find What You Need? > > Search all GermainUX docs with **Ctrl + K**, or use the feedback buttons at the bottom of this page to tell us what is missing. The content of this document is proprietary to GERMAIN SOFTWARE. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.