Basic Plug-In Concepts
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 sample 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.