Automação de Processos de Negócio em Dispositivos Móveis

Automação de Processos de Negócio em Dispositivos Móveis Gonçalo Filipe da Silva Batista Dissertação para obtenção de Grau Mestre em Engenharia Informática e de Computadores Júri Presidente: Professor Doutor António Manuel Ferreira Rito da Silva Orientador: Professor Doutor Pedro Manuel Moreira Vaz Antunes de Sousa Vogais: Professor Doutor Artur Miguel Pereira Alves Caetano Outubro 2010

I. Agradecimentos Ao apresentar esta dissertação quero agradecer a todos aqueles que de alguma forma contribuíram para a sua concretização, em particular: Ao meu orientador Professor Pedro Sousa pelo acompanhamento, encorajamento e crítica constantes que me permitiram levar a cabo esta dissertação. Ao Eng. Manuel Fonseca pela orientação e ajuda. A Eng. Alexandra Marques e ao Prof. José Borges pela participação no Paper e ajuda em alguns temas da sua área nomeadamente a floresta. Aos meus pais pelo apoio incondicional durante todo o processo de realização desta dissertação. 2

II. Resumo Devido ao forte crescimento das tecnologias de informação e dos dispositivos móveis, é de extrema importância desenvolver mecanismos de automação de trabalho com vista a maximizar a eficácia dos processos de uma empresa. Os sistemas de gestão de workflows foram criados nesse sentido, no entanto, nenhum suporta a realização de tarefas com utilização recursos que estejam em ambientes desconectados, sendo o caso da exploração florestal um exemplo forte. O Objectivo desta dissertação era encontrar uma solução para contornar o problema da falta de conexão, utilizando o armazenamento persistente e ferramentas de sincronização. A solução consiste em disponibilizar uma worklist aos clientes num PDA com armazenamento persistente e, realizar a sincronização posteriormente. Esta solução foi implementada num projecto em curso na empresa Link Consulting designado CAMTec, que define a visão tecnológica para a gestão de toda a cadeia de abastecimento de produtos florestais, onde vão ser realizados os testes e a respectiva validação através de utilizadores do sector. Palavras-chave Workflow Base Dados Sincronização Floresta Dispositivos Móveis 3

III. Abstract Due to the strong growth of information technologies and mobile devices, it is extremely important to develop mechanisms for automation of work to maximize the effectiveness and efficiency from processes of a company. The workflow management systems was something created in this sense, the problem is that doesnt supports the accomplishment of tasks to resources that are in disconnected environments, and the case of logging is a strong example. The objective of this dissertation was to find a solution to overcome the lack of connection, using persistent storage and synchronization tools. The solution is to provide a worklist to customers on a PDA with persistent storage, and then perform the synchronization. This solution was implemented in an ongoing project at Link Consulting company named CAMTec that sets the technology vision for managing the entire supply chain of forest products, where will be performed testing and validation by users in the sector. Keywords Workflow Data Base Sync Forest Mobiles 4

Índice I. Agradecimentos... 2 II. Resumo... 3 III. Abstract... 4 Índice... 5 IV. Lista de Figuras... 8 Introdução... 10 1.1 Estrutura do relatório... 10 1.2 Enquadramento da Tese... 11 1.3 Enquadramento Teórico... 12 1.4 Planeamento... 12 2. Problema... 13 3. Conceitos... 15 3.1 Computação móvel... 15 3.2 Processo Negócio... 15 3.3 Sistemas Móveis... 15 3.4 Sistemas de informação empresariais... 16 3.5 Workflow... 16 3.6 Sistema de gestão workflows... 16 4. Objectivos... 17 4.1 Requisitos... 17 4.2 Objectivos pessoais... 17 4.3 Benefícios esperados... 18 5. Estado da Arte... 19 5.1 Documentos Científicos... 20 5.1.1 Exótica... 20 5

5.1.2 INCA s... 21 5.1.3 MAGI... 23 5.1.4 CosmoBiz... 24 5.1.5 Processos desconectados, mecanismos e arquitecturas para Mobile E- Business (14)... 25 5.1.6 Experiência em operações desconectadas em ambientes de computação móvel (15)... 27 5.1.7 WHAM: supporting mobile workforce and applications in workflow environments (17)... 28 5.2 Soluções comerciais... 28 5.2.1 Teasing Mobile workflow... 28 5.2.2 WonderWare... 29 5.2.3 Apacheta... 30 5.3 Avaliação de soluções... 31 6. Solução... 34 6.1 Vista Geral... 34 6.2 Revisão de processos de negócio... 35 6.3 Arquitectura... 36 6.3.1 Estações móveis... 37 6.3.2 Estação fixa... 40 6.3.3 Comunicação para o exterior... 40 6.4 Linguagens de Programação... 40 6.5 Persistência de dados... 41 6.6 Mapeamento Objecto-Relacional... 42 6.7 Sincronização... 43 6.7.1 Provedores... 43 6.7.2 Participantes... 44 6.7.3 Componentes da plataforma... 46 6.7.4 Gestão versões... 48 6

6.7.5 Fluxo sincronização... 49 6.7.6 Gestão conflitos... 51 6.7.7 Código Gerado... 51 6.7.8 Filtros Sincronização... 53 6.7.9 Web service... 54 6.8 Segurança... 54 6.9 Ferramentas utilizadas... 55 7. Actividades no percurso de desenvolvimento da dissertação... 56 7.1 Participação em workshops... 58 7.2 Participação na Realização de um Paper... 60 8. Validação da Solução... 61 9. Conclusões... 63 10. Trabalho Futuro... 65 11. Referências... 67 12. Anexos... 70 12.1 Glossário... 70 12.2 Acrónimos... 70 12.3 Anexo 1... 72 12.4 Anexo 2... 73 7

IV. Lista de Figuras Fig. 1 Arquitectura Exótica... 20 Fig. 2 Arquitectura INCA s... 22 Fig. 3 Arquitectura MAGI... 23 Fig. 4 Arquitectura camadas CosmoBiz... 24 Fig. 5 Maquina de estados para suportar desconexão... 26 Fig. 6 Arquitectura Coda... 27 Fig. 7 Arquitectura WHAM... 28 Fig. 8 Arquitectura Teasing Mobile WorkFlow... 29 Fig. 9 Arquitectura wonderware... 30 Fig. 10 Arquitectura Apacheta Service ACE... 31 Fig. 11 Vista geral do sistema móvel... 35 Fig. 12 Workflow exemplo... 36 Fig. 13 Decomposição em módulos... 37 Fig. 14 Vista de ecrãs... 38 Fig. 15 Menu Tarefa... 39 Fig. 16 Esquema Base Dados... 41 Fig. 17 Arquitecturas da Sync Framework... 43 Fig. 18 Provedores Framework... 44 Fig. 19 Participante completo... 44 Fig. 20 Participante Parcial... 45 Fig. 21 Participante Simples... 45 Fig. 22 Componentes da Sync Framework... 46 Fig. 23 Colunas Informação de versões... 47 Fig. 24 Tabelas de Tombstones... 47 8

Fig. 25 Esquema da tabela TASK_Tombstone... 48 Fig. 26 Triggers para Gestão Versões... 49 Fig. 27 Fluxo sincronização... 50 Fig. 28 Excerto código funções sincronização... 52 Fig. 29 Código de chamada à sincronização... 53 Fig. 30 Arquitectura 3-tier de Sincronização... 54 Fig. 31 Diagrama de Processos da CAPF... 57 Fig. 32 Tipos de solução... 66 Fig. 33 Diagrama da cadeia de abastecimento... 72 Fig. 34 Diagrama da rede procurement... 73 9

Introdução Nos dias de hoje, com a competitividade que se tem vindo a sentir por parte das empresas, é de extrema importância e factor decisivo incluir e incorporar toda a tecnologia e metodologia inovadora, de modo a melhorar tempos de resposta e minimizar os tempos de operação, conseguindo assim uma redução nos custos, um aumento da satisfação do cliente e maior competitividade no mercado. Um estudo realizado pelo Internacional Data Corporation (Portugal) sobre as pequenas e médias empresas, revela que o investimento em tecnologias de informação vai continuar a aumentar a uma taxa média de 7.8% ao ano entre 2005 e 2010 (1). As principais razões apontadas são o aumento de produtividade, maior eficácia de processos e a garantia da continuidade do negócio. Hoje e cada vez mais surgem novos paradigmas procedentes da mutação permanente do mercado das tecnologias de informação e comunicação. Diariamente somos confrontados com novos produtos e serviços de mobilização do negócio, que alteram a própria maneira de ser e estar das pessoas, sendo algo cada vez mais importante tendo em conta a constante evolução dos equipamentos móveis como os PDA, a abrangência e velocidade das ligações, nomeadamente as 3G oferecidas pelas operadoras móveis, e os sistemas de base dados móveis introduzidos. Outro factor motivador é o crescente número de utilizadores móveis por todo o mundo, como mostra o estudo de cinco anos realizado pelo IDC (2), tendo em conta as ferramentas por estes disponibilizadas, pequenos aparelhos de elevado suporte à realização de um grande leque de actividades. Nestes dispositivos são encontradas vantagens competitivas para as empresas, nomeadamente na redução de custos, qualidade e rapidez dos serviços prestados bem como agilizar os seus processos de negócio. 1.1 Estrutura do relatório Introdução: Neste capítulo é feita a descrição do contexto onde se insere a indicação da motivação e descrição do problema. Problema: Aqui é descrito o principal problema abordado nesta tese. 10

Conceitos: Breve descrição de alguns conceitos para melhor compreensão do conteúdo desta dissertação. Objectivos: No presente capítulo são descritos e relacionados objectivos pessoais e objectivos associados ao projecto. Estado Arte: Este capítulo alberga todo o trabalho de pesquisa e investigação realizado referente ao problema em questão, resultantes de todas as perspectivas pertinentes para o desenvolvimento da solução. Solução: Neste capítulo é apresentada uma breve descrição da proposta de solução, bem como uma presentação do modo de funcionamento e respectiva arquitectura. Actividades no percurso de desenvolvimento da dissertação: Descrição das actividades realizadas, participação em workshops e co-produção de um paper. Conclusões: Descrição da relação dos objectivos com uma investigação relacionada e com a proposta de solução. Trabalho Futuro: Direcções a tomar de forma a acrescentar valor ao trabalho realizado nesta dissertação Referencias: Referencias Bibliográficas Anexos: Contêm diagramas, glossário e acrónimos. 1.2 Enquadramento da Tese Esta Dissertação foi realizada com vista à obtenção de Grau mestre em Engenharia Informática e de Computadores, curso frequentado no Instituto Superior Técnico pertencente Universidade Técnica de Lisboa. O trabalho foi realizado na Empresa Link Consulting SA sob orientação do Professor Pedro Manuel Moreira Vaz Antunes de Sousa, do departamento de Engenharia Informática do IST, e coordenação do Engenheiros Manuel José Rolo da Fonseca. 11

1.3 Enquadramento Teórico Neste subcapítulo irei enquadrar a dissertação no mundo real, mostrando a motivação e casos de uso associados. Como enquadramento podem referir-se diversos exemplos em que funcionários de várias empresas necessitam de informações actualizadas no local, informações estas que passam por dados de clientes necessários a um vendedor, tarefas a executar por um operário, dados recolhidos no local através de um responsável de fiscalização, bem como a junção das três em casos mais complexos. Este tipo de ligação é normalmente feito por ferramentas tradicionais de baixa eficiência, como o telefone e os relatórios em papel. Para além disto pelo facto de as tarefas de recolha de informação e da posterior inserção da mesma no sistema, serem feitas por indivíduos/pessoas diferentes existe uma maior probabilidade de erros de transcrição. Um exemplo disso, é o caso no qual vou focar a atenção da minha dissertação, trata-se das operações realizadas na exploração florestal, onde apenas são usadas ferramentas tradicionais sem qualquer automação ou tecnologia, neste exemplo é especialmente evidente a ausência de conexão de rede, sendo este o problema fundamental encontrado. 1.4 Planeamento Esta secção enquadra temporalmente a realização desta tese, no segundo semestre do ano lectivo 2009/2010. A pesquisa do trabalho relacionado decorreu no primeiro semestre do ano lectivo 2009/2010, onde a pesquisa se baseou no suporte a utilizadores desconectados em sistemas de gestão de workflows, indicada pelo orientador Professor Pedro Sousa e pela pessoa que me auxiliava dentro da Link, o Eng. Manuel Fonseca. No final dessa surgiu a especificação do problema e a proposta de solução. Toda essa informação foi escrita e entregue num relatório de projecto de dissertação, sendo posteriormente avaliada num workshop realizado no Tagus Park no dia 2 de Fevereiro de 2010. 12

2. Problema O problema que é abordado nesta dissertação é: Falta de suporte a realização de tarefas de um workflow com dispositivos móveis e em ambientes desconectados Este problema é enfrentando nomeadamente na exploração florestal, onde a cobertura de rede no meio dos talhões da madeira é escassa e muitas das vezes inexistente. Privando a utilização de ferramentas automáticas para recolha de dados e controlo das operações, fazendo com que tudo isso seja feito com ferramentas tradicionais de baixa eficiencia e alto número de erros. Para que exista um sistema em que a mobilidade não seja uma condicionante, permitindo a atribuição de tarefas e execução das mesmas a recursos apenas conectados parte do tempo, são encontrados vários problemas ligados ao hardware bem como aos softwares existentes. Os factores apresentados de seguida são as principais condicionantes e que por sua vez geram este problema. Ecrãs pequenos para aplicações complexas, assim como os mecanismos de inserção de dados tendem a ser mais pequenos e de menor facilidade de utilização que num computador de secretaria. Por norma todos estes dispositivos móveis têm um poder de processamento e armazenamento notavelmente mais fraco que um servidor ou computador de mesa, impossibilitando a instalação de aplicações mais pesadas, nomeadamente um motor de gestão de workflows, de forma a permitir ter a lógica num PDA. No caso da floresta são dados como factores importantes a robustez dos equipamentos bem como a sua autonomia em penalização do poder de processamento e do armazenamento. Existe uma grande variedade de dispositivos PDAs, heterogeneidade nos sistemas operativos, suporte para linguagens de programação, respectivos mecanismos de inserção de dados e visualização dos mesmos. Os sistemas gestão de workflows bem como outros sistemas aplicacionais restringem, por norma, o acesso a recursos que se encontram fora das instalações da organização. Quando existe suporte, exigem que os dispositivos móveis estejam conectados todo o tempo em que 13

se está a realizar a tarefa, impossibilitando do ponto de vista de software uma interacção com recursos em ambientes desconectados ou com quebras de conexão. 14

3. Conceitos Neste capítulo são apresentadas breves descrições de diversos conceitos chave relacionados com a dissertação, de forma a facilitar a compreensão da mesma. 3.1 Computação móvel Cada vez menos se vêm as pessoas que operam fora das organizações a utilizarem ferramentas tradicionais, como relatórios em papel e chamadas telefónicas para as trocas de informação. O método mais empregado actualmente é o uso de um equipamento móvel de apoio à tarefa que consiste em levar para o terreno um computador portátil, PDA ou Smartphones, o respectivo software e todos os ficheiros necessários à realização de tarefas. 3.2 Processo Negócio Os processos de negócio são actividades previamente estabelecidas que têm como objectivo determinar a forma como o trabalho é realizado numa organização. Constituem um conjunto de acções relacionadas entre si de forma lógica e coerente, a fim de promover um resultado favorável à organização, tanto a nível interno como externo (3). 3.3 Sistemas Móveis Os sistemas móveis são conhecidos por ter um determinado número de estações fixas, com localização fixa e estática e um conjunto de estações móveis. Todas as comunicações entre estes dois tipos de estações fazem-se normalmente através de ligações sem fios, nomeadamente o WIFI, GPRS e 3G. Neste tipo de sistemas a estação móvel não se encontra sempre conectada, e portanto, em momentos de desconexão as tarefas são realizadas com os dados guardados persistentemente. As desconexões podem ser voluntárias, para poupar nos preços das comunicações ou para aumentar a autonomia, ou involuntários, ao passar por um local sem cobertura de rede ou em caso de falha nas estações fixas. 15

Um caso particular de sistemas móveis relevantes para este trabalho, são os sistemas de base dados móveis (SBDM), que são uma extensão aos sistemas de base dados distribuídos (SBDD). Os SBDM têm estações móveis com persistência e características diferentes e mais limitadas que as estações fixas. 3.4 Sistemas de informação empresariais Expressão utilizada para descrever um sistema que permite colectar, processar, transmitir e disseminar dados que representam informação para a empresa. A informação é um recurso de extrema importância nas organizações, quanto mais fiável, oportuna e exaustiva for, mais coesa será a empresa e maior será o seu potencial de resposta às solicitações da concorrência (4). 3.5 Workflow Trata-se de uma sequência de passos necessários para que se possa atingir a automação de processos de negócio, de acordo com um conjunto de regras definidas, envolvendo a noção de processos, permitindo que estes possam ser transmitidos de uma pessoa para outra de acordo com algumas regras (5). 3.6 Sistema de gestão workflows Sistema que cria, gere e controla workflows com o uso de software. Este sistema trata da automação dos processos de negócio, através de interacções com os recursos (responsáveis pela realização de tarefas), bem como da invocação de outros sistemas de informação. Estes sistemas dispõem de ferramentas de supervisão e controlo, para permitir não só o rearranjo das tarefas mas também a verificação do estado de cada processo. (6) São exemplos ou parte de sistemas de informação empresariais nos quais foquei mais a minha Framework. 16

4. Objectivos Neste sentido proponho-me encontrar uma solução que permita integrar os recursos que realizam o seu trabalho em ambientes sem rede com os sistemas do backoffice, nomeadamente sistemas de gestão de workflows. Vou focar a minha solução no caso da floresta, e focar o suporte a tarefas de Recolha de dados, e controlo de operações. O foco nestas tarefas visa encontrar uma solução para este nicho de mercado. 4.1 Requisitos Tendo em conta o problema e as necessidades pretendidas pelos utilizadores desconectados de um sistema de gestão de workflows no ambiente florestal, sumarizaram-se e redigiram-se os requisitos mais importantes de forma a servir de guia. Foram identificados os seguintes requisitos funcionais: Automatizar a distribuição das actividades pelos vários recursos no campo; Disponibilizar indicação e descrição do local para cada tarefa; Recolha de dados no momento da realização de tarefas; Disponibilizar serviços para actualização do sistema backoffice; Interface adequada a PDAs; Possibilidade de trabalhar em modo desconectado; Disponibilizar armazenamento persistente localmente; Disponibilizar autonomia aos clientes de forma a evitar conflitos entre os mesmos no momento da sincronização com o backoffice; Mecanismos de envio e de recepção apropriados para manter a integridade da informação. 4.2 Objectivos pessoais Posteriormente são apresentados os objectivos pessoais que se pretendem alcançar com a realização desta tese de mestrado: 17

Estudar o que existe no Mercado associado ao problema de suporte a clientes em ambientes desconectados; Propor e formalizar uma solução; Validar esta solução através de uma implementação. Redigir e apresentar a Dissertação para alcançar o Grau Mestre; 4.3 Benefícios esperados Neste subcapítulo são enunciados alguns dos benefícios que se esperam conseguir com a solução encontrada em casos reais de utilização. Menor risco de erro nos dados recolhidos; Redução de papel envolvido nos processos; Eliminar tempo necessário à inserção de dados no sistema; Informação actualizada com maior rapidez; Maior quantidade e qualidade de informação disponível nas tomadas de decisão por parte de todos os agentes do CAPF; Aumento da eficiência dos recursos nas interacções no terreno; Distribuição automática das actividades pelos recursos no campo; 18

5. Estado da Arte Todo o trabalho de investigação relacionado com esta temática para a realização do relatório de projecto de dissertação, foi recolhido no sentido de suportar clientes desconectados para sistemas de gestão de workflows. Assim este capítulo é composto não só por um resumo do trabalho relacionado já recolhido e considerado importante na iteração anterior, mas também por um novo encontrado nesta iteração. Todos os trabalhos encontrados que incluem suporte para utilizadores fora das instalações da organização dividem-se em duas metodologias diferentes de funcionamento: as soluções online e algumas soluções com sincronização. As soluções online são aquelas que normalmente são acedidas nos dispositivos móveis através de um simples browser. Este tipo de soluções não tem qualquer lógica do lado do cliente, impossibilitando-o de realizar qualquer operação na ausência de rede. Sendo que as soluções online não resolvem o problema inerente a esta tese, estas serão descartadas e não será feita qualquer referência às mesmas. As soluções que interessam são aquelas que têm alguma lógica negócio lado do cliente e permitem ao mesmo realizar o trabalho independentemente das condições de rede, trabalho este que é sincronizado posteriormente com as aplicações de backoffice nomeadamente sistemas de gestão de workflows. Será criticada uma hipótese de enquadramento das possíveis soluções existentes ou do conhecimento importante que podemos retirar destas, segundo os objectivos anteriormente referidos no sub-capitulo 5.3. Estas críticas são importantes para saber de que forma é que as soluções se adequam ou não a este trabalho e de que forma podem ajudar. Todas as soluções online enunciadas no relatório de projecto da dissertação serão agora descartadas pois não introduzem qualquer valor para a direcção final levada a cabo por esta tese. A pesquisa de documentos científicos baseou-se em sites indicados pelo coordenador Professor Pedro Sousa: CiteSeer, b-on, IEEE Xplore, ACM Digital Library, Science Direct e também SpringerLink. As soluções comerciais foram encontradas através de motores de pesquisa nomeadamente o Google assim como algumas indicadas pelo Eng. Manuel Fonseca. 19

5.1 Documentos Científicos Aqui serão resumidos alguns aspectos interessantes encontrados em documentos científicos assim como resumo de algumas das soluções apresentadas para endereçar este problema ao longo do tempo. 5.1.1 Exótica O Exótica (7) é um projecto de desenvolvimento, que mesmo sendo antigo foi importante no seu tempo, realizado pelo centro de pesquisa da IBM. Trata-se de um upgrade ao FlowMark, conhecido como o sistema de gestão de workflows da IBM, para suportar clientes Offline. De seguida é apresentada de forma sintética a arquitectura do sistema FlowMark (Fig.1). O sistema FlowMark é composto por um Cliente para os recursos onde são vistas as suas tarefas associadas (runtime client), um cliente para controlo do processo (program execution client), um servidor (FlowMark Server) e uma base de dados orientada por objectos (Object Store Server). A comunicação dos workflows é suportada essencialmente pela troca de mensagens entre os componentes descritos, mensagens estas que indicam que uma tarefa está pronta para execução, o início da execução e indicação de fecho que a dá como completa. Fig. 1 Arquitectura Exótica Dentro desta arquitectura foram pensados dois caminhos a seguir para suportar clientes Off-line, todos com o intuito de alterar apenas o cliente, deixando o servidor e a base de dados intactos. A primeira pressupõe a atribuição de um conjunto de tarefas a cada recurso, o qual irá fazer download de toda a informação relevante para a realização das mesmas antes do momento de desconexão. A segunda permite aos clientes fazer navegação própria nos 20

processos através do download de parte dos processos. A primeira solução foi mais explorada, pelo facto de ser mais simples e de não adicionar tanta complexidade ao cliente. A versão existente do FlowMark já contem algumas potencialidades em modo Off-line, tal como, permitir realizar a tarefa corrente sem conexão. A sua única limitação era apenas o facto de não ser possível passar para uma tarefa subsequente sem que, a informação resultante da finalização da tarefa corrente, fosse enviada ao servidor. As alterações vão ser feitas essencialmente ao Program Execution Client, ao qual vai ser adicionado armazenamento persistente para guardar a informação necessária às tarefas a correr no Runtime Client e os resultados da finalização das mesmas. A funcionalidade foi pensada da seguinte forma: para que se dê inicio ao funcionamento desconectado é necessário passar por uma fase de preparação onde é feito o download de toda a informação necessária e onde o cliente selecciona e tranca as tarefas que tem por intenção realizar, permitindo assim, ao servidor, evitar que dois recursos iniciem a mesma tarefa. O servidor passa então a ter dois tipos de tarefas a realizar, as que estão reservadas por recursos Off-line e as On-line. Em modo desconectado o cliente apenas pode realizar as tarefas que previamente trancou. Quando o Cliente é novamente conectado envia toda a informação sobre as tarefas que completou, passando-as já completas do lado do servidor, sincronizando a sua lista de tarefas com a do servidor. Esta solução tem como contrapartida a instalação possível apenas em desktops ou laptops, deixando de fora os PDAs. 5.1.2 INCA s Da Universidade de Houston provém outro desenvolvimento denominado INCAs (8). INCA é um pacote de informação no qual se baseia toda a arquitectura deste sistema e tem por objectivo resolver problemas de workflows dinâmicos em ambientes distribuídos. O funcionamento baseia-se numa arquitectura P2P pelo facto de não existir um cliente nem um servidor e de todos os nós se comportarem da mesma forma. A esses nós, é dado o nome de Estações de Processamento. Pode ser visto o esquema da arquitectura na figura seguinte. 21

Fig. 2 Arquitectura INCA s Cada INCA contém todos os dados privados do workflow, o Log do mesmo para garantir atomicidade e um conjunto de regras que definem o controlo e o Fluxo de informação entre os vários passos. Cada estação de processamento têm toda a potencialidade de um motor de workflow e tem a função de receber as INCAs, realizar a actividade associada e enviar ao próximo destinatário por um canal adequado. Ao realizar o seu serviço, cada estação de processamento pode adicionar, apagar ou modificar regras da INCA assim como as suas. Esta arquitectura resolve o factor de distribuição e da realização das tarefas em ambientes diferentes. Para que ocorra um funcionamento semelhante ao representado, as estações de processamento são dotadas de uma camada, denominada INCA shell, composta por dois módulos: o agente e o sistema de gestão de regras. O Agente ao receber uma INCA tem como funções: Guardar os Dados e Regras da INCA de forma persistente; Fazer a chamada ao serviço da Estação de processamento, passando-lhe o contexto, aguarda que este execute a actividade de retorne os resultados; Guardar os resultados da execução persistentemente; Executar as regras presentes no módulo de gestão de regras da INCA e envia-las para os destinos apropriados; O Sistema de gestão de regras tem como funcionalidade instalar as regras na chegada da INCA e proceder à sua execução quando é feita a chamada pelo Agente. 22

5.1.3 MAGI Baseado no http e no Apache Project surge o MAGI (9) (Micro-Apache Generic Interface) que é uma Framework arquitectural que suporta a coordenação do negócio electrónico e permite a instalação em várias plataformas. O http tem a propriedade de ser escalável desde dispositivos móveis a desktops e permite o uso com qualquer conteúdo. Permite, portanto, que o WAP (wireless Application protocols) possa ser usado com o MAGI mantendo a interoperabilidade com a WEB. A WEB é a infra-estrutura perfeita à escala da internet, mas falha na falta de algumas primitivas necessárias para o suporte de colaboração e coordenação. Para contornar isto e permitir a utilização de workflows pela Web são normalmente usados sistemas de workflow centralizados, que limitam o acesso e a interacção a clientes desconectados. O MAGI resolve isto, disponibilizando uma Framework para facilitar a construção de aplicações distribuídas em XML e Java e promovendo o envio de eventos para qualquer dispositivo que contenha um servidor MAGI a correr. A arquitectura é composta por dois componentes chave: um micro- Apache http server e uma interface genérica e extensível, dispondo-se da forma apresentada na figura seguinte. Fig. 3 Arquitectura MAGI Os servidores MAGI podem ser configurados para IP s dinâmicos ou estáticos, sendo que os dinâmicos requerem um servidor de DNS intermediário, desenhado essencialmente para realizar os workflows que incluem troca de documentos. 23

5.1.4 CosmoBiz O CosmoBiz (10), outro projecto de desenvolvimento a decorrer desde Janeiro de 2007 por parte do departamento de IT da universidade de Copenhaga, tem como objectivo atingir uma plataforma para suporte da evolução dos processos de negócio, de forma distribuída e com execução em ambientes mobile. Para alcançar esse objectivo foram reunidas três áreas de pesquisa: a Computer Supported Cooperative Work (CSCW), a área de formalização da evolução dos processos de negócio para mobile e a implementação de sistemas distribuídos e Peer-to-Peer (P2P). O CSCW tem vindo a desenvolver sistemas de informação complexos que permitem coordenação e integração de actividades distribuídas. Foi feito um desenvolvimento importante para perceber a utilidade e as vantagens do alinhamento das tarefas entre os recursos e a partilha da informação. Este teve como ponto de partida a falha de tecnologia no que toca à mobilidade de recursos e actores. Na evolução da formalização dos processos de negócio móveis é adoptado um formalismo bigraphical reactive systems (11), pelo facto de toda a flexibilidade oferecida pelas evoluções, tanto as distribuídas como as de mobilidade, complicar a construção de descrições correctas de processos. Mais importante é a parte da implementação que passa por criar um motor de gestão de processos de negócio que suporte clientes móveis mesmo com possíveis desconexões. Fig. 4 Arquitectura camadas CosmoBiz A solução apresentada para o sistema de gestão de workfows é composta por três camadas. De baixo para cima temos XML Store (12) para o armazenamento, Distributed Reactive XML (13) como linguagem de programação onde se encontra alguma da lógica de negócio, e por último, o BPEL como linguagem de execução dos processos de negócio, tudo isto representado na figura acima. O Distributed Reactive XML guarda documentos XML com o estado de 24

execução dos processos na XML Store. Estes têm uma arquitectura P2P, permitindo assim uma distribuição e suportando a mobilidade. Os Peers podem ser estáticos (quase sempre conectados) ou dinâmicos (conectividade instável), dotando assim os dispositivos de recursos limitados, apenas com conteúdo essencial aos processos que o actor está a realizar. Após o funcionamento desconectado a sincronização é depois feita com um controlo optimista e seguindo estratégias ainda a serem investigadas. Relativamente a dispositivos móveis, um motor de workflow leve está ainda em progresso de implementação. 5.1.5 Processos desconectados, mecanismos e arquitecturas para Mobile E- Business (14) Neste documento, são apresentadas algumas soluções para o suporte a clientes para integrar processos de negócio, nomeadamente acesso a conteúdos E-Commerce. Assim são enunciados alguns mecanismos de suporte à desconexão dos clientes durante as transacções entre os clientes (estações móveis) e os servidores (estações fixas). Toda esta solução, visto ser desenvolvida nos centros IBM, usa base de dados e aplicações produtos da mesma, os clientes são dispositivos móveis e os servidores Web-application servers de E-Commerce ou Servidores de conteúdos. Para suportar a desconexão, falhas na rede e entraves do cliente são utilizadas máquinas de estados. Na figura seguinte está uma máquina exemplo, na qual é possível observar os estados pelos quais passa um pedido de compra. 25

Fig. 5 Maquina de estados para suportar desconexão No caso de se desenrolar uma operação sem desconexões apenas são percorridos cinco estados possíveis que correspondem aos estados representados a azul. Os estados a laranja servem para suportar situações de desconexão e outras falhas, nomeadamente excepções por falta de memória. Este sistema permite ao utilizador processar várias encomendas ao mesmo tempo, mesmo em caso de desconexão, podendo estas estar em qualquer um dos estados. No momento da desconexão, cada estado tem uma transição para um estado desconectado respectivo. Sendo que os processos de negócio podem ser projectados em máquinas de estados, maquinas estas que foram apresentadas anteriormente, onde podem ser injectados estados utilizados no momento de desconexão e erros, de forma a suportar estes de forma transparente. 26

A arquitectura é baseada num middleware de suporte entre o cliente e o servidor, cuja arquitectura será aprofundada, mas que pode ser consultada no documento indicado nas referências. 5.1.6 Experiência em operações desconectadas em ambientes de computação móvel (15) O objectivo principal é o desenvolvimento de um sistema que torne transparente a portabilidade e conexão dos dispositivos móveis que interagem uns com os outros. Este documento foca o acesso à informação partilhada através de dispositivos móveis, informação esta fundamental aos recursos nas respectivas operações. Todo o acesso à informação se baseia num sistema designado de Coda (16). O Coda tem um funcionamento simples, baseado em caches, desenhado para suportar desconexões e replicação de servidores. Suponha-se a existência de vários clientes com um respectivo armazenamento persistente, um gestor de caches (Vénus) e vários servidores replicados com um gestor de versões (Volume Storage Group). A figura seguinte demonstra a arquitectura de uma forma simples. Fig. 6 Arquitectura Coda O autor conclui que o uso do Coda em situações de desconexão tem alguns inconvenientes mas nenhum é considerado fatal. De qualquer modo para que houvesse uma evolução por parte do sistema era necessária uma refinação do mesmo. O uso de Unix levou a que esta tecnologia fosse posta de parte. 27

5.1.7 WHAM: supporting mobile workforce and applications in workflow environments (17) Este documento relata a prototipagem de um sistema denominado WHAM cuja designação é workflow enhancements for mobility, cujo objectivo é suportar a força de trabalho móvel bem como as aplicações usadas por estas. Os principais problemas a endereçar são as restrições da conectividade, desconexões e o funcionamento desconectado. A arquitectura do WHAM consiste em duas aplicações principais: o IBM s MQSeries Workflow e um gestor de tarefas à medida, desenvolvido em Java, uma no servidor (estação fixa) e outra no cliente (estação móvel) respectivamente. As funções chave disponibilizadas no cliente são: localização das tarefas sobre um mapa; atribuição dinâmica de actividades e operações de workflow desconectado. O diagrama seguinte ilustra brevemente a referida arquitectura. Fig. 7 Arquitectura WHAM 5.2 Soluções comerciais Para além de documentos cientificos que endereçam o problema, existe também algumas ferramentas comerciais que visam resolver este. 5.2.1 Teasing Mobile workflow Esta é uma das soluções comerciais encontradas. Foi desenvolvida e é vendida pela empresa Teasing sediada na Holanda. Esta solução denominada Teasing Mobile Workflow (18) disponibiliza software do lado do dispositivo móvel bem como do lado do backoffice. 28

Do lado do dispositivo móvel é oferecido um sistema de gestão de workflows com um funcionamento independente da rede de acesso à informação proveniente do backoffice, para além de muitas outras funcionalidades não relevantes para o contexto do projecto. No backoffice são oferecidas ferramentas para despacho, controlo e planeamento dos trabalhos a serem realizados pelos recursos no campo, produção de relatórios e análise dos dados. No que diz respeito à arquitectura, a informação a que se tem acesso é escassa. Sabe-se apenas que existe uma aplicação para instalar em Windows mobile, e um módulo que faz a integração entre a mesma e o sistema do backoffice. Fig. 8 Arquitectura Teasing Mobile WorkFlow A integração é feita por XML permitindo assim a integração com variadíssimos sistemas de backoffice, sendo que os mais recomendados pela empresa responsável pela venda do produto são a SAP e Microsoft Dynamics. Esta integração é feita através de um módulo instalado do lado do backoffice, o backoffice integration, assegurando uma comunicação e uma sincronização seguras. 5.2.2 WonderWare Outro caso de Solução comercial é a disponibilizada pela empresa WonderWare sediada nos Estados Unidos da América. Esta atribui o nome de IntelaTrac (19) ao seu produto, que não pode ser directamente associado a workflows, pelo facto de a sua funcionalidade estar mais ligada à recolha e uso de boas práticas por parte dos utilizadores, com o intuito de controlar os recursos e disponibilizar um software móvel de apoio à decisão. As suas tarefas são assim controladas pelo conhecimento já adquirido anteriormente. 29

Na figura seguinte é apresentada, do lado do dispositivo móvel, uma arquitectura composta por uma aplicação Mobile IntelaTrac e uma de gestão de tarefas e recursos, instalada no backoffice designada IntelaTrac Management Center. Fig. 9 Arquitectura wonderware Relativamente à interacção entre os recursos, a informação será recolhida usando um questionário com regras associadas, que incluem as boas práticas e que consequentemente vão receber mensagens de aviso no decorrer das tarefas para reagir a problemas já conhecidos, sem que seja necessário o contacto com o sistema central. Os questionários para além de recolherem a informação, ajudam a tomar decisões por parte dos recursos ou mesmo a medir a performance destes. Os gestores têm a aplicação de backoffice que lhes permite monitorizar os estados das tarefas atribuídas aos recursos e verificar a performance de cada recurso na execução das suas respectivas tarefas. Assim, tal como o produto Teasing, este também tem a vantagem de permitir a escolha do ERP ou outro sistema backoffice a utilizar, devido ao facto de na parte backoffice do pacote (IntelaTrac Management Center) estar embutida uma camada de integração que serve de interface para o mesmo. Existem casos de sucesso detalhadamente descritos, como é o exemplo de uma grande refinaria a Chevron nos Estados Unidos da América. 5.2.3 Apacheta Continuando com as soluções comerciais, igualmente proveniente de uma empresa sediada nos Estados Unidos da América, este produto é denominado ServiceACE TM e faz parte das Mobile Business Solutions oferecidas pela Apacheta. Disponibiliza uma aplicação Mobile com um motor de workflow, uma aplicação interactiva de criação de workflows para o backoffice, o 30

respectivo servidor e portais de acesso e gestão no backoffice, como pode ser observado ver na figura seguinte. Fig. 10 Arquitectura Apacheta Service ACE A aplicação que está instalada no dispositivo móvel tem a propriedade de ser rapidamente adaptada a cada caso de negócio e dispõe de vários workflows predefinidos que traduzem boas práticas conhecidas e a possibilidade de criar novos workflows, de forma interactiva no respectivo editor fornecido. Nesta solução é possível que a qualquer altura possam ser enviados novos workflows para a aplicação mobile, desde que haja conexão. Além disso, este produto suporta ainda ligações com GPS e RFID, permitindo assim integrar outras funcionalidades, como guiar o trabalhador ao local da tarefa através do GPS ou permitir a leitura de tags RFID, facilitando a identificação de objectos e um sistema de troca de mensagens em tempo real, facultando o envio e recepção de avisos importantes. Assim, tal como outras soluções comerciais, esta afirma também a facilidade de integração com os produtos ERP (20). 5.3 Avaliação de soluções Neste subcapítulo vou fazer uma breve crítica sobre o estado de arte encontrado e as nuances retiradas para a realização da solução. Um dos documentos mais referenciados em todos os documentos científicos que envolvam suporte a clientes desconectados é do Exótica, e percebi esse facto, pois é uma solução simples com boas ideias teóricas, com três detalhes que a fazem dela má na prática e pouco utilizada. Esses detalhes são a tecnologia IBM cara e antiga, a falta de suporte a dispositivos 31

móveis e finalmente a necessidade de uma fase de preparação antes da desconexão, tornando inútil a solução numa desconexão inesperada, mas as ideias boas estão lá, as alterações simples feitas para suportar desconexões apenas do lado do cliente, ao adicionar persistência a este, bem como os mecanismos para iniciar o processo de desconexão e mecanismos para sincronizar dados posteriormente. No que toca as INCA s penso ser uma solução demasiado complexa, e o facto de ter uma arquitectura P2P aumenta o problema de controlo, e ao contrário do que se possa pensar não aumenta a colaboração entre utilizadores, já que não podem ser realizadas duas tarefas do mesmo workflow em paralelo, por fim e como ponto fundamental suporta dispositivos móveis logo é descartada, ficando apenas a visão de uma possível ligação entre cliente P2P para colaboração de utilizadores. Na solução vista com a utilização do Magi, temos outro sistema complexo, com uma utilização minuciosa dos servidores Apache, eu achei muito difícil de aplicar. O uso de bookmarks (marcadores) com cache além do simples ponteiro não é intuitivo, sendo essa a maneira usada para suportar a desconexão. Desenhado para tarefas que evolvam apenas troca de documentos, todas as outras funcionalidades mais ligadas a workflows e gestão de tarefas não são implicitamente suportadas, apenas com uma extensão que teria de ser desenvolvida. O CosmoBiz é outro documento científico com uma solução semelhante às Inca s apresentando o mesmos problemas, não existe controlo centralizado, impossibilita a realização de tarefas paralelamente do mesmo workflow, e não suporta dispositivos móveis, o que levam também a descartar sua utilização. No ponto 5.1.5 é descrito um documento que apresenta uma solução interessante, controlada por máquinas de estados. Todo o processo de realizar uma tarefa passa por vários estados, no caso de desconexão todas as tarefas em realização e as que se realizam em modo desconectado têm uma máquina de estados pendente que necessita ser guardada persistentemente até nova conexão, com o realizar de muita tarefa, isto vai aumentar o consumo de memória linearmente. Fazendo o dispositivo lento, nomeadamente dispositivos móveis, no caso de longos períodos na ausência de rede. Esta solução é também baseada em produtos IBM, o que faz o seu preço elevado e de difícil acesso para testes e futura aplicação. 32

De seguida no ponto 4.1.6 trata-se de uma referencia também antiga, cujo uso não é praticável trata-se de uma solução de UNIX desactualizada. O único ponto de interesse é as nuances que se podiam tirar do sistema de Caches presente no Coda, do tipo cliente servidor, com dados centralizados e um gestor de caches em cada cliente. A solução denominada WHAM relatada, diz suportar desconexão no documento, mas não está explicado a forma como este suporte é realizado, daí eu suponha que seja alguma persistência do lado do cliente de alguma forma gerida por proxys referidos no documento. É outro dos desenvolvimentos da IBM, cujo qual não tive acesso para testar. As soluções comerciais encontradas ambas diziam na sua documentação, a qual podemos retirar do site de cada uma respectivamente, que resolviam de certa forma o problema apresentado. Mas todas estas tinham preços de licença elevados, e apesar do esforço a minha tentativa de conseguir versões de avaliação não foi bem-sucedida, mesmo com os vários contactos por correio electrónico e insistência em nome da Link Consulting para obter as mesmas. Com isto não me foi possível avaliar as mesmas. De qualquer das formas penso que nenhuma seja a mais adequada e orientada ao problema encontrado na exploração florestal. As mesmas não possuem grandes ferramentas de sincronização e cooperação, são mais indicadas para trabalho autónomo e conter a pouca lógica de negocio necessária no dispositivo móvel. 33

6. Solução O Capitulo seguinte tem por objectivo explicar ao leitor a solução encontrada para enfrentar o problema, bem como a arquitectura e funcionamento da framework desenvolvida. Nenhuma das soluções de estado de arte parece portanto ideal, finda a procura do estado de arte, e tendo em conta os problemas das soluções criticados anteriormente, concluí que a criação de uma Framework versátil e extensível, usando tecnologias recentes, com um funcionamento simples, e que permita uma fácil integração com sistemas de informação, nomeadamente sistema de gestão de workflow, seria o passo a realizar a seguir. A solução é simples e passa por disponibilizar uma worklist persistente no PDA. Cada utilizador recebe assim as suas tarefas nos momentos em que se encontra conectado a uma rede 3G ou com redes Wi-Fi, com essas tarefas guardadas persistentemente pode deslocar-se para os ambientes desconectados onde se desenrola a exploração florestal. No local as tarefas são realizadas e guardados os dados recolhidos, esta informação é guardada na base dados móvel, esta que posteriormente será sincronizada. No momento de re-conexão as tarefas completas são sincronizadas para o servidor de middleware e posteriormente apagadas do dispositivo móvel, libertando espaço na base dados móvel, além disso são recebidas novas tarefas que tenham sido associadas posteriormente a esse utilizador. A solução na projecção e implementação de um sistema móvel, constituído por uma estação fixa e várias estações móveis. A estação fixa serve de Middleware entre o sistema de gestão de workflows, localizado no backoffice, e a estação móvel. Para além da implementação de um sistema móvel que liga com o sistema de gestão de workflows, vamos ter também alguma restruturação por parte dos processos de negócio corridos neste, de forma a suportar um maior número de actividades por parte do utilizador. 6.1 Vista Geral No diagrama seguinte pode observar-se o funcionamento geral da aplicação, onde podem ser identificados os tipos de estações existentes a as trocas de informação realizadas. 34

Fig. 11 Vista geral do sistema móvel Este sistema desenvolvido, possuí uma estação fixa onde está todo o Middleware de ligação entre o sistema de gestão workflow e a estação móvel, sendo este responsável pela gestão de tarefas. É observável também a presença de várias estações móveis que dispõem da aplicação para realização de tarefas e respectiva worklist. As comunicações fazem-se, por norma, entre a estação fixa e a estação móvel, por meio de WCF services, as comunicações entre o sistema de gestão workflows e o middleware é feito através de um adaptador específico. 6.2 Revisão de processos de negócio A necessidade de alguma manipulação dos processos de negócio subsiste, de forma a promover um maior suporte no caso da desconexão. Além disso, aqui serão também identificados alguns casos de processos de negócio a evitar. Em primeira instância isto é possível visto que não existe grande complexidade nas actividades que são realizadas na exploração florestal. As actividades resumem-se à recolha de dados sobre os talhões para inventário florestal e a valores registados nas cargas aquando do controlo de operações, em que as tarefas podem ser vistas como questionários dinâmicos, diferentes para cada tarefa. 35

Fig. 12 Workflow exemplo Todas as actividades sequências que sejam da responsabilidade do mesmo recurso, devem ser fundidas numa macro actividade devido ao facto de a segunda tarefa de uma sequência só ficar disponível na worklist do utilizador após a execução da primeira e, da sincronização da mesma com o sistema de gestão de workflows. Um exemplo disso é as actividades A e B do diagrama seguinte, que caso sejam da responsabilidade do mesmo recurso devem ser fundidas numa única mais complexa. Existem alguns princípios para simplificação das mesmas, mas neste caso o contrário é favorável. Referenciando agora casos a evitar, é importante destacar aqueles em que existem várias tarefas da responsabilidade do mesmo utilizador espalhadas num workflow, intercaladas com outras de outros utilizadores, devido ao aumento da espera por sincronizações. Exemplo disso é a existência de um utilizador móvel alocado às tarefas A e C. Deste modo, o utilizador da B vai ter de esperar uma sincronização de A que pode só acontecer ao final do dia. As tarefas só devem ficar misturadas caso exista necessidade de dados, caso contrário devem ficar em ramos diferentes. 6.3 Arquitectura De seguida é apresentado ao leitor os módulos pelos quais cada componente software se subdivide, nomeadamente a estações fixa e as estações móveis, de forma a perceber mais 36

detalhadamente o desenvolvimento e o funcionamento das mesmas. O diagrama seguinte mostra os módulos e as ligações entre os mesmos. Fig. 13 Decomposição em módulos A arquitectura implementada nesta Framework trata-se de uma arquitectura clienteservidor, entre a estação móvel e a estação fixa. O servidor (estação fixa) comunica com o sistema de gestão de workflows através de um adaptador. A comunicação entre estas aplicações será feita essencialmente pelas redes 3G e Wi-Fi, usando Web services disponibilizados no módulo de integração. Numa aplicação local, uma arquitectura 2-tier (Client-Server) seria a ideal para fazer a sincronização, mas visto tratar-se de clientes em dispositivos móveis, é necessária a criação de uma arquitectura 3-tier sendo uma WCF Service Library o middleware utilizado. 6.3.1 Estações móveis A aplicação realizada para o dispositivo móvel vai ser a mesma que foi usada pelos recursos no campo. Foi desenvolvida para correr em PDAs e terá o papel essencial de disponibilizar aos recursos no campo a sua lista de tarefas (worklist) e um editor de relatórios dinâmico para recolha de dados. Esta permite o funcionamento autónomo na ausência de rede e realiza sincronizações na presença da mesma. 37

A estação móvel pode ser decomposta em três módulos essenciais, um módulo de interface (GUI), um gestor de tarefas (disponibliza a worklist) e o módulo de sincronização (Sync service). O módulo GUI é responsável por toda a interface disponível visível ao utilizador através do dispositivo móvel. É composto por vários menus de navegação e um gerador de relatórios dinâmico a preencher. Alguns dos ecrãs podem ser vistos nas imagens seguintes, onde está o menu de login,, o menu principal e o menu de tarefas (worklist) respectivamente, estes com valores exemplo sem significado. Fig. 14 Vista de ecrãs O gerador de relatórios é dinâmico e composto por três tipos genéricos de recolha de dados, aquando da realização da tarefa. De seguida serão explicados separadamente cada um destes tipos. O mais simples denominado decisão consiste numa pergunta cujas opções de resposta são sim e não. O seguinte é composto pela pergunta e um campo de resposta livre, de tamanho variável. Finalmente o último, o campo opções contém uma pergunta e um conjunto de hipóteses das quais podemos seleccionar apenas uma. Na figura seguinte pode visualizar-se um exemplo muito simples de uma tarefa modelo com quatro campos para recolha de dados, cada um correspondente aos tipos indicados nas perguntas. 38

Fig. 15 Menu Tarefa O módulo Sync Service é o único elemento presente na aplicação móvel que tem comunicação com o exterior. Este é responsável pela sincronização da estação móvel com a estação fixa e contém todo o código responsável pelo consumo dos serviços criados pela ferramenta da Microsoft Sync Framework, que são providenciados através de um Web service da estação fixa. A estação móvel dispõe também de uma base de dados para persistência dos dados, cujo esquema é criado automaticamente através da ferramenta da sync Framework, tendo em conta o esquema definido na estação fixa. Com a presença desta base de dados, localmente a estação móvel já permite um funcionamento independentemente do estado da rede, visto existir a possibilidade de guardar o trabalho persistentemente. Dentro deste módulo existe também uma rotina de sincronização automática que corre numa thread diferente. Esta é executada em intervalos de tempo definidos pelo utilizador no menu de configuração para que deste modo, todas as actividades de acumulação de dados, por parte das estações móveis, e as tarefas de sincronização, sejam feitas automaticamente. Para além da possibilidade de executar a sincronização a pedido. O módulo gestor de tarefas encarrega-se de colocar as alterações feitas nas tarefas, com todos os dados recolhidos na realização das mesmas, no armazenamento persistente, 39

permitindo desta forma que os dados recolhidos e todas as alterações sejam propagados até à estação fixa, assim como também carregar as tarefas da base dados local. 6.3.2 Estação fixa O software da estação fixa existe essencialmente para fazer a ponte entre a aplicação cliente, presente na estação móvel, e o sistema de gestão de workflows. Esta aplicação existe para minimizar a complexidade da aplicação presente na estação móvel bem como para criar uma independência da relação entre o sistema de gestão de workflows e a aplicação cliente. Para além disso é responsável por disponibilizar serviços para possibilitar a sincronização dos dispositivos móveis a operar no campo. Nestas, são transferidas novas tarefas para a estação móvel e tarefas completas para a estação fixa, assim como todos os logs associados a estas operações. O WCF service é o módulo que disponibiliza os Web services para as estações móveis. É aqui também que está todo o código que contém as funções de sincronização a serem chamadas pelos Web services. Estas funções que são geradas automaticamente pela ferramenta da Sync Framework. 6.3.3 Comunicação para o exterior A comunicação para o exterior fica a cargo de um adaptador, este tem por objectivo informar-se das tarefas e dos dados associados as mesmas e coloca-las na base dados do middleware. O adaptador é especifico para casa sistema de gestão de workflows, já que estes têm interfaces e modos de funcionamento diferentes. 6.4 Linguagens de Programação Nesta secção serão apresentadas as linguagens de programação usadas no desenvolvimento desta Framework. Na codificação, tanto da estação móvel como da estação fixa, a linguagem predominante é o C#. A persistência de dados fica a responsabilidade do SQL. Para os Web services a tecnologia usada é ASP.NET Web services (ASMX).NET Remoting. 40

6.5 Persistência de dados Nesta secção serão identificadas as tecnologias utilizadas na persistência de dados, tanto nas estações móveis como na estação fixa. Na estação fixa foi utilizado o produto Microsoft SQL 2005 Express,, não só pela sua simplicidade mas pela fácil ligação ao código C# e ao uso da mesma na plataforma Sync Framework.. Para que a persistência fosse garantida foi utilizada a ferramenta LinQ, que será abordada mais detalhadamente no subcapítulo Mapeamento Objecto-Relacional. Relativamente às estações móveis foi utilizado o Microsoft SQL compact,, um requisito necessário, visto a forte ligação existente desta base dados à plataforma Sync Framework. De seguida é apresentado um esquema de base de dados utilizado tanto na estação fixa como na estação móvel para realizar a persistência de dados. Fig. 16 Esquema Base Dados 41

Este esquema de base de dados foi desenvolvido tendo em vista a criação de uma Framework para suportar todos os tipos de tarefas e todo tipo de sistemas de informação, para atingir isso, tudo é simples e permite expansão. Posteriormente será explicada sumariamente cada uma das tabelas. A principal tarefa e à qual tudo está ligado é a TASK, onde são guardadas as tarefas. Esta é expansível pela TASKATTRIBUTES onde são inseridos quaisquer atributos adicionais e campos de dados a preencher ou a recolher na realização de tarefas. As tabelas ATTPARTLINK e ATTPART são tabelas para expandir os TASKATTRIBUTES. Os aspectos de localização e de caminhos estão a cargo das tabelas PLACES e SEGMENT que guardam, respectivamente, localizações e caminhos. A tabela DEVICE guarda informação sobre os dispositivos móveis e os utilizadores são guardados na tabela MOBILEUSER. Finalmente faltam as três tabelas de registo de log s, em que no GEOLOG são cruzadas informações entre tarefas, localizações e dispositivos móveis para registar onde, quando e em que dispositivo são completadas as tarefas. No DEVICELOG são registados os intervalos de tempo em que cada utilizador usa determinado dispositivo móvel. 6.6 Mapeamento Objecto-Relacional O termo mapeamento Objecto-Relacional refere-se à técnica de mapear uma representação de um determinado dado, de um modelo orientado a objectos para um modelo relacional sob um esquema baseado em SQL. A ferramenta usada para fazer o mapeamento Objecto-Relacional escolhida foi o LINQ (21). Esta faz parte de um conjunto de extensões a.net Framework. Com esta é possível estender a linguagem C# e o visual studio, adicionando sintaxe para querys e bibliotecas que tiram vantagens disto. Esta ferramenta permite passar classes para tabelas SQL e vice-versa, entre outros mapeamentos possíveis. (22) A aplicação desta Framework foi usada para criar as classes na estação fixa através do esquema de base dados já definido. O acesso à base de dados é assim facilitado, sendo que é utilizado código C# ao invés de serem escritas as respectivas querys que este vai gerar. No caso da estação móvel, o mapeamento foi feito manualmente, visto não existir ferramenta a utilizar na.net Compact Framework. São utilizadas querys embebidas no código C# para aceder e para guardar informação, não uma solução elegante, mas um mal necessário. 42

6.7 Sincronização Na seguinte secção será detalhado o funcionamento bem como o desenvolvimento do mecanismo de sincronização usado entre a estação fixa e as estações móveis. Toda a sincronização é feita através da Sync Framework, disponibilizada pela Microsoft. Desta forma será detalhado o potencial da ferramenta, seguido do caso de utilização nesta Framework. A ferramenta disponibilizada pela Microsoft apresenta como principais objectivos permitir o acesso a aplicações ou serviços na ausência de conexão de rede, possibilitar a colaboração entre utilizadores em ambientes cliente-servidor, bem como P2P, representados na imagem seguinte à esquerda e direita respectivamente, e finalmente suportar todo o tipo de ligações, tipos de dados e protocolos de transferência. Fig. 17 Arquitecturas da Sync Framework De seguida são apresentados alguns dos conceitos relativos à Sync Framework, nomeadamente o tipo de provedores e participantes possíveis, as componentes da plataforma de sincronização, os métodos de gestão de versões, o fluxo pelo qual se processa a sincronização e como são tratados os conflitos. 6.7.1 Provedores Uma das características chave da Sync Framework é a existência de provedores. Existem alguns predefinidos para suportar algumas das fontes de dados mais comuns, assim como é também possível criar novos tipos personalizados. Os tipos predefinidos existentes separamse essencialmente em três grupos distintos: os provedores de bases de dados, os provedores de ficheiros e finalmente os provedores de serviços de consulta (ex: RSS feeds). 43

No caso da aplicação na qual se centra esta tese, ambos os provedores, a estação fixa e as estações móveis são do tipo Base Dados, tratando-se de um tipo comum é usado um tipo predefinido. Fig. 18 Provedores Framework 6.7.2 Participantes Outro conceito que convém realçar é a classificação do tipo de participantes de uma sincronização e as características que estes reflectem para a sua caracterização. A forma de integração por parte do provedor varia consoante as capacidades do dispositivo onde os dados estão alojados. As características pelas quais é feita a classificação são: a possibilidade de manipular e guardar dados no dispositivo; permissão de inserir e executar aplicações no dispositivo. Existem três tipos de participantes, que serão apresentados, de seguida, individualmente. Primeiro tem-se o participante completo, que como o nome sugere, permite a criação e execução de aplicações no próprio dispositivo, para além da criação e gestão de dados. Como exemplo disto têm-se dispositivos como os computadores portáteis, PDA s ou telemóveis. Fig. 19 Participante completo 44

Em segundo lugar o participante parcial. Este está presente em dispositivos que não correm aplicações como por exemplo: pen drives, discos externos, câmaras fotográficas, entre outros. Comporta-se como um disco rígido, manejando os dados efectuando apenas as operações CRUD, ficando dependentes de um participante completo para executar a sincronização. Fig. 20 Participante Parcial Por fim têm-se os participantes simples, que apenas permitem a busca e download de informação quando solicitada. Não permitem a criação e manipulação de dados ou a criação de aplicações a correr nos dispositivos, onde estão contidos os dados. Exemplos disto são RSS feeds assim como alguns Web services. Estes permitem a sua execução e colecta de informação, mas não permitem a criação e instalação de aplicações nossas nos servidores Web. Fig. 21 Participante Simples Ambos os participantes presentes na Framework da estação fixa e da estação móvel são participantes completos, correm aplicações e têm presente uma base dados SQL. 45

6.7.3 Componentes da plataforma Para que a sincronização se dê entre provedores estes têm de ter alguns componentes importantes, nomeadamente os representados na figura seguinte. Fig. 22 Componentes da Sync Framework De seguida passo a explicar cada um dos componentes, indicando o seu papel na sincronização. A Data Source ou Fonte de dados é o elemento fundamental pois representa os dados a serem sincronizados. Pode representar-se por uma base dados, de ficheiros ou por um web service. Outra componente é a Metadata. Nesta está toda a informação pela qual se rege o controlo de versões, que será explicado mais detalhadamente no subcapítulo posterior. Por norma esta informação é guardada num ficheiro no caso de sincronização de ficheiros ou injectada nas tabelas, no caso da sincronização de base de dados, existindo ainda outras possibilidades. Esta informação pode ser decomposta em vários campos: as versões, o conhecimento, o Tick Count, Replica ID e por fim, os TombStones. Nas versões são guardadas as datas de criação da última actualização. O conhecimento representa as alterações nas quais a réplica em questão está ocorrente, e que permite enumerar alterações e detectar conflitos. O Tick Count é o contador de alterações de todos os elementos sincronizados. A Replica ID é um número único que identifica uma data store. Por fim, os Tombstones são a informação que as réplicas guardam sobre os elementos eliminados, o ID, a versão de criação e a versão eliminada. Isto é importante no momento da sincronização, pois na ausência do elemento a fonte não consegue propagar uma alteração. 46

Na aplicação prática da presente tese, é observável a presença de novas colunas nas tabelas: coluna CreationDate e LastEditDate, que indicam a data da criação e da última actualização respectivamente, como se pode verificar na figura seguinte, assinalado com um círculo vermelho. Fig. 23 Colunas Informação de versões Quanto à informação dos Tombstones são criadas novas tabelas pelo wizard com como é visível na figura seguinte assinalado com setas vermelhas. Fig. 24 Tabelas de Tombstones 47

Estas tabelas de Tombstones são muito simples e apenas guardam o ID da linha apagada e a data em que esta foi removida. Pode ver-se a estrutura das tabelas na imagem seguinte, onde está representada a tabela TASK_Tombstone. Fig. 25 Esquema da tabela TASK_Tombstone A outra informação da metadata, o Tick Count e a Replica ID, é guardada em código injectado pela ferramenta nas aplicações das estações. Toda esta informação foi obtida através da inspecção da base de dados, através da ferramenta SQL Management Studio, e do código gerado através do Visual Studio 2008. 6.7.4 Gestão versões Existem dois métodos para o controlo de versões. A necessidade das duas possibilidades passa pela natureza dos dispositivos onde se encontram os dados a sincronizar. As versões estão associadas aos elementos que são ficheiros ou linhas de uma tabela para sincronização de ficheiros ou base de dados respectivamente O primeiro método denominado Inline Tracking, pressupõe que as versões são actualizadas no momento em que são alterados os elementos e para isso é injectado um código que actualiza automaticamente a metadata, mais propriamente o conhecimento da réplica. Um exemplo disso é a aplicação em bases de dados, onde são inseridos triggers nas tabelas, que actualizam a metadata automaticamente no momento da alteração. O outro método, Asynchrronous Tracking implica que hajam processos externos de procura de alterações. Estes podem ser executados no momento da sincronização fazendo parte desta ou serem processos à parte executados previamente. Este método é usado normalmente em participantes parciais ou simples onde não é possível correr aplicações próprias. Na aplicação da Sync Framework à presente tese, o método de gestão de versões utilizado foi o Inline Tracking. Este processo decorre a partir da injecção de trigger associados às tabelas 48

da base dados a serem sincronizadas. A figura seguinte mostra a presença dos triggers nas tabelas através de uma inspecção às mesmas com a ferramenta SQL Management Studio. Fig. 26 Triggers para Gestão Versões Estes triggers são inseridos automaticamente através do wizard de criação de DataBase Cache no Visual Studio 2008. 6.7.5 Fluxo sincronização De seguida são identificados os passos gerais que seguem um fluxo de sincronização. Em cada sincronização existe uma fonte, réplica que inicia a sincronização, e o destino, a réplica a quem se conecta. A figura seguinte apresenta um diagrama com todos os passos necessários à sincronização com indicação da respectiva fonte e destino. 49