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.

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

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

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

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 .

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

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

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

545.00 Qtde Bytes: 234. {Linha Branco} {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Inicio variavel (entre 8 e 59).256.txt Qtde Bytes: 876.64.670 Regs : 1.545.RESUMO DE ESPECIFICAÇÃO {Linha Branco} ** Conversor {NOME_FORNECEDOR} ** Resultado da Conversao Arquivo de Entrada: Nome: /billing40/RJBOTB/teydtmp/09808/JEFERSON.64.670} Inicia na coluna 8 {102.645.765 Regs : 233.456.000.670 Acoes Exec: Exclusao do arquivo outputFile Armazenamento no diretorio definido.234.064. Acoes Exec: {acoes} Inicia na coluna 8 {acoes} Inicia na coluna 22 Pode conter uma ou duas linhas .456.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. Esta linha deve ser centralizada no espaco entre as colunas 08 ate a coluna 59. Resultado da Conversao Inicio na coluna 22.121 Nome do Arquivo de Saida: Nome: /billing40/RJBOTB/teydtmp/RJBOT_90808900_YUI billing40/RJBOTB/teydtmp/RJBOT_90808900_YU/8 098908/JEFERSON. Descrição do campo: IDEM MENSAGEM ANTERIOR.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.545.64. Tratamento de REGs antigos Inicia na coluna 8 Qtde REGs : {102.545. {NOME_FORNECEDOR} Espaco para o nome do fornecedor do conversor.

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

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

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

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

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.672 .txt Qtde Bytes: Qtde de REGs: 100.64.670 100.txt Qtde Bytes: Qtde de REGs: 100.545.64.545.545.64.671 100.txt Qtde Bytes: Qtde de REGs: 100.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.064.545.670 100.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar ler ao tentar deslocar ponteiro de leitura do arquivo.064.670 ** Conversor SIEMENS ** Erro na Conversao Causa: Erro ao tentar alocar memória.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.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.064.

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

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

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

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

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. PATH = deverá ser copiado da variavel “tmpDir”.Nome do arquivo de saída: PATH + [nome-de-arquivo de entrada (inputfile) excluindo-se o PATH] + “.00” = sufixo (sem aspas) para ser colocado apos o nome do arquivo.00” Onde. Exemplos: inputFile = “/billingTST/BEjefNGNHUW080/aaa28022” tmpDir = “/billingTST/BEjefNGNHUW080/temporário” outputFile deverá ser: “/billingTST/BEjefNGNHUW080/temporário/" + "aaa28022" + ".00" . nome-de-arquivo em “inputfile” sem o PATH “.

Sign up to vote on this title
UsefulNot useful