Understanding Oracle Service Fulfillment Manager

This chapter covers the following topics:

• Overview of Oracle Service Fulfillment Manager
• Service Order Requests in Oracle Service Fulfillment Manager
• Why SFM Orders Fail
• Ways to Resolve Failed Orders
• System Notification Types
• The Order Resubmission Utility
• The Event Manager
• Queues in Oracle Service Fulfillment Manager
• The Oracle Service Fulfillment Manager System Queues
• The Queue Console
• Understanding Network Adapters
• The Network Adapter Types
• Adapter Commands
• Adapter Modes
• Network Adapter Management
• The Connection Manager
• Fulfillment Element Types in Oracle Service Fulfillment Manager
• Fulfillment Elements in Oracle Service Fulfillment Manager
• Understanding Services
• Work Items in Oracle Service Fulfillment Manager
• Understanding Packages
• Understanding Notifications
• The Notifications Utility
• Messaging in Oracle Service Fulfillment Manage
• Message Elements
• Message Processing Logic
• Message Processing Logic - Guidelines
• Timers in Oracle Provisioning
• Timer Usage in Oracle Provisioning
• Using Timers in Workflow
• Activity Timers in Oracle Service Fulfillment Manager
• Process Timers in Oracle Service Fulfillment
• Message Timers in Oracle Service Fulfillment
• Workflow in Oracle Service Fulfillment Manager
• Workflow Processing of a Service Order Request
• The Workflow Monitor
• Understanding the Procedure Builder

Overview of Oracle Service Fulfillment Manager

One of the primary functions of the Oracle Service Delivery Platform is to supply telecommunication providers, ISPs (Internet Service Providers) and similar vendor companies with the ability to manage the critical business functions of order capture and order activation, network administration and operation.

The Benefits of Oracle Service Fulfillment Manager

Oracle Service Fulfillment Manager provides the following benefits:

• A fully automated, nearly real-time activation of services for multiple network elements in a multi-vendor network environment.

• A number of APIs (Application Program Interfaces) that you can use as building blocks in creating an interface to any Operational Support System (OSS) available on the service provider's network. For example, you can use these APIs to create an interface to an external order entry or customer care system.

Features of Oracle Service Fulfillment Manager

Oracle Service Fulfillment Manager is designed to be an integrated management system that acts as the coordinating link between different external systems. It supports the following features:

• The rapid deployment of new services by integrating the functions of service management with the network details (service attributes, Service Fulfillment Manager algorithm, fulfillment element).

• The Service Fulfillment Manager of multiple technologies (e.g., ATM, ADSL, Switch, Routers)

• The delivery of complex services requiring configuration of multiple fulfillment elements and OSS (Operational Support Systems) interfaces.

• The delivery of bundled services combining voice, data and video products.

Service Order Requests in Oracle Service Fulfillment Manager

Oracle Service Fulfillment handles a typical service order request by performing the following tasks:

1. Capturing a service order request

2. Validating the order

3. Analyzing the order

4. Fulfilling the order

5. Completing the order

   And, if necessary,

6. Managing order fallout

Capturing a Service Order Request

Initially, a customer places an order with the carrier for a telecommunication service. Examples of services could be one or a combination of phone lines, internet connections and wireless access.

Customer orders are captured from an external Order Entry (OE) system. If necessary, customer orders can also be input through the Service Fulfillment Manager screens. However, the primary capture process is through the Oracle Service Fulfillment Manager APIs.

Validating the Order

After the service order is captured by the system (or manually entered, as the case may be), it is examined for validity by the system. If an order fails validation, OP returns an appropriate message indicating such errors to the order originator. Failed orders due to validation errors are not processed further in Oracle Service Fulfillment Manager.

Order validation includes the following:

• Verifying the order syntax

• Verifying the inclusion of mandatory parameters

• Verify that necessary dependent information is also included

• Verify that the supplied dates are valid dates

Analyzing the Order

After an order is captured, Oracle Service Fulfillment Manager performs the following steps:

1. Analyzes the order.

2. Breaks it down into the required set of tasks needed to fulfill the order.

3. Orders the tasks so that they will be performed in the proper sequence.

For example, say the new order requires two new lines to be activated at a customer residence, one an analog voice phone line, the other a digital ISDN line to be used for high-speed Internet access. In addition, each separate line is to have a different bundle of services associated with it. The analog line must have basic voice service, as well as the Caller ID and Call Waiting features. The digital line needs to have a connection established to the desired ISP (Internet Service Provider).

After order capture, Oracle Service Fulfillment Manager analyzes and validates the order, then puts the order steps into sequence. While some of the tasks involved in setting the customer order can be performed in parallel, others must be performed in a definite sequence. In this example, basic voice service must be established on the analog line before the additional features can be implemented.

Fulfilling the Order

Order fulfillment in Oracle Service Fulfillment Manager is accomplished through one of two ways:

• OP performs the requested tasks internally.

• OP directs external systems to perform the tasks involved in setting up the order.

Oracle Service Fulfillment Manager first translates these tasks into network language, and then activates the various network elements needed to complete the tasks.

For example, it can:

1. Request configuration and activation of services on specific switches. (Connections to the needed network elements are managed using the Connection Manager.)

2. Notify the OSS (Operational Support Systems) to commence service.

The tasks involved in setting up an order are managed via workflow. Workflow is either internal to Oracle Service Fulfillment Manager or external to it.

• Internal workflow is the default, or standard workflow delivered with the application.

• External workflow is created by the user, and is integrated with the standard workflow delivered with the application. For example, you write the business process logic (the executable code) to retrieve data from outside the Service Delivery Platform database. (This could be, for example, the telephone number function for a network switch.)

These workflows are user-configurable to match company specific business practices.

Note: Oracle Service Fulfillment Manager can also handle the results of the network elements through its generic fulfillment engine.

Completing the Order

If the service order completes:

• Successfully

  The system sends a notification message of success to the Event Manager that includes both the internal and external order IDs for the order as well as the services it provisioned. This includes all the subscriber details (service assignments, parameter values and product attributes). All activation information, updates and modifications performed on the service order request are captured.

  The Event Manager then publishes the event that the service order request completed successfully. The status of the order is changed to COMPLETED.

• Unsuccessfully

  Oracle Service Fulfillment Manager suspends the Service Fulfillment Manager process after the first error occurs. It then creates a notification message with the error information and sends the message to the Notifications utility. The order remains open, but the status is changed to indicate that the order has been suspended. The Service Fulfillment Manager process can not continue until the error is rectified.

  To continue processing, you must modify the order via the Notifications utility interface and re-submit the order to the Service Fulfillment Manager process where the error occurred.

Managing Order Fallout

Order Service Fulfillment Manager can fail during the Service Fulfillment Manager process due to invalid activation information, or perhaps the unavailability of a needed network element.

Oracle Service Fulfillment Manager provides a number of ways to effectively manage the order fallout process through its Notifications utility.

You can, for example:

• Examine order details and drill down to error messages

• Track the progress of problem resolutions through the system

• Initiate action to reconfigure a service, if needed

• Generate a notification and forward the notification to the Trouble Ticket system and/or Work Force Managements

• Confirm that the order trouble has been cleared

Why SFM Orders Fail

Order fulfillment can fail during the Service Fulfillment Manager process due to the following factors:

• Invalid orders: Orders that fail the order validation process may require escalation to the order entry or customer service groups. In such cases, the Notifications utility serves as a tracking and notification mechanism.

• Bad or missing data: Incorrect or missing data can cause order fallout.

• Fulfillment action problems: Fulfillment elements may not function properly, or be too busy, or unavailable, so the system rejects the service activation command.

• Time-outs on orders: The connection session between the application and the fulfillment elements may time-out due to either application or external errors. Orders that have timed out may have been partially completed prior to the time-out.

• Network element or service configuration problems: The new service order may conflict with the current subscriber configuration. This may be the result of invalid orders. However, there may be other reasons, such as improper configuration of the customer.

Ways to Resolve Failed Orders

You use the Notifications utility to track, monitor and resolve failed orders.

The table following details some of those ways that you can resolve failed orders.

Ways to Resolve Failed Orders

Action	Description
Retry Failed Orders	You can re-send failed orders in one of the following ways: Modify parameters in the failed order and re-send the order down to where the failure occurred, and then continue processing. Re-send unchanged order down to where the failure occurred in the Service Fulfillment Manager process. (Failure may have been due merely to network problems.) Restart the Service Fulfillment Manager workflow from the point where it failed or stopped.
Stop Processing Failed Orders	You can stop the workflow processing of an order that is due for Service Fulfillment Manager. This is useful in the case of identified network outages and order processing backlog.
Terminate Failed Workflows	You can completely terminate processing an order if an exception state is encountered.
Resolve Failed Workflows	You can correct the error in the order Service Fulfillment Manager workflow (from within the Notifications utility).
Escalate Failed Workflows	You can escalate a failed order notification by forwarding it to another user or group in order to troubleshoot the order.
Re-assign Failed Workflows	You can reassign a failed order to another user or group for resolution.

System Notification Types

Notifications are generated by various events and at various stages in the Service Fulfillment Manager process. Example events are:

• Recovery daemons

• Service Service Fulfillment Manager process failure

• Internal exceptions

Notification types

The workflow produces two distinct types of notifications:

• Informative notifications

  The system generates these notifications if the Service Delivery Platform system detects a stopped fulfillment element manager process and starts it up automatically. Also, the system generates a notification if an internal problem occurs that requires a system administrator's attention.

• Order fallout notifications

  The system generates these notification for failed orders.

The Order Resubmission Utility

You use the Resubmission Utility to force the system to re-run an order on a particular fulfillment element. However, only those orders which have either completed, or have been previously submitted, on the fulfillment element in question, can be resubmitted. This is useful, for example, in the event that a network switch fails or experiences a service disruption, causing a Service Fulfillment Manager order to fail.

Through this utility, you specify a particular fulfillment element and the time window during which is was unavailable. After entering the required information, fulfillment elements re-execute the fulfillment actions as scheduled. A Job ID is generated and the progress of the re-submission can be tracked.

Re-submitted Orders and Fulfillment Actions

Successful re-execution of the fulfillment action requires that the adapters run in this mode.

• If there are no available adapters and the fulfillment element adapter maximum has not been reached, then an error message is generated.

• If no adapters can be started, all re-submission requests are queued.

• Re-submitted fulfillment actions can be identified in the Order Flowthrough window using the Resubmitted check-box.

Re-submitted Orders and Notifications

Re-submitted orders execute the same fulfillment procedure as the original orders.

• These re-submitted orders can generate notifications based on the fulfillment procedure logic.

• Any generated notification message includes the Job ID.

The Event Manager

The Event Manager handles incoming and outgoing messages within the Oracle Service Delivery Platform. The Event Manager provides a set of APIs that are used by both internal and external systems to register for messages.

• Incoming messages are frequently a response to a previously initiated message from an external or internal system

• Outgoing message are frequently user-defined notifications informing an external or internal system of an event occurrence.

Message Registration

External applications can send request messages to the Event Manager, if they are registered for that message. External applications can also register for response messages.

Inbound Messages

The Event Manager identifies the subscriber and delivers an incoming message to the registered applications. The following sequence of steps is performed automatically. The Service Delivery Platform:

• Picks up the message from the Incoming Queue

• Pulls the message out of the Incoming Queue and into the Event Manager

• Validates the message structure via the Event Manager

• Verifies if any internal or external subscribers are registered for this message

• Executes the user-defined logic

• Delivers the message to all registered application systems

Processing Logic

External systems can define their own processing logic at the time when validation and processing logic are defined. If no application has registered for a message, the application uses the default processing logic after message validation.

Queues in Oracle Service Fulfillment Manager

In Oracle Service Fulfillment Manager, a service order request is often queued in one of the many internal system queues between different stages in its processing.

As the Service Fulfillment Manager of an order progresses, the order moves sequentially through the various system queues as part of the fulfillment process. For example:

• Incoming orders are moved to the Orders Pending queue if scheduled for later Service Fulfillment Manager

• Orders are transferred from the Orders Pending queue to the Orders Ready queue as the Service Fulfillment Manager date occurs.

The table following describes the queues in use in the Oracle Service Fulfillment Manager system.

Oracle Service Fulfillment Manager Queues

Queue	Contains
Orders Pending	Orders waiting for a Service Fulfillment Manager date to occur
Orders Ready	Orders that are ready to be provisioned immediately
Work Item	Work items for orders currently being processed (Work items are a logical grouping of fulfillment actions.)
Fulfillment Actions
Wait for FE Channel	Fulfillment actions waiting for one of the channels configured for the fulfillment elements to becomes available
FE Ready	Fulfillment actions associated with each fulfillment element that are ready to be executed
Outbound Messages	Messages sent by Oracle Service Fulfillment Manager
Inbound Messages	Messages received by Oracle Service Fulfillment Manager
Event Manager	Events which occur internally in Oracle Service Fulfillment Manager

The Oracle Service Fulfillment Manager System Queues

As an order moves through the system, it progresses from queue to queue in a sequential manner. Typically, this progression moves through the system queues in the following order.

• Order Pending Queue

• Order Ready Queue

• Work Item Queue

• FA Queue

And additionally, the following queues are used as necessary

• FE Ready Queue

• Wait for FE Channel Queue

Order Pending Queue

The Process Order API moves the order into the Order Pending queue. The order stays in the pending queue until the date set for Service Fulfillment Manager. This date can be passed to the Service Delivery Platform as part of the order.

On the Service Fulfillment Manager date the order is moved to the Order Ready queue. If an order does not contain a Service Fulfillment Manager date, the default date becomes the current date and the order is moved immediately to the Order Ready queue.

Order Ready Queue

The Order Ready queue holds orders that are ready to be provisioned immediately. The order is dequeued from the Order Ready queue and the work items generated by the work-plan are placed on the work item queue.

Work Item Queue

The work item queue is used to manage the execution of work items.

Processing the work item involves the following:

• Checking the configurator for existence of fulfillment actions mapped to the work items.

• Determining if the work item is a regular Service Delivery Platform work item or a user-defined workflow.

The following then occurs:

• In the case of regular work items, the fulfillment actions are enqueued into the FA Queue in the sequence specified.

• For user-defined workflows, the execution of the fulfillment actions is determined by the user-defined workflow. (Users can drag and drop EXECUTE_FA activities into their workflows based on the business process being implemented.)

  Note: At this point, the Service Delivery Platform does not know which fulfillment elements need to be provisioned.

FA Queue

The FA Queue is used to manage the execution of fulfillment actions for regular (on user-defined) work items.

Processing the fulfillment actions involves the following:

• Checking the configuration to determine to which fulfillment element the fulfillment procedure must be sent.

• Checking for the availability of an adapter for the fulfillment element.

The following then occurs:

• If an adapter is available, then it is immediately used to send the fulfillment element commands specified in the fulfillment procedure.

• If all adapters for the fulfillment element are busy or none are immediately available, the fulfillment action is put into the Wait for FE channel queue.

Wait for FE Channel Queue

When an adapter becomes available, the fulfillment action waiting in the queue is moved to the FE Ready queue.

FE Ready Queue

This is a temporary holder for all fulfillment actions that are waiting for a free fulfillment element adapter. As an adapter becomes available, the fulfillment action is immediately dequeued and its fulfillment procedure executed.

The Queue Console

The Queue Console provides a set of screens that display specialized information about each internal system queue. It can also be used to track down an order and to take corrective actions to expedite the order fulfillment process.

The Queue Console provides the following information about each queue:

• State Information

• Process Information

• Entry Information

State Information

The Queue Console displays information on the state or status of each Oracle Service Fulfillment Manager queue.

• Enabled: The processors are up and running and processing orders.

• Disabled: The processors are running, but an error condition has occurred. No order is being processed.

• Suspended: The processes have been suspended manually.

• Shutdown: The processors have been shutdown manually.

Process Information

The Queue Console displays information on the processes that are registered or running for a queue.

• Processors Registered: The actual number of processors pulling or processing orders out of a queue.

• Processors Running: The actual number of orders running in a queue.

Entry Information

The Queue Console displays information the number and date of the entries in a queue.

• No. of Entries: The number of entries in the queue.

• Last Entry Date: The date when the last order entered this queue.

Understanding Network Adapters

A network adapter mediates the communication between Oracle Provisioning and the fulfillment elements.

• An adapter is a runtime instance of a fulfillment element.

• Messages to be sent and received are specified by the fulfillment element and the connection procedures executed by Oracle Provisioning workflow.

• The Service Fulfillment Manager workflow executes connect procedures for each new fulfillment element connection (provided a procedure has been defined for the particular fulfillment element).

• The Connection Manager interacts with fulfillment element connections through adapters.

Adapter Usage

The following table lists the ways that adapters are used in the Service Delivery Platform, and describes each:

Adapters Usage in the Service Delivery Platform

Usage	Description
Service Fulfillment Manager Mode	Usual mode of operation Required mode for executing a fulfillment action or fulfillment procedure. Only one fulfillment action or fulfillment procedure can be processed through an adapter execution. An adapter using this mode can service only one request at any given time.

The Network Adapter Types

You can issue commands to network adapters in one of two ways.

• You pre-define a sequence of commands for the system to perform automatically during the course of the Service Fulfillment Manager process. This is the most common method of issuing commands to the adapters.

• You issue adapter commands manually, also through the Connection Manager. However, while possible, this is not likely.

• You schedule commands to run at a future time, or times.

Adapter Commands

You can issue commands to network adapters in one of two ways.

• You pre-define a sequence of commands for the system to perform automatically during the course of the Service Fulfillment Manager process. This is the most common method of issuing commands to the adapters.

• You issue adapter commands manually, also through the Connection Manager. However, while possible, this is not likely.

• You schedule commands to run at a future time, or times.

You request (command), or schedule a request, that an adapter perform one of the following operations:

• Suspend

• Resume

• Connect

• Stop

• Startup

Suspend

This command stops the application from sending orders to be provisioned. It places service orders in a queue until the fulfillment element becomes available.

If this command is used, then the following events occur:

• The application will not send any data/commands/Service Order Requests to the connected fulfillment element.

• All service order requests that specify this adapter are stored in a job queue until the adapter is re-started.

The current status of the adapter must be Idle for this command to be available.

Resume

This command acts as a toggle to end/resume normal operations from a previous suspension.

If this command is used, then the following events occur:

• The Connection Manager sets any fulfillment element interfacing to this adapter to either Idle or Busy.

  • It sets the fulfillment element to Idle, if the job queue is empty for the adapter interfacing at the fulfillment element (meaning that no service order requests awaiting Service Fulfillment Manager use this adapter).

  • It set the fulfillment element to Busy, if there is a service order request in the Service Fulfillment Manager queue that uses the adapter interfacing to the fulfillment element.

• The application continues the Service Fulfillment Manager process, if service order requests are waiting in the job queue. The next service order request marked for processing continues its Service Fulfillment Manager course.

The current status of the adapter must be Suspended for this command to be available.

Disconnect

This command is used to close the appropriate connection. It stores the service activation order in a job queue until the connection to the fulfillment element is restored by issuing a connect request.

If this command is used, then the following events occur:

• The Connection Manager sets the adapter status to Disconnected.

• The Connection Manager places all service order requests that use this adapter into a queue until the adapter is re-connected.

The current status of the adapter must be Suspended or Idle for this command to be available.

Connect

This command is used to establish a connection to a fulfillment element so that is starts, or continues, its normal operation. Service order requests that are stored in a job queue re-start processing.

If this command is used, then the following events occur:

• The Connection Manager sets the fulfillment element to one of the following states:

  • Idle

  • Busy

  • Error

• Processing continues based on the following conditions:

  The current status of the adapter must be Disconnected for this command to be available.

  • If service order requests are waiting in the job queue, the next service order request due for processing continues its Service Fulfillment Manager course. The status of the adapter is Busy.

  • If the job queue is empty for that fulfillment element (meaning no service order requests are awaiting Service Fulfillment Manager), the status of the adapter is set to Idle.

  • If the Network Element Manager status is Error, then the connection could not be established to the Network Element, the connection procedure failed.

STOP

This command is used to close the connection to a fulfillment element by discontinuing adapter operation. Service order requests are stored in a job queue until a new adapter becomes available.

If this command is used, then the following events occur:

• The Connection Manager sets the adapter status to Shutdown.

• The Connection Manager shuts down the adapter.

The current status of the adapter can not be Shutdown or Reconnecting for this command to be available. If the status is Busy, the shut down operation does not happen immediately. The application logs a Shutdown request that becomes active upon order completion.

Start Up

This command is used to start up a new adapter and establish a connection to a fulfillment element.

If this command is used, then the following events occur:

• The Connection Manager sets the fulfillment element status to Idle or Busy.

• Order service requests start processing using the new adapter.

  • If service order requests are waiting in the job queue, then the next service order request continues its Service Fulfillment Manager course. The status of the adapter is Busy.

  • If the job queue is empty for that fulfillment element, then the status of the adapter is set to Idle.

    The current status of the adapter must be Shutdown for this command to be available.

Adapter Modes

There are two types of adapters modes. They are:

• Startup Mode

• Debug Mode

Startup Mode

There are three possible states to the Startup Mode:

• Automatic

  The adapters can be started from the command line using the xdp-ctl utility.

• Manual

  The adapters can be started only through the Connection Manager.

• Disabled

  Adapter operations are disabled unless the adapter mode is changed to either Automatic or Manual.

Debug Mode

This mode indicates the level of logging for the UNIX executable and the interactive adapter types.

• Low

  Critical activities only are logged.

• Medium

  Most of the system activities are logged.

• High

  All activities are logged.

• None

  No activities are logged except fatal errors.

Network Adapter Management

You issue requests (commands) to the adapters and schedule adapter activities through the Connection Manager.

Adapter Commands

You issue the following commands to adapters:

• Connect: Establish a connection to the fulfillment element and resume its normal operation.

• Disconnect: Close the appropriate connection and store the service activation order in a job queue until the connection to the fulfillment element is restored by issuing a connect request.

• Ftp file: Transfer a file using ftp.

• Resume: Resume normal operation.

• Stop: Close the connection to the fulfillment element by bringing down the adapter.

• Start up: Start up a new adapter and establish a connection to the fulfillment element (if any).

• Suspend: Stop Oracle Provisioning from sending any orders to be provisioned and have all service orders placed in a queue until the fulfillment element becomes available.

Adapter Scheduling

You schedule the use of adapters in one of three ways:

• Immediate: The adapter fulfills the request immediately, on the current date.

• Future: The adapter fulfills the request on a future date.

• Periodic: The adapter fulfills the request at periodic time intervals based on the supplied period.

The Connection Manager

The Connection Manager provides the means to view, quickly modify, and manage the adapters connected to each fulfillment element. Adapters maintain connectivity to each fulfillment element during service Service Fulfillment Manager.You can manage each connection for purposes such as load balancing, trouble shooting and maintenance.

You use the Connection Manager to accomplish the following tasks:

• View all the available fulfillment elements that have been configured in Oracle Provisioning

• View the total number of service order requests awaiting activation in the queue for a selected fulfillment element

• View the average time a service order request has been waiting in the queue

• View the number of adapters currently active for this fulfillment element

• View the date and time when the order entered the queue

• View the elapsed time a service order request has been in the queue

• View network problems and order flow to perform trouble shooting

• Monitor the number of adapters currently available

• Perform administrative activities on adapters

• Schedule activities for adapters

• Define a connection management schedule as needed

Fulfillment Element Types in Oracle Service Fulfillment Manager

Note: Fulfillment element types are defined by system experts only.

Fulfillment elements in Oracle Service Fulfillment Manager are grouped into logical categories. A fulfillment element type can be any of the following:

• An operating system

• An equipment platform

• A Network Element Mediation (NEM) layer

• A piece of telecommunication-specific hardware

The table following lists examples of different fulfillment element types.

Examples of Fulfillment Element Types

Item	Fulfillment Element Type
Home Location Registration (HLR) unit	Network Element
Cisco server	Server
AT&T 5ESS switch	Telephony Switch
Nortel DMS200 switch	Telephony Switch

Parts to a Fulfillment Element Type

Any service order request provisioned through Oracle Provisioning requires that the type for that specific fulfillment element be defined in the system before the fulfillment element itself is defined.

To configure a fulfillment element type, you must define the following items:

• The fulfillment element type name and details

• The software generic properties for the fulfillment element type

• The attributes of the fulfillment element type

Type Attributes

An attribute defines a property of a fulfillment element type. This can include all of the attributes with a connect/disconnect procedure. Attributes are also used to uniquely identify a fulfillment element.

Each fulfillment element inherits its attributes from its fulfillment element type. The value of an attribute is the default value defined at the level of the fulfillment element.

The attributes of an fulfillment element type defines its properties and behavior. These include the following:

• IP address

• Username

The following are additional attributes for a fulfillment element type:

• Passwords used in connection/disconnection procedures

• Software generics associated with the procedures

  Note: It is possible to configure multiple software versions (generics) for each fulfillment element type, each with a specific effective date.

All attributes are associated with a fulfillment element type or a fulfillment element.

• Each fulfillment element instance can have a different value.

• Each fulfillment element inherits attributes from its fulfillment element type.

• Adding attributes is performed at the fulfillment element type level.

  Note: Setting a value for an attribute overwrites the default value of that attribute specified at the fulfillment element type level.

Fulfillment Element Type Attribute Default Values

Oracle Service Fulfillment Manager sets default values for the following attributes:

NE_CMD_TIMEOUT

When executing commands within a fulfillment element, the default set time-out is 120 seconds.

NE_CMD_RETRY

The adapter retries the command numerous times before it times- out. A failure message is returned and the default value is set to zero retry.

NE_CMD_WAIT

Waiting period (in seconds) before retrying commands within a fulfillment element. The default value is set to zero seconds.

NE_NO_ACTIVITY_TIMEOUT

Some fulfillment elements may terminate the session, if there is no processing activity. The Service Delivery Platform allows you to set processing time to execute a command. This allows the connection between an adapter and the fulfillment element to remain active. The default processing time is set to 120 seconds.

NE_DUMMY_CMD

The Service Delivery Platform allows you to send commands to a fulfillment element to maintain the active sessions with the adapter. The adapter sends a command five seconds before processing time-out (NE_NO_ACTIVITY_TIMEOUT).

Note: If you want an carriage return command to be sent, use " " as the attribute value. The default command is " ".

NE_CONNECT_RETRY_COUNT

Number of times the interactive adapter will try to reconnect automatically if the connection to the fulfillment element is dropped. The default value is zero.

NE_CONNECT_WAIT

Elapsed time (in seconds) between attempts to reconnect. The Default value is zero.

Fulfillment Elements in Oracle Service Fulfillment Manager

In the Oracle Service Delivery Platform, a fulfillment element is a unique physical entity. It has the following characteristics:

• It has a unique name on a carrier's network.

• It is a member of a unique Fulfillment Element type.

You must give each fulfillment element a unique name. This name is registered in the system during the configuration of the fulfillment element.

For example, if a telecommunications service provider has a router of a certain fulfillment element type (such as Cisco), then a logical name (Cisco_LA, or Cisco_NY, etc.) must be created for it during configuration. This helps to identify which particular Cisco router needs to be activated during Service Fulfillment Manager.

Definition Considerations

When configuring a fulfillment element, consider the following:

• A fulfillment element is always configured as an instance of a fulfillment element type.

• Attributes assigned to a fulfillment element type are inherited by the newly configured fulfillment element.

• Attribute values can be overwritten at the fulfillment element type level.

Understanding Services

In Oracle Service Fulfillment Manager, a service is a telecommunication-related product, offered to the customer as an individual item or in bundles.

Examples of services include:

• Telephone services: Voice, data, videoconferencing, FAX, etc.

• Internet Protocol (IP) services: Web hosting, ecommerce, email, etc.

Service Versions

It is possible to define more than one version of a service in Oracle Service Fulfillment Manager. You set the begin dates and end dates for each service/product version individually. However, only one version of the service is available to a given customer at one time.

Work Items in Oracle Service Fulfillment Manager

Services provided by the carrier are fulfilled by a set of work items performed in a specific sequence within Oracle Provisioning. A work item, then, is a unit of work which is necessary to fulfil a service action.

• You assign to a work item the appropriate parameters, fulfillment actions and fulfillment procedures necessary for the Service Fulfillment Manager process.

• Fulfillment actions are responsible for the actual Service Fulfillment Manager of services at the fulfillment element level.

• As an alternative to work items, users can execute the fulfillment actions conditionally in a user-defined workflow. The workflow is defined according to pre-set conditions in a service order request.

Work item Types

The available work item types are:

• Static: The list of fulfillment actions and their sequence are defined prior to runtime and do not change.

• Dynamic: The list of fulfillment actions and their sequence are determined at runtime by executing a shared procedure.

• User-defined workflow: The list of fulfillment actions and their sequence are determined at runtime by a predefined workflow that executes multiple procedures based on some pre-defined conditions.

• User workflow procedure: Sets the user-defined workflow that is to execute at runtime.

Work Item Rules

Oracle Service Fulfillment Manager comes preseeded with a number of rules for adding, deleting, and modifying work items. They are used to determine dependencies between work items and to analyze the impact if a work item is modified or deleted.

Understanding Packages

A service package contains at least two products/services which are sold together as a unit.

• A package may consist of either related or non-related services.

• All attributes and rules that apply to a service also apply to a service package.

• A service package must contain at least two mandatory products before it can be made available to customers. It can contain as many optional services as desired.

The dates of availability for the service package and the services/products within the package must be consistent. For example, you can not set the package available start date earlier than the earliest start date of all products in the package.

It is possible to add products/services to the package version. However, mutually exclusive products cannot be added to a package. In addition, products with dependencies (co-requisites) can not be added to a package unless the entire set is added.

During package creation, you must specify the minimum and maximum number of products the customer can order from a package that has optional products. For example, you may require that a customer pick at least three, but no more than five of eight possible services/products in the package.

Note: Once a product package has been defined and in the available state, it is not possible to modify or change the package. You must create a new version of the package to modify that package in any way.

Understanding Notifications

The Notifications module is a utility which provides a graphical interface for monitoring service request orders that fail during Service Fulfillment Manager.

If a service order request fails, then the Service Fulfillment Manager workflow sends notifications about these failed service order requests to the Notifications utility, reporting Service Fulfillment Manager problems at various phases of the Service Fulfillment Manager process.

Users with sufficient privilege can review and correct the failed orders through manual intervention. The privileged user can, for example, perform the following tasks from within the Notifications utility:

• View order flowthrough.

• View workflow notifications for failed service order requests.

• Respond to a notification by assigning an error handling action to the service order request.

• Forward a notification to appropriate individuals or groups for resolution.

• Modify the service order request.

• View the workflow diagrams of order activities, using the Workflow Monitor.

If more details are necessary to asses the problem and resolve a failure, the privileged user can step through each of the failed notifications and view the actual Service Fulfillment Manager commands sent by a particular service order request to a fulfillment element and the responses to those commands.

Based on the information contained in the notification messages received in the Notifications utility, the privileged user can follow-up with service order requests or workflow that failed during the Service Fulfillment Manager process.

Follow-up actions include the following:

• Sending the order/workflow back to the process after modifying the order

• Sending orders to other personnel for escalation or resolution

• Stopping the process altogether

The Notifications Utility

You view and access workflow notification messages through the Notifications utility.

You can view:

• All messages (both open and closed)

• Only the open notification messages.

You can query messages based on the following criteria:

• Status

• Receive date

• Order number

• Notification Type

  Note: You can only search for orders which have their workflow started.

Messaging in Oracle Service Fulfillment Manage

Oracle Service Fulfillment Manager obtains messages which are initiated from workflows to communicate with external systems. A message can be used to initiate a Start Billing event with a billing system. Workflow can be configured to wait for inbound messages or can branch out to another workflow based on the information passed.

Message functions

The following are messages functions:

• Trigger a process

• Activate processes within an application

• Send application messages asynchronously using the Event Manager

• Receive application messages asynchronously using the Event Manager

• Handle incoming and outgoing messages and events using multiple queues and the Event Manager

Message Definition

The following are ways to define a message:

• Message type: The message type defines a message either as a timer, an event, or a message.

  • Messages are used for communication between application systems.

  • Events are used to broadcast multi-cast state changes in business objects. Events are published to both external and internal application systems.

  • Timers are messages that have a time delay and a duration interval associated with them.

• Message for internal applications: Internal applications can register a PL/SQL callback procedure via the Event Publisher or through an API.

• Messages for external applications: External applications do not register callback procedures, but have adapters that relay the published event to the remote system. External applications can register for an event using the default subscribers screen.

Message Queues

Messages can go to multiple queues. The following are some of the queues where messages can reside:

• Inbound Message Queue: Messages are sent to this queue for internal processing.

• Outbound Message Queue: Messages are sent to this queue that are enroute to peer systems.

• Internal Event Queue: Messages defined as Events ignore the queue name and the event is published to both the Outbound Message Queue and the Internal Event Queue.

The table following lists the messaging queues and their attributes.

Queue Name	Service Name	Description
Inbound Message Queue	Message Server	Processes all incoming messages.
Internal Events Queue	Event Server	Events generated for internal consumption are enqueued on the internal events queue for speedy processing.
Outbound Message Queue	Communication Adapters	Dequeues messages from the Outbound Message queue and passes it to the peer system.

Outbound Message Structure

Outbound messages must have the following defined:

• Subscriber (system)

• Gateway name

• Adapter type

Message Elements

Message elements in the iMessage Studio can be marked either as mandatory or optional.

During message creation, the iMessage Studio automatically inserts the Message Code and MESSAGE as mandatory message elements in the Elements screen. In addition, the message code is defined as the root element. However, it is possible to define an element more than once in the structure.

Follow these guidelines during message creation:

• Message element names must follow PL/SQL naming conventions.

• The internal name for all message elements must be defined in upper case, replacing any spaces with an underscore.

Warning: Never delete the root element of a message.

Message Elements

• Message elements marked as parameters automatically use the default value specified.

• Message elements marked as parameters are used to derive values of remaining message elements.

• Message elements marked as parameters are not passed in the content of the message body.

• Message elements marked as parameters generate CREATE_MSG(), SEND() and PUBLISH() procedures with the specified message element as a parameter defaulted to the message specified.

Mandatory Elements

• Message elements can be marked as mandatory or optional.

• Upon receiving an incoming message, the validation logic checks all mandatory message elements to ensure that values are in the correct data format.

Message Processing Logic

The Oracle Provisioning Event Manager handles all incoming messages and events. There are four possible ways to process a message. The table following lists them.

Type	Process	Description
Default Process Logic	DEFAULT_PROCESS()	Automatically executed by the Event Manager if no application has registered for the message.
Validate Logic	VALIDATE()	Automatically executed by the Event Manager on the newly arrived messages. The VALIDATE() procedure provides a hook to include business specific validation.
Incoming Message Process Logic	PROCESS()	Executed by the Event manager before delivering the message to the callback procedure of the registered application. The PROCESS() procedure also provides a hook to include any application logic.
Outgoing Message Process Logic	SEND()	Executed by the Event Manager before publishing a message to the Outgoing Queue for delivery. These logic procedures are not generated automatically, they are user-defined and the code is executed as part of the SEND() procedure.

Processing Failure

The Event Manager does not deliver a message to any registered applications if an error is detected during the execution of the processing logic. Nor does the Event Manager process and deliver a message if the message validation process failed. If an error occurs, each resulting error code and error message are logged into the system log.

Message Processing Logic - Guidelines

Use the following guidelines during creation of your message processing logic procedures.

1. If no application logic is specified, the procedure is created with a single NULL; statement

2. Any user defined data which is stored as part of the registration process is passed to the procedure in the parameter p_process_reference.

3. The parameter p_msg_text is the XML message

4. Element values can be obtained using the following procedure:

   xnp_xml_utils.decode(). xnp_xml_utils.decode

   This procedure works only if a message has no repeating elements.

5. User defined logic is required to return any error code and error message. This information must be passed using the parameters:

   • x_error_code

   • x_error_message

6. Any non zero value in x_error_code is considered to be an error.

Timers in Oracle Provisioning

In any reasonably complex business process, system and user generated business events are continually occurring. These business events are not isolated, but are often required as triggers to further business processes. Such business processes may have time constraints.

Timers in Oracle Provisioning are used to handle the events or processes that must occur at specified time intervals during the course of implementing complex business processes.

Timers in Oracle Provisioning are implemented using the Oracle Advanced Queuing mechanism, and the message builder features of the Oracle Service Delivery Platform.

Timer Definition

A timer is a message that consists of the following two elements:

• Delay: Represents the amount of time to wait before starting a timer.

• Interval: Represents the wait time for a timer.

Timer Categorization

Timers are divided into three categories in Oracle Provisioning:

• Activity Timer: The timer is associated with a particular activity within a workflow.

• Process Timer: The timer is associated with an entire workflow process.

• Message Timer: The timer is associated with a message.

Timer Usage in Oracle Provisioning

You use the iMessage Studio Message Framework to create the different types of timers that you use in Oracle Provisioning.

Timer Types

Oracle Provisioning comes with three different timer types. The table following describes each type.

Timer Type	Description
Activity Timer	The timer is associated with a particular activity within a workflow.
Process Timer	The timer is associated with an entire workflow process.
Message Timer	The timer is associated with a message.

Timer Elements

Timer messages requires two mandatory elements:

• Delay

• Interval

Additional optional elements can also be related to a product type, customer category, or the service level agreement based on the business requirements of the user.

Timer Data

It is possible to set the delay and interval timer elements in several different ways:

• The user provides the data source for the timer elements. This feature is useful in retrieving the timer information from other timer configuration tables.

• A stored procedure retrieves the timer delay and interval information.

If desired, you can also set the processing logic that occurs when the timer expires. The processing logic may include jeopardy management or error processing features when the timer expires.

Timer Testing

You may also specify that a test message be sent to test that the Timer message has been correctly configured.

Using Timers in Workflow

You can build timer functionality into your user-defined Workflow by using a set of drag-and-drop activities provided by Oracle Provisioning. These activities are part of the SDP Standard item type.

The table following lists the activities that can be associated with timers in Workflow:

Function Name	Description
Deregister	Remove all timers for a given order
Fire Timer	Function to start either a process or activity timer
Send Message	Function that sends a message which has a timer associated with it
Start Related Timers	Function to start either an activity timer or a timer associated with a message
Subscribe to Acknowledgements	Function to subscriber for possible results from the Send Message function
Get Jeopardy Flag	Checks whether or not a jeopardy timer exists for a given order
Get Timer Status	Returns the status of a timer
Recalculate all timers	Recalculates the delay and interval elements for all timers associated with the given the Work Item name, Instance ID, Order ID, or the Fulfillment Action Instance ID.
Remove Timer	Deletes the timer with the given name

Activity Timers in Oracle Service Fulfillment Manager

An Activity Timer is used in conjunction with a workflow activity. The purpose of an Activity Timer is to provide the ability to set a pre-defined period of time within which a workflow activity must be completed.

For example, a workflow activity is defined to check the network capacity for a requested data service. The time period to perform the workflow activity is set to 30 minutes. An Activity Timer is then associated with the workflow activity to handle the required business logic if the 30 minute time frame for the activity is exceeded.

Process Timers in Oracle Service Fulfillment

A Process Timer is used in conjunction with a Workflow process. The purpose of a Process Timer is to provide the ability to set a pre-defined period of time within which a Workflow process must be completed.

For example, a workflow process is defined to provide a requested data service. The time period to perform the Workflow process is set to one business day. A Process Timer is then associated with the workflow process to handle the required business logic if the one day time frame for the process is exceeded.

Message Timers in Oracle Service Fulfillment

A Message Timer is used in conjunction with a message. The purpose of a Message Timer is to provide the ability to set a pre-defined period of time within which a message acknowledgment must be received.

For example, a workflow process is defined to set up an account for a network service. A message is sent to the associated network service administrator. If a reply is not received back with in 30 minutes, then the timer message is published and picked up by the workflow activity that is Waiting for the Acknowledgments. The acknowledgment may be a message reply or a timer in which the workflow follows a path based on the message received.

The Waiting For Acknowledgments activity subscribes to events. An event can be configured to include an acknowledgment for the message sent out, as well as a timer. Depending on the message received, the workflow progresses.

Workflow in Oracle Service Fulfillment Manager

Workflows are processes that execute during the main Service Fulfillment Manager process to process and fulfill the order. Workflows can be run before starting the service Service Fulfillment Manager process.

You use the Oracle Workflow Builder to configure the workflows to be executed during the Service Fulfillment Manager process. The workflow can be invoked for a work item or a fulfillment action.

The main Service Fulfillment Manager workflow waits until all sub-processes complete their activities before continuing to fulfill the order.

If an error occurs during the main Service Fulfillment Manager process, you can intervene manually and launch appropriate workflows as the situation dictates. You can launch any workflow process in Oracle Provisioning, as necessary.

The Workflow Builder

Refer to the Oracle Workflow Guide for details of the workflow builder.

Workflow Processing of a Service Order Request

During the execution of a service order, the line items associated with it are processed by workflow. Which fulfillment procedures execute depend on the type and software generic of the fulfillment element configured in Oracle Provisioning.

• The mapping between fulfillment procedure and fulfillment element is specified in the Service Creation Manager.

• The fulfillment procedure involves sending commands to a fulfillment element, receiving, and analyzing responses to determine success or failure of commands.

• The procedures are written in PL/SQL which has been extended with open APIs.

• A watchdog workflow detects the termination of adapter processes and manages their recovery.

• When all adapters for a given fulfillment element are shutdown, suspended, disconnected or goes down, all service order requests for that fulfillment element are queued until the adapter is up again and ready to process the next fulfillment action in the queue.

Steps Involved in Processing a Service Order Request

A service order consists of many line items. A line item can be either a service or a package.

• Each line item can be mapped to multiple work items.

• Each work item is mapped to a set of fulfillment actions via different means. (For example, this could be either a static or dynamic fulfillment action, workflow, or a workflow procedure.)

• Each fulfillment action invokes one fulfillment procedure at runtime depending on the type of fulfillment element.

• Each procedure is executed on one fulfillment element.

• The identity of the fulfillment element to be provisioned is determined through routing rules implemented through user-defined PL/SQL procedure.

• Error conditions detected during Service Fulfillment Manager cause the workflow to send error notifications.

• The workflow waits for the notification response.

• The response indicates how the error condition is to be handled.

The Workflow Monitor

The Workflow Monitor utility provides a graphical interface to track a service order's path in Oracle Provisioning. When launched, it opens in a web browser screen. The browser screen displays the runtime path for the order within the Oracle Service Delivery Platform.

Using the graphical interface, you can:

• View each activity performed on an order.

• View the route of an order from the beginning to the end.

• Retrieve statistical information and branching activities for each node displayed on the workflow path.

Workflow Information Types

Oracle Provisioning workflow provides the following categories of information:

• Definition: The definition of the actual activity as defined in the Workflow. This also includes the description of the activity, its type and its results.

• Usage: The location, start/end status, performer, and time-out status information.

• Status: The status of execution of a particular activity, the begin and end dates for the activity.

• Notification:The recipient, the current status, the date sent, due date and end date for a given notification.

Understanding the Procedure Builder

Oracle Provisioning provides a procedure builder tool that you use to write PL/SQL based procedures. PL/SQL procedures must be defined before processing a service order request.

The procedure builder comes with a library of constructs (building blocks) that you can use to write procedures. These procedures, then, are used during the various phases of Service Fulfillment Manager a service order.

Note: It is expected that the user-defined procedures are written by system experts who have knowledge of the Service Fulfillment Manager syntax and service parameters required for the fulfillment element. They must also have good knowledge of PL/SQL.

Procedure types

The different procedures types are:

• Connect and disconnect: The connect procedure is used to connect Oracle Provisioning to a fulfillment element when the Oracle Service Fulfillment Manager application is started. Similarly the disconnect procedure disconnects Oracle Provisioning from a fulfillment element.

  You can choose from a set of PL/SQL constructs which can be used to write connection/disconnection procedures for multiple fulfillment elements.

• Fulfillment element routing: The Locate Fulfillment Element procedure returns the fulfillment element that should be provisioned.

• Dynamic work item-fulfillment action mapping: If you choose the work item type to be of type dynamic, you must use the procedure builder to define the procedure that is executed when the order is sent to Oracle Service Fulfillment Manager. This procedure specifies the fulfillment actions to be executed for the work item.

• Work item parameter evaluation: The evaluation procedure evaluates the parameter values for the work item parameters.

• Fulfillment action parameter evaluation: The evaluation procedure evaluates the parameter values for the fulfillment action parameters.

• User-defined workflow: This procedure is used to launch a user defined workflow. A workflow can consist of multiple procedures to be executed in a pre-set sequence.

• Dynamic service to work item mapping: This procedure specifies at runtime which work items will be executed to fulfill the service.

• Evaluate all fulfillment action parameters: This evaluation procedure is used to evaluate all the fulfillment action parameters together.

• Fulfillment procedure: This procedure specifies the Service Fulfillment Manager commands that need to be executed in fulfilling a service order.