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.

3.RESUMO DE ESPECIFICAÇÃO 3.3. Numero Seqüencial que e incrementado a cada arquivo a cada novo arquivo gerado na plataforma [7 Digitos]. 2. A plataforma devera disponibilizar um comando para permitir a plataforma à compactação dos arquivos. 4. Caso os arquivos a serem processados pelas LIBs não possuam uma blocagem definida deve-se implementar uma blocagem. inserindo um filler no final do arquivo utilizando a LIB que valida o arquivo (a definição desta blocagem seguira em documento anexo).1. . 3. O nome dos arquivos nativos gerados pela plataforma devera conter as seguintes formatação e informações. 4. Os arquivos de bilhetagem e/ou tarifação deverão ser transferidos no formato nativo em que os mesmos são gerados pela PLATAFORMA. 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 arquivos a serem transferidos. Exemplo: 1. 3. A OI definirá quais os formatos.1. serviços e/ou tipos de chamadas deverão constar em cada formato de arquivo a ser produzido pelos conversores. Os CDRs AMA128 somente deverão conter chamadas internacionais. Os CDRs AMA111 somente deverão conter chamadas de Rede Inteligente menos os serviços blacklist e whitelist.2. 4. Dos Formatos de CDRs que serão produzidos. 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.2.

bloca o arquivo caso este não possua uma blocagem pré-definida (Regra V) e renomeia o arquivo conforme regra VI. Envia uma mensagem padrão (regra I e III) informando o problema encontrado.Filtragem de registros antigos 3.RESUMO DE ESPECIFICAÇÃO 5.1 Se conversão concluída com sucesso: 1. Ações: 1.Criar uma cópia do arquivo A LIB de validação deverá avaliar a integridade física do arquivo.Cria copia do arquivo a ser validado.Converter registro 2.Definir blocagem se necessário.Avaliar integridade física do arquivo.Separação de registros antigos 1. Programa de validação Ações: 1. 3. Retorna valor 1.1. 2. . Informa o diretório e o nome da cópia criada do arquivo a ser validado na variável outputfile. 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.Retorna valor 0.Disponibilizar no diretório temporário informado na variável “tmpDir” o arquivo resultante da conversão.Informa o diretório e o nome da cópia criada do arquivo a ser validado na variável outputfile.Conversão de registro 1. 3. 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. 7. 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. 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”).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.

Disponibilizar na variável “message” a mensagem de conversão concluída conforme descrito na especificação (ver Regra I e III). .1 A LIB de CONVERSÃO devera incluir uma regra que identifique um registro antigo. 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.1.Retornar valor 1 1.3 . a partir da definição descrita no arquivo de configuração da LIB. A regra deverá ser validada pela OI.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.4 . 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.2 .Filtragem e/ou Exclusão dos Registros Antigos 2. Exemplos: O arquivo de configuração tem no campo QtdeDias o valor 15.3.2.1 .4 .Excluir arquivos criados no diretório temporário.Retornar valor -1 1.F.2. 1.2 . 1. A LIB somente deverá deletar os arquivos que criados por ela. 3.3. A data atual do sistema é 16/10/2005 Exemplo1.1 .Retornar valor 1 2.Informar o PATH e o nome do arquivo resultante da conversão na variável “outputFile” (regra VI) 1.1. 1.Manter variável "outputFile" 1.1 A LIB de CONVERSÃO devera incluir uma regra que identifique e filtre os registros por U. 1.2.3.3 .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). 1.4 .Disponibilizar mensagem (regra II e regra III) na variável “message” informando o motivo da não conversão do arquivo.A aplicação encontrou um registro no arquivo que tem a data da chamada igual a 30/01/2005 logo este registro é considerado antigo.3 .1. 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.Separação de Registros Antigos por UF 3.Informar o PATH e o nome do arquivo resultante da conversão na variável “outputFile” (regra VI) 1.2. Exemplo2.Disponibilizar mensagem (regra II e regra III) na variável “message” informando o motivo da não conversão do arquivo. da plataforma onde a LIB será executada) seja igual ou maior que o valor informado no arquivo de configuração (ver Regra-IV).3.O.2. Caso conversão encontre arquivos com problemas: 1.3.RESUMO DE ESPECIFICAÇÃO 1.

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 .

Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59.000.545.00 Qtde Bytes: 234.456.O e problemas de processamento. {NOME_FORNECEDOR} Espaco para o nome do fornecedor do conversor.txt Qtde Bytes: 876.064.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.234.456.765 Regs : 233.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).670 Regs : 1. .256. 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".645.121 Nome do Arquivo de Saida: Nome: /billing40/RJBOTB/teydtmp/RJBOT_90808900_YUI billing40/RJBOTB/teydtmp/RJBOT_90808900_YU/8 098908/JEFERSON.txt. recursos de S. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Resultado da Conversao Arquivo de Entrada: Nome: /billing40/RJBOTB/teydtmp/09808/JEFERSON.

000} Inicia na coluna 22 Deve conter 12 digitos separados por ". 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. 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. 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. Qtde Bytes: {Qtde de Bytes} Inicia na coluna 10 {Qtde de Bytes} Inicia na coluna 22 Deve conter ate 12 digitos separados por ".000. Regs : {000.000.000} Inicia na coluna 15 {000. Descrição do campo: Devera conter o PATH mais o nome 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. Descrição do campo: Devera conter a qtde de REGs do arquivo a ser convertido contido na variavel "inputFile". Se houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando no- .000.RESUMO DE ESPECIFICAÇÃO Resultado da Conversao Inicio na coluna 22. 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.

Regs : {233.000.000." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda. 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"." 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 resultante da conversão que foi gravado na variavel "outputFile".RESUMO DE ESPECIFICAÇÃO vamente na coluna 16 ate a 59 e assim sucessivamente.121} Inicia na coluna 15 {233. Qtde Bytes: {000. {Linha Branco} .256.000} Inicia na coluna 10 {000.256.000} Inicia na coluna 22 Deve conter 12 digitos separados por ". Descrição do campo: Devera conter a qtde de bytes do arquivo resultante da conversão que foi gravado na variavel "outputFile".000.121} 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. Descrição do campo: Devera conter o PATH mais o nome do arquivo resultante da conversão que foi gravado na variavel "outputFile".000.000.

Tratamento de REGs antigos Inicia na coluna 8 Qtde REGs : {102.RESUMO DE ESPECIFICAÇÃO {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Resultado da Conversao Arquivo de Entrada: Nome: /billing40/RJBOTB/teydtmp/09808/JEFERSON.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.txt.64.545. Acoes Exec: {acoes} Inicia na coluna 8 {acoes} Inicia na coluna 22 Pode conter uma ou duas linhas .000.670 Acoes Exec: Exclusao do arquivo outputFile Armazenamento no diretorio definido. {NOME_FORNECEDOR} Espaco para o nome do fornecedor do conversor. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59).121 Nome do Arquivo de Saida: Nome: /billing40/RJBOTB/teydtmp/RJBOT_90808900_YUI billing40/RJBOTB/teydtmp/RJBOT_90808900_YU/8 098908/JEFERSON.456.545. Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59.234. Resultado da Conversao Inicio na coluna 22.545.64.670 Regs : 1.765 Regs : 233.txt Qtde Bytes: 876. Descrição do campo: IDEM MENSAGEM ANTERIOR.064.645.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.545.670} Inicia na coluna 8 {102.00 Qtde Bytes: 234.456.256.

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.765 Conteudo dos 25 bytes da posic.670 Posicão no arquivo onde ocorreu o erro: 1.545. {Descrição do erro} Inicia na coluna 10 e escrito ate a coluna 59. CONVERSAO => Quando o erro ocorrer durante a conversao. Causa: Inicia na coluna 08.645. {TIPO_ERRO} Devera conter uma das duas palavras a seguir: VALIDACAO => Quando o erro ocorrer durante a vali dacao.064. Se . Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59. onde ocorreu erro: 0D304021110000000000000000000000000000000000000000 {Linha Branco} {Linha Branco} ONDE: {Linha Branco} Inserir linha em branco ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59).txt Qtde Bytes: Qtde de REGs: 100. {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. Erro na {TIPO_ERRO} Inicio na coluna 24.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.456.670 100.

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.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. .545. 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. Descrição do campo: Devera conter o texto da mensagem de erro a ser informada na variavel "message". Posicão no arquivo onde ocorreu o erro: Inicia na coluna 8 {1.456.Cada campo podera conter ate 12 digitos separados por ponto. 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 .O preenchimento e da esquerda para direita.545.Os zeros a esquerda deverao ser suprimidos.645.064.670} Inicia na coluna 22 e na coluna 43 . Descrição do campo: Posição (em bytes) no arquivo a ser validado ou convertido (informado na variavel "inputFile") onde inicia o problema.064.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.670} {100. Descrição do campo: Devera conter o PATH mais o nome do arquivo a ser validado ou convertido contido na variavel "inputFile". Descrição do campo: Devera conter a qtde bytes ou REGs do arquivo a ser validado ou convertido informado na variavel "inputFile". Conteudo dos 25 bytes da posic. . Qtde Bytes: Qtde de REGs: Inicia na coluna 8 {100.

RESUMO DE ESPECIFICAÇÃO onde se encontra o erro do arquivo a ser validado ou convertido informado na variavel "inputFile".545.670 {Linha Branco} {Linha Branco} A DESCRICAO DOS CAMPOS E POSICÃO É IGUAL A MENSAGEM ACIMA SO QUE ESTA MENSAGEM POSSUI MENOS CAMPOS.txt Qtde Bytes: Qtde de REGs: 100. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Erro na {TIPO_ERRO} Causa: Erro ao tentar ler do arquivo. .545.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.064.670 100.

O e problemas de processamento. Pode conter palavras acentuadas: NÃO A LIB de conversão devera retornar mensagens nos casos abaixo: 1. recursos de S. Quando o campo DestREGs do arquivo de configuração igual a 3 (ver Regra IV): 4. Quando o campo DestREGs do arquivo de configuração igual a 2 (ver Regra IV): 3.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 1 (ver Regra IV): 2. Quando houver problemas no arquivo .

672 .545.64. 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.064.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar ler ao tentar deslocar ponteiro de leitura do arquivo.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.64.txt Qtde Bytes: Qtde de REGs: 100.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.545.545.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.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar alocar memória.671 100.064.670 100.64.545.txt Qtde Bytes: Qtde de REGs: 100.

AMA180).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. AMA128. Este nome deve ser definido conjuntamente com a equipe da OI.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. /CONFIG_LIBs/fornecedor/CONFIG_LIB_[nome_da_lib].so]. . AMA111. 4.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. 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 Bilhetador Indica o nome do Bilhetador que pertence os registros que foram selecionados do arquivo nativo da central para serem convertidos. Ambas as formas deverão estar disponíveis na LIB e a escolha entre uma e outra devera ser opcional. nome_da_lib Nome da LIB (shared library). 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.0 LayoutSaída Identifica o formato de saída do registro (AMA80.csv Onde: fornecedor: Nome fornecedor ou tecnologia.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 de uma variável de ambiente chamada PATH_ARQ_CONFIG_LIB 2. 2. Esta somente deverá ser usada quando a variável de ambiente não estiver presente. 1. Os campos deverão ser separados por ponto-e-virgula. Através da variável “ConfFilePathname”mantida no código fonte com o pathname default do arquivo de configuração conforme descrito a seguir. 2. Exemplo: Sendo “NGNFULANO” o nome do fornecedor e “Conv_NGNFULANO. 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. 3.csv Parâmetros que deverão constar no arquivo de configuração: 1.

6.) deverá ser considerado que esta verificação de CDRs antigos não será efetuada.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). Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado . Lista de regras (separadas por virgula) a serem aplicadas. Esta opção age como um filtro. 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 .. 8. Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado . ASCII EBCDIC ASCLF Arquivo em ASCII com LF no final de cada registro. não converte o mesmo e segue para o próximo. 2 = Converte os registros antigos.0 RegrasAplic Este campo deverá constar no arquivo de configuração porem não deverá ser efetuado nenhum tratamento no mesmo.RESUMO DE ESPECIFICAÇÃO 5.. (separada por virgulas) dos registros que deverão compor o arquivo. 7. 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.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.0 FmtSaida Formato de Saída do arquivo.0 QdteDias Define quantidade de dias (contados a partir da data atual do sistema operacional) que o registro deverá ser considerado antigo. Armazena os registros antigos convertidos em um arquivo no diretório definido no arquivo de configuração. * (asterisco) ou vazio (quando o campo assim for apresentado . (siglas dos estados) de origem das chamadas que deverão constar nos registros. Exemplo: Numa linha do arquivo de configuração no campo UFdosREGs contem a seguinte informação:BA.) deverá ser considerado que esta verificação de CDRs antigos não será efetuada.F..0 UFdosREGs Lista de U. ASCCRLF Arquivo em ASCII com CR e LF no final de cada registro. 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). Caso este campo apresente espaço em branco ou vazio (quando o campo assim for apresentado .) deverá ser considerado que esta verificação de CDRs antigos não será efetuada.) deverá ser considerado que não haverá filtragem de CDRs por UF ou seja todos os CDR contidos no arquivo serão convertidos. Isso significa que no arquivo de saída (arquivos resultante da conversão) somente deverá conter os registros que originaram chamadas nestes estados. mas não armazena estes registros no arquivo outputFile. 10.. Neste campo deverá constar (separado por virgula) todas as U. MG. Caso este campo apresente espaço em branco.F. 9.

listadas abaixo.RESUMO DE ESPECIFICAÇÃO processamento dos arquivos. 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 . Exemplo: A LIB possui regras de exclusão de registros. que deverão ser aplicadas de acordo com o tipo de registro a ser processado.

Para resolver este problema se usou uma blocagem por tamanho de arquivo com valor de 2000 bytes. Detalhamento do Algoritmo: 1.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.1667 (Resto da divisão) = 333 Bytes C.1 . 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.1 Recupera o tamanho do arquivo. Calcular quantos bytes tem que ser inseridos no arquivo para que o resultado da divisão seja exato. 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. logo o calculo consiste em subtrair o valor do resto da divisão (neste caso 1667) de 2000: 2000 (Valor da Blocagem) . Se o valor do resto fosse 2000 a divisão seria exata.RESUMO DE ESPECIFICAÇÃO Regra V . Dividir o tamanho do arquivo em bytes pelo fator de blocagem (que neste caso é 2000 bytes): 12.233. .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.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.667 Bytes tiver de ser processado.667 / 2000 => Quociente da Divisão = 12.000 Resto da Divisão = 1667 B. 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.2 Divide o tamanho do arquivo pelo fator de blocagem (fixo e pré-definido) 1.233. Regra V .232.

Nome do arquivo de saída: PATH + [nome-de-arquivo de entrada (inputfile) excluindo-se o PATH] + “. 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.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.00" . nome-de-arquivo em “inputfile” sem o PATH “. PATH = deverá ser copiado da variavel “tmpDir”.00” Onde.

Sign up to vote on this title
UsefulNot useful