Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

E35415-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

10 About Notifications

This chapter describes Oracle Communications Order and Service Management (OSM) event notifications and jeopardy notifications.

About 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:

Figure 10-1 shows notifications displayed in the Task Web client. You can specify which workgroups can see the notifications.

Figure 10-1 Notifications Displayed in the Task Web Client

Shows notification in the Task Web client.

About Notification Priority

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.

About Sending Notifications in Email

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.)

About Using Order Rules in Notifications

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.

Figure 10-2 Rule Example

Shows a rule example.

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.

About Using Notifications to Run Automation Plug-Ins

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.

About Configuring Notifications

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 can model automation plug-ins as you define notifications, but modeling automation plug-ins before you configure notifications is more efficient.

Strategies for Using Notifications

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.

About Jeopardy Notifications

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:

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 use two methods to trigger a jeopardy notification:

To trigger a notification, OSM follows this process:

  1. 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.

  2. 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.

  3. 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.

About Jeopardy Notification Conditions

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.

Specifying Jeopardy Notification Conditions for an Order

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.

Specifying Jeopardy Notification Conditions for a Task

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.

Example of a Jeopardy Notification

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-3 Jeopardy Notification in Design Studio

Shows jeopardy notification in Design Studio

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-4 Jeopardy Conditions in Design Studio

Shows jeopardy conditions in Design Studio.

Figure 10-5 shows the roles defined for receiving email about the jeopardy notification.

Figure 10-5 Jeopardy Notification Roles in Design Studio

Shows jeopardy notification roles in Design Studio.

Figure 10-6 shows the configuration for the polling used for the jeopardy notification. In this case, OSM polls every hour.

Figure 10-6 Jeopardy Polling in Design Studio

Shows jeopardy polling in Design Studio.

About Event Notifications

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:

About Using Task Transitions to Trigger Event Notifications

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.

Figure 10-7 Event Notification Based on Task Transition

Graphic is described in surrounding text.

The event notification for a status change works as follows:

  1. 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.

  2. 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.

About Using Task States and Rules to Trigger Event Notifications

An event notification triggered by a task state change and rules works as follows:

  1. 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.

  2. 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.

Figure 10-8 Notification Based on Task State and Rule

Graphic is described in surrounding text.

You can specify an automation plug-in that the notification runs; however, an automation plug-in is not required.

About Using Task States to Trigger Automated Event Notifications

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:

  1. When the task reaches the Assigned state, a notification is created.

  2. 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.

Figure 10-9 Event Notification Based on Task Status

Shows an even notification in Design Studio.

About Using Order Milestones to Trigger Event Notifications

You can use an order milestone to trigger an event notifications. Figure 10-10 shows an event notification based on an order milestone.

Figure 10-10 Event Notification Based on an Order Milestone

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:

  1. After all tasks within a process successfully complete for an order, the order Completion milestone is reached and a notification is created.

  2. 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.

About Using Order Data Changes to Trigger Notifications

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.

Figure 10-11 Event Notification Based on Data Change in an Order

Shows an event notification based on data change in an order

Summary of Notification Functionality

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