Post Client Flow and System Variables

Not applicable

So i have been working on a good solution to output log information in a usable format for requests & responses. I have identified which part of the Apigee flow i need to use the message- logging policy one to get the information i need:

1) Inbound request from client: Proxy Endpoint Default Pre-Flow Request

2) outbound request to target endpoint: Target Endpoint Default Pre-Flow Request

3) inbound answer from target endpoint: Target Endpoint Default Post-Flow Request

4) outbound to client from proxy: Proxy Endpoint PostClientFlow

Heres the problem: the date/time stamp formats that we get access to are limited to non iso standard values. This is great when in steps 1-3.. because we can use (yet another policy) a javascript policy to do date conversion w/ the .toISOString() method. (thansk to @Diego Zuluaga and @Sudheer Gopalam for the help HERE)

But - javascript policies cant be attached to the PostClientFlow! This unfortunately breaks the value of doing any conversions to iso date formats.

Does anyone have any suggestions?

0 5 1,698
5 REPLIES 5

Not applicable

Thanks, @Benjamin Goldman. I thought context variables set through JavaScript are global, so you can leverage them from all flows. From your findings, it sounds as if these variables were not available. What value do you obtain when trying to access the variable from PostClientFlow?

If that's the case, I wonder if you can consider leveraging session object instead.

so I guess i need to add a bit more detail here.

The above represents a 4 part flow right?

At each step i need to log important information:

1) Inbound request from client: Proxy Endpoint Default Pre-Flow Request

Client request start time, client request end time, client ip, request uuid, and a calculated request duration.

2) outbound request to target endpoint: Target Endpoint Default Pre-Flow Request

Havnt started working on this yet.

3) inbound answer from target endpoint: Target Endpoint Default Post-Flow Request

Havnt started working on this yet.

4) outbound to client from proxy: Proxy Endpoint PostClientFlow

Client response start timestamp client response end timestamp, response code and reason, request UUID, a calculated response duration, and OPTIONALLY a response payload in plain text.

In step 1 - we realized that we only had two formats of time we had easy access to:

EPOC time: client.request.start.timestamp & client.request.end.timestamp expressed as a 64 bit (long) integer - pretty standard for app internals

Or some other time format: client.request.start.times & client.request.end.times expressed as a string in this format: 'Wed, 21 Aug 2013 19:16:47 UTC'

Neither are the ubiquitous ISO standard time format. This makes things interesting. Right? So instead of dealing with the mess we use a javascript policy to make new context variables that convert the epoc to the correct timestamp is being generated so i never have to worry about it upstream.

Now i skip to step 4 - Here things get interesting because im working on. Initially we thought that to write the log information we wanted out correctly we would attach to the

Proxy Endpoint Default Post-Flow Response Flow. We were here and the variables we needed, client.sent.start.timestamp & client.sent.end.timestamp were returning -1.

A quick check of the trace tool showed why: The variables were not set yet because the client response came AFTER the policies were executed!

Checking the Apigee documentation we found out about the optional flow Proxy Endpoint PostClientFlow allows access to these with one MASSIVE caveat: i cant do any javascript conversions on this - so i Cant output data in iso standard format.

So in most cases the context variables are a great help- but if you want to get really accurate timings out of a flow you are going to have to deal with this problem still.

If there is some way to embed a javascript method in the log policy its self this will all work for me - otherwise things are going to be interesting.

Not applicable

Hi, @Benjamin Goldman. You could write the desired ISO timestamp string into a variable or header as the last step in the Proxy PostFlow Response, just before you enter the PostClientFlow. Then you can log the already-converted variable inside PostClientFlow. This will admittedly introduce a very small error.