-
Notifications
You must be signed in to change notification settings - Fork 18
8.4. Caching
The APIM-CLI is using the official API-Manager REST-API in order to load the Actual-API(s).
Based on the number of APIs, Applications, Organizations and how they are related to each other (e.g. how many subscriptions to an API), this might result in a massive amount of requests and significantly reduces the performance of the CLI, especially when doing a massive export of APIs or Applications.
To avoid requesting the same entities over and over again, the CLI is using a cache, which persists the requested information to disk and it is reusing next time the CLI is called.
The APIM CLI distinguishes between export actions, like apim api get and import actions like apim api import.
Export actions use all available caches by default, import actions do not.
If you wish, you can disable the cache completely and ensure that the API Manager REST API is accessed for any necessary information. You can use the toggle: -ignoreCache to skip using the caches at all. For import actions it is not possible to disable individual caches.
Since version 1.7.0 it is possible to enable selected caches to the performance. This can be necessary, for example, if an API is subscribed by more than 2000 applications. When updating this API the APIM-CLI is forced to load all applications, if necessary incl. the configured application quota, to know the actual state of the API. This leads to more than 4000 API requests.
However, the cache is not activated by default for import actions to avoid that the APIM CLI loads an actual state that is not completely correct and then uses it in the further process. Use the option as with caution and monitor closely whether the behavior works as required.
Example: You enable the cache for application quotas. This cache contains which quotas are configured for which applications. The APIM CLI naturally uses this cache based on the Application-ID. If you now change the quota for an application, for example in the API-Manager UI, then any existing cache entry will of course remain unchanged. If you now import an API and it has to be created again (e.g. because the API specification has changed), then the APIM-CLI will load the old quota from the cache and will configure this application with the previously configured quota.
This is the reason why for import actions not all caches are activated, but only individual caches. Only enable caches that actually have an impact on performance and consider how dynamically the corresponding data changes in the API Manager. It makes especially much sense to enable caches for resources that are called in a loop. For example, the quotas for applications when the base is very many applications.
The following table represents all known caches and in which context they are used.
| Cache | Cached entity | REST-Endpoint | Comment |
|---|---|---|---|
| applicationAPIAccessCache | Apps subscribed to API | /applications/<appId>/apis |
Since API-Mgr version 7.7 not used anymore. |
| organizationAPIAccessCache | Orgs access to an API | /organizations/<orgId>/apis |
Which APIs the organization has granted access. |
| oauthClientProviderCache | List of OAuth-Profiles | /oauthclientprofiles |
In Policy-Studio configured OAuth-Client profiles |
| applicationsCache | Application details | /applications/<appId> |
The details of an application |
| applicationsSubscriptionCache | Subscribed apps for an API | /proxies/<apiId>/applications |
Applications subscribed a specific API |
| applicationsQuotaCache | Application-Quotas | /applications/<appId>/quota |
Configured quotas for an application |
| applicationsCredentialCache | Application-Credentials | /applications/<appId>/<type> |
Configured credentials for an application. Type might be oauth |
| organizationCache | Organization details | /organizations/<orgId> |
The details of an organization |
| userCache | User details | /users/<userId> |
The details of a user |
The CLI is delivered with a pre-configured set of entities and you can configure the caches time-to-live yourselves in the configuration file: lib/cacheConfig.xml.
Also, the configuration specifies where the cache should be persisted to disk. The default is ${java.io.tmpdir}/apim-cli-cache.
Please note that only one running apim-cli can initialize the cache at a time. If you run the APIM CLI as part of the CI/CD pipeline and jobs are running at the same time, you may see the following message:
"Error initiliazing cache - Perhaps another APIM-CLI is running that locks the cache. Retry again in 3 seconds. Attempts: 5/100
The CLI will check every 3 seconds for a maximum of 5 minutes to see if the cache can be exclusively initialized. These values are not configurable as of today.
If you would like to clear one, more or all caches you can provide the option: -clearCache to a command:
-clearCache ALL -- All caches are cleared and will be filled up with fresh data
-clearCache "*API*" -- All caches named with API. This is NOT case sensitive.
-clearCache "organizationCache,*API*" -- Clears a combination of combination of caches
The get a list of all available caches, just provide an invalid to the clearCache option (-clearCache XXXX)