19.03.01 - Apigee Edge for Public Cloud release notes

Load balancing - more control for removing failing servers

When configuring a load balancer for an API proxy, you can determine how many response failures occur before a server is removed from the load balancing rotation. A response failure means Apigee doesn't receive any response from a target server. When this happens, the failure counter increments by one. When Apigee does receive a response from a target, even if the response is an HTTP error (such as 500), that counts as a response from the target server, and the failure counter is reset. To help ensure that bad HTTP responses (such as 500) also increment the failure counter to take an unhealthy server out of load balancing rotation as soon as possible, you can add a new <ServerUnhealthyResponse> element with <ResponseCode> child elements to your load balancer configuration. Edge will also count responses with those codes as failures.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

AccessControl policy enhancements

The AccessControl policy determines which IP addresses can make calls to an API proxy. A new element on that policy give API developers more control in identifying which IP addresses to evaluate.

<IgnoreTrueClientIPHeader>: Optional (default is false). When you set this to true, the policy ignores the True-Client-IP header and evaluates IP addresses in the X-Forwarded-For header, following the X-Forwarded-For evaluation behavior you've configured.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

For details, see this Community post.

Two new elements are available in the RaiseFault policy to make FaultRules handling cleaner and more powerful.

• ShortFaultReason is a boolean that, when set to true, puts the policy name in the fault.reason variable.
• AssignVariable, available in the FaultResponse, lets you assign the fault response to a variable to be used by other policies in the API proxy flow.

Limits are now being enforced for Hosted Targets. See Limits for limits details.

You can now use message template variables to set IP addresses and CIDR masks on the AccessControl policy. For example, if you want to store an IP address and mask in a key value map (KVM), you can retrieve those values from a variable you set in the API proxy flow. This lets you change IP values more easily at runtime without having to change your policy configuration.

For example, instead of:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

You could configure the policy like this, assuming the values are stored in a KVM, and you use the KeyValueMapOperations policy to retrieve the values and assign them to the variables shown here:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

API Monitoring provides two roles: API Monitoring Administrator and API Monitoring User, described in Access API Monitoring. These were made available in December 2018.

Edge now adds the header X-Apigee.Message-Timeout to each request. This header is for internal use by Edge. Do not rely on the values in the X-Apigee.* headers in your API proxies as these headers are not intended for customer use and can be removed or changed by Apigee at any time.

Handle keystore deletion errors so that API call does not fail

x-apigee.edge.execution.sense.action is always set to null

In ResponseCache policy, NIOTheread is executing without rejection from the thread pool

Multiple log exporters on Apigee routers cause high CPU usage

Intermittent 404s in specific organizations

Deployed Shared Flow not executing on some message processors

This fix will be included in the next Edge for Private Cloud release.

This fix will be included in the next Edge for Private Cloud release.

This fix will be included in the next Edge for Private Cloud release.