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.

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

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

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

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 .

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

Descrição do campo: Devera conter a qtde de bytes 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 novamente na coluna 16 ate a 59 e assim sucessivamente.RESUMO DE ESPECIFICAÇÃO Resultado da Conversao Inicio na coluna 22.000} Inicia na coluna 15 {000.000} Inicia na coluna 22 Deve conter 12 digitos separados por ".000. Se houver mais caracteres a serem escritos estes deverão ser escritos na linha abaixo iniciando no- ." 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 o PATH mais o nome do arquivo a ser convertido contido na variavel "inputFile". Regs : {000. Descrição do campo: Devera conter a qtde de REGs do arquivo a ser convertido contido na variavel "inputFile". 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. 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. Qtde Bytes: {Qtde de Bytes} Inicia na coluna 10 {Qtde de Bytes} Inicia na coluna 22 Deve conter ate 12 digitos separados por ".000." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda.000.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".256. 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".121} Inicia na coluna 15 {233.000. Regs : {233. {Linha Branco} .000} Inicia na coluna 10 {000. Descrição do campo: Devera conter a qtde de REGs do arquivo resultante da conversão que foi gravado na variavel "outputFile".000." Deve ser escrito da esquerda para a direita a partir da coluna 36 e suprimir os zeros a esquerda.RESUMO DE ESPECIFICAÇÃO vamente na coluna 16 ate a 59 e assim sucessivamente.000.000} 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 bytes do 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.256.000. Qtde Bytes: {000.000.000.

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

txt Qtde Bytes: Qtde de REGs: 100.456. {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.064. 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). {TIPO_ERRO} Devera conter uma das duas palavras a seguir: VALIDACAO => Quando o erro ocorrer durante a vali dacao. CONVERSAO => Quando o erro ocorrer durante a conversao.670 100.064. Causa: Inicia na coluna 08. Se .670 Posicão no arquivo onde ocorreu o erro: 1.545.765 Conteudo dos 25 bytes da posic.645.545.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. 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. Erro na {TIPO_ERRO} Inicio na coluna 24. {Descrição do erro} Inicia na coluna 10 e escrito ate a coluna 59.

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

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

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. recursos de S.O e problemas de processamento. Quando o campo DestREGs do arquivo de configuração igual a 3 (ver Regra IV): 4. Quando houver problemas no arquivo . 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.

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

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

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

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

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

00" .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" + ". PATH = deverá ser copiado da variavel “tmpDir”. nome-de-arquivo em “inputfile” sem o PATH “.00” = sufixo (sem aspas) para ser colocado apos o nome do arquivo.00” Onde.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.

Sign up to vote on this title
UsefulNot useful