up

previous
next
Show "Changes on this Page"
My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Description

Description
The mediation device represents the interface between BSCS applications and the network. It
consists of a generic component and a component that has to be adapted for the requirements of
each switch vendor. Generic Mediation Device (GMD) represents the generic component and is
independent of switch vendors and hardware.
GMD is based on a client-server architecture. It establishes a platform on which vendor-specific
mediation devices can be coupled with BSCS without being effected by the BSCS-internal
application logic and data formats.
GMD forwards changes that are requested by the customer care system to either the appropriate
components of BSCS, to the network or to both of them depending on the type of request.
Typically, there are two types of change requests:

contract-related requests
Change requests relating to contract and service changes, including changes to the
resources assigned to a contract.
Examples for contract-related requests are the suspension of a contract, the activation of a
new service assigned to a contract, the deletion of microcells assigned to the contract and
so on.
Most of the changes in contract-related requests have to be provisioned to the network,
such as a contract activation or the change of an MSISDN. Therefore, these contractrelated requests are also referred to as network-related requests.

customer-related requests
Change requests for which 'customer' is the managed object of the request, such as the
creation of a customer or a change in the familiy assignment of a customer.
Provisioning to the network is not required for this type of request. The information has
to be made available to the appropriate BSCS applications only.

For more information on the types of messages that GMD creates for the network and the various
BSCS applications, refer to the Architecture section.
Details on the data flow between the components of GMD and on the processing logic of these
components can be found in the Processing Logic section.
GMD connects to LEM and enquires, whether a license is present and, if so, whether
Licensing GMD functions have to be suspended because of exceeded license limits. GMD can
suspend the following functions:

contract activations - GMD action ID = 1

contract reactivations - GMD action ID = 3

When a function is suspended, the corresponding request is suspended, too. Suspended requests
can be processed using the GMDLRD process.
When a request is part of a complex request chain, but its processing is not commenced because
of licensing issues, all requests of the complex request chain are processed except for those that
are directly dependent on the suspended request.
up
previous
next
Send us your feedback
Open this page in a new window for bookmarking
Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights reserved.

Usually, change requests are initiated by a client of Customer Management Server (CMS), such
as Customer Center (CX). CMS writes the requests in the GMD request table (MDSRRTAB)
where they can be picked up by GMD.
If horizontal scalability of rating applications is used, requests for the network provisioning of
family group information can be created by Event Handler (EVH). These provisioning actions
are required if a customer has moved from one family group to another and the rating of the new
family group is done by a different rating instance. The creation of a change request by EVH is
triggered by PRIH if it detects a mismatch between the family group information in the incoming
CDRs and the family group partitioning in the system.
GMD regularly polls this table and forwards the requests according to the request type:

network-related changes to contracts and services are forwarded to the network

provisioning system by means of EDIFACT messages

customer-related changes as well as contract-related changes that are relevant for the
rating applications are forwarded to RDH by means of reference data records (RDRs)

offline charging requests are created for contract activations

The one-time charges and the first recurring charge (if that has to be paid in advance) are
forwarded to Recurring Charge Handler (RCH) by means of reference data records
(RDRs).
For details on the RCH processing of these records, refer to Charges Resulting From
Contract Activation.

for service activations in existing contracts, charge reservations for the one-time charges
and the first advance recurring charge, confirmations or cancellations for the reserved
balance amounts as well as charging requests are forwarded to the online charging chain
(starting with Call Control Gateway, CCGW) by means of usage data records (UDRs)
For details about the communication between GMD and CCGW for this scenario, refer to
One-time and Recurring Charges in the Online Charging functional area.

RDRs for successfully finished contract-related requests are sent to Order Management
Server (OMS)

customer-related changes in the context of extraordinary free units granted in CX or CMS

are forwarded to Rate Load Handler (RLH) by means of RDRs

If GMD is running in the MVNO instance of an MVNO/MVNE environment, the contents of

the EDIFACT message has to be evaluated by the network provisioning system in order to
replicate the changes of the MVNO instance in the MVNE instance. For details on the
provisioning workflow to be implemented in an MVNO/MVNE environment, refer to
Provisioning in the Multicompany Deployment (MVNO/MVNE) concept.
The commands directed to the external network provisioning system are usually generated by
GMD. GMD also accepts transparent mode requests; that is, it hands over command strings to
the provisioning system without checking the contents. Therefore, BSCS online applications can
directly instruct the external network provisioning system, even if GMD does not know the
required command syntax.

Multiple instances of all GMD processes can run in parallel to increase the performance of GMD
and to support the high availability of the applications in the customer care functional area.
Processing Logic

The data flow between GMD components is as follows:

1. GMD Command Generator (GMDCOM) retrieves new requests from the database.
If a request has been marked to require preprocessing by GMD Extension (GMDEXT),
the requests are retrieved and processed by GMDEXT first and are then sent to
GMDCOM to continue the standard processing chain.
2. GMCCOM creates the required messages, as specified by Customer Management Server
(CMS) during creation of the request in the GMD request table.
3. Depending on the type of message, GMDCOM forwards the message to the next process
in the data flow:

o EDIFACT messages are sent to the network provisioning system.

If an error occurs in the transmission, an EDIFACT command file is written to be
able to retry the sending of the message.
o RDRs of contract-related requests are written to the file system, so that they can
be written to DaTA after the corresponding network request has successfully been
completed.
o RDRs of customer-related requests are directly written to DaTA.
4. When the EDIFACT response summarizing the executed actions is received from the
network, GMD Request Response Parser (GMDRRS) converts the EDIFACT message to
a file and sends an acknowledgement about the success or the failure of the processing to
the network.
5. GMD Response Parser (GMDRES) retrieves the response file, parses it and inserts the
response details into the database.
6. If an RDR is required for a contract-related action, GMDRES converts the RDR file into
an RDR message and writes it to DaTA.
7. In addition to that, an RDR is sent to Order Management Server (OMS ) to indicate the
successful completion of a contract-related request.
8. GMDRES finishes the request.
o If a request has been marked to require postprocessing by GMD Extension
(GMDEXT), GMDRES hands over control to GMDEXT before it finishes the
request. When GMDEXT postprocessing is finished, control is handed back to
GMDRES to finish the request processing as in the standard processing chain.
o If the action was a family change, the request is finished by GMDRESDaTA,
which waits for the acknowledgement RDR for the family change before it
actually finishes the request in the database.
All GMD components involved in the request processing update the request status in the
database according to the currently processed step in the data flow. If an error occurred in the
processing, the request status is set to '1' (error) and GMD Recovery Process (GMDREC) tries to
recover the failed request so that the processing of the request can be tried again.
If license limits are exceeded, contract activation or contract reactivation functions can be
suspended.
Administration
Tools
In addition to the components mentioned above, several tools exist to
facilitate GMD administration. For more information, refer to Administration

Tools.
up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Extension (GMDEXT)

GMD Extension (GMDEXT)

GMD Extension (GMDEXT) is a generic GMD component that can perform tasks before
GMDCOM starts working on a request (GMDEXT preprocessing) or before GMDRES finishes a
request (GMDEXT postprocessing).

preprocessing - GMDEXT processes the request before GMDCOM. Once the

preprocessing is complete, GMDCOM continues the regular provisioning.

postprocessing - GMDRES does not complete the request, but forwards it to

GMDEXT. Once GMDEXT completes post-processing, it returns the request to
GMDRES.

mixed mode - GMDEXT switches between prepocessing and postprocessing

as follows:
o

GMDEXT fetches up to n postprocessing-relevant requests from

MDSRRTAB and processes these.

When the processing of these requests is finished, GMDEXT retrieves

the next set of requests to be processed.

If less than n postprocessing-relevant requests can be found in

MDSRRTAB, GMDEXT switches to preprocessing scope. If n
postprocessing-relevant requests can be found in MDSRRTAB, GMDEXT
stays in postprocessing scope.
o

In preprocessing scope GMDEXT fetches up to n preprocessing-relevant

requests from MDSRRTAB and processes these.

The scope is switched back to postprocessing, even if more

preprocessing requests exist.

GMDEXT can either run as a sender of UDS records (send mode) or as a receiver
of UDS records (receive mode).

GMDEXT
Modes

If a GMDEXT instance runs in receive mode, it reads UDS records from a dedicated message
profile. There will be a subprofile to distinguish UDS records relating to the preprocessing scope
and UDS records relating to the postprocessing scope to ensure that the records are routed to the
correct GMDEXT instance.
For GMDEXT in send mode, the following load balancing issue has to be kept in mind: A
situation has to be avoided in which a preprocessing GMDEXT sends more records into the
system than a postprocessing GMDEXT can handle. If there are multiple instances of GMDEXT,
it is the responsibility of the integrator to set up an appropriate amount of processes for each
scope.
Processing The processing logic below contains the steps of both GMDEXT processing
modes and also of both GMDEXT scopes.
Logic

1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdext.<host name>.<pid>.running

2. Creates a log file GMDEXT.<host name>.<pid>.log in the <work>/LOG directory.

3. Fetches requests waiting for GMDEXT processing from the MDSRRTAB table.
By default, 50 requests are retrieved at a time. The number of requests can
be configured with the -n command line option. The following criteria have to
be met by the requests:
o

the request has one of the following statuses: 2 ('new request'), 10

('processing required for a failed request'), 15 ('bypassed')

GMDEXT preprocessing or postprocesing is required (that is,

GMDEXT_TASK is not NULL)

GMDEXT has not processed the request yet (that is, EXT_SENT is NULL)

4. Initializes the request processing by copying the preprocessing and

postprocessing tasks for the request to the MDSRRTAB table. GMDEXT
retrieves the internal names for these tasks from the GMDEXT_PROCESSING
table, by means of the value specified in MDSRRTAB.GMDEXT_TASK.
GMDEXT is used for the tasks listed below. For details, refer to the
corresponding subsections:
o

activation of additional services for existing contracts, refer to Service

Activation for Existing Contracts

online charging requests without network provisioning, refer to

Charging Requests

contract takeovers in the context of initial activation of preactivated

prepaid contracts, refer to Contract Takeover

5. Creates UDS records as defined in the specific preprocessing task required for
the request and waits for a reply.
To indicate that GMDEXT has sent the request and is now waiting for a reply,
the EXT_SENT flag is set for the request.
6. When the acknowledgement is received, GMDEXT processes the
acknowledgement as defined in the preprocessing task and sets the
EXT_RECEIVED flag to indicate that GMDEXT preprocessing is finished.
7. GMDCOM continues the processing of the request and the processing steps of
the standard GMD processing chain are carried out.
8. Just before the standard GMD processing chain is finished, that is, before
GMDRES performs 'finish request' on the database, GMDRES hands over
control to GMDEXT for postprocessing.
9. GMDEXT can identifies requests that are ready for postprocessing by means
of the RES_PAUSED column.
10.GMDEXT evaluates if the processing was successful or not (by means of the
value in the RES_PAUSED column), creates UDS records as defined in the
specific postprocessing task required for the request and waits for a reply.
To indicate that GMDEXT has sent the request and is now waiting for a reply,
the EXT_SENT flag is set for the request.

11.When there is a problem with connecting to the BSCS database (severity '1'),
a reconnect can be attempted. You can set up reconnect options in the
RAC_Setup.xml registry file. The following options can be set:
o

Wait time for reconnect

Total time for reconnect

Total number of reconnect attempts

12.When the acknowledgement is received, GMDEXT processes the

acknowledgement as defined in the postprocessing task and sets the
EXT_RECEIVED flag to indicate that GMDEXT preprocessing is finished.
13.GMDRES finishes the processing of the request.
Service Activation for Existing Contracts

To support one-time and recurring charging for prepaid services, GMD enables coupling of
provisioning and charging. This means that a prepaid contract is charged upon service activation,
provided that the service activation has been successful. This is achieved by using GMD
Extension (GMDEXT).

Preprocessi GMDEXT performs the following preprocessing tasks before the processing of the
ng

service activation request is started in GMDCOM:

1. GMDEXT (in 'send mode') creates a reservation UDR for the online charging
chain and sends it to Call Control Gateway (CCGW).
2. To indicate that the 'send' step of the preprocessing task has been
completed, GMDEXT sets the EXT_SENT flag in MDSRRTAB.
3. GMDEXT (in 'receive mode') waits for an acknowledgement of the charge
reservation.
4. GMDEXT marks the preprocessing of the request as finished by setting the
EXT_RECEIVED flag in MDSRRTAB.

Processing of the request continues in the other GMD components: GMDCOM initiates the
network provisioning of the service activation and after the response has been received and
registered by GMDRRS, GMDRES updates the database with the requested changes and hands
over control to GMDEXT for the postprocessing task. GMDRES forwards the result of the GMD
processing to GMDEXT by means of the RES_PAUSED column in MDSRRTAB. GMDRES
pauses until after postprocessing.
Postprocessi GMDEXT performs the following postprocessing tasks to confirm or cancel the
charge reservation made in the preprocessing step.
ng

1. GMDEXT (in 'send' mode) evaluates the value of the RES_PAUSED column set
by GMDRES.
o

If the network provisioning and the request processing were successful,

GMDEXT confirms the charge reservations made in the preprocessing
step.

If the network provisioning or anything else in the request processing

has failed, GMDEXT cancels the charge reservations.

2. To indicate that the 'send' step of the postprocessing task has been
completed, GMDEXT sets the EXT_SENT flag in MDSRRTAB.
3. GMDEXT (in 'receive' mode) waits for an acknowledgement.
o

If an error occurs during the reservation confirmation, GMDEXT creates

a forced charge UDR, which is a copy of the original reservation UDR
sent to CCGW, but this time with the the 'charge regardless' flag set to
ensure that the charge is applied no matter if there is credit left in the
balance or not.

If no error occured and depending on the business case, a DRR for an

SMS can be created.

4. GMDEXT marks the postprocessing of the request as finished by setting the

EXT_RECEIVED flag in MDSRRTAB.

The processing of the request continues in GMDRES, which finishes the request.
Contract Takeover

In GMD, a contract takeover is split into two requests: first, the contract of the old contract
owner is deactivated and next, the contract of the new contract owner is activated. To make sure
that the processing of the two requests is linked, the requests are represented by means of a GMD
parent-child request. That means that only after the parent request for the contract deactivation
has been finished, GMDCOM starts processing the child request for the contract activation.
The request 'deactivation for contract takeover' (action ID 59), does not require GMDEXT
processing. GMD sends an RDR to the rating applications and finishes the request. Network
provisioning is not required for the change of the contract owner.
The request 'activation for contract takeover' (action ID 60) requires GMDEXT processing,
because the RDR for contract activation should only be created after a snapshot of the balances
related to the deactivated contract has been written to the file system. The balance snapshot is
forwarded to GMD by means of a balance information record (BIR).
Preprocessi GMDEXT performs the following preprocessing tasks before the RDRs for an
activation request of a contract takeover action are sent:
ng

1. GMDEXT (in 'receive' mode) waits for a BIR from Reference Data Handler
(RDH) for CCH.
2. When such a record arrives, GMDEXT initializes the corresponding request by
copying the start parameters for the related action from
GMDEXT_PROCESSING to MDSRRTAB.
3. GMDEXT writes the BIR to the file system (to the <work>/EDI/COMMAND
directory).
The following file naming conventions are used: <request number>.bir
4. GMDEXT marks the preprocessing of the request as finished by setting the
EXT_SENT and EXT_RECEIVED flags in MDSRRTAB.

Processing of the request continues in the other GMD components: GMDCOM writes an RDR
for contract activation to the file system and GMDRES creates an RDR for the rating
applications as well as a multi-message for cost control that combines the BIR information and
the RDR information (both read from the file system).
Postprocessing No postprocessing is performed for this kind of GMD action.
up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.

up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Command Generator (GMDCOM)

GMD Command Generator (GMDCOM)

GMD Command Generator (GMDCOM) converts requests created by the customer care system
to either EDIFACT messages that are transferred to the external network provisioning system
using TCP/IP connect, or to RDRs that are written to DaTA to be picked up by the appropriate
rating and cost control applications.
The type of messages to be created for a specific request are specified as part of the request
details in the GMD request table MDSRRTAB.
For the creation and the processing of the requests, GMDCOM distinguishes between contactrelated requests and customer-related requests. A request is considered to be a customer-related
request if the managed object of the action is 'CUSTOMER' (that is, if
GMD_ACTION.MO_LEVEL = 'CUSTOMER'). All other requests are considered to be contractrelated.
For contract-related requests GMDCOM creates the following messages:

EDIFACT messages
Most of the contract-related actions are provisioning-relevant, that is,
EDIFACT messages have to be sent to the network provisioning system.
If GMD is running in a multiple-instance MVNO/MVNE environment, all
contract-related changes in the MVNO instance have to be provisioned to the
network and the contract and service changes have to be replicated in the
MVNE instance.
In the MVNE instance, no EDIFACT messages are created for contract-related
requests, if GMDCOM detects that a request originates from an MVNO
instance. The originator of the request can be determined by means of the
request code, which is unique for the whole MVNO/MVNE environment. For
details on the provisioning workflow required to synchronize the MVNE
instance with the contract-related changes made in the MVNO instance, refer
to Provisioning in the Multicompany Deployment (MVNO/MVNE) concept.

RDRs

In addition to being provisioning-relevant, contract-related actions may be

rating-relevant as well, that is, RDRs have to be created for applications of
the rating and cost control area.
The RDRs are not written to DaTA directly. GMDCOM writes them to the file
system and only after the successful response has been received from the
network, GMDRES writes the RDRs to DaTA.

For customer-related requests GMDCOM creates RDRs and applies the following processing
steps:

For changes to the family assignment of a customer (action ID 47, 'familiy

change'): Creates an RDR and sends it to Reference Data Handler (RDH ),
which makes the information available to Rate Input Handler (RIH) and Cost
Control Handler (CCH). For details on the processing steps in RDH, refer to
Processing Logic in the RDH documentation.
The familiy change request remains in pending status until GMDRESDaTA
receives the acknowledgement messages and finishes the request.

For all other customer-related requests, GMDCOM writes the RDRs to DaTA
and finishes the request.

GMDCOM periodically enquires the License Manager whether license limits are exceeded and,
therefore, certain functions must be suspended.
At least one instance of GMDCOM has to run. Multiple GMDCOM instances can run in parallel.
No special configuration is needed. For details on how to start the GMD environment, refer to
Starting and Stopping.
Processing Logic The processing logic of each GMDCOM instance is as follows:
1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdcom.<host name>.<pid>.running

2. Creates a log file GMDCOM.<host name>.<pid>.log in the <work>/LOG directory.

3. Loads the market-specific configuration settings from the GMD_MPDSCTAB
table.
4. Fetches requests waiting for GMDCOM processing from the MDSRRTAB table.
By default, 50 requests are retrieved at a time. The number of requests can
be configured with the -n command line option.
The following criteria have to be met by the requests:

The request is new (status '2') or the sending of the EDIFACT message
failed for the request and has to be retried (status '10').

No other GMD process is working on the request (that is,

MDSRRTAB.WORKER_PID is empty).

The execution date for the request has been reached (that is,
MDSRRTAB.ACTION_DATE is less than or equal to the current date).

The request must not call for an action that is currently suspended
because of exceeded license limits.

If the switch that the request should be forwarded to is down or if there are
other pending requests for the related contract, the request will not be
processed by GMDCOM.
If no requests can be found for processing, GMDCOM enters in a configurable
sleep period (the default length is 1 second) and tries to retrieve requests
again. After 10 consecutive sleep periods, the sleep interval is increased by a
factor of 10.
5. Enters the process ID and the host name in MDSRRTAB, so that the retrieved
requests are marked as 'in process'.
6. For each of the requests retrieved from the database, GMDCOM performs the
following actions, depending on the requst status:
o

For new requests (that is, requests in status '2'), GMDCOM creates a
request log file and translates the request into the required message
formats (EDIFACT, RDR or both), as specficied in MDSRRTAB.

For requests for which the sending of the EDIFACT message failed (that
is, requests in staus '10'), GMDCOM reads the EDIFACT file referenced
in the log file of the request and tries to resend it.

7. For contract-related changes that require provisioning to the network, the

EDIFACT message is sent to the network provisioning system via TCP/IP. If
RDRs have to be sent in addition to the EDIFACT message, the RDR is written
to the file system (<work>/EDI/COMMAND directory), so that GMDRES can write
the RDR to DaTA after a successful response from the HLR has been received.
o

If the sending of the EDIFACT message was successful, the request

status is set to '4' (waiting for answer from network provisioning
system).

If an error occured in the connection to the network provisioning

system, the request status is set to '1' (error) and the EDIFACT

message is written to the file system (to the <work>/EDI/COMMAND

directory).
After GMDREC has analyzed the error and has set the status to '10',
GMDCOM can pick up the EDIFACT message from this directory again
and can try to resend it.
8. When there is a problem with connecting to the BSCS database (severity '1'),
a reconnect can be attempted. You can set up reconnect options in the
RAC_Setup.xml registry file. The following options can be set:
o

Wait time for reconnect

Total time for reconnect

Total number of reconnect attempts

9. For contract-related changes that require RDRs only, the RDR is written to the
file system (to the <work>/EDI/COMMAND directory) and the status is set to '16'
so that the RDR will be writtten to DaTA by GMDRES.
10.RDRs related to a family change (action ID 47) are sent to DaTA and the
request remains in pending status until GMDRESDaTA has successfully
processed the response.
11.RDRs of other customer-related requests are sent to DaTA and the request is
finished directly.
12.For each processed request, GMDCOM removes the process ID from
MDSRRTAB.WORKER_PID and the host name from
MDSRRTAB.WORKER_HOST , to indicate that the request is no longer 'in
process'.
13.After all requests retrieved from the database have been processed,
GMDCOM returns to step 4 and retrieves new requests for processing.

GMDCOM supervises license limits by periodically connecting to the License Manager.

Licens
The period is set during startup of GMDCOM by a command line option and depends
es

on whether license limits are currently exceeded or not:

If license limits are not exceeded, the period must be within a range from 60
seconds to 86.400 seconds. This period is set using the -lps command line
option.

If license limits are exceeded, the period must be within a range from 60
seconds to 3.600 seconds. This period is set using the -lpf command line
option.

If a license limit is exceeded, the corresponding function - which is either a contract activation or
a contract reactivation request - can be suspended.
GMDCOM requires host and port of the License Manager to be able to connect. Host and port
information can be configured using the SENTINEL_HOST and SENTINEL_PORT environment
variables or can be set within the LICENSE_CONFIG database table.
up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.
up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Request Response Server (GMDRRS)

GMD Request Response Server (GMDRRS)

GMD Request Response Server (GMDRRS) receives EDIFACT response messages from the
external network provisioning system. Multiple instances of GMDRRS can be started. A
dedicated TCP/IP port has to be defined for each instance of GMDRRS.
To do so, a new line has to be inserted into the /etc/services file and the host and port of each
GMDRRS instance have to be configured in the MSDSVTAB table. For more information on the
configuration of GMD, refer to MSDSVTAB in the GMD Configuration Options. The
information about the host and port for the TCP/IP connection of the network provisioning
system to GMDRRS has to be made available to the network provisioning system as well.
If Network Provisioning Extension (NPX) is used as the network provisioning system, the
configuration of the GMDRRS connection details has to be made in the VMD_SERVERS
configuration table.
At least one instance of GMDRRS has to run. An instance of GMDRRS is started on one of the
configured ports by means of the mandatory command line parameter -srv <SRV_ID>. For
details on how to start the GMD environment, refer to Starting and Stopping.
A specific instance of GMDRRS is not linked to a specific instance of the network provisioning
system or to specific requests. Any running instance of GMDRRS can handle any incoming
EDIFACT acknowledgement. No concurrency problems between multiple instances of
GMDRRS will occur because there is only a single EDIFACT acknowledgement per request.
When sending EDIFACT messages to the network provisioning system, GMD Command
Generator (GMDCOM) includes the identifier (SRV_ID) of a GMDRRS instance into the
EDIFACT. This information can be used by the external network provisioning system to select
the GMDRRS instance to which the EDIFACT response message is sent.
If NPX is used as the network provisioning system, the EDIFACT response is always sent to the
GMDRRS instance identied by the SRV_ID that was forwarded by GMDCOM.
Processing Logic

The processing logic of GMDRRS is as follows:

1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdrrs.<host name>.<pid>.running

2. Creates a log file GMDRRS.<host name>.<pid>.log in the <work>/LOG directory.

3. Waits until it receives an EDIFACT response message from the external
network provisioning system via TCP/IP.
4. Creates an EDIFACT response file and writes it to the <work>/EDI/RESPONSE
directory.
5. Returns positive or negative acknowledgement messages to the network
provisioning system and changes the request status accordingly:
o

If the processing was successful, GMDRRS returns a positive

acknowledgement to the network provisioning system and sets the
request status to 14 ('GMDRRS processing finished').

If an error occured, GMDRRS sends a negative acknowledgement to the

network provisioning system and sets the request status to 4 ('waiting
for response from the network provisioning system').

6. When there is a problem with connecting to the BSCS database (severity '1'),
a reconnect can be attempted. You can set up reconnect options in the
RAC_Setup.xml registry file. The following options can be set:
o

Wait time for reconnect

Total time for reconnect

Total number of reconnect attempts

7. Returns to step 3 and waits for the next EDIFACT response message from the
external network provisioning system.
up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.
up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Response Parser (GMDRES)

GMD Response Parser (GMDRES)

GMD Response Parser (GMDRES) performs the following main tasks:

parses the responses received from the network and stores the extracted
information in the database

writes RDRs from the file system to DaTA

finishes the requests in the database

sends acknowledgement messages to the provisioning system to indicate the

successful completion of MVNO/MVNE-related requests

cleans up the database and optionally also cleans up the file system

At least one instance of GMDRES has to run. Multiple GMDRES instances can run in parallel.
No special configuration is needed. For details on how to start the GMD environment, refer to
Starting and Stopping.
Processing Logic The processing logic of each GMDRES instance is as follows:
1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdres.<host name>.<pid>.running

2. Creates a log file GMDRES.<host name>.<pid>.log in the <work>/LOG directory.

3. Retrieves requests waiting for GMDRES processing from the MDSRRTAB table.
By default, 50 requests are retrieved at a time. The number of requests to be
retrieved can be configured with the -n command line option.
If no requests can be found for processing, GMDRES enters in a configurable
sleep period (the default length is 1 second) and tries to retrieve requests
again. After 10 consecutive sleep periods, the sleep interval is increased by a
factor of 10. The sleep period can be configured using the -m command line
option.
4. Enters the process ID and the host name in MDSRRTAB, so that the retrieved
requests are marked as 'in process'.
5. Parses the EDIFACT response message for the request and writes the
extracted information to the GMD_RESPONSE and GMD_DETAILED_RESPONSE
tables.
If it was not required to send an EDIFACT message for the request (that is, the
request is in status '16' ), GMDRES only inserts a new row for the request into
GMD_RESPONSE.
6. Checks the return code provided in the EDIFACT response file to see if the
processing in the external system was successful or not.
7. If an error occurred in the external system (that is, if an error code is
forwarded in the response file), GMDRES performs the following status
changes:
o

If the processing of the request cannot be retried (either because the

limit of the retry counter has been reached or because the request
response file did not allow to resend the request), the status is set to
'11'.
These requests will then be picked up by GMDREC to send memos and
notifications to the administrator.

If it is possible to retry sending the EDIFACT to the network, GMDRES

sets the status to '1' (error) and deletes the response file from the file
system.
These requests will then be picked up by GMDREC who detects that
something went wrong with the request after it had successfully been
sent. GMDREC will reset the request status to '2' (new request) so that
the GMD processing for this request starts again.

8. GMDRES continues with step 11 .

9. When there is a problem with connecting to the BSCS database (severity '1'),
a reconnect can be attempted. You can set up reconnect options in the
RAC_Setup.xml registry file. The following options can be set:
o

Wait time for reconnect

Total time for reconnect

Total number of reconnect attempts

10.If the processing of the request was successful in the external

system, GMDRES updates the BSCS database tables impacted by the
successfully processed change request.
The changes to be made had been entered as pending status changes by
CMS when it created the request. The actual changes are made by an Oracle
stored procedure as soon as the request has successfully been provisioned to
the network.
For details on the effective date that is stored for the changes, refer to
Effective Date Handling below.
11.If RDRs have to be sent for the request, GMDRES retrieves the RDR message
from the file system, updates the timestamps in the RDR to the effective date
stored in the database and writes the RDR to the relevant DaTA queues.
An exception applies to timestamps in the following RDRs or RDR parts, if
they exist for the request in question: RDRs relating to the contract snapshot
action (action ID 61): the RDRs contain history data that needs to be
forwarded to the rating applications as is. The information may not be
changed.
12.Creates RDRs for successfully finished contract-related requests and sends
them to Order Management Server (OMS).

This information is required in the workflow processing of OMS to be able to

stop the workflow while the contract-related request is being processed and
to continue the workflow as soon as the request has been finished.
13.If running in an MVNO/MVNE environment, the GMDRES instance running in
the MVNE system sends an acknowledgement message to the provisioning
system that informs the GMD instance of the MVNO system about the
successful or failed replication of contract-related changes. The address of
the TCP/IP listener for these messages has to be configured in MSDSVTAB.
If the sending of the acknowledgement message fails, GMDRES sets the
request status to '1' (error) and the RECOVER_TO_STATUS to '17' (pending
acknowledgement message). If an error occured in the processing of the
request, that is, an error which is not related to the sending of the request,
GMDRES stores the error code as ACKNOWLEDGEMENT_CODE of the request
to be able to forward the information when it tries to resend the
acknowledgement.
In the next run of GMD Recovery Process (GMDREC), the request status is set
to the requested recovery status ('17'), which will then be picked up by
GMDRES again.
14.Removes the process ID and the host name from the request to indicate that
the request is no longer 'in process' (that is, GMDRES sets
MDSRRTAB.WORKER_PID and MDSRRTAB.WORKER_HOST to NULL).
15.For each successfully finished request, GMDRES creates a memo.
16.Cleans up the database and the file system according to the configuration of
the clean up level in the GMD_MPDSCTAB configuration table:
o

All successfully processed and finished requests are moved to the GMD
history table (GMD_REQUEST_HISTORY) and removed from the GMD
request table (MDSRRTAB).

Optionally, the EDIFACT command files, EDIFACT response files and

request log files are removed from the file system.

Optionally, and in addition to the actions listed above, the request is

removed from the GMD_RESPONSE and GMD_DETAILED_RESPONSE
tables.

Depending on the defined market-specific cleanup level in the

CLEAN_UP_LEVEL column of the GMD_MPDSCTAB table clean up will be
performed on the contract level. For customer level, it cleans up using
the CLEAN_UP_LEVEL specified in MPSCFTAB.

17.Returns to step 3 if all n requests are processed.

As a rule, the date on which the changes become effective in BSCS is set to the

Effective effective date returned in the EDIFACT response file, or, if no such date is available
Date
because no EDIFACT messages were involved in the request processing, the
Handling

effective date is set to the system date of the database.

If BSCS time and network time are not synchronized, there might be situations in which the
ACTION_DATE stored in MDSRRTAB is greater than the effective date returned in the
EDIFACT message.
GMDRES always uses the greatest available date for the effective date of the changes. So, in the
situation outlined above, the ACTION_DATE set during request creation would be used and not
the effective date returned in the EDIFACT response. If the time in the HLR (and therefore the
timestamps in the call records sent to BSCS) is before the time stored as effective date, this
might lead to rating problems.
To notify the administrator about synchronization problems between BSCS time and network
time, GMDRES logs a warning in the request log file if the ACTION_DATE stored in the
database was used instead of the effective date returned in the EDIFACT response.
There is one exception to the described handling of effective dates: If an EFFECTIVE_DATE is
already available in the GMD request table, that date will in any case be used as the effective
date of the changes in the BSCS database. The EFFECTIVE_DATE can be set during request
creation in Customer Management Server (CMS), for example, when contract-related request
data is propagated from an MVNO instance to an MVNE instance.
up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.
up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Recovery Process (GMDREC)

GMD Recovery Process (GMDREC)

GMD Recovery Process (GMDREC) is responsible for the following tasks:

changing the status of locked switches if the switch unlock time has passed
and the network provisioining system has not sent a 'SWITCH UP' message
yet

changing the status of failed requests so that an appropriate GMD component

can process them again
Every GMD process that detects an error in the processing, sets the request
status to '1' (error). GMDREC uses a number of rules that evaluate the system
status and tries to determine the most appropriate status for recovering the
request.

cleaning up of blocked data by resetting the process ID and host name if the
configured request timeout has passed
Each GMD process that works on a specific request marks the request in
MDSRRTAB with the GMD process ID and the name of the host on which the
GMD process is running. In addition to that, for each change in MDSRRTAB,

each GMD process sets the timestamp to the current system time. This way,
GMDREC can determine if a request has been marked as 'in process' for
longer than the configured request timeout.
If such a situation occurs, GMDREC assumes that the related GMD process or
the server on which the GMD process has been running has crashed and
resets the request information about process ID, host name and timestamp in
the database. This way the request can be processed by another instance of
the GMD process in question.
The request timeout ist configured in MPSCFTAB, where CFCODE = '900'.

tracking the number of GMD attempts for processing a request in the error
retry counter
The maximum number of attempts for a request is configured in the
GMD_RETRY table . If the maximum number of retries is reached, the request
status is set to status '12' (GMD failure). For these requests, GMDREC sends a
notification to the system administrator.
If the maximum number of retries has been reached while trying to send the
acknowledgement message for contract provisioning in an MVNO/MVNE
environment, GMDREC sends an acknowledgement message that contains
the error that prevented the successful sending of the message.

Multiple instances of GMDREC can run in parallel. No special configuration is needed. For
details on how to start the GMD environment, refer to Starting and Stopping.
Processing Logic The processing logic of each GMDREC instance is as follows:
1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdrec.<host name>.<pid>.running

2. Creates a log file GMDREC.<host name>.<pid>.log in the <work>/LOG directory.

3. Unlocks switches for which the network provisioning system sent a 'SWITCH
DOWN' message and no 'SWITCH UP' message has been received until the
configurable switch unlock time has passed. For more information, refer to
GMD_SWITCH_STATE.
4. Resets requests for which the timeout specified in MPDSCTAB has been
exceeded.
This way, blocked data that is still marked as 'in process' although the
instance of the GMD process working on the request has crashed (or even the

whole server on which the GMD process was running) can be cleaned up so
that another instance of the same GMD process can try to continue the
processing of the request.
5. Fetches a request from the MDSRRTAB table.
The number of requests to be retrieved at once can be configured using the
-n command line option. By default, only one request is processed at a time.
6. Sends a memo and notification for requests that have reached the limit of the
error retry counter, that is, where MDSRRTAB.WORKER_PID > 0, and status =
'11' or '12' (for errors that occured in the network provisioning system or in
the GMD environment).
7. Checks if there are any requests in the database for which the status '1'
(error) has not been set, although an error must have occurred in the
processing and the request status should be changed so that request
processing continues.
Some of the most important checks are outlined below. Requests are set to
status '1' if they are older than the configured wait time and one of the
following conditions is fulfilled:
o

The request is in status '4' (waiting for response from network

provisioning system) and no GMD process is working on it (that is,
MDSRRTAB.WORKER_PID = 0), but a response file is available in the file
system.

The request is marked as 'in process' (MDSRRTAB.WORKER_PID > 0),

but the status is '2' (new request), '4' (waiting for response from the
network), '10' (failure when sending the EDIFACT to the network) or
'14' (ready to be finished by GMDRES)

8. When there is a problem with connecting to the BSCS database (severity '1'),
a reconnect can be attempted. You can set up reconnect options in the
RAC_Setup.xml registry file. The following options can be set:
o

Wait time for reconnect

Total time for reconnect

Total number of reconnect attempts

9. Tries to determine the most appropriate GMD component that should try to
continue the processing of failed requests. Some of the most important rules
that are evaluated are outlined below:

If the RECOVER_TO_STATUS has been set by the GMD process in which

the error occured, the request status is set to the specified status.

If there is no EDIFACT command file stored in the file system:

If no response file from the network is available, GMDREC sets the
status to '2' (new request).
If there is a response file from the network, GMDREC sets the status to
'14', so that GMDRES can pick up the response file and finish the
request.
In any case, GMDREC increments the error retry counter.

If there is an EDIFACT command file in the file system:

If no response file from the network is available, GMDREC increments
the retry counter for errors in the connection to the network
provisioning system and sets the status to '10' (sending of EDIFACT
message failed). GMDCOM will try to resend the EDIFACT message.
If there is a response file from the network, GMDREC increments the
the retry counter for general processing errors in GMD components and
sets the status to '14', so that GMDRES can pick up the response file
and finish the request.

10.Sets MDSRRTAB.WORKER_PID and MDSRRTAB.WORKER_HOST of the

processed request to 0 (the request is no longer 'in process').
11.Sleeps 10 seconds if no more failed requests are found. If no failed request
can be found in the next processing loop, the sleep interval is extended to the
maximum of 20 seconds.
12.Returns to step 3.
up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.
up

previous

next

Show "Changes on this Page"

My Pages

BSCS iX Release 3 > Applications > GMD - Generic Mediation Device > GMD Overview >
Processing Logic > GMD Response Parser DaTA (GMDRESDaTA)

GMD Response Parser DaTA (GMDRESDaTA)

GMD Response Parser for DaTA (GMDRESDaTA) is responsible for the following tasks:

Receiving acknowledgement RDRs for familiy change requests and returning

a COMMIT or CANCEL message for the change, depending on the evaluation
of the contents in the acknowledgement RDRs
The acknowledgement RDRs are sent by Reference Data Handler (RDH)
instances running for Rate Input Handler (RIH ) and for Cost Control Handler
(CCH).

Finishing family change requests.

Only after the family change request has been finished by GMDRESDaTA, new
family move requests can be created for the customer.

Multiple instances of GMDRESDaTA can be started in order to increase the performance.

Deadlock is not a problem because a customer can change the family only if there is not already
a family request pending for this customer. For details on how to start the GMD environment,
refer to Starting and Stopping.
Processing
Logic

The processing logic of each GMDRESDaTA instance is as follows:

1. Creates a PID file in the <work>/GMD directory. The name of the file is
gmdresdata.<host name>.<pid>.running

2. Creates a log file GMDRESDATA.<host name>.<pid>.log in the <work>/LOG

directory.
3. Retrieves confirmation RDRs from DaTA, which have been sent from RDH for
RIH and RDH for CCH.
4. Checks the RDR content.
o

If an RDR is corrupt, GMDRESDaTA marks it for rejection. If required,

RDRs are rejected after the processing of all other records of the DXL
transaction has been finished.
Reject reasons include: Mandatory attributes are missing, for example,
the request ID or the customer ID. There is no counterpart of the RDR
in the database, for example, the request is not found in the database
or it has already been finished.

If the record retrieved from DaTA is not an RDR, the DXL setup is
corrupt. In this case, GMDRESDaTA cannot reject the record because it
does not know all possible UDS variants and their reject-relevant
attributes (they are different for the various UDS variants). So, if
GMDRESDaTA reads a UDS record of an unknown variant, it writes an
error message to the error log file and terminates.

GMDRESDaTA does not consider how often an RDR was rejected, it processes
RDRs even if they were rejected in an earlier transaction.
5. Writes the response details to the GMD_REQUEST_KEY_VALUES table.
The keys RECEIVED_FROM_CCH and RECEIVED_FROM_RIH are used for the
values received in the acknowledgement RDRs sent by RDH for CCH and by
RDH from RIH.
6. Checks if both RDRs relating to the request have arrived and evaluates the
processing status returned in the acknowledgement RDRs.

7. Compares the content of the RDR with the records in the CUSTOMER_FAMILY
table for the current request.
8. If the processing of the request failed in one or both RDH instances,
GMDRESDaTA sets the request status in MDSRRTAB to 'failed'.
9. If the answers from both RDH instances indicated a successful processing,
GMDRESDaTA finishes the request by making the following changes in the
database:
o

MDSRRTAB: The status is updated according to the statuses used also

by the other GMD processes.

CUSTOMER_FAMILY: The COMPLETION_STATUS is set for all involved

customers according to the result of the RDR analysis. The status 0
indicates success.

GMD_REQUEST_KEY_VALUES: all entries related to the request are

deleted

GMD_REQUEST_HISTORY: After having processed the request

successfully, the request is copied from the MDSRRTAB to the
GMD_REQUEST_HISTORY table.

When the above-mentioned tables have been updated and the changes
committed, the request is no longer pending and the involved customers are
available for further family-related changes.
10.Sends an RDR answer to all RDH instances
The RDR contains a COMMIT or a CANCEL message for the family move,
depending on the two responses received from RDH for RIH and RDH for CCH.
Only if both RDH responses indicated a successful processing result, the RDR
answer will contain a commit of the family move request. In all other cases,
the family move request will be cancelled and the RDH instances will rollback
any changes that they made when processing the request.
11.Rejects RDRs for which an error occured in one of the steps above.
12.Commits the database changes as well as the DXL transaction:
DXL and the database do not have a two-phase-commit interface, therefore a
commit is performed first in the database and then in DXL.
If a commit action fails on either side, the following situations occur:

If the database commit was successful but the DXL commit failed, the
updates in the database are committed but the RDR is still in the DaTA
queue from which GMDRESDaTA is reading. It is not possible to get rid
of the RDR, therefore GMDRESDaTA terminates and writes an error
message to its error log file.

If the database commit failed, GMDRESDaTA terminates without

performing a commit in DXL and writes an error message to its error
log file. The RDR remains in the DaTA queue and is available for
reprocessing.

up

previous

next

Send us your feedback

Open this page in a new window for bookmarking

Legal Information | LHS Telekommunikation GmbH & Co. KG, 2010. All rights
reserved.