This chapter provides information on the key components required in implementing Oracle Service Fulfillment Manager and integrations with other Oracle products.
This chapter covers the following topics:
The following items are part of planning an Oracle Service Fulfillment Manager Implementation:
Overview of Oracle Service Fulfillment Manager
Application architecture
Features and functions
User roles
Other considerations
Oracle Service Fulfillment Manager provides the following benefits:
A fully automated, nearly real-time activation of services for multiple network elements in a multivendor 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.
The Oracle Service Fulfillment Manager (SFM) architecture consists of three functional layers:
Application Interface Layer
The Application Interface layer performs the mediation function with external systems. This layer is made of API sets implemented in various interfaces implemented through PL/SQL remote procedure calls.
Workflow Management Layer
The Workflow Management layer performs order processing.
Communications Management Layer
The Communications Management layer is responsible for managing communications between SFM and the network elements. This activity is handled though the Connection Management Utility (CMU) module.
The basic components which make up Oracle Service Fulfillment Manager are as follows:
Order capture through Process Order and Order interface
Ability to resubmit orders
Order management through the Flow Through module
Connection Management Utility acting as a gateway to OSSs, FEs, NEs
Order fallout and repair through the Fallout Management Center
Service definition through the Service Creation Manager module
Order queue processing management through the System Console
Setup of service providers
Ability to create messages to send/receive to any external system
Oracle Service Fulfillment Manager provides three major functions:
Through PL/SQL procedures calls, Oracle Service Fulfillment Manager provides mechanisms for performing the following tasks:
Submitting orders
Obtaining order statuses
Receiving error notification
Responding to error notifications
The Service Fulfillment function also provides the capabilities for service creation, package creation, work item creation, workflow customization, handling of fulfillment elements, handling for fulfillment element types, and other Service Fulfillment Manager procedure capabilities.
Oracle Service Fulfillment Manager has established procedures for user administration, security, console, and connection management (through the Connection Management Utility - CMU), throughput of order processing (through the System Console).
Oracle Service Fulfillment Manager Operations consists of Flow Through Management and Fallout Management (through the Fallout Management Center (FMC))
Oracle Service Fulfillment Manager is designed to be an integrated management system that acts as a coordinating link between different external systems. The following are the primary features of Oracle Service Fulfillment Manager:
Enables rapid deployment of new services by integrating functions of service management with the network details such as service attributes, Service Fulfillment Manager algorithms, and fulfillment elements.
Supports multiple technologies such as ATM, ADSL, switches, routers.
Delivers complex services requiring configuration of multiple fulfillment elements and OSS (Operational Support Systems) interfaces.
Delivers bundled services combining voice, data, and video products.
Oracle Service Fulfillment Manager handles a typical service order request by performing the following tasks:
Managing order fallout (if needed)
Initially, a customer places an order with the carrier for a telecommunication service. Examples of services are phone line connections, Internet connections or wireless access.
Customer orders are captured from an external order entry system. If necessary, you can use the Oracle Service Fulfillment Manager screens to input customer orders. However, as the name of the form indicates the purpose of the Test Center. 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, SFM 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 verifying the following:
Order syntax
Inclusion of mandatory parameters
Inclusion of necessary dependent information
Validity of the supplied dates
After the system captures an order, Oracle Service Fulfillment Manager performs the following steps:
It first analyzes the order.
It then breaks down the order into the required set of tasks needed to complete the order.
Finally, it orders the tasks so that they will be performed in the proper sequence.
For example, say a new order requires two new lines to be activated at a customer residence. The first line is an analog voice phone line. The second line is 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, and 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, you must establish basic voice service on the analog line before implementing the additional features.
Oracle Service Fulfillment Manager accomplishes order fulfillment through one of two ways:
SFM performs the requested tasks internally.
SFM 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,
First, it can request configuration and activation of services on specific switches. (Connections to the needed network elements are managed using the Connection Manager.)
Then, it can notify the OSS (Operational Support Systems) to commence these service.
Workflow manages the tasks involved in setting up an order. Workflow is either internal to Oracle Service Fulfillment Manager or external to it.
Internal Workflow
This is the default, or standard workflow delivered with the application.
External Workflow
You create this workflow, and integrate it with the standard workflow delivered with the application. You configure workflow to match your company specific business practices.
Note: Oracle Service Fulfillment Manager can also handle the results of the network elements through its generic fulfillment engine.
A Service Fulfillment Manager order can complete either successfully, or unsuccessfully.
Order Completion Successful: Upon the completion of an order successfully an event is raised with status of SUCCESS.
Order Completion Unsuccessful: When an order fails the order goes to an ERROR status. On checking the error notification, users can change/modify the order if necessary and continue process the order.
To continue processing you may modify the order from the Notifications Utility or resume the order from the point of failure.
Order fulfillment 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, be too busy, or be 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 due to 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 how 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. Stopping the workflow is useful in the case of identified network outages and order processing backlog. |
| Terminate Failed Workflows | You can completely terminate processing an order if the order encounters an exception state. |
| 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 to troubleshoot the order. |
| Re-assign Failed Workflows | You can reassign a failed order to another user or group for resolution. |
As an order moves through the Service Fulfillment Manager process, the system can generate notifications in response to various events.
Some example of events are:
Recovery daemons
Service Fulfillment Manager process failure
Internal exceptions
The workflow produces two types of notifications:
Informative notifications: The system generates information notifications if the Service Delivery Platform system detects a stopped fulfillment element manager process and starts it up automatically. Also, the system generates this kind of notification if an internal problem occurs that requires a system administrator’s attention.
Order fallout notifications: The system generates an order fallout notification for failed orders.
The Resubmission Utility enables you to force the system to rerun an order on a fulfillment element. However, only those orders which have either completed, or have been previously submitted to the fulfillment element in question, can be resubmitted. You resubmit an order, for example, in the event that a network switch fails or experiences a service disruption, causing a Service Fulfillment Manager order to fail.
Through the Resubmission Utility, you specify a particular fulfillment element and the time window during which it was unavailable. After entering the required information, the fulfillment element re-executes the fulfillment actions as scheduled. For each resubmitted order, the system generates a unique Job ID. You can use the Job ID to track the progress of the resubmitted order.
Successful re-execution of the fulfillment action requires that the adapters run in this mode.
If no adapters are available, 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.
You use the Resubmitted check box in the Order Flowthrough utility to identify resubmitted fulfillment actions.
Resubmitted orders execute the same fulfillment procedure as original orders.
These resubmitted 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 Fulfillment Manager. The Event Manager provides a set of APIs that internal and external systems use to register for messages.
Incoming messages are frequently a response to a previously initiated message from an external or internal system.
Outgoing messages 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 Fulfillment Manager:
Picks up the message from the incoming queue
Pulls the message out of the incoming queue 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
If no application has registered for a message, then the application uses the default processing logic after message validation. External systems, however, can define the processing logic at the time when validation logic is defined.
As a service order moves between the different stages in its processing, the order is often queued in one of the many internal system queues.
As the Service Fulfillment Manager of an order progresses, the order moves sequentially through the various system queues as part of the fulfillment process. The table following describes the queues that the Oracle Service Fulfillment Manager system uses.
| Queue | Contains |
|---|---|
| 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 | Fulfillment actions that are ready for execution (Fulfillment actions execute fulfillment procedures on fulfillment elements.) |
| Wait for Resource | Fulfillment actions waiting for the fulfillment elements to become available on one of the configured channels |
| Ready for Resource | 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 Example events:
|
As an order moves through the system, it progresses in a sequential manner. Typically, this progression moves through the system queues in the following order
The Order Ready queue holds orders that are ready to be provisioned immediately. The order is removed from the Order Ready queue and the work items generated by the work-plan are placed on the work item queue.
The system uses the work item queue to manage the execution of work items.
Processing the work item involves the following action:
Checking the configurator for existence of fulfillment actions mapped to the work items
The following then occurs:
With work items, the fulfillment actions are enqueued into the Ready for Resource in the sequence specified.
For user-defined workflows, the workflow determines the execution of the fulfillment actions. (Users can drag and drop EXECUTE_FA activities into their workflows based on the business process being implemented.)
The system uses the Ready for Resource to manage the execution of fulfillment actions for regular work items.
Processing the fulfillment actions involves:
Checking the configuration to determine which fulfillment element is to receive the fulfillment procedure
Checking 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 system enqueues the fulfillment action in the Wait for Resource queue.
The following queues are used as necessary:
These queues are used by the Service Delivery Platform to communicate with asynchronous XML message based systems.
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.
When an adapter becomes available, the system moves the fulfillment action waiting in the queue to the Ready for Resource queue.
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 number of processors pulling or processing orders out of a queue.
Processors Running:The 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 Service Fulfillment Manager and the fulfillment elements.
Messages to be sent and received are specified by the fulfillment element and the connection procedures executed by Oracle Service Fulfillment Manager 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 uses of adapters by the Service Delivery Platform:
| Usage | Description |
|---|---|
| Provisioning Mode |
|
| Messaging Mode |
|
| Test Mode |
|
| Order Resubmission |
|
The following table lists the types of adapters that are used and describes each:
| Adapter Types | Description |
|---|---|
| Interactive |
|
| Script |
|
| File |
|
| HTTP |
|
You can issue commands to adapters in one of the following ways.
You predefine a sequence of commands (through the Connection Manager) for the system to perform automatically during the course of the Service Fulfillment Manager process. This method is the most common way of issuing commands to the adapters.
You issue adapter commands manually, also through the Connection Manager. However, while possible, this is not recommended.
You schedule commands to run at a future time, or times.
You request, or schedule a request, that an adapter perform one of the following operations:
Suspend
Resume
Disconnect
Connect
Shutdown
Startup
The following table identifies the available commands that the Service Fulfillment Manager system sends to an adapter, the state that the adapter must be in to accept that command, and the state of the adapter after the command is implemented.
| Operation | Current State | Next State |
|---|---|---|
| Suspend | Running | Suspended |
| Resume | Suspended | Running, In Use |
| Disconnect | Running | Disconnected |
| Connect | Disconnected | Running, In Use, Error |
| Shutdown | In Use, Running, Suspended, Disconnect, Session Lost | Shutdown |
| Startup | Shutdown | Starting, Running, In Use, Error, Shutdown |
This command stops the application from sending orders to be fulfilled. It places service orders in a queue until the fulfillment element becomes available.
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 RESUMED.
The current status of the adapter must be running for this command to be available.
This command acts as a toggle to 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 Running or In Use.
It sets the fulfillment element to Running, 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 In Use, if there is a service order request in the Service Fulfillment Manager queue that uses the adapter interfacing to the fulfillment element.
The current status of the adapter must be Suspended for this command to be available.
This command is used to close the appropriate connection. All service order requests are queued until the adapter is available again.
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 reconnected.
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 restart processing.
If this command is used, then the following events occur:
The Connection Manager sets the fulfillment element to one of the following states:
Running
In Use
Error
Processing continues based on the following conditions:
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.
The current status of the adapter must be Disconnected for this command to be available.
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.
When a start up command is issued the next state is "starting". Then the next state can be:
Disconnected - If there is a problem with the connect procedure the Connect on demand flag on the adapter is enabled and there are no waiting orders to be processed.
In Use - If there are waiting orders to be processes.
Running - If there are no waiting orders to be processed and the Connect on demand flag is not Set.
The two types of adapters modes are:
Startup Mode
Debug Mode
There are two 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.
To allow debug messages in all layers of the application code to be funneled into a single repository, and dynamically enabled by user.
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.
Shutdown: Close the connection to the fulfillment element by bringing down the adapter.
Startup: Start up a new adapter and establish a connection to the fulfillment element (if any).
Suspend: Stop Oracle Service Fulfillment Manager 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 at 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. 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 available fulfillment elements that have been configured in Oracle Service Fulfillment Manager
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
Note: Fulfillment element types are defined by system administrators 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 following table lists examples of different fulfillment element types.
| Item | Fulfillment Element Type |
|---|---|
| Home Location Registration (HLR) unit | Network Element |
| Cisco server | Server |
| AT& 5ESS switch | Telephony Switch |
| Nortel DMS200 switch | Telephony Switch |
Any service order request provisioned through Oracle Service Fulfillment Manager 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 a fulfillment element type defines its properties and behavior. These include the following:
IP address
User name
The following are additional attributes for a fulfillment element type:
Passwords used in connection/disconnection procedures
Software generics associated with the procedures
Note: You can 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.
Warning: Setting a value for an attribute overwrites the default value of that attribute specified at the fulfillment element type level.
Default Values for Fulfillment Element Type 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 a 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 Fulfillment Manager, 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.
The following tables describes the standard function activities provided by Oracle Number Portability:
| Name | Description |
|---|---|
| Check Flag Value | Checks the flag value for the PORTING_ID workitem parameter. |
| Check if Donor is eligible to Port Out | Checks whether or not the donor service provider in this porting transaction has provisioned the number range, or has assigned the number range. If either condition is true, then the activity completes with Y. |
| Check if Donor is Initial Donor | Checks whether or not this donor is also the initial donor. |
| Create or Modify SMS Porting Records | Creates or modifies a porting record for each telephone number in the range. The Porting ID for the first record is the same as that set in the work item parameter. |
| Creates Porting Order | Creates a porting order based on the Service Provider role. |
| Deprovision FEs | Sets the fulfillment elements to be deprovisioned for this feature type and number range. For each fulfillment element, the Oracle Service Fulfillment Manager provisioning procedure (Execute FA) is invoked. At the end of this activity, control passes to the provisioning subsystem which executes the fulfillment procedure. An FA_ DONE message is subscribed for each fulfillment action being executed which gives the execution result of the fulfillment procedure. The callback procedure associated with the FA_DONE handles the responses received. The immediate next activity following this activity must be the Oracle Service Fulfillment Manager Standard Wait For Flow. This is to ensure proper hand-off from the provisioning system back to the Number Portability system. Only fulfillment elements that were earlier provisioned by this service provider can be modified. Otherwise, the fulfillment elements are ignored. |
| Determine Current Service Provider Role | Determines whether or not a given service provider is the donor, original donor, or recipient for the current porting transaction, and completes the activity with the appropriate result code. |
| Determine if Subsequent Porting Request | Checks whether or not this is a subsequent porting request. Returns either Y or N. |
| Does Porting Record exist for Donor | Check whether or not there exists a porting record with the given status in this telephone number range that belongs to the given donor’s service provider ID. Returns either Y or N. |
| Does Porting Record exist for Recipient | Check whether or not a porting record with the given status exists in this telephone number range that belongs to the given recipient’s service provider ID. Returns either Y or N. |
| Get Porting Status | Retrieves the status of the porting record for the given PortingID |
| Prepare Notification Message | Prepares a default notification message. |
| Provision or Modify Provisioned FEs | Sets or retrieves the fulfillment elements to be provisioned or modified for this feature type and number range. For each fulfillment element, the Service Delivery Platform’s provisioning procedure (Execute FA) is invoked. At the end of this activity, control passes to the provisioning subsystem which executes the fulfillment procedure. An FA_ DONE message is subscribed for each fulfillment action being executed which gives the execution result of the fulfillment procedure. The callback procedure associated with the FA_DONE handles the responses received. The immediate next activity following the activity must be SDP Standard Wait For Flow. This is to ensure proper hand-off from the provisioning system back to the Number Portability system. Only fulfillment elements that were earlier provisioned by this service provider can be modified. |
| Set Date Value | Sets the Date value |
| Set Flag Value | Sets the flag to the given value for the entries in XNP_SV_SOA for the given PORTING_ID workitem parameter, and FLAG_ NAME for the current Service Provider. The value is either Y or N. |
| Set SMS Provisioning Done Date | Sets the date when the Service Management System completes provisioning |
| Update Charging Information | Updates the Subscription Version in the Service Order Administrator for each telephone number with the given Porting ID, with invoice information. |
| Update Comments and Notes Information | Updates the comments and notes for the current Porting ID and the current service provider. |
| Update Customer Information | Updates the customer information for the current Porting ID and the current service provider. |
| Update Network Information in SOA | Updates the network information in the XNP_SV_SOA for the current Porting ID and the current service provider. |
| Update Porting Status for Number Range | Updates the status type code in the XNP_SV_SOA with the new status type code. All records with the porting ID belonging to the current service provider are updated to the new status. If the new status belongs to the ACTIVE phase, and if records exist for this number range in ACTIVE phase, then these records are first reset to the OLD phase. The actual update of the records with the given porting ID is performed after this step. |
| Update Porting Status for Porting Id | Updates the status type code in the XNP_SV_SOA with the new status type code. All records with the porting id and belonging to the current service provider are updated to the new status. If the new status belongs to the ACTIVE phase, and if there exists records for this number range already in ACTIVE phase, then they first are reset to OLD phase. The actual update of the records with the given porting id is done next. |
| Validate Runtime Data | Validates runtime data |
| Verify Porting Status | Checks if the STATUS_TYPE_CODE from XNP_SV_SOA for the given PORTING_ID is same as the given status type code (in STATUS_TO_COMPARE_WITH). Returns T if the two statuses match. Returns F if the two statuses do not match. |
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 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, video conferencing, FAX, etc.
Internet Protocol (IP) services: Web hosting, ecommerce, email, etc.
Services provided by the carrier are fulfilled by a set of work items performed in a specific sequence within Oracle Service Fulfillment Manager. 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 preset conditions in a service order request.
Work items are organized into groups known as item types. The following table lists the standard item types delivered with Oracle Number Portability.
Note: Do not modify any of the standard Oracle Number Portability item types, except NP Processes.
| Item Type | Internal Name | Description | Customizable |
|---|---|---|---|
| Standard | WFSTD | Contains standard function activities that are commonly used to create business processes. | No |
| SFM Standard | XDPWFSTD | Contains function activities that are commonly used across both the Oracle Service Fulfillment Manager and Oracle Number Portability applications. The following are examples of functions:
|
No |
| SFM Lookup Code | XDPCODES | Contains lookup types used for easy selection in workflow activities. This could be, for example, a list of fulfillment actions, or a list of messages. | No |
| NP Standard | XNPWFSTD | Contains function activities that are specific to Oracle Number Portability. Use these activities in the implementation of your business processes. The following are examples of standard functions:
|
No |
| NP Lookup Code | XNPTYPES | Contains lookup types used for easy selection in workflow activities. This could be, for example, a list of fulfillment actions, or a list of messages. | No |
In general, you should use the SFM Standard and NP Standard function activities whenever possible, and only customize the Number Portability activities as absolutely necessary.
SFM Lookups and NP Lookups must be updated as you start to configure Oracle Service Fulfillment Manager. Run the Lookups Loader API to update these 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 predefined conditions.
User workflow procedure: Sets the user-defined workflow that is to execute at runtime.
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 cannot 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 and track order.
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
Received Date
Order Number
Notification Type
Note: You can only search for orders whose workflow has started.
From the Notification Inbox, you can take various actions to deal with workflow notifications. For example, you can perform the following tasks:
To view the existing notification messages in the system, perform the following steps.
Prerequisites
None
Steps
Navigate to Operations, then Notifications.
Click View Open to view only those notification messages that are currently open.
Click View All to view notification messages, regardless of status.
Select a notification from the list at the left. The Notification Message Details window appears.
Close the window after viewing the information.
To add a comment to a notification message, perform the following steps.
Prerequisites
The message must exist for this option to be available.
Steps
Navigate to Operations, then Notifications.
Select a notification from the list on the left.
Click View Details. The Notification Message Details window appears.
Click Add Comment to launch the Notification Comment window.
Enter your comments about the notification in the space provided.
Save your changes and close the window.
To respond to a notification message, perform the following steps. Responding to a notification changes its status from Open to Closed.
Prerequisites
The status of the message must be Open for this option to be available.
Steps
Navigate to Operations, then Notifications.
Select a notification from the list on the left.
Click View Details. The Notification Message Details window appears.
Click Respond to launch the Notification Response window.
Select one of the responses from the list.
Click OK to close the window and initiate the action.
To forward the notification to a third party, perform the following steps. When a notification is reassigned, it is marked as Closed.
Prerequisites
The status of the message must be Open for this option to be available.
Steps
Navigate to Operations, then Notifications.
Select a notification from the list on the left.
Click View Details. The Notification Message Details window appears.
Click Forward to launch the Notification Response window
Select another user or group from the list.
Click OK to close the window and reassign the message.
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 multicast 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 following table 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 message 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: Do NOT 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.
On receiving an incoming message, the validation logic checks all mandatory message elements to ensure that values are in the correct data format.
The Oracle Service Fulfillment Manager Event Manager handles all incoming messages and events. The following table lists the four possible ways to process a message.
| 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, then 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.
Oracle Provisioning comes with three different timer types. The tfollowing table 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.
The Waiting For Acknowledgments activity subscribes to events. An event may be configured to include and Acknowledgment for the Message sent out and a Timer. Depending on the message received, the workflow progresses.
For example,
We may have an event group call MSG_ACK_TIMER_1 that consists of Timer 1 and Ack. Depending on Timer 1 or Ack being received, the workflow progresses.
You may also specify that a test message be sent to test that the Timer message has been correctly configured. Define a connection management schedule as needed
It is possible to view status details and other details of a service order while it is in one of the following phases:
Ordering
Active
Ole
To view the porting summary, perform the following steps.
Prerequisites
None
Steps
Navigate to Operations, then Flowthrough Manager.
If an order has not yet been referenced, the Find Orders dialog box displays it initially.
Enter a value to use as the search criteria in the Find Orders dialog box.
You can search for an order on several criteria. If you know the order ID or order number, then simply enter this information and click Show Order. Alternatively, you can enter one or more of the other criteria to search for the order.
The Flowthrough Manager displays the found order (with the order number in the left-hand list box). All of the line items associated with this order are displayed in the form of leaf nodes. If necessary, expand the list of line items by clicking the plus sign next to the order number.
Select the Order Header tab to view the basic information associated with this order.
The current Service Fulfillment Manager status of the order displays in the Order Status field. Service Fulfillment Manager statuses are pre-seeded by the application.
To view information about the Notifications, Event Log, Workflow and Parameters associated with this order, click the appropriate button at the bottom of the screen.
Select the Order Line tab to view information relating to the current Service Fulfillment Manager status and associated parameters for this order.
To view information about the workflow associated with this order, click Workflow.
To view information about the parameters associated with the order line, click Parameters.
Select the Work Items tab shows all the Work Items associated with the selected Order Line Item selected on the left hand corner (the leaf element).
To view status and state information, select the Status sub-tab.
To view date-related information, select the Date sub-tab.
To view information about the parameters associated with a work item, select it and click Parameters.
To view information about the workflow associated with this work item, click Workflow.
Select the Fulfillment Actions tab to view information relating to fulfillment actions associated with this work item and the fulfillment element to which each action is being applied.
To view status-related information, select the Status sub-tab.
To view date-related information, select the Date sub-tab.
To view Parameter, Audit Trail, and Workflow information for a fulfillment action, select a fulfillment action (if any exist for this order) and click the appropriate button at the bottom of the screen.
Click Cancel to exit the Order Flowthrough screen.
You use the Resubmission Utility to re-run orders. This is useful, for example, if a network switch fails, or experiences service disruption that causes a Service Fulfillment Manager order to fail. The order, however, has not been lost by the system, and can be resubmitted when the unit becomes available.
For example, a particular fulfillment element fails at 3:02 a.m. on a particular date. It remains unavailable for service until 5:20 a.m. the same day. This fulfillment element was to be used to provision a number of orders during that span of time, but as it was unavailable, the orders failed to complete. After the fulfillment element (or its replacement) becomes available, it is necessary to resubmit all orders that were to be provisioned by that particular fulfillment element during the window of time from 3:02 to 5:20 a.m. The order information is not lost, and can be re-used to resubmit the original Service Fulfillment Manager orders.
You use the Resubmission Utility to perform the following tasks.
To resubmit all orders that were to be provisioned by a specific fulfillment element during a span of time, perform the following steps.
Steps
Navigate to Operations, then Order Resubmission.
The Order Resubmission Jobs window appears. Previously defined resubmission jobs display under Job ID (Fulfillment Element) on the left.
Click New.
The New Job window appears. You use this window to create a new resubmission job that targets a specific fulfillment element during a specified time window.
Enter the name of the fulfillment element for which you want to resubmit orders.
Chose a fulfillment element from the List of Values (LOVs).
Enter the exact date and time at which the fulfillment element became unavailable in the Outage Start Date field. And, if desired, enter the exact date and time that the fulfillment element became available again.
Enter the number of adapters that this affects in the No. of Adapter field.
Click Submit.
The job displays in the Job ID (Fulfillment Element) window. You can track the progress of order resubmission process through the Job ID.
Click Cancel to close this window
To view the status or details of a resubmission job, perform the following steps.
Steps
Navigate to Operations, then Order Resubmission.
The Order Resubmission Jobs window appears. Previously defined resubmission jobs display under Job ID (Fulfillment Element) on the left.
Select the Job ID from the list at the left.
The pertinent information for the resubmission job displays.
Click Order List.
The Resubmitted Order Information window appears. This window displays information about each individual order.
Click Cancel to close the Resubmitted Order Information window.
Click Cancel to close the Order Resubmission Jobs window.