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.
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.
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.
Oracle Service Fulfillment handles a typical service order request by performing the following tasks:
And, if necessary,
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.
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
After an order is captured, Oracle Service Fulfillment Manager performs the following steps:
Analyzes the order.
Breaks it down into the required set of tasks needed to fulfill the order.
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.
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:
Request configuration and activation of services on specific switches. (Connections to the needed network elements are managed using the Connection Manager.)
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.
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.
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
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.
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.
Action | Description |
---|---|
Retry Failed Orders | You can re-send failed orders in one of the following ways:
|
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. |
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
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.
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.
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 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 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.
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.
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
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.
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.
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 |
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.
And additionally, the following queues are used as necessary
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.
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.
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.
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.
When an adapter becomes available, the fulfillment action waiting in the queue is moved to the 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 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:
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.
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.
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.
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.
The following table lists the ways that adapters are used in the Service Delivery Platform, and describes each:
Usage | Description |
---|---|
Service Fulfillment Manager Mode |
|
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 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:
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.
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.
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.
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.
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.
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.
There are two types of adapters modes. They are:
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.
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.
You issue requests (commands) to the adapters and schedule adapter activities through the Connection Manager.
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.
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 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
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.
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 |
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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 messages must have the following defined:
Subscriber (system)
Gateway name
Adapter type
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 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.
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.
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. |
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.
Use the following guidelines during creation of your message processing logic procedures.
If no application logic is specified, the procedure is created with a single NULL; statement
Any user defined data which is stored as part of the registration process is passed to the procedure in the parameter p_process_reference.
The parameter p_msg_text is the XML message
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.
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
Any non zero value in x_error_code is considered to be an error.
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.
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.
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.
You use the iMessage Studio Message Framework to create the different types of timers that you use in Oracle Provisioning.
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 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.
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.
You may also specify that a test message be sent to test that the Timer message has been correctly configured.
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 |
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.
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.
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.
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.
Refer to the Oracle Workflow Guide for details of the workflow builder.
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.
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 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 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.
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.
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.
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.