Reduce Excessive Logging in SAP BTP Integration Suite

Logging should help you answer a question, not reproduce everything an integration processed.

In SAP BTP Integration Suite, excessive logging often begins with a convenient debugging script. That script records every header, every exchange property, and the complete message body. It then remains in the integration flow after testing ends.

My architectural recommendation is simple: design diagnostic logging around the decisions your support team must make. Preserve useful identifiers and failure context. Leave unrelated data out.

This tutorial focuses on the Cloud Integration capability of SAP BTP Integration Suite. You will review an integration flow, replace broad logging with selected fields, and validate that troubleshooting still works.

Prerequisites

• Access to SAP BTP Integration Suite with Cloud Integration available.
• Permission to edit and deploy integration flows in a development or test environment.
• Permission to inspect message processing logs in monitoring.
• An existing integration flow, preferably with a Groovy logging script.
• Basic familiarity with integration flow steps, headers, and exchange properties.
• Synthetic test messages that contain no production credentials or personal data.

You do not need advanced Groovy knowledge. The example below uses a small script and explicitly named fields.

Overview: Log for a Troubleshooting Question

Consider an order integration that receives requests, transforms them, and sends them to a receiver system.

When a message fails, support typically needs to establish:

• Which execution failed?
• Which processing stage was involved?
• What category of failure occurred?
• How can the execution be correlated with another system?

The full order payload usually does not answer all these questions efficiently. It can instead surround the useful information with addresses, line items, and unrelated fields.

The supplied SAP BTP Integration Suite Common Issues & Fixes source explicitly warns against logging every header, property, and full payload because excessive logs make troubleshooting harder.

Its concrete contribution is this recognizable implementation anti-pattern—not a measured performance improvement or a product configuration guide. The workflow below translates that warning into a practical review and replacement pattern. The source’s publication date is unknown.

Step 1: Inventory Existing Logging

Start in a non-production environment. Open the integration flow and inspect its scripts and processing steps.

Look for these patterns:

// Anti-pattern: broad diagnostic capture
def headers = message.getHeaders()
def properties = message.getProperties()
def payload = message.getBody(String)

def messageLog = messageLogFactory.getMessageLog(message)
if (messageLog != null) {
    messageLog.addAttachmentAsString(
        "FullMessage",
        "Headers: ${headers}\nProperties: ${properties}\nBody: ${payload}",
        "text/plain"
    )
}

Do not deploy this example. It illustrates what to remove.

The script serializes entire header and property collections. It also converts the body into a string solely for logging. That creates unnecessary work and may expose sensitive content.

Review more than the main processing path:

• Groovy scripts and reusable script resources.
• Local integration processes.
• Exception subprocesses.
• Logging before and after mappings.
• Logging inside loops or split-message processing.
• Temporary diagnostic steps left from previous investigations.

Create a short inventory:

Location	Current behavior	Action
Before mapping	Attaches complete request body	Remove routine attachment
After receiver call	Dumps all headers	Keep only an approved result field
Exception subprocess	Logs raw exception text and payload	Use a safe error category
Shared script	Records all exchange properties	Replace with an allowlist

Also inspect the runtime logging level. Application-created attachments and runtime Trace are separate sources of diagnostic data. Removing one does not automatically disable the other.

Step 2: Define a Small Logging Contract

Before changing code, decide which fields support actual troubleshooting.

For the order integration, a starting contract could be:

Field	Purpose	Capture policy
CorrelationId	Link executions across systems	Routine, if approved
ProcessingStage	Identify a useful checkpoint	Targeted diagnostics
ErrorCategory	Describe a known failure class	Targeted diagnostics

These are application-defined names, not built-in SAP fields.

Cloud Integration already provides execution information in message processing logs. Avoid copying information merely because it is available. Add custom fields only when they make correlation or diagnosis easier.

Use an allowlist, not a denylist:

• Allowlist: “Record these three approved fields.”
• Denylist: “Record everything except passwords.”

The denylist approach fails when a new sensitive field appears.

Treat identifiers as data that requires review. A customer number or email address is not automatically safe because it is short. Prefer an approved technical correlation identifier.

Step 3: Replace Broad Logging with a Targeted Groovy Script

Add a Content Modifier before the logging script. Create these exchange properties:

• LogDiagnostics: constant value false.
• ProcessingStage: a controlled label such as BeforeReceiver.
• CorrelationId: your flow’s existing, approved technical correlation value.
• ErrorCategory: a controlled category where applicable.

Do not derive LogDiagnostics directly from an incoming request header. Otherwise, an external sender could potentially influence diagnostic collection.

Use this Groovy script:

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def messageLog = messageLogFactory.getMessageLog(message)

    if (messageLog == null) {
        return message
    }

    // Validate format and bound length.
    // This is NOT a substitute for reviewing data sensitivity.
    def safeToken = { Object value ->
        if (value == null) {
            return null
        }

        String text = value.toString().trim()

        if (!(text ==~ /[A-Za-z0-9._:-]{1,80}/)) {
            return null
        }

        return text
    }

    def correlationId =
        safeToken(message.getProperty("CorrelationId"))

    if (correlationId != null) {
        messageLog.addCustomHeaderProperty(
            "CorrelationId", correlationId
        )
    }

    boolean diagnosticsEnabled = "true".equalsIgnoreCase(
        message.getProperty("LogDiagnostics")?.toString()
    )

    if (diagnosticsEnabled) {
        ["ProcessingStage", "ErrorCategory"].each { field ->
            def value = safeToken(message.getProperty(field))

            if (value != null) {
                messageLog.addCustomHeaderProperty(field, value)
            }
        }
    }

    return message
}

This script:

• Reads only explicitly selected properties.
• Never reads or serializes the payload.
• Creates no payload attachments.
• Rejects unexpected token formats.
• Limits each value to 80 characters.
• Enables additional fields only through an explicit switch.
• Returns the message without changing its body.

addCustomHeaderProperty adds metadata to the message processing log; it does not add an outbound business-message header.

The format check prevents arbitrary text from entering these fields. It does not detect secrets. An access token could still match an allowed character pattern, so field selection remains the primary security control.

Deploy the revised flow to your test environment.

Step 4: Keep Error Logging Focused

Error paths deserve the same discipline as successful paths.

Avoid copying raw exception text automatically. Depending on the failing component, an exception may contain endpoint details, request fragments, or other sensitive information.

Instead, use controlled categories such as:

• VALIDATION_FAILED
• MAPPING_FAILED
• RECEIVER_TIMEOUT

Set a category only when your flow can reliably identify that condition. Do not label every receiver failure as a timeout.

Place targeted logging at the relevant checkpoint or in an appropriate exception subprocess. An error-category property must exist before the script reads it.

Do not change error-handling behavior merely to simplify logging. Whether a failure remains failed, is retried, or is handled successfully must follow the integration’s functional design.

Step 5: Use Payload Capture Only for a Specific Investigation

Some problems require inspecting message content. A mapping defect, for example, may depend on a particular input structure.

Before capturing content:

1. Try reproducing the issue with synthetic data.
2. Identify the smallest useful fragment or structural detail.
3. Review whether the data contains personal information or secrets.
4. Restrict access and define a cleanup or retention approach.
5. Disable temporary capture when the investigation ends.

Do not assume that truncating a payload makes it safe. Sensitive information may appear in its first few characters.

Use runtime Trace only for a controlled investigation. Trace can expose message content independently of your custom logging script. Check its current status and behavior in your tenant rather than assuming it is inactive.

Changing LogDiagnostics to false does not remove existing attachments or previously captured trace data.

Step 6: Validate the Result

Run these tests:

Test	Expected result
Successful message, diagnostics disabled	Approved correlation field only
Successful message, diagnostics enabled	Correlation and configured stage
Known failure, diagnostics enabled	Safe category at the appropriate error checkpoint
Missing correlation value	Script continues without that custom field
Invalid token format	Value is omitted
Large payload	No payload attachment from this script

In message monitoring, open representative message processing logs and inspect their custom metadata and attachments. Navigation labels can vary by tenant interface.

Compare the original and revised flows using:

• Number of custom attachments.
• Presence of unnecessary payload content.
• Availability of useful correlation fields.
• Ability to identify the failing stage.
• Diagnostic readability.

Do not claim a performance improvement without measurement. The immediate objective is less diagnostic noise with sufficient troubleshooting context.

Step 7: Make Logging Review Routine

Add these checks to integration-flow reviews:

• Does every logged field answer a support question?
• Are full header or property dumps absent?
• Is routine payload capture disabled?
• Are diagnostic switches controlled internally?
• Are identifiers approved for logging?
• Does temporary debugging have an owner and removal plan?

Review shared scripts carefully. One verbose utility can spread the same problem across many flows.

Conclusion

Reducing excessive logging is not about removing visibility. It is about making useful evidence easier to find.

Start with one integration flow. Remove blanket header, property, and payload capture. Introduce a small field allowlist, test both success and failure paths, and verify the result in monitoring.

From an architecture perspective, the best logging contract is one your support team can explain: what each field means, why it is captured, and when it should disappear.

References

• EXCESSIVE Definition & Meaning
• EXCESSIVE Synonyms & Antonyms - 105 words
• Excessive Heat Events Guidebook
• Technical documentation
• Documentation
• Google Docs: Sign-in