apigee x complete log headers req params

[pato17]

What is the most time-efficient way to log everything (request and response headers, query parameters, or path variables) in Apigee X for all response types (200, 400, or 500)? I'm trying to create a structured log object in a JavaScript policy within the PostFlow, but handling the headers is cumbersome and the resulting object is messy. How can I do this more effectively?

[markjkelly]

Hi @pato17 ,

Have you seen this example? I think it may be a useful reference for you. In addition this answer may also help you with logging headers, sounds like you may need to combine both to get the outcome you are looking for.

Hope this helps!

[ssvaidyanathan]

@pato17 - Check this sample. Its a sharedflow that created a good structure of most fields that might be necessary. Since its a SF, you can re-use it across all your proxies. 

[pato17]

Thanks for the help, but none of these methods fully capture the request and response. That's not even the main issue; the primary goal is to log all those variables (request/response headers& params) in the most efficient way to avoid impacting performance. Is there a better approach than creating an object in a JavaScript policy(in postflow) and sending it in the PostClientFlow?

[nmarkevich]

Hey @pato17 , JavaCallout is usually more efficient than JavaScript for this since Java runs natively. That said, blindly logging all headers and parameters is a bad idea - these can contain PII or other sensitive data.

[pato17]

Hey, regarding performance, would it be better to create the JSON object using a Java Callout? What would be the performance cost of making a call to a Java JAR?

[nmarkevich]

Yes, JavaCallouts are generally more performant.

Java code runs natively on the JVM, while JavaScript in Apigee is executed via Rhino, a Java-based JS engine. Even though Rhino is written in Java, it adds an extra processing layer that can't match native Java performance.

Also, the main class of a JavaCallout is instantiated at deploy time, not per request, which helps with efficiency. I'm not sure the same happens with JavaScript policies.

So for performance-critical tasks JavaCallout is usually the better choice.