Introduction to Agent Manifest Resolution Strategy

The manifest of an agent is its full and detailed list of capabilities. A manifest includes all extension components, including processors and controller services, and how they are configured.

When an agent first communicates to EFM through the C2 Protocol (heartbeats), the EFM server asks the agent to describe itself, and the agent supplies its manifest to the server.

An agent class is a group of agents. Currently, agent classes are defined by a unique property in each agent, and agents with matching class names are put in the same agent class in the EFM server.

An agent manifest is necessary in order to design a flow for an agent class, but because an agent class can contain many agents, the EFM server must decide which agent manifest to use for the entire agent class when loading the flow for that class in the flow designer. The logic that decides this is referred to as the Agent Manifest Resolution Strategy.

EFM supports multiple strategies to resolve agent manifest for a class at run time:
Strategy Description
First In This is the default manifest resolution strategy and binds an agent class to the first manifest reported for it.
Last In This strategy updates the associated manifest to the most recently reported by any agent associated with the specified class.
Static This strategy allows mapping of an agent class to a specific manifest ID.

The strategy is configurable at the application level and applies to all agent classes.

In, set the global agent manifest resolution strategy:
# This property does not exist, so you will have to add it anywhere in
# The default is 'First In'
efm.manifest.strategy=Last In

Static mappings act as overrides to the global manifest resolution strategy. If a static mapping of agent class to manifest ID is configured, then the application uses the static manifest strategy for that class and ignore the globally configured strategy. Classes without a static mapping falls back to the global stratey (i.e., First In or Last In).

Static mappings are created through the REST API (or Swagger UI) and stored in the EFM database.

Here is an example of setting a mapping for a class to manifest using curl:
# Get all agent manifests
curl -X GET "http://localhost:10080/efm/api/agent-manifests" -H "accept: application/json"

# Make a note of the manifest identifer to use in the mapping

# Create a mapping
curl -X POST "http://localhost:10080/efm/api/agent-class-manifest-config" -H "accept: application/json" --data { "agentClassName": "MyAgentClass", "agentManifestId": "27165b44-c54a-4504-8d47-7e3bec421a00" }

# Later, update to map the agent class to a new manifest
curl -X PUT "http://localhost:10080/efm/api/agent-class-manifest-config" -H "accept: application/json" --data { "agentClassName": "MyAgentClass", "agentManifestId": "90af998a-f7ff-4422-b8fb-2ed08f273959" }
See the Swagger UI Section Agent class manifest config for more details.