Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-79-2128647.1
Update Date:2017-06-20
Keywords:

Solution Type  Predictive Self-Healing Sure

Solution  2128647.1 :   Performance Intelligence Center Static Enrichment File Format  


Related Items
  • Oracle Communications Performance Intelligence Center (PIC) Software
  •  
Related Categories
  • PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec PIC
  •  




In this Document
Purpose
Details
 Sections
 Enrichment by mapping
 Enrichment by copy
 File Format
 MAIN section
 MAPPING section
 COPY section
 Definitions


Applies to:

Oracle Communications Performance Intelligence Center (PIC) Software - Version 7.1 and later
Information in this document applies to any platform.

Purpose

This document explain how a static enrichment file (fse) has to be formated.

Details

The file can contain comments (a comment line starts with a sharp #).

The file’s name is important: it defines in which order the enrichments (if more than one enrichment file) will be done by the Data Server or IXP: the alphabetical order is chosen (so a file name “$0….fse” will be used before a file named “something.fse”); remember that ProTraq files enter in the same naming rule, so preferably name enrichment files with “$….fse” and ProTraq files without a starting $.

Sections

An enrichment file contains at least one MAPPING section (SECTION:MAPPING) or one COPY section (SECTION:COPY); it can contain several MAPPING or COPY sections (SECTION:MAPPING:number or SECTION:COPY:number) incrementally numbered, starting at 0. Note that in case of several MAPPING/COPY sections, the tables are used in the reverse order of their number: an xDR is first enriched according to the table with the highest number, and finally enriched according to the table with number 0.
There can also be a filter (SECTION:FILTER) letting you select which xDR may be modified by the enrichment processes.

Enrichment by mapping

This way of enriching an xDR is based on a mapping table where field values combinations are associated to field values (a combination of values, the key, is associated to a single value, the result); for each xDR to enrich, the engine will scan the xDR and extract the values of the input fields; if the combination of these values is listed in the mapping table, then, the output field is updated with the result matching this combination; if the combination cannot be found in the mapping table, the output field is updated with the default value, if it is provided; in any other case, the output field is not updated.

The INPUT instruction lists the fields used as keys; each field is separated from the other with a semi-colon; a field can be prefixed with a tilde (~) specifying that the values of that field can be declared as an interval; the intervals only apply to numeric fields.

The OUTPUT instruction defines the field that will be updated; there can only be one output field and it is mandatory.

The SKIP instruction can only be used if there is a single input field of BCD_ADDRESS type (like B-Number, A-Number, MSISDN…); its goal is to remove an unwanted known prefix.
Example: if you want to map the end (starting at the fourth digit) of the B-Numbers beginning with ??3, set the B-Number as a single input field, define a SKIP instruction with ??3 as a parameter; the following MAP instructions will describe input prefixes for B-Number truncated (those matching the SKIP) or not (those not matching the SKIP).

The MAP instruction defines an association between a key and a result; each key is separated from the other with a semi-colon; the key of a field expressed as an interval can be given as intervals min_value~max_value or single_value. The keys (single values, as well as min and max of intervals) must be compatible with the matching input fields; the keys (single values) of input fields of BCD_ADDRESS type are implicitly prefixes; the results must be compatible with the output field.

The DEFAULT command instructs the engine to put a default value for the output field of the xDRs not matching any keys in the MAP; if no DEFAULT is defined, the non-matching xDRs will not be modified. The default value must be compatible with the output field.

Enrichment by copy

This way of enriching an xDR is based on the concatenation of parts of values: the given rules define what part of what input field is to be extracted and the order of the definition of the rules defines in what order these parts are to be concatenated into the output field.

The INPUT instruction lists the fields from which parts will be extracted; each input field is separated from the other with a semi-colon; the input fields can also be provided in several INPUT instructions. Input fields can only be of type BCD_ADDRESS, STRING or VARSTRING. At least one input field is needed.

The OUTPUT instruction defines the field that will be updated; there can only be one output field and it is mandatory. The output field can only be of type STRING; if all the input fields are of type BCD_ADDRESS, the output field can also be of type BCD_ADDRESS.

Rules are defined with the LEFT and RIGHT instructions; in case no rule is defined, and only if there is one single input field, the implicit rule LEFT:* is used.
A rule needs, at least, 1 parameter (in addition to the instruction itself): the count of characters/digits to extract. The count is either a strictly positive number or *; when count is a positive number, the exact given number of characters/digits is extracted, or less of the input value is too short; when the count is defined as *, all the characters/digits following (from left to right, whatever the rule) and including the character/digit designated by the possible start parameter, are extracted.
The last parameter of the rule, if given, is the start position of the characters/digits to extract; it is a strictly positive number; depending if the rule is LEFT or RIGHT, 1 is the left most character/digit, resp. the right most one; 2 is the second left most one, resp. the second right most one, aso.
If several input fields are listed, the rule has to define to which input field it applies: the name of the input field has to be provided as the first parameter of the rule (right after the rule instruction); the input field can also be specified if there is one single input field, but it is not mandatory in that case.

Example: To extract the serial number, SNR, out of an IMEISV field, 6 digits starting from 9th position, syntax is:

SECTION:MAIN
DLL:FSEMAP
MODE:BEFORE

SECTION:COPY
INPUT:IMEISV
OUTPUT:SNR
LEFT:6:9

File Format

In the following chapters:

  • [] is an element appearing never or once
  • {}* is an element appearing never, once or more
  • {}+ is an element appearing once or more
  • {|} is a choice of one only element among several elements

MAIN section

SECTION:MAIN
DLL:FSEMAP
MODE:BEFORE

MAPPING section

SECTION:MAPPING [ : <section> ]
INPUT: [ ~ ] <field> { ; [ ~ ] <field> }*
OUTPUT: <field>
{ SKIP: <mask> }*
{ MAP: <value> [ ~ <value> ] { ; <value> [ ~ <value> ] }* : <value> }+
[ DEFAULT: <value> ]

COPY section

SECTION:COPY [ : <section> ]
INPUT: <field> { ; <field> }*
OUTPUT: <field>
{ { LEFT | RIGHT } [ : [ <field> ] ] : { <count> | * } [ : <start> ] }*
FILTER section (optional)
SECTION:FILTER
NAME: <name>
EXPR: <expression>
{ COND: <condition> : <field> : <operator> : <value> { ; <value> }* }+

Definitions

  • <section> ::= section number (starts at 0 and increments for following sections).
  • <field> ::= name of a field (keyword from the dictionary).
  • <mask> ::= <digit> { <digit> }*
  • <digit> ::= { ? | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
  • <value> ::= acceptable value for a given field (input or output field)
  • <count> ::= the number of characters/digits to be extracted
  • <start> ::= the first character/digit to be extracted
  • <name> ::= name of the filter
  • <expression> ::= filtering expression combining <condition> with AND, OR, NOT and ( ) operators
  • <condition> ::= { A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z }
  • <operator> ::= { = | <= | < | <> | > | >= }

Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback