Projetos

MailManager

Descrição

    O MailManager é um sistema de controle de mensagens que substitui, com vantagens, os leitores de email comuns, porque faz estatísticas das mensagens recebidas, respondidas, possui regras que disparam ações automáticas para diminuir o número de mensagens a serem lidas, histórico de mensagens por email.

Cronograma

    A primeira versão do produto estava programada para durar 4 meses, com lançamento previsto para Janeiro de 2001.


 Minha participação

    Fiquei encarregado por dois subprojetos: O Middleware e um Serviço para baixar mensagens.

    Middleware
 
    O middleware foi desenvolvido como uma DLL/ISAPI, que é uma aplicação que aguarda requisições feitas via http, escrita em Delphi, disponível no ambiente operacional  IIS do Windows 2000. Ele fazia a comunicação entre o programa para responder os emails e o banco de dados utilizado para armazenar as mensagens. Como utilizamos o Delphi (Object Pascal) que é uma linguagem pseudo orientada a objetos, foi possível fazer uma boa estrutura de classes para facilitar o entendimento de seu funcionamento, assim como o desenvolvimento de novas funcionalidades.

    Serviço de Baixar Mensagens

     Neste estágio, foi desenvolvido um programa disponibilizado como um serviço do Windows que era responsável por ler mensagens de uma caixa postal POP3. Para evitar que houvesse concorrência entre os serviços, construímos o sistema com diversas threads, ou seja, um fio de execução para cada conta POP3. Foi necessário um estudo de algumas RFCs, pois na época tínhamos um componente pouco flexível e que não conseguia fazer o decodificação correta de algumas mensagens (dependendo da codificação do email, o sistema travava). 

RFC: Request for comment. Documento numerado onde ficam documentados os padrões da Internet. Nem toda RFC é padrão, porém todos os padrões estão em alguma RFC.  

Refactoring do Interactive

Descrição

    O Interactive foi o primeiro produto da Direct Talk e como fora desenvolvido sem muitos critérios técnicos e de forma inexperiente, ele apresentava diversos problemas estruturais, o que acarretava em perda de performance. Com o aumento no número de clientes, a performance do nosso banco de dados foi degradando-se e foi necessário fazer um refactoring da principal stored procedure do sistema.

Refactoring: Processo de reescrever algum código para aumentar a compreensão, entendimento e melhorar sua performance, sem alterar seu funcionamento.
Stored Procedure:  Conjunto de comandos do banco de dados que ficam armazenados e são utilizados com freqüência.

Cronograma

    Apesar de não haver um cronograma definido, a situação era crítica, pois a instabilidade do nosso serviço claramente comprometia a imagem de nossos serviços, portanto o prazo era curto.

Minha participação

    Fiquei responsável pela definição técnica, implementação e também testes das mudanças. A stored procedure era responsável por pegar as novas informações que o operador deveria receber (novos usuários, novas mensagens, etc). Ela fazia consultas em diversas tabelas, o que no princípio não era muito custoso, mas com o aumento do tamanho das tabelas, assim como do número de operadores, a performance ficou crítica.
    Para evitar isso, imaginei um esquema baseado em eventos. Ou seja, criamos um nova tabela, que armazena os eventos não lidos de um operador. Nas tabelas pertinentes, criei triggers que faziam inserção na tabela de eventos. Assim, a stored procedure fazia apenas um select na tabela de eventos e, se necessário, fazia as consultas nas outras tabelas.

Trigger: Gatilho. Seqüência de comandos que são executados quando um determinado evento (inserção, alteração ou remoção) ocorre em uma tabela.

Info Network

Descrição

    Depois de desenvolvidos o Interactive e o MailManager, surgiu a necessidade de integrar as duas ferramentas e disponibilizar para o operador um histórico unificado de atendimentos de chat e de emails recebidos de um cliente. Para isso e a fim de integrar outras ferramentas e sistemas externos, criamos o Info Network, que é um banco de dados que centraliza as informações de todos os canais de comunicação e também de sistemas externos (CRM do cliente, por exemplo).

Cronograma

    A princípio estava definido um período de dois meses, porém houve atrasos e utilizou-se três meses para finalizar o projeto.

Minha participação

    Como conhecia bem as duas ferramentas, fiquei responsável pela definição técnica, implementação e também dos testes. Criei algumas triggers nas tabelas do Interactive e do MailManager que alimentavam o Info Network, criando as ocorrências. Além das ocorrências, tínhamos também uma estrutura na qual era possível associar um cliente com informações vindas de fora do nosso sistema através de troca de informações via XML.Fiquei encarregado de fazer as estruturas no banco de dados assim como as stored procedures que fariam as inserções de dados externos.

Workflow Services

Descrição

    Havia a demanda por parte de um cliente de um sistema que controlasse os fluxos de troca de produtos, de estorno de valores, etc. Daí, iniciou-se o projeto de um sistema de workflow, que iniciaria processos a partir de uma ocorrência em nosso sistema de atendimento ao cliente, atribuindo tarefas a grupos ou pessoas dentro da organização e controlando todas as etapas fosses cumpridas e respeitando o tempo máximo estipulado.

Cronograma

    A primeira versão teve três meses para ficar pronta e sua nova versão está em fase de testes.

Minha participação

    Após fazer o estudo de outras ferramentas de workflow, fiquei responsável pela preparação de uma especificação de requisitos, mostrando como seria o funcionamento do sistema, quais seriam as funcionalidades. Após discutirmos essa especificação, desenvolvi a especificação técnica, detalhando como seria o banco de dados e como seriam algumas interações com o próprio banco. Após o desenvolvimento da primeira versão, surgiu a necessidade de novas funcionalidades não previstas. Então foi feito um refactoring do banco de dados e utilizou-se da técnica de especialização, que deixa uma estrutura no banco semelhante a algo orientado a objeto, tornando-o bastante flexível. Tínhamos a seguinte estrutura de classes:





Que acabou se tornando a seguinte estrutura no banco de dados:




Dessa forma, para consultarmos todas as atividades que iniciam um subprocesso, assim como seu nome e qual processo ele inicia temos o seguinte comando SQL:

SELECT
    A.id_atividade,
    A.nome AS nome_atividade,
    P.nome AS nome_processo
FROM
    atividades A
    INNER JOIN atividades_subprocesso AS ON
        A.id_atividade = AS.id_atividade
    INNER JOIN processos P ON
        AS.id_processo = P.id_processo

Para consultarmos todas as atividades que acessam a URL 'www.americanas.com.br/webservice' utilizamos o seguinte comando SQL:

SELECT
    A.id_atividade
FROM
    atividades A
    INNER JOIN atividades_url AU ON
        A.id_atividade = AU.id_atividade
        AND
        AU.endereco    = 'www.americanas.com.br/webservice'