Effective Axios Error Logging for Robust SAP Integrations
Share

[[{“value”:”

Comparing Error Responses: Which One Aids Debugging Better?

Suppose we have executed an HTTP request using CAP and it fails. Below are two logged error responses:

1st Scenario:
Axios-Error.png
2nd Scenario:
Axios-Error-Handling.png

It’s immediately clear which version is easier to debug and helps us quickly identify the reason for the failure.

When building SAP extensions or integrations, developers often rely on Axios for handling HTTP requests. While Axios simplifies API communication, error handling can quickly become a challenge—especially when debugging complex integration scenarios.

In many projects, errors are either logged with too little detail (just a generic message) or with too much raw data, making debugging time-consuming. To improve maintainability and speed up root cause analysis, we need a structured error logging mechanism.

Why Structured Error Logging Matters

In enterprise scenarios like SAP SuccessFactors or SAP BTP service integrations, requests often involve multiple systems. Without detailed error insights, you might only see:

Error: Request failed with status code 400

 But what you really need is:

  • Which endpoint failed?

  • What payload was sent?

  • What was the response from the server?

  • Was there any custom error code attached?

This is where a structured error handling approach becomes invaluable.

Implementation: A Structured Axios Error Logger

Here’s a reusable utility function you can plug into your Node.js / TypeScript projects:

public getAxiosErrorObject(error: any) {
if (error.isAxiosError) {
const errorObj = {
message: error.message || ‘An error occurred during the request.’,
code: error.code || ‘UNKNOWN’,
status: error.response ? error.response.status : ‘No Status’,
statusText: error.response ? error.response.statusText : ‘No Status Text’,
requestData: error.config ? error.config.data : ‘No Request Data’,
requestMethod: error.config ? error.config.method : ‘No Request Method’,
requestUrl: error.config ? error.config.url : ‘No Request URL’,
responseData: error.response ? error.response.data : ‘No Response Data’
};
return errorObj;
}
return {
message: error.message || ‘An unknown error occurred’,
stack: error.stack || ‘No Stack Trace’
};
}

 

How It Works

  • Checks if it’s an Axios error
    Axios sets error.isAxiosError = true. This allows us to distinguish between HTTP request errors and other runtime issues.

  • Captures request details
    The request URL, method, and payload are logged, which is crucial for reproducing and debugging issues.

  • Captures response details
    If the server responded, we extract the status code, status text, and response body.

  • Fallback for non-Axios errors
    In cases where the error didn’t come from Axios (e.g., runtime exceptions), we still log a meaningful message and stack trace.

Example Usage

try {
const response = await axios.post(‘/api/employees’, { name: ‘Sahil M’ });
console.log(response.data);
} catch (error) {
const structuredError = this.getAxiosErrorObject(error);
console.error(‘API Error:’, structuredError);
}

Example Output  

{
“message”: “Request failed with status code 400”,
“code”: “ERR_BAD_REQUEST”,
“status”: 400,
“statusText”: “Bad Request”,
“requestData”: “{“name”:”Sahil M”}”,
“requestMethod”: “post”,
“requestUrl”: “/api/employees”,
“responseData”: {
“error”: “Invalid employee data”
}
}

Best Practices

  1. Avoid logging sensitive data
    When logging request payloads, ensure no confidential fields (e.g., passwords, tokens) are exposed.

  2. Integrate with monitoring tools
    Forward structured error logs to tools like SAP Cloud Logging for central monitoring.

  3. Normalize error structure
    Use this function as a single source of truth for error logging across your project, ensuring consistent logs.

  4. Enhance with correlation IDs
    In SAP integrations, add transaction or correlation IDs to quickly trace requests across systems.

“}]] 

 [[{“value”:”Comparing Error Responses: Which One Aids Debugging Better?Suppose we have executed an HTTP request using CAP and it fails. Below are two logged error responses:1st Scenario:2nd Scenario:It’s immediately clear which version is easier to debug and helps us quickly identify the reason for the failure.When building SAP extensions or integrations, developers often rely on Axios for handling HTTP requests. While Axios simplifies API communication, error handling can quickly become a challenge—especially when debugging complex integration scenarios.In many projects, errors are either logged with too little detail (just a generic message) or with too much raw data, making debugging time-consuming. To improve maintainability and speed up root cause analysis, we need a structured error logging mechanism.Why Structured Error Logging MattersIn enterprise scenarios like SAP SuccessFactors or SAP BTP service integrations, requests often involve multiple systems. Without detailed error insights, you might only see:Error: Request failed with status code 400 But what you really need is:Which endpoint failed?What payload was sent?What was the response from the server?Was there any custom error code attached?This is where a structured error handling approach becomes invaluable.Implementation: A Structured Axios Error LoggerHere’s a reusable utility function you can plug into your Node.js / TypeScript projects:public getAxiosErrorObject(error: any) {
if (error.isAxiosError) {
const errorObj = {
message: error.message || ‘An error occurred during the request.’,
code: error.code || ‘UNKNOWN’,
status: error.response ? error.response.status : ‘No Status’,
statusText: error.response ? error.response.statusText : ‘No Status Text’,
requestData: error.config ? error.config.data : ‘No Request Data’,
requestMethod: error.config ? error.config.method : ‘No Request Method’,
requestUrl: error.config ? error.config.url : ‘No Request URL’,
responseData: error.response ? error.response.data : ‘No Response Data’
};
return errorObj;
}
return {
message: error.message || ‘An unknown error occurred’,
stack: error.stack || ‘No Stack Trace’
};
} How It WorksChecks if it’s an Axios errorAxios sets error.isAxiosError = true. This allows us to distinguish between HTTP request errors and other runtime issues.Captures request detailsThe request URL, method, and payload are logged, which is crucial for reproducing and debugging issues.Captures response detailsIf the server responded, we extract the status code, status text, and response body.Fallback for non-Axios errorsIn cases where the error didn’t come from Axios (e.g., runtime exceptions), we still log a meaningful message and stack trace.Example Usagetry {
const response = await axios.post(‘/api/employees’, { name: ‘Sahil M’ });
console.log(response.data);
} catch (error) {
const structuredError = this.getAxiosErrorObject(error);
console.error(‘API Error:’, structuredError);
}Example Output  {
“message”: “Request failed with status code 400”,
“code”: “ERR_BAD_REQUEST”,
“status”: 400,
“statusText”: “Bad Request”,
“requestData”: “{“name”:”Sahil M”}”,
“requestMethod”: “post”,
“requestUrl”: “/api/employees”,
“responseData”: {
“error”: “Invalid employee data”
}
}Best PracticesAvoid logging sensitive dataWhen logging request payloads, ensure no confidential fields (e.g., passwords, tokens) are exposed.Integrate with monitoring toolsForward structured error logs to tools like SAP Cloud Logging for central monitoring.Normalize error structureUse this function as a single source of truth for error logging across your project, ensuring consistent logs.Enhance with correlation IDsIn SAP integrations, add transaction or correlation IDs to quickly trace requests across systems.”}]] Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL

By ali