Agent migration checklist

Creating your own App Domain in RelativityOne will exhibit undesired behavior. Agents should be redesigned to avoid the use of App Domains.

Threads and thread pools may be created; we will provide guidance on how to leverage cloud-native scalability in future documentation

Currently, each agent is a long-lived thread of work. This design worked correctly on VMs that are similarly long-lived, but isn't appropriate for RelativityOne’s modernized architecture. In the new infrastructure, we want agents to only be running while there is work to do.

Your agent must return from the Execute method once all work or tasks are completed. Using a loop to process a queue of work is acceptable if the loop and the Execute method are exited once no more work remains.

Agents have historically had few limitations into what they could do, resulting in some agents self-hosting APIs in a separate process or thread in order to provide status on the agent’s work. Moving forward in RelativityOne, though, all access will be tightly controlled, meaning the agent and any threads or spawned processes will be inaccessible from the outside.

If you need an API, you should create a Kepler service and use the database or another shared data store to communicate information between your agent and your Kepler service.

Agents may be preempted and restarted at any time. In practice, this happens infrequently, but you will need to ensure that your agent is resilient to these operations and that these operations will not result in any data integrity issues. Your agent must be able to recover from preemption in part of its workflow and process the remaining work correctly.

Agents must also be architected such that they do not rely on long-lived information stored in-memory or in scratch disk. Agents should use cloud storage solutions for anything but small, short-lived scratch space, as heavy usage of scratch space may cause performance issues.

Historically, the Agent has provided metadata for every instance of a running Agent. Moving forward in RelativityOne, though, scalability will happen behind the scenes, and the Agent table will no longer be available. This means that agent IDs are no longer fixed as part of the context and that you cannot rely on any persistent metadata for a particular running instance of an agent.

If you require persistence between multiple stages of your business logic, you should create queues to manage the tasks.

Agent processes may be destroyed once the Execute method of an Agent returns. Therefore, any threads outliving Execute will likely be interrupted before they can finish. Spinning off additional threads will work correctly, but they must rejoin the main thread before Execute returns. If you use threads, you must carefully manage their lifecycle.

If you are using threads in order to speed up performance, this may later be addressed through the native scaling provided by RelativityOne’s modernized infrastructure, but we recommend first migrating before optimizing on its scaling capabilities.

Resource Servers are a Server-only concept that requires a Relativity Admin to manage where Agents run on in-tenant infrastructure. This concept will not exist in the modernized infrastructure.

Agents should be able to run outside of the concept of Resource Servers.

Resource Pools are a Server-only concept that requires a Relativity Admin to manage how and where Agents run on in-tenant infrastructure. This concept will not exist in the modernized RelativityOne infrastructure. Agents should be able to run outside of the concept of Resource Pools.

If you must support both in-tenant and RelOne version of Relativity, you may have branching logic based on whether or not a Resource Pool is returned.