How to set a different target end-point for the test environment?

anton
Participant V

Hello

I need to use a different end-points with different flows (e.g. assign different parameters, filter the responses differently, add a custom Python script actions).

Is this possible?

Thanks,

Anton

Solved Solved
0 5 846
1 ACCEPTED SOLUTION

Yes, it is possible to use different endpoints with different flows. ??

But I think you know that.

What do you REALLY want to do?

If you elaborate on your requirements, I can provide some better suggestions.

View solution in original post

5 REPLIES 5

Yes, it is possible to use different endpoints with different flows. ??

But I think you know that.

What do you REALLY want to do?

If you elaborate on your requirements, I can provide some better suggestions.

I don't know how to change the endpoints, the Edge site GUI doesn't support that.

what I really really want 🙂 is:

  • select a proxy
  • select an environment (e.g. test)
  • open the DEVELOP tab for this particular selection
  • set different policies

You will modify a proxy independent of the environment.

you cannot "edit" a proxy+environment combination. You can deploy a particular revision of a particular proxy to an environment. Or undeploy.

MAYBE what you would like is to have a proxy that can query the environment in which it is deployed, and then execute different policies based on that environment.

In that case, you can wrap policies in a Condition. Like so:

  <Flows>
    <Flow name="f1">
      <Request>
        <Step>
          <Name>AM-XmlDoc</Name>
        </Step>
        <Step>
          <Name>XMLToJSON-1</Name>
        </Step>
        <Step>
          <Condition>environment.name = 'test'</Condition> <!-- here -->
          <Name>JS-ImportJsonToContext</Name>
        </Step>
      </Request>
      <Response>
        <Step>
          <Name>JS-EmitElementIntoResponse</Name>
        </Step>
      </Response>
      <Condition>(proxy.pathsuffix MatchesPath "/t1") and (request.verb = "GET")</Condition>
    </Flow>
   ...

To make this happen you must manually add the condition to the XML. Sadly the UI does not provide any assistance for adding Conditions, or for constructing the boolean statements within Condition elements.

You can also add Conditions to Route Rules. For example:

  <RouteRule name='rule1'>
    <TargetEndpoint>target1</TargetEndpoint>
    <Condition>environment.name = 'test'</Condition>
  </RouteRule>

Helpful?

It is helpful, thank you, but I'm not quite there yet. Let's try the latter way - adding conditions to Route Rules.

Would I need to add another <TargetEndpoint name="prod"> tag to apiproxy/targets/default.xml

OR

Would I need to add another file called "prod.xml" next to the "default.xml".

I understand that it should be obvious for Apigee employees but let me tell you, it's a riddle for me. I could find clear and updated documentation on this, or other topics, I was struggling with.

Anyway, back to the topic, now that the frustration level is lower:

After I add another target point, would I need to add it under apiproxy/Shipping.xml (that's the name of my API proxy)?

Anything else?

Thanks in advance.

Yes, Anton, I'm sorry for the frustration. I understand that some aspects of Apigee Edge can be obscure.

The way I have discovered SOME OF these things... is to do things in the UI, then save the proxy and see what it looks like. It is possible to add a second target in the UI; then you can see how it gets realized in the output files.

To answer your question directly, if you use multiple targets, you must have multiple .xml files in the ~apiproxy/targets directory. The names are up to you. (I like to keep the filename consistent with the target name, but that is not required)

So your directory might look like this :

apiproxy/
apiproxy/apiproxy-test.xml
apiproxy/policies/
apiproxy/policies/AM-CleanResponseHeaders.xml
apiproxy/policies/AM-ExpiredApiKey.xml
apiproxy/policies/AM-InvalidApiKey.xml
apiproxy/policies/JS-MaybeFormatFault.xml
apiproxy/policies/RF-UnknownRequest.xml
apiproxy/proxies/
apiproxy/proxies/proxy-endpoint1.xml
apiproxy/resources/
apiproxy/resources/jsc/
apiproxy/resources/jsc/maybeFormatFault.js
apiproxy/targets/
apiproxy/targets/target-endpoint1.xml
apiproxy/targets/target-endpoint2.xml

And then inside the target-endpoint1.xml, you might have:

<TargetEndpoint name='target-endpoint1'>
  <Description>target endpoint 1</Description>
  <FaultRules>
    ...
  </FaultRules>
  <Flows/>
  <PreFlow name='PreFlow'>
    <Request>
    </Request>
    <Response>
    </Response>
  </PreFlow>
  ...
</TargetEndpoint>

the name attribute there must be the one that you reference in the RouteRule. ok, to complete the example, let's look at RouteRules now. These should be present in your API ProxyEndpoint. Perhaps apiproxy/proxies/default.xml (or, in my example, apiproxy/proxies/proxy-endpoint1.xml ).

  <RouteRule name='rule1'>
    <TargetEndpoint>target-endpoint1</TargetEndpoint>
    <Condition>environment.name = 'test'</Condition>
  </RouteRule>
  <RouteRule name='rule2'>
    <TargetEndpoint>target-endpoint2</TargetEndpoint>
    <Condition>environment.name = 'prod'</Condition>
  </RouteRule>
  <RouteRule name='none'/>

The first RouteRule for which the Condition is either TRUE or not present, will be used. The last rule there is a "no route" rule, which means the API proxy doesn't call a backend at all. It's a loopback. That rule would apply if the environment is neither "test" nor "prod". That logic may or may not be what you want. This is just an example.

You do not need to explicitly add the new target to the apiproxy/Shipping.xml file.

Actually when you perform the import (send the zipped directory tree to Apigee Edge), Edge will inspect the ZIP and will build the manifest from the contents of the zip, not from the apiproxy/Shipping.xml file. It does use the apiproxy/Shipping.xml file to determine the name of the API Proxy bundle, and ... a few other things. But basically you don't need to ever modify that thing. The same applies if you were to add a new Policy. No need to modify apiproxy/Shipping.xml .

If you were to export (download) the API Proxy bundle, then Edge would give you an updated apiproxy/Shipping.xml , which would contain a mention of everything - all the targets, policies, etc.

One last thing - we Apigeeks can be a bit sloppy in our terminology. But let me try to clarify one point here. There is a distinction between "API Proxy Bundle" and "API Proxy Endpoint".

Usually when people say "API Proxy" they refer to "API Proxy Bundle", which includes one or more API Proxy endpoints. The very typical case is a single API Proxy has exactly ONE API Proxy endpoint, and so the two can be thought of as synonyms. But being very precise, this isn't quite right - the terms are not really synonyms, because the API Proxy Bundle also includes targets - aka "Target Endpoints". The API Proxy Endpoint does not include Target Endpoints.

In general, an API Proxy Bundle contains

  • one or more Proxy Endpoints
  • zero or more Target Endpoints. The zero case implies a "loopback" Proxy that never calls a target.

And this may be obvious, but: the RouteRules in each Proxy Endpoint define the mapping of requests to Targets. It means you can route requests received at N Proxy Endpoints to one of M Target Endpoints, depending on the conditions you apply.