Prevent and Trace Failed Orders Across Salesforce, MuleSoft and SAP ERP

ComponentsEngineRUM JSRUM Extension

Prevent Failed Orders

Synthetic orders and early warnings

Connect the Layers

One ID from app to ERP

Find Where Orders Fail

One order or all orders

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)SalesforceMuleSoftSAP 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.

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, such as web applications, ReactJS, mobile apps, Salesforce Experience Cloud portals, Salesforce Lightning apps used by sales and service reps, and Windows applications.
Salesforce	Apex exceptions, failed callouts, API limits, platform incidents, configuration changes	Salesforce event logs, including Apex callouts and exceptions, Apex exceptions, platform statistics and limits, instance status and setup audit changes
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.
SAP ERP	Rejected orders, slow or unavailable services, failed jobs, database problems	Whatever the SAP landscape exposes: SAP Fiori and other browser UIs, 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 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 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 or behaves as an outlier:

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 shows the setup change that came right before the failures.
A flow that stopped. 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:

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.	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
Inside MuleSoft	The GermainUX monitoring sub-flows read the header automatically. See 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:

Apex

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 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 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.
MuleSoft	MuleSoft uses an incoming `X-Correlation-ID` header as the event’s 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 extracts it from application, job and integration logs, and SQL execution can read order status from the database.
Any other system	Extract the order ID from its logs and files, or send it with your own data through the Data Ingestion API.

Join the Records for Each Order

With the order ID on every layer, GermainUX joins the records:

ID-Based Correlation builds the trace from the tracking header: click, request, Salesforce callout and MuleSoft call.
Exact-Match Correlation groups records from any layer that share the same key, such as the order number.
Stream Correlation pairs records by time and attributes where no shared ID survives a hop.
Business Process Monitoring 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 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 shows the order’s transaction with its status, attributes and identifiers. The 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 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 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 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 surface the signals from other layers that moved with the failures.

The investigation moves from the population to one order and back:

AlertAggregate AnalysisLeading FactorFailed OrderFull TraceSession Replay

Ask Your AI Assistant

The GermainUX MCP Server 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 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 by email, SMS, Microsoft Teams or Slack, with the failed order and a link to its trace
Incidents in ServiceNow, routed to the team that owns the failing layer
Automated actions that run a script or HTTP call, for example to resubmit a stuck order to MuleSoft
Scheduled reports 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.

Monitor the app where orders start

Deploy GermainUX on the front end: RUM JS for web and mobile web apps, or the integration for your platform. Turn on request tracking for the Salesforce endpoints, and add a metadata extractor for the order number.

Monitor Salesforce

Deploy Salesforce monitoring 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.

Monitor MuleSoft

Add the GermainUX monitoring sub-flows to the order API, and set germainuxDownstream in the flows that call SAP. Add runtime and Anypoint Platform monitoring.

Monitor SAP ERP

Add the sources your SAP landscape exposes: browser monitoring for Fiori and other browser UIs, HTTP checks for the OData and REST services, log file analysis with order-ID extraction, and monitoring for the database and hosts.

Correlate and test

Configure exact-match correlation on the order number, and an order business process with one milestone per layer. Record a synthetic order scenario, and set SLAs and alerts on the order KPIs.

Additional Resources

Correlation or Tracing

The three correlation methods

MuleSoft Observability

API, runtime and Anypoint monitoring

Use Cases

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.

Contact GermainUX Support

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.

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.

Prevent Failed Orders

Connect the Layers

Find Where Orders Fail

Set It Up

​Overview

​Questions It Answers

​How Each Layer Is Monitored

​Prevent Failed Orders

​Test the Order Path Before Customers Do

​Watch the Early-Warning Signals

​Catch Changes and Silent Stops

​Connect the Layers

​Pass the Tracking Header Through Every Layer

​Carry the Order ID on Every Layer

​Join the Records for Each Order

​Find Where Orders Fail

​One Order: Instance Analysis and Full Trace

​All Orders: Aggregate Analysis and Relationships

​Ask Your AI Assistant

​Alert and Act

​Set It Up

​Additional Resources

Correlation or Tracing

MuleSoft Observability

Use Cases

​Get Help

Contact GermainUX Support

Can't Find What You Need?

Overview

Questions It Answers

How Each Layer Is Monitored

Prevent Failed Orders

Test the Order Path Before Customers Do

Watch the Early-Warning Signals

Catch Changes and Silent Stops

Connect the Layers

Pass the Tracking Header Through Every Layer

Carry the Order ID on Every Layer

Join the Records for Each Order

Find Where Orders Fail

One Order: Instance Analysis and Full Trace

All Orders: Aggregate Analysis and Relationships

Ask Your AI Assistant

Alert and Act

Set It Up

Additional Resources

Get Help