Agent implementation approaches

Implement an agent for each runtime by using Java™ based SDK (Software Development Kit) or REST APIs offered by federated API management.

Java™ based implementation

The developer can use the Java™ based Agent SDK (Software Development Kit) to develop an agent for each runtime in your API management environment. The Agent SDK includes libraries, Java™ documentation, and implementation samples to assist developers in creating an agent.

Developer can implement the Agent SDK by using either of the following approaches that are provided in the SDK.

  • Manual
  • Managed

The main difference between these two approaches lies in the level of abstraction, implementation control, and ease of use when implementing the Agent SDK.

Comparison between manual and managed approach

The following table lists the differences between the managed and manual approaches.

Key points Manual approach Managed approach
When to use which approach? Use this approach in the following scenarios.
  • The runtime does not provide REST APIs for data retrieval.
  • Needs more precise control over the interaction with the runtime environment.
  • The developer prefers to manage the connection and authentication of the runtime manually.
Prerequisites. The runtime must expose the necessary REST APIs to retrieve APIs, health check status, and metrics.
Note: When the runtime does not expose any REST APIs, then the developer must opt for manual approach.
Use this approach in the following scenarios.
  • REST APIs are available to facilitate implementation.
  • The developer does not prefer to manage the connection and authentication of the runtime manually.
Connection establishment The developer must explicitly implement code to establish a connection to the runtime. The developer must configure the REST API or URL to establish the connection to the runtime and the authentication information. The SDK takes care of managing the connection and authentication.
Asset retrieval The developer must also implement code to retrieve the assets from the runtime. The Agent SDK automatically handles the retrieval of assets from the REST APIs and stores them in an in-memory cache of the agent for asset synchronization.
Asset synchronization The developer must implement code to identify the updates that are made to the assets and synchronize those assets with federated API management. The developer does not need to implement code to identify the updates that are made to the assets, as this process is managed by the SDK automatically. Instead, the developer's responsibility lies to implement parsing logic to convert the runtime's asset into the asset model compatible with .
Benefits The approach offers more flexibility and control to the developer but requires more coding effort and customization. The approach abstracts away many of the lower-level details of connection management and data retrieval, providing a more streamlined experience for the developer.
Interface utilization For this approach, developer must use the AgentSDKContextManual interface.

For a sample, download the federated API management Agent SDK compressed file from IBM® Integration Community and open the agent-sdk-manual-implementation sample at samples\implementation.

 For this approach, developer must use the AgentSDKContextManaged interface.

For a sample, download the Agent SDK compressed file from IBM Integration Community and open the agent-sdk-managed-implementation sample at samples\implementation.

REST API-based implementation

If the developer does not want to use the Agent SDK, they can use the REST APIs offered by federated API management to implement an agent for each runtime in the API management environment by using their preferred programming language.

The following workflow outlines the sequence in which the REST APIs must be used to register the runtime for the first time.

Note:
  • Prerequisite - Register runtime type. Implement the register runtime type only if the runtime type is not previously registered in federated API management. Registering a runtime type is a one-time activity where a new runtime type intended for monitoring through federated API management is registered. By default, the runtime types - IBM webMethods API Gateway and IBM webMethods Developer Portal are already registered within federated API management. Example, Assume that you want to implement an agent for Amazon API Gateway. Check against federated API management instance that you want to use to make sure that there are no runtime types that are created already for Microgateway by using the GET/api/assetcatalog/v1/runtimes/types REST API. If it is not already available, then create one using the POST/api/assetcatalog/v1/runtimes/types REST API.
  • Runtime registration and re-registration. When the agent implementation is registering the runtime for the first time, the expected response status code of the POST /api/assetcatalog/v1/runtimes REST API must be 201. When re-registering the runtime, the expected response status code of the POST /api/assetcatalog/v1/runtimes REST API must be 200. The response includes additional information such as the last synchronized time of the APIs, heartbeats, and metrics. This information aids developers in identifying the duration for which the agent was down.
  • Heartbeats. The heartbeats of the runtime are synchronized with federated API management by using the POST /api/engine/v2/runtimes/heartbeats REST API. If the agent goes down and gets back online, the heartbeats of the runtime for the downtime duration can be sent in bulk to federated API management by using the POST /api/engine/v2/runtimes/heartbeats/bulk REST API.
  • For publishing and synchronizing multiple APIs in a single request, developers can use Bulk APIs too. For details, see Bulk API Management.