This document describes the server-side beans used by the triggers on the Windchill RV&S Server.

Most operations performed by the server can be intercepted by a trigger. Installing a trigger is an application-specific task.

When a trigger runs, your javascript is run. The javascript can access objects called Beans, which are defined in these javadoc pages. The special variable bsf (which stands for bean scripting framework) is available to obtain handles to beans describing the current operation, for which this trigger is running. There will always be at least the environment bean siEnvironmentBean which describes the current operation. You can look it up via:

var environmentBean = bsf.lookupBean("siEnvironmentBean");

Operations will generally make available information specific to the operation in an Operation bean, or an Arguments bean. Each operation documents what beans are made available. For example, in the Workflows and Documents interface, if you create a new item, there will always be a imIssueDeltaBean. From that bean, you can find out exactly what operation the user was performing.

Caution

Triggers are code which runs protected inside the Windchill RV&S Server. This means not only that it can bypass most permissions, but it is subject to the limitations of all code: errors. Errors in scripting code can bring down the Windchill RV&S Server, or make it inoperative. Scripts hold resources which may be locked making them unavailable to other users so execution duration is important. They slow down all users of the server, so performance is important.

As code, they should be subject to all normal precautionary measures used for development. It is highly recommended that appropriate code review procedures be put in place; and that appropriate testing is done on staging or development servers.

A typical coding error, such as an infinite loop, has multiple problems:

• Resources held by the current transaction are locked while the loop runs.
• Triggers cannot be interrupted externally, so until it runs out of some resource, the end-user application will be hung.
• Typically such a loop would only terminate when the entire server runs out of memory. There is no resource limitation for a given trigger; use of a resource removes its use for other activities in the server. The server will slow down, and may appear to hang; other activies may receive out of memory errors; until this trigger actually hits the out of memory error itself.

Use extreme caution with any external resources. There are many ways that a script can rely on resources external to the current transaction. The most usual ways are:

• External processes through the ScriptProcessBuilderBean.
• Other commands, requiring another transaction, through the ScriptAPISessionBean.
• Direct access to the database, through the various JDBC calls.

In all such cases, you may come back into direct conflict with resources held by the original transaction. The trigger framework has no way to know what resources you are going to access through these external operations; if such operations come back into the Windchill RV&S Server and try to access resources in use by the current transaction, the result may well be a deadlock, which will render part or all of the Windchill RV&S Server inoperative.

Remember, triggers can cause problems for the potentially hundreds of users of the Windchill RV&S Server. Use caution!

Packages

Package	Description
mks.ci.server	Provides the beans needed to manipulate time entries.
mks.ci.server.engine	Provides the beans needed for Workflows and Documents.
mks.frame.triggers	This package is used to capture and interact with TriggerAPIException.
mks.frame.triggers.beans	Windchill RV&S Server base beans.
mks.si.brain.triggers.beans	Provides the beans needed for Configuration Management operations.