Overview	Top

High-Level Description

An Action is a set of programmatic instructions that performs a specific operation. LabVantage provides ready-to-use Actions (called "System Actions"), or you can create your own (which are called "User Actions").

As an example, consider the System Action called "AddSDI". This is probably the most frequently used System Action, as it adds SDIs to the database. To provide an Action with arguments, you specify "Input Properties". In the example below, we want to add two Sample SDIs and specify their identifiers.

			Action		Database
Input Properties			AddSDI		SDC table		Sys table		s_ Sample table
sdcid	Sample				SDCId	Sample	TableId	s_Sample	KeyId1	Sample-001;Sample-002
keyid1	Sample-001;Sample-002
Output Properties
newkeyid1	Sample-001;Sample-002

The AddSDI Action then cuts records in the Sample table, creating two Samples and maintaining the Sample SDI data structure in the database. AddSDI is an Action that returns values of "Output Properties". The Output Property newkeyid1 shows the identifiers of the added SDIs.

AddSDI has other properties. The example below shows Input Properties required to add two Samples with automatically-generated keys.

			Action		Database
Input Properties			AddSDI		SDC table		Sys table		s_Sample table
sdcid	Sample				SDCId	Sample	TableId	s_Sample	KeyId1	S-0418-01;S-0418-02
overrideautokey	n
copies	2
Output Properties
newkeyid1	S-0418-01;S-0418-02

The next example shows Input Properties required to generate two Samples from an SDI Template, thus creating two identical Samples, each with an automatically-generated key.

			Action		Database
Input Properties			AddSDI		SDC table		Sys table		s_Sample table
sdcid	Sample				SDCId	Sample	TableId	s_Sample	KeyId1	S-0418-01;S-0418-02
templateid	Template-A
overrideautokey	n
copies	2
Output Properties
newkeyid1	S-0418-01;S-0418-02

Each Action performs its function from a Java class. Fields (variables) in the class define and hold values of the Input and Output Properties. In simplest terms, an Action performs the following functions when it executes:

Actions can automate operations internal or external to LabVantage in any of the following contexts:

The ready-to-use System Actions are described in the Javadoc for System Action Public Interfaces.

User Actions must be written in Java, compiled, and packaged into your classpath on your application server.

Action Processing	Top

The LabVantage Automation Engine is involved with multiple background activities. Navigate to System Admin > Monitoring > System Monitor and expand the Automation Stats detail for a list of automation tasks being performed by that server, and by other servers in a clustered environment.

In a clustered environment, it is possible to restrict which server(s) perform automation tasks. Any server that participates in a LabVantage cluster will have a labvantageconfig.props XML file. This contains a property called AUTOMATION_SERVER. If this value is set to "false", the server will not participate in ToDoList processing or SDMS file processing. This means that the server can be reserved for processing web requests only. LabVantage will ensure there is always at least one automation server in the cluster. LabVantage will automatically and temporarily turn on the automation engine for servers where this is turned off if no other automation servers are running. This prefents a single point of failure in a LV cluster. A temporary automation server will stop being an automation server when other automation servers are back online.

If there are multiple automation servers in a cluster, one of them will be automatically nominated by LV as the "primary automation server". The primary automation server is elected by LabVantage during startup and may adjust as servers are added or removed from the cluster. Here is a list of activities performed by only the primary automation server:

1. Polling Tasks and adding them to the todolist
2. Polling ScheduleTasks (defined in SchedulePlans) and adding those to the todolist
3. Polling for SDMS data-capture-folders (.zip files) and adding import commands to the todolist
4. Timout connections and rsets
5. Performing database housekeeping (like deleting old bulletins)
6. Performing Lucene (search) indexing

The default ToDoList Poll interval is one second. This means that after an action has been placed on the todolist, it could take up to one second for a quiet automation engine to "wake up"; todolist entries will then be processed continuously until the todolist queue is once again empty.

Consider an example of two automation servers in a cluster. Each automation server defaults to 10 threads per automation engine. Which of our two servers will pick up this item could depend on the backlog. If 19 other items are already processing, the one idle thread (10 threads per server) will pick it up.

In an extremely busy system with a large backlog of ToDoList processing, a Buffer Time helps reduce the number of database reads from the todolist table. The default buffer time is 100ms. Setting this to a lower number may cause the Poller to allocate threads more frequently but cause the database to process more queries for new items.

In a multi-threaded or a clustered environment, entries on the ToDoList are not guaranteed to be picked up or completed in the order that they are added to the list. This could have some undesired consequences if Action2 relies on Action1 to finish first. To address this, you can use ToDoList Groups. The AddToDoList action has a groupname property. When supplied a value, all entries on the list can still be processed by individual threads. However, each thread is instructed to wait until the prior item in the group has completed processing.

Related Topics	Top