Service bundles provide a level of abstraction over the service action layer that you can use to represent marketing-level configurations. You can use service bundles when upstream systems are not capable of breaking down marketing bundles into their constituent services or providing the exact data that is required for activation.
For example, a wireless service provider may offer a basic marketing package that provides the following services:
Voice calls
Free voice mail
Free call waiting and call forwarding
These services require the following activations in the network:
Create a new subscriber (Home Location Register - HLR).
Enable authentication of the subscriber (Authentication Center - AUC).
Enable number portability (Flexible Number Router - FNR).
Create and assign a voice mailbox (Voice mail Server - VMS).
Activate the call waiting and call forwarding features (Home Location Register - HLR).
The service provider may also offer a more expensive marketing package that builds upon the basic marketing package by providing a few more advanced services, which would also require the activation of advanced features (Home Location Register - HLR).
While it is possible to model a single service action to activate each of the network services, introducing an additional level of abstraction at the service bundle level results in a less complicated and less customized service model at the service action level. Additionally, more generic service actions permit reuse of the service actions across service bundles. The following service bundle configuration could be created to implement the above examples:
Note:
In the configurations below, theC_ADD_SUBSCRIBER, C_VMS_ADD_SUB, and C_HLR_ADD_BASIC-FEATURES service actions can be reused in both the basic and advanced service bundle configurations.
SB_WIRELESS_PREPAID_ADD_SUBSCRIBER_BASIC
C_HLR_ADD_SUB
A_HLR_ADD_SUB
A_AUC_ADD_SUB
A_FNR_ADD_SUB
C_VMS_ADD_SUB
A_VMS_ADD_SUB
C_HLR_ADD_BASIC-FEATURES
A_HLR_ADD_CW
A_HLR_ADD_CF
SB_WIRELESS_PREPAID_ADD_SUBSCRIBER_ADVANCED
C_HLR_ADD_SUB
A_HLR_ADD_SUB
A_AUC_ADD_SUB
A_FNR_ADD_SUB
C_VMS_ADD_SUB
A_VMS_ADD_SUB
C_HLR_ADD_BASIC-FEATURES
A_HLR_ADD_CW
A_HLR_ADD_CF
C_HLR_ADD_ADVANCED-FEATURES
A_HLR_ADD_CFB
A_HLR_ADD_CFNRC
A_HLR_ADD_CFNRY
About Service Action Spawning Conditions
Working with Upstream Interface Parameters
Service action spawning conditions determine whether a service action executes. When you map service bundles to service actions, Design Studio assigns to each service action a spawning condition of Always (no conditions prevent the action from executing). The conditions associated with the service action must evaluate to true for the service action to execute.
The labels used in the evaluation of the service action spawning condition are those that are derived as a result of the upstream parameters to service action parameter mapping. Use the service action labels in your spawning expression.
You define the spawning conditions on the Service Bundle editor Service Actions tab. For example, you can specify that an action always execute or only if a specified parameter is present.
Also, you can define a logical expression that is used with one of the delivered spawning conditions, where ASAP executes the service action if both the out-of-the-box expression and your user-defined expression evaluate to true. The range of options available enables a service action to be executed if the service action parameter value is within a set range of values, or if the service action parameter is greater than, less than, or equal to, a specified value. You can combine multiple expressions using an AND or OR operator.
To define your own spawning logic, enable the Include Expression check box on the Service Bundle editor Service Actions tab and define a logical expression in the associated text box.
The logical expression mechanism works in cooperation with one of the out-of-the-box spawning expressions. For example, if you have specified a service action condition of Equals and have created a logical expression, both of these conditions must evaluate to true in order for the service action to be executed. If you want only the logical expression to trigger the execution of the service action, then use the action condition of Always and specify a logical expression.
The following operators can be used to define logical expressions:
| Operators | Description |
|---|---|
| AND, OR, NOT | Operators used to create compound expressions. For example:
|
| ISDEF, NOTDEF | Operators that can be used with single parameters. For example:
Note: Always use brackets with these operators. |
| >, <, >=, =<, =, != | The parameter values must be able to be converted to integers. For example:
|
| LIKE, !LIKE | String operators. The strings being evaluated must be placed inside quotation marks. It is also possible to use wildcard syntax such as the % (to specify one or more characters) and ? (acts on a single character). For example:
Note: Always use brackets with these operators. |
Logical expressions are limited to a length of 255 characters.
Logical Expression Operational Order
To specify the order of operations, use as many parentheses as needed; for example:
((A < 8) OR ((NOTDEF B) AND ((C != 3) OR (NOT (D = 9)))))
Logical Expression Error Conditions
The following error conditions that may arise as a result of the use of logical expressions:
Using the integer operator when the input parameter cannot be converted to an integer (all SRT parameters are strings initially)
The specified parameter label is not present
The evaluation of an expression fails and a SYS_ERR message is generated in the diagnostics. These errors do not fail the work order; however, the atomic action is not executed.
Note:
The syntax of complex expressions is not currently checked by Oracle Communications Design Studio but is checked by ASAP at run time.You map the parameters contained in the messages sent from upstream systems to the parameters required by the service actions associated with the service bundle. At run time, after the initial translation has occurred, SRT uses this service bundle configuration to analyze the contents of messages sent from upstream systems.
Note:
Some upstream interface parameters may not be used in the provisioning process. Upstream interface parameters can be mapped to lookups for further processing, for example to split parameters apart or to concatenate them together.To map upstream interface parameters to service action parameters, you add the parameters to the Upstream Interface list using the following methods:
Automatically, based on service action labels. When you associate service actions with the service bundle, you can use the service action labels to populate the upstream interface parameter list. Design Studio places the parameters in the parameter list on the Service Bundle editor Upstream Interface tab.
Manually, in the Service Bundle editor. If you know what the upstream labels will be but do not have a sample XML document that can be imported, the parameters can be added in manually.
By importing the upstream parameters from a sample upstream service request (in XML format). Using this method, Design Studio runs a transformation against the upstream XML file and extracts the interface parameters. The XSLT that implements the transformation must first be created by a technical resource such as a developer. See "Configuring Translations" for more information.
Lookups are required when upstream systems fail to send all of the required information needed to model service bundles (for example, the data is not fully assigned, has incorrect labels or values, and so forth). Generally, a developer is required to create the code (Java or stored procedure) for the lookup. Solution designers, however, can configure attributes of the lookups using Design Studio.
Lookups are executed by the SRT during the processing of an upstream XML service request. Lookups can be used to look up additional parameters that are required for activation of services, to format parameters so that they are compatible with service action parameters, and so forth. The lookup library contains custom lookups that are used by the SRT only. You may want to create lookups in the following situations:
The upstream system is unable to provide a network element identifier. As opposed to using ASAP's internal support for network element routings (for example, ID routing, user defined routing, and so forth), you can create a lookup to accept an identifier (such as a MSISDN or IMSI in the case of mobile services, or DN or LEN in the case of PSTN services) and return one or more network element identifiers. You can implement this lookup as a stored procedure or java method to retrieve the data from a database table.
Several parameters need to be concatenated or one parameter needs to be split apart in order to match the parameters required by one or more service actions. No database interaction is required as the algorithm is implemented inside a java method or java script.
After a technical resource creates the lookup (the stored procedure or java code that implements the lookup logic), you can define the lookup in Design Studio by describing its attribute, such as its name and input/output parameters. Existing lookups are available for use and appear in Service Bundle editor SA Parameter Map tab where they can be mapped to service action parameters. It also possible to create a series of lookups that feed parameters to each other as well.
Prior to deploying your Activation SRT cartridge to the environment, you package the required lookups in addition to service bundles and other element types.