Dynamically route to target endpoints using javascript based on header parameter

[ramnath_ananth]

I want to dynamically route to different target endpoints to different environments (dev,qa and uat ) based on a header parameter. For eg, if the header has value env = qa , it should be routed to the respective QA target endpoint. Similarly for all other environments.

Please let me know can I achieve this. I would like to achieve this without the creation of target servers.

Thanks

Ramnath

[DChiesa · Accepted solution]

Yes, you can do this. There are two options.

1. explicitly set target.url in a policy, somewhere in the target request flow. This will implicitly override any target url you have specified in the HTTPTargetConnection. For example, suppose you have this in your target:

  <HTTPTargetConnection>
    <Properties/>
    <URL>https://api.example.com/v2</URL>
  </HTTPTargetConnection>

Setting the context variable target.url in the TARGET request flow (not proxy request flow) will override this setting.

2. specify HTTPTargetConnection to refer to variables, like so:

  <HTTPTargetConnection>
    <Properties/>
    <URL>https://{myhost}/{myurlpath}</URL>
  </HTTPTargetConnection>

...and then set context variables myhost and myurlpath in the target request flow.

[ramnath_ananth]

Hi Dino,

I implemented both methods, but the target url is not getting replaced with the one set in the javascript policy.

Method 1:

var url = "my-test-url";  // this url should replace the target endpoint

context.setVariable("myurl", url);

 <HTTPTargetConnection>
        <Properties>
            <Property name="success.codes">2xx, 4xx, 5xx</Property>
        </Properties>
        <URL>http://{myurl}</URL>
        <Path>/esg</Path>
  </HTTPTargetConnection>

Method 2:

In this approach, I get Unexpected EOF error

var url = "my-test-url";  // this url should replace the target endpoint

context.setVariable("target.url", url);

<HTTPTargetConnection>
        <Properties>
            <Property name="success.codes">2xx, 4xx, 5xx</Property>
        </Properties>
        <URL>http://api.test.com</URL>
        <Path>/esg</Path>
  </HTTPTargetConnection>

Please let me know where I am going wrong. Also, can I add more target endpoints in the http target configuration ? This is required since one environment has 2 target servers

[DChiesa]

I suspect you are not setting target.url in the Target Request flow.

See attached for a working example.

You can deploy it to any Edge org, and invoke it repeatedly as:

curl -i https://MYORG-MYENV.apigee.net/ramnath-1

There is a JS policy that will randomly select one of three target URLs . The proxy will respond with different responses depending on which target has been selected. Also see the injected response header, `x-chosen-header`, which indicates the selected target.

ramnath-1.zip

[#5]

Hello @Dino @Anil Sagar

In my case, we have loadbalancer in target server as below.

However if use target.url for few cases then will targte.url override loadbalancer?

<HTTPTargetConnection>
        <LoadBalancer>
            <Server name="BIZX-API-LB-INT"/>
        </LoadBalancer>
        <Path>/</Path>
        <Properties>
            <Property name="use.proxy">false</Property>

[dchiesa1]

yes

[ramnath_ananth]

thanks Dino, the code provided works !

[anilsr]

@Ramnath

Glad to know, Please accept the answer by clicking on Accept link below the answer so that it will be also helpful for others. It's the way to recognize best answer and gives credit to the user who answered same. Thank you.

[ramnath_ananth]

Can we perform load balancing between target servers through javascript callout by extending the above solution ?

[DChiesa]

Please ask new questions with the "Ask a Question" button.

[Testee]

I'm trying the option 2, however the variables are not getting replaced.

I have to go with this option as I have SSLInfo block as well, so JS target.url option doesn't fit here.. and this option 2 doesn't really replace the variables.

Can you kindly execute once and share it.

[dchiesa1]

have you checked my reply on this thread of September 6, 2016 ? 

It's worth a re-read. Except now the UI is a little different.