This chapter describes how to use the Service Lifecycle Management (SLM) feature to configure and use custom service life cycles in Oracle Communications Billing and Revenue Management (BRM).
The life cycle of a service is composed of the states and state transitions through which the service passes from its initial state to its final state.
By default, all BRM service types use the default service life cycle, which has the following statuses:
Active: The customer can perform normal service activity.
Inactive: The customer's use of the service is restricted, usually because a credit limit was exceeded, a bill was not paid, or the service is new and is waiting for provisioning. This is a temporary status.
Closed: The customer is prevented from using any aspect of the service. This status implies that the customer will not use the service again.
You cannot customize the default service life cycle. If you need a life cycle that better represents the phases of a particular service type, create a custom service life cycle for that service type. BRM includes a sample prepaid service life cycle that has the following states:
Preactive: This is the start state of the sample prepaid service life cycle. The subscriber has not yet used the service.
Active: The subscriber can perform normal service activity.
Recharge Only: The subscriber can receive calls and use free aspects of the service, but she cannot make prepaid calls. She can use top-ups to replenish the balance.
Credit Expired: The subscriber cannot make or receive calls.
Dormant: A dormant service has the same available features as an active service. If a subscriber uses a dormant service, its state automatically changes to Active.
Fraud Investigated: The service's account is being examined for evidence of fraudulent activity. The subscriber cannot make or receive calls.
Suspended: The subscriber intends to resume the service. In this state, no aspect of the service can be used.
Closed: This is the final state of the prepaid service life cycle. In this state, no aspect of the service can be used.
See "About the Sample Prepaid Service Life Cycle" for more information.
Custom service life cycles can contain any number of states and state transitions. For each state, you can specify the following:
A descriptive name
An expiration time
Rules to validate requests received in the state
The states to which the state can change
The actions that occur before and after a state transition takes place
You can associate custom life cycles with any BRM service type.
Note:
The default service life cycle status is stored in the PIN_FLD_STATUS field in /service objects. The custom service life cycle state is stored in the PIN_FLD_LIFECYCLE_STATE field of /service objects.To use custom service life cycles, do the following:
Set up BRM to support custom service life cycles:
Enable the SLM feature. See "Enabling BRM to Use Custom Service Life Cycles".
Enable the load_config utility to validate SLM configuration files. See "Enabling load_config to Validate SLM Configuration Files".
Add SLM entries to the Connection Manager (CM) pin.conf file. See "Adding SLM Entries to the CM pin.conf File".
Create a custom service life cycle. See "About Creating Custom Service Life Cycles".
Map each state in the custom service life cycle to a status in the default service life cycle. See "About Mapping States to Statuses".
Associate one or more services with the custom service life cycle. See "About Associating Services with Custom Life Cycles".
Associate account bill units with the SLM business profile. See "Associating Bill Units with the SLM Business Profile".
Enable Services Framework AAA Manager to validate AAA requests for services that use the custom life cycle. See "Validating AAA Requests for Services that Use Custom Life Cycles".
Configure Customer Center to display the names of the custom service life cycle states. See "Configuring Customer Center to Display Custom Service Life Cycle States".
To set up BRM to support custom service life cycles, do the following:
Enable the SLM feature. See "Enabling BRM to Use Custom Service Life Cycles".
Add the SLM validation entry to the load_config pin.conf file. See "Enabling load_config to Validate SLM Configuration Files".
Add entries for custom service life cycles to the CM pin.conf file. See "Adding SLM Entries to the CM pin.conf File".
By default, BRM supports only the default service life cycle.
Before you can create and use custom service life cycles, you must configure BRM to support them by enabling the customer SubscriberLifeCycle business parameter in the business_params object.
To enable BRM to use custom service life cycles:
Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed the BRM software.
Create an editable XML file for the customer parameter class by using the following command:
pin_bus_params -r BusParamsCustomer bus_params_customer.xml
This command creates the XML file named bus_params_customer.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_customer.xml.out file
Search for the following line:
<SubscriberLifeCycle>disabled</SubscriberLifeCycle>
Change disabled to enabled.
Save the file as bus_params_customer.xml.
Run the following command, which loads this change into the /config/business_params object:
pin_bus_params bus_params_customer.xml
Caution:
BRM uses the XML in this file to overwrite the existing customer 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 BRM customer 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.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
You use the load_config utility to load the following service life cycle information:
Custom service life cycles configured in the config_lifecycle_states.xml file. See "About Creating Custom Service Life Cycles" for more information.
Mapping between custom service life cycle states and the default service life cycle statuses configured in the config_service_state_map.xml file. See "About Mapping States to Statuses" for more information.
To validate those XML files, load_config needs the following entry in its pin.conf file:
- load_config validation_module libLoadValidSLM LoadValidSLM_init
If that entry is not in the utility's pin.conf file, add it before using the utility to load the XML files.
Note:
The pin.conf file is in the directory from which the utility is run. The utility is located in BRM_Home/apps/load_config. See "load_config" for more information.To support custom service life cycles, BRM needs the following entries in the CM pin.conf file:
- cm_cache fm_bill_utils_business_profile_cache
- cm_cache fm_bill_template_cache
- cm_cache fm_cust_lifecycle_config_cache
- cm_cache fm_cust_statemap_config_cache
If these entries are not in your CM pin.conf file, you must add them.
To add the CM pin.conf entries for custom service life cycles:
Open the CM pin.conf file in BRM_Home/sys/cm.
Add the following entries to the pin.conf file:
- cm_cache fm_bill_utils_business_profile_cache number_of_entries, cache_size, hash_size - cm_cache fm_bill_template_cache number_of_entries, cache_size, hash_size - cm_cache fm_cust_lifecycle_config_cache number_of_entries, cache_size, hash_size - cm_cache fm_cust_statemap_config_cache number_of_entries, cache_size, hash_size
Where
number_of_entries is the following:
For fm_bill_utils_business_profile_cache, the total number of business profiles (/config/business_profile objects), including service life cycle business profiles, that you plan to create in your system. See "About Associating Services with Custom Life Cycles" for more information.
For fm_bill_template_cache, the total number of service validation templates (/config/template/service objects), including those defined in service life cycle business profiles, that you plan to create in your system. See "About Associating Services with Custom Life Cycles" for more information.
For fm_cust_lifecycle_config_cache, the number of /config/lifecycle_states objects you plan to create in your system. Each object represents one custom service life cycle. See "About Creating Custom Service Life Cycles" for more information.
For fm_cust_statemap_config_cache, the number of /config/service_state_map objects you plan to create in your system. The only valid value is 1. See "About Mapping States to Statuses" for more information.
cache_size is the sum of the sizes of the cached objects in bytes.
hash_size is the square root of number_of_entries.
For example, if the only custom life cycle you use is the sample prepaid service life cycle and the only business profile you use is the default SLM business profile and its three service validation templates, Oracle recommends the following settings:
- cm_cache fm_bill_utils_business_profile_cache 1, 12040, 1 - cm_cache fm_bill_template_cache 3, 10240, 1 - cm_cache fm_cust_lifecycle_config_cache 1, 102400, 1 - cm_cache fm_cust_statemap_config_cache 1, 102400, 1
Save and close the file.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To create custom service life cycles, edit the service life cycle configuration file (BRM_Home/sys/data/config/config_lifecycle_states.xml). See "About the Service Life Cycle Configuration File" for more information.
By default, that file contains a sample prepaid service life cycle, which you can use as is, modify, or delete. See "About the Sample Prepaid Service Life Cycle" for more information.
After editing the configuration file, use the load_config utility to load the file's contents into a /config/lifecycle_states object in the BRM database. See "Creating Custom Service Life Cycles" for more information.
Note:
The config_lifecycle_states.xml file can contain multiple service life cycle configurations. In the XML file, each life cycle configuration is identified by its <NAME> element. When the content of the XML file is loaded into the BRM database, each life cycle configuration is put into a separate /config/lifecycle_states object. The objects are distinguished by their Portal object IDs (POIDs).The state of a service changes as the result of actions or conditions that affect the service. The actions can be triggered manually or automatically.
In custom service life cycles, state changes can be triggered by the following:
CSRs: Using Customer Center, a customer service representative (CSR) can manually perform any permitted state change. Such changes are defined in the <TRANSITIONS> child element of the <STATES> element in the config_lifecycle_states.xml file (see "About the Service Life Cycle Configuration File" for more information).
Customer Center does not allow CSRs to make unauthorized state changes. See the Customer Center Help for more information.
The first use of a service: Services that use the sample prepaid service life cycle start in the Preactive state. The first use of such services triggers the PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE helper opcode to change the state from Preactive to Active.
Any action that impacts a service balance: After a balance is adjusted or topped up, the PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE policy opcode triggers any required service state changes and updates the state expiration date (PIN_FLD_SERVICE_STATE_EXPIRATION_T field) in the /service object based on the new state's expiration period.
For example, this policy opcode supports the sample prepaid service life cycle as follows:
If the service state is Active and a balance impact causes the resources associated with the service to reach their credit limit, this policy opcode calls the PCM_OP_CUST_UPDATE_SERVICES opcode, which calls the PCM_OP_CUST_SET_STATUS opcode to change the state to Recharge Only. The state expiration time in the /service object is not updated.
If the service state is Recharge Only or Credit Expired and a balance impact replenishes the associated resources, this policy opcode calls the same opcodes to change the state to Active.
If the service state is Preactive, Active, or Credit Expired and a voucher is used to replenish the balance, this policy opcode compares the voucher's validity period with the state's expiration period. It then updates the state expiration date in the /service object based on the greater of the two periods.
Note:
Oracle recommends that top-ups not be performed in the Preactive state.If you create your own custom service life cycles, you can modify this policy opcode to trigger state changes based on different criteria.
pin_state_change: This utility performs bulk service state changes based on the state expiration time (PIN_FLD_SERVICE_STATE_EXPIRATION_T field) in /service objects).
A system administrator schedules the utility to run at a specified time each day. When the utility finds services whose state expires on the current date, it changes that state to its default next state.
Note:
The default next state is specified in the <TRANSITIONS> element whose <DEFAULT_FLAG> is set to 1 (see "About the Service Life Cycle Configuration File"). If this flag is not set to 1 in any of the transitions configured for a state, this utility does not change the state.For example, pin_state_change supports the sample prepaid service life cycle as follows:
When a service is in the Active state and it reaches its state expiration date, the utility changes the state to Recharge Only.
When a service is in the Recharge Only state and its balance is not replenished by the state's expiration date, the utility changes the state to Credit Expired.
When a service is in the Credit Expired state and its balance is not replenished by the state's expiration date, the utility changes the state to Suspended.
See "pin_state_change" for more information.
See "About Triggering Sample Prepaid State Changes" for more information.
See "Changing Account and Service Status" for more information on how service status changes are triggered.
For each life-cycle state, you can configure business rules to validate the actions that subscribers try to perform in the state. For example, the rules configured for the Recharge Only state in the sample prepaid service life cycle permit subscribers to receive calls and to use free aspects of the service, but they do not permit subscribers to make prepaid calls.
You configure business rules in the <RULES> child element of the <STATES> element in the config_lifecycle_states.xml file (see "About the Service Life Cycle Configuration File" for more information). In that file, each business rule includes the following elements:
<MODULE>: The name of the facilities module (FM) that uses the rule. (The rule is coded in the FM.)
For example, the business rules in the sample prepaid service life cycle are used by the AAA module. In that module, the PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE and PCM_OP_TCF_AAA_POL_VALIDATE_LIFECYCLE opcodes evaluate each request against the business rules configured for the service's current state and authorize or reject the request based on those rules.
<NAME>: The name of the rule as it appears in the FM.
<VALUE>: A value that indicates whether the business rule is enabled or disabled for the state.
To create and use a custom business rule:
Code the validation logic for the new rule in the appropriate policy opcode.
Include a name for the rule in the policy opcode.
Configure a <RULES> element for the rule in the appropriate service life cycle state. See "Creating Custom Service Life Cycles" for more information.
See "About the Sample Business Rules" for more information on the business rules in the sample prepaid service life cycle.
To create a custom service life cycle:
Open the config_lifecycle_states.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
Add a <ConfigObject> element to the <ObjectList> element.
In the <ConfigObject> element, specify values for the elements listed in Table 13-1, "Custom Service Life Cycle Elements".
Save and close the file.
Run the following command, which loads the config_lifecycle_states.xml file:
load_config config_lifecycle_states.xml
Important:
The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
The pin.conf file must contain the following entry:
- load_config validation_module libLoadValidSLM LoadValidSLM_init
This entry enables the utility to validate the XML file values.
If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
load_config BRM_Home/sys/data/config/config_lifecycle_states.xml
The utility converts the XML file into one or more /config/lifecycle_states objects, depending on the number of <ConfigObject> elements in the XML file. Each object contains the life cycle defined in one <ConfigObject> element.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
You configure all the custom service life cycles in your BRM system in the BRM_Home/sys/data/config/config_lifecycle_states.xml file. By default, this file contains a sample prepaid service life cycle (see "About the Sample Prepaid Service Life Cycle").
Each life cycle is defined in a <ConfigObject> element, which has the following syntax:
<ConfigObject> <DESCR>Description</DESCR> <NAME>Name</NAME> <PERMITTED_SERVICE_TYPES elem="0"> <SERVICE_TYPE>ServiceType</SERVICE_TYPE> </PERMITTED_SERVICE_TYPES> <STATES elem="0"> <INITIAL_STATE>InitialStateInteger</INITIAL_STATE> <SERVICE_STATE_EXPIRATION_T>days:hrs:mins</SERVICE_STATE_ EXPIRATION_T> <STATE_ID>StateID</STATE_ID> <STATE_NAME>StateName</STATE_NAME> <RULES elem="0"> <MODULE>Module</MODULE> <NAME>Name</NAME> <VALUE>Value</VALUE> </RULES> <TRANSITIONS elem="0"> <DEFAULT_FLAG>DefaultFlag</DEFAULT_FLAG> <NEXT_STATE>NextState</NEXT_STATE> <POST_OPCODE>PostOpcode</POST_OPCODE> <PRE_OPCODE>PreOpcode</PRE_OPCODE> </TRANSITIONS> </STATES> </ConfigObject>
Table 13-1 lists the child elements of the <ConfigObject> element:
Table 13-1 Custom Service Life Cycle Elements
| XML Element | Description | Notes |
|---|---|---|
|
DESCR |
(Optional) Character string that describes the service life cycle. |
Minimum length is 0 characters. Maximum length is 255 characters. |
|
Character string used as the name of the service life cycle. The value of this element is used in the key-value pair that associates a service with the custom service life cycle. See "About Associating Services with Custom Life Cycles". |
The name must be unique within your BRM system. Minimum length is 1 character. Maximum length is 255 characters. |
|
|
PERMITTED_SERVICE_TYPES |
Parent element of a <SERVICE_TYPE> child element. This element is mapped to the PIN_FLD_PERMITTED_SERVICE_TYPES array in the /config/lifecycle_states object. The array lists the service types to which the states in this life cycle apply. |
If you configure multiple <PERMITTED_SERVICE_TYPES> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements. Note: The array is included for your convenience. It is not used in the validation process, and it does not associate services with this life cycle. See "About Associating Services with Custom Life Cycles" for more information. |
|
SERVICE_TYPE |
Character string that specifies a service type in the PIN_FLD_PERMITTED_SERVICE_TYPES array. |
Specify any service type in your BRM system, such as /service/telco/gsm/telephony. Minimum length is 1 character. Maximum length is 255 characters. |
|
STATES |
Parent element of the child elements that define a state for this life cycle. This element is mapped to the PIN_FLD_STATES array in the /config/lifecycle_states object. The array contains all the states configured for this life cycle. |
If you configure multiple <STATES> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements. |
|
INITIAL_STATE |
Integer that specifies whether this is the initial state of the life cycle. |
Specify one of the following values:
|
|
SERVICE_STATE_EXPIRATION_T |
Character string that specifies the number of days, hours, and minutes between the time the service changes to this state and the time it automatically changes to the default next state in its life cycle. BRM uses the state's start date (PIN_FLD_LAST_STATUS_T field of the /service object) and the amount of time specified in this element to set the state's end date (PIN_FLD_STATE_EXPIRATION_T field of the /service object). |
Specify a value in one of the following formats:
Where
For example, 365:0:600 specifies 365 days, 0 hours, and 600 minutes. There are no minimum or maximum numbers for this value. |
|
Integer that identifies a state in a custom service life cycle. |
Use 109 or greater for any custom states that you create. Each state ID must be unique. The sample prepaid service life cycle uses the following state IDs:
See "About the Sample Prepaid Service Life Cycle" for more information on these states. |
|
|
Character string used as the name of the state (for example, Active). This string is mapped to the PIN_FLD_STATE_NAME field in the /config/lifecycle_states object. |
Minimum length is 1 character. Maximum length is 255 characters. Note: Values in this field are used to populate a list of service states in the Change state to field on the Change Account/Service Status panel in Customer Center. They also appear in the Current state field on that panel and in the Status column in the Services tab. When creating the string, take Customer Center UI length restrictions into consideration. |
|
|
RULES |
Parent element of the child elements that define a business rule for this state. This element is mapped to the PIN_FLD_RULES array in the /config/lifecycle_states object. The array contains all the business rules configured for this life cycle state. The rules validate the actions that subscribers try to perform in the state. For example, the rules configured for the Recharge Only state in the sample prepaid service life cycle permit subscribers to receive calls and to use free aspects of the service, but they do not permit subscribers to make prepaid calls. See "About Configuring Business Rules for Custom Service Life Cycles" and "About the Sample Business Rules" for more information. |
If you configure multiple <RULES> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements. |
|
MODULE |
Character string that identifies the facilities module (FM) that validates this rule. For example, the AAA module validates the rules configured for the sample prepaid service life cycle. |
Use any string that identifies the validating FM. This string is only informational. It does not appear in the code. Minimum length is 1 character. Maximum length is 255 characters. |
|
NAME |
Character string used as the name of the business rule (for example, REQ_ALLOWED). Note: The rule is coded in an FM. |
Use a string that matches the name of the rule as it is coded in the FM. Minimum length is 1 character. Maximum length is 255 characters. |
|
VALUE |
Character string that specifies whether the rule is enabled or disabled. |
Specify one of the following values:
|
|
Parent element of the child elements that define how this state changes to another state. This element is mapped to the PIN_FLD_TRANSITIONS array in the /config/lifecycle_states object. The array contains all the states to which this state can change. If a state is not listed in the array, the current state cannot be changed to it. For more information on how transitions are triggered, see "About Triggering State Changes in Custom Service Life Cycles". |
If you configure multiple <TRANSITIONS> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements. |
|
|
Integer that indicates whether this is the default transition for this state. When the pin_state_change utility changes a service state, it uses the PIN_FLD_NEXT_STATE whose PIN_FLD_DEFAULT_FLAG is set to 1 in the PIN_FLD_TRANSITIONS array. |
Specify one of the following values:
|
|
|
Integer that identifies the state to change the service to. |
Specify the state's unique ID (see "STATE_ID"). |
|
|
POST_OPCODE |
Integer that identifies the policy opcode you want BRM to call after the state transition occurs. In this policy opcode, you must code the action to perform immediately after a state transition occurs. For example, you might add logic to the policy opcode that notifies the subscriber to let her know that her balance is insufficient and needs to be replenished. |
Specify the opcode number of the policy opcode to run. Opcode numbers are listed in the pcm_ops.h file in BRM_Home/include directory. Enter 0 to call no opcode. |
|
PRE_OPCODE |
Integer that identifies the policy opcode you want BRM to call before the state transition occurs. In this policy opcode, you must code the action to perform immediately before a state transition occurs. For example, you might add logic to the policy opcode that notifies the subscriber to let her know that her balance is insufficient and needs to be replenished. |
Specify the opcode number of the policy opcode to run. Opcode numbers are listed in the pcm_ops.h file in BRM_Home/include directory. Enter 0 to call no opcode. |
To modify a custom service life cycle:
Open the config_lifecycle_states.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
Modify the <ConfigObject> element in which the life cycle is configured.
Important:
If you change the <NAME> element of a life cycle that services are using, you must update the value of the lifecycle_obj key in those services' validation templates in the pin_slm_business_profile.xml file. You must then reload that file.For details about editing and loading pin_slm_business_profile.xml, see "Associating Services with Custom Life Cycles".
See Table 13-1, "Custom Service Life Cycle Elements" for more information on the elements of a custom service life cycle.
Set the configMode attribute of the <ObjectList> element to one of the following values:
replace: (Default) Updates the existing /config/lifecycle_states objects.
recreate: Deletes the existing /config/lifecycle_states objects and creates new objects.
Save and close the file.
Run the following command, which loads the modified config_lifecycle_states.xml file:
load_config config_lifecycle_states.xml
Important:
The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
The pin.conf file must contain the following entry:
- load_config validation_module libLoadValidSLM LoadValidSLM_init
This entry enables the utility to validate the XML file values.
If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
load_config BRM_Home/sys/data/config/config_lifecycle_states.xml
The utility converts the XML file into one or more /config/lifecycle_states objects, depending on the number of <ConfigObject> elements in the XML file. Each object contains the life cycle defined in one <ConfigObject> element.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To delete all custom service life cycles from your BRM system, run the following command:
load_config -r lifecycle_states
WARNING:
Do not delete a life cycle that a service is using. Doing so will cause data corruption.
This command deletes all instances of the /config/lifecycle_states class from your BRM database.
See "load_config" in BRM Developer's Guide for more information.
Each service life cycle state (for example, Preactive, Active, Recharge Only, Credit Expired, Fraud Investigated, Dormant, Suspended, and Closed in the sample prepaid service life cycle) must be mapped to a status (Active, Inactive, or Closed) in the default service life cycle. This mapping supports the following:
Backward compatibility
Custom service state changes triggered by account status changes
Member service state changes triggered by subscription service status changes
Note:
You should not include both services that use the default service life cycle and services that use a custom service life cycle in a subscription group. If you do, the subscription service might be inactive while a member service is active.A state can be mapped to only one status.
A status can be mapped to multiple states.
To create state-to-status mapping for the states in all your custom service life cycles, edit the service state mapping configuration file (BRM_Home/sys/data/config/config_service_state_map.xml). See "About the Service State Mapping Configuration File" for more information.
By default, that file contains mapping for the sample prepaid service life cycle, which you can use as is, modify, or delete. See "About the Sample Service State-to-Status Mapping" for more information.
After editing the configuration file, use the load_config utility to load the file's contents into the /config/service_state_map object in the BRM database. That object contains the state-to-status mapping for every custom service life cycle in your system. See "Mapping States to Statuses" for more information.
Consider the following situation:
BRM needs a state for a service that uses a custom life cycle.
Only the service status is known.
The status is mapped to multiple states.
In this situation, BRM uses the status's default state, which is the state whose PIN_FLD_DEFAULT_FLAG field is set to 1 for that status in the /config/service_state_map object.
For example, suppose the Active (10100) status is mapped to the Active, Recharge Only, and Credit Expired states. If a state value is required for a service whose status (Active) is known but whose state is unknown, BRM uses the state in the PIN_FLD_STATES array of the /config/service_state_map object that contains the following values:
PIN_FLD_DEFAULT_FLAG = 1
PIN_FLD_STATUS = 10100
Note:
When a status is mapped to multiple states, the default flag of only one of those states can be set to 1.The states shown in Table 13-2 are configured as the status defaults for the sample prepaid service life cycle:
Table 13-2 Default States for Statuses in the Sample Prepaid Service Life Cycle
| Status | Default State |
|---|---|
|
Active |
Active |
|
Inactive |
Suspended |
|
Closed |
Closed |
Important:
Every service life cycle state defined in your system must have a transition to each status's default state. This enables BRM to complete a state transition when only the status to which the service must change is known.For example, if BRM receives a request to change a status from Active to Inactive and the current state of the service is Recharge Only, a transition from Recharge Only to Suspended (the default state for the Inactive status) must exist. If the transition is not defined, the transaction fails.
The sample prepaid service life cycle has two states that are exceptions to this rule: Preactive (the start state) and Closed (the end state).
State transitions are defined in the config_lifecycle_states.xml file. See "Creating Custom Service Life Cycles" for more information.
Important:
A custom life cycle state should not be mapped to more than one status. Each status, however, can be mapped to multiple states.To create state-to-status mapping:
Open the config_service_state_map.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
Add a <States> element to the <ConfigObject> element.
In the <ConfigObject> element, specify values for the elements listed in Table 13-3, "Service State Mapping Elements".
Save and close the file.
Run the following command, which loads the changes into the /config/service_state_map object in the BRM database:
load_config config_service_state_map.xml
Important:
The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
The pin.conf file must contain the following entry:
- load_config validation_module libLoadValidSLM LoadValidSLM_init
This entry enables the utility to validate the XML file values.
If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
load_config BRM_Home/sys/data/config/config_service_state_map.xml
The utility converts the XML file into one /config/service_state_map object.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
You configure the state-to-status mapping for the states in all your custom service life cycles in the BRM_Home/sys/data/config/config_service_state_map.xml file. By default, this file contains mapping for the sample prepaid service life cycle (see "About the Sample Prepaid Service Life Cycle").
The mapping for each service life cycle state in your BRM system is configured in a <States> element, which has the following syntax:
<ObjectList>
<ConfigObject>
<DESCR>Description</DESCR>
<NAME>Name</NAME>
<STATES elem="0">
<DEFAULT_FLAG>DefaultFlag</DEFAULT_FLAG>
<LIFECYCLE_STATE>LifeCycleStateNumber</LIFECYCLE_STATE>
<STATUS>StatusNumber</STATUS>
<STATUS_FLAGS>StatusFlagNumber</STATUS_FLAGS>
</STATES>
</ConfigObject>
</ObjectList>
Table 13-3 lists the elements of the preceding syntax:
Table 13-3 Service State Mapping Elements
| XML Element | Description | Notes |
|---|---|---|
|
DESCR |
(Optional) Character string that describes the state-to-status mapping. |
Minimum length is 0 characters. Maximum length is 255 characters. |
|
NAME |
Character string used as the name of the mapping. |
The name must be unique within your BRM system. Minimum length is 1 character. Maximum length is 255 characters. |
|
STATES |
Parent element of the child elements that map a state to a status. This element is mapped to the PIN_FLD_STATES array in the /config/service_state_map object. The array must contain all the the service life cycle states in your system. It can contain states from multiple service life cycles. |
If you configure multiple <STATES> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements. |
|
DEFAULT_FLAG |
Integer that specifies whether this is the default state for the status to which it is mapped. A status can be mapped to multiple states, but only one of those states can be the status's default state. If a state is required when only a status value is available, BRM uses the default state for that status. |
Specify one of the following values:
|
|
LIFECYCLE_STATE |
Integer that specifies the numeric ID of a custom service state. |
Specify the unique ID of the custom service state to which this mapping applies. This ID is configured in the config_lifecycle_states.xml file (see Table 13-1, "Custom Service Life Cycle Elements"). The sample prepaid service life cycle uses the following state IDs:
See "About the Sample Prepaid Service Life Cycle" for more information on these states. |
|
STATUS |
Integer that specifies the numeric ID of the status in the default service life cycle to which this mapping applies. |
Specify one of the following status IDs:
|
|
STATUS_FLAGS |
Integer that specifies the status flag to pass when a state change occurs. The status flag specifies the reason for the change. |
When a service is reactivated, the value must match the value used in the previous state change. Note: STATUS_FLAGS values are listed in the BRM_Home/include/pin_cust.h file. |
To modify state-to-status mapping:
Open the config_service_state_map.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
Modify the <States> element in which the mapping is configured.
See Table 13-3, "Service State Mapping Elements" for more information on the elements of state-to-status mapping.
Set the configMode attribute of the <ObjectList> element to one of the following values:
replace: (Default) Updates the existing /config/service_state_map objects.
recreate: Deletes the existing /config/service_state_map objects and creates new objects.
Save and close the file.
Run the following command, which loads the changes into the /config/service_state_map object in the BRM database:
load_config config_service_state_map.xml
Important:
The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
The pin.conf file must contain the following entry:
- load_config validation_module libLoadValidSLM LoadValidSLM_init
This entry enables the utility to validate the XML file values.
If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
load_config BRM_Home/sys/data/config/config_service_state_map.xml
The utility converts the XML file into one /config/service_state_map object.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information On reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To delete the state-to-status mapping from your BRM system, use the following load_config command:
load_config -r service_state_map
WARNING:
Do not delete mapping that a service is using. Doing so will cause data corruption.
This command deletes the /config/service_state_map object from your BRM database.
See "load_config" for more information.
A service type (/service subclass object) can be associated with only one life cycle.
By default, all service types use the default service life cycle.
To associate a service type with a custom service life cycle, you add the following key-value pair to that service's validation template in the SLM business profile:
Key: lifecycle_obj
Value: Name of the custom service life cycle (see Table 13-1, "Custom Service Life Cycle Elements")
The SLM business profile is configured in the pin_slm_business_profile.xml file. By default, it associates the /service/telco/gsm/telephony service type with the sample prepaid service life cycle (see "About the Sample Prepaid Service Life Cycle").
WARNING:
After a service type is in use in your BRM system, do not associate it with a different life cycle. If you do, state and status changes might fail and data might be corrupted.
For example, if subscribers begin purchasing the /service/telco/gsm/telephony service when it uses the default life cycle (Active, Inactive, Closed), do not later associate it with the sample prepaid life cycle.
See "Associating Services with Custom Life Cycles" for more information on editing the SLM business profile and loading it into the BRM database.
See "Managing Business Profiles" for general information about business profiles.
To associate a service type with a custom life cycle:
Open the pin_slm_business_profile.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
In the list of validation template IDs (<TemplateID> elements), add or delete the name and type of the validation template for the appropriate service.
By default, this business profile contains these validation template IDs:
<TemplateId name="ServiceTelcoGprs" type="/service/telco/gprs" /> <TemplateId name="ServiceTelcoGsm" type="/service/telco/gsm" /> <TemplateId name="ServiceTelcoGsmTel" type="/service/telco/gsm/telephony" />
See "Defining Business Profiles" for more information on <TemplateID> elements.
In the list of key values (<NameValue> elements), add or delete key-value pairs to identify the bill units (/billinfo objects) that belong to this business profile.
By default, these key values are associated with this business profile:
<NameValue key="Prepaid" value="yes" /> <NameValue key="CacheResidency" value="REALTIME" />
See "Defining Business Profiles" for more information on <NameValue> elements.
In the list of validation templates (<TemplateList> parent element), add or delete the definition of the validation template (<Template> element) for the appropriate service.
By default, these validation templates are defined in the SLM business profile:
<TemplateList> <Template name="ServiceTelcoGprs" type="/service/telco/gprs"> <Desc>Description of the template</Desc> <Iscript /> <NameValue key="Prepaid" value="yes" /> <NameValue key="CacheResidency" value="REALTIME" /> </Template> <Template name="ServiceTelcoGsm" type="/service/telco/gsm"> <Desc>Description of the template</Desc> <Iscript /> <NameValue key="Prepaid" value="yes" /> <NameValue key="CacheResidency" value="REALTIME" /> </Template> <Template name="ServiceTelcoGsmTel" type="/service/telco/gsm/ telephony"> <Desc>Description of the template</Desc> <Iscript /> <NameValue key="Prepaid" value="yes" /> <NameValue key="CacheResidency" value="REALTIME" /> <NameValue key="lifecycle_obj" value="Default Lifecycle Configuration" /> </Template> </TemplateList>
Note:
In the ServiceTelcoGsmTel template definition, the following key-value pair associates the /service/telco/gsm/telephony service with the sample prepaid service life cycle:key = lifecycle_obj
value = Default Lifecycle Configuration (the NAME value of the sample prepaid service life cycle in the default config_lifecycle_states.xml file)
See "Defining Validation Templates" for more information on the <TemplateList> and <Template> elements.
Save and close the file.
Create a /config/template/service subclass for each service type in the list of validation template IDs (<TemplateID> elements) of the slm_business_profile.xml file.
For example, to support the SLM business profile, create the following subclasses:
/config/template/service/telco/gprs
/config/template/service/telco/gsm
/config/template/service/telco/gsm/telephony
See the following for more information:
"Creating Service and Event Storable Classes" in BRM Developer's Guide
Run the following command, which loads the SLM business profile into a /config/business_profile object in the BRM database:
load_pin_business_profile pin_slm_business_profile.xml
Important:
The load_pin_business_profile utility needs a configuration (pin.conf) file in the directory from which you run the utility.
If you do not run the utility from the directory in which the XML file is located, include the complete path to the file. For example:
load_pin_business_profile BRM_Home/sys/data/config/pin_slm_business_profile.xml
See "load_pin_business_profile" for more information.
The PIN_FLD_NAME field in the /config/business_profile object containing the SLM business profile is set to SLM.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
(Optional) Make the SLM business profile your system's default business profile. See "Associating Bill Units with the SLM Business Profile".
For an account to own a service that uses a custom life cycle, the account's bill unit (/billinfo object) must be associated with the business profile in which the service is linked to the custom life cycle (see "About Associating Services with Custom Life Cycles").
By default, services are linked to custom life cycles in the SLM business profile. You can associate an account's bill unit with the SLM business profile in either of the following ways:
Make the SLM business profile your system's default business profile. In this case, when an account is created, its bill unit is automatically associated with the default business profile. See "Making the SLM Business Profile Your System's Default Business Profile" for more information.
If the SLM business profile is not the system's default business profile, you can associate the SLM business profile with the bill unit after the account is created. See "Overriding the Default Business Profile" in BRM System Administrator's Guide for more information.
To make the SLM business profile your system's default business profile:
Open the bus_params_billing.xml file in an XML editor or a text editor.
By default, the file is in the BRM_Home/sys/data/config directory.
Search the XML file for following line:
<DefaultBusinessProfile>string</DefaultBusinessProfile>
Change string to SLM (the name of the business profile configured in (pin_slm_business_profile.xml):
<DefaultBusinessProfile>SLM</DefaultBusinessProfile>
Caution:
BRM uses the XML in this file to overwrite the existing billing instance of the /config/business_params object. If you delete or modify any other parameters in the file, the changes affect the associated aspects of BRM's billing configuration.Save and close the file.
If the name of your service life cycle business profile is not SLM, do the following:
Open the bus_params_billing.xsl file in an XML editor or a text editor.
By default, the file is in the BRM_Home/xsd directory.
Search the file for the following section:
<xsl:template match="bc:DefaultBusinessProfile">
In the following lines of that section, replace SLM with the name of your service life cycle business profile:
<xsl:when test="normalize-space(text()) = 'SLM'"> <xsl:text>SLM</xsl:text>
For example, if the profile is named XYZ, the lines should look like this:
<xsl:when test="normalize-space(text()) = 'XYZ'"> <xsl:text>XYZ</xsl:text>
Close and save the file.
Go to the BRM_Home/sys/data/config directory.
Run the following command, which loads the changes into the /config/business_params object in the BRM database:
pin_bus_params bus_params_billing.xml
You should execute this command from the BRM_Home/sys/data/config directory, which includes support files used by the utility. To execute it from a different directory, see "pin_bus_params" in BRM Developer's Guide.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
Make sure the PIN_FLD_BILLINFO array is correctly populated when the account is created. See discussions about the following for more information:
PCM_OP_CUST_CREATE_ACCT opcode
PCM_OP_CUST_COMMIT_CUSTOMER opcode
PCM_OP_CUST_CREATE_CUSTOMER opcode
Creating /billinfo objects in BRM Configuring and Running Billing
See "Changing the Default Business Profile" in BRM System Administrator's Guide for more information.
When Services Framework AAA Manager performs AAA for a service that uses a custom life cycle, it must call a helper opcode during the VALIDATE_LIFECYCLE processing stage to validate the service request against the business rules configured for the current state of the service. By default, it calls the PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE helper opcode.
To enable Services Framework to do that, you must map any service that uses a custom life cycle to the appropriate AAA opcode, processing stage, and helper opcode in the AAA opcode map (/config/opcodemap/tcf object).
See "Configuring Services Framework to Call Helper Opcodes" in BRM Telco Integration for more information on creating AAA opcode mapping.
See BRM Telco Integration for more information on AAA processing stages.
To support the sample prepaid service life cycle, the following entries must be in the AAA opcode map:
Framework_Opcode: PCM_OP_TCF_AUTHORIZE Processing_Stage: VALIDATE_LIFECYCLE Opcode_Map: /service/telco/gsm/telephony, PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE Framework_Opcode: PCM_OP_TCF_AAA_ACCOUNTING Processing_Stage: VALIDATE_LIFECYCLE Opcode_Map: /service/telco/gsm/telephony, PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE Framework_Opcode: PCM_OP_TCF_AAA_STOP_ACCOUNTING Processing_Stage: VALIDATE_LIFECYCLE Opcode_Map: /service/telco/gsm/telephony, PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE
If those entries are not in the AAA opcode map, you must add them to it.
Note:
To check the entries in the AAA opcode map, display the /config/opcodemap/tcf object by using Object Browser or the testnap utility's robj command. For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.To add VALIDATE_LIFECYCLE entries for the sample prepaid service life cycle to the AAA opcode map:
Open the BRM_Home/sys/data/config/pin_config_opcodemap_tcf file in a text editor.
Add the entries to the file.
Note:
If the entries are in the file but not in the AAA opcode map, the object was not loaded into the database after the entries were added to it.Save and close the file.
Run the following command, which loads the changes into the /config/opcodemap/tcf object in the BRM database:
Note:
To replace the entire contents of the object, use the -f parameter. To append data to the object, use the -i option.
load_aaa_config_opcodemap_tcf -i|-f pin_config_opcodemap_tcf
See "load_aaa_config_opcodemap_tcf" in BRM Telco Integration for more information.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.
For more information on reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
To display the names of custom service life cycle states in Customer Center fields, lists, and tables, add the names to the CC_Home/lib/CustomizedResources.properties file, where CC_Home is the directory in which you installed Customer Center. If this file does not exist, you must create it.
Note:
The default names of the sample prepaid service life cycle states are in the CustomerCenterResources.properties file. You do not have to add them to the CustomizedResources.properties file to see them in Customer Center.To configure Customer Center to display the names of custom service life cycle states:
If your system does not have a CustomizedResources.properties file in the CC_Home/lib directory, do the following:
Copy the CCSDK_Home/CustomerCareSDK/CustCntr/custom/CustomizedResources.properties file (where CCSDK_Home is the directory in which you installed the Customer Care SDK).
Paste the copy into the CC_Home/lib directory.
Add the following entry to the CC_Home/lib/CustomizedResources.properties file:
service.state.format={0,choice,0#No change|101#Preactive|102#Active|103#Recharge Only|104#Credit Expired|105#Dormant|106#Fraud Investigated|107#Suspended|108#Closed|state_ID#state_name| . . . }
where
state_ID is an integer that identifies a state in a custom service life cycle (for example, 101). See "STATE_ID".
state_name is a character string used as the name of the state (for example, Preactive). See "STATE_NAME".
The entry must include a state_ID#state_name element for every custom life cycle state in your system, including the states in the sample prepaid service life cycle.
If you want to customize the default prepaid service life cycle names, you can do so in this entry.
Important:
By default, the CustomerCenterResources.properties file has a service.state.format entry that contains the names of the states in the sample prepaid service life cycle. The service.state.format entry in the CustomizedResources.properties file, however, overrides the entry in the CustomerCenterResources.properties file. Therefore, if you add the service.state.format entry to the CustomizedResources.properties file, make sure it includes the prepaid life cycle states.For example, suppose that you want to add two states (Telephony1 ID 109 and Telephony2 ID 110) to the prepaid service life cycle and that you created another life cycle for SMS services that has three states (SMS1 ID 111, SMS2 ID 112, SMS3 ID 113). In that case, you would add the following entry:
service.state.format={0,choice,0#No change|101#Preactive|102#Active|103#Recharge Only|104#Credit Expired|105#Dormant|106#Fraud Investigated|107#Suspended|108#Closed|109#Telephony1|110#Telephony2|111#SMS1|112#SMS2|113#SMS3}
Save and close the file.
Restart Customer Center.
The default config_lifecycle_states.xml service life cycle configuration file contains a sample life cycle for prepaid services. The life cycle has the following states:
Preactive: This is the start state of the sample prepaid service life cycle. This state indicates that the subscriber has never used the service. Typically, the service is provisioned in this state.
Active: A service automatically changes to this state when the subscriber first uses the service by making a call or sending an SMS. In this state, the service start date is set, and the subscriber can perform normal service activity.
The length of time a service is active depends on its balance, usage, and plan type. If the balance reaches its credit limit or if the Active state expires, the service state automatically changes to Recharge Only.
Recharge Only: An active service automatically changes to this state when its balance reaches its credit limit. In this state, the subscriber can receive calls and use free aspects of the service but cannot make prepaid calls. The subscriber can use top-ups to replenish the balance. If the subscriber does not replenish the balance before the state expires, the state changes to Credit Expired.
Credit Expired: A service automatically changes to this state when its Recharge Only state expires. In this state, the subscriber cannot make or receive calls. If this state expires, the state changes to Suspended.
Dormant: This state enables service providers to identify unused subscriptions and to offer subscribers incentives to resume using their services. A CSR must set this state manually through Customer Center. A dormant service has the same available features as an active service. If a subscriber uses a dormant service, its state automatically changes to Active.
Fraud Investigated: This state indicates that the service's account is being examined for evidence of fraudulent activity. A CSR must set this state manually through Customer Center. In this state, the subscriber cannot make or receive calls. This state can be changed to Active or Closed.
Suspended: This state implies that the subscriber intends to resume the service. In this state, no aspect of the service can be used. A subscriber might ask a CSR to suspend a service while she is on vacation or if she loses her mobile prepaid handset.
Closed: This is the final state of the sample prepaid service life cycle. In this state, no aspect of the service can be used.
Table 13-4 lists the triggers that initiate state changes in the sample prepaid service life cycle:
Table 13-4 Triggers for State Changes in the Sample Prepaid Service Life Cycle
| Trigger | Change Performed By | From State | To State |
|---|---|---|---|
|
First use of service |
PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE |
Preactive |
Active |
|
Balance reaches credit limit |
PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE |
Active |
Recharge Only |
|
Balance replenished |
PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE |
Recharge Only or Credit Expired |
Active |
|
State expires |
pin_state_change utility or CSR |
Recharge Only |
Credit Expired |
|
State expires |
pin_state_change utility or CSR |
Credit Expired |
Suspended |
|
State expires |
pin_state_change utility or CSR |
Suspended |
Closed |
|
Fraudulent activity suspected |
CSR |
Active |
Fraud Investigated |
|
Fraudulent activity not found |
CSR |
Fraud Investigated |
Active |
|
Fraudulent activity found |
CSR |
Fraud Investigated |
Closed |
|
State expires |
pin_state_change utility or CSR |
Active |
Recharge Only |
|
First use of service after specified period of inactivity |
PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE |
Dormant |
Active |
For an overview of state-change triggers, see "About Triggering State Changes in Custom Service Life Cycles".
The sample prepaid service life cycle includes the following business rules:
REQ_ALLOWED: Specifies whether a data usage request is allowed. This rule is evaluated by the PCM_OP_TCF_AAA_VALIDATE_LIFECYCLE opcode. If it is set to Yes, the other two sample business rules are evaluated before BRM determines whether to authorize or reject the request. If it is set to No or not set, the other two sample business rules are ignored and the request is rejected.
MO_ENABLED: Specifies whether mobile-originated calls are allowed. Values are Yes and No. This rule is evaluated by the PCM_OP_TCF_AAA_POL_VALIDATE_LIFECYCLE policy opcode, which can also apply custom rules that you configure.
MT_ENABLED: Specifies whether mobile-terminated calls are allowed. Values are Yes and No. This rule is evaluated by the PCM_OP_TCF_AAA_POL_VALIDATE_LIFECYCLE policy opcode, which can also apply custom rules that you configure.
When these rules are loaded into a /config/lifecycle_states object, they are combined into one rule called CALL_ALLOWED, whose values represent various combinations of the values of all three of the preceding rules (see Table 13-5).
Table 13-5 CALL_ALLOWED Values for the Sample Prepaid Service Life Cycle
| CALL_ALLOWED Value | MT_ENABLED | MO_ENABLED | REQ_ALLOWED |
|---|---|---|---|
|
0 |
No |
No |
No |
|
1 |
No |
No |
Yes |
|
2 |
No |
Yes |
No |
|
3 |
No |
Yes |
Yes |
|
4 |
Yes |
No |
No |
|
5 |
Yes |
No |
Yes |
|
6 |
Yes |
Yes |
No |
|
7 |
Yes |
Yes |
Yes |
For an overview of business rules and information about creating custom business rules, see "About Configuring Business Rules for Custom Service Life Cycles".
The default config_service_state_map.xml file contains the mapping shown in Table 13-6. This mapping supports the states in the sample prepaid service life cycle.
Table 13-6 State-to-Status Mapping for the Sample Prepaid Service Life Cycle
| <LIFECYCLE_STATE> | <DEFAULT_FLAG> | <STATUS> | <STATUS_FLAGS> |
|---|---|---|---|
|
101 (Preactive) |
0 |
10102 (Inactive) |
0 |
|
102 (Active) |
1 |
10100 (Active) |
0 |
|
103 (Recharge Only) |
0 |
10100 (Active) |
0 |
|
104 (Credit Expired) |
0 |
10100 (Active) |
0 |
|
105 (Dormant) |
0 |
10100 (Active) |
0 |
|
106 (Fraud Investigated) |
0 |
10100 (Active) |
0 |
|
107 (Suspended) |
1 |
10102 (Inactive) |
0 |
|
108 (Closed) |
1 |
10103 (Closed) |
0 |
See "About Mapping States to Statuses" for more information on service state-to-status mapping.