Semantix Roaming Components
HomeProductsServicesDownloadsContact UsFAQs
Semantix Roaming Components
Home arrow Features arrow TAP to ASCII

TAP2ASCII Overview

The TAP2ASCII Roaming component is used to create ASCII files from TAP3 input files (presumably received by another PMN or generated by some other system). It utilizes a module/plugin-based architecture with a common frontend (the TAP2ASCII binary), which is responsible for TAP reading, and an output module/plugin that acts as a backend. This plugin (DLLs under Windows, shared objects under UNIX OSes) provides the logic for "mapping-from-TAP" and "writing to output".

Variery of output formats

TAP2ASCII can generate ANY desired output format. It accomplishes this through a plugin-based system, that allows it to dynamically load (at runtime) a specific output plugin. Each plugin creates files adhering to a unique output ASCII format.

Moreover, you can use multiple output plugins to generate different ASCII outputs. For example, your Revenue assurance department may require a simple format, containing only charge-related information, whereas the billing department or your data warehouse may require all TAP3 information to be present in the ASCII file.

When you purchase TAP2ASCII, you get complete source code and binaries of ready-made plugins that transform ALL the TAP3 content into an ASCII format. You can also create your own plugins through the development API. Altermatively, Semantix can develop a customized plugin to cover your needs.

The trial package includes (a) a plugin (binary only) that dumps ALL information of TAP3.10 and (b) complete source code for a simple plugin that generates simple output out of TAP3.10 files.

Here's an example of the output of the plugin that dumps ALL information:

003,"Test case generated with Semantix Toolkit"

Features - Usage

For most of our clients, the output of the "full dump" plugins (which come with complete source code when you purchase TAP2ASCII) cover all their requirements. Some clients, however, have other, more specific needs. Output ASCII files can follow many different formats - fixed width files with one call record per line, delimited files with character or strings as delimiters, etc. Output data may in fact not even be going to ASCII data files, but to databases or sockets or whatever other output. To cope with this diversity, a plugin-based architecture was engineered in TAP2ASCII, which allows TAP data to be read and subsequently processed through any kind of APIs. The plugins are written in the C language, and can thus use whatever library they want, in order to work on the data they read from the TAP3.x tree, and subsequently write them off to the desired targets (output files, databases, sockets, etc). This design provides optimality in speed of execution, portability and extensibility.

TAP2ASCII's interface is shown below:

Usage: TAP2ASCII <options>
Where mandatory options are:
        -ims inputMappingSpec.dll
                DLL (shared object) containing mapping logic
        -i inputTapFilename.ber
                Input TAP file
                Output ASCII file
        -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 processing plugin is also provided through the "-ims" command line argument. It is this DLL/shared library that maps and writes the TAP3 data inside the newly created "" file. Naturally, the "inputMappingSpec" module might choose to ignore this argument and write the TAP data inside a database, send them over a socket to another process, etc.

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

The trial version of TAP2ASCII includes (a) a plugin that dumps the FULL content of TAP3.10 files and (b) the complete source code for a simple output plugin. Also bundled is 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 (if you do indeed, want to create a plugin on your own). All the necessary information about writing your own mapping extensions is here.

Source code generator

To assist in the creation of custom plugins, you may choose to use a source code generator which we provide. This code generator can create all the "writing" part of your plugin's code, based on a simple XML file that describes the output data format. You can easily review the code generator's functionality, since it is bundled inside the trial version.

In both the trial version and the retail version, a sample project is provided that maps MobileOriginatedCalls (and only them, i.e. only MOCs) to an ASCII data format. In the provided sample project, the code performing the mapping and writing is stored in two .c files, sampleOutput.c and sampleOutput.logic.c. The first one performs the writing, while the latter one maps the data read from the TAP tree into C structs. The first one is also the largest one, and quite error-prone; this is why we created a code generator that automatically handles 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 that is easier to write by a machine...

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

<?xml version="1.0" encoding="utf-8" ?>
<FileSpecification Name="TAP2" Description="TAP2 input specification" 
		<Record Name="MOC" Prefix="20">
			<StringField Name="IMSI" Length="15" Mandatory="true" 
				DefaultValue="" />
			<DateField Name="CHARGING_DATE_TIME" Length="14" 
				Mandatory="true" DefaultValue="" Format="%Y%m%d%H%M%S" />
			<NumberField Name="CHARGE" Length="9" DecimalPlaces="3" 
				Mandatory="true" DefaultValue="" />
		<Record Name="MTC" Prefix="30">
			<StringField Name="IMSI" Length="15" 
				Mandatory="true" DefaultValue="" />

This XML file is then processed by our code generator:

bash$ cd codeGen
bash$ parseOutputFormatXML sampleOutput.xml

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

  • sampleOutput.c
    This file contains all the writing logic for files adhering to the format specified in the XML file (sampleOutput.xml).
  • sampleOutput.logic.h
    This file contains the structure declarations for all the different record types specified in the XML file (sampleOutput.xml).
  • sampleOutput.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 this output in source/sampleOutput1/sampleOutput.logic.c

Once your particular output format mapping module is written, you can "glue" this component with a simple script monitoring a directory (perhaps an output directory from your billing system), and automatically convert it to TAP3 (TAP-out, maybe). 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.

Semantix Services

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

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