SAP API Management - Antipatterns

[maxi1555]

Hi experts,

As you probably already know SAP API Management uses apigee under the hood, this means that apigee best practices apply to SAP API Management 🙂

I wanted to share with you a book of apigee antipatterns that should be mandatory for all those who have started or will begin their journey in this world of APIs through SAP API Management, to avoid common pitfalls.

Below you can find the most common pitfalls in the development of an API in SAP API Management:

1. Policy Antipatterns
   
   
   
   1. Use waitForComplete() in JavaScript code
   
   
   2. Set Long Expiration time for OAuth Access and Refresh Token
   
   
   3. Use Greedy Quantifiers in RegularExpressionProtection policy
   
   
   4. Cache Error Responses
   
   
   5. Store data greater than 512kb size in Cache
   
   
   6. Log data to third party servers using JavaScript policy
   
   
   7. Invoke the MessageLogging policy multiple times in an API proxy
   
   
   8. Configure a Non Distributed Quota
   
   
   9. Re-use a Quota policy
   
   
   10. Use the RaiseFault policy under inappropriate conditions
   
   
   11. Access multi-value HTTP Headers incorrectly in an API proxy
   
   
   12. Use Service Callout policy to invoke a backend service in a No Target
       API proxy
   
   
   
   


2. Performance Antipatterns:
   
   
   
   1. Invoke Management API calls from an API proxy
   
   
   2. Invoke a Proxy within Proxy using custom code or as a Target
   
   
   3. Manage Resources without using Source Control Management
   
   
   4. Access the Request/Response payload when streaming is enabled
   
   
   5. Define multiple ProxyEndpoints in an API proxy
   
   
   
   


3. Backend Antipatterns
   
   
   
   1. Allow a Slow Backend
   
   
   2. Disable HTTP persistent (Reusable keep-alive) connections
   
   
   
   

Book: Link

Let's take an extraction of the book for "Configure a Non Distributed Quota" from "Policy Antipatterns"( replacing "apigee" by "SAP API Management" ):

"..."

SAP API Management provides the ability to configure the number of allowed requests to an API proxy for a specific period of time using the Quota policy.

Antipattern:

An API proxy request can be served by one or more distributed SAP API Management components called Message Processors. If there are multiple Message Processors configured for serving API requests, then the quota will likely be exceeded because each Message Processor keeps it’s own ‘count’ of the requests it processes.

Let’s explain this with the help of an example. Consider the following Quota policy for an API proxy -

<!-- /antipatterns/examples/1-6.xml -->

<Quota name="CheckTrafficQuota">

 <Interval>1</Interval>

 <TimeUnit>hour</TimeUnit>

 <Allow count="100"/>

</Quota>

The above configuration should allow a total of 100 requests per hour.

However, in practice when multiple message processors are serving the API requests, the following happens

In the above illustration:
-The quota policy is configured to allow 100 requests per hour.
-The requests to the API proxy are being served by two Message Processors.
-Each Message Processor maintains its own quota count variable,quota_count_mp1 and quota_count_mp2, to track the number of requests they are processing.
-Therefore each of the Message Processor will allow 100 API requests separately.The net effect is that a total of 200 requests are processed instead of 100 requests.

Impact:

This situation defeats the purpose of the quota configuration and can have detrimental effects on the backend servers that are serving the requests.

The backend servers can:

-be stressed due to higher than expected incoming traffic

-become unresponsive to newer API requests leading to 503 errors

Best Practice:

Consider, setting the element "Distributed" to true in the Quota policy to ensure that a common counter is used to track the API requests across all Message Processors. The element "Distributed" can be set as shown in the code snippet below:

<!-- /antipatterns/examples/1-7.xml -->

<Quota name="CheckTrafficQuota">

 <Interval>1</Interval>

 <TimeUnit>hour</TimeUnit>

 <Distributed>true</Distributed>

 <Allow count="100"/>

</Quota>

"..."

 

I hope this helps you avoid the most common pitfalls in API development.

 

Not forget, be curious! ?

Max.