Sabrix

Execução

O Sistemas de Vendas tem que se comunicar com o MTS via on-line e por processos de lote. Eu era responsável por desenvolver a comunicação on-line e prover manutenções ao processo de lote. Para a parte on-line eu projetei um componente a ser implementado em C++ na plataforma Mainframe. Este componente seria acoplado a um código PL/1 que acessa os Sistemas de Vendas. Eu implementei o método para receber os dados de fatura e transformar isto em um formato XML. O código abria uma conexão sockets de baixo nível com uma Servlet do MTS que estava em um Linux em plataforma System z, comprimia o conteúdo usando uma biblioteca de gzip, e enviava o pedido de HTTP. Eu criei o código para analisar gramaticalmente o HTML de resposta, unia os múltiplos pacotes e usava a biblioteca de gzip para expandir o conteúdo. O conteúdo final era analisado gramaticalmente por uma biblioteca XML e o conteúdo era disponibilizado para o código PL/1 recuperar os impostos. Para desenvolver este componente eu tive que estudar as APIs C++ disponíveis na plataforma Mainframe e pesquisar como eu poderia reproduzir este ambiente em uma plataforma Windows para melhorar a produtividade. Eu vi que eu pudia usar o compilador gcc disponível no ambiente cygwin. Eu também tive que pesquisar bibliotecas gzip e de XML em C++. A comunicação de lota já havia sido implementada em componente Java multi-thread usando filas MQ Series. O componente recebe faturas dos Sistemas de Vendas, aplica regras de transformação, e então os remete ao MTS. Eu tive que aplicar mudanças às regras de transformação deste componente.

O MTS é instalado em dois países: Dinamarca e nos E.U.A.. A instalação de MTS na Dinamarca recebe imposto automaticamente da companhia Thomson Reuters. Depois que o banco de dados é atualizado com os novos impostos, um operador acessa o console MTS e despacha uma requisição de refresh de memória que atualiza os caches dos servidores. Este processo é chamado sincronização de cache. Embora o MTS seja uma aplicação J2EE que pode ser executada num cluster, o sistema de cache interno só pode ser atualizado entre os servidores de uma mesma sub-net. Então, não pôde ser propagado do ambiente de Dinamarca para o ambiente dos E.U.A.. As instâncias de DB2 foram configurados para propagar qualquer mudança do banco de dados da Dinamarca para o banco de dados dos E.U.A.. Mas a necessidade de um operador local ter que despachar uma sincronização de cache nos E.U.A. tinha que ser eliminada. Para resolver este problema, eu tive que implementar uma aplicação nova chamada de Cache Synchronization (CS). A aplicação identifica a atualização dos imposto na instalação mestre do MTS na Dinamarca despacha um comando de sincronização de cache na instalação escravo MTS nos E.U.A. somente depois que o banco de dados for sincronizado. A execução do comando de sincronização teve que ser feita simulando um usuário que tem acesso ao console MTS. Assim, o componente tem que navegar automaticamente pelos menus e emitir um comando de sincronização de cache. Eu provei que a solução proposta pelos arquitetos não funcionaria. O produto especificado Rational Funcional Tester (RFT) não podia simular um usuário que navega no consolo de MTS. A razão principal é que uma interface gráfica como KDE ou GNOMO tinha que estar disponível em Linux em ambiente de Sistema z. Além disto a sessão tido que estar destravada durante todo o processo, caso contrário o RFT não poderia navegar no console do MTS. Eu negociei uma extensão de tempo para analisar outras possíveis alternativas para o RFT. Eu comecei uma investigação de como substituir a solução de RFT. Eu analisei muitos produtos e bibliotecas. Eu implementei uma prova de conceito usando a biblioteca HTTPUnit. Eu utilizei a metodologia de companhia e gerei uma sequência de produtos que seriam entregues. Eu criei o:

Cronograma de implementação,
Catálogo de regras empresarial,
Macro Design,
Regras empresariais para Micro Design,
Modelo de componente,
Diagramas de componentes físicos,
Diagrama de classe,
Diagrama de estados para o CS mestre,
Diagrama de estados para o CS escravo,
Modelo de dados lógico,
Design físico de banco de dados,
Materiais de apoio ao usuário, e
Resultados de teste de sistemas.

Eu projetei e implementei quatro componentes com interfaces mínimas para reduzir as dependências. Eu os nomeei Máquina de Evento, Controle de Persistência, Gerente de Comunicação, e Componente de Notificação. A Máquina de Evento implementa uma máquina de estados para controlar o ciclo de vida dos eventos. Os eventos controlados por este componente têm uma sucessão bem definida de possível estado que depende do tipo da instalação. Uma instalação é selecionada para ser o Mestre e pode haver muitas instalações de Escravo, embora somente uma instalação Escravo era necessária no momento. Isto permite que a solução seja facilmente escalável. O Controle de Persistência tem o objetivo de esconder como os estados da Máquina de Eventos era persistido. As mídia utilizadas para armazenar as informações podem ser mudadas de banco de dados para arquivos simples, arquivo de XML ou qualquer outro formato sem ter que mudar a Máquina de Evento. O Gerente de Comunicação é projetado para controlar todas as comunicações entre o Mestre CS e os Escravos CS. A Máquina de Eventos desconhece como as mensagens são transmitidas entre o Mestre CS aos Escravos CS e vice-versa. Isto é porque a tecnologia ou produto utilizado na transmissão de mensagem é escondida dentro do Gerente de Comunicação. Esta tecnologia ou produto pode ser mudada sem afetar os outros componentes do CS. Eu implementei isto com o produto MQ Series. O Componente de Notificação controla como o time de apoio é notificado quando um evento de exceção é gerado pelo CS. Atualmente a implementa notifica através de e-mail. Mas esta tecnologia pode ser mudada para pager, mensagens móveis ou qualquer outra tecnologia. Quaisquer mudanças somente afetaria o Componente de Notificação. O arquivo de configuração para CS tinha que ser um único arquivo de XML. Eu criei uma aplicação Swing para controlar este arquivo de configurações. Isto por causa de seu tamanho e complexidade. Este arquivo de configuração teve que armazenar muita informação diferente como:

Informações de Contato para o time de apoio incluindo um teste para validar a configuração,
Configuração geral como a frequência do evento de pooling e o numero de dias antes de limpar os arquivos de log,
A configuração para a instalação de instância Mestre como informação de acesso ao DB2 o do banco de dados da instalação MTS ser monitorada,
Uma configuração para a instância Mestre que declara o nome dos estados, o intervalo de timeout, o próximo estado se sucesso, o próximo estado se houver problemas, e a classe que implementa cada estado com um botão para testar a sua inicialização,
Uma configuração para a instância Escrava com declarações do mesmo modo da instância Mestre,
A adição de instâncias escravas com o banco de dados usado pelo componente de CS, o banco de dados de MTS que é monitorado, e o usuário e senha para o console do MTS (as senhas são codificadas no arquivo XML usando AES 128),
A lista das tabelas monitoradas no MTS e o nome da coluna que que possui o timestamp da última atualização, e finalmente
Uma funcionalidade para ler os últimos eventos do arquivo de log direto da ferramenta.

O acesso para o console de MTS só é concedido se o usuário é catalogado no banco de dados interno do MTS. Assim um código customizado foi desenvolvido para autenticar o usuário com a contra no sistema de autenticação de companhia. Eu era responsável por manter este componente. A aplicando estava tendo dificuldades com códigos de identificações de usuário que estavam sendo rejeitadas porque não estava de acordo com a expressão regular interna para Id válidos. Eu arrumei as expressões regulares.

Uma aplicação inicial chamada Tax Inquire foi criada para fazer o MTS acessível pela Intranet. A aplicação Tax Inquire consiste em dois componentes. O primeira parte é para receber as informação da cota dos usuários pela Intranet. Esta parte tem que obedecer aos padrões de companhia e gerar um pedido de WebService. O segundo componente é um Web Service que recebe pedidos de cotas e transforma isto em um pedido de HTTP para uma servlet do MTS que calcula os impostos. Eu era responsável por manter as duas partes e forncer encarecimentos de ambos os componentes. Eu tive que fazer o código obedecer aos padrões da Intranet e de Acessibilidade. Eu usei a ferramenta WebKing para validar o HTML gerado pelo Tax Inquire e arrumei muitos códigos que estavam de acordo com os padrões. Eu usei a ferramenta Jaws para simular as pessoas com inaptidões. Eu tive que garantir acessibilidade por pessoas cegas. Eu arrumei muitos erros que impediram a ferramenta JAWs de ler as páginas corretamente. Eu tive que acrescentar lógica empresarial nova ao código e melhorar o qualidade do código removendo muitos arquivos de propriedades desnecessários. Para o componente de WebService eu tive que executar muitos testes para validar as respostas de WebServices. Eu instalei o Rational Performance Test (RPT) e instalei o WebServices Feature Pack. Eu configurei o RPT para usar a comunicação segura através de SSL e Certificado Digital. Eu transformei uma planilha eletrônica com muitos dados de teste em um datapool. Eu criei o mapeamento entre o datapool e os campos especificados no arquivo de WSDL. Eu executei os testes que capturam as requisições SOAP para gerar relatórios. Eu enviei os relatórios a um contato de finanças que analisaria a validaria os dados.

Para garantir o desempenho da plataforma Sabrix um grupo foi contratado para executar testes de performance. Este grupo é chamado de HIPODS. Eles reproduziriam o ambiente de MTS na plataforma AIX e executariam testes e afinaria os parâmetros do WebSphere Application Server. Eu ajudei o HIPODS a montar o ambiente inteiro com todos os componentes da solução. Eu implementei alguns feeds para suprir dados para a plataforma. Estes feeds simulam os períodos do dia quando há carga de trabalho principalmente on-line, como se usuários estivessem acessando o Tax Inquire. Os feeds funcionaram bem. Nós revisamos as recomendações de de configuração de produtos fornecidas pelo HIPODS e aceitamos o relatório final.

Eu tive que interagir com a Dinamarca que fazia o hosting dos servidores. Eles eram responsáveis por manter o ambiente de desenvolvimento com só um servidor, o ambiente de teste com oito servidores e também o ambiente de produção também com oito servidores. Eu tive que abrir tickets para mover código de desenvolvimento para o ambiente de teste.

Eu tive que diagnosticar um problema ao aplicar o WebSphere Application Server Fixpack 6.1.0.25. O Sabrix interface de cálculo de taxas deixou de funcionar. Eu contatei o grupo de suporte ao WebSphere. Com a ajuda deles eu pude isolar procura para o problema nos fluxos de compressão gzip. Depois de alguns testes com ferramentas sniffer de HTTP eu descobri que a requisição estava comprimida mas a resposta não. Eu vi que o WebSphere estava descomprimindo o pedido automaticamente e Sabrix estava recebendo um pedido descomprimido e também enviando uma resposta descomprimida. O problema foi resolvido colocando o parâmetro AutoDecompressed para falso no canal HTTP.

Os códigos para todos os componentes foram armazenados no repositório de código CVS. Eu tive que manter o código atualizado no CVS e criar as releases para serem promovidas ao ambiente de teste.

Eu tive acesso completo ao console WebSphere Application Server do ambiente de desenvolvimento e acesso de leitura para o console do ambiente de teste. Eu era responsável por manter as configurações das aplicações no ambiente de desenvolvimento. Eu tive que diagnosticar problemas durante promoções para o ambiente de teste como reproduzir as configurações para acessar o ambiente de autenticação de usuários..

Eu mantive o gerente de projeto atualizado comparecendo a reuniões semanais para informar o estado, responder a perguntas e prover atualizações do cronograma, para isto tive que usar uma comunicação verbal concisa e efetiva. Eu também enviei relatórios semanais através de notas e mantive a ferramenta de controle de defeito atualizada com a mais recente informação.