SCF Internal Concepts

3.12.1 Service Program Structure

Service Program. is build from one or several service scripts. A service script is more or less a modularity concept to divide programs in reusable and functional modules.

Whenever a service is invoked and has to be executed on the interpreter, the identity of the service needs to be determined. This in order to select the service script to execute. This function is referred to in reference 2.

This selection can be very depended on different parameters and is there-fore also implemented on the interpreter as a script, called the ACCESS service script.

A Service Program is normally structured as follows:

Figure 3.14

Service Program Structure

The ACCESS service script. determines the actual Service to execute. So whenever the interpreter is invoked, the same service script will be invoked which will determine the requested service. There is no real limi-tation on the number of scripts used to determine the service. In the exam-ple above only one script is used to determine the service but the ACCESS service script can consist of several scripts.

How many scripts that is used to specify the service itself is arbitrary. In the figure the ACCESS service script points out 4 different services of which two uses only one script, one service uses three scripts and the last one uses two scripts.

3.12.2 SIB’s and Controltypes

Service scripts are build from SIB’s instances (Service Independent Build-ing blocks), or in Ericsson terminology controltype instances. The figure below shows the functional model of the SIB.

Access

Service Script Service Scripts

Service Script

Service Scripts

Figure 3.15

Functional Model of the SIB

A SIB has the following characteristics:

• A SIB defines one complete activity/function

• A SIB definition is service independent as well as network implementa-tion independent

• SIB’s are reusable among different services

• The implementation of a SIB in the SCF and network is of no impor-tance to the service designer

A SIB has one logical inlet. via which it is activated. Depending on the specific controltype of the SIB and the different parameters/data, one out of a number of logical outlets. is selected after the SIB has completed its function. By connecting logical inlets of other SIB’s to the logical outlets, a flow of SIB’s can be executed. In this way a service script is build up, i.e.

by connecting SIB’s to each other.

The controltype determines the function of the SIB. When building a ice scripts, instances of SIB’s are created and tailored to the specific serv-ice by defining the parameters. I.e. the controltype is a servserv-ice independent function, the parameters are used to describe the function for a specific service. The parameters/data the SIB instance uses at execution can be divided in different categories:

• Process data., dynamic data which is received from the network for a specific process or set by other SIB instances in the same process.

• Service data parameters., static data specific for a service script or a service customer (i.e. the customer subscribing to the service). This data can be constants or identifiers of process data.

• Service logic parameters., static data specific for the service logic part of the service script. This data can either be constants or identifiers of

Parameters:

process data.

3.12.3 Service Script Structure

When the model is applied to real implementation, the division in service logic and service data parameters becomes obvious. Once a service script is build, it must be possible to reuse it for different services and different customers without building the script again. This is achieved by dividing the SIB instance in a service logic module. (SLM) and a service data mod-ule. (SDM), as shown in the figure below.

Figure 3.16

Service Script Structure

A script is build by defining SLM’s and connecting them to each other, each SLM is of a certain controltype. This part of the service script is called the Service Logic. and constitutes the logical connections in the service scripts (i.e. the program flow), and some fixed parameters. The service logic can be reused for different services. For each SLM a service data module must be defined (if necessary for the controltype). All those SDM’s form the service data part of the service script, and tailor the serv-ice script for a specific servserv-ice and/or customer.

The logic and data are kept together on script level by a service adminis-trator. It contains a reference table with an entry for each service logic module and a reference to the corresponding service data module. As shown below, different service administrators can refer to the same service logic, but each one has its own service data.

connections to

Figure 3.17 Service Script

Note that the above picture shows actually three different service scripts (one per service administrator) which all use the same service logic.

This structure allows for the reuse of complete service logic with different data. But the reuse of complete services for different customers requires another class of data, i.e. the part of the service that is tailored for the cus-tomer is normally very small compared to all service data of the service script. For instance call transfer will only need a C-number per customer while all other service data in the service logic program is typically the same for all customers.

Service data modules can be of different classes:

• data modules per service administrator

• global data modules, which can be used from any script by a SIB instance of the corresponding controltype.

• data modules per service customer.

The class of the data per SDM is also kept in the reference table of the service administrator and for the first two the reference to the actual serv-ice data module as well.

The reference to a Service Customer. can be determined anywhere in a service program, before the first service customer data module is encoun-tered (e.g. the access script). The Service Customer reference is estab-lished at run-time dynamically (for instance by analysing the A-number) and valid through the complete service process (not just per script).

service logic

service data service admin.

Service Script

Figure 3.18 Data Reference

Therefore a service customer has its own service data reference table inde-pendent of the service script (data of a certain Service Customer can be used in several scripts).