Asynchronous Logging in SAP API Management

[Aishwarya_Pola]

Introduction

When configuring APIs in SAP API Management, it is as important aspect to configure info logging or error logging and then send it across to the downstream systems like Loggly, ServiceNow etc. which is Synchronous mode by default. Since the default logging in API Proxies takes place in Synchronous mode, the consumer of the API Proxy must wait for all backend calls to finish, which increases the total response time which is a big concern in the Request-Reply pattern.

This blog explains how to implement true asynchronous logging in SAP API Management. The main objective of this blog is to showcase the approach of implementing Asynchronous logging in APIM and improve the response time which is so critical for Request-Reply Pattern.

Synchronous vs Asynchronous Logging

Before building the necessary Artifacts for enabling Asynchronous logging, let’s understand the behavioral difference:

Synchronous Logging

When a request arrives, the API proxy processes it to the target backend and then directly calls logging systems like Loggly where in the result could be success or failure. If it is success ,the flow moves into the PostFlow of the proxy endpoint. Here, the proxy makes a synchronous call to the logging system. The response is sent to the consumer only after this logging call finishes, which increases the overall response time. If there is a failure, the flow triggers FaultRules where error logging happens synchronously, and the error response is sent only after the logging call completes.

Asynchronous Logging

When a request arrives, the API proxy processes it and immediately sends the response back to the api proxy consumer due to async mode of logging. Logging operations happen separately in the background by queuing messages to JMS for later processing. Background processes handle the actual delivery to Loggly or other logging platforms. If logging fails, it gets retried without impacting the response time.

Compared to synchronous logging, this approach helps APIs respond faster, keeps logging problems away and perform well even during high traffic.

Architecture Overview

Implementation Steps:

Step 1:Create a proxy endpoint:

After creating the proxy endpoint, include the following policies:

Step 2: Extract the Control Header

First, we add a header to control when asynchronous logging should be used.

Policy: ExtractVariables-Flag.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<! -- Extract AsyncFlag from incoming HTTP header -->
    <Header name="AsyncFlag">
        <Pattern>{AsyncFlag}</Pattern>
    </Header>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
</ExtractVariables>

This extracts the AsyncFlag header from the request. When the value is "true", asynchronous logging will be triggered.

Step 3: Prepare the Log Payload

Build the log message containing all the request details you want to capture. This structured JSON format makes it easy to search and analyze logs in Loggly.
Policy: AssignMessage-LogPayload.xml

<!-- This policy assigns a log payload JSON to a variable -->
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>
  <AssignVariable>
    <Name>LogPayload</Name>
    <Value>
      {
        "timestamp":”system.timestamp}",
        "messageId":"{messageid}",
        "apiProxy":"{apiproxy.name}",
        "environment":"{environment.name}",
        "logLevel":"INFO",
        "description":"Request received for processing",
        "syncFlag":"{req.AsyncFlag}",
        "targetURL":"{target.url}"
      }
    </Value>
  </AssignVariable>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" type="request">request</AssignTo>
</AssignMessage>

This creates a variable called LogPayload containing a JSON object.

Step 4: Configure the Async Log Request

Prepare the request object that will be used to send logs asynchronously. This step structures how the log data will be transmitted to the logging system.

Policy: AssignMessage-AsyncLogRequest.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<!-- Assign payload and headers for async log request -->
  <AssignVariable>
    <Name>AsyncLogRequest.payload</Name>
    <Value>{logPayload}</Value>
  </AssignVariable>
<AssignVariable>
    <Name>AsyncLogRequest.header.Content-Type</Name>
    <Value>application/json</Value>
  </AssignVariable>
<AssignVariable>
    <Name>AsyncLogRequest.verb</Name>
    <Value>POST</Value>
  </AssignVariable>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="true" type="request">AsyncLogRequest</AssignTo>

Step 5: Configure Authentication Credentials

Configure the authentication needed to securely call your SAP Cloud Integration endpoint. Store your cloud integration client credentials and encode them into the proper authorization header format that will be used when sending logs.

Step 6: Trigger Asynchronous Logging via Integration Flow and JMS

In this step, the API proxy hands over the prepared log payload to an integration endpoint asynchronously, and from there the message is written into a JMS queue. This asynchronous approach ensures that it does not wait for the logging response and no delay to the consumer.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Request clearPayload="true">
        <Set>
            <Headers>
                <Header name="Content-Type">application/json</Header>
                <Header name="Authorization">{sapapim.Authorization}</Header>
            </Headers>
            <Payload contentType="application/json">{logPayload}</Payload>
            <Verb>POST</Verb>
        </Set>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>cpi.logresponse</Response>

    <Timeout>30000</Timeout>

    <HTTPTargetConnection>
        <URL>https://{cpi-tenant-url}/http/Async_toJMS</URL>
    </HTTPTargetConnection>
</ServiceCallout>

Important: This policy is configured to be executed only when the condition request.header.AsyncFlag = "true" is met. This means asynchronous logging is triggered based on the header value sent in the request.

Once the integration endpoint receives the log payload, it stores the message in a JMS queue instead of sending it directly to Loggly or another logging system. This is where real asynchronous behavior comes from.

Why JMS helps with asynchronous logging?

JMS queues let the integration flow accept a log message, drop it into a queue, and return immediately. The queue takes responsibility for the message from that point on. A separate consumer reads from the queue later and sends the log to Loggly or any other target system such as service now etc.

This means the logging process is completely decoupled from the original request. The API response is not tied to how fast Loggly responds or whether it is even available at that moment. The request finishes as soon as the business logic is done, while JMS guarantees that the log will be processed in the background, which is exactly the asynchronous behavior we want.

Conclusion

Asynchronous logging keeps logging out of the API’s critical execution path. The API finishes its business processing and sends the response back to the client right away, while logs are passed in the background to the integration layer and JMS for delivery to Loggly.

This way, response times stay fast, logging delays or outages don’t affect the API, and you still get all the visibility needed for monitoring and troubleshooting. It’s a practical approach that balances performance, reliability, and observability, making it a good fit for high-volume, enterprise APIs.