| 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 |
Agile PLM has the capability to send notifications to users, either when the user is required to take action, or to notify the user that various actions have taken place.
With the introduction of the Event Management framework, there are now two types of notifications in PLM. The Notifications node stores both types:
Default notifications can be modified but only in a limited way; for this reason they are sometimes referred to as notification templates.
Event-based notifications are admin-user-created and permit much more flexibility and creativity in how and when notifications are sent by the system.
The default notifications are triggered by the system based on system- or end-user-generated actions that have been captured in the notification templates. Default notifications have an uneditable Object Type property. They cannot be used by Event Subscriptions, that is, unless you perform Save As on the default notification and proceed to configure a Notification mask.
Event-based notifications can be distinguished by their configurable Object Type property. They can be triggered by Event Subscriptions that are configured in the Event Subscribers node.
It is necessary for the administrator to enable a database setting before any notifications are sent. In Server Settings > Database, ensure that the setting of the Notification Enabled property is Yes. If this property is set to No, PLM does not send notification emails or messages to the users in the system.
An individual notification is sent only if it has been enabled by setting its Enabled attribute to Yes. Depending on the Notification Type property setting for the notification, the notification appears in the user's Inbox, is sent by email, or both. The Enabled and Notification Type attributes can be set as needed for each notification.
A user can receive notifications with links back to Java Client or Web Client; more explicitly, the User preference Preferred Client (under User Settings > Users > <any user> > Preferences tab) determines which client is automatically opened to the object to which the notification's link points. Since Agile users working in the PPM, PCM, and PG&C solutions operate only in Web Client, it is recommended that the Preferred Client be set to Web Client for those users.
To fully configure email notification in Agile PLM Clients, see "Configuring Web Client Notification", "Configuring Java Client Notification".
Default notifications are listed in the System Settings > Notifications node. Default notifications are not and cannot be associated with any events configured by the administrator in the Event Management node; however, a Default notification can be saved to create a new notification that can be associated with an Event Subscription. See "Creating a Notification using Save As" for more information.
Table 21-1 Attributes of Default Notifications
| Default notification attribute | Description |
|---|---|
|
Name |
Name of notification; not editable |
|
API Name |
API Name is non-editable in Default notifications |
|
Object Type |
Object Type is non-editable in Default notifications |
|
Enabled |
Yes = the notification is enabled, so it can be sent (by the system). No = the notification is disabled, it cannot be sent. |
|
Priority |
Default is Regular; list includes High and Low |
|
From |
Select a user from the list who will be listed in the "From:" field of the notification. Only one user can be selected for the From attribute. The defaults are variables: $AGILE is always present on the drop-down list; $ORIGINATOR and $SENDER are often present; on routable objects, the appropriate routing manager variable is present (for example, $CHANGE ANALYST). |
|
To |
To: is always empty on Default notifications. |
|
Notification Type |
Select Email, Email and Inbox, or Inbox from the drop-down list. |
|
Subject (and Data) |
By including Data tags when you compose the subject line, you can include references specific to the triggering event, such as Change Number and Originator. |
|
Body (and Data) |
By including Data tags when you compose the body text, you can include references specific to the triggering event, such as Change Number and Originator. |
$NOTIFY picks up only the default Notify users from manual routing. In this case, when Change Status is brought about by autopromotion (for example, when a Relationship is triggered), the default Notify users are not picked up. This is a difference between how Default notifications and Event-based notifications process change status.
Event-based (or "admin-created" or "user-defined") notifications are created in the Notifications node. A notification created by the administrator has much more flexibility than the default notifications. Event-based notifications support Page Three attributes (if any) for subclass notification.
Event-based notifications are the Handler in those Event Subscriptions that are dedicated to notifications. See "Event Management" and "Handler Types." For an example of a Notification mask configured into an Event Subscription, see "Notify when Affected Items Table is Updated."
Notifications can also be called by the Agile SDK and a Script PX handler. (See "Invoking Notifications Programmatically"). For an example of generating a notification through the SDK, see "Notify Create User when Item is Incorporated."
When a notification is triggered in the application, a Scheduled Notification is tracked in the History tab of the object. It shows the triggered Event and Notification and the $NOTIFY users that may receive the notification.
In an admin-created notification, $NOTIFY picks up the "Notify" users entered by end-user in the Notify field in routing slips, Signoff dialog box, and Comment dialog box; it also picks up the "check box" users in Signoff dialog box and Comment dialog box.
In addition, if the Default notification is used for Reminders, it picks up the Approvers or Acknowledgers to be reminded; if the Default notification is used for Escalations, it picks up the Escalation persons of the Approvers or Acknowledgers.
To find a list of only Event-based notifications that are created by the administrator go to System Settings > Event Management > Event Handler Type > Notifications > Where Used tab.
|
Note: Unlike Default notifications, admin-created notifications can be deleted. See "Deleting a Notification." |
|
Important: For notification-specific Event Subscriptions, the object type of the Event mask must be appropriate for the object type of the Notification mask. Either the notification applies to all objects of the Object Type (subclass), or, the notification is derived from the Object Type (base class and class). 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. |
General Information Tab Attributes
Table 21-2 Attributes of Event-based Notifications, General Information tab
| Event-based notification attribute | Description |
|---|---|
|
Name |
Name of Notification mask |
|
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 Notification mask. See "API Name." |
|
Object Type |
The object type attribute limits the notification to actions on objects of the type specified. This required field is selected from a drop-down list of Base Class, Class, and Subclass options. The object type selected also dictates the available From options and available attributes (Cover Page, Page One, Page Two, or Page Three) to be added as tags for the Subject and Body fields in the notification. It also dictates some of the variables available in the "To" options (for example, $CHANGEANALYST). Object Type can be changed in the Create Notification (Mask) dialog for user-defined notifications. Object Type is non-editable once the Notification mask has been created. (See "Important" note just above this table.) |
|
Enabled |
Yes = the notification is enabled, so it can be sent (by Event Subscription or even programmatically, i.e., by SDK). No = this notification is disabled, it cannot be sent. |
|
Priority |
Default is Regular; list includes High and Low. |
|
From |
Select a user from the list who will be listed in the "From:" field of the notification. Only one user can be selected for the From attribute. The defaults are variables: $AGILE is always present on the drop-down list; $ORIGINATOR and $SENDER are often present; on routable objects, the appropriate routing manager variable is present (for example, $CHANGE ANALYST). |
|
To |
Select a user from the list who will be listed in the "To:" field and receive the notification. The variable $NOTIFY is available, in addition to specific recipient users from the Address Book. Note If the object type is a routable object then the available list of recipients will also include workflow users. The list of users may include users that will not receive notifications because of lack of privileges. |
|
Notification Type |
Select Email, Email and Inbox, or Inbox from the drop-down list. |
|
Subject (and Data) |
You may compose a subject line for the notification. By including Data tags when you compose the subject line, you can include references specific to the triggering event, such as Change Number and Originator. |
|
Body (and Data) |
You may compose body text for the notification. By including Data tags when you compose the body text, you can include references specific to the triggering event, such as Change Number and Originator. |
Where Used Tab Attributes
Table 21-3 Event-based Notification Attributes, Where Used tab
| Event-based notification attribute | Description |
|---|---|
|
Name |
Names of Event Subscribers (masks) that point to the notification |
|
Description |
Description of Subscriber masks that point to the notification |
|
Enabled |
The setting of Enabled for the Subscriber masks |
|
Event |
The Event mask that is associated with the Subscriber masks |
|
Event Handler |
The current notification's name. This is always the Notification currently opened because the Notification functions as the Handler for the associated Subscriber masks. |
|
Trigger Type |
The trigger type for a notification is always Post. See "Trigger Type: Pre and Post." |
|
Execution Mode |
The execution mode for a notification is always Asynchronous. See "Execution Mode: Synchronous or Asynchronous." |
|
Order |
Disabled; the column does not display data because the property does not apply to notifications. |
|
Error Handling Rule |
Disabled; the column does not display data because the property does not apply to notifications. |
The following tasks apply to Events-based notifications, not Default notifications.
This is the procedure to create a Notification mask. It can then be named by a Subscriber mask that binds it to an Event mask to become a complete Events-based notification.
To create a Notification mask:
Under System Settings, double-click Notifications. The Notifications window appears.
Click New.
Enter a name in the Name field.
Enter a name or click the AutoNumber button to generate the required API name.
For the required Object Type field, choose a Base Class, Class, or Subclass type of object.
Click Next.
Set the Enabled field to Yes or No.
Set Priority to High, Low, or Regular.
In the From field select from the drop-down list of the available values for the object type selected, such as $AGILE or $CHANGEANALYST, depending on Base Class, Class, or Subclass.
In the required To field select from the Address Book of Users and User Groups who the notification will be sent to.
Set the Notification Type as Email, Email and Inbox, or Inbox only.
To insert a data tag (or data variable) into the Subject or Body field, click Add Data Tag. For more information, see "Entering Subject and Body Text."
Click Finish.
Notification masks can be deleted only if they are not used by Subscribers. Default notifications cannot be deleted; they can be enabled and disabled.
To delete a user-defined notification:
Under System Settings, double-click Notifications. The Notifications window appears.
Use the filter to find the specific notification you want to delete.
Select the notification and click Delete.
You can also double-click the notification and then click Delete. By doing so, you can look through the settings and properties to be sure you want to delete the notification.
|
Note: If you delete a Notification mask that has already sent notifications to users, then the subject of the notifications in the users' inboxes will change to appear as null, reflecting that the notification is deleted. |
SDK and Scripting enables notifications to be sent out programmatically. A notification invocation uses the following parameters, whose use is explained:
SendNotification – the program module or method used to send out a notification.
Notification Name – the name of the notification.
Urgent – whether the notification is to be flagged as Urgent or not; the value can be True or False.
Addressee List – list of users who may be notified; this set of values is appended to the list of people listed in the "To" field of the notification. This list of Addressees is only picked up if $NOTIFY is assigned in the "To" field.
Comment – refers to the comment passed to the Comment data tag, if assigned in the notification template.
Object – an object of the type corresponding to that associated with the notification in its definition. For example, an ECO object must be passed to a notification tied to a notification associated with the ECO subclass (it can also be passed to a notification tied to the Change Orders class or Changes base class). This object is used to derive the values of variables used in the notification Subject, Body, and To fields.
For more information about sending notifications using Agile SDK, see Chapter 9, "Subscribing to Agile PLM Objects" in the Oracle Agile PLM SDK Developer's Guide.
The following tasks apply to both Default notifications and Events-based notifications.
To edit a notification:
Under System Settings, double-click Notifications. The Notifications window appears.
Filter the notifications by Name or Object Type.
Double-click the name of the notification you want to edit. Its window appears.
Edit the attributes in the appropriate manner: select from a drop-down list or enter text. Refer to the table found above.
To insert a data tag (or data variable) into the Subject or Body field, click the Add Data Tag button. See "Entering Subject and Body Text."
Click Save.
Subject and Body fields are required to be populated. Each Default notification includes text for the subject and body of the message. You can use the default text, or you can enter a text message that you want to use.
During the editing or creation of a notification, when you enter the text you want to appear in the subject line and body of the notification, you can add data tags that refer to pertinent information for that notification.
The available tags are dictated by the object type associated with the notification.
For example, for an ECO Status Promotion, Approvers and Change Analyst notification, you might want the subject line to say:
[Cover Page.Change Type] [Cover Page.Number] has been moved from [From Status] to the [To Status] of [Cover Page.Workflow] workflow.
To include the From Status in the subject line:
Click to position the cursor in the appropriate place in the subject message.
Select From Status in the Data field drop-down next to the Subject field.
Click Add Data Tag. The data tag [From Status] appears in the Subject field.
As you continue to enter text in the subject line, you can add more data tags.
Similarly, use the Data field next to the Body field to add data tags to the body text.
From existing notifications you can perform a Save As function to create a new notification with a new name and configure the values according to your needs.
|
Note: All Default notification templates that are not bound to an object type (for example, Transfer Authority, Create, or Modify) and those for Product Cost Management cannot use the Save As feature. |
When you create a notification using Save As, the object type of the original notification cannot be changed for the new one. The new notification is automatically associated with the object type of the original notification.
This is the only way a Default notification can be recast as a Notification mask and be used as an Event-based notification.
Also, if the source notification is a Default notification, then the To field in the new notification is unpopulated and can now be selected.
To create a new notification using Save As:
From an open notification click Save As.
Enter a new name and autogenerate the API Name.
On the General Information tab enter a To recipient.
Click Save.
Use the instructions in "Editing a Notification" to tailor the new notification as desired.
