Overriding target.basepath and target.url via Javascript worked previously, but now not

[#1]

I was successfully using the following Javascript to override the target.basepath and/or target.url for certain operations that need to a different controller in the target application. This no longer works though as it seems the variables are now read only. Is there a way to get this working again? The javascript is in the target Endpoints Preflow. In the trace on this new release, the "targetUrl" now shows as N/A.

var proxyPathSuffix = context.getVariable("proxy.pathsuffix");
print("proxy.pathsuffix=" + proxyPathSuffix + " ");
var requestVerb = context.getVariable("request.verb");
print("requestVerb=" + requestVerb + " ");
if (!proxyPathSuffix.localeCompare("/special-operation") && !requestVerb.localeCompare("POST")) {
  var targetBasePath = context.getVariable("target.basepath");
  print("targetBasePath=" + targetBasePath + " ");
  if (targetBasePath && targetBasePath.localeCompare("")) {
    var newTargetBasePath = targetBasePath.replace("old-context-path", "new-context-path");
    context.setVariable("target.basepath", newTargetBasePath);
    targetBasePath = context.getVariable("target.basepath");
    print("targetBasePath=" + targetBasePath + " ");
  } else {
    print("ERROR: targetBasePath is null! ")
  }
}

[robinm]

Hey @Donald Collett.

It doesn't look as if you are going to get any other answers, so here's comments and a workaround :-

1. Trace shows those variables with a "not-equal" sign (crossed-out equals) - I guess that means read-only, yes. (and I suspect can happen if the value is rejected for syntax or similar)

2. Same effect with Javascript or with AssignMessage

3. The workaround: Rewrite the full target.url ... protocol,hostname and basepath, e.g

 var host = context.getVariable("target.url");
 var suffix = context.getVariable("proxy.pathsuffix");
 var newURL = host.concat(suffix);
 context.setVariable("target.url",newURL);

HTH.

[dchiesa1]

Good answer @Robin Martin .

target.basepath is documented as being read-only.

I am not aware of any recent change, either in documentation or in behavior.

Setting target.url has always worked.

[#4]

It was working like your example previously but our Apigee portal was updated and it stopped working. In the Target Endpoint PreFlow, the target.url is now showing a value of " -NA-" like its been depreciated or something. So the attempt to modify the target.basepath.

Called the context.setVariable("target.url",newURL) but it no longer sets the target.url. I printed the newURL right before setting then called the context.getVariable("target.url") and it came back null.

[#5]

@Donald Collett

I am also facing the same issue. Please let me know if you find any solution for this.

[#6]

What I found is "target.url" is only usable if you use a <URL> in the <HTTPTargetConnection>. If you use <LoadBalancer>, then "target.url" becomes unusable.

In my case, the need for load balancing can be handled by setting the <URL> to a VIP provided by an F5 load balancer.

Ran into another limitation in that apparently variables such as {host} and {port} can't be used inside the <URL>. The functionality doesn't appear to be implemented. So that blocked us from making the URL dynamic from variables defined in Environment Configuration Key Value Maps using the Key Value Map Operations policy.

[dchiesa1]

If you use <LoadBalancer>, then "target.url" becomes unusable.

True.

You can do something like this

  <HTTPTargetConnection> 
    <SSLInfo> 
      <Enabled>true</Enabled> 
    </SSLInfo> 
    <LoadBalancer> 
      <Server name="testserver"/> 
    </LoadBalancer> 
    <Path>{mypath}</Path> 
  </HTTPTargetConnection> 

...and then the Path element is treated as a Message template - the values of the variable (or variables, if you use more than one) are inserted into the string.

[dchiesa1]

This can happen if you use an HTTPTargetConnection with a LoadBalancer element, like this:

  <HTTPTargetConnection> 
    <SSLInfo> 
      <Enabled>true</Enabled> 
    </SSLInfo> 
    <LoadBalancer> 
      <Server name="testserver"/> 
    </LoadBalancer> 
    <Path>/foo</Path> 
  </HTTPTargetConnection> 

In that case, setting target.url is ineffectual.

The good news is that the Path element is a Message Template. So you can do this:

  <HTTPTargetConnection> 
    <SSLInfo> 
      <Enabled>true</Enabled> 
    </SSLInfo> 
    <LoadBalancer> 
      <Server name="testserver"/> 
    </LoadBalancer> 
    <Path>{mypath}</Path> 
  </HTTPTargetConnection> 

...and the variable "mypath" will be used for the path.