ESTÁGIO CURRICULAR I e II PROJETO E DESENVOLVIMENTO DE MELHORIAS NO SISTEMA DE FLUXOS DE TRABALHO

Transcrição

1 GUILHERME OENNING ESTÁGIO CURRICULAR I e II PROJETO E DESENVOLVIMENTO DE MELHORIAS NO SISTEMA DE FLUXOS DE TRABALHO EMPRESA: NEOGRID SOFTWARE SETOR: SISTEMAS INTERNOS SUPERVISOR: ERMES RÜCK ORIENTADOR: RUI JORGE TRAMONTIN JUNIOR CURSO DE TECNOOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC JOINVILLE SANTA CATARINA - BRASIL JUNHO DE 2011

2

3

4

5

6

7 CRONOGRAMA FÍSICO E REAL PERÍODO (20 horas) ATIVIDADES P R Estudar a plataforma do SharePoint através de documentos e P aplicando customizações um ambiente de testes R Realizar correções e melhorias nos fluxos de trabalho já existentes P R Construir o fluxo de férias solicitado pela área de recursos humanos P R Construir um novo modelo de arquitetura para os fluxos de trabalho P R Migrar os antigos fluxos de trabalho para a nova plataforma P R Testes, homologações e ajustes P R Legenda: P Previsto; R- Realizado

8 Aos meus pais e amigos por todo apoio, confiança e incentivo.

9 AGRADECIMENTOS Muitas pessoas e empresas tornaram-se merecedoras de meu reconhecimento, pelo muito que colaboraram para a realização deste trabalho, dentre elas destacam-se: A NeoGrid pela oportunidade; Os meus colegas de faculdade e trabalho pelos bons momentos; O professor Rui Jorge Tramontin Junior pela orientação;

10 SUMÁRIO LISTA DE FIGURAS... XI LISTA DE TABELAS... XII RESUMO... XIII INTRODUÇÃO OBJETIVOS Geral Específicos Justificativa ORGANIZAÇÃO DO ESTUDO A EMPRESA HISTÓRICO PRINCIPAIS PRODUTOS WebEDI NF-e CT-E PRINCIPAIS CLIENTES TECNOLOGIAS E CONCEITOS FLUXO DE TRABALHO C# E FRAMEWORK.NET SHAREPOINT WINDOWS WORKFLOW FOUNDATION ATIVIDADES DESENVOLVIDAS ESTUDO DA PLATAFORMA SHAREPOINT CORREÇÕES NOS FLUXOS DE TRABALHOS JÁ EXISTENTES CONSTRUÇÃO DO FLUXO DE TRABALHO DE SOLICITAÇÃO DE FÉRIAS Funcionamento Desenvolvimento Publicação e Divulgação NOVO MODELO DE ARQUITETURA PARA OS FLUXOS DE TRABALHO Mudança no modelo lógico A resolução de problemas ATIVIDADES PENDENTES TABELA DE SUBSTITUIÇÃO MIGRAR OS FLUXOS DE TRABALHO PARA A NOVA PLATAFORMA TESTES, HOMOLOGAÇÕES E AJUSTES CONSIDERAÇÕES FINAIS GLOSSÁRIO REFERÊNCIAS BIBLIOGRÁFICAS... XXXIII

11 LISTA DE FIGURAS Figura 1 Portfólio de ofertas da NeoGrid... 4 Figura 2 Papel da NeoGrid no processo de NF-e... 5 Figura 3 Papel da NeoGrid no processo de CT-e... 6 Figura 4 Diagrama das relações entre os diferentes recursos acionados durante a compilação e execução de um programa em C#... 9 Figura 5 Página inicial da Intranet utilizando SharePoint Figura 6 Exemplo de um fluxo de trabalho utilizando máquina de estados Figura 7 Processo de solicitação de férias desenhada no Microsoft Office Visio Figura 8 Formulário de solicitação de férias Figura 9 Modelo lógico da dependência dos fluxos de trabalho com o SharePoint Figura 10 Modelo lógico proposto para a solução dos problemas Figura 11 Modelo lógico aprovado Figura 12 contendo detalhes da solicitação de férias Figura 13 Conteúdo do de tarefas atrasadas... 28

12 LISTA DE TABELAS Tabela 1 Estrutura da tabela de substituição... 29

13 RESUMO O presente trabalho descreve as atividades desenvolvidas durante o estágio obrigatório do curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade do Estado de Santa Catarina. Estas atividades foram desempenhadas na empresa NeoGrid Software no setor de sistemas internos. O projeto detalhado neste trabalho é o de construção e manutenção de uma nova arquitetura para a solução de fluxos de trabalho utilizada internamente pela empresa. Para a execução do projeto foi necessário exercer atividades de levantamento de requisitos, análise do problema, modelagem da nova solução, desenvolvimento, testes e homologação.

14 1 INTRODUÇÃO A NeoGrid possui uma solução própria para formalizar alguns dos processos da empresa, como por exemplo, o processo de compras de equipamentos, material de expediente etc. Este sistema é executado sobre a plataforma de colaboração da Microsoft conhecida como Microsoft SharePoint. Este documento tem como finalidade detalhar as atividades exercidas pelo acadêmico Guilherme Oenning na manutenção e melhoria deste sistema OBJETIVOS Geral Atuar na análise, desenvolvimento, testes e melhoria contínua dos fluxos de trabalho de acordo com as necessidades dos usuários e da empresa Específicos Conhecer melhor como funciona o desenvolvimento de soluções customizadas no SharePoint e as melhoras práticas sugeridas pelo fornecedor Aprender como foram construídos os fluxos de trabalho já desenvolvidos para adicionar novas funcionalidades solicitadas Facilitar e padronizar o desenvolvimento de novos fluxos Remover a complexidade e duplicidade de código que os fluxos de trabalho atuais possuem e inseri-los dentro do novo padrão

15 Justificativa Apesar da solução atual atender as necessidades da empresa, foram levantados pelos próprios usuários e o time de sistemas internos algumas melhorias que poderiam ser realizadas no sistema para facilitar tanto o uso quanto a manutenção e criação de novos fluxos de trabalho. Estas alterações foram classificadas como importantes, pois é esperado um aumento significativo no uso deste sistema por parte dos usuários dos Estados Unidos e Europa ORGANIZAÇÃO DO ESTUDO Este relatório está dividido da seguinte maneira. O primeiro capítulo apresenta o objetivo do relatório bem como uma introdução ao assunto será abordado. O segundo capítulo apresenta algumas informações sobre a NeoGrid, um breve histórico da empresa, sua área de atuação e seus principais clientes. Já o terceiro capítulo destina-se à apresentação das tecnologias exploradas durante o projeto, bem como o problema a ser resolvido, a solução proposta e o desenvolvimento do mesmo. O quarto capítulo descreve as atividades que foram desenvolvidas durante o período de estágio e também as que ficaram pendentes. Por fim encerra-se o relatório de estágio com uma breve conclusão.

16 3 2. A EMPRESA 2.1. HISTÓRICO O portfólio de ofertas NeoGrid é composto por soluções inovadoras para a cadeia de suprimentos e demanda. Essas ofertas buscam gerar resultados expressivos aos clientes: agilizam o processo de compras, melhoram o processo de vendas, automatizam a reposição e aumentam o giro dos estoques. Assim conseguem alavancar sua competitividade. Isso fez com que a empresa conquistasse 9 dos 10 maiores clientes de varejo nacionais e 7 dos 10 maiores varejos mundiais. Após 3 grandes aquisições, a NeoGrid tornou-se uma das maiores empresas no segmento de soluções de negócios para a cadeia de suprimentos e demanda. Em 2008 a NeoGrid foi declarada líder de mercado em gestão da cadeia de suprimentos no Brasil, crescendo mais de 40% ao ano, suas soluções integram mais de empresas de todo o mundo (NEOGRID 1) PRINCIPAIS PRODUTOS A NeoGrid possui quatro macro-ofertas que são compostas por uma ampla quantidade de produtos. Dentre todas as solução disponíveis no Brasil, destacam-se o EDI (Eletronic Data Interchange), a NF-e (Nota Fiscal Eletrônica) e o CT-e (Conhecimento de Transporte Eletrônico), ambos integrantes da macro-oferta ICC (Integration, Communication and Collaboration) (NEOGRID 2). A figura 1 apresenta todas as ofertas e o público alvo da companhia. Nesta imagem também é possível notar que o serviço de consultoria estratégica é oferecido para todos os tópicos relacionados à logística, manufatura, vendas etc.

17 4 Figura 1 Portfólio de ofertas da NeoGrid (NEOGRID 2) WebEDI EDI é o acrônimo de Electronic Data Interchange (do português, troca eletrônica de dados). O WebEDI ou também conhecido como NeoGrid EDI, é uma plataforma de B2B utilizado para integrar os processos de negócios de uma empresa com seus parceiros através da troca de documentos pela internet. O produto é destinado para o varejo, indústrias, instituições financeiras, transportadoras entre outros. Através de uma interface na internet o cliente pode consultar quais os documentos que são enviados e/ou recebidos de seus clientes e fornecedores. Alguns exemplos de arquivos que são trocados pelo WebEDI são: pedidos de compra e venda, aviso de embarque, solicitação de cotação, entre outros.

18 NF-e A NF-e é um documento emitido e armazenado de forma digital que substitui a nota fiscal impressa. Este produto ajuda as empresas a estarem de acordo com o projeto nacional criado pelo Governo Federal através de uma plataforma segura e madura. A solução NeoGrid é líder de mercado e já atende diversos segmentos tais como refinarias e distribuidores de petróleo, fabricantes de cigarros, fabricantes de alimentos e bebidas, telecomunicações, grandes varejistas, operadores logísticos, montadoras de veículos e seus parceiros, entre outros (NEOGRID 3). A figura 2 apresenta a função da NeoGrid dentro do processo de emissão e acompanhamento da nota fiscal eletrônica. Figura 2 Papel da NeoGrid no processo de NF-e (NEOGRID 3) CT-E O Conhecimento de Transporte Eletrônico é um documento emitido e armazenado eletronicamente, que existe apenas no ambiente digital para documentar o serviço de transporte de cargas pelo país. Com expertise garantida em Conhecimento de Transporte Eletrônico, a NeoGrid trabalha com os diversos sistemas de gestão de transporte (TMS), garantindo agilidade na implantação destes projetos. Nosso processo gera inúmeros benefícios para as empresas que desejam atender à legislação de emissão e recebimento de Conhecimentos de Transporte com performance testada por empresas de porte mundial (NEOGRID 4).

19 6 A figura 3 apresenta a função da NeoGrid dentro do processo de emissão e acompanhamento do conhecimento de transporte eletrônico. Figura 3 Papel da NeoGrid no processo de CT-e (NEOGRID 4) 2.3. PRINCIPAIS CLIENTES Dentre os diversos clientes da NeoGrid, destacam-se (NEOGRID 5): Panarello; Melitta; Lepper; Havaianas; Rede de supermercados do Angeloni; Whirlpool; Pepsico, fabricante das marcas Pepsi, Gatorade, Quaker, Elma Chips, H2OH!, Toddy e Toddynho.

20 7 3. TECNOLOGIAS E CONCEITOS Este capítulo apresenta algumas das tecnologias que foram estudados durante as atividades do estágio FLUXO DE TRABALHO Um fluxo de trabalho é a automação do processo de negócio, na sua totalidade ou em partes, onde documentos, informações ou tarefas são passadas de um participante para o outro para execução de uma ação, de acordo com um conjunto de regras de procedimentos (WFMC 1). No modo tradicional, uma tarefa é passada de um funcionário para outro. A grande vantagem deste tipo de automação é que a atribuição de tarefas é feita de forma automática, além disso, é possível garantir que se uma tarefa chegou para um dos participantes do fluxo, é porque a tarefa está pronta para ser iniciada já que subentendese que o sistema não repassaria uma atividade incompleta. Cada atividade de um fluxo de trabalho pode ser classificada como uma atividade que necessita de interação manual ou então é realizada automaticamente pelo sistema através de recursos de programação, como por exemplo, cálculos e envio de s C# E FRAMEWORK.NET O C# é uma linguagem orientada a objetos, fortemente tipada, o que permite aos desenvolvedores criarem uma variedade de aplicativos seguros e robustos que são executados no.net Framework (MICROSOFT 2).

21 8 A sintaxe do C# é baseada no C++, porém muito mais simplificada e igualmente eficiente. A linguagem possui recursos de delegate 1, lambda 2 e tipos genéricos, o que possibilita a criação de componentes inteligentes, seguros e fáceis de utilizar. Programas escritos em C# são executados no.net Framework, um componente do Windows que inclui um sistema de execução virtual chamado Common Language Runtime (CLR) e um conjunto unificado de bibliotecas de classes. O CLR é a implementação comercial da Microsoft da infraestrutura de linguagem comum (CLI), um padrão internacional que é a base para a criação e execução de ambientes de desenvolvimento em que as linguagens e as bibliotecas trabalham juntos sem problemas (MICROSOFT 2). Diferente de programas escritos em C/C++, o C# possui uma linguagem intermediária parecida com o bytecode do Java. Esta linguagem intermediária é carregada pela CLR que é responsável por interpretar e convertê-la em um código que o sistema operacional consiga entender. É através deste processo de compilação e execução que permite que um código em C# possa ser executada tanto no Windows 7 quanto no Windows Mobile. O que muda de uma plataforma para outra é a CLR. No caso do Windows Mobile, por exemplo, a biblioteca de métodos matemáticos é mais compacta. Além disso, o gerenciador de memória não permite que o programa abuse do processador e da memória RAM já que isso pode afetar diretamente o consumo de bateria. A figura 4 detalha o processo de compilação de um código escrito em C# até que ele se transforme em um código que o sistema operacional consiga entender e processar. 1 Delegate é equivalente à um ponteiro para uma função na linguagem C/C++. Este recurso permite que o programador encapsule métodos dentro de variáveis para tornar a programação mais dinâmica já as chamadas dos métodos serão resolvidas em tempo de execução (MICROSOFT 3). 2 Uma expressão lambda é uma função anônima que possui expressões e comandos e que pode ser utilizada para a criação de delegates de forma mais limpa e objetiva.

22 9 Figura 4 Diagrama das relações entre os diferentes recursos acionados durante a compilação e execução de um programa em C# (MICROSOFT 2) 3.3. SHAREPOINT Segundo Pyles (2007), o objetivo da Microsoft com o SharePoint é permitir que mesmo as organizações espalhadas em diversos países possam ter um local centralizado para divulgação de conteúdo, ideias e documentos. A ferramenta destina-se principalmente às empresas ou comunidades que buscam ter uma única aplicação na intranet ou extranet para a divulgação de informação. Dentre suas diversas funcionalidades, destacam-se recursos de fórum, blog, wiki, site pessoal e distribuição de documentos. O SharePoint pode ser utilizado, por exemplo, por cada equipe ou departamento para ter seu próprio site e divulgar as informações que acharem relevantes. Através de uma interface bastante poderosa, amigável e fácil de utilizar, não é necessário ter nenhum especialista na solução para criar e modificar os sites.

23 10 Uma das características que mais chama a atenção é o fato de que a plataforma possui uma excelente integração com os aplicativos do pacote Microsoft Office. Quando um documento é publicado no SharePoint, qualquer pessoa pode abri-lo através da internet, editar e salvar, sem ter que se preocupar em fazer download e upload explicitamente. O mecanismo de segurança também é bastante utilizado já que certas informações não podem ser acessíveis a todos os funcionários. Este é o caso de informações de faturamento da empresa que podem ser publicados no SharePoint, porém, apenas podem ser vistos por alguns cargos. O SharePoint também suporta a criação de fluxos de trabalho de forma bastante simples e fácil de usar. Um exemplo bastante comum na empresa é a utilização de fluxos de trabalho para aprovação de documentos, por exemplo, para os documentos de políticas de segurança e código de conduta que necessitam aprovação de um diretor caso seja alterado. A figura 5 apresenta a página inicial da intranet utilizado pela empresa. No conteúdo da página há um mural de avisos, uma lista de aniversariantes e a Missão, Visão, Valores e algumas Políticas. Todos estes textos e configurações são feitos pelos próprios usuários. Figura 5 Página inicial da Intranet utilizando SharePoint

24 WINDOWS WORKFLOW FOUNDATION O windows workflow foundation, mais conhecido como WWF, é um framework escrito em C# para a criação de fluxos de trabalho na plataforma.net. Conta com o auxílio de uma interface rica permitindo que o desenvolvedor possa desenhar o fluxo através de componentes gráficos e escrever código customizado em C#. Segundo Bukovics (2007), as aplicações baseados em fluxos de trabalho permitem que o desenvolvedor utilize um modelo de programação declarativo ao invés de um procedural. Sendo totalmente integrado ao Microsoft Visual Studio, o framework fornece uma experiência de desenvolvimento altamente visual. Disponível a partir do.net Framework 3.0, o WWF conta com duas opções de fluxos de trabalho. O primeiro, chamado de fluxo de trabalho sequencial, é um modelo que executa atividades de forma ordenada, onde o término de uma atividade desencadeia a execução da próxima. A outra opção é com a utilização de máquina de estados. Neste modelo o fluxo começa em um estado inicial e, dado um evento externo definido pelo desenvolvedor, o fluxo avança para algum outro estado. Um bom exemplo de um estado é Aguardando Aprovação do Gerente. Quando o gerente tomar alguma ação, o fluxo move para um estado chamado Aprovado ou Rejeitado. Cada um destes estados possui uma programação customizada, isso permite uma clara e agradável separação de código. Este framework é bastante utilizado para realizar customizações em produtos da Microsoft, como por exemplo, o Microsoft SharePoint e o Microsoft Dynamics AX e CRM. Ambas as ferramentas possuem suporte para fluxos de trabalho mais básicos. Quando é necessário algum tipo de programação mais avançada, é necessário utilizar uma ferramenta mais flexível como o WWF. Na figura 6 pode ser visto o diagrama de estados do fluxo de contratação. Os estados presentes são: InitialState; ApprovalState; AnalysisState; ManagerReviewState; NotificationState.

25 12 Em cada um destes estados existe uma lógica de programação que é executada para atender aos requisitos solicitados pela área de processos. Figura 6 Exemplo de um fluxo de trabalho utilizando máquina de estados 4. ATIVIDADES DESENVOLVIDAS 4.1. ESTUDO DA PLATAFORMA SHAREPOINT Como primeira atividade do estágio, foi proposto um estudo sobre o SharePoint para entender melhor como funcionam os recursos de criação de sites, páginas, listas, bibliotecas, dentre outros. Foi disponibilizado um servidor de testes onde era possível realizar qualquer alteração sem que isso impactasse o ambiente de produção. Neste servidor foram realizados os primeiros passos para customizar e utilizar as funcionalidades padrões da solução. Percebeu-se que a criação de listas é bastante comum dentro da organização e por isso, foi dado um foco maior no funcionamento deste recurso.

26 13 Estas listas são como tabelas em um banco de dados, porém com o foco em um usuário final que não possui conhecimento técnico. As listas permitem criações de colunas de vários tipos de dados, possibilitando o usuário de utilizá-la em diversas solucões. Um exemplo de lista bastante útil é a de classificados. Localizada no site de recursos humanos e acessível por qualquer usuário, é possível divulgar produtos a venda, compra ou troca. O SharePoint permite que as páginas sejam construidas e configuradas utilizando WebParts. As WebParts são componentes gráficos com um objetivo bastante claro e bem definido além de serem voltadas para os usuários finais da aplicação. Os exemplos mais comuns são as WebParts de conteúdo rico, de imagem, de links, de feed RSS 3 e Excel. Através destes componentes, o SharePoint permite que usuários sem conhecimento técnico possam construir páginas, inserir imagens e editar conteúdo de forma totalmente gráfico através do navegador de internet. Para atividades mais complexas que envolvem, por exemplo, manipulação de banco de dados, envio de ou integração com outras ferramentas, é necessário ter mais flexibilidade e que não é possível através das páginas criadas com WebParts. Por isso o SharePoint permite que qualquer desenvolvedor possa utilizar o Visual Studio para criar páginas em ASP.NET 4 e C# e publicá-las dentro da intranet herdando o layout da página pai CORREÇÕES NOS FLUXOS DE TRABALHOS JÁ EXISTENTES A primeira solicitação de correção foi a pendência com identificador AITS-888 no Jira 5. O usuário reclamou da lentidão que o sistema estava apresentando nas últimas semanas. Segundo as informações incluídas pelo usuário, as atividades que antes levavam 1 ou 2 segundos estavam demorando cerca de 10 a 30 segundos. 3 Feed RSS é uma forma de disponibilizar conteúdos de um site em um formato pré-definido e padronizado para que outros programas possam ter acesso ao conteúdo. Este recurso é bastante visto em blogs e sites de noticia. 4 ASP.NET é a plataforma de desenvolvimento para a internet criada pela Microsoft para suceder o ASP. 5 Jira é um software de controle de pendências desenvolvido pela Atlassian. Ele permite a divisão por área e projeto o que facilita a localização e divisão das tarefas.

27 14 O primeiro passo realizado foi conversar com o usuário para descobrir em qual tela do sistema e quais ações ele efetuava para que pudesse ser possível simular no ambiente de testes. O segundo passo foi instalar o Microsoft Visual Studio e conectar-se ao Subversion 6 para buscar a última versão do código armazenado no repositório da empresa. Após algumas simulações e testes, foi descoberto que a instrução de código que chamava o método GetItemById da classe SPListItemCollection era responsável por toda a demora no processamento. Segundo a documentação da Microsoft, o que este método faz é montar um comando SQL que retorna todos os registros de uma determinada lista e, depois de ter todos os objetos em memória, é realizada uma busca binária para encontrar o registro que possui o identificador solicitado. O texto de abertura da pendência deixava claro que este problema começou a ficar mais grave com o passar do tempo. A explicação obtida pelos documentos da Microsoft comprova que, quanto mais registros houver no banco de dados, mais tempo a operação leva para ser completado, afinal, o comando SQL está buscando todos os dados sem restrição. Depois de uma busca no livro SharePoint 2007: The Definitive Guide, foi encontrado um método da classe SPList chamado de GetItemById que realizava exatamente a operação que estávamos procurando. Apesar do nome do método ser igual ao outro, nesta classe o método executava um comando SQL que retorna no máximo um registro, pois utiliza a chave primária da tabela. Foram criados dois scripts para testar a diferença de desempenho dos dois métodos. Ambos os scripts foram executados na lista de tarefas que continha cerca de itens. Utilizando o método antigo para buscar um item que estava no fim da lista, o algoritmo levou 40 segundos e fez a memória RAM do servidor subir em 10%. Já o método recentemente descoberto levou 0.51 segundos para buscar o mesmo registro. Não houve alteração no uso de memória. Depois de realizado este teste ficou constatado que este novo método resolveria o problema de desempenho apontado no chamado. 6 Subversion é um sistema de controle de versão de código fonte.

28 15 Neste momento foi necessário descobrir como publicar uma alteração em um fluxo de trabalho. Foi seguido um tutorial escrito pelo time que explicava que era necessário incrementar o número da versão do fluxo, desativar o antigo, instalar a nova versão e então ativar novamente. Ao término do fechamento da pendência, esta informação foi repassada aos outros integrantes do time para que todos ficassem cientes de qual era a forma errada e a certa de se utilizar o método GetItemById. Outra pendência que se faz importante comentar é a com identificador AITS-895. O usuário relatou que uma das solicitações de compra criou uma tarefa para um usuário errado. Ao invés de enviar para o usuário que estava cadastrado como aprovador, a tarefa foi repassada para o antigo usuário que era responsável por esta aprovação. O que acontecia é que, quando o fluxo iniciava e o código relacionado ao evento OnInitialize era invocado, o sistema resgatava todos os aprovadores que fariam parte da aprovação (normalmente quatro pessoas) e guardava-os em memória. Isso era feito para economizar processamento nas outras etapas do fluxo. O problema é que, o aprovador foi alterado após a inicialização do fluxo e, portanto, o usuário antigo estava em memória e não o novo aprovador. A solução para este problema foi uma completa remodelagem do código. O método OnInitialize passou a ser muito mais enxuto e as informações de quem iriam aprovar cada tarefa passaram a ser obtidas somente quando necessário. Quando um usuário aprova a solicitação de compra, o fluxo busca qual o próximo aprovador e cria uma tarefa para este caso necessário. Desta forma conseguiu-se evitar o problema descrito na abertura da pendência CONSTRUÇÃO DO FLUXO DE TRABALHO DE SOLICITAÇÃO DE FÉRIAS A área de recursos humanos solicitou a criação de um fluxo automatizado para controlar as requisições de férias, pois o processo atual estava muito falho e demorado. O principal motivo desta solicitação foi o excesso de troca de entre o funcionário, o gerente e o pessoal de recursos humanos. Estes s não eram padronizados e não havia um processo formalizado de como dar entrada em uma

29 16 solicitação de férias. Além disso, procurar os s de aprovação era uma tarefa bastante demorada e em muitos casos, impossível. O fluxo de trabalho foi desenhado pela equipe de processos e pode ser visto na figura 7. De forma bastante simples, o objetivo desta automação é acabar com o excesso de troca de , deixar o processo registrado de forma clara e que possua um mecanismo de pesquisa fácil de utilizar. Figura 7 Processo de solicitação de férias desenhada no Microsoft Office Visio Funcionamento O fluxo inicia quando o funcionário entra na página de nova solicitação de férias e preenche o formulário conforme a figura 8. Faz-se necessário que o próprio funcionário informe qual o seu gerente, pois para muitos funcionários, esta informação ainda está desatualizada no Active Directory 7. 7 O Active Directory é um serviço de diretório e um conjunto de Atributos sobre recursos e serviços existentes na rede, isso significa que é uma maneira de organizar e simplificar o acesso aos recursos de sua rede centralizando-os; Bem como, reforçar a segurança e dar proteção aos objetos da database contra intrusos, ou controlar acessos dos usuários internos da rede. (MICROSOFT 1).

30 17 Através da data de início e a quantidade de dias, a data de término é automaticamente calculada. Figura 8 Formulário de solicitação de férias A opção de antecipação do 13 fica disponível apenas para os funcionários dos escritórios do Brasil já que nos Estados Unidos, Europa e Japão não existe esta política. A primeira pessoa a aprovar a solicitação é o gerente informado no formulário. Esta tarefa de aprovação possui três possíveis ações: aprovar, reprovar ou enviar para revisão. Caso o gerente escolha reprovar a solicitação, o funcionário é informado por e- mail e o fluxo finaliza imediatamente. A opção de enviar para revisão é utilizada quando o gerente não concorda com as datas, neste caso o fluxo cria uma tarefa de revisão e a atividade volta para o requisitante. O solicitante então pode corrigir e encaminhar novamente para aprovação ou então cancelar a solicitação. Caso a solicitação seja aprovada pelo gerente, a pessoa responsável pela área de recursos humanos do escritório do solicitante recebe uma tarefa também de aprovação, tendo as mesmas opções de ação que o gerente possuia. A diferença é que nesta etapa é visto dentro do sistema de recursos humanos se o solicitante possui direito a férias e se o período de gozo confere com o saldo de dias do funcionário. Caso aprovado, o fluxo é finalizado e um de aviso é enviado para o solicitante e seu gerente. Além disso, um automático é enviado para o fornecedor de serviços de RH da NeoGrid, este contém todas as informações necessárias para que esta empresa tome as devidas providências para que o funcionário possa sair de férias, incluindo o pagamento do 13 salário caso ele tenha optado pela antecipação.

31 Desenvolvimento Foi utilizado o fluxo de contratação de funcionários como base para o desenvolvimento desta nova solicitação, pois existe uma grande semelhança entre ambos. A primeira tarefa realizada foi a construção do diagrama máquina de estados utilizando o Windows Workflow Foundation. Baseado nos diagramas já existentes pode-se perceber que há um padrão para a criação de tarefas. Os seguintes passos são seguidos: 1) Primeiro é utilizado um componente do SharePoint que é responsável por criar efetivamente a tarefa; 2) Em seguida é utilizado outro componente também do SharePoint para gravar uma entrada no arquivo de log; 3) Por fim, um é enviado para o usuário dono da tarefa. Estes passos sempre são realizados durante a criação de uma tarefa e por isso teve que ser repetido três vezes durante a criação do novo fluxo de trabalho. Na interface foram utilizados os elementos básicos do HTML e um pouco de JavaScript para fazer o cálculo da data de término das férias de forma automática e instantânea. Também foi utilizado os componentes de validação do ASP.NET para que o usuário não possa informar mais que 30 dias de férias ou então colocar mais de 10 dias à venda. O visual do formulário seguiu o padrão já existente enquanto que a listagem, histórico e busca de solicitações ficou sob responsabilidade dos recursos padrões do SharePoint Publicação e Divulgação Depois de concluído o desenvolvimento, alguns testes foram realizados em um ambiente isolado juntamente com os principais envolvidos e a área de recursos humanos. Com a aprovação dos interessados, o trabalho foi dado como concluído e então liberado no ambiente de produção. A área de recursos humanos ficou responsável por montar um manual de utilização do fluxo e também enviar um comunicado para toda a empresa, tanto no Brasil quanto no exterior.

32 19 Houve uma grande utilização já na primeira semana, pois os funcionários que já tinham suas férias agendadas previamente foram instruídos a utilizar a ferramenta. Foram mais de 50 solicitações, algumas dúvidas surgiram, porém nenhum problema foi encontrado NOVO MODELO DE ARQUITETURA PARA OS FLUXOS DE TRABALHO Foi sinalizado pela área de governança corporativa da empresa que existe uma fila de novos processos que precisam ser automatizado além de outros que devem aparecer durante o ano de O trabalho de construção de um novo fluxo de trabalho automatizado é bastante repetitivo, demorado e muito propício ao erro. Além disso, os usuários do sistema já haviam repassados diversas críticas e sugestões quanto à solução atual. Por esses motivos a equipe resolveu investir algum tempo para melhorar a forma com que estes fluxos são desenvolvidos e aproveitar a oportunidade para adicionar várias pequenas melhorias e funcionalidades que foram sugeridas Mudança no modelo lógico O modelo atual Conforme citado anteriormente, o SharePoint é amplamente utilizado como plataforma para desenvolvimento e utilização dos fluxos de trabalho. Através de uma API (Application Programming Interface) disponibilizada pelo SharePoint é possível fazer consultas, gravar registros no log, ativar um processamento em segundo plano entre outras funções. A figura 9 apresenta um modelo lógico de como estão estruturados as dependências dos fluxos de trabalho.

33 20 Figura 9 Modelo lógico da dependência dos fluxos de trabalho com o SharePoint Analisando esta imagem é possível identificar claramente que existe uma dependência muito forte da API do SharePoint já que o acesso aos recursos desta é feita diretamente, sem passar por qualquer outra camada intermediária. Segundo Martin (2006), as camadas de mais alto nível não devem depender das camadas de menor nível, elas devem depender de abstrações. A reutilização de classes ser torna complicada quando há qualquer tipo de alto acoplamento. Neste caso, o fato de que os fluxos estejam altamente acoplados à API do SharePoint faz com que qualquer alteração na API ou até mesma em algum detalhe de interface resulte em uma alteração em toda a camada superior para atender as novas mudanças. Outro ponto bastante preocupante é a utilização dos recursos padrões banco de dados, arquivos de log, motor do fluxo de trabalho, diretório de usuário, tarefas assíncronas e a interface do SharePoint. Existe uma grande dificuldade em se administrar e estender estes recursos, pois depende das funcionalidades de customização do SharePoint, que infelizmente, não são satisfatórios em alguns casos.

34 21 O recurso de log, por exemplo, permite algumas configurações como alterar o padrão no nome do arquivo ou o local de armazenamento, mas não há como editar o formato do conteúdo. O motor de fluxo de trabalho também possui suas deficiências. Por estarem diretamente ligados ao IIS 8, quando é necessário realizar alguma manutenção onde este serviço precisa ser reiniciado, os fluxos de trabalho param de executar e só voltam ao normal quando o IIS é iniciado novamente O modelo proposto Foi proposta uma solução onde se esperava resolver todos os problemas citados no item anterior. A figura 10 apresenta o modelo lógico da solução proposta. Figura 10 Modelo lógico proposto para a solução dos problemas Seria criado um framework entre os fluxos de trabalho e o SharePoint para fazer a ponte entre os dois universos. Este framework seria responsável por prover os 8 IIS (Internet Information Services) é um serviço do Windows utilizado para a publicação de conteúdo estático ou dinâmico na internet. Permite também a realização de streaming, balanceamento de carga além de ser basta flexível e extensível.

35 22 componentes gráficos e recursos técnicos como acesso ao banco de dados e gravação em arquivos de log, por exemplo. A dependência ao SharePoint seria reduzida drasticamente, sendo que apenas os recursos de tarefas assíncronas e de interface gráfica continuariam a ser utilizadas. Não faria sentido em não utilizar o agendador de tarefas já que este é um recurso bastante poderoso, útil e extensível. Já no caso das interfaces, como os usuários já estão acostumados a entrar no SharePoint diariamente. Mover as telas de fluxo de trabalho para uma aplicação separada traria confusão e complicações desnecessárias. Este framework iria possui componentes para acesso à base de dados totalmente administrada pela equipe e sem qualquer ligação com as bases de dados do SharePoint. Isso facilitaria a administração de índices, migração de dados, atualização e a possibilidade de utilizar qualquer software gerenciador de banco de dados. O motor de fluxo de trabalho seria desvinculado do IIS e publicado em uma máquina específica já que é um serviço bastante pesado e que pode comprometer o uso do processador da máquina do SharePoint, impossibilitando assim que os usuários acessem o site O modelo utilizado Apesar de o modelo proposto ser bastante aceito e elogiado, foi constatado que o tempo de desenvolvimento para a criação desta solução seria muito elevado quando comparado com o que se esperava gastar no projeto. Além disso, os ganhos desta aplicação seriam em sua maioria em longo prazo e não trariam um resultado imediato. Com vista no tempo e nas necessidades atuais, foi sugerida uma solução mais compacta e simplificada que pode ser vista na figura 11.

36 23 Figura 11 Modelo lógico aprovado O framework continua sendo utilizado da mesma forma como foi proposto no modelo anterior. A diferença é que todos os recursos padrões do SharePoint continuarão a ser utilizados. O projeto foi então dividido em duas fases. A primeira fase é a criação do framework para os fluxos de trabalho e a migração dos fluxos atuais para esta nova arquitetura. A segunda fase é onde o framework será expandido para utilizar recursos próprios ao invés de utilizar os do SharePoint, sendo assim, aos poucos a solução estaria cada vez menos dependendo do SharePoint, chegando ao ponto de utilizá-lo apenas como interface final da solução de gerenciamento de fluxos de trabalho A resolução de problemas As dificuldades encontradas pela equipe de sistemas internos e pelos usuários do sistema podem ser divididas em duas categorias: técnico e não técnico.

37 24 Os problemas técnicos são aqueles que dificultam a construção, manutenção e entendimento do código de um fluxo de trabalho. Apesar de serem transparentes aos usuários, são considerados importantes, pois afetam diretamente a produtividade e a qualidade dos trabalhos entregues pela equipe. No caso dos problemas não técnicos, são algumas oportunidades de melhorias na interface, usabilidade, padronização além de algumas funcionalidades sugeridas pelos usuários para facilitar o trabalho. Abaixo serão listados os problemas e as soluções aplicadas Duplicidade de código e a criação de componentes A maior dificuldade era com relação à reutilização de código através de classes e componentes. Como no início do sistema não houve preocupação quanto a este assunto, os fluxos de trabalho foram desenvolvidos todos de forma independente, quando havia a necessidade de fazer algo que já estava pronto em um fluxo de trabalho já construído, o código era copiado e colado. Isso fez com que houvesse muita duplicidade de código e, consequentemente, desencadeou uma grande dificuldade para manter os fluxos de trabalho atualizados já que, por mais que a alteração fosse simples, era necessário alterar diversos pontos do código. A primeira ação tomada foi fazer um levantamento de todos os pontos que estão duplicados e que poderiam ser abstraídos em classes de negócio ou de interface gráfica. Os seguintes pontos de melhoria foram levantados: 1. Acesso ao banco de dados; 2. Visualização do histórico das tarefas; 3. Criação de tarefas; 4. Gravação de log; 5. Envio de ; 6. Validação de formulário. A segunda etapa foi efetivamente criar as classes necessárias e agrupá-las no que foi chamado de NeoGrid Workflow Framework. Este framework seria utilizado para guiar o desenvolvimento dos fluxos de trabalho através de uma convenção e um padrão de como utilizar os componentes tanto

38 25 gráficos quanto componentes de negócio. A grande vantagem nesta abordagem é que as alterações que afetam todos os fluxos de trabalho podem ser atualizadas a partir da alteração de um único local do código, reduzindo assim a probabilidade de cometer erros e diminuir o esforço necessário Padronização e melhoria nos s Os s enviados pelo sistema já seguem um padrão, porém isso não acontece em todos os fluxos de trabalho. Alguns mais antigos possuem um layout bastante ruim, nada amigável e pouco informativo. Além de ter alguns s que ainda são enviados no modelo antigo, os usuários sugeriram que os s contivessem mais informações. Atualmente o contém apenas um título, o nome do fluxo de trabalho, uma breve descrição, padrão para qualquer , e um link de acesso rápido para a tomada de ação na tarefa em questão. Foi solicitado que no conteúdo do tivesse uma descrição do que se trata o item que gerou o . Por exemplo, no caso de uma solicitação de compra de um notebook modelo X que custa R$2.500,00, estas informações deveriam estar listadas no para que o responsável possa tomar uma ação imediata caso seja uma solicitação que necessita de uma aprovação urgente. Atualmente é necessário entrar no site e ler o formulário de solicitação para obter esta informação. O mesmo ocorre no fluxo de solicitação de férias onde o ideal seria que o contivesse o nome de quem está solicitando. Como pode ser visto na figura 12, o contém o nome do funcionário, o mês e ano, a quantidade de dias de férias e a quantidade de dias a serem pagos. Com base nestas informações o gerente já tem como saber do que se trata e se precisa de ação imediata. Como estas informações variam de fluxo para fluxo, o componente de foi programado para ser flexível o suficiente para atender esta necessidade.

39 26 Figura 12 contendo detalhes da solicitação de férias Reatribuição de tarefas Outro problema bastante comum é que quando uma tarefa é atribuída para alguém, não é possível repassar esta tarefa para outra pessoa, ela fica atrelada àquele usuário e por questões de governança só aceita tomada de ação que venha do dono da tarefa. Quando o usuário clica no botão de reatribuição em uma tarefa que seja sua, é aberta uma janela Pop-up para que ele possa escolher para que outra pessoa ele deseja repassar tarefa. Caso o usuário abra uma tarefa de outra pessoa da sua equipe e clique no botão de reatribuição, fica disponível também a opção de atribuir a tarefa para ele mesmo. Como o SharePoint permite a criação de grupos de usuários, foi criado um grupo de administradores do sistema onde toda a equipe de sistemas internos faz parte. Este grupo possui uma permissão especial nos fluxos de trabalho onde qualquer membro deste grupo pode reatribuir qualquer tarefa do sistema para si mesmo ou então repassar para outra pessoa. Essa funcionalidade foi programada para que se possa dar continuidade naqueles fluxos de trabalho que estão paradas por causa de alguma pessoa ausente.

40 Alerta de tarefas atrasadas Algumas pessoas na empresa chegam a receber 50 tarefas de aprovação por dia através dos mais diversos fluxos de trabalho. Como é um número bastante grande, levase algum tempo até ler, analisar e tomar alguma ação para cada uma destas tarefas. Além disso, em dias onde essas pessoas estão ocupadas com atividades mais urgentes, é comum que estas tarefas fiquem paradas durante um ou dois dias sem a tomada de qualquer ação. Na maioria dos casos não há problema em esperar alguns dias, mas há situações onde uma solicitação de compra é considerada urgente e requer uma ação imediata. Atualmente a pessoa que solicitou a compra precisa entrar em contato com o aprovador pessoalmente e pedir para que ele aprove a compra o mais rápido possível. Outro caso bastante comum é quando uma pessoa não possui o costume de realizar tarefas em fluxos de trabalho e apenas uma tarefa por semana. Por não estar acostumado a acessar no sistema todo dia e ter poucas tarefas para tomar alguma ação, essas pessoas normalmente esquecem-se da tarefa e o fluxo chega a ficar quase um mês parado. Foi solicitado então que fizéssemos alguns ajustes no sistema para que pudéssemos resolver estes problemas. Para solucionar a primeira dificuldade foi criada a coluna Due Date (data de vencimento) na lista de tarefas. Esta coluna contém até que dia determinada tarefa deve ser realizada. Por padrão, toda vez que uma tarefa é criada, a data de vencimento é a data de criação acrescida de sete dias úteis. Por outro lado, também é possível customizar para que a data de vencimento seja maior ou menor, como por exemplo, no fluxo de compras, quando uma solicitação é criada com prioridade alta, a data de vencimento é dois dias a mais ao invés de sete. Todas estas configurações são possíveis de serem feitas utilizando os componentes criados anteriormente. A listagem de tarefas pendentes é ordenada de forma crescente pela data de vencimento, sendo assim, as primeiras tarefas são aqueles que precisam ser realizados primeiro. Está em estudo a necessidade de incluir a opção Urgente no fluxo de compras, neste caso a data de vencimento seria igual à data de criação por se tratar de algo que precisa ação imediata.

41 28 Já no caso do segundo problema, foi utilizada a funcionalidade de agendamento de tarefas do SharePoint para criar um processo que é executado todo dia útil às 01h00min. Este processo é responsável por verificar todas as tarefas que estão pendentes e já passaram da data de vencimento. Estas tarefas são agrupadas por funcionário e um único é enviado para cada pessoa informando todas as tarefas atrasadas. A figura 13 apresenta um exemplo de enviado pelo processo noturno. No conteúdo do há uma lista das tarefas que o usuário precisa concluir seguido da quantidade de dias em que a tarefa está atrasada. Isso significa que, provavelmente, a primeira tarefa da lista é a mais crítica. Figura 13 Conteúdo do de tarefas atrasadas 5. ATIVIDADES PENDENTES Nem todas as atividades planejadas para serem realizadas durante o estágio puderam ser executadas. O principal motivo foi que não se tinha ideia de quão difícil seria padronizar as funcionalidades do fluxo de trabalho em forma de classes reutilizáveis. Atividades que foram previstas algumas horas para escrever chegaram a durar dias. Além disso, novas sugestões e ideias de novas funcionalidades iam surgindo com o passar do tempo e já eram imediatamente inseridas no projeto. Abaixo são listadas as atividades que ainda não foram executadas.

42 TABELA DE SUBSTITUIÇÃO Uma das situações embaraçosas que acontece com bastante frequência é quando um funcionário sai de férias e a equipe de sistemas internos não é avisada. Caso um fluxo de trabalho necessite aprovação de um desses funcionários, a tarefa fica presa com este usuário e o fluxo fica travado até que o funcionário volte de férias ou que a equipe de sistemas internos reinicie todo o fluxo. Como nós somos responsáveis por configurar os aprovadores de cada fluxo de trabalho, é necessário fazer alterações de papeis no sistema toda vez que um funcionário sai de férias. Isso requer um trabalho manual que se não for feito com antecedência pode causar transtornos conforme descrito acima. Foi estabelecido pela nossa equipe que uma tabela de substituição seria a solução mais elegante, simples e efetiva de resolver o problema. Esta tabela seria programada em forma de uma lista do SharePoint pela facilidade de manutenção e visualização. A estrutura desta lista seria baseada no quadro abaixo. Nome da Coluna Funcionário Substituído Funcionário Substituto Data de Saída Data de Retorno Tipo de Dado Usuário Usuário Data Data Tabela 1 Estrutura da tabela de substituição Antes de qualquer fluxo criar uma tarefa para qualquer usuário, o sistema consulta esta lista para saber se o funcionário possui algum substituto. Caso haja, então a tarefa é criada para o usuário substituto. As datas de saída e de retorno são utilizadas para verificar qual o período de validade da substituição, isso permite que a equipe possa fazer agendamento de substituições que só serão consideradas dentro do período criado por estas duas datas. Surgiu também a ideia de que o fluxo de solicitação de férias fosse integrado a esta tabela de substituição. No final da solicitação, após aprovação do gerente e do departamento de RH, o fluxo de trabalho cria uma nova tarefa para o gerente informar quem vai substituir o funcionário em questão durante as férias. Tendo esta informação é

43 30 possível criar um novo registro na tabela de substituição onde o funcionário substituído é quem solicitou férias, o funcionário substituto foi informado pelo gerente, a data de saída é a data de início das férias e a data de retorno é a data de fim das férias MIGRAR OS FLUXOS DE TRABALHO PARA A NOVA PLATAFORMA Nesta etapa estava prevista a readequação de todo o código dos fluxos de trabalho já em utilização. Seria necessário reescrever a maior parte do código para que ele pudesse se adequar à nova estrutura. Apesar de parecer muito trabalhoso, a utilização dos componentes criados na etapa anterior iria acelerar esta atividade. Além destes componentes, o uso de regras de negócio encapsuladas em classes permitiria a reutilização de grande parte do código necessário para construir um fluxo TESTES, HOMOLOGAÇÕES E AJUSTES Depois de finalizado toda a migração seria necessário aplicar algum tempo em testes para garantir que os fluxos estejam funcionando da forma esperada. Uma das maiores preocupações nesta etapa era garantir a compatibilidade retroativa, ou seja, certificar-se que nenhum dos fluxos pare de funcionar após a atualização e também que as interfaces continuassem suportando a visualização das requisições de versões antigas. Foi previsto pouco tempo para esta etapa porque toda a equipe estaria junta aplicando este tempo junto nos testes para que houvesse uma maior cobertura de testes.

44 31 CONSIDERAÇÕES FINAIS O curso de Tecnologia em Análise e Desenvolvimento de Sistemas da UDESC proporcionou experiências que foram de extrema importância para as atividades desenvolvidas no projeto de estágio. Entre elas, destaca-se principalmente a matéria de Análise de Sistemas que ensinou a ter sempre em mente a pergunta chave para questionar os usuários: O que você espera ganhar ou parar de perder com isso? A cadeira de SQL ajudou no entendimento do banco de dados enquanto que a Sociologia das Organizações ensinou qual o comportamento ideal diante de uma organização e como trabalhar melhor em equipe. Apesar do conhecimento prévio em linguagens de programação, as aulas de Estrutura de Dados I e II fizeram-me praticar a escrita de algoritmos que potencializaram o desenvolvimento do raciocínio lógico. Apesar de que nem todas as atividades propostas no início do estágio foram concluídas, é possível notar que o projeto possui um grande potencial. Nas últimas semanas foi realizada uma apresentação para algumas pessoas interessadas no assunto e o resultado foi bastante positivo. Por este motivo foi decidido dar continuidade no projeto. O trabalho realizado na NeoGrid foi de suma importância para o desenvolvimento profissional do acadêmico pois permitiu que tecnologias e conceitos que estão em alta no mercado fossem colocadas em prática. Além disso, a atuação lado a lado com especialistas dos mais diversos departamentos, como financeira, recursos humanos e vendas, proporcionou uma experiência única de conhecer um pouco mais sobre outras áreas de negócios.