Plug-ins in Automation Orchestrator rely on several key features.
Checkpointing
The checkpointing feature makes it possible for Automation Orchestrator to store the state of a running workflow and resume the workflow run from where it stopped. Checkpointing occurs every time a workflow completes a step and switches to the next element.
For example, you can run a workflow that calls another workflow, List path in guest, and then calls a set result scripting element. When the workflow run switches from the List path in guest workflow to the scripting element, the engine creates a checkpoint by storing all input and output parameters and variables.
The List path in guest workflow verifies if a folder exists in the file system of a specified virtual machine.
The sample workflow includes four input parameters. Two of them are strings, one is a custom SDK object that derives from the Automation Orchestrator vCenter plug-in, and the fourth one is a secure string.
In the current sample scenario, when the List path in guest workflow step is finished, the engine serializes the state of the workflow, which is called a token, and stores it in the Automation Orchestrator database. When the workflow run passes to the set result scripting element, the engine deserializes the token and tries to resume the parameters and attributes that are associated with the workflow.
Parameter types are serialized in a different way. Serializing string types consists of storing and reading the value of the string. However, VC:VirtualMachine is a scripting object that contains data and methods, so serializing and deserializing it requires the use of a plug-in.
Scripting objects, whose serialization and deserialization involve using a plug-in, are known as SDK objects or finders. Such finder objects are not serialized by value but rather by a reference.
The reference has two components – object type, for example, VC:VirtualMachine, and object ID. The engine delegates the deserialization of finder objects to a plug-in and calls that plug-in by the prefix in the parameter name. The engine strips the VC prefix from the VC:VirtualMachine parameter type and calls the finder and the associated ID for type VirtualMachine.
Finders
Custom SDK objects are defined by the underlying plug-ins. Finders create the custom SDK objects and pass them to the platform. The platform exposes an interface that includes three methods for retrieving these objects - findById, findAll, and findRelation.
In the previous checkpointing example, on every checkpoint, the engine invokes the findById method to restore the object. If you set a property to the virtual machine from the example, without storing this property on a third-party system, the next checkpoint retrieves a new object from the platform but does not save the assigned property. This means that the platform retains only a reference to the custom SDK object, without serializing the objects.
