Event Plans

Event Plans let you define business rules that can modify the behavior of LabVantage functionality. In general, Event Plans perform functions when "Events" occur according to this logical model:

When an [ Event ] occurs under these [ Event Conditions ] , do these [ Event Functions ].

Examples:

"When a Sample is Received and the Sample Type is "External", add a Test and Specification to the Sample, then notify the Lab Manager".

Event Plan

Event

Event Conditions

Event Functions

Sample Received

Sample is Received

Sample Type is External.

Add a Test to the Sample

Add a Specification to the Sample

Notify the Lab Manager

"When a Specification fails for a Sample that is associated with Product-A, add another Test to the Sample, then notify the Lab Manager".

Event Plan	Event	Event Conditions	Event Functions
Specification Failed	Specification fails	Sample is associated with Product-A	Add another Test to the Sample Notify the Lab Manager

You can define multiple Events in an Event Plan. For example, a single Event Plan can have 3 Events: creation of a Sample, creation of a Batch, and creation of a Project

You can also define multiple Event Plans to handle varying scenarios throughout a system operation. For example, during the Sample life cycle, you can create separate Event Plans to perform functions during Sample creation, receipt, completion, and approval. Multiple Event Plans can also perform different functions in response to the same Event. For example, when a Sample is received, one Event Plan can notify the customer, while another Event Plan can add more Tests.

Event Plans are created using intuitive graphical interfaces, thus eliminating the need for programmatic solutions and customized code. Creating Event Plans is a system administrator function that is done as part of overall system configuration. Once created, non-administrative users can see what the Event Plan did to the relevant SDI.

Event Types

Events are based on "Event Types". Event Types monitor LabVantage activity and tell the Event Manager what it needs to know for a given Event. For example, when you modify a Sample, a PostEdit Event object is generated. If the Event Plan defines a "SampleValueChanged" Event Type, the Event Plan is able to respond to the change in Sample value. Other examples:

•	A "SampleStatusChanged" Event Type lets a "Sample Received" Event Plan detect a change in Sample Status.
•	A "BatchStatusChanged" Event Type lets a "Batch Released" Event Plan detect the release of a Batch.
•	A "TestCreated" Event Type lets a "Tests Added" Event Plan detect the addition of Tests to a Sample.

Event Types are defined independently, i.e., they are standalone entities that can be reused for any Event Plan.

All Event Types are based on a core set of "primitive" Event Types. Primitives are the lowest-level Event Types, i.e., they are not based on other Event Types. Event Types can be created based on the primitives to provide more specialized functionality. For example:

•	The "SampleStatusChanged" Event Type is a specialized form of the primitive "PrimaryValueChanged".
•	The "BatchCreated" Event Type is a specialized form of the primitive "SDICreated".

The above examples are provided with LabVantage. You can create your own specialized Event Types from the primitives, such as:

•	A "ProtocolCreated" Event Type based on the primitive "SDICreated" (Protocol is an SDC).
•	A "StabilityStatusChanged" Event Type based on the primitive "PrimaryValueChanged" (Stability Status is a primary value).

Event Conditions

Event Conditions can be imposed on Events. For example, a "Sample Received" Event will add a Test only if the Sample Type is "External". In general, the Event "fires" when all Event Conditions have been met for an Event. There are two kinds of Event Conditions:

Setup Conditions

"Setup Conditions" are mandatory. For example, the "SDICreated" Event Type requires the "SDC" Setup Condition because it must know the SDC for the SDI you will be creating. Setup Conditions are often defined in a cascading style. For example, the "PrimaryValueChanged" Event Type requires Event Conditions that define an SDC, then a column, and finally a column value.

Filter Conditions

"Filter Conditions" are optional. For example, the "SampleStatusChanged" Event Type can have an Event Condition that reports the status change only for a specific Sample Type. You cannot define Filter Conditions until all Setup Conditions are defined.

Event Functions

When an Event fires, all Event Functions associated with the Event are executed. Event Functions essentially define what happens when an Event fires.

Event Functions are Action Blocks or Groovy script that you create using the Action Block Editor. To simplify processing logic or readability of Action Blocks, you can associate multiple Event Functions with an Event.

Event Properties

Adding Event Properties to the Event Function can make Event Plans more generic. For example, if you want a single Event Plan with a "Batch Released" Event to print a different COA report depending on the Batch Type, you could add an Event Property for the report. When the Event Plan is linked to the different Batches, the value of the Event Property (ReportId) can be populated and processed with the Event Function. Event Properties can be defined for the entire Event Plan, specific Events, and specific Functions.

Event Properties can be defined with default values and can be declared as "mandatory". When an Event Plan is explicitly added to a specific SDI (as described in Local Event Plans below), Event Properties that are not "readonly" or "hidden" can be modified in the Event Plan.

Global and Local Event Plans

Global Event Plans

Most Global Event Plans provided OOB are "SDC-based", meaning that you associate them with a specific SDC. SDC-based Global Event Plans are processed only for Events occurring on the specific SDC. For example, an SDC-based Global Event Plan for the Sample SDC will process only Events that occur on Samples (such as creation or modification of Samples). Only Events specific to a single SDC can be added to an SDC-based Global Event Plan. In a Global Event Plan that is SDC-based:

•	If there is only one Event in the Global Event Plan, the Event must act on a specific SDC. An example is an Event Plan that contains a SampleCreated Event. The Event adds a Batch each time a Sample is created. There is only one Event, and it acts on Samples.
•	If there are multiple Events in the Global Event Plan, all Events must act on the same SDC. An example is an Event Plan that contains two SampleCreated Events. One Event creates a Batch each time a Sample is added, the other Event creates a Workorder each time a Sample is created. Both Events act on Samples.

Global Event Plans can also be "non-SDC-based", meaning:

•	One or more Events do not act on any SDC. An example is an Event Plan that contains an Event authenticating a User's logon. This does not act on any SDC. It acts only on the system logon Event.
	and / or
•	All Events do not act on the same SDC. An example is an Event Plan that creates two Events: a SampleCreated Event and a BatchCreated Event. The SampleCreated Event creates a Batch each time a Sample is created, so this Event acts on Samples. The BatchCreated Event creates a Workorder each time a Batch is created, so this Event acts on Batches. Each Event acts on a different SDC.

In Global Event Plans, Events are checked every time they occur in the system. For example, if a Global Event Plan contains an Event that creates a Sample SDI, the Event fires each time a Sample is created (assuming all Event Conditions are met).

Global Event Plans are not recorded in the SDIEventPlan table (unless modifications are made to the properties of the plan). However, the SDIEventPlanLog will record them for auditing purposes.

Local Event Plans

Local Event Plans are always specific to an SDC because they define business rules for specific SDIs. Accordingly, all Events that you add to a Local Event Plan must act on the same SDC.

Local Event Plans are explicitly added to a specific SDI. In fact, Local Event Plans must be added to an SDI before they can take effect and act on the SDI.

You have three options for using Local Event Plans:

1.	You can add a Local Event Plan to an SDI in the Event Plan detail tab of an SDI Maintenance page. When you add an Event Plan here, you choose from a list that shows only the Local Event Plans available for that SDI. For example, on the Sample Maintenance page, the list of available Event Plans would show only Local Event Plans that act on Samples.
2.	If one of the Events in the Local Event Plan has to do with creating the Sample itself, adding the Event Plan to a Sample Maintenance page makes no sense (since the Sample has already been created). In this case, you can add the Local Event Plan in the Event Plan detail tab of a Sample Template Maintenance page. The Local Event Plan then acts on the Sample Template. For example, if the Local Event Plan contains an Event to create a Sample, the Event will fire when you create a Sample based on that Sample Template.
3.	Use the Copy-Down Policy to copy an Event Plan between SDCs that are linked by foreign key. For example, you can create a Product SDI called "Product-A". In the Product Maintenance page for "Product-A", add a Local Event Plan that fires an Event whenever you create a Sample that is associated with Product-A. You can setup the Copy-Down Policy to Copy the Product's Local Event Plan to a Sample. The Event is then fired whenever you create a Sample that is associated with Product-A. The Local Event Plan will be in effect from Sample creation onward.

The sdieventplanmaint Element configures the Event Plan detail tab of an SDI Maintenance page. This Element defines two modes of operation for Local Event Plans:

•	"Host" mode refers to adding a Local Event Plan directly to an SDI or SDI Template as described in options 1 and 2 above.
•	"Linked" mode refers to copying-down the Local Event Plan as described in option 3 above.

Local Event Plans are recorded in the SDIEventPlan and SDIEventPlanLog table.

Basic Examples: Creating Event Plans

Top

Before delving into details, here are some examples that demonstrate the basics of creating Event Plans.

Creating a Global Event Plan

In this example, we create a Global Event Plan to send the "admin" user a Bulletin whenever a Sample is logged in. Accordingly, this example assumes you are logged into LabVantage as the "admin" user.

Open the Event Plan List page from System Admin → Scheduling & Events → Event Plans:

Add an Event Plan by clicking "Add".

The Event Plan Maintenance page opens:

Enter or select these values, then click "Save":

Field	Value
Event Plan	CreateSampleBulletin
Description	Send Bulletin On Sample Creation
Scope	Global
SDC	Sample
Status	Active
Allow Modifications	Check this.

Add an Event by clicking "Add Event".

The Event form opens:

Enter these values, then click "Save":

Field	Value
Description	Create Sample
Event Type	Select "SampleCreated".

Add an Event Function by clicking "Add Function"

The Event Function form opens:

Enter "Notify Admin" for the "Description" of the Event Function.

Define Event Function processing (specify what the Function will do) by clicking "Edit" in the "Processing" section.

The Action Block Editor opens.

In the editor, add the SendBulletin Action to the Action Block. Define these SendBulletin properties:

Input Property Id	Value
To (User)	admin
Description	[s_sample_s_sampleid] Created

Save by clicking OK.

When specifying conditional expressions for Event Plans, you must preface the expression with "inputs". See Conditional Blocks.

The "Processing" section shows a read-only summary of the Action Block:

Save the Event Plan by clicking "Save"

Test the Event Plan by creating a Sample. Check the Bulletins. The Bulletin should have been sent when the Sample was created.

Once again, open the Event Plan List page from System Admin → Scheduling & Events → Event Plans. Select the Event Plan you just created, then click "Edit". The Event Plan Maintenance page opens:

Select the "Create Sample" Event, then add a Filter Condition to the Event by clicking "Add Filter Condition". Select or enter these values:

Filter Condition	Operator	Value
Sample Type	equals	Raw Material

This Event will fire only when the created Sample has a Sample Type equal to "Raw Material". Save the Event Plan.

Once again, create a Sample that has a Sample Type of "Raw Material". Note that another Bulletin is created for the new Sample.

Now, create a Sample that has a Sample Type of "Finished". Note that a Bulletin is not issued.

NOTE:

Note that rather than hardcoding the User who receives the Bulletin in the SendBulletin Action (as in step 5), you can ~~use~~ add a Function Property to the Event Function to define the user, then specify a variable in the SendBulletin Action.

In the Properties tab for the Event Function, specify these values, then Save the Event Plan:

Property	Editor Style	Prompt	Default Value	Mandatory
sendto	Users	Enter Bulletin Recipient	admin	Check this.

Click "Edit" in the "Processing" section of the "Function" tab.

Drag the sendto property from "Available Properties" to the user Input Property. This creates the [sendto] variable. Click OK.

Return to the Event Plan and Save it.

When you create another Sample of Sample Type "Raw Material", another bulletin will be created. The default value "admin" will be substituted for the [sendto] variable in the SendBulletin Action.

10.

Edit one of the Samples you created in the previous example. In the Sample Maintenance page, click the Event Plans tab in the SDI Maintenance detail. This tab shows a summary of the Global Event Plan you created.

Note that when you added the Event Function Property, you specified an Input Box with a prompt. The Event Plan detail shows this ("Enter Bulletin Recipient"). Since you chose the "Allow Modifications" option when you created the Event Plan, you can change the Bulletin recipient by clicking "Modify".

Creating a Local Event Plan

In this example, we create a Local Event Plan that will send a Bulletin to the "admin" User when a Data Set is added to a Sample. As stated in Global and Local Event Plans, Local Event Plans are explicitly added to a specific SDI, SDI Template, or by copying-down the Local Event Plan from a parent SDC linked by foreign key. All Local Event Plans added to an SDI must act on the same SDC.

Host Mode

As stated in Global and Local Event Plans, the sdieventplanmaint Element defines "Host" mode as adding a Local Event Plan directly to an SDI or SDI Template. Here is an example:

You create a Local Event Plan in the same manner as you create a Global Event Plan, except that you set the "Scope" to "Local":

For this Event Plan, enter or select these values, then click "Save":

Field	Value
Event Plan	LocalDataSetBulletin
Description	Send Bulletin On Data Set Creation
Scope	Local
SDC	Sample
Status	Active
Allow Modifications	Check this.

Once again, add an Event by clicking "Add Event".

The Event form opens:

Enter these values, then click "Save":

Field	Value
Description	CreateDataSet
Event Type	Select "DataSetCreated".
SDC Equals	Select "Sample".

Once again, sdd an Event Function by clicking "Add Function"

The Event Function form opens:

Enter "Notify Admin" for the "Description" of the Event Function. Click "Edit" in the "Processing" section.

The Action Block Editor opens.

As in the Global Event Plan example, drag the "sendto" property into the "To (User)" field and define these SendBulletin properties:

Input Property Id	Value
To (User)	[sendto]
Description	Data Set Created for [s_sample_s_sampleid]

Save by clicking OK.

Set the Properties as you did in the Global Event Plan:

Adding a Local Event Plan to an SDI involves performing the same steps as adding a Local Event Plan to an SDI Template. To avoid repetition, this example adds the Local Event Plan to an SDI.

Edit a Sample. In the Event Plan detail tab of the Sample Maintenance page, click "Add Event Plan". The Lookup shows only Active Local Event Plans that are associated with the same SDC (Sample):

Select the Local Event Plan. The new Local Event Plan is shown in the tab.

Click Save to save the changes.

This would be a good time to note that any Events that have already occurred will no longer fire.

Add a Data Set to the Sample. The new Bulletin should be sent.

Linked Mode

As stated in Global and Local Event Plans, the sdieventplanmaint Element defines "Linked" mode as using the Copy-Down Policy to copy an Event Plan between SDCs that are linked by foreign key. As provided OOB, the Sample SDC (the "linked SDC") has a foreign key column that links to the primary key in the Product SDC (the "primary SDC"). The Local Event Plan will then fire an Event whenever you create a Sample that is associated with the Product SDI. The Product-Sample relationship is preconfigured for you OOB. For an example configuration, see the sdieventplanmaint Element. Here is the result after configuration:

After the Copy-Down Policy and Product Maintenance page have been configured, editing the Product (primary SDI) shows the "Linked Event Plans" tab in the detail. In this tab are the Event Plans that will be copied-down to any Sample SDI (linked SDI) upon creation, provided that the Sample is associated with a Product SDI.

Event Plan List Page

Top

The Event Plan List page (accessed from the tramstop System Admin → Scheduling & Events → Event Plans) lets you add, edit, copy, view, and delete Event Plans.

These buttons operate on the selected Event Plans:

Button	Description
Add	Opens the Event Plan Maintenance page to allow creation of a new Event Plan.
Edit	Opens the Event Plan Maintenance page to allow editing of the selected Event Plan.
Copy	Creates a copy of the selected Event Plan and prompts for a new Event Plan identifier. The copy is created with the new identifier.
View	Opens the Event Plan Maintenance page to allow viewing the selected Event Plan in read-only mode.
Delete	Deletes the selected Event Plan.
Manage Categories	Lets you associate Categories with Event Plans.
Export	Exports the Event Plans using the Configuration Transfer Tools.
Show Records Hide Records	Lets you specify if both "Active" and "Inactive" Event Plan SDIs are shown (see Active and Inactive SDIs).

Event Plan Maintenance Page

Top

Event Plan Tree

The Event Plan Maintenance page is rendered in two frames. The left frame maintains the Event Plan tree, which shows the structure of the Event Plan:

The Event Plan tree is synchronized with the forms in the right frame. The tree structure is updated as you build the Event Plan. Selecting a tree item shows the corresponding details in the right frame. The tree in the left frame lets you determine the sequence in which Events and Event Functions will occur.

1.	Adds a new Event to the bottom of the tree. This duplicates the "Add Event" button on the Event Plan Maintenance page.
2.	Adds a new Event Function to the bottom of the tree. This duplicates the "Add Function" button on the Event Plan Maintenance page.
3.	Changes the sequence of Events and Event Functions by moving the selecting item up or down the tree. You cannot move an Event Plan.
4.	Displayed if another connection has this Event Plan locked.

Event Plan Tab

The Event Plan tab configures details at the highest level of the Event Plan.

Field	Description
Event Plan	Unique identifier of the Event Plan. This will be used to identify the Event Plan in the tree. If you edit an Event Plan, you cannot change its identifier.
Description	Description of the Event Plan. This will be displayed on the Event Plan List page.
Scope	Determines whether this is a Global Event Plan or Local Event Plan.
SDC	Determines the SDC on which the Event Plan will act. For example, if you choose "Sample", the Events in the Event Plan will act on Sample SDCs. You must specify an SDC for Local Event Plans and SDC-based Global Event Plans. You need not specify an SDC for non-SDC-based Global Event Plans. See Global and Local Event Plans for more information.
Status	Determines whether the Event Plan is Active or Inactive. This is a status mechanism that is specific to Event Plans.
Allow Modifications	Determines if the Event Plan can be modified in the Event Plan detail tab of an SDI Maintenance page.

If you attempt to leave the page without saving changes, you will receive a verification prompt. Saving an Event Plan:

•	Validates the Event Plan identifier, which must be specified and not equal to the default value.
•	Switches the Event Plan form to edit mode.

Event Plan Properties Tab

The Event Plan Properties tab configures properties at the highest level of the Event Plan. This same "Properties" tab is available for Event Plans, Events, and Event Functions.

Field/Option	Description
Property	Unique identifier of the property. This must be a valid identifier. For example, if you declare a property called sendto and you intend to pass the property into an Action, the Action must have a [sendto] variable declared as an input property.
Editor Style	Determines the Editor Style that will be used when the property is displayed in the Event Plan detail tab of an SDI Maintenance page.
Prompt	Determines the prompt that will be shown when the property is displayed in the Event Plan detail tab of an SDI Maintenance page. For example, if the property defines an email address, this could be "Enter email address".
Default Value	Value that will be displayed for the Prompt (above) by default.
Mandatory	When checked, the property must have a value. This can be the Default Value, or a value as mandatory, i.e., it must have a value Default Value or the value must be entered by a user in the Event Plan detail tab of an SDI Maintenance page.
ReadOnly	When checked, the property will not be editable in the Event Plan detail tab of an SDI Maintenance page.
Hidden	When checked, the property will be hidden in the Event Plan detail tab of an SDI Maintenance page.
X	Removes the property.

Button	Description
Add Property	Creates an empty property definition row.

Event Maintenance Page

Top

Event Tab

The Event tab configures details at the Event level of the Event Plan.

Field	Description
Description	Description of the Event. This will be used to identify the Event in the tree.
Event Type	Event Type on which the Event is based.
Conditions	If the Event Type requires Setup Conditions, they are displayed. You must specify Setup Conditions, as the Event Type requires them as inputs. After specifying Setup Conditions (if any), you can further narrow the Event Condition by clicking "Add Filter Condition". For cascading Conditions, you must enter values incrementally (such as first Condition, second Condition, third Condition). For both Global and Local Event Plans, Events with a Setup Condition that includes an SDC automatically default to the Event Plan SDC.

Button	Description
Add Filter Condition	Offers additional filtering of the Event. For example, if you are creating a Sample, the Filter Condition could specify that the BatchId begins with LVBAT. The Event would then apply only to Samples belonging to Batches that begin with the string LVBAT. Filter Condition operators and the value editor change according to the Filter Condition selected.
Add Function	Adds an Event Function to the Event, appends it to the Event Plan Tree, and opens the Event Function Maintenance page.
Delete Event	Deletes the Event from the Event Plan.

Event Properties Tab

This works in the same manner as the Properties tab for Event Plans. This lets you use the same mechanism to specify properties for the Event.

Event Options Tab

The Event Options tab configures details concerning Event firing and logging.

Option

Description

Event Firing

Determines if and when the Event fires when the Event Plan is executed:

Option	Description
Always	Fires the Event every time the Event Conditions are met (default).
Once	Fires the Event only the first time Event Conditions are met. The Event must not have previously fired. This promotes the Event Logging to "Summary" if it is not already set.
After First	Fires the Event only after the first time Event Conditions are met. The Event must have previously fired at least once. This promotes the Event Logging to "Summary" if it is not already set.
Never	Never fires the Event, even if Event Conditions are met.

In addition to these settings, also note that (in general) an Event will fire if:

•	There are no Event Conditions to evaluate.
•	At least one Event item in the Event object matches the Event Conditions of the Event in the Event Plan.

Event Logging

Determines the logging threshold when the Event fires:

Threshold	Description
None	No logging is performed when the Event fires. The Event Plan History will not be available if this option is selected.
Summary	Performs a summary detail of the Events as they fire. This is logged in the EventPlanHistory table and can be viewed in the Event Plan History.
Debug	In addition to Summary details, this generates a full debug log to the level of Function processing and Action Blocks. This is logged in the EventPlanHistory table and can be viewed in the Event Plan History. This is verbose, so it should not be used in a production environment.

Event Function Maintenance Page

Top

Event Function Tab

The Event Function tab configures details at the Event Function level of the Event Plan.

Field

Description

Description

Description of the Function. This will be used to identify the Function in the tree.

Processing

"Edit" opens the Action Block Editor, which lets you use Action Blocks and Groovy to define Function processing.

In the GAP, the "Available Properties" list shows properties from the current Function, the parent Event, and the Event Plan.

The Processing area of the form shows a non-editable rendering of the GAP.

Button	Description
Add Function	Adds a new Function to the Event Plan.

Event Function Properties Tab

This works in the same manner as the Properties tab for Event Plans. This lets you use the same mechanism to specify properties for the Event.

Event Function Options Tab

The Event Function Options tab configures details concerning Event processing.

Option

Description

Group
Processing

Determines how the Function is processed when the Event generates multiple Event items. For example, adding 3 Samples during Sample Login generates 3 Event items.

Option

Description

Grouped
(default)

Pushes Event items into Actions as a group defined by a semicolon-separated list. Example:

SendBulletin properties for 1 Sample:

Property		Value
sendto		admin
description		S1 created

SendBulletin properties for 3 Samples:

Property		Value
sendto		admin
description		S1;S2;S3 created

Grouped with
matching properties

Pushes Event items into Actions as a group defined by a semicolon-separated list, along with matching properties. Example:

SendBulletin properties for 1 Sample:

Property		Value
sendto		admin
description		S1 created

SendBulletin properties for 3 Samples:

Property		Value
sendto		admin;admin;admin
description		S1;S2;S3 created

Individually

Processes each Event item in its own Action call.

Missing
Mandatory
Properties

Determines what happens when a mandatory Property required for Function processing is not set or otherwise unresolved:

Option	Description
Generate Error (default)	Event Plan processing halts and an exception is sent back to the originator of the Event (such as an Action). In turn, this may fail the Action.
Ignore Function Processing	Current Function processing for the Event is ignored and no error is generated. Note that there may be multiple Function processing blocks for an Event.

Transaction
Scope

Determines how Functions are processed with regard to transactions:

Option	Description
Use Existing (default)	Function processing is performed in the same transaction as the originator of the Event. Any processing errors are thrown back to the originator of the Event and may halt processing.
Create New	Function processing is performed in a new transaction. Errors in the new transaction will not affect the Event originator's transaction. Data will be committed in the new transaction regardless of whether the Event originator's transaction succeeds or fails.
Suppress Error (Yes or No)	Yes suppresses/ignores errors generated in a "Create New" transaction. When this is set to No (default), errors generated in a "Create New" transaction will generate an error in the Event originator's transaction.

Asynchronous
Processing

Determines how Action Blocks defined for the Event Functions are processed. This option is available only for processing Action Blocks. Asynchronous processing of Groovy script is not supported.

Option	Description
Yes	Asynchronous processing: The Event Function is put into the ToDo List for processing through the ToDoList Queue.
No (default)	Synchronous processing: The Event Function is processed "on demand" when the Event occurs.

SDI Maintenance Event Plan Detail

Top

The Event Plan detail tab on SDI Maintenance pages shows SDC-based Global Event Plans that act on the current SDC (meaning the SDC supported by the SDI Maintenance page) and Local Event Plans that act on the current SDC.

For each Event Plan, the Event Plans detail tab shows:

Event Plan tree. Events that have fired are identified with a check

If Event Logging is enabled in the Event Options tab, Events that have an Event History recorded and have fired are highlighted with an alternate event icon. For Events that have not fired, hovering over the Event Plan icon shows a tooltip to that effect.

Properties defined for each level of the Event Plan (Event Plan Properties, Event Properties, and Event Function Properties).

If the "Allow Modifications" option is checked on the Event Plan Maintenance page, the "Modify" button lets you change the Property values.

In SDI Templates, property attributes are shown next to each property, and "Modify" lets you edit them. However, after you create the SDI from the Template, the property attributes are not visible.

Indicates whether this is a Global or Local Event Plan.

For Local Event Plans, "Remove" lets you remove the Local Event Plan from the SDI.

"Add Event Plan" opens a lookup that lists Active Local Event Plans for the current SDC. Choosing one of these Local Event Plans adds it to the SDI.

"View Event Plan History" shows a history depending on settings in the Event Options tab.

"Show full event plan" toggles between showing the full Event Plan and showing only Event Functions.

If you use the Copy-Down Policy to copy an Event Plan between SDCs that are linked by foreign key (See Linked Mode), the Linked Event Plans detail adds a dropdown list of SDCs. If the Event Plan is copied to the two SDCs and each has a foreign-key link to the primary SDC, the SDC list lets you choose which of the linked SDCs you want to view.

Event Types

Top

Event Type List Page

Open the Event Type List page from the tramstop System Admin → Scheduling & Events → Event Types:

Button	Description
Add Edit	Opens the Event Type Maintenance page to allow creation of new Event Types or editing of existing ones. Primitive Event Types cannot be edited and are always shown in read-only mode.
Copy	Creates a copy of the selected Event Type and prompts for a new Event Type identifier. Primitive Event Types cannot be copied.
View	Opens the Event Type Maintenance page in read-only mode.
Delete	Deletes the selected Event Type. Primitive Event Types cannot be deleted.
Manage Categories	Lets you associate Categories with Event Types.
Export	Exports the Event Types using the Configuration Transfer Tools.

Event Type Maintenance Page

The Event Type Maintenance Page lets you add and edit Event Types that are based on primitives.

Field

Description

Event Type

Identifier of the Event Type.

Description

Textual description of the Event Type that will appear on the Event Type List page.

Based on Event Type

Primitive Event Type on which the new Event Type is based.

Conditions

If you select a primitive Event Type that has Event Conditions, the Conditions are shown here. Note that:

•	If the Event Type has Setup Conditions, you must enter values for those first.
•	Filter Conditions are shown only after you have entered values for all Setup Conditions.
•	Filter Condition operators and the value editor change according to the Filter Condition selected.
•	If any Conditions are cascading, you must enter values incrementally, i.e., first Condition, second Condition, and so on.

Additional functionality:

•	Save validates the Event Type identifier, which must be specified and not equal to the default value. Saving a new Event Type switches the form to edit mode.
•	If you edit a primitive Event Type, you can change only the Description. If you edit a non-primitive Event Type, you can change the Description, Based on Event Type, and Conditions.
•	If you attempt to leave the page without saving changes, you will receive a verification prompt.

These are the primitive Event Types:

Event Type	Occurs:
DataSetCreated	When a new Data Set is added to an SDI.
DataSetValueChanged	When a column value in the SDIData record is changed.
NoteCreated	When a new Note is added to an SDI.
SDICreated	When a new SDI is created.
SDIDeleted	When an existing SDI is deleted.
SDIPrimaryValueChanged	When a column value in the SDI primary record is changed.
SendBulletin	When a User is sent a Bulletin.
SetBulletinStatus	When the status of a Bulletin changes.
SpecItemCheck	After the check source Event (defined by a method in the BaseSDCRules class in the Java Public API) has occurred
SpecRuleCheck	After the check source Event (defined by a method in the BaseSDCRules class in the Java Public API) has occurred.
Task Completed	When a Task completes.
TestCreated	When a new Workitem (Test Method) is added to an SDI.
TestValueChanged	When a column value in the SDIWorkitem (Test) record is changed.
UserAuthentication	When a user logs in.
Workflow Completed	When an End Task in a Workflow completes.

These Event Types are based on the primitives:

Event Type	Primitive	Occurs:	Setup Conditions
BatchCreated	SDICreated	When a new Batch is created.	SDC equals Batch.
BatchStatusChanged	SDIPrimaryValueChanged	After a Batch status transitions from one value to another.	SDC equals Batch. Column equals s_batch_batchstatus. Value goes to [ new value ] from [ old value ]. See Note 1 below.
BatchValueChanged	SDIPrimaryValueChanged	When a column value in the Batch primary record is changed.	SDC equals Batch. Column equals [ SDC Column ]. Value goes to [ new value ] from [ old value ]. See Note 1 below.
SampleCreated	SDICreated	When a new Sample is created.	SDC equals Sample.
SampleSpecFailDataRelease	SpecItemCheck	When a Sample Specification fails under the conditions described in Note 2 below.	SDC equals Sample. Check Source equals PostDataRelease. Spec Condition equals Fail. Spec Type equals A.
SampleSpecRuleFailDataRelease	SpecRuleCheck	When a Sample Specification Rule fails after data Release.	SDC equals Sample. Check Source equals PostDataRelease. Source Options equals A. Spec Condition equals Fail. Spec Type equals A.
SampleStatusChanged	SDIPrimaryValueChanged	After a Sample status transitions from one value to another.	SDC equals Sample. Column equals s_sample_samplestatus. Value goes to [ new value ] from [ old value ]. See Note 1 below.
SampleValueChanged	SDIPrimaryValueChanged	When a column value in the Sample primary record is changed.	SDC equals Sample. Column equals [ SDC column ]. Value goes to [ new value ] from [ old value ]. See Note 1 below.
User Disabled	SDIPrimaryValueChanged	When the status of a User transitions to Disabled.	SDC equals User. Column equals sysuser_disabledflag. Value goes to Y from [ old value ].
User Enabled	SDIPrimaryValueChanged	When the status of a User transitions from Disabled to Enabled.	SDC equals User. Column equals sysuser_disabledflag. Value goes to N from Y.
WorksheetStatusChanged	SDIPrimaryValueChanged	When the status of an ELN/LES Worksheet changes.	SDC equals LV_Worksheet. Column equals worksheet_worksheetstatus. Value goes to [ new value ] from [ old value ]. See Note 1 below.

Note 1:

In addition to entering specific values for [ new value ] and [ old value ], you can specify (any) or * to refer to any value rather than a specific value, and (blank) to refer to the nonexistence of a value. The asterisk can also be used as a general wildcard, e.g., abc* will match any value beginning with abc. In any case, you cannot leave these fields blank.

Note 2:

The "SampleSpecFailDataRelease" Event Type does not fire if you "Save" a Parameter value that violates a Specification, then "Release" the data after the fact as a separate operation. For example:

1.	Create a Global Event Plan for a Sample that uses the SampleSpecFailDataRelease Event Type to send a Bulletin to a User when he enters a data value that violates a Specification.
2.	Perform Data Entry on the Sample, but enter a value that violates the Specification. Save the data.
3.	Re-open Data Entry, then Release the data you just entered. Save again.
4.	No Bulletin will be created.
5.	Re-open Data Entry and enter another value (for the same Data Item) that violates the Specification. This time, click "Save and Release".
6.	This time, a Bulletin will be generated.