RESUMO DE ESPECIFICAÇÃO 1.

Pré-Requisitos
1.1 Serão entregues 2 (dois) programas, descritos a seguir:

# 1

PROGRAMA VALIDAÇÃO

FORMATO SHARED LIBRARY – Padrão Unix Sun Solaris

LOCAL E FORMA DE EXECUÇÃO MEDIADOR DA TELEMAR COM ASSINATURA DE FUNÇÃO PROPRIETÁRIA DA TELEMAR

2

CONVERSÃO

SHARED LIBRARY – Padrão Unix Sun Solaris

MEDIADOR DA TELEMAR COM ASSINATURA DE FUNÇÃO PROPRIETÁRIA DA TELEMAR

OBJETIVOS a- VALIDAR ARQUIVOS NATIVOS DA PLATAFORMA; b- FORMATAR ARQUIVOS COM BLOCAGEM DEFINIDA a- CONVERTER ARQUIVOS NATIVOS DA PLATAFORMA PARA UM OU MAIS FORMATOS PROPRIETÁRIOS

1.2. Pré-requisitos de Implementação Capacidade de processar arquivos concatenados Regras de metodologia de desenvolvimento definidas pelo cliente Construção utilizando linguagem definida pelo cliente Aplicação exige alta performance Entrega do fonte Comentários no código-fonte Idioma Documentação Sim Sim – UML Sim (C ANSI UNIX) Sim Sim Sim Ingles Sim

1.3 Parâmetros de Desempenho Tamanho de arquivo base Quantidade de registros Tamanho médio do registro Tempo de conversão aceitável por arquivo Arquivo de 1 GB 14 milhões 80 bytes 15 minutos

1.4. Entensão da documentação IDIOMA Formato Metodologia Documento de Especificação de Projeto Documento de Requisitos de Implantação Documento de Resultados de Testes Português PDF UML Sim Sim Sim

RESUMO DE ESPECIFICAÇÃO
Documento de Utilização da Aplicação Documento de Descrição das Regras de Validação dos arquivos nativos gerados pela Plataforma Documento de Descrição de Parâmetros, configurações e caracteristicas técnicas da porta Ethernet da Plataforma Documento de descrição das regras de conversão dos arquivos nativos da Plataforma para os formatos proprietários da Telemar Documento de Descrição dos arquivos nativos gerados pela Plataforma Documento de Detalhamento dos comandos de transferência de arquivos dentro da Plataforma Sim Sim Sim

Sim

Sim Sim

2. Sobre a Transferência dos Arquivos.
FORMA DE TRANSFERENCIA RESTRIÇÕES PORTA FTP DIRETA, UTILIZANDO PORTA ETHERNET 10/100/1GB NA PLATAFORMA, UTILIZANDO PROTOCOLO FTP. EXCETO PADRÃO (21) E DEVE SER SUPERIOR A 4000

2.1. Dentro de cada PLATAFORMA deverão ser criados dois diretórios com os seguintes nomes; primary e secondary. No diretório primary deverão estar os arquivos validos a serem coletados pelo mediador. O mediador em intervalos de tempo programados se conectara a PLATAFORMA e iniciara a copia (através de FTP) dos arquivos que estão no diretório primary. Cada arquivo copiado pelo mediador será movido para o diretório secondary existente na PLATAFORMA. Os arquivos deverão permanecer no diretório secondary durante pelo menos 90 dias. Após este período a plataforma automaticamente deverá providenciar a exclusão dos arquivos do diretório. O processo de exclusão do diretório deverá ter como opção a possibilidade dos arquivos serem compactados (RFC 1951, RFC 1952) e gravados em mídia de DVD e/ou Disco Óptico (5,25” de 4.8 Gbytes Norma ISO/IEC 15286) sendo essas formatadas em padrão aberto de leitura/gravação e suportados pelos sistemas operacionais Windows, SUN SOLARIS, LINUX. O processo de compactação e gravação em mídia deverá gerenciar o espaço disponível nas mesmas informando quando da necessidade de sua substituição.

2.2. A periodicidade e o tamanho dos arquivos a serem disponibilizados no diretório primary para coleta deverão ser configuráveis através de IHM de forma independente ou conjuntamente.

2.3. TODA INFRAESTRUTURA de hardware e software necessária ao processo de transferência de arquivos (placas de rede, drive de disco óptico, software de compactação, rotina de backup, etc...) devera estar fisicamente contida no interior da PLATAFORMA. Não será admitida a utilização de equipamentos externos aos ao(s) módulo(s) que compõem o hardware PLATAFORMA (servidores ou microcomputadores, etc...) a menos que os mesmos sejam utilizados para fins de administração e gerencia deste processo.

2.4. A PLATAFORMA deverá prover uma IHM (interface homem maquina) que comporte todos os comandos de administração do processo transferência e backup dos arquivos.

2. Os CDRs AMA111 somente deverão conter chamadas de Rede Inteligente menos os serviços blacklist e whitelist. Dos arquivos a serem transferidos. NOME DO ARQUIVO: ID_DATAINIC_CRC32_SEQUENCIAL EXEMPLO: TLMR_240604123402_AD0A34BB_0000001 DEFINIÇÃO DOS CAMPOS: CAMPO ID DATAINIC CRC32 SEQUENCIAL DESCRIÇÃO Identificação da Central com 4 posições alfanuméricas Data Inicio de Geração do Arquivo [DDMMAAhhmmss] Código CRC (Cyclical Redundancy Check) com 32 Bits do arquivo. 3. 3. inserindo um filler no final do arquivo utilizando a LIB que valida o arquivo (a definição desta blocagem seguira em documento anexo). Numero Seqüencial que e incrementado a cada arquivo a cada novo arquivo gerado na plataforma [7 Digitos]. A plataforma devera disponibilizar um comando para permitir a plataforma à compactação dos arquivos. 3. 4.1.2.RESUMO DE ESPECIFICAÇÃO 3. Os CDRs AMA128 somente deverão conter chamadas internacionais. Caso os arquivos a serem processados pelas LIBs não possuam uma blocagem definida deve-se implementar uma blocagem. 4. serviços e/ou tipos de chamadas deverão constar em cada formato de arquivo a ser produzido pelos conversores. A OI definirá quais os formatos. O nome dos arquivos nativos gerados pela plataforma devera conter as seguintes formatação e informações.1. Os arquivos de bilhetagem e/ou tarifação deverão ser transferidos no formato nativo em que os mesmos são gerados pela PLATAFORMA. .2. 4. O conversor deverá ser capaz de somente converter determinados tipos de chamadas e/ou serviços para cada um dos formatos definidos pela OI. Dos Formatos de CDRs que serão produzidos. Exemplo: 1.3.

Informa o diretório e o nome da cópia criada do arquivo a ser validado na variável outputfile. Programa de conversão A LIB de Conversão deverá avaliar a integridade física do arquivo a ser convertido (informado na variável “inputFile”).Retorna valor 0. Envia uma mensagem padrão (regra I e III) informando o problema encontrado. .1 Se conversão concluída com sucesso: 1. definir uma blocagem caso este não seja “blocado” e criar uma copia do arquivo utilizando os critérios a seguir: Caso o programa de validação não encontre erros no arquivo: 1. converter os CDRs nativos do mesmo para o formato especificado pelo arquivo de configuração e armazenar estes novos CDRs em um arquivo que chamaremos de arquivo resultante da conversão. 3.1.Conversão de registro 1.Filtragem de registros antigos 3.Converter registro 2.Separação de registros antigos 1. Informa o diretório e o nome da cópia criada do arquivo a ser validado na variável outputfile. Ações: 1.1 . Caso o programa de validação encontre um arquivo com problemas: 1234Cria uma cópia desblocada (ver regra V) do arquivo a ser validado e renomeia o arquivo conforme regra VI.Cria copia do arquivo a ser validado. Retorna valor 1.Disponibilizar no diretório temporário informado na variável “tmpDir” o arquivo resultante da conversão. 7. Tabela de Programas x Regras aplicáveis Programa Validação Conversão Regra I Sim Não Regra II Não Sim Regra III Sim Não Regra IV Não Sim Regra V Sim Não Regra VI Sim Sim 6. 2. bloca o arquivo caso este não possua uma blocagem pré-definida (Regra V) e renomeia o arquivo conforme regra VI.Definir blocagem se necessário. Programa de validação Ações: 1.Criar uma cópia do arquivo A LIB de validação deverá avaliar a integridade física do arquivo. 2.RESUMO DE ESPECIFICAÇÃO 5. 3.Avaliar integridade física do arquivo.

4 . Exemplo2.2.1.3. A LIB somente deverá deletar os arquivos que criados por ela.Disponibilizar mensagem (regra II e regra III) na variável “message” informando o motivo da não conversão do arquivo.Informar o PATH e o nome do arquivo resultante da conversão na variável “outputFile” (regra VI) 1. 1.2 .Filtragem e/ou Exclusão dos Registros Antigos 2.3.2.Retornar valor 1 2.Retornar valor -1 1. A regra deverá ser validada pela OI. da plataforma onde a LIB será executada) seja igual ou maior que o valor informado no arquivo de configuração (ver Regra-IV). Caso o registro nativo da plataforma não disponha desta informação a regra poderá ser montada utilizando a tabela de Código Nacional de Localidade Telefônica Oficial.1 . Entenda-se por registro antigo ao registro no qual o numero de dias entre a data no campo data da inicio da chamada de um registro bruto e a data atual do sistema (data informada pelo S.3 . 3.2.Retornar valor 1 1.3 . 1.1 A LIB de CONVERSÃO devera incluir uma regra que identifique um registro antigo. 1. Caso conversão encontre arquivos com problemas: 1.O. 1. A data atual do sistema é 16/10/2005 Exemplo1.2 . a partir da definição descrita no arquivo de configuração da LIB.F.Informar o PATH e o nome do arquivo resultante da conversão na variável “outputFile” (regra VI) 1.2.Disponibilizar no diretório temporário (informado na variável “tmpDir”) o arquivo resultante da conversão com zero bytes (tamanho em bytes igual a zero).Manter variável "outputFile" 1. Exemplos: O arquivo de configuração tem no campo QtdeDias o valor 15.Disponibilizar na variável “message” a mensagem de conversão concluída conforme descrito na especificação (ver Regra I e III).Disponibilizar mensagem (regra II e regra III) na variável “message” informando o motivo da não conversão do arquivo.2 .3 . 1.4 .Excluir arquivos criados no diretório temporário.4 .1 .1.1 A LIB de CONVERSÃO devera incluir uma regra que identifique e filtre os registros por U. Caso o programa de conversão não encontre registros no arquivo a ser convertido que atendam aos critérios de conversão para o formato definido no arquivo de configuração 1.A aplicação encontrou um registro no arquivo que tem a data da chamada igual a 30/01/2005 logo este registro é considerado antigo.Separação de Registros Antigos por UF 3.2.3.A aplicação encontrou um registro no arquivo que tem a data da chamada igual a 01/10/2005 logo este registro é considerado antigo devido à quantidade de dias entre a data atual do sistema e a data da chamada encontrada no registro ser maior que o valor definido no arquivo de configuração.1.3. .RESUMO DE ESPECIFICAÇÃO 1.3.

RESUMO DE ESPECIFICAÇÃO Definições das Regras Regra Regra I Regra II Regra III Regra IV Regra V Regra VI Aplicabilidade Conversão Validação Validação Conversão Validação Validação/Conversão Objetivo FORMATO DAS MENSAGENS A SEREM INCLUIDAS NA LIB DE VALIDAÇÃO FORMATO DAS MENSAGENS A SEREM INCLUIDAS NA LIB DE CONVERSÃO FORMATO DAS MENSAGENS A SEREM INCLUIDAS NAS LIBs POR PROBLEMAS NO AMBIENTE DE PROCESSAMENTO DETALHAMENTO DO ARQUIVO DE CONFIGURAÇÃO BLOCAGEM/DESBLOCAGEM Definição do nome do arquivo resultante da operação de validação ou conversão .

121 Nome do Arquivo de Saida: Nome: /billing40/RJBOTB/teydtmp/RJBOT_90808900_YUI billing40/RJBOTB/teydtmp/RJBOT_90808900_YU/8 098908/JEFERSON.101 Datas e Hora de Referencia Menor: 20/10/2005 12:45:59 Maior: 28/10/2005 01:37:11 {Linha Branco} {Linha Branco} ONDE: {Linha Branco} Inserir linha em branco ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59).RESUMO DE ESPECIFICAÇÃO Regra I Objetivo da regra: FORMATO DAS MENSAGENS A SEREM INCLUIDAS NA LIB DE VALIDAÇÃO Detalhamento do Algoritmo: Exibir a causa do erro ou evento ocorrido de acordo com a implementação.456. {NOME_FORNECEDOR} Espaco para o nome do fornecedor do conversor. .O e problemas de processamento.645. recursos de S.000. Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59.00 Qtde Bytes: 234.txt Qtde Bytes: 876.545.064. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Resultado da Conversao Arquivo de Entrada: Nome: /billing40/RJBOTB/teydtmp/09808/JEFERSON.765 Regs : 233.234.670 Regs : 1.txt. Pode conter palavras acentuadas: NÃO Exemplos: -------------------------------------------DETALHAMENTO DAS MENSAGENS A SEREM COLOCADAS NA VARIAVEL "message" -------------------------------------------Segue a definição das mensagens a serem colocadas na variavel "message".256.456.

Se houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando novamente na coluna 16 ate a 59 e assim sucessivamente.000. Se houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando no- .000} Inicia na coluna 22 Deve conter 12 digitos separados por ". Nome do Arquivo de Saida: Inicia na coluna 08 Nome: {PATH + Nome do arquivo que foi processsado} Inicia na coluna 10 {PATH + Nome do arquivo que foi processsado} Inicia na coluna 16 e escrito ate a coluna 59.RESUMO DE ESPECIFICAÇÃO Resultado da Conversao Inicio na coluna 22. Regs : {000. Qtde Bytes: {Qtde de Bytes} Inicia na coluna 10 {Qtde de Bytes} Inicia na coluna 22 Deve conter ate 12 digitos separados por ". Descrição do campo: Devera conter o PATH mais o nome do arquivo a ser convertido contido na variavel "inputFile".000. Arquivo de Entrada Inicia na coluna 8 Nome: {PATH + Nome do arquivo que foi processsado} Inicia na coluna 10 {PATH + Nome do arquivo que foi processsado} Inicia na coluna 16 e escrito ate a coluna 59.000} Inicia na coluna 15 {000." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda. Descrição do campo: Devera conter a qtde de REGs do arquivo a ser convertido contido na variavel "inputFile".000.000. Descrição do campo: Devera conter a qtde de bytes do arquivo a ser convertido contido na variavel "inputFile"." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda.

000. Qtde Bytes: {000. Descrição do campo: Devera conter a qtde de bytes do arquivo resultante da conversão que foi gravado na variavel "outputFile".RESUMO DE ESPECIFICAÇÃO vamente na coluna 16 ate a 59 e assim sucessivamente.000.000.256.000. Datas e Hora de Referencia Inicia na coluna 10 Menor: {20/10/2005 12:45:59} Inicia na coluna 15 {28/10/2005 01:37:11} Inicia na coluna 22 Descrição do campo: Devera conter a data e hora do REG mais antigo encontrado no arquivo resultante da conversão que foi gravado na variavel "outputFile".000} Inicia na coluna 22 Deve conter 12 digitos separados por ". Menor: {20/10/2005 12:45:59} Inicia na coluna 15 {28/10/2005 01:37:11} Inicia na coluna 22 Descrição do campo: Devera conter a data e hora do REG mais recente encontrado no arquivo resultante da conversão que foi gravado na variavel "outputFile".000. Regs : {233.256.000.121} Inicia na coluna 15 {233." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda. {Linha Branco} ." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda.000} Inicia na coluna 10 {000.121} Inicia na coluna 22 Deve conter 12 digitos separados por ". Descrição do campo: Devera conter o PATH mais o nome do arquivo resultante da conversão que foi gravado na variavel "outputFile". Descrição do campo: Devera conter a qtde de REGs do arquivo resultante da conversão que foi gravado na variavel "outputFile".

765 Regs : 233.545.456.RESUMO DE ESPECIFICAÇÃO {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Resultado da Conversao Arquivo de Entrada: Nome: /billing40/RJBOTB/teydtmp/09808/JEFERSON.545.670 Acoes Exec: Exclusao do arquivo outputFile Armazenamento no diretorio definido. {NOME_FORNECEDOR} Espaco para o nome do fornecedor do conversor.00 Qtde Bytes: 234.64. Acoes Exec: {acoes} Inicia na coluna 8 {acoes} Inicia na coluna 22 Pode conter uma ou duas linhas .000.234.456.txt.txt Qtde Bytes: 876. Descrição do campo: IDEM MENSAGEM ANTERIOR.545. Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59. Resultado da Conversao Inicio na coluna 22.64.121 Nome do Arquivo de Saida: Nome: /billing40/RJBOTB/teydtmp/RJBOT_90808900_YUI billing40/RJBOTB/teydtmp/RJBOT_90808900_YU/8 098908/JEFERSON.670} Inicia na coluna 8 {102.064.64.101 Datas e Hora de Referencia Menor: 20/10/2005 12:45:59 Maior: 28/10/2005 01:37:11 Tratamento de REGs antigos Qtde REGs : 102.670 Regs : 1.545. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59).645.256.670} Inicia na coluna 35 conter ate 12 digitos separados por ponto e ser escrito da esquerda para a direita e suprimir os zeros a esquerda. Tratamento de REGs antigos Inicia na coluna 8 Qtde REGs : {102.

Nome do Arquivo de Entrada: /billing40/RJBOTB/teydtmp/098908/teste/solucao/COL LETA/RJ_ABCD_GJHGJGJ_0980890_RJEFERSON_RJBOT_90800 YU_TELEMAR_RIO_JANEIRO_220820051234_CODIGO_ONLINE_ fatuaramento.txt Qtde Bytes: Qtde de REGs: 100.064. {Descrição do erro} Inicia na coluna 10 e escrito ate a coluna 59.765 Conteudo dos 25 bytes da posic.645. Causa: Inicia na coluna 08. {TIPO_ERRO} Devera conter uma das duas palavras a seguir: VALIDACAO => Quando o erro ocorrer durante a vali dacao.545. CONVERSAO => Quando o erro ocorrer durante a conversao.064. Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59.670 100. Se .670 Posicão no arquivo onde ocorreu o erro: 1. onde ocorreu erro: 0D304021110000000000000000000000000000000000000000 {Linha Branco} {Linha Branco} ONDE: {Linha Branco} Inserir linha em branco ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59). Erro na {TIPO_ERRO} Inicio na coluna 24. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Erro na {TIPO_ERRO} Causa: O arquivo estava com defeito devido ao tamanho do registro estar inCompatível com a quantidade de by tes do arquivo.545.456.RESUMO DE ESPECIFICAÇÃO Descrição do campo: Aqui deverá estar decritas as ações efetuadas no arquivo por regras especificas definidas no arquivo de configuração.

064.Cada campo podera conter ate 12 digitos separados por ponto.O preenchimento e da esquerda para direita. Descrição do campo: Devera conter a qtde bytes ou REGs do arquivo a ser validado ou convertido informado na variavel "inputFile".545.064.645.670} {100. Descrição do campo: Devera conter o texto da mensagem de erro a ser informada na variavel "message".456. . onde ocorreu erro: Inicia na coluna 8 {0D304021110000000000000000000000000000000000000000} Inicia na coluna 10 Descrição do campo: DUMP dos primeiros 25 bytes a partir da posição do arquivo . Qtde Bytes: Qtde de REGs: Inicia na coluna 8 {100.545. Conteudo dos 25 bytes da posic. .RESUMO DE ESPECIFICAÇÃO houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando novamente na coluna 10 ate a 59 e assim sucessivamente. Posicão no arquivo onde ocorreu o erro: Inicia na coluna 8 {1. Descrição do campo: Devera conter o PATH mais o nome do arquivo a ser validado ou convertido contido na variavel "inputFile".Os zeros a esquerda deverao ser suprimidos. Nome do Arquivo de Entrada: Inicia na coluna 8 {PATH + Nome do arquivo que foi processsado} Inicia na coluna 10 e escrito ate a coluna 59.670} Inicia na coluna 22 e na coluna 43 . Se houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando novamente na coluna 10 ate a 59 e assim sucessivamente.765} Inicia na coluna 22 conter ate 12 digitos separados por ponto e ser escrito da esquerda para a direita Os zeros a esquerda deverao ser suprimidos. Descrição do campo: Posição (em bytes) no arquivo a ser validado ou convertido (informado na variavel "inputFile") onde inicia o problema.

{Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Erro na {TIPO_ERRO} Causa: Erro ao tentar ler do arquivo.545.txt Qtde Bytes: Qtde de REGs: 100.RESUMO DE ESPECIFICAÇÃO onde se encontra o erro do arquivo a ser validado ou convertido informado na variavel "inputFile".670 100.670 {Linha Branco} {Linha Branco} A DESCRICAO DOS CAMPOS E POSICÃO É IGUAL A MENSAGEM ACIMA SO QUE ESTA MENSAGEM POSSUI MENOS CAMPOS.064. .064. Nome do Arquivo de Entrada: /billing40/RJBOTB/teydtmp/098908/teste/solucao/COL LETA/RJ_ABCD_GJHGJGJ_0980890_RJEFERSON_RJBOT_90800 YU_TELEMAR_RIO_JANEIRO_220820051234_CODIGO_ONLINE_ fatuaramento.545.

Quando o campo DestREGs do arquivo de configuração igual a 1 (ver Regra IV): 2. Pode conter palavras acentuadas: NÃO A LIB de conversão devera retornar mensagens nos casos abaixo: 1. recursos de S.RESUMO DE ESPECIFICAÇÃO Regra II Objetivo da regra: FORMATO DAS MENSAGENS A SEREM INCLUIDAS NA LIB DE CONVERSÃO Detalhamento do Algoritmo: Exibir a causa do erro ou evento ocorrido de acordo com a implementação. Quando o campo DestREGs do arquivo de configuração igual a 2 (ver Regra IV): 3.O e problemas de processamento. Quando houver problemas no arquivo . Quando o campo DestREGs do arquivo de configuração igual a 3 (ver Regra IV): 4.

545.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar ler ao tentar deslocar ponteiro de leitura do arquivo.545.545. Nome do Arquivo de Entrada: /billing40/RJBOTB/teydtmp/098908/teste/solucao/COL LETA/RJ_ABCD_GJHGJGJ_0980890_RJEFERSON_RJBOT_90800 YU_OI_RIO_JANEIRO_220820051234_CODIGO_ONLINE_ fatuaramento.545.545.64.064.670 100.064.txt Qtde Bytes: Qtde de REGs: 100.672 . Nome do Arquivo de Entrada: /billing40/RJBOTB/teydtmp/098908/teste/solucao/COL LETA/RJ_ABCD_GJHGJGJ_0980890_RJEFERSON_RJBOT_90800 YU_OI_RIO_JANEIRO_220820051234_CODIGO_ONLINE_ fatuaramento.txt Qtde Bytes: Qtde de REGs: 100.64.txt Qtde Bytes: Qtde de REGs: 100. Nome do Arquivo de Entrada: /billing40/RJBOTB/teydtmp/098908/teste/solucao/COL LETA/RJ_ABCD_GJHGJGJ_0980890_RJEFERSON_RJBOT_90800 YU_OI_RIO_JANEIRO_220820051234_CODIGO_ONLINE_ fatuaramento.064.670 100.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar alocar memória.545.RESUMO DE ESPECIFICAÇÃO Regra III Objetivo da regra: FORMATO DAS MENSAGENS A SEREM INCLUIDAS NAS LIBs POR PROBLEMAS NO AMBIENTE DE PROCESSAMENTO Detalhamento do Algoritmo: ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar ler do arquivo.64.671 100.

. /CONFIG_LIBs/fornecedor/CONFIG_LIB_[nome_da_lib]. 1. Exemplo: Sendo “NGNFULANO” o nome do fornecedor e “Conv_NGNFULANO. 2.so].0 NEname O conteúdo deste campo será confrontado com o conteúdo da variável NEname (esta variável é informada pela API do mediador) para identificar qual a linha do arquivo de configuração será utilizada para definir os parâmetros utilizados no processo de conversão. Através da variável “ConfFilePathname”mantida no código fonte com o pathname default do arquivo de configuração conforme descrito a seguir. Os campos deverão ser separados por ponto-e-virgula. Esta somente deverá ser usada quando a variável de ambiente não estiver presente. A LIB de conversão deverá ser capaz de ler arquivos em CSV com a quebra de linha no padrão UNIX (LF 0x0D) ou DOS (CRLF 0x0D 0x0A).0 LayoutSaída Identifica o formato de saída do registro (AMA80. 4. AMA111. Este nome deve ser definido conjuntamente com a equipe da OI. AMA128. nome_da_lib Nome da LIB (shared library).0 BEName O conteúdo deste campo será confrontado com o conteúdo da variável BEName (esta variável é informada pela API do mediador) para identificar qual a linha do arquivo de configuração será utilizada para definir os parâmetros utilizados no processo de conversão.csv Onde: fornecedor: Nome fornecedor ou tecnologia. Este nome deve ser definido conjuntamente com a equipe da OI. No arquivo os caracteres após o “#” deverão ser desprezados (serão considerados comentários) bem como os espaços e linhas em branco. AMA180). O local onde ficara o arquivo de configuração poderá ser informado das duas maneiras descritas a seguir sendo a forma através da variável de ambiente dominante.0 Bilhetador Indica o nome do Bilhetador que pertence os registros que foram selecionados do arquivo nativo da central para serem convertidos. Através de uma variável de ambiente chamada PATH_ARQ_CONFIG_LIB 2. 3.RESUMO DE ESPECIFICAÇÃO Regra IV Objetivo da regra: DETALHAMENTO DO ARQUIVO DE CONFIGURAÇÃO O arquivo de configuração será utilizado pela LIB de CONVERSÃO para definir como deverá ser efetuada a conversão do arquivo informando na variável “inputFile” que deverá informar os parâmetros a serem utilizados na conversão conforme descrito abaixo e devera assim ser formatado: 1. 2.so” o da LIB acordados entre o fornecedor da LIBs e a OI então assim ficará o pathname default da variável que contem o PATH e o nome default do arquivo de configuração: /CONFIG_LIBs/NGNFULANO/CONFIG_LIB_[ Conv_NGNFULANO.csv Parâmetros que deverão constar no arquivo de configuração: 1. Ambas as formas deverão estar disponíveis na LIB e a escolha entre uma e outra devera ser opcional.

(separada por virgulas) dos registros que deverão compor o arquivo.. Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado .F. Lista de regras (separadas por virgula) a serem aplicadas.. Exemplo: Numa linha do arquivo de configuração no campo UFdosREGs contem a seguinte informação:BA. MG.0 UFdosREGs Lista de U. ASCCRLF Arquivo em ASCII com CR e LF no final de cada registro.0 DirRegAnt Diretório (PATH) onde deverão ser colocados os arquivos com registros antigos (Quando o diretório não existir a LIB de Conversão devera criá-lo).0 FmtSaida Formato de Saída do arquivo.) deverá ser considerado que esta verificação de CDRs antigos não será efetuada.RESUMO DE ESPECIFICAÇÃO 5. O nome do arquivo a ser gravado no diretório deverá ter a seguinte formação: {Bilhetador}_{NEname}_{BEname}_{DataAtual[ddmmaaaa]}_{HoraAtual[hhmmss]} 3 = Ao identificar que um registro nativo é antigo. 7.0 RegrasAplic Este campo deverá constar no arquivo de configuração porem não deverá ser efetuado nenhum tratamento no mesmo. não converte o mesmo e segue para o próximo. Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado . 9.. Caso este campo apresente espaço em branco.) deverá ser considerado que não haverá filtragem de CDRs por UF ou seja todos os CDR contidos no arquivo serão convertidos. ASCII EBCDIC ASCLF Arquivo em ASCII com LF no final de cada registro.) deverá ser considerado que esta verificação de CDRs antigos não será efetuada. Esta opção age como um filtro. Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado . 8. Neste campo deverá constar (separado por virgula) todas as U. Armazena os registros antigos convertidos em um arquivo no diretório definido no arquivo de configuração. Isso significa que no arquivo de saída (arquivos resultante da conversão) somente deverá conter os registros que originaram chamadas nestes estados. 10. * (asterisco) ou vazio (quando o campo assim for apresentado . 2 = Converte os registros antigos. 6.0 QdteDias Define quantidade de dias (contados a partir da data atual do sistema operacional) que o registro deverá ser considerado antigo. (siglas dos estados) de origem das chamadas que deverão constar nos registros.. Este campo conterá a regra (ou lista das mesmas) contendo um conjunto de caracteres que identificam que (ou quais) regras deverão ser aplicadas durante o . retirando do arquivo outputFile (arquivo a ser gerado como resultado da conversão) todos os registros que atendam a regra (neste caso a idade do registro).) deverá ser considerado que esta verificação de CDRs antigos não será efetuada. mas não armazena estes registros no arquivo outputFile.F.0 DestREGs Chave que define o que deve ser feito com os registros antigos: 1 = Habilita a conversão de todos os registros do arquivo para o arquivo outputFile.

listadas abaixo. que deverão ser aplicadas de acordo com o tipo de registro a ser processado.RESUMO DE ESPECIFICAÇÃO processamento dos arquivos. Exemplo: A LIB possui regras de exclusão de registros. Logo a seguir esta uma linha informando coma as regras deverão ser colocadas no arquivo de configuração: Nome da Regra: ExclChamLocais ExcluiChamIntern Descrição Exclui chamadas locais Exclui chamadas internacionais .

3 Se a divisão não for exata preencher o final do arquivo com um filler que torne o resultado desta divisão exata. Dividir o tamanho do arquivo em bytes pelo fator de blocagem (que neste caso é 2000 bytes): 12.1 Recupera o tamanho do arquivo.233.000 Resto da Divisão = 1667 B.DESBLOCAGEM DE ARQUIVOS Para gerar um arquivo desblocado ou com a blogagem fora do padrão definido basta incluirmos no final do arquivo o filler de preenchimento que deveria ser inserido para blocar o arquivo acrescido de um byte a mais. 1. Observações: Para linhas com comprimentos distintos utilizar como filler linhas com espaços em branco cuja soma dos comprimentos dos caracteres de todas as linhas torne o resultado da divisão exata Exemplos: O arquivo coletado da Central de MUQUIFO não é blocado e seus registros são de tamanho variável. deverá ser efetuado o seguinte procedimento: A. Exemplos: Usando o EXEMPLO acima para desblocar este arquivo basta que ao invés de inserirmos 333 bytes sejam colocados 334 bytes no final do mesmo.667 Bytes tiver de ser processado. Regra V .1 . Calcular quantos bytes tem que ser inseridos no arquivo para que o resultado da divisão seja exato. Para resolver este problema se usou uma blocagem por tamanho de arquivo com valor de 2000 bytes.232. Logo o programa de validação devera incluir 333 Bytes de filler no final deste arquivo para que este arquivo mantenha um fator de blocagem de 2000 bytes.2 Divide o tamanho do arquivo pelo fator de blocagem (fixo e pré-definido) 1.667 / 2000 => Quociente da Divisão = 12.BLOCAGEM DE ARQUIVOS Objetivo da regra: Acrescentar caracteres de preenchimento (filler) no final do arquivo para que a nova quantidade de bytes seja múltiplo do fator de blocagem.2 . Isto significa que quando um arquivo com tamanho 12. Detalhamento do Algoritmo: 1. Se o valor do resto fosse 2000 a divisão seria exata. . logo o calculo consiste em subtrair o valor do resto da divisão (neste caso 1667) de 2000: 2000 (Valor da Blocagem) .1667 (Resto da divisão) = 333 Bytes C.RESUMO DE ESPECIFICAÇÃO Regra V .233.

PATH = deverá ser copiado da variavel “tmpDir”.00" . Exemplos: inputFile = “/billingTST/BEjefNGNHUW080/aaa28022” tmpDir = “/billingTST/BEjefNGNHUW080/temporário” outputFile deverá ser: “/billingTST/BEjefNGNHUW080/temporário/" + "aaa28022" + ".00” = sufixo (sem aspas) para ser colocado apos o nome do arquivo. nome-de-arquivo em “inputfile” sem o PATH “.RESUMO DE ESPECIFICAÇÃO Regra VI Objetivo da regra: Definição do nome do arquivo resultante da operação de validação ou conversão Detalhamento do Algoritmo: 1.Nome do arquivo de saída: PATH + [nome-de-arquivo de entrada (inputfile) excluindo-se o PATH] + “.00” Onde.