| Agile Product Lifecycle Management Administrator Guide Release 9.3.6 E71145-01 |
|
 Previous |
 Next |
| Agile Product Lifecycle Management Administrator Guide Release 9.3.6 E71145-01 |
|
Previous |
Next |
Event Management enables Agile PLM customers to automate their business processes across the PLM suite of solutions. The Event Management framework provides the administrator with a flexible alternative to Process Extensions for extending Agile PLM.
This chapter describes the components of Event Subscriptions and how the administrator creates those components in the Event Management nodes. Two other chapters in this manual pertain to this robust new feature of Agile PLM:
"Event-based Notifications" are created in the Notifications node.
"Scripting and Sample Event Subscriptions" gives a brief introduction to the scripting capability and sample configured Event Subscriptions.
Also, Agile PLM SDK Developer's Guide provides technical documentation of the Event framework for the Agile administrator or assisting programmer. Event Management leverages the Agile SDK just as Process Extensions do, only with much greater flexibility and specificity to PLM business objects and user actions.
The preliminary configuration required to set up event management is described here.
Ensure that your own User Profile has proper access to all six Event Management nodes through the AppliedTo property in the Administrator privilege mask.
Once you can access the Event Management node folder, still, the Event functions are initially disabled on all 9.3 PLM installations. When the administrator has configured Event Subscriptions and wants to commence their use by the system, Event triggers are enabled by the Enable Triggering Events button on the Admin toolbar. Only users with the Administrator privilege mask with the AppliedTo of Global Event Triggers Control can see and use this button.
|
Important: It is highly recommended that Event Subscriptions and their various masks are first created and tested on a PLM Test system before introducing them into the Production system. With Agile Configuration Propagation (ACP, see separate manual), fully tested Event Management configurations can easily be transferred from Test to Production systems. |
There is extensive control of the layers of Event Management; for more information, see "Control of Event Components."
Once initially enabled, Event Management will start automatically when the Agile Application Server is restarted; this step does not need to occur again.
Several systemwide Preferences must be set to govern some aspects of Event Management: Agile Script Log Level, Event Maximum Nested Levels Allowed, and Event Monitor Log Level. These are detailed in "Default Systemwide Preferences."
These are the nodes in the Event Management node folder and a brief description of the purpose of each node.
Create and manage Handler masks based on "Java PX" and "Script PX" handler types.
Notifications, the third handler type, are created and managed in Notifications node.
Review the status of transactions and results, such as messages or errors, from Handler transactions that have been invoked – see "Event Handler Monitor."
With the incorporation of the Events framework, PLM has two types of Notifications and multiple types of Process Extensions. Note the distinctions and naming conventions below.
Default Notifications are the "ready-to-use" notification templates in the Notifications node. These Notifications are still useful, particularly before you have deployed Event-based notifications.
Event-based Notifications are created in the Notifications node. A notification created in PLM 9.3.x has much more flexibility than a default notification. Most Event Subscriptions that are dedicated to notifications have a configured Notification mask for the Handler. See "Handler Types."
Custom process extensions (Custom PX) is a general name for PXs created in Data Settings > Process Extensions node. These PXs have limited initiation capability, for instance, they can be added to objects' Actions menu. It may be preferable to maintain your Custom process extensions until you have developed and tested Java PX Event Subscriptions (outside your Production system).
Event-based process extensions (Event PX) are created in the Event Management nodes. "Event PX" is a general term to contrast with "Custom PX", but we will be referring more to the specific kinds of Event-based PXs, namely, Java PXs and Script PXs.
An Event Subscription is a single instance of an "administrator-configured event".
The Event Subscription provides complete instructions for an automation, including what kind of object is to be acted on, what actions will be taken, and what result or outcome will be accomplished by the system.
An Event Subscription, configured and ready to be invoked, consists of...
an Event mask – specifies the conditions under which an automation will be invoked, includes an Event Type, an Object Type (often but not always), and additional attributes;
and a Handler mask or a Notification mask – describes the intended automated result, a Handler mask is a configured Java PX or a configured Script PX; a Notification mask is a configured Notification;
and a Subscriber mask – binds a Handler to an Event, a Subscriber names Event and Handler/Notification masks to work in tandem with additional attributes that refine the Event Subscription's behavior;
... and when the Event Subscription is invoked, the configured result is completed by the system.
As end-users perform normal actions in PLM, the default Event Types may be triggered dozens of times a day. However, nothing happens unless one (or more) Event Subscription gives the information to the system about what to do when an event type is triggered.
|
Note: Be careful how you think of "Events" and "triggered Events". It is the Event Types that are triggered by user actions; but nothing happens unless a proper combination of the three masks are in place. |
You cannot create "duplicate" Event masks, that is, there can be only one Event mask that names an Event Type-Object Type combination. However, Event and Handler masks are reusable, that is, they can be named by any number of Subscriber masks to create highly specific Event Subscriptions.
For every Event Subscription that you configure, you must be clear about the object type you want to affect—whether it is a subclass, or a class (and all of its subclasses), or a base class (and all of its "descendant" classes and subclasses).
|
Note: There are several Event Types that are not specific to object types; this is the first category in the table in "Event Types." |
So a "Create Object" Event mask for Items base class is triggered for the Parts and Documents classes and, in turn, their children subclasses. A "Create Object" Event mask for Parts class trigger for all subclasses of the Parts class. A "Create Object" Event mask for Part subclass triggers for that subclass only, not for other subclasses in the Parts class.
When you create the masks, an automatic naming capability provides a name that you can accept or modify; or, you can create your own name. For example, you may prefix mask names with a business process or subclass.
|
Note: System-provided names follow internal conventions, but the provided name may not be unique and you may need to modify the provided name. |
A naming system will be a benefit when you have stored many masks in your Event-node libraries. In any case, choose names that help you see at a glance what their use is.
Here is an example of names for three masks in a possible Event Subscription.
Let's say the administrator builds on the "Create Object" event type to specify "objects from the Capacitor subclass". The name of the Event mask is:
[Create Object Capacitor]
Every Event mask names an Event Type, in this case the Create Object event type. This event type takes an object type (most of them do), so this Event mask specifies Capacitor, a subclass of the Parts class.
Now a Handler mask is created:
[New Part on ECO]
This handler's name gives the idea that a change order will be created with the new part associated with it. Also, you can see that this Handler mask will work with any Event mask that names a subclass of the Parts class, or the Parts class itself.
Finally, a Subscriber mask that names the Event mask and Handler mask is:
[Create Object Capacitor New Part on ECO]
When the system recognizes that a Capacitor was just created, and this Event Subscription is invoked, the Subscriber provides the specific instructions and the system runs the Handler that produces the desired outcome:
"Since a Capacitor was just created, now (automatically) create a new Change Order and add that new object on the ECO."
With this automation, the user does not have to create an ECO and associate it with the part; the user simply creates a part and soon after sees the system-generated ECO containing the part.
The names of the "Default Event Types" gives an idea of the range of automated Event Subscriptions in PLM that the administrator can create in the Event Management framework.
This schematic depicts the connections between individual objects that are created in Event Management nodes.
For example, when you open an event type from the Event Types node, it has a Where Used tab that lists all event masks that use that event type. In the other direction, when you open an event mask from Events node, the field "Event Type" is a live link to the named event type object.
The right-most element "Object Screen" represents any object type—each row in Classes node—and each and every object type has an Event Subscribers tab that lists all event subscribers that are associated to this object type (because a given subscriber names an event mask that names the object type).
|
Note: For Event-based Notifications, a Notification mask is the Handler. The distinction between Handler mask and Notification mask is simply because they are created in different nodes in Administrator, namely, Events Handlers node and Notifications node. |
The Event Subscribers tab has been added to every base class, class, and subclass (default and administrator-created). When you create an Event Subscription that points to an object type, you can open the object type in Classes and see all its associated Subscribers under this tab.
This is also the best way to see which Subscribers are active or inactive, by using a drop-down filter with these values:
All – displays both Active and Inactive subscribers, per the other criteria in the filtering process.
Active – a subscriber can be Active if each of the three masks are enabled: the Subscriber mask itself is enabled, the Event mask it names is enabled, and the Handler mask or Notification mask it names is enabled.
In addition, the entire Event Management framework must be enabled (through Admin toolbar > Enable Triggering Events button), and also the associated Event Type, Handler Type (all three), or Notifications (through Server Settings > Database > Notification Enabled).
Inactive – a Subscriber mask may be enabled, but if either the Event mask or Handler mask that it names is disabled (or if base Event Type, Handler Type, or Event Management itself are disabled), the subscriber is considered Inactive; any disabled Subscriber is also Inactive.
The Inactive Reason field is automatically populated in every subscriber displayed by filtering for Inactive. The Inactive Reason field displays these various reasons:
[Blank, no value] if the Subscriber is active;
"Event triggering disabled" if the global Event Management control is disabled;
"Event is disabled" if the Event mask is disabled;
"Event type disabled" if the Event Type is disabled;
"Handler type disabled" if the Handler Type (Java PX, Script PX, or Notification) is disabled;
"Event handler disabled" if the Notification itself is disabled, or
"Notifications are disabled" if global notifications are disabled.
Remember for any filtering of subscribers on a given object type, the hierarchy of base class, class, and subclass is in effect, as follows:
If you open a base class, you see those handlers available to that base class (through subscribers).
If you open a class, you see those handlers available to that class and its parent base class (through subscribers).
If you open a subclass, you see those handlers available to that subclass, its parent class, and its parent base class (through subscribers).
The Event Handler Types node contains a library of the available Handler Types. Currently there are three handler types, which are described below; first, this table clarifies some terms used with regard to Event Handler Types.
Table 29-1 Event Handler Types
| Category of Handler Type | Handler Type | Kind of Mask | Where created & managed | Comment |
|---|---|---|---|---|
|
PX-based Handler Types |
Java PX Script PX |
Handler mask |
Event Handlers node |
When you create a Handler mask, only Java PX and Script PX are in drop-down menu for selection. |
|
Notification-based Handler Type |
Notification |
Notification mask |
Notifications node |
"Create" in Notifications node creates a Notification mask. These can be associated with Event and Subscriber masks, or they can be triggered by Java PX or Script PX handler. |
The Handler Type dictates the form that the Handler's instructions will take. The Handler mask or Notification mask identify what to invoke when the related Event mask has been invoked.
There are two types of process extension-based handler types: Java Process Extensions and Script process Extensions.
A Java Process Extension (Java PX or jPX) is a Java class deployed on the Agile Application Server. The Java PX handler type permits you to trigger compiled Java code. Compared with Custom PXs (created and stored at Process Extensions node), the Events framework gives Java PXs much greater potential for your targeted automations.
Java PXs are stored on the Agile Application Server directory structure. Refer to Agile PLM SDK Developer's Guide for information about writing Java PX code and deploying PXs.
The Script PX handler type (Script PX or sPX)—a new form of process extension in Agile PLM—permits you to store code directly in the system database. The script is always visible and can be edited right in the Handler mask.
|
Note: Groovy is the only scripting language that is supported in Agile PLM 9.3.x. |
Scripting is introduced to the administrator in "Overview to Scripting in Agile PLM", and there is substantial information for the developer about scripting in Agile PLM SDK Developer's Guide.
Use the Notifications node to create Notification masks, and to manage the Default notifications.
Admin-created Notification masks work in conjunction with the Event framework.
In an Event Subscription whose outcome is a notification, the Subscriber mask names the Notification mask, rather than a Handler mask (example: "Notify when Affected Items Table is Updated"). Notification masks also can be triggered by Java PX or Script PX handler (example: "Notify Create User when Item is Incorporated").
Details about Handler masks, their attributes, and related business rules are taken up in "Working in Event Handlers Node". Notification masks are detailed in "Notifications."
When you double-click to open a handler type, the General Information tab contains just a few attributes: Name, API Name, and Description are all uneditable.
All handler types are enabled by default, and they can be enabled and disabled – see "When a Handler Type is Disabled."
On the Where Used tab of the handler types:
Java PX – lists all Handler masks that are based on the Java PX handler type.
Script PX – lists all Handler masks that are based on the Script PX handler type.
Notifications – lists all Event-based Notification masks.
The rows in these Where Used tables are active links so you can "click" directly to a specific Handler mask.
The Event Types node lists all of the supported Event Types. The event types are enabled out of the box, and you can disable and re-enable them at any time. See "Control of Event Components."
Use the list in Event Types node to see what user actions can be the starting point for automated Event Subscriptions. Because the event types name what the system is "triggering," it may also help to think of the event types as the points in PLM where Handler masks are invoked.
The Name of each event type begins with the action (or verb, for example, Approve) and a target (or noun, for example, Workflow, so, Approve for Workflow). If you click the Description column header, the event types sort by the targets, alphabetically (so, Workflow, Approve for), ascending or descending.
The Where Used tab lists all Event masks that are associated with that event type. These rows are active links so you can go directly to a specific Event mask.
The following table lists all of the event types that are available to create Event masks. The default event types can be categorized in five groups to help understand their scope:
Global event types – do not apply directly to PLM object types
Generic Object-based event types – apply to all PLM object types
Specific Object-based event types – apply to specific PLM object types
Workflow-based event types – apply to all Workflow objects
Variant Management specific event types – apply to Items with part subtype Model
The purpose of each event type is described by what user action will trigger the event type (right column) and by the PLM base class it applies to (center column).
Information about selected event types beyond the scope of this table is presented in "More about Selected Event Types."
Global Event Types
Table 29-2 Global Event Types
| Event Type | Applies to these PLM base classes | Event type is triggered by this end-user Action (or system action or through SDK) |
|---|---|---|
|
Scheduled Event |
(Global event types do not apply directly to PLM base classes.) |
There is a Schedule Event Task that controls the execution of this event type. See "Task Configuration," Schedule Event Task. |
|
Export Object |
(Global event types do not apply directly to PLM base classes.) |
Action > Export, or whenever the Export utility is opened. |
|
Extend Tools Menu |
(Global event types do not apply directly to PLM base classes.) |
Event triggered from the Tools Menu. |
|
Transfer Authority |
(Global event types do not apply directly to PLM base classes.) |
Transfer Authority is added, removed, or changed. |
Generic Object-based Event Types
Table 29-3 Generic Object-based Event Types
| Event Type | Applies to these PLM base classes | Event type is triggered by this end-user Action (or system action or through SDK) |
|---|---|---|
|
Extend Actions Menu |
All base classes |
Creates link or action, or something that can be activated from a business object's Actions menu. |
|
Extend Tools Menu |
All base classes |
Creates link or action, or something that can be activated from the Tools menu. |
|
Create Object |
All base classes |
An object is created; this does not include objects that are created by the "Save As" method of object creation (see Save As Object). |
|
Delete Object |
All base classes |
An object is Deleted. |
|
Save As Object |
All base classes |
An object is created by Actions > Save As, which creates a copy of the current object. |
|
Check In Files |
All base classes except Reports; also excludes Automated Transfer Orders class |
A File Folder is checked in, either from direct action on the file folder or through an object's Attachments tab. The Replace File action is part of checkin and will not generate an Update Table event on the file folder. |
|
Check Out Files |
All base classes except Reports; also excludes Automated Transfer Orders class |
A File Folder is checked out, either from direct action on the file folder or through an object's Attachments tab. From Web Client, the Checkout action creates a separate Get File action and event. |
|
Cancel Check Out Files |
All base classes except Reports; also excludes Automated Transfer Orders class |
A File Folder checkout is canceled, either from direct action on the file folder or through an object's Attachments tab. |
|
Get File |
All base classes except Reports; also excludes Automated Transfer Orders class |
A user requests to Get a file; this can occur through use of the Get button or if selecting the file name causes a Get action. |
|
Update Relationship |
All base classes |
A user adds, removes, or directly edits a Relationship on an object's Relationships tab; editing includes either updating the Relationship Rule or editing a field on the row. |
|
Update Table |
All base classes; however, certain tables are not supported. |
A user modifies a table on a business object, for example, on Items' BOM tab, or Changes' Affected Items tab. See details and exceptions in "Update Table." |
|
Update Title Block |
All base classes |
A user directly edits any fields on an object's Page1, Page2, or Page3. |
Specific Object-based Event Types
Table 29-4 Specific Object-based Event Types
| Event Type | Applies to these PLM base classes | Event type is triggered by this end-user Action (or system action or through SDK) |
|---|---|---|
|
Change Status for Sourcing Object |
Requests For Quote, Sourcing Projects |
A user performs Action > Change Status on a PCM-solution object, also from the RFQ tab of Sourcing Projects. |
|
Compliance Rollup on Object |
Items, Mfr.Parts, Part Groups, Declarations |
A manual or scheduled rollup commences, e.g., when user performs Action > Calculate Compliance on the object, or when the declaration's workflow changes status (manually or automatically). |
|
Incorporate Item |
Items: Parts and Documents |
A user selects Action > Item Incorporate. |
|
Unincorporate Item |
Items: Parts and Documents |
A user selects Action > Item Unincorporate. |
|
Purge Version Files |
File Folders |
A user selects Action > File Folder Purge. |
Workflow Object-based Event Types
Table 29-5 Workflow Object-based Event Types
| Event Type | Applies to these PLM base classes | Event type is triggered by this end-user Action (or system action or through SDK) |
|---|---|---|
|
Approve for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A user approves a workflow |
|
Audit for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A user initiates a Status Audit or a Release Audit on a workflow using Actions > Audit Status or Actions > Audit Release. (System audit does not trigger it.) |
|
Change Approvers or Observers for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A user adds an Approver/Observer to, or removes Approver/Observer from, the Workflow tab. This event type is not triggered when Approver/Observer is added or removed by using the Routing Slip. |
|
Change Status for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A workflow moves from one status to another, either by user action, or by autopromotion, or by forced change due to Relationship rule. |
|
Comment for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A user comments on a workflow. |
|
Escalation for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A workflow has been in a status awaiting signoff longer than the period defined by Review Escalation Period on the status. |
|
Promotion Failure for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A system-initiated workflow status promotion fails; promotion failures can occur due to autopromotions or Relationship triggers. |
|
Reject for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A user rejects a workflow. |
|
Reminder for Workflow |
Changes, Declarations, Programs, PSRs, QCRs, Transfer Orders, Packages, File Folders |
A workflow has been in a status awaiting signoff longer than the period defined by Reminder Period on the status. |
Variant Management-specific Event Types
Table 29-6 Variant Management-specific Event Types
| Event Type | Applies to these PLM base classes | Event type is triggered by this end-user Action (or system action or through SDK) |
|---|---|---|
|
Create Variant Instance |
Items: part subtype Model |
|
|
Derive Variant Model Option BOM |
Items: part subtype Model |
|
|
Update Variant Configuration |
Items: part subtype Model |
|
|
Validate Variant Configuration |
Items: part subtype Model |
|
|
Validate Variant Instance Selections |
Items: part subtype Model |
|
|
Validate Variant Model Option BOM |
Items: part subtype Model |
Note: On startup of the Instance Manager, this event type is triggered once, independent of how many Instances are selected. |
Additional information about selected event types is presented in "More about Selected Event Types."
Generally one user action in a PLM client will trigger one event type; however, there are many actions in PLM that trigger secondary actions, and this fact accounts for how a single user action may trigger more than one event type.
For example, on an item's Actions menu is Create Change. When a user selects this action, the Create Object event type is triggered. Meanwhile, when PLM creates the change order associated with the original item, it automatically adds the item to the change's Affected Items table, and so the Update Table event type is also triggered.
Here are some additional examples of this:
Item > Actions > Create Declaration: triggers Create Object and Update Table (the Parts table on the new Declaration) event types;
QCR > Actions > Create Change: triggers Create Object and Update Relationship (the Relationships tab on the new change order) event types;
Change object > Actions > Bulk Change: triggers Update Table (the Affected Items table on each new Change, one for each item that is "affected") and Update Table (for each BOM or Manufacturers table that is redlined on each affected item;
Checking out a file triggers Checkout File and Get File event types;
Checking in a file on Agile object (except File Folder) triggers Checkin File and Update Table (Attachments) event types; Modify action if the folder version of the attachment is not the latest; Update Table event type is not triggered if the folder version is set to the latest;
Action > Create File Folder triggers Create Object and Checkout File event types;
In Java Client, adding two URLs to a File Folder triggers two events (adding two URLs to any other business object, only one event is triggered; note also that the user can add two URLs to a File Folder in Web Client, only one event is triggered).
Most of the Variant Management actions trigger multiple events.
Table 29-7 Variant Management actions and triggered events
| Action | Triggered Events |
|---|---|
|
Check Model Option BOM menu on BOM tab |
Validate Variant Model Option BOM |
|
Launch Configurator button on Instances tab |
Validate Variant Model Option BOM Validate Variant Configuration Update Variant Configuration Validate Variant Instance Selections
|
|
Modifications (e.g. select, deselect, edit quantities) in Instance Manager |
Update Variant Configuration Validate Variant Instance Selections |
|
Validate button in Instance Manager |
Validate Variant Instance Selections |
|
Create Instance button in Instance Manager |
Validate Variant Instance Selections Derive Variant Model Option BOM Create Variant Instance |
|
Save As Draft button in Instance Manager |
No event is triggered |
|
Reset Configuration button in Instance Manager |
Update Variant Configuration Validate Variant Instance Selections |
|
Copy Configuration button in Instance Manager |
Validate Variant Configuration Update Variant Configuration Validate Variant Instance Selections |
The following three event types, when used in an Event mask, work in the background:
Scheduled Event
Escalation for Workflow
Reminder for Workflow
For them, the Handler will be invoked as $AGILEUSER. By default, this user is a PLM-system user with many roles assigned, even though it is not available in the Administrator user interface (for example, ACS uses it). As a result, if the Handler does not have a role assigned, these "invisible" roles that are assigned to $AGILEUSER are used when running the Handler.
The Events node is where you create and manage Event masks.
The table below lists attributes found on the General Information tab in Event masks.
All Event masks must name an Event Type. Most Event masks must name an Object Type (excepting those that name one of the "Global" event types).
|
Note: System-generated names are a helpful feature when creating Event masks and Subscriber masks. The Name Helper button can be used: it concatenates Event Type and Object Type (if you select them before you manually enter a Name) to generate a Name and API Name. |
Additional attributes may appear in the Create dialog as certain event types and object types are selected; these are given general mention in this table. "Additional attributes" are also noted by event type in "More about Selected Event Types."
The Where Used tab lists all Subscriber masks that use the Event mask.
Table 29-8 Attributes of Events Masks
| Attribute | Description |
|---|---|
|
Event Type |
Event type categorizes what user action will trigger the event. In a configured Event mask, this field becomes uneditable. "Event Type" itself is a live link: click it to go to the event type. |
|
Name |
Name of the Event mask. You can specify the name, but it is best if the name includes the event type and object type. If you populate Event Type and Object Type fields first, the Name Helper button produces a system-generated name (see Note above this table). |
|
API Name |
Name of the object that is used by external processes use to identify the object. You can specify an API name, but internal consistency is enhanced by accepting the system-generated name once you have specified the Name of the Event mask. |
|
Description |
Enter a useful description of the Event mask. Descriptions are searchable. |
|
Enabled |
Value is Yes or No. |
|
Object Type |
Object Type specifies what kind of business object is being acted on (by the user's task) for the event to be triggered. (Exception: when a workflow is selected as the object type of an Event mask, the system uses the object type of the first Matching Criteria property of the workflow. Only object types that support the Event Type may be selected.
|
|
User Role Required to See PX |
This attribute appears only when the selected Event Type is Extend Actions Menu or Extend Tools Menu. The default role is My User Profile. Multiple roles can be selected. If you select (Restricted) My User Profile, then Supplier users are able to see the PX. You can limit the users that can see the PX by selecting specific roles that have visibility of the PX. All roles are available for selection. |
|
Workflow |
Appears only if a workflow-specific event type is selected. Specify a workflow in the system, or <All> workflows. (<All> is not available for the Change Status for Workflow event type.) If <All> is chosen, Object Type attribute becomes uneditable. |
|
Status - from |
Appears if Change Status for Workflow event type is selected; choose one or multiple statuses, or <Any> status. |
|
Status - to |
Appears if Change Status for Workflow event type is selected; choose one or multiple statuses, or <Any> status. |
|
Action |
Appears and lists appropriate actions for some event types; the list of actions may also be modified by selected object type. |
|
Source Object |
Appears only for the Update Relationship event type; names one or multiple object types as source of the relationship ("relating to"). |
|
Target Object |
Appears only for the Update Relationship event type; names one or multiple object types as target of the relationship ("related from"). |
|
Frequency |
Appears only for the event type Scheduled Event; the drop-down is a scheduling utility (similar to Frequency property for Scheduled Event under Events of ACS). |
|
Table Name |
Appears only for Update Table event type; list of tabs/tables pertains to selected object type. |
This is a checklist of questions to ask (of, perhaps, a company Change Analyst or Product Analyst) and have answered when you begin to create Event Subscriptions and, more specifically, when you create any Event mask.
For my company's installed PLM solutions—and routine tasks performed by Agile users—what are all the PLM Actions that I want to automate the system? Are there any automations needed to supplement actions such as Create, Save As, Update Title Block, Update Table, or by other object behaviors (that are represented by the event types)?
From a given event type being triggered, what is the result that we want to automatically happen?
What is the proper object type that this Event mask will apply to? You may need to ask: will the Handler or Notification (the outcome of this automation) apply to a specific subclass or subclasses? Can the handler apply to all the subclasses for a class and/or base class?
If the event involves a Change, which Workflow(s) does it apply to? Does it apply to all workflows or a specific workflow?
Are there any Event Type-specific parameters to consider? For example, for the event type Delete Object Action, is the Handler mask going to handle soft deletes or hard deletes?
To create an Event mask:
Open the Events node and click the New button. The new Event mask object appears.
In the Event Type field, use the drop-down arrow to select an event type.
In the Object Type field, use the drop-down arrow to select an object type.
It is possible to select a disabled object type, so you must be clear about the status of all object types in your PLM system (the Classes node).
If the event type you selected applies to workflows, the Workflow field appears: select the appropriate workflow and then, if Object Type is enabled, an appropriate object type.
Selection of object type may have also caused the Action field to appear, in which case it is required.
|
Note: If you intend to create an Event mask whose Handler is a notification (sent by email to selected users), the object type of the Event mask must be appropriate for the object type of the Notification mask. For example, if the Notification mask specifies Change Orders (a class), the Event mask must specify the class or ECO (subclass) or any other subclass derived from the Change Order class. For Update Relationship event type, the Notification object type must match the Source object type (or the common object type if there is more than one Source object type) of the Event mask. |
At the Name field, click the Name Helper button to the right; the system uses the event type and object type names to generate a standard name for the Event mask.
Accept the auto-generated API Name. You can enter your own API name, but it is recommended to let the system's name stand for naming consistency.
Fill in a description.
In the Enabled field, accept Yes or select No.
|
Note: A disabled Event mask cannot be invoked; any Subscriber mask that names an Event mask that is disabled will itself be Inactive. |
Click OK to save the configured Event mask.
The Event Handlers node is where you create and manage Handler masks that are based on the Java PX or Script PX handler types.
Here are a couple of tips for quick sorting in the Filter (which becomes more useful as you accumulate Handler and Notification masks).
In Event Handlers node: if you set Filter By to Handler Type and Match If to Starts With, in the field you can simply type "j" or "s" for all Handler masks based on Java PX or Script PX handler types, respectively.
However, in Event Handlers node, typing "n" for Notifications does not return the Notification masks; instead, open Event Handler Types node, open Notifications handler type, and look under the Where Used tab for that list; or, open Notifications node itself.
The table below lists attributes found on the General Information tab in Handler masks.
The Where Used tab on a Handler mask lists all Subscriber masks that point to the Handler mask.
Table 29-9 Attributes of Handler Masks
| Attribute | Description |
|---|---|
|
Handler Type |
Java PX or Script PX. In a configured Handler mask, this field becomes uneditable; however, "Handler Type" has become a live link: click it to go to the handler type. |
|
Name |
Name of the Handler mask: you specify the name (there is no Name Helper as in other parts of these masks). It is recommended that the name describes what the purpose or result of the Handler is. |
|
API Name |
Name of the object that is used by external processes to identify the object. You can specify an API name, but internal consistency is enhanced by accepting the system-generated name once you have specified the Name of the Handler mask. See "API Name." |
|
Description |
Enter a description that is useful; descriptions are searchable. |
|
Enabled |
Value is Yes or No. See "Control of Event Components." |
|
Role |
Select one or more roles to override the user's default roles when the system executes the Handler. See "Roles in Handler Masks." |
|
Event Action |
Appears if handler type is Java PX. The drop-down list enables the user to pick from a list of Java PXs that have been deployed and are available in the system. Note that the completed Events-based process extension itself is deployed in the same manner that you deploy Custom PXs. |
|
Script |
Appears if handler type is Script PX; the script code is pasted into this field; for more information, see "Editing Scripts in the Handler Mask." |
The PLM Roles that are specified in Handler masks determine what roles are taken into account by the system when running the Handler.
If no role is specified in the Roles attribute, the Handler is run with the system observing the assigned role(s) of the user who performed the original action (that triggered the Event Type that is named by the Event mask that has been invoked in the current Subscription).
Whereas, If the Roles attribute is populated, the Handler is run with the system observing only the roles specified in that field, which essentially overrides the user's roles for the actions dictated by the Handler.
With no overriding role specified in the Handler mask, an error condition will occur if that user does not have sufficient privileges to perform the action (or some partial action) dictated by the Handler.
In this way, the administrator uses the Roles attribute to guarantee that the Handler can complete all of its specified actions.
This is a checklist of questions to ask and have answered when you create a Handler mask. These items can also serve as a communication vehicle between yourself and a programmer who is tasked to create Java-based PXs and Groovy script-based process extensions.
Do I already have configured Event masks? What Event mask am I trying to handle?
Is this a notification or a process extension? That is, what broad result does the Handler need to accomplish? What kind of instructions must the system have to complete a successful automation?
If the Handler is to be a notification, has the Notification mask already been created (in System Settings > Notifications)?
If the Handler is to be a process extension, what is the proper handler type for this Handler mask?
Who is providing the Java code, SDK or Groovy script that will drive this Handler mask?
Has the Java process extension been developed and tested? Is it properly deployed so the Java PX Handler mask will be able to find it?
What Roles are needed to run the handler mask? Will the user performing the PLM action always have the right Roles?
To create a Handler mask:
Open the Event Handlers node and click the New button. The new Handler mask object appears.
In the Event Handler Type field, choose Java PX or Script PX.
Remember that while Notifications are categorically a handler type, Notification masks are created in Notifications node and thus are not offered as a choice when creating a Handler mask.
If you select Script PX, the Script field appears with this default Groovy script:
import com.agile.agileDSL.ScriptObj.IBaseScriptObj
// add other import statements here
void invokeScript(IBaseScriptObj obj) {
//script body starts here.
}
In the Name field, enter a name.
Accept the auto-generated API Name.
In the Role field, enter the roles that will permit the Handler to be run as. If a role is specified here, it overrides the original user's roles when the Handler is executed. See "Roles in Handler Masks."
Enabled should be set to Yes if you want this Handler mask to be available for Event Subscriptions.
Script field: paste in the script for this handler. (You can create the Handler mask without providing a script yet; in this case it is better to set Enabled to No.)
Click Validate Script to make sure the script will run properly.
Click OK to save the configured Handler mask.
The Event Subscribers node is where you create and manage Subscriber masks.
The Subscriber binds (by naming) an Event mask and a Handler mask, and provides concrete "How" and "When" information about the automated outcome with such fields as Trigger Type (Pre- or Post), Execution Mode (Synchronous or Asynchronous), Order and Error Handling Rule; all of these are defined later in this section.
You can create more than one Subscriber mask that names a given Event mask. A second Subscriber mask naming the same Event mask would name a different Handler mask. In this case, when this Event fires, more than one Handler will be executed. The Subscriber can specify the order for the system to run the Handlers (Order), and how to handle error cases (Error Handler Rule).
Here are a couple of tips for quick sorting in the Filter (which becomes more useful as you accumulate Handler and Notification masks).
In Event Subscribers node, if you set Filter By to Handler Type and Match If to Starts With, in the Value field you can simply type "j" or "s" to return all Subscribers with a Handler mask based on, respectively, Java PX or Script PX handler types.
In this node, you also can enter "n" and Subscribers with a Notification mask are returned (unlike in the Event Handlers node).
When you create a subscriber mask, two dialogs offer similar filtering attributes, which are mentioned here for comparison.
Event [Mask] field drop-down arrow brings up the Select Event [Mask] dialog, in which you can Filter By:
Name [of Event masks]
Event Type
Object Type
Event Handler [Mask] field drop-down arrow brings up the Select Event Handler [Mask] dialog, in which you can Filter By:
Name [of Handler masks or Notification masks]
Handler Type
Object Type
In this second dialog, if Filter By is Handler Type, and Match If is Starts With, in the Value field this dialog returns the appropriate Handler or Notification masks when you type "j" (Java PX Handler masks), "s" (Script PX Handler masks), or "n" (Notification masks).
It may be said explicitly (as these filters imply) that the selectable Event mask and selectable Handler mask must be compatible. This point may help explain why some Event masks or Handler masks do not appear as you construct the Subscriber mask. Other compatibility concerns come up with Subscriber attributes such as Trigger Type and Execution Mode; they are suggested in the definitions of Subscriber attributes below and in sections after the table.
The table below lists attributes found on the General Information tab in Subscriber masks.
Subscriber masks also have a Monitor tab, which provides a view of the row for the current Subscriber mask from the "Event Handler Monitor."
Table 29-10 Attributes of Subscriber Masks
| Attribute | Description |
|---|---|
|
Name |
Name of the Subscriber mask: it can be system-generated the Event (mask) and Event Handler (mask) fields are given values |
|
API Name |
Name of the object that is used by external processes to identify the object. You can specify an API name, but internal consistency is enhanced by accepting the system-generated name once you have specified the Name of the Subscriber mask. See "API Name." |
|
Description |
Enter a description that is useful; descriptions are searchable |
|
Enabled |
Value is Yes or No. See "Control of Event Components." |
|
Event |
Name of Event mask bound by this Subscriber mask: use drop-down arrow to display the Select Event dialog to filter and choose Event mask. In a configured Subscriber mask, although this field remains editable (because you can modify the Subscriber to point to another Event mask), "Event" has become a live link: click it to go to the designated Event mask itself. |
|
Event Type |
Appears (uneditable) in the saved Subscriber mask from the selected Event mask |
|
Object Type |
Appears (uneditable) in the saved Subscriber mask from the selected Event mask |
|
Event Handler |
Name of Handler mask bound by this Subscriber mask: use drop-down arrow to display the Select Event Handler dialog to filter and choose Handler mask. In a configured Subscriber mask, although this field remains editable (because you can modify the Subscriber to point to another Handler mask), "Event Handler" has become a live link: click it to go to the designated Handler mask itself. |
|
Handler Type |
Appears (uneditable) in the saved Subscriber mask from the selected Handler mask |
|
Trigger Type |
Pre – invokes the Handler before the action (described by the event type named in the Event mask) occurs. Post – invokes the Handler after the action (described by the event type named in the Event mask) occurs. "Post" is generally the more applicable setting. See "Trigger Type: Pre and Post" and "Trigger Types and Execution Mode".
|
|
Execution Mode |
Asynchronous – the transaction completes and the interface control is returned to the user while the Handler is executed in a different thread in the background. Synchronous – the user waits for interface control to return until after the handler completes and then handler is executed in the same thread. If Trigger Type is Pre, Execution Mode can only be Synchronous. See "Execution Mode: Synchronous or Asynchronous".
|
|
Order |
A number (integer) that sets the sequence of synchronous events. Applies to synchronous Subscribers only. |
|
Error Handling Rule |
The basic definitions of Continue and Stop are elaborated below. Continue – If there is an error during the execution of a Handler with synchronous execution mode, the error is ignored. Stop – If there is an error during the execution of a Handler with synchronous execution mode, the original action and the Event Subscription is ceased. When Execution Mode is Synchronous:
When Execution Mode is Asynchronous:
|
Pre and Post are settings for the Subscriber mask attribute Trigger Type. The familiar prefixes "pre" and "post" are used to mean, respectively, before and after. In configuring Event Subscriptions, you must choose whether you want the Event Subscription to be run before or after the transaction.
Pre(-event) trigger types signal a point just before the system starts the transaction for the PLM action that the user requested. A Subscriber with a Pre trigger type can be used to prepare objects or data for a subsequent, upcoming action; or to validate objects or data.
Post(-event) trigger types signal a point just after the system completes transaction for the PLM action that the user requested. A Subscriber with a Post trigger type can be used for notifications, reminders, escalations, or to perform some auditing tasks based on an earlier action (such as tasks accomplished by Pre-event Subscribers); or external-system integration tasks.
Notification masks are handled only by Post-type Event Subscriptions.
This discussion only defines these terms; you may consult the schematic called "Triggering and Processing an Agile PLM Event" in Chapter 24 of Agile PLM SDK Developer's Guide.
Event handlers can be run either asynchronously or synchronously.
Generally, asynchronous means "not occurring at the same time" and synchronous means "occurring at the same time".
In Event Management, an asynchronous Handler means the Handler is executed in a separate thread, and the original thread does not wait for the Handler to finish (that is, it is not blocked). A synchronous Handler is executed in the same thread as the initiator, and it waits for the Handler to finish.
The choice of the handler's Execution Mode varies based on the choice of Trigger Type:
Pre-event triggers support only those handlers that can be run synchronously.
Post-event triggers support handlers that can be run both asynchronously and synchronously.
Notifications are always Post trigger type and Asynchronous execution mode.
|
Note: Be sure to read the nuances about Pre, Post, and Synchronous in "Error Handling Rule" in the above table. |
For synchronous Subscribers, either pre or post, the Order value determines the sequence of calling handlers.
For example, if there are three Subscriber masks that trigger based on a user creating a part. These could have been triggered because of Event masks that name the object types Items (base class), Parts (class), or Part (subclass).
The system evaluates all three Subscribers together: it sorts first by values for Order, so if you entered 1, 2, and 3, respectively, in these three Subscribers, the system knows which one to act on first, and so on.
If Order has no values or the same value, the system resorts to selecting Subscriber names in alphabetical order to determine the sequence of calling Handlers.
Again, you may consult the schematic called "Triggering and Processing an Agile PLM Event" in Chapter 24 of Agile PLM SDK Developer's Guide.
Here are some questions to be answered when you set up a Subscriber mask. The attributes in the Subscriber mask may have been already considered when you set up the Event and Handler masks.
Do I have all the relevant Subscribers to support my Event masks and Handler masks?
What Event mask is being named in this Subscriber mask? What is the event type that you are interested in?
What Handler mask or Notification mask is being named in this Subscriber mask? What Handler do you want invoked when the event type of interest is triggered?
Which Trigger Type should be used, Pre or Post? Why do you want the Handler to invoke Pre or Post?
Which Execution Mode should be used, Asynchronous or Synchronous?
What is the Order in which the Handler mask should be invoked?
What Error Handling Rule should be used?
Am I certain that all elements of this Event Subscription are enabled? Can I verify that this Subscriber mask is Active? (See "Event Subscribers Tab on All Object Types.")
System-generated names are a helpful feature when creating Event masks and Subscriber masks. The Name Helper button can be used: when you create a Subscriber mask, the system concatenates selected Event mask name and Handler mask name (if you select them before you manually enter a Description, in which case the system uses the Description to generate the name, with a limit of 150 characters).
To create a Subscriber mask:
Open the Event Subscribers node and click the New button. The new Subscriber mask object appears.
At the Event field, use the drop-down arrow to display the Select Event dialog.
Use Filter By and Match If criteria (see "Filtering in Dialogs during Create Subscriber") to return Event masks, and select one.
At the Event Handler field, use the drop-down arrow to display the Select Event Handler dialog.
Use Filter By and Match If criteria to return Handler masks or Notification masks, and select one.
|
Note: If you are creating an Event Subscription whose outcome is a notification (sent by email to selected users), the object type of the Event mask must be the same as the object type of the Notification mask. This is a good time to verify that this condition is met by the Event mask (designated in step 2) and the Notification mask (designated in this step). |
At Name field, click the Name Helper button to the right; the system uses the Event mask and Handler mask names to generate a standard name, and the API Name. If the system-generated name is not sufficient, you may change it.
A new Subscriber mask is enabled by default; you can set Enabled field to No, but of course it will not run the Subscription until it is enabled.
At Trigger Type field, select Pre or Post.
At Execution Mode field, select Asynchronous or Synchronous.
If Trigger Type is Post, Execution Mode field is automatically set to Asynchronous.
Post and Asynchronous are the correct settings for notification-specific Event Subscriptions.
If appropriate, at Order field, give an order number.
Similarly, if an Error Handling Rule is required, select one.
Click OK to save the configured Subscriber mask.
The chapter "Scripting and Sample Event Subscriptions"introduces scripting for the administrator and presents five sample Event Subscriptions, including the script, as appropriate.
This Event Subscription updates an item's Description when a user updates the Title Block of any business object from one of all the Parts-class subclasses.
"Notify Create User when Item is Incorporated."
This Event Subscription creates a notification and sends it to the user who created that part or document when an item—an instance of any subclass in the Parts or Documents subclass, and therefore of the Items base class—is incorporated. Note that this notification is generated by instructions from a script (a Script PX handler), rather than a Notification mask created by the administrator (as in last example below).
"Set Change Analyst" when ECO changes status
This Event Subscription automatically sets the Change Analyst when an ECO changes status to Submitted.
This Event Subscription automatically creates a Document and adds it to the Assembly BOM any time a part is created.
"Notify when Affected Items Table is Updated."
This Event Subscription automatically sends a notification (created in Notifications node) any time the Affected Items table of a Change is updated.
The Event Management framework provides several means to monitoring handlers and subscribers, or troubleshooting problems with triggered events:
Event Handler Monitor node is a monitor of event activities; it is detailed below;
An Event-specific log file; see "Event Log File."
Runtime error messages are presented in an error dialog; and,
Execution of Java PX, Script, or Notification is logged on the object's History tab.
The Event Handler Monitor keeps track of which Handlers have been run as a result of events being triggered. The administrator can see how many handlers have been invoked and how many are still running. For each Handler, the administrator can see when it was invoked, what Event mask was involved, the Handler's current status, when it finished, explicit return messages from the Handler, or exceptions if something is wrong.
The systemwide Preference Event Handler Logging can be set to log all invoked Handlers (All), to log only errors (Error), or turned off (Off).
When you open Event Handler Monitor node, use the filter bar (table search) to return existing event masks. The Filter By attributes in the Event Handler Monitor node are:
Event [that is, name of Event mask]
Event Handler [that is, name of Handler mask or Notification mask]
Event Subscriber [that is, name of Subscriber mask]
Status
Object
This table defines the Event Handler Monitor attributes. Note that each Subscriber mask has a monitor view that shows essentially the same information, only for Handlers named by that Subscriber.
Table 29-11 Attributes of Event Handler Monitor
| Attribute | Definition |
|---|---|
|
Event Type |
The event type of the triggered Event mask |
|
Event |
Name of the Event mask |
|
Handler Type |
The handler type of the designated Handler mask |
|
Event Handler |
Name of the Handler mask |
|
Event Subscriber |
Name of the Subscriber mask |
|
Trigger Type |
Whether the Event Subscription is to be run before or after the transaction |
|
Execution Mode |
Whether the Handler is to be run synchronously or asynchronously |
|
Object |
The specific business object on which the Event was triggered |
|
Start Time |
When the Handler begins to run, displayed in the user's Time Zone |
|
Stop Time |
When the Handler has finished running, displayed in the user's Time Zone |
|
Owner |
The end-user whose action triggered the Event |
|
Status |
These are the values for Status and what they mean: Running – handler is in progress Completed – handler has finished Failed – handler did not finish Queued – waiting to be run, only applies to asynchronous handlers Unknown – handler failed but the reason is unknown Submit for Notification – status for Notification handler |
|
Message |
The result message that is returned by the handler mask |
|
Thread ID |
ID of thread for which the Handler runs |
|
Event Count |
Tracks the level of "nested" events, that is, events triggered by an event (not a user's action). The allowed maximum of nested events is defined in the systemwide preference "Event Maximum Nested Levels Allowed". |
In addition to the Event Handler Monitor, Agile PLM also provides an Event Log file, SOAEvent.log. It records all event-related activities occurring in the application.
This log file is configured in Log.xml, which is established at Install time. The "log level" can be configured from log.xml. Like other Agile log files, SOAEvent.log resides on the File Server.
Log.xml is found in <AgileInstallFolder> \ AgileDomain \ config
A business object's History tab will indicate such information as: in the Action column, what user-defined action called the process extension; in the Details column, what the Handler name is and any returned message (if an event was triggered on the object). Scheduled Notification is also tracked in an object's History tab.
The following subsections specify the "stop controls" in Event Management nodes.
In any given Event Management node, multiple rows can be selected and disabled or enabled with one click. The details that follow all come with an implicit warning to be careful about what you are disabling or, for that matter, enabling.
|
Note: It is highly recommended that Event Subscriptions and their various masks are first created and tested on a PLM Test system before introducing them into the Production system. With Agile Configuration Propagation (ACP, see separate manual), fully tested Event Management configurations can easily be transferred from Test to Production systems. |
The Admin toolbar has a button called Disable Triggering Events. When it is clicked (and you respond to the prompt), no Events are triggered from that point on, until the same button—which changed to Enable Triggering Events—is clicked. At that point, event triggering resumes.
The Disable Triggering Events button is, like the other buttons on the Admin toolbar, enabled only for those users who have been assigned the Administrator privilege mask with the AppliedTo of Global Event Triggers Control.
When Triggering is disabled, all currently running transactions will be completed, but no new events are triggered. The button only disables triggering, that is, it does not impact administrator configuration of events.
|
Note: The Disable/Enable Triggering Events button creates a persistent setting: on startup, the system begins with this setting in the mode used when the server was stopped. |
Any indirect changes in the setting of this button—which includes changes caused by switching database, or being enabled/disabled by another administrator—does not take effect until logout and log back in to Java Client.
If you disable an Event Type, the system does not change the Enabled property of the Event masks that use that event type; however, as a result, each and every Event mask of the disabled event type is effectively inactive—which renders inactive any Subscriber that names it.
So with one click you could effectively "shut down" all Get File-based events, for example.
You can still create Event masks of that event type while it is disabled.
If you re-enable that event type (by selecting its row and clicking the Enable button), the system resumes triggering for that event type. Subscribers that name such Event masks may be active again.
If you disable a handler type, the system does not change the Enabled property of any Handler masks that use that handler type; however, each and every Handler mask of the disabled handler type is effectively inactive—which will render inactive any Subscriber that names that Handler.
By disabling any handler type, you are therefore effectively preventing the execution of the Handler with that handler type. So you could effectively "shut down" all Java PX-based events, or all Script PX-based events, or all Notification-based events with one click.
You can still create Handler masks of that handler type while it is disabled; they simply will not be executed.
If you re-enable that handler type (by selecting the row and clicking the Enable button), the system resumes responding to all Handler masks based on the handler type. Subscribers that name such Handlers may be active again.
If you disable an Event mask, Subscribers that name such Event masks are then inactive.
You can still modify a disabled Event mask; it simply will not respond when invoked.
If you re-enable that Event mask, the system resumes responding to it. Subscribers that name such Event masks may be active again.
If you disable a Handler mask, all Subscribers that name that Handler are then inactive.
You can still modify a disabled Handler mask.
If you re-enable that Handler mask, the system resumes responding to it. Subscribers that name that Handler may be active again.
If you disable a Subscriber mask, that Subscriber mask is immediately inactive and cannot be executed.
You can still modify a disabled Subscriber mask.
If you re-enable that Subscriber mask, the system resumes responding to it; and the Subscriber mask is active.
This section adds information about selected event types that is not captured in the table in "Default Event Types."
Extend Tools Menu
Extend Tools Menu event type is a direct parallel to the existing capability for legacy PXs to appear in the client's Tools menu. Use of this event type will place the Event mask in the Tools menu.
There is no relevance to Pre and Post conditions, so this event type only triggers on Post.
The event mask's Name is what appears in the Tools menu. Note that the listing of PXs in the Tools menu is alphabetical, with legacy PXs and new event mask Names sorted together.
Scheduled Event
Scheduled Event enables the execution of any Event Subscription at a time you select.
All standard fields in event masks are available. Selecting Scheduled Event adds the Frequency field, similar to Scheduled Event in ACS with the same settings. Object Type is Not Applicable.
Only Post event is possible for this event type.
The timestamp (Time that is displayed) is in GMT time zone.
Extend Actions Menu
Extend Actions Menu event type is a direct parallel to the existing capability for legacy PXs to appear in an object's Actions menu. Use of this event type will place the Event mask in the correct object's Actions menu.
There is no relevance to Pre and Post conditions, so this event type only triggers on Post.
The event mask's Name is what appears in the Actions menu.
Create Object
Besides the Create menu in Web Client, there are several other ways to initiate object creation: through the Actions shortcuts (as in an Item > Actions > Create Change); through a Table action; through the Agile SDK; or through Agile Web Services.
Use of Save As to create objects is covered by a separate event type.
|
Note: When a user creates a Project by means of Create Program from Template action, the Save As Object event type is triggered, not Create Object event type. |
Entering Required Fields during the "Create" process is not considered an "Update" action, and so does not trigger the Update Title Block event type.
Delete Object
The "Delete" action occurs in Java Client through the Delete button or, in Web Client, by Actions > Delete. This action can also be called by SDK or Web Services.
When an object is first deleted, it is recognized as an Initial, or "soft", delete. The object is not yet removed from the database and can be retrieved through Recycle Bin searches. After opening the object from a Recycle Bin search, the user can select Delete again to trigger a final delete ("hard" delete).
Additional Attributes
Delete Type – Soft, Hard
For an Agile business object that does not support hard delete, there is no risk in selecting Hard since the event itself will never trigger.
RFQs class supports only Hard delete. RFQ Responses class does not support either type of delete.
Get File
The Get File event type is triggered in the following cases:
on a business object's Attachments table, user hits Get button
on a business object's Attachments table, user clicks a file name link:
if the file is a viewable file, Agile Viewer is launched; no event type is triggered.
If the file is not a viewable file, the system performs the Get File action and the Get File event type is triggered; in general, from Java Client the Get File event type is triggered on File Folder objects, while from Web Client it is triggered on business objects.
Also, in Java Client, the number of Get File triggers depends on whether the "Download the files in one ZIP file" option is selected or not: if selected, one Get File trigger fires; if this option is not selected, multiple Get File triggers are fired.
Update Relationship
The Update Relationship event type is triggered whenever a Relationship is added, removed, or directly edited on a business object's Relationships tab. Editing can include editing any field on the row, including the Relationship Rule.
The "Relationship" use case is treated as a discrete event type (compared to Update Table) because the target object is significant, that is, any PLM object can be in Relationship to any other PLM object.
This event type is not triggered due simply to the Relationship Rule being met. For example, let the rule for an ECO be: set an ECR to Closed status when the ECO moves to its Implemented status; so, when the ECO moves to Implemented, the condition of the rule is met, and Agile PLM attempts to move the ECR to Closed. If the ECR is moved to Closed, then the Change Status event type is triggered; whereas, if the move to Closed fails, then the Promotion Failure for Workflow event type is triggered.
Additional Attributes
Source Object Type – select from list of object types that can trigger this event type when a user modifies the Relationships tab.
Target Object Type – select from list of object types that can be updated as a result of the Relationships tab update.
|
Note: To set up a Subscriber mask for a Notification handler when the Event mask is based on Update Relationship event type, the object type of Source Object Type and the object type of the Notification mask must match. If multiple Source object types under the same class hierarchy are selected, the Update Relationship-based Event mask can be bound to a Notification mask whose object type is common among all selected Source object types. |
Update Table
Not all tabs of all objects support the Update Table event type.
Inclusions
Update Table event type captures user-initiated object table edits. In general, this includes Items > BOM table, Changes > Affected Items table, Attachments table, and so forth.
Mass Update from a file folder object causes Update Table to be called for the relevant actions. Different events are triggered for each object's Attachments tab.
A Changes > Redline table for BOM, Manufacturers, or Attachments triggers an event on the Item, not on any Changes table.
For PCM-specific, PPM-specific, or "Common Services" objects.
Supported in Attachments only.
Exclusions
The Relationships table warrants its own event type, as noted above.
In general, Update Table event type excludes those kinds of tables that are Read Only, for example, all Where Used and all History tables.
Secondary table updates are also excluded, for instance, Changes and Quality tables, because the primary action is taking place elsewhere.
Modifications to the BOM and Manufacturers tables do not trigger an update when an ECO is released – the trigger is used on the Changes > Redline tables or on Change Status.
Additional Attribute
Table – This multilist field contains all relevant Tables that are valid for the object and that are enabled for Events; tables are listed once they are implemented for Events. All implemented tables display for the object, even if they are not made Visible for users within Administrator.
There is no <All> table action. As a multilist field, customers can select multiple values.
Update Title Block
The Update Title Block event type is triggered when a user directly edits any fields on an object's Page One (that is, Cover Page, General Information, or Title Block), Page Two, or Page Three. It does not trigger based on system-written values, for example, releasing a Change Order to update Lifecycle Phase.
The new Attribute Change Management feature of Change Orders and Manufacturing Orders are treated consistently with a BOM or AML update. Update Title Block event type is invoked only because of direct data entry, not because the Change was released with Attribute Change Management.
Redlining the Title Block on a Change Order or Manufacturer Order will trigger the Update Title Block event on the Item, not on the Change. A property of the Event Context Object indicates whether the update is occurring as a Redline; see Agile PLM SDK Developer's Guide.
LDAP updates do not invoke the Update Title Block event type.
Change Status for Sourcing Object
The PCM solution does not use the standard Agile workflow. Change Status for Sourcing Object event type captures various changes to the statuses of PCM objects.
Additional Attributes
Action – In general, this is the list of Lifecycle Phases for PCM Objects.
List for Requests for Quote
List for Sourcing Projects
When a workflow is created by the administrator, the only object type that can be chosen is a base class. Events are designed to be more definable than that; the system therefore uses the workflow's Matching Criteria property.
For all of the Workflow-based event types, the Workflow property is added to the Event mask. This property follows these rules:
For all but Change Status for Workflow event type, the Workflow value can be <All>; when <All> is selected, Object Type property is disabled.
When, however, a class-based workflow is chosen, if that workflow's Matching Criteria property has one value, the system uses that value as the Object Type of the Event mask.
If the workflow's Matching Criteria property has multiple values, the system uses them to provide a drop-down list from which the administrator selects the Object Type for the Event mask.
Approve for Workflow
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Audit for Workflow
Besides a user starting a Status Audit or a Release Audit, the Audit for Workflow event type can be initiated through SDK or Web Services. (For more information, see Agile PLM SDK Developer's Guide.) System-generated audits that occur during status changes do not trigger this event. Any failure information is included in the Event Context Object; see Agile PLM SDK Developer's Guide.
Additional Attributes
Type – Status (audit), Release (audit)
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Change Reviewers for Workflow
There is no "affected status" for this event type.
Additional Attributes
Workflow – populating this property and Object Type property observes the rules stated at start of this section
Action – Add Approver or Observer, or, Remove Approver or Observer
Change Status for Workflow
Besides a Change Status in a workflow taking place because of user action, this event type recognizes Change Status in these cases: autopromotion within the server; when a Relationship Rule is matched which forces a Change Status; when "If Rejected, Set Status To" status property causes a status change. This event type triggers whenever a workflow moves from one status to another.
The Pre-event is before the object exits the "From" status. The Post-event is after the object arrives in the "To" status. This event type is structured in this way because there is no valid condition between statuses – the Change Status transaction is a "black box" to the programmer.
Additional Attributes
Workflow – value cannot be <All> or blank; there is a single list of valid workflows for the selected object. Once a workflow is chosen, populating Object Type property observes the rules stated at start of this section.
Status – From – list of statuses from the selected workflow; <Any> is valid and indicates any status
Status – To – list of statuses from the selected workflow; <Any> is valid and indicates any status
Comment for Workflow
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Escalation for Workflow
Since this event type is predicated on a system action that must complete (regarding the status property Review Escalation Period), the Pre-event is not available, so Trigger Type is Post only.
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Promotion Failure for Workflow
Since this is a system action which must complete, the Pre-event is not available, so Trigger Type is Post only.
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Reject for Workflow
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
Reminder for Workflow
Since this event type is predicated on a system action that must complete (regarding the status property Reminder Period), the Pre-event is not available, so Trigger Type is Post only.
Additional Attribute
Workflow – populating this property and Object Type property observes the rules stated at start of this section.
There are no "Pre" or "Post" trigger types for Variant Management event types. Once enabled, Variant Management event types replace the system behavior instead of extending it.
Variant Management events are different than other events in the system. They act differently to allow customers to replace the default system logic with their own logic in managing Model Option BOMs.
Create Variant Instance
The Create Variant Instance is triggered upon clicking the Create Instance button and after successfully completing the Validate Variant Instance Selection and the Derive Variant Model Option BOM event types.
The event handler creates the derived Instance BOM.
Derive Variant Model Option BOM
The Derive Variant Model Option BOM is triggered when the user clicks the Create Instance button in the Instance Manager and after the successful processing of the Validate Variant Instance Selection event type.
The event handler creates the logical structure of the Instance BOM without actually creating new items or changing the BOM tab of an item.
Update Variant Configuration
The Update Variant Configuration event type is triggered for every user modification of a line item, for modifications of quantities or selecting/deselecting check boxes in the Instance Manager, and for preselections (e.g. mandatory items) when starting the Instance Manager. It is also triggered when pressing the Copy Configuration button.
The event handler adds or removes configuration options and runs propagations and pre-selections.
Validate Variant Configuration
The Validate Variant Configuration event type is triggered once when opening the Instance Manager for an Instance with Configuration Graph, and after the successful processing of the Validate Variant Model Option BOM event type. This event type is not triggered for preselections (e.g. mandatory items) or if no Configuration Graph is available.
This event type is also triggered when clicking the Copy Configuration or Reset Configuration button in the Instance Manager.
The event handler checks the consistency of the Configuration Graph and the Model Option BOM.
Validate Variant Instance Selection
The Validate Variant Instance Selections event type is triggered once:
During the launch of the Instance Manager.
Modifying a line item after the successful processing of the Update Variant Configuration event type.
Clicking the Validate button in the Instance Manager.
Clicking the Create Instance button in the Instance Manager.
Clicking the Reset Configuration button in the Instance Manager.
Clicking the Copy Configuration button in the Instance Manager.
The event handler checks validation rules for the configuration, e.g. minimum/maximum violations, or if an Option class has valid child options.
Validate Variant Model Option BOM
The Validate Variant Model Option BOM event type is triggered once when selecting the Check Model Option BOM menu of the BOM tab of a Model, or when starting the Instance Manager.
The event handler checks validation rules on the Model Option BOM, e.g. if the minimum quantity value is smaller/equal to the maximum quantity value, or if an Option Class has valid child options.
