Hunter Parameters (Schema)

segunda-feira, 16 de maio de 2011 18:15:00 Categories: Access Hunter Parameters
Rate this Content 1 Votes

Um dos pontos chaves para o sucesso de todas as atividades da Rede consiste em reunir todas as informações dos parâmetros (GSM, UMTS, LTE...) numa base única e atualizada.

 

 

A partir dessa base (parameters database) podemos realizar uma grande quantidade de ações, com benefícios dos mais diversos tipos: auditoria de parâmetros, geração de relatórios precisos, plotagem no Google Earth e Mapinfo, atualização de outras bases de dados e ferramentas como drive test, etc.

Se você está aqui lendo esse tutorial, provavelmente já deve ter idéia de como esse processo traz resultados. Principalmente por outra vantagem em se ter uma base de dados desse tipo: os dados são confiáveis, pois correspondem ao que temos na rede ativa!

O módulo Hunter Parameters, que começamos a ver hoje, consiste de forma simplificada em procedimentos e macros que buscam os dados brutos de parâmetros das OSS, e armazenam o mesmo em um banco de dados Access.

E se você vem acompanhando os tutoriais Hunter, também já deve estar acostumado com nossa forma simplificada de demonstrar como desenvolver os seus aplicativos específicos que tragam o mesmo resultado para você na sua rede.

 

Objetivo

O objetivo hoje é criarmos um database com todos os dados de parâmetros organizados em tabelas e campos.

No nosso caso, seguindo a modularização Hunter, o nosso banco de dados é o Hunter_Parameters_DB.mdb, do Access.

Os parâmetros da rede são fornecidos em diversos formatos (TXT, XLS, CSV, XML, etc..), e podem ser buscados de diversas formas (FTP, Download, etc..).

Para cada tipo específico, podemos criar um 'parser', ou seja, uma 'macro' que pegue os arquivos em determinado formato e agrupe e organize os mesmos em um database.

Um formato mais comum a grande maioria dos vendors é o formato TXT, até mesmo por ser um formato mais genérico ou comum.

Para importar os dados TXT para um banco de dados do Access, podemos utilizar uma funcionalidade especial: criar um arquivo com as especificações de cada tabela/campo: o arquivo Schema.ini.

E essa será a forma que vamos demonstrar aqui hoje, através de dados simulados (fictícios). Mesmo não sendo dados e formatos específicos de nenhum vendor, os conceitos apresentados aqui podem ser adptados facilmente para a sua rede específica.

 

Cenário

O nosso cenário é o seguinte: temos uma rede GSM/UMTS de um Vendor X, com duas BSC (BSC001 e BSC002) e um RNC (RNC001).

Através de comandos próprios em seu sistema de gerência (todo vendor tem seu formato), agendamos a criação diária da exportação de todas as tabelas de parâmetros em um diretório específico do sistema de gerência. (Quando as tabelas são exportadas, é exportado também um arquivo com as especificações - tabelas, campos, tipos de dados - de cada arquivo exportado).

O próximo passo é buscar esses dados brutos, e copiá-los para um diretório local. (Embora essa ação possa também ser automatizada, por enquanto ainda vamos fazer isso manualmente).

Em seguida, podemos simplesmente rodar uma macro que vai buscar cada um desses arquivos nos diretórios locais, importando cada um deles fazendo alguns tratamentos* e disponibilizando tudo em um banco de dados único!

* O tratamento de dados é um passo essencial, principalmente a inclusão de novos campos em cada tabela. Isso porque se simplesmente juntássemos todos os arquivos comuns de todas as BSC's, como saberíamos a qual BSC um determinado setor pertence (por exemplo).

 

Estrutura de Arquivos

Como já dissemos, você já deve estar familiarizado com a modularição do Hunter. Assim, hoje vamos criar mais alguns diretórios, para suportar os arquivos e macros desse módulo Parameters (1). Os novos diretórios são mostrados abaixo.

Como estamos acostumados, o diretório 'Script' contém os scripts relativos a esse módulo. O diretório 'Data' é o diretório de onde esse módulo busca os dados. E o diretório 'Database' é o diretório onde ficará o database final: Hunter_Parameter_DB.mdb com os nossos dados.

Nota: é muito importante manter uma padronização da nomenclatura utilizada, principalmente, e pelo menos, dos databases chave. O Database de parâmetros é um desses, e como vimos, será usado futuramente como base (fonte de dados) para diversos outros módulos. Se ele não tiver um nome padrão – ou seja, mudar o nome para um outro qualquer – teremos problemas para vincularmos os demais módulos. Você pode entender mais ou menos fazendo uma analogia com o Excel. Se você utilizar uma planilha externa em uma fórmula, e apagar ou renomear essa planilha, terá que informar ao Excel de onde os novos dados virão!

Você deve ter percebido o sinal de '+' no diretório Data. Isso porque, para esse exemplo específico, temos os dados de nosso Vendor X dispostos conforme mostrado abaixo (praticamente um espelho dos dados brutos gerados nos diretórios das OSS do mesmo, e baixados via ftp).

 

Temos:

  • BSC001 com 3 BTS: GAAA1, GBBB1 e GCCC1 (todas com 3 setores).
  • BSC002 com 3 BTS: GDDD1, GEEE1 e GFFF1 (todas com 3 setores).
  • RNC001 com 2 NODEB: UAAA1 e UEEE1 (todas com 3 setores).

 

Por exemplo, os arquivos brutos da BSC001 são:

E em todos os diretórios, existe um arquivo com a definição dos tipos de dados de cada campo de cada tabela:

Observação 1: note que o arquivo 'gsm_par_1.txt' da BSC001 será armazenado em uma tabela 'gsm_par_1'. O arquivo 'gsm_par_1.txt' da BSC002, será armazenado nessa mesma tabela. Já dá para entender porque precisamos inserir alguns campos no tratamento, não? (Nesse caso, um campo para informar qual a BSC/RNC).

Observação 2: seguindo o mesmo raciocínio, e pela estrutura apresentada, os arquivos 'gsmumts_par_1.txt' da BSC001, 'gsmumts_par_1.txt' da BSC001 e 'gsmumts_par_1.txt' do RNC001 serão armazenados em uma mesma tabela. Também vale a pena inserir um campo adicional informando se o nosso parâmetro é GSM (BSC) ou UMTS (RNC) não?

De qualquer forma, logo mais ficará mais fácil perceber a importância e os benefícios desses campos.

Vamos continuar. E chega de falar sobre os dados fictícios da nossa rede. Somente lembre-se que formatos bem parecidos são fornecidos por todos os vendors, e você pode adpatar os procedimentos aprendidos aqui sem problemas.

 

Introdução ao Código Utilizado

Vamos então, apresentar uma sugestão de código VBA que você poderá usar para criar a sua própria macro que faça todas essas tarefas.

Estamos falando de criação de macros no Access (um arquivo mdb auxiliar, localizado na pasta Scripts), por isso precisamos adicionar um módulo.

Nota: até hoje, em todos os tutoriais, mostramos passo a passo inserir cada objeto no banco de dados. Por exemplo, qual menu acessar, qual item clicar, etc. Essa metodologia é boa para aprender, mas repetir todo esse procedimento que já deve estar assimilado torna-se desnecessário, e pode até acabar atrapalhando. Assim, sempre que indicarmos uma ação como inserir um módulo para escrever uma macro, se você tiver alguma dúvida, por favor, recorra aos tutoriais Hunter anteriores.

A macro que vamos mostrar utiliza algumas tabelas e consultas como apoio, por isso vamos falar primeiro sobre elas.

 

Tabelas Auxiliares

Todas as tabelas que criamos são do tipo 'tbl_*' .

No nosso exemplo de hoje, utilizamos 3 tabelas auxiliares, conforme mostrado abaixo, com sua respectiva explicação.

  • tbl_Config_Schema: como todas as tabelas de configuração que utilizamos, essa tabela contém os campos que vão definir o que a nossa macro vai fazer.

    • ExportFilePath: diretório local onde encontram-se os dados. Geralmente os dados são baixados via ftp em um único arquivo do tipo ZIP.
    • ExportFileName: sub-diretório local onde encontram-se todos os arquivos. Nesse exemplo, extraimos todos eles para o sub-diretório com o nome desse arquivo.
    • NEType: campo para indicar se o elemento é BSC ou RNC. Esse campo/valor será apendado em cada tabela desse elemento.
    • NEName: campo para informar o nome do Elemento. Também será apendado em cada tabela desse elemento.
    • Regional: um campo livre, que será também apendado, e pode conter informações adicionais, como por exemplo o vendor ou a sua rede.
    • Import: campo auxiliar, informando se esse elemento deve ser processado (importado).

 

  • tbl_Aux_FieldType: utilizamos os dados dessa tabela para escrever o arquivo Schema.ini corretamente. Isso porque o Schema.ini deve conter os tipos de dados exatamente como o Access espera. E os dados em nosso arquivos podem estar diferentes. Por exemplo, o nosso arquivo informa que o campo é do tipo inteiro utilizando a palavra 'int'. No Access, a definiçao do tipo inteiro é através de 'Short'.

 

  • tbl_Config_Schema: tabela com as informações das tabelas e tipos de dados. Usamos essas informações para escrever o arquivo Schema.ini, que como falamos é um arquivo auxiliar, que permite a importação automática dos dados. No nosso caso, essa especificação é fornecida junto com o dump, e para cada elemento, carregamos via código essa tabela de definição correspondente.

Consultas Auxiliares

Todas as consultas que criamos são do tipo 'qry_*' .

No nosso exemplo de hoje, utilizamos 2 consultas auxiliares, conforme mostrado abaixo, com sua respectiva explicação.

  • qry_Config_Schema: praticamente os dados da tabela tbl_Config_Schema, apenas filtrando – mostrando – apenas os elementos que configuramos para processar.

 

  • qry_ViewDefinition: também uma consulta bem simples, com basicamente os dados da tabela tbl_ViewDefinition, incluindo um novo campo FieldTypeAccess, que como falamos, informa o formato do tipo de dados para o arquivo Schema.ini no formato que o Access espera.

 

 

Código VBA

Agora que já conhecemos os nossos dados, e as tabelas e consultas auxiliares, podemos montar um rascunho do que o código VBA deve fazer.

Lembrando sempre que essa é apenas uma forma de fazer – certamente você poderá fazer de outra forma. Essa é a nossa sugestão, então vamos 'ler' as etapas principais do nosso código, apresentando sugestões e idéias para que você possa criar o seu próprio. Para maiores referências e possibilidades em cada comando apresentado, por favor, leia a Ajuda do VBA ou faça uma pesquisa no Google. De qualquer forma, o apresentado aqui serve como idéia ou guia para você criar as suas próprias soluções/códigos.

Enumerando as principais ações sequencialmente, temos o resumo do código:

Para cada linha da consulta de configuração (que já exclui possíveis elementos que não desejamos processar):

[utilizamos o comando db.OpenRecordset para manipularmos essa consulta via código]

Ler as informações, por exemplo do diretório onde encontram-se os arquivos a serem buscados;

[atribuimos os valores de cada campo desse recordset a variáveis auxiliares; por exemplo a variável 'strExportFilePath' contém o valor do campo 'ExportFilePath' do recordset ativo]

Importar, antes de tudo, o arquivo com as definições das tabelas/campos;

[utilizamos o comando DoCmd.TransferText, pois sabemos qual o nome do arquivo, e temos uma Especificação de Importação de Texto salva previamente para essa ação específica. Para acessar essas definiçoes salvas, você pode importar qualquer arquivo Texto pela interface do Access, e quando o Wizard aparecer, clique em Avançado – Especificações. De qualquer forma, essa é um especificação simples]

Com essas definições carregadas, escrever o arquivo 'Schema.ini' nesse diretório onde encontram-se os arquivos;

[utilizamos o comando Open For Output – inserindo o cabeçalho do Schema.ini e Open For Append, para escrever as informações de cada campo]

Importar cada arquivo (exemplo NOME1.txt) nesse diretório, já baseado nas informações do arquivo 'Schema.ini' que criamos na raiz desse diretório, para uma tabela temporária 'temp_NOME1';

[utilizamos os comandos CreateObject("Scripting.FileSystemObject"), para varrer as informações no diretório, e o comando db.Execute SELECT * INTO, para inserir os dados utilizando o Schema.ini]

Incluir os campos adicionais, com os valores que lemos na linha da consulta de configuração, e também com outros valores desejados, por exemplo um campo com informação de Data;

[utilizamos o comando .CreateField e .Append para inserir os campos adicionais customizados]

Inserir os dados dessa tabela temporária, agora com os nossos campos de apoio, em uma tabela definitiva NOME1;

[utilizamos o comando db.Execute SELECT * INTO]

Deletar a tabela temporária 'temp_NOME1';

[utilizamos o comando db.TableDefs.Delete]

Finalmente, copiamos todas as tabelas do arquivo atual (lembre-se que ele é nosso 'Script') para o banco de dados definitivo 'Hunter_Parameters_DB.mdb'.

[utilizamos DoCmd.CopyObject, com as informações do arquivo atual e de destino]

 

Resultado

Como resultado (rodando a macro que chama esse código), temos o nosso banco de dados com todas as tabelas e campos com informações dos parâmetros da nossa rede.

Abrindo o banco de dados, temos acesso a todos os dados em um único local!

 

Voltando ao nosso exemplo, temos 2 BSC, com uma tabela 'gsm_table_1' exportada para seus sub-diretórios específicos. Após o processamento, temos os dados dessas tabelas armazenados numa só tabela, junto de campo adicionais! (Por exemplo o campo NENAME – com o nome de cada BSC).

 

No nosso exemplo, veja que também incluímos uma RNC UMTS, com uma tabela de parâmetros comum a rede GSM e UMTS: 'gsmumts_table_1'. Quando todos os 3 arquivos (2 das BSC's e 1 da RNC) são importados para uma única tabela, vemos a utilizadade de um campo como o NETYPE – que nos permite filtar por parâmetros de BSC e/ou RNC.

 

IMPORTANTE: Observe que utilizamos aqui dados fictícios, e poucos arquivos/tabelas de parâmetros de configuração da rede. Na prática, o número de arquivos/tabelas chega a centenas, tornando a utilização de artifícios como essa macro uma ação praticamente imprescindível.

 

Conclusão

Iniciamos uma nova etapa nos desenvolvimentos da ferramenta Hunter. Como informamos, estamos focando mais em aplicações. Os tutoriais publicados até recentemente voltavam-se mais a uma familiarização com a metodologia, e também na utilização dos programas, principalmente do Access e VBA.

Hoje vimos como criar um banco de dados com todas as informações dos parâmetros GSM e UMTS da nossa rede. Outras tecnologias como LTE podem ser inseridas da mesma forma apresentada.

A concentração dessas informações em um arquivo único traz muitos benefícios, como permitir uma rápida criação de relatórios, vizualização dos parâmetros no Google Earth, auditorias de parâmetros, verificação de alterações na rede, atualização de outras bases de dados e ferramentas, como arquivos auxiliares na execução de drive tests. E o mais importante – os dados confiáveis, pois correspondem ao que temos na rede ativa!

Agradecemos a sua visita, e esperamos que as informações apresentadas possam servir de ponto de partida para suas soluções e macros.

Em especial, agradecemos aos colaboradores do telecomHall. Os arquivos desse tutorial já foram enviados, por favor verifiquem. Caso tenham tido algum problema no recebimento, por favor informem.