| Oracle® Communications Order and Service Management Concepts Release 7.2.2 Part Number E35415-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Order and Service Management Concepts Release 7.2.2 Part Number E35415-02 |
|
|
PDF · Mobi · ePub |
This chapter describes Oracle Communications Order and Service Management (OSM) event notifications and jeopardy notifications.
You can use notifications to alert users and external systems to events that occur in the order process or to tell users that an action must be carried out.
There are two types of notifications:
Use jeopardy notifications when you want to alert users that an order might have a problem. To trigger jeopardy notifications, OSM checks order or task conditions at specified intervals. If an action has not occurred as expected, OSM sends a notification. Jeopardy notifications are displayed in the Task Web client Notifications page. See "About Jeopardy Notifications" for more information.
Use event notifications to alert users of changes to the order based on its progress. Event notifications are based on changes that occur to an order. Event notifications based on a change to order data are displayed, but event notifications generated by order milestones and changes to task status are not displayed. See "About Event Notifications" for more information.
Figure 10-1 shows notifications displayed in the Task Web client. You can specify which workgroups can see the notifications.
You can specify a priority for most types of notifications. For example:
Notifications can be prioritized to control how they are sorted in the Task Web client. You should prioritize Jeopardy notifications higher than information messages.
Prioritizing notifications sent to external systems helps those systems process the more important notifications first.
OSM evaluates notifications with the highest priority first (1 is the highest priority). For notifications that are sent to external systems, the notification priority represents the JMS queue priority.
You can deliver notifications in email. The email message consists of the same information that is displayed in the Notifications window in the Task Web client. You cannot customize the message or add information to it. The message template is:
You have a notification for Order ID ID number and notification ID notification ID. Use the following URL to connect to the notification details: url
For most types of notifications, you specify to send email by selecting a checkbox in the notification configuration. For event notifications that are used only for running an automation plug-in, you configure the automation plug-in to send the email. See OSM Developer's Guide for information about automation.
To specify who to send the email to, you do the following:
When configuring the notification in Oracle Communications Design Studio, or in your automation plug-in, specify the roles that receive the notification.
Configure the email recipients for the roles by using the OSM Administrator application. (Roles are called workgroups in OSM Administrator.)
All jeopardy notifications and most event notifications use order rules to determine if the notification should be triggered. (Event notifications that are used only for running an automation plug-in do not use order rules.)
Figure 10-2 shows an example of a rule defined in Design Studio. This rule finds the city that the customer lives in and the type of account, (Business or Residential).When the jeopardy notification uses this rule, the notification is sent only if the order came from a residential customer in Sao Paulo.
You can use rules such as the one shown in Figure 10-2 to route notifications to specific roles. For example, you can combine rules and roles as follows:
Table 10-1 Example Rule and Role Combinations
| Notification Type | Triggered By | Rule Specifies | Sent to Role |
|---|---|---|---|
|
Notification_Residential |
Expected duration exceeded |
Residential account |
Residential |
|
Notification_Business |
Expected duration exceeded |
Business account |
Business |
In this example, two identical notifications are created, both triggered by the order processing time exceeding the expected duration. If the order is for a residential account, the notification is triggered and sent to the role that handles residential accounts.
OSM uses a system-based null_rule. This rule always evaluates to true. Therefore, if you do not specify a rule for a notification, the null_rule is used; because it is set to true, the notification is triggered. If you do not specify any conditions to trigger the notification, and the notification uses the null_rule, the notification is triggered every time it is polled.
Note:
The polling interval cannot be changed at run time.See "About Order Rules" for more information about rules.
All types of notifications can run automation plug-ins to send the notification to an external system. For example, you can trigger a notification that runs an automation plug-in that sends a message that a task has completed to the order-source system. An automation plug-in can also perform custom logic, update an order, send email, and send a message to display on the Task Web client Notifications page.
An automated notification triggers a specific automation plug-in when a notification is created in OSM, which can occur several different ways depending on the notification definition, such as a task reaching a specified state or an order reaching a specified milestone. An automated notification receives a message internally from OSM, and the information contained in the message is made available to the automation plug-in. The automation plug-in can then use that information to perform custom logic, update an order, or send a message to the OSM Notifications page, to a user email address, or to an external system. Automated notifications are not capable of receiving external messages back from an external system.
Automations use OSM roles to restrict who can receive the notification. If the notification is sent to an external system by using an automation plug-in, ensure that you include the role whose credentials are used when running the automation plug-in.
Automation plug-ins run by notifications are always defined as internal event receivers because notifications are used to notify OSM users or other areas of the OSM system of something happening within OSM. To notify users on external systems, you need to configure an automation plug-in.
When you use automation plug-ins, you configure the automation plug-in properties; for example, the automation type and the event type. See OSM Developer's Guide for more information.
You define notifications when you model orders, tasks, and processes. There is no OSM notification entity, so you cannot model notifications and reuse them.
Before you configure notifications, you need to configure the following entities:
You must create the roles to assign notifications to.
To trigger notifications based on a change to order data, you must first model the data. See "About Using Order Data Changes to Trigger Notifications" for information.
You can model automation plug-ins as you define notifications, but modeling automation plug-ins before you configure notifications is more efficient.
Some common uses for notifications are:
In general, jeopardy notifications are used for alerting order management personnel about something that should have happened but did not happen. By contrast, event notifications are based on events that have happened, and they are used more for communicating status information and for directing the order fulfillment process to the next step.
Communication with external systems is usually handled by automation plug-ins run by event notifications. For example, the progress of an order is typically monitored in external systems by tracking which parts of the order have been completed. To communicate that, you typically configure event notifications based on a change to order data or a change to task status.
Notifications intended for an internal audience (OSM users) are typically created using a notification type that, by default, sends a notification to the Task Web client. The only notification types that do not are event notifications based on order data change and task state change notifications that run an automation plug-in. See "About Using Task States and Rules to Trigger Event Notifications" for more information.
A jeopardy notification is a message that is sent to OSM users or users on other systems (for example, to return status to a CRM system). Jeopardy notifications are not event-driven; they use polling at specified intervals to identify processes or tasks in jeopardy.
OSM uses three methods to deliver jeopardy notifications:
By displaying a notification in the Task Web client.
By sending email to users.
By using an automation plug-in to notify an external system. Each order jeopardy notification can map to one automation plug-in.
Jeopardy notifications can be defined for an order or for a task. Many of the jeopardy properties are the same for orders and tasks; for example, you can specify the roles to notify and the rule to trigger the notification. However, defining a jeopardy for an order or a task allows you use the order or task properties. For example:
You can trigger a notification based on the state of the order.
You can trigger a notification if a task has exceeded its expected duration.
You can use two methods to trigger a jeopardy notification:
Conditions; for example, if the order processing time has exceeded the expected duration.
Order rules; for example, you can define an order jeopardy notification based on a rule that evaluates the data condition orderMilestone <>completion and dueDate>SpecifiedDate. This checks to see if there are any orders that are not completed but that are supposed to be completed by today.
To trigger a notification, OSM follows this process:
OSM polls in-flight orders and tasks to determine if a condition has been met. For example, the condition might be that a task has been in progress for longer than one hour. If the condition is met, OSM begins to process the notification.
OSM checks to see if there are any rules that might restrict the notification from being triggered. For example, you might configure two types of jeopardy notifications, one that is triggered for orders from only business accounts and one that is triggered for orders from only residential accounts. Each notification might have a different email recipient, so the notification is only triggered for the correct recipient.
If the rule evaluates to true, the notification is triggered.
You can specify how often OSM should poll to re-evaluate the jeopardy condition. You can specify a polling interval in hours, days, weeks, or months. You can specify the day of the week (for example, Monday), or the day of the month (for example, the first day of the month). You can specify a date and time for OSM to begin polling. The default is the current date.
Tip:
When configuring notifications, consider the performance impact from polling for jeopardy notifications. For example, a configuration that polls every minute on one million orders has a much greater performance impact than polling every hour on one thousand orders.You can trigger jeopardy notifications based on an order or task condition. For example, you can specify to send a jeopardy notification if a task has exceeded its expected duration.
The conditions you can use are different, depending on if you define the jeopardy notification in an order or in a task.
When you define an order, you can specify to trigger a jeopardy notification based on the following:
The number of days that an order has been in the In Progress state. For example, you can trigger a notification if the order has been in the In Progress state for longer than 30 days.
The number of days that an order has been in the Completed state. For example, you can trigger a notification if the order has been in the Completed state for longer than 30 days.
If the process duration has exceeded the expected duration. The value is based on elapsed time, regardless of the order states that the order might transition in and out of.
If the process duration has exceeded a duration that you define; for example, five days. This duration value starts at the creation task.
To determine the duration that the order has been in any of these conditions, OSM polls the system at an interval that you define.
When you define a task, you can specify to trigger a jeopardy notification based on the following:
If the process that the task is associated with has exceeded the expected duration.
If the process that the task is associated with has exceeded a duration that you define. This duration is measured starting with the creation task.
If the task has exceeded the expected duration.
If the task has exceeded a duration that you define.
If the order has exceeded a specified amount of time past when it was received (when the order is created in OSM).
To determine the duration that the order has been in any of these conditions, OSM polls the system at an interval that you define.
When you define a jeopardy notification in a task, and the task can have multiple instances, you can specify if the notification should be triggered for every task instance.
In this example, the order processing for a service requires that a customer service manager enter payment information. This has been configured as a manual task. It is expected that the task can be and should be completed quickly. Therefore, a jeopardy notification is configured that triggers if the task is in the Received state for longer than one hour.
Figure 10-3 shows the configuration for a jeopardy notification in Design Studio. This jeopardy notification sends an email notification to members of a workgroup.
Figure 10-4 shows the conditions under which the jeopardy notification is triggered. In this case, the given notification specifies to trigger notification if the task has been in the Received state for longer than one hour.
Figure 10-5 shows the roles defined for receiving email about the jeopardy notification.
Figure 10-6 shows the configuration for the polling used for the jeopardy notification. In this case, OSM polls every hour.
Event notifications are triggered by events. You do not specify polling intervals for event notifications. You can configure them to occur in the following cases:
When a task transitions through a task status. For example, you might trigger an event notification when a task transitions to the Failed status.
Event notifications triggered by transitions can be sent to a workgroup. See "About Using Task Transitions to Trigger Event Notifications" for more information.
When a task reaches a specified state. You can use two methods:
You can use the task state to trigger an automated event notification. In this case, only the task state is evaluated (no rules are applied to evaluate a condition), and the notification runs an automation plug-in that handles the notification actions. For example, when a task reaches the Assigned state, you can automate an external lookup before allowing the workflow to continue. You do not specify roles or email delivery for the notification. See "About Using Task States to Trigger Automated Event Notifications" for more information.
You can use the task state in combination with rules to trigger the event notification. In this case, you can specify a rule to evaluate conditions, the priority, if the notification can be delivered by using email, and the workgroups that receive the notification. See "About Using Task States and Rules to Trigger Event Notifications" for more information.
When you use the task state to trigger an automated event notification, the notification is run from all processes that include the task. When you configure a notification based on a task state change in a process, the notification is applicable only to the task within the process in which it is defined.
You can trigger an event notification when an order passes an order milestone. You use this type of notification to trigger an automation plug-in that handles the notification actions. You do not specify roles or email delivery for the notification. See "About Using Order Milestones to Trigger Event Notifications" for more information.
You can trigger an event notification when a change is made to order data. You typically use these notifications to update external systems (such as a CRM) with information about the progress of the order when a specific data element in the order data is changed. See "About Using Order Data Changes to Trigger Notifications" for more information.
An event notification based on a task transition does not apply to all instances of the task. It applies to a task only as it is used in a specific process. Therefore, to configure an event notification based on a task transition, you edit the process that includes the transition and apply the event notification to the transition. Figure 10-7 shows the configuration for a success transition in Design Studio. In this figure, the success transition is selected, and the event notification properties are defined below the process window.
The event notification for a status change works as follows:
When the task status changes to the status that you define for the notification, the notification runs a rule to evaluate if the conditions are true.
If the conditions are true, the event notification is triggered.
When you use a task transition to trigger an event notification, you can specify an automation plug-in that the notification runs; however, an automation plug-in is not required.
An event notification triggered by a task state change and rules works as follows:
When the task state changes to the state that you define for the notification, the notification runs a rule to evaluate if the conditions are true.
If the conditions are true, the event notification is triggered.
For example, you can specify that when the Completed task state is reached, a rule evaluates if the billing address is in California.
This type of notification does not apply to all instances of the task. It applies to a task only as it is used in a specific process. Therefore, you create this type of notification when you create processes in Design Studio. Figure 10-8 shows how to assign an event notification to a task in a process. In this figure, the EnterAccountInformation task is selected, and the rule and state are defined in the window below.
You can specify an automation plug-in that the notification runs; however, an automation plug-in is not required.
You can use a task state to trigger an automated event notification. In this case, only the task state is evaluated (no rules are applied to evaluate a condition), and the notification triggers an automation plug-in which handles the notification actions. This type of notification runs for every instance of the task, independent of the process that it is in. Event notifications triggered by task states are not displayed in the Task Web client.
For example, you can define an automated notification that sends a notification when the task reaches the Assigned state. The event notification works as follows:
When the task reaches the Assigned state, a notification is created.
When the notification is created, the automation plug-ins run.
Figure 10-9 shows an event notification configured in Design Studio. Any time this task runs, the event notification is triggered when the task reaches the Completed state.
You can use an order milestone to trigger an event notifications. Figure 10-10 shows an event notification based on an order milestone.
Only the order milestone is evaluated (no rules are applied to evaluate a condition), and the notification triggers an automation plug-in that handles the notification actions. Each event notification maps to one or more automation plug-ins. Event notifications triggered by order milestones are not displayed in the Task Web client.
For example, you can define an event notification that specifies the Completion milestone. The event notification works as follows:
After all tasks within a process successfully complete for an order, the order Completion milestone is reached and a notification is created.
When the notification is created, the automation plug-ins run.
Note:
You cannot define custom order milestones. Order milestones are based on order states; for example, the Completion milestone occurs when the order transitions to the Completed state.When you create event notification that is triggered by an order milestone, you specify the order milestone that triggers the notification. You can use the following order milestones:
Creation: The order was created in the OSM system.
Completion: The final task in the order has completed, and the order transitioned to the Completed state.
Deletion: The order was removed from the OSM system by transitioning to the Deleted state.
Exception: A process exception or fallout was initiated.
State change: The order transitioned to a different state.
You define event notifications based on order data changes when you create orders in Design Studio. For example, you can define an event notification that sends a notification when a telephone number is entered. Event notifications triggered by data changes are shown in the Task Web client.
When you create an event notification based on order data changes, you can specify the data field that triggers the notification when the data is changed. Any change to the field causes the notification to trigger. However, this value is not evaluated for content. To trigger the notification based on the value of the data, you must configure a rule to evaluate it.
For example, to trigger a rule when the billing address is changed to California, you specify the billing address field as the field that triggers the notification and run a rule that evaluates if the address was changed to California.
You can specify an automation plug-in that the notification runs; however, an automation plug-in is not required.
Figure 10-11 shows an event notification based on data change in an order. In this example, when a credit card number changes, the notification is triggered.
Table 10-2 shows a summary of notification functionality.
Table 10-2 Summary of Notification Functionality
| Notification Type | Sends Email | Displays in Task Web Client | Can Be Evaluated By a Rule | Can Be Sent to Different Roles | Runs Automation Plug-in | Has a Priority |
|---|---|---|---|---|---|---|
|
Jeopardy - Task |
Yes |
Yes |
Yes |
Yes |
Optional |
Yes |
|
Jeopardy - Order |
Yes |
Yes |
Yes |
Yes |
Optional |
Yes |
|
Event - Task status |
Yes |
No |
Yes |
Yes |
Optional |
No |
|
Event - Task state, automation |
Sent by automation plug-in only |
No |
No |
Defined by automation plug-in only |
Mandatory |
Yes |
|
Event - Task state, in a process |
Yes |
No |
Yes |
Yes |
Optional |
Yes |
|
Event - Order milestone |
Sent by automation plug-in only |
No |
No |
Defined by automation plug-in only |
Mandatory |
No |
|
Event - Order data change |
Yes |
Yes |
No |
Yes |
Optional |
Yes |
|
 Copyright © 2009, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
