This chapter describes how Oracle Communications Billing and Revenue Management (BRM) Services Framework provisioning works.
Before reading this document, see "Understanding the Services Framework".
Services Framework provisioning notifies external provisioning agents when an account or service changes. For example, it notifies an external provisioning agent when a customer adds or removes a service; adds, cancels, or replaces a device; or modifies a profile. After the external provisioning agent updates its records, Services Framework provisioning updates the account or service information in the BRM database.
For example, when a customer switches to a new wireless phone device, the following occurs:
Services Framework provisioning notifies the wireless phone carrier that the account is discontinuing its old device and switching to a new device.
The wireless phone carrier updates its records.
The wireless phone carrier responds to Services Framework provisioning that the records were successfully updated.
Services Framework provisioning updates the account by activating the new device and canceling the old device.
Services Framework can provision both telco services and non-telco services.
All telco service types (/service/telco/* objects) are automatically recognized and provisioned by Services Framework.
Non-telco service types are provisioned only if they are listed in the /config/service_framework/permitted_service_types object. You specify the non-telco service types that Services Framework supports by using the load_pin_service_framework_permitted_service_types utility. See "Specifying the Non-Telco Services Supported by Services Framework".
Services Framework provisioning uses service orders to alert external provisioning agents about account and service changes. The service order includes details about what changed, including the following:
POID of the device, service, or profile object that changed
The current status of the service order. See "About Service Order Status".
The provisioning action to perform: activation, deactivation, suspension, reactivation, change, or ignore
Specified fields from the /service or /device object. See "About Adding Details to the Service Order".
The service order is sent to the external provisioning agent and stored in the BRM database in an /event/provisioning/service_order/telco/service_name object.
Supplementary services are added or removed from service objects (/service/telco/service_name) when products and deals are purchased or canceled. Services Framework service management initially sets the service status to NEW. If supplementary services are not included with the service, Services Framework provisioning adds them to the service order.
Note:
It is possible that some features are part of two or more products that are purchased separately. In this case, the one added later takes the status of the existing one and is not included in the service order.Tip:
Customer Center displays the supplementary services status in the Service tab.You can localize the status flags for the service and the status for the supplementary service by using the load_localized_strings utility, which updates the /strings storable class based on localized configuration file. See "Creating a Localized Version of BRM" in BRM Developer's Guide.
Device service order creation is controlled by the device status stored in the configuration object (/config/device_state). If the device status is listed in the configuration object, a service order is created. The action associated with this service order is the one specified in the configuration for this device status entry.
The /event/device/associate and /event/device/disassociate events occur during an update services action. These events get device information needed to create the service order from the device objects. Only events for device types listed in the /config/telco/provisioning object are processed. The fields read from the device objects are specified in the /config/telco/provisioning object for this type of device.
When a device is changed, the /event/device/state event is generated as part of the device state change. PCM_OP_TCF_CREATE_SVC_ORDER reads the configuration object (/config/telco/provisioning) to determine if the device state requires that a service order be created. If so, this opcode creates it as part of the service order event (/event/provisioning/service_order/telco/service_name).
The PCM_OP_TCF_PROV_POL_CREATE_SVC_ORDER policy opcode is called as part of the state transition and can be customized to change some value in the service order. This opcode calls the opcodes that update the service order.
Profiles are added and removed from BRM service objects through the purchase and cancellation of products and deals. Services Framework provisioning includes profiles in service orders as directed by the provisioning configuration object /config/provisioning/telco. The PCM_OP_TCF_CREATE_SVC_ORDER opcode determines whether to create a service order based on data that has been added, changed, or removed from this object.
This opcode subscribes to the /event/notification/profile/pre-modify and /event/notification/profile/modify events generated by the PCM_OP_CUST_MODIFY_PROFILE opcode to create service orders for profile changes. Based on the value in the status field of the profile object, a service order is created and stored in the /event/provisioning/service_order/telco/service_name event by capturing changes made to the profile object.
Like services, service orders have different statuses in their lifetimes. Table 19-1 shows the default values for service order status:
Table 19-1 Service Order Status Default Values
| Service Order Status | Description |
|---|---|
|
NEW |
This is the initial service order state. |
|
READY |
A READY service order is ready to be sent to the provisioning agent. The provisioning functional modules have all the necessary data to completely fill in the service order and send it to the network provisioning interface. |
|
PROCESSING |
After the service order is received by the network provisioning interface, the state is changed to PROCESSING. |
|
COMPLETED |
If the service order is successfully processed and the devices are provisioned, the service order state changes to COMPLETED. |
|
FAILED |
If there are errors during device provisioning or in the network, the status of the service order is set to FAILED. |
To view the status of a service order, use Event Browser.
BRM uses event notification to alert Services Framework provisioning that one of the following occurred:
A service was created or modified.
A device was associated with or disassociated from a service.
A device was replaced with a new device.
A device's state changed.
A profile was modified.
Note:
To configure event notification to alert Services Framework provisioning that other events occurred, see "Setting Up Event Notification for Provisioning".Services Framework provisioning then performs the following main functions:
Generates a service order and adds specified details to it. See "About Adding Details to the Service Order".
Retrieves the service order state transitions for the specified service or device type. See "About the Allowable Service Order State Transitions".
Optionally tests the provisioning process by using the Network Simulator. See "Testing Provisioning Using BRM Network Simulator" for more information.
Publishes the service order and, depending on the provisioning mode, either finishes processing or waits for a response from the network provisioning agent. See "About Provisioning Modes".
Service orders contain information about the service, device, or profile that changed as well as the provisioning action to perform. You can also have other details about the service, device, or profile added to the service order before it is sent to the external provisioning agent. For example, you can add the quality of service (QoS) values and APN names to GSM service orders.
You specify the service, device, or profile object fields to add to the service order in the BRM_Home/sys/data/config/pin_telco_provisioning configuration file. You then load the file into the provisioning configuration object (/config/telco/provisioning and /config/telco/provisioning/fieldlist) by using the load_pin_telco_provisioning utility.
During the provisioning process, Services Framework determines the object fields to include in the service order by reading the provisioning configuration object:
For telco services, the provisioning configuration object is /config/telco/provisioning/ServiceType, where ServiceType is the service type passed in the input flist. For example, if the service type is /service/telco/gprs/telephony, the provisioning configuration object is /config/telco/provisioning/gprs/telephony.
For non-telco services, the /config/service_framework/permitted_service_types object lists the provisioning configuration object to use.
To configure the service, device, and profile object fields to add to the service order, see "Specifying the Details to Add to the Service Order".
Service orders can be set to a NEW, READY, PROCESSING, COMPLETED, or FAILED state. When a service order is first created, it is set to the NEW state by default. The service order can then transition from the NEW state to a list of permitted states that you specify.
For each service order state, you define the valid states to which it can transition. For example, you specify whether service orders can transition from a NEW state to only a READY state or from a NEW state to either a READY state or a PROCESSING state.
You specify the allowable state transitions on a service-by-service basis in the BRM_Home/sys/data/pin_telco_service_order_state configuration file. You then load the file into the /config/telco/service_order_state/* database object by using the load_pin_telco_service_order_state utility.
Note:
You can also configure BRM to call an opcode when a service order transitions from one state to another.To configure the state transitions that are allowed, see "Specifying the Available States for Each Service Order".
After service orders are published, the provisioning process cannot continue until the network provisioning agent returns a response. You can configure whether Services Framework provisioning sends the service order directly to the agent and waits for a response or publishes the service order to a queue by setting the provisioning mode:
Queued provisioning mode. Services Framework provisions service orders in two separate transactions. In the first transaction, Services Framework generates a service order and queues it for the external provisioning agent. In the second transaction, the external provisioning agent responds that provisioning failed or was successful and then Services Framework updates the service in the BRM database. This is the default provisioning mode.
Confirmed provisioning mode. Services Framework publishes the service order immediately to the external provisioning agent, waits for a response, and updates the service in the BRM database in one transaction. Specifically, Services Framework:
Processes the request and converts the service order information into a provisioning payload object in XML format.
Sends the service order to the network provisioning agent through a TCP/IP connection.
Waits for a response from the network provisioning agent.
If the wait exceeds the timeout value, the transaction is rolled back. See "Setting a Timeout Value for Requests Sent in Confirmed Mode".
You specify the provisioning mode on a service-by-service basis by using the pin_service_framework_permitted_service_types.xml configuration file. You then load the XML file into the BRM database's /config/service_framework/permitted_service_types object by using the load_pin_service_framework_permitted_service_types utility. See "Specifying the Non-Telco Services Supported by Services Framework".
You can also customize the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode to set an event's provisioning mode based on service order attributes. The policy opcode overrides the provisioning mode set in the /config/service_framework/permitted_service_types object.
Note:
The /config/service_framework/permitted_service_types object and the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode are used primarily to configure non-telco service types. However, they can be used to specify the provisioning mode for telco service types.Services Framework provisioning generates service orders as follows:
A customer account creates or modifies a service, device, or profile. This generates a notification event.
The event notification system calls the opcode specified in the /config/notify object. By default, the PCM_OP_TCF_PROV_CREATE_SVC_ORDER opcode is called. See "Using Event Notification" in BRM Developer's Guide.
PCM_OP_TCF_PROV_CREATE_SVC_ORDER performs the following:
Determines whether the service type passed in the input flist is supported by Services Framework. All telco service types and all service types listed in the /config/service_framework/permitted_service_types object are supported. See "About Provisioning Telco and Non-Telco Services".
Determines the provisioning configuration object to use. See "About Adding Details to the Service Order".
Determines the service order configuration object to use. See "Specifying the Available States for Each Service Order".
Generates the service order business event (/event/provisioning/service_order/telco/*).
Note:
The service order business event contains ”telco” in its name for both telco and non-telco service types because the common substruct for holding the service order data is at the /event/provisioning/service_order/telco level.The event notification system calls the opcode specified in the /config/notify object. By default, PCM_OP_TCF_PROV_HANDLE_SVC_ORDER is called.
PCM_OP_TCF_PROV_HANDLE_SVC_ORDER performs the following:
Determines whether the service order status is NEW. If it is, the opcode calls PCM_OP_TCF_PROV_SERVICE_ORDER_SET_STATE to update the service order status to READY.
Determines whether to call Network Simulator by reading the simulate_agent entry in the CM pin.conf file. If simulate_agent is set to 1, the opcode calls the PCM_OP_TCF_PROV_SIMULATE_AGENT opcode to simulate the provisioning flow with the CM. For information about Network Simulator, see "Testing Provisioning Using BRM Network Simulator".
Determines the provisioning mode for the service type by reading the /config/service_framework/permitted_service_types object. The default is Queued. See "About Provisioning Modes".
Calls the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode with the service order event details and provisioning mode.
The PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode performs any custom actions and then returns to the calling opcode. By default, this policy opcode does nothing, but you can customize it to override the provisioning mode and modify service order event details.
PCM_OP_TCF_PROV_HANDLE_SVC_ORDER calls the PCM_OP_PROV_PUBLISH_SVC_ORDER opcode to publish the service order.
PCM_OP_PROV_PUBLISH_SVC_ORDER publishes the service order to dm_prov_telco.
dm_prov_telco determines the provisioning mode by reading the PIN_FLD_MODE flist entry. dm_prov_telco operates in Queued mode when the entry is 0 and Confirmed mode when the entry is 1.
In Queued mode, dm_prov_telco queues the request in-memory and calls PCM_OP_TCF_PROV_SERVICE_ORDER_SET_STATE to update the service order status to PROVISIONING. See "About Provisioning Modes".
In Confirmed mode, dm_prov_telco sends the service order to the network provisioning agent through a TCP/IP connection and waits for a response. See "About Provisioning Modes".
After the network provisioning agent returns a response in flist format, Services Framework provisioning performs the following:
dm_prov_telco sends the response to the PCM_OP_PROV_PUBLISH_SVC_ORDER opcode.
PCM_OP_PROV_PUBLISH_SVC_ORDER passes the response to the PCM_OP_TCF_PROV_HANDLE_SVC_ORDER opcode.
PCM_OP_TCF_PROV_HANDLE_SVC_ORDER calls the PCM_OP_PROV_UPDATE_SVC_ORDER opcode to update the service order status.
PCM_OP_PROV_UPDATE_SVC_ORDER changes the service order status to Processed and generates the /event/provisioning/service_order/telco/* business event.
The event notification system calls the opcode specified in the /config/notify object. By default, the PCM_OP_TCF_PROV_UPDATE_PROV_OBJECT opcode is called.
PCM_OP_TCF_PROV_UPDATE_PROV_OBJECT updates the service's status and supplementary features.
To set up Services Framework for provisioning:
Specify the notification events that trigger provisioning. See "Setting Up Event Notification for Provisioning".
Specify the details to add to the service order. See "Specifying the Details to Add to the Service Order".
Specify the available state transitions for each service type. See "Specifying the Available States for Each Service Order".
Configure service status change for device-to-service associations. See "Configuring Service Status Change for Device-to-Service Associations".
BRM uses event notification to start the Services Framework provisioning process. You specify which notification events trigger provisioning by editing the event notification configuration file and then loading it into the database with the load_pin_notify utility.
To configure event notification for provisioning:
Open the BRM_Home/sys/data/config/pin_notify_telco file in a text editor.
If your system has multiple configuration files for event notification, merge them with the pin_notify_telco file.
Add the following entry for each service or device type that you want to provision:
OpcodeNumber Flag Event
where:
OpcodeNumber specifies the hard-coded number for an opcode. To find an opcode's number, see the opcode header files (*.h) in the BRM_Home/include/ops directory.
Flag is the name of the flag to pass to the opcode when it is called by the event notification feature. 0 means no flag is passed.
Event is the name of the event that triggers the opcode. You can use any BRM default or custom event defined in your system.
The default pin_notify_telco file includes the following lines, which indicate that PCM_OP_TCF_PROV_CREATE_SVC_ORDER (opcode number 4016), PCM_OP_TCF_PROV_HANDLE_SVC_ORDER (opcode number 4017), and PCM_OP_TCF_PROV_UPDATE_PROV_OBJECT (opcode number 4019) are called whenever these notification events occur:
4016 0 /event/notification/service/pre_create 4016 0 /event/notification/service/create 4016 0 /event/notification/service/pre_change 4016 0 /event/notification/service/post_change 4016 0 /event/device/associate 4016 0 /event/device/disassociate 4016 0 /event/device/replace 4016 0 /event/notification/profile/pre_modify 4016 0 /event/notification/profile/modify 4016 0 /event/device/state 4017 0 /event/provisioning/service_order/telco 4017 0 /event/provisioning/service_order/telco/gsm 4017 0 /event/provisioning/service_order/telco/gsm/telephony 4017 0 /event/provisioning/service_order/telco/gsm/data 4017 0 /event/provisioning/service_order/telco/gsm/fax 4017 0 /event/provisioning/service_order/telco/gsm/sms 4017 0 /event/provisioning/service_order/telco/gprs 4019 0 /event/provisioning/service_order/telco 4019 0 /event/provisioning/service_order/telco/gsm 4019 0 /event/provisioning/service_order/telco/gsm/telephony 4019 0 /event/provisioning/service_order/telco/gsm/data 4019 0 /event/provisioning/service_order/telco/gsm/fax 4019 0 /event/provisioning/service_order/telco/gsm/sms 4019 0 /event/provisioning/service_order/telco/gprs
Save and close the file.
Load your final event notification list (pin_notify_file) into the BRM database by using the load_pin_notify utility:
load_pin_notify pin_notify_file
Restart the Connection Manager (CM). See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
For more information, see "Using Event Notification" in BRM Developer's Guide.
You specify the services and associated devices (if any) to include in a provisioning service order by editing the pin_telco_provisioning file. You load the file into the BRM database's /config/telco/provisioning object by using the load_pin_telco_provisioning utility.
Note:
Including associated devices in a service order is not the same as pre-provisioning devices, although you use the pin_telco_provisioning file for both operations. For more information, see "About SIM Card Pre-Provisioning".To specify the service, device, and profile object fields to add to service orders:
Open the BRM_Home/sys/data/config/pin_telco_provisioning file in a text editor.
Add the following lines for each service that you want to provision:
Service provisioning info: ServiceType, ProvAction, Field1, Field2, Field3
where:
ServiceType specifies the type of service that is being provisioned.
ProvAction specifies the provisioning action that is sent in the service order. The external provisioning system uses this information to determine the appropriate provisioning action. Use A (activate), C (close), D (deactivate), I (ignore), P (provisioning), R (reactivate), and S (suspend).
FieldX specifies the service object fields to include in the service order.
For example, the following lines specify to add the bearer service name, APN name, and QOS profile name to the service order when a GPRS service is being activated. Note that the fields specified are part of the /service/telco/gprs schema.
Service provisioning info: /service/telco/gprs, A, PIN_FLD_GPRS_INFO.PIN_FLD_BEARER_SERVICE, PIN_FLD_APN_ARRAY[*].PIN_FLD_APN, PIN_FLD_APN_ARRAY[*].PIN_FLD_QOS_PROFILE_NAME
(Optional) Add the following lines to specify devices associated with the service. Each device you include requires a separate line, separated by commas.
Device provisioning info: DeviceType, ProvAction, Field1, ”String1”, DeviceType, ProvAction, Field2, ”String2”
where:
DeviceType specifies the type of device associated with the service.
ProvAction specifies the provisioning action for the device objects in the service order. The external provisioning system uses this information to determine the appropriate provisioning action. Use A (activate), C (close), D (deactivate), I (ignore), P (provisioning), R (reactivate), and S (suspend).
FieldX specifies the name of a field that contains a device attribute to include in the service order. Field names are replaced by actual values when you run pin_telco_provisioning.
StringX specifies a string that is used in the service order to identify the attribute specified by the field value. You can query for the string in the service order.
For example, the following line activates a phone number. The actual phone number value will be included in the service order, identified by the MSISDN string.
/device/num, A, PIN_FLD_DEVICE_ID, "MSISDN"
Save and close the file.
Run the following command, which loads the file into the database:
load_pin_telco_provisioning pin_telco_provisioning
For the complete command syntax, see "load_pin_telco_provisioning".
Restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To verify that the data was loaded, you can display the /config objects by using the Object Browser or use the robj command with the testnap utility. See testnap and "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
You specify the available service order state transitions for each service type by editing the pin_telco_service_order_state file. You then load the file into the BRM database's /config/telco/service_order_state/* object by using the load_pin_telco_service_order_state utility.
To specify the state transitions:
Open the BRM_Home/sys/data/config/pin_telco_service_order_state file in a text editor.
Add the following lines for each service type that you want to provision:
ServiceType StateID: StateType: OpcodeNum: Flags NextState:OpcodeNum:Flags NextState:OpcodeNum:Flags NextState:OpcodeNum:Flags
where:
ServiceType specifies the service type that is being provisioned.
StateID specifies the starting service order state: NEW (1), READY (2), PROCESSING (3), COMPLETED (4), and FAILED (5).
StateType specifies the state type: raw (0), init (1), normal (2), and end (3).
NextState specifies the state to which the service order can be transitioned to from the starting state: NEW (1), READY (2), PROCESSING (3), COMPLETED (4), and FAILED (5).
OpcodeNum specifies the opcode to call when the transition is made. To not call an opcode, use 0.
Flags specifies the flag to pass to the opcode.
For example, the following lines specify that service orders can transition from a NEW state to a READY state, from a READY state to a PROCESSING state, and from a PROCESSING state to a COMPLETED or FAILED state:
/event/service_order/telco/gsm
1: 1: 0: 0
2: 0:0
2: 2: 0: 0
3: 0:0
3: 3: 0: 0
4: 0:0
5: 0:0
Save and close the file.
Run the following command, which loads the file into the database:
load_pin_telco_service_order_state pin_telco_service_order_state
For the complete command syntax, see "load_pin_telco_service_order_state".
Restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To verify that the data was loaded, you can display the /config objects by using Object Browser or use the robj command with the testnap utility. (See "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.)
By default, when you associate a device with a service, BRM activates the service, provisions the associated supplementary features, updates the status of the service and the associated supplementary features, and generates a service order that contains the service status and the status of the associated supplementary features. When you disassociate a device from a service, BRM deactivates the service, unprovisions the associated supplementary features, updates the status of the service and the associated supplementary features, and updates the service order.
You can configure BRM to not update the status of a service when you associate a device with a service or disassociate a device from a service by modifying a field in the TCF instance of the /config/business_params object.
You modify the /config/business_params object by using the pin_bus_params utility. For information on this utility, see "pin_bus_params" in BRM Developer's Guide.
To configure service status change for device-to-service associations:
Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed BRM.
Run the following command, which creates an XML file from the TCF instance of the /config/business_params object:
pin_bus_params -r BusParamsTCF bus_params_TCF.xml
This command creates the XML file named bus_params_TCF.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.
Open the bus_params_TCF.xml.out file in a text editor.
Search for the following line:
<RestrictDeviceToServiceStatePropagation>disabled</RestrictDeviceToServiceStatePropagation>
Change disabled to enabled.
Save the file as bus_params_TCF.xml.
Go to the BRM_Home/sys/data/config directory, which includes support files used by the pin_bus_params utility.
Run the following command, which loads this change into the /config/business_params object:
pin_bus_params PathToWorkingDirectory/bus_params_TCF.xml
where PathToWorkingDirectory is the directory in which the bus_params_TCF.xml file resides.
Caution:
BRM uses the XML in this file to overwrite the existing TCF instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the Telco Framework (Services Framework) configuration.Note:
To run this command from a different directory, see "pin_bus_params" in BRM Developer's Guide.Read the object with the testnap utility or Object Browser to verify that all fields are correct.
See "Using testnap" in BRM Developer's Guide for general instructions on using the testnap utility. See "Reading Objects by Using Object Browser" in BRM Developer's Guide for information on how to use Object Browser.
Stop and restart the Connection Manager (CM). For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.
To set up Services Framework to process non-telco service types, perform the following tasks:
Specify the non-telco service types supported by Services Framework. See "Specifying the Non-Telco Services Supported by Services Framework".
(Optional) Customize the service order details and provisioning mode. See "Customizing the Provisioning Mode Based on Service Order Attributes".
Set the timeout value for the Confirmed provisioning mode. See "Setting a Timeout Value for Requests Sent in Confirmed Mode".
You specify the non-telco service types that are supported by Services Framework by editing the pin_service_framework_permitted_service_types.xml configuration file. You then load the XML file into the BRM database's /config/service_framework/permitted_service_types object by using the load_pin_service_framework_permitted_service_types utility.
The pin_service_framework_permitted_service_types.xml file specifies the following for each supported service type:
The provisioning configuration object, which defines the fields to include in a service order.
The service order configuration object, which specifies the service order state transitions.
The provisioning mode: Queued or Confirmed.
Note:
You use the XML file primarily to configure your non-telco services, but you can use it to specify the provisioning mode for telco services. To do this, list only the telco service type and the provisioning mode.To specify the supported non-telco service types, perform these tasks:
Open the BRM_Home/sys/data/config/pin_service_framework_permitted_service_types.xml file in an XML editor.
For each non-telco service type that is supported by Services Framework, add the following entries:
Specify the supported non-telco service type on the ServiceType line. For example, replace ServiceType with /service/cable.
<ServiceType>ServiceType</ServiceType>
Specify the provisioning configuration object to use on the ConfigTypeProvisioningDetails line. For example, replace ProvDetails with /config/telco/provisioning/cable.
<ConfigTypeProvisioningDetails>ProvDetails</ConfigTypeProvisioningDetails>
For information, see "About Adding Details to the Service Order".
Specify the service order configuration object to use on the ConfigTypeServiceOrderState line. For example, replace SOstate with /config/telco/service_order_state/cable.
<ConfigTypeServiceOrderState>SOstate</ConfigTypeServiceOrderState>
For information, see "About the Allowable Service Order State Transitions".
Specify the provisioning mode on the ProvisioningMode line. Replace Value with 0 for Queued mode and with 1 for Confirmed mode.
<ProvisioningMode>Value</ProvisioningMode>
Save and close the file.
Run the following command, which loads the list of non-telco service types into the database:
load_pin_service_framework_permitted_service_types
See "load_pin_service_framework_permitted_service_types" for more information.
Note:
This utility requires a configuration (pin.conf) file in the directory from which you run the utility. See "Creating Configuration Files for BRM Utilities" in BRM System Administrator's Guide.Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To verify that the data loaded successfully, you can display the /config/service_framework/permitted_service_types object by using Object Browser or by using the robj command with the testnap utility. See "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
By default, Services Framework assigns provisioning modes to events based on the service type. You can customize Services Framework to assign the provisioning mode based on other attributes, such as service order details, by customizing the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode. You can also customize the policy opcode to modify service order event details before they are published to the external provisioning agent.
You customize the policy opcode to find events with specific flist fields, assign the appropriate provisioning tag and change service order details, and then return the provisioning mode in the PIN_FLD_MODE output flist field.
For information about customizing policy opcodes, see "Adding and Modifying Policy Facilities Modules" in BRM Developer's Guide.
When provisioning service orders in Confirmed mode, dm_prov_telco waits for a response from the external provisioning agent before activating the service in the BRM database. If the external provisioning agent encounters an error or fails, dm_prov_telco might have to wait indefinitely. To prevent this problem, you can configure dm_prov_telco to close the connection and roll back the transaction if the wait exceeds a specified amount of time.
To specify a timeout value:
Open the dm_prov_telco configuration file (BRM_Home/sys/dm_prov_telco/pin.conf) in a text editor.
Set the prov_timeout entry to the amount of time, in seconds, that dm_prov_telco waits for a response from the external provisioning agent before timing out.
For example, to set the timeout value to 30 seconds, enter the following:
-dm_provision prov_timeout 30
By default, the timeout value is set to 20. If you specify 0, dm_prov_telco waits an infinite amount of time for the external provisioning agent to respond.
Save and close the file.
Stop and restart dm_prov_telco. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
By default, Services Framework provisioning generates only one service order for a particular service at a time. For example, when a customer adds a service, such as GPRS telephony, Services Framework provisioning generates a service order to activate the service. Services Framework does not generate any other service orders for that GPRS telephony service until the external provisioning agent sends a response and Services Framework updates the GPRS telephony service's status in the BRM database. This prevents the external provisioning agent from overwriting service changes or processing service orders out of order.
You can enable Services Framework provisioning to generate multiple service orders for a particular service before it receives a response from the external provisioning agent and updates the service's status. This allows you to make in-flight changes to a service's provisioning request. For example, one service order could activate a GPRS telephony service and a second service order could correct the device ID associated with the service.
Note:
When Services Framework sends multiple service orders for a particular service to the external provisioning agent, it waits until it has received a response for all requests before updating the service's status in the BRM database.To enable Services Framework provisioning to generate new service orders for a service that already has a provisioning request in process:
Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.
Add the following entry to the file:
- fm_tcf support_multiple_so 1
where:
0 prohibits Services Framework provisioning from generating new service orders for a service that already has a provisioning request in process. This is the default.
1 allows Services Framework provisioning to generate service orders for services that already have a provisioning request in process.
Save and close the file.
Restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
Use the PCM_OP_TCF_PROV_UPDATE_PROV_OBJECT opcode to update the status of a service order, based on the /config/telco/service_order_state object. Based on the updated service order, this opcode updates the status of the corresponding service, profile, or device object and possibly sub-statuses, such as those for supplementary services.