Chris Phillips’ Blog - API, Integration and Governance

When using the rate limit policy on the Assembly you need to first create a rate limit in datpower in the API Gateway object. This must be done via a GatewayExtension to stop the policy being removed when a publish request is done from API Connect.

This article will show you to create the rate limit objects in DataPower using a gateway extension.

We will create a rate limit called chrisblog-ratelimit that can be referenced from a rate limit policy.

While testing disaster recovery it is advisable to take offline the primary API Manager. This instructions will cover OpenShift and Kubernetes.

Setting a downstream proxy is often a requirement when API Connect needs to make calls to the invoke downstream services on the internet.

In part 1 we discussed what a multipart API was and how it can be parsed in API Connect. In this part we will take that knowledge and apply it to a real situation.

Scenario: Upload two images, validate that the images are png and that the size is less then 1MB.

MultiPart API calls allow multiple sets of data to be sent to an API as individual items. If you have a series of images and text you need to upload you could write a curl command similar to

curl -vk -F 'name=fred' -F "name2=@image.png" https://APIURL/ -H "content-type: multipart/related"

This articles covers the key pieces of information that needs to be passed on to the load balancer team to configure the load balancer of choice.

Please Note: DataPower Self Load balancing with the AIO module is not supported with API Connect v10.

AppConnect Enterprise recommends enabling OpenTelemetry to provide end to end tracing.

This article will explain how to enable it in a new deployment or augment it to an existing deployment in ACE.

When each API Connect component looses quorums it changes how the components work.

This is an updated to my 2019 article, which could have been clearer.

This was originally published on 3rd October 2022 on IBM Community. Republished with permission from author

It is a common mistake to simply add more resources to a system to get more performance. For example, one might enlarge the thread pools and database connection pools, assuming more threads can do more work and therefore process more messages. This can be true up to a point, but beyond that it may result in no performance increase, or even significantly reduced performance. This article attempts to describe a situation where these two things can happen.

Having a good set of in-house API Governance rules allow your developers to validate that their APIs meet their enterprise standards. Other rules can be used to ensure serviceability considerations are made to support the API or can highlight where anti patterns are being used.

I have been challenged by API Connect’s Product Management to come up with some sensible governance rules. I expect this article to grow from time to time as new ideas are formed.