Semantix Roaming Components
HomeProductsServicesDownloadsContact UsFAQs
Semantix Roaming Components
Home arrow Products arrow Roaming Components arrow ASCII2TAP

ASCII2TAP Overview

The ASCII2TAP Roaming component is used to create TAP files from ASCII input files (presumably generated by a pre-existing rating/billing system). It utilizes a module-based architecture with a common backend (a library inside ASCII2TAP) responsible for TAP encoding, and one of a set of modules acting as a frontend. These modules (DLLs under Windows, shared libraries under UNIX OSes) provide the "reading" and "mapping-inside-TAP" logic for a specific ASCII format. For an extended description of ASCII2TAP you can download the whitepaper from here.

Features - Usage

Input files can follow many different formats - fixed width files with one call record per line, delimited files with character or strings as delimiters, etc. Input data might not even come through ASCII data files, but through databases or sockets or whatever other input source. To cope with this diversity a module-based architecture was engineered in ASCII2TAP, which allows any kind of input to be read and mapped inside TAP files. The modules are written in the C language, and can thus use whatever library to read data from a multitude of sources and place them inside TAP trees. This design provides optimality in speed of execution, portability and extensibility.

ASCII2TAP's interface is shown below:

Usage: ASCII2TAP <options>
Where mandatory options are:
        -ims inputMappingSpec.dll
                (the DLL/shared object performing the mapping)
        -i inputASCII_Filename
                (input ASCII filename, passed on to the DLL)
        -o outputBERFilename
                (output BER filename)
and optionally:
        -fixup
                When the DLL finishes update AuditControlInfo and make it consistent
        -V
                output version number
        -v
                increase verbosity (you can use it more than once, e.g. -vv)
        -h
                this help message

Besides the obvious input and output file arguments, the particular input module is also provided through the "-ims" command line argument. It is this DLL/shared library that reads and maps the data read inside the newly created "outputBERFilename". If the optional "-fixup" argument has been passed, the TAP file's AuditControlInfo structure will be updated with all the appropriate information before saving.

The component returns 1 if the exporting process failed for any reason, or 0 otherwise.

The complete source code for a sample input format is provided together with this component (bundled also inside the trial version) together with a Makefile (for UNIX environments) and Visual Studio 8 project files (for Windows). You can thus easily verify that the mapping API provided covers all your needs. Again, read all about the mapping extensions here.

Source code generator

To assist the creation of the input modules, a source code generator is provided. This code generator can create all the "reading" part of the code, based on a simple XML file describing the input data. You can easily review the code generator's functionality, since it is bundled inside the trial version.

To be more precise: In both the trial version and the retail version, a sample project is provided that maps ASCII data to MobileOriginatedCalls. In the provided sample project, the code performing the reading and mapping is stored in two .c files, SimpleMOCinput.c and simpleMOCinput.logic.c. The first one performs the reading, while the latter one stores the data read inside the TAP tree. The first one is also the largest one, and quite error-prone; this is why we created a Python-based code generator to automatically handle the writing of this code. Naturally, you can use the API on your own (see include/AsciiAPI.h) and ignore this code generator if you so wish. You could, however, end up spending time coding and debugging something better written by machines...

To use this code generator, you must specify the input file format in an XML file. Our sample converter was based on codeGen/SimpleMOCinput.xml parts of which you can see below:

<?xml version="1.0" encoding="utf-8" ?>
<FileSpecification Name="SimpleMOC" Description="Simple MOC input specification" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="FileInputSpec.xsd">
 <FixedWidthFile>
  <Record Name="HEADER" Prefix="10">
   <StringField Name="SENDER" Length="5" Mandatory="true" DefaultValue=""/>
   <StringField Name="RECIPIENT" Length="5" Mandatory="true" 
	DefaultValue=""/>
   ...
   <DateField Name="FILE_CREATION_DATE" Length="6" Mandatory="true" 
	DefaultValue="" Format="%y%m%d"/>

This XML file is then processed by our code generator:

bash$ cd codeGen
bash$ parseInputFormatXML SimpleMOCinput.xml

After executing these commands, you will see an "auto-src" directory appear under codeGen, containing three files:

  • SimpleMOCinput.c
    This file contains all the reading logic for files adhering to the format specified in the XML file (SimpleMOCinput.xml).
  • SimpleMOCinput.logic.h
    This file contains the structure declarations for all the different record types specified in the XML file (SimpleMOCinput.xml).
  • SimpleMOCinput.logic.c
    This is the file the developer fills with the mapping logic - the boilerplate has already been written by the code generator. You can see how we enriched this file for the purposes of our sample conversions in source/sampleInput1/simpleMOCinput.logic.c

Once your particular input format mapping module is written, you can "glue" this component with a simple script monitoring a directory (perhaps an output directory from one of your mediation devices), and automatically convert it to TAP3. The simple but complete interface allows chaining this module with existing processes and systems or using it in conjunction with other modules to provide more complex solutions for your installation.

Services

Depending on the complexity of your ASCII format, you might find the provided source code adequate for your needs. For any additional functionality, do not hesitate to contact Semantix for a custom, optimized implementation driven by your input format.
 

    ©2001-2010 Semantix Information Technologies. All rights reserved.
Terms & Conditions        Contact us