Defect in the api flow, or possibly the trace view

Google Cloud Apigee
1

3713-trace-step1.jpg
3713-trace-step1.jpg882×640 82.3 KB

3714-trace-step2.jpg
3714-trace-step2.jpg908×583 84.6 KB

3715-trace-step3.jpg
3715-trace-step3.jpg900×574 81 KB

3716-trace-step4.jpg
3716-trace-step4.jpg1025×559 81.1 KB

I have an API proxy and I’m extracting values from the original request to do target path replacement. Trace view is showing conflicting values.

Here is my target endpoint

<HTTPTargetConnection>
    <Properties/>
        <URL>http://data.tmsapi.com/v1.1/theatres/{data-theatreId}/movies</URL>
</HTTPTargetConnection>

In the preflow for that endpoint, I have three policies, logically, extractTheaterId, assignTheaterId, assignApiKey. Neither of my assigns create a new message.

Here is the extract policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables async="false" continueOnError="false" enabled="true" name="extractTheatreIdFromMoviesPath">
    <DisplayName>extractTheatreIdFromMoviesPath</DisplayName>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <Source clearPayload="false">request</Source>
    <URIPath>
        <Pattern ignoreCase="true">/{data-theatreId}/movies</Pattern>
    </URIPath>
</ExtractVariables>

Here is the assignTheaterId

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="addTheatreIdMovies">
    <DisplayName>addTheatreIdMovies</DisplayName>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <AssignTo createNew="true" transport="http" type="request"/>
    <AssignVariable>
        <Name>target.url</Name>
        <Value>http://data.tmsapi.com/v1.1/theatres/{data-theatreId}/movies</Value>
    </AssignVariable>
</AssignMessage>

And here is the assignApiKey (obfuscated)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="addGraceApiKey">
    <DisplayName>addGraceApiKey</DisplayName>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
    <Add>
        <QueryParams>
            <QueryParam name="api_key"> -OBFUSCATED- </QueryParam>
        </QueryParams>
    </Add>
</AssignMessage>

(I know it’s not right to store it this way but this is just for POC at the moment

When you look at the trace views that I’ve attached, it appears in the header to have done the replacement for theaterId, but if you see the target.url and the “show curl”, in both those places it is still my variable name. You will also see in the trace view headers, you see the api key, but in the curl there is no api key.

This is very confusing and I hope I’m doing something wrong or somebody can recommend a different strategy.

2

@Kd Ford , I know trace is not consistent when you are changing the target.url flow variable midway. Trace is mostly used for debugging & troubleshooting API Proxies. It has information what you are looking for but not exactly that you want to see. I don’t see anything wrong with trace tool. I believe it’s what it is.

On a separate note, I went through your proxy,

I think the way you are implementing proxy resources is little bit strange. You don’t need to define multiple target endpoints for different resources of same target hostname, basepath. Not necessarily you need route rules in your use case.

You can define target endpoint as http://data.tmsapi.com/v1.1/theatres/" & use conditional flows / resources in proxy. By default, Apigee forwards proxy path suffix to targetendpoint. It will help you maintain your proxy & re-use policies. Find more about Understanding Flows & Configuring Flows.

Let me know if you need any help with updating your proxy with different conditional flows as API resources. Hope it helps.

3

Thanks Anil.. I’m going to read those docs again and loop back here to make a straw man of the approach for your comments.

4

@Anil Sagar I actually have a question. The diagram here looks as if proxyEndpoint.postFlow executes before targetEndpoint.preFlow. Is that right?

5

Yes, that’s correct. Proxyendpoint Request PostFlow executes before targetEndpoint Request postflow.

Incase of response, TargetEndpoint Response PostFlow executes before proxyEndpoint Response postflow.

BTB, Above concept is very important when it comes to Apigee Edge Proxy, Take your time & understand same completely. Keep us posted if any.

6

It turns out, at least for me, that the auto-generated RouteRules do not have a defined. I need to put those in manually, pointing them to “default” and then I got the behavior you described.

Thanks for the help!