IBM Tivoli Netcool Service Quality Manager Data Mediation Gateway Development

58 IBM Tivoli Netcool Service Quality Manager Data Mediation Gateway Development

The original parser has time stamps in the data block, but we move it to the

header. So, instead of using the $d_ref variables, we use the $h_ref variables.

This change is shown in Example 3-9 for the EngineConfig.pm file.

Example 3-9 Generic CSV engine time rounding settings in EngineConfig.pm

$h_ref->{startTime} = timeRounding($h_ref->{startTime});

$h_ref->{endTime} = timeRounding($h_ref->{endTime});

if($h_ref->{startTime} == $h_ref->{endTime}){

$h_ref->{endTime}= $h_ref->{endTime} + 900;

}

In every vendor gateway, there is specific documentation that has more details

about the available configuration options. Some of the configuration options we

have discussed for Generic CSV can be found in the Generic CSV User Guide

packaged with the installation.

3.5 Developing the post parser configuration for

Motorola GGSN

The post parser configuration is where the majority of the development takes

place. We have to modify this configuration to generate a CSV output file instead

of a LIF file. We want to produce a CSV file for the adapter in the GPRS Core

GGSN PM service solution. This configuration will be done in the UserConfig.pm

file.

Our solution is discussed in these sections:

򐂰 “Manipulating the data in the PERLIZE post parser rule” on page 58

򐂰 “Outputting data in the CSV format using the PIF_2_CSV rule” on page 63

3.5.1 Manipulating the data in the PERLIZE post parser rule

According to 3.1, “Identifying the data source” on page 44, we have an idea of

how to generate the required data from the raw data, either through direct

one-to-one, or many-to-one mappings. This mapping relationship, which is

created by renaming existing data and calculations, does not seem to be directly

available with the standard post parser rule.

Chapter 3. Gateway development 59

We can created these mappings by using the PERLIZE rule, which provides

advanced customized data manipulation in header and data blocks. By enabling

debug mode, we can see the first level PIF (see “Sample first level PIF data file”

on page 76 for more information).

From our previous gateway parser engine configurations, we understand some

data resides in the header and data block section. The purpose of having header

data is because it is common information that can be used for all other data block

sections, so they would not need to be repeated within each data block section.

Eventually, the combination of a header and each data block section will form

one record, or row, in the CSV file format. The PERLIZE rule allows manipulation

of the data in header and block sections.

We decide how to manipulate the data from the PIF file as follows:

򐂰 Input to the PERLIZE rule is defined with the INPUT_FILE_DESCRIPTION

option, as shown in see Example 3-10. We also show how the PERLIZE rule

is called by simply defining the RULE_TYPE option. The RULE_DESC option

is mainly a description, so this rule can be easily searched for when

performing auditing or logging, because sometimes the same rule type may

be used more than once.

Example 3-10 Matching the PIF file name for the PERLIZE rule in UserConfig.pm

RULE_TYPE => 'PERLIZE',

RULE_DESC => 'Manipulating Motorola GGSN Data',

INPUT_FILE_DESCRIPTION => '^*-#-I.pif$',

򐂰 Header manipulation

In the header, there are several changes that we want to perform:

– We would like to change the time format for startTime and endTime to the

format YYYYMMDD.hhmm. Currently, startTime and endTime information only

includes the time, but does not include date information, which has to be

created by combining the time with the day. To combine them, a

conversion to UNIX® date time is done and then converted to the desired

format. The Date::Manip Perl libraries should be included to allow this date

and time manipulation.

– The startTime and endTime fields use prefixes that conform to the naming

convention of the output file discussed in “GPRS Core GGSN PM CSV file

naming convention” on page 47.

– We want to rename the field from systemName to GGSNName. Copy the

same data from the old field name to a new field name. Then the old data

field, which is not necessary, is removed with the

REDUNDANT_HEADER_COUNTERS option.