Logging without leaking personal data

When an order fails at 02:00, the person on call has the message processing log (MPL) and whatever your flow put into it. Good logging answers three questions fast: which business document, which step, and why. Bad logging either answers none of them or answers them by dumping the full payload, names, addresses and all, into a log that many people can read. This lesson is about getting the first without the second.

Log levels

You set the log level per deployed integration flow in the Monitor, under Manage Integration Content, in the Log Configuration section. A newly deployed flow runs at Info. Changes apply only to messages created after the change.

Two traps follow from the table. Error looks like a sensible production setting until you combine it with JMS retries: the message that succeeded on the fourth attempt still shows Retry or Failed, and someone reprocesses an order that already posted. And None hides messages from central monitoring: SAP Cloud ALM only collects messages that have an MPL. Contoso keeps Info in production and switches to Trace only in CMC_TEST, or in production for a short, approved diagnosis, because Trace stores the payload. The header SAP_MessageProcessingLogLevel (INFO, NONE, DEBUG or ERROR) can set the level for a single incoming message.

Make messages searchable with headers, not payloads

Cloud Integration reads a few headers into the MPL so you can search without opening payloads. Set them early, in the first Content Modifier:

For anything else, a Groovy script can call messageLogFactory.getMessageLog(message) and then addCustomHeaderProperty(name, value). Custom header properties are persisted and searchable; Contoso adds the plant (1710) and the sold-to party. By contrast, properties written with setStringProperty appear in the MPL only at Debug or Trace.

Attachments and the data protection risk

addAttachmentAsString(name, text, mediaType) attaches text to the MPL, and SAP's own examples attach the incoming payload. Be careful. SAP Help warns that payload attachments consume the tenant's limited storage and, at high volume, can push the tenant until the circuit breaker opens. The bigger issue is personal data: a Great Lakes order carries a ship-to contact name, phone number and delivery address. MPL data is kept for 30 days by default and is readable by everyone with monitoring access. The HTTP receiver's Attach Error Details on Failure option does the same with response bodies.

SAP's Setting Log Levels page shows a script that reads the property SAP_MPL_LogLevel_Overall and adds the payload attachment only when it is high enough. Contoso uses that pattern in CMC_Common_ErrorHandler, and Nadia reviews every flow that writes an attachment. If you must keep a failed payload, keep it where access is controlled and expiry is defined (a parking queue or an encrypted data store), not in the log.

Trace in production deserves a rule of its own, because it captures the very payloads you kept out of the log. At Contoso, switching a production flow to Trace needs a ticket that names the reason and the time window, Nadia's approval when the flow carries personal data, and a note when the level has switched back. Most diagnoses do not need it: the business key, the failed step and the error text in an Info log usually locate the problem, and the payload can be reproduced in CMC_TEST.