Accueil > Réalisations > Logiciels > Outils pour autocommutateurs Alcatel 4400 > Alca-Line, analyse du trafic téléphonique sur un Alcatel 4400 > Principe de décodage des fichiers de taxation
Principe de décodage des fichiers de taxation
jeudi 4 janvier 2007, par
Les fichiers que nous vennons de récupérer sont stockés sous un format binaire. Vous trouverez ci-dessous la procédure à suivre pour les transformer en une version lisible et explotable...
Les fichiers de taxation sont en effet des fichiers compressés (avec le compress unix calssique) contenant des enregistrements de type texte dont la décomposition est donnée dans leur première ligne . Par exemple :
#TicketVersion,1,5,L,CalledNumber,6,31,L,ChargedNumber,32,51,L,....
Ce qui signifie :
- ’#’ commence une ligne de description de format
- le premier champ s’appelle « Ticket version »
- il commence en colonne 1 et se termine en colonne 5
- son type est L (les types possibles sont ’L’, champ texte, ’N’, champ texte, et ’R’, nombre entier)
- le deuxième champ est « CalledNumber »
- etc...
Cette définition peut changer d’une version de logiciel à l’autre, version qui est d’ailleurs systématiquement rappelée dans le champ « TicketVersion ». Dans les versions que j’ai utilisé pour mes tests (4.8, 4.9 et 5.1), les champs sont les suivants :
| Champ | 4.8 | 4.9 | 5.1 | Contenu |
| TicketVersion |  | | | Version du ticket de facturation |
| CalledNumber | | | | Numéro appelé ou appelant (selon le sens) |
| ChargedNumber | | | | Poste facturé |
| ChargedUserName | | | | Nom du titulaire du poste |
| ChargedCostCenter | | | | Centre de coût |
| ChargedCompany | | | | - |
| ChargedPartyNode | | | | - |
| Subaddress | | | | - |
| CallingNumber | | | | - |
| CallType | | | | PublicNetworkOutgoingCall (0), PublicNetworkOutgoingCallThroughPrivateNetwork (1), PrivateNetworkCall (2), LocalCall (3), PublicNetworkIncomingCall (4), PublicNetworkIncomingCallThroughPrivateNetwork (5), Unspecified (6), PrivateNetworkOutgoingCallToPublicNetwork (7), PrivateNetworkOutgoingCallToPrivateNetwork (8), PublicNetworkIncomingCallToPrivateNetwork (9), PrivateNetworkIncomingCallToPrivateNetwork (10), PublicOrPrivateNetworkOutgoingCallThroughPrivateNetwor (11), PublicOrPrivateNetworkIncomingCallThroughPrivateNetwork (12), PrivateNetworkIncomingCall (13), LocalLocalNode (14) |
| CostType | | | | - |
| EndDateTime | | | | Date/heure de fin de l’appel |
| ChargeUnits | | | | Unités téléphoniques facturées |
| CostInfo | | | | - |
| Duration | | | | Durée de l’appel |
| TrunkIdentity | | | | - |
| TrunkGroupIdentity | | | | - |
| TrunkNode | | | | - |
| PersonalOrBusiness | | | | - |
| AccessCode | | | | - |
| SpecificChargeInfo | | | | - |
| BearerCapability | | | | - |
| HighLevelComp | | | | - |
| DataVolume | | | | - |
| UserToUserVolume | | | | - |
| ExternFacilities | | | | - |
| InternFacilities | | | | - |
| CallReference | | | | - |
| SegmentsRate1 | | | | - |
| SegmentsRate2 | | | | - |
| SegmentsRate3 | | | | - |
| ComType | | | | - |
| X25IncomingFlowRate | | | | - |
| X25OutgoingFlowRate | | | | - |
| Carrier | | | | - |
| InitialDialledNumber | | | | - |
| WaitingDuration | | | | - |
| EffectiveCallDuration | | | | - |
| RedirectedCallIndicator | | | | - |
| StartDateTime |  | | | Date/heure de début de l’appel |
| ActingExtensionNumber | | | | - |
| CalledNumberNode | | | | - |
| CallingNumberNode | | | | - |
| InitialDialledNumberNode | | | | - |
| ActingExtensionNumberNode | | | | - |
| TransitTrunkGroupIdentity | | | | - |
| NodeTimeOffset | | | | - |
A noter que d’une version à l’autre le type et la taille des champs peuvents changer !
Notre procédure d’import va fonctionner comme suit :
1/ Nous allons creer une base de données vide qui servira de container aux données
2/ Nous allons ensuite creer dans cette base les tables nécessaires au bon fonctionnement de l’application :
- une table temporaire « spooledfiles » qui contiendra la liste des fichiers disponibles (ce qui permettra de charger uniquement les nouveaux fichiers à partir du répertoire spool) ;
- une meta table (meta_columndesc décrivant la table de données (d’une version à l’autre le format est succeptible de changer, nous garderons donc la liste des descriptifs pour savoir si le format existe déjà et, si tel n’est pas le cas nous ajusteront dynamiquement une nouvelle table) ;
- un début de table taxdata contenant le minimum d’informations nécessaires au fonctionnement du système : un identifiant unique de ticket et l’identifiant du fichier qui le contenait.
Nb : dans les évolutions possibles du système, il conviendra de gérer des notions de profil (qui peut faire quoi), de type d’analyses prédéfinies avec une exécution paramétrable, etc... Pour le moment notre objectif est simplement de charger ces fichiers de taxation dans un SGBDR, puis de fournir quelques exemples de traitements en SQL pur. L’interface clickodromesque viendra plus tard ;-). De ce fait seront crées :
- des tables décrivant des traitements et leur évènements déclencheurs ;
- des tables associées stockant les résultats des dits traitements.
3/ La procédure d’import va calculer la liste des fichiers à importer puis les chargera en adaptant si nécessaire la table de stockage (ajout/conversion de colonnes).
Remarque : de manière à permettre un travail plus efficace les données seront retravaillées comme suit :
- les « leading spaces » et « trailing spaces » seront supprimés ;
- les dates (StartDateTime et EndDateTime) seront converties en « timestamp ».
