Integração de OpenERP Enterprise Resource …paginas.fe.up.pt/~ee05128/dissertacao/wp-content/uploads/2012/02/...FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Integração de

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Integração de OpenERP (EnterpriseResource Planning) num Sistema de

Gestão Documental e Workflow

Marcelo Sousa Almeida

VERSÃO PROVISÓRIA

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Orientador: Professor Doutor José Manuel Magalhães Cruz

Proponente: iPortalMais - Serviço de Internet e Redes Lda

Janeiro de 2012

c© Marcelo Sousa Almeida, 2012

Resumo

No contexto atual da gestão empresarial, devido ao aumento da competitividade e à formadinâmica como os negócios têm evoluído, surgem novos desafios a serem enfrentados pelas em-presas. Para fazer frente a estes desafios é necessário uma maior cooperação entre funcionários,dirigentes e outros intervenientes na cadeia de produção.

Com o auxílio das novas tecnologias surgem importantes ferramentas estratégicas que auxi-liam a coordenação entre as diferentes áreas levando a uma melhoria da eficiência e de organizaçãoda empresa causando consequentemente uma redução de custos.

Uma forma de atingir estes objetivos é a utilização de ferramentas de planeamento de recursos,ERP’s. Ferramentas deste tipo auxiliam as empresas na integração e sincronização de processosisolados de forma a diminuir ou mesmo desfazer a complexidade resultante da sua agregaçãoconducente ao produto final.

OpenERP é uma solução de gestão empresarial de código aberto que inclui aplicações devendas, Customer Relationship Management (CRM), gestão de projetos, gestão de materiais, con-tabilidade, recursos humanos entre outras.

iPortalDoc é um sistema de gestão documental e workflow disponibilizado pela iPortalMaisque visa melhorar a gestão documental e fluxo de trabalho de qualquer empresa ou instituição queo decida utilizar.

A integração dos sistemas de gestão documental e workflow com sistemas de gestão empresa-rial, é um passo importante no desenvolvimento das organizações.

O trabalho que se apresenta teve como objetivo a instalação e parametrização do sistema degestão empresarial OpenERP para funcionar em conjunto com o sistema operativo IPBrick e como sistema de gestão documental iPortalDoc .

Os sistemas de gestão empresarial geram muita documentação que tem de ser salvaguardada,por sua vez os sistemas de gestão documental são feitos propositadamente para cumprir essa fun-ção.

Outra funcionalidade implementada neste projeto é possibilidade de consultar informaçõesdos documentos de teor contabilístico presentes no iPortalDoc , mesmo que gerados por outrasaplicações ou provenientes de entidades terceiras. Toda essa informação pode ser consultada ouvisualizado o estado em que se encontram os documentos ao longo da execução do workflow,através da interface do OpenERP . Além disso toda a documentação gerada pelo OpenERP podeagora ser exportada para o iPortalDoc .

i

ii

Versão 1.10 (16 de Fevereiro de 2012)

Abstract

In the current context of business management, increased competitiveness and dynamism, newchallenges arise to be faced by the companies. To meet these challenges, a greater cooperationbetween employees, managers and other stakeholders in the production chain is needed.

With the help of new technologies, important strategic tools arise that assist the coordinationbetween the different areas leading to improved efficiency and organization of the company andso resulting in the reduction costs.

One way of achieving these objectives is the use of tools for resource planning, ERP. Tools ofthis kind help companies in the integration and synchronization of isolated processes to reduce oreven remove the complexity resulting from their aggregation leading to the final product.

OpenERP is an open source solution for enterprise management that includes applications tocontrol sales, Customer Relationship Management (CRM), project management, materials mana-gement, accounting, human resources among others.

iPortalDoc is a document and workflow management system provided by iPortalMais to im-prove document management and workflow that any company or institution decides to use.

The integration of document and workflow management systems with enterprise resource plan-ning systems, ERP is an important step in the development of organizations.

The work here presented has aimed installation and configuration of the enterprise resourceplanning system OpenERP to work in conjunction with the operating system IPBrick and iPortal-Doc .

Fundamental part of the management systems are the entities, therefore, must be guaranteedbi-directional synchronization of all information between these two systems in question.

Another important part of these systems is the documentation. The enterprise resource plan-ning systems generate a lot of documentation that must be safeguarded; in turn document mana-gement systems are made purposely to fulfill this function.

Another feature implemented in this project is the ability to consult the information and thecontent of the documents present on iPortalDoc , even if generated by other applications or fromthird party entities, offering the possibility to consult them or to view the status in which theyare along the workflow. everything through the interface of OpenERP Also, all the documentationgenerated by OpenERP can be exported to iPortalDoc .

iii

iv


Agradecimentos

Em primeiro lugar à minha família, que sempre me apoiou e ajudou em tudo o que puderam,sendo sempre um grande exemplo de trabalho e humildade.

Ao meu orientador Professor Doutor José Manuel Magalhães Cruz por todo o tempo despen-dido comigo e pela preciosa ajuda e disponibilidade prestada na escrita deste trabalho.

À iPortalMais por me ter concedido a oportunidade de realizar esta dissertação.A todos os colaboradores da iPortalMais pela forma como me receberam e por toda a ajuda e

disponibilidade prestada.Por último, mas não menos importante, a todos os meus amigos que sempre me apoiaram e

motivaram a seguir em frente.

A todos o meu muito obrigado

Marcelo Almeida

v

vi


“What we do for ourselves dies with us.What we do for others and the world, remains and is immortal.”

Albert Pine

vii

viii


Conteúdo

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Arquitetura Geral e Principais Tecnologias 32.1 Gestão Documental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Sistemas de Gestão Documental . . . . . . . . . . . . . . . . . . . . . . 52.1.4 Classificação da Informação . . . . . . . . . . . . . . . . . . . . . . . . 52.1.5 Conceitos Aplicados na Gestão Documental . . . . . . . . . . . . . . . . 62.1.6 Funcionalidades básicas dos Sistema de Gestão Documental . . . . . . . 62.1.7 Vantangens dos Sistema de Gestão Documental . . . . . . . . . . . . . . 8

2.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 Sistemas de Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Sistema de Gestão de Workflow . . . . . . . . . . . . . . . . . . . . . . 112.2.5 Funcionalidades de um Sistema de Gestão Workflow . . . . . . . . . . . 112.2.6 Constituição de um Workflow . . . . . . . . . . . . . . . . . . . . . . . 142.2.7 Categorias de Sistema de Gestão Workflow . . . . . . . . . . . . . . . . 152.2.8 Requisitos Típicos numa Aplicação de Workflow . . . . . . . . . . . . . 152.2.9 Vantagens dos Sistemas de Gestão de Workflows . . . . . . . . . . . . . 16

2.3 Enterprise Resource Planning, ERP . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.3 Estrutura básica de um ERP . . . . . . . . . . . . . . . . . . . . . . . . 182.3.4 Potencialidades de um Sistema ERP . . . . . . . . . . . . . . . . . . . . 182.3.5 Implementação de um Sistema ERP . . . . . . . . . . . . . . . . . . . . 192.3.6 Pontos Críticos de um Sistema ERP . . . . . . . . . . . . . . . . . . . . 20

2.4 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.2 PHP, Hypertext Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . 232.4.3 HTTP/HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.4 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.5 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.6 NET-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ix

x CONTEÚDO

2.4.7 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.8 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.9 Lightweight Directory Access Protocol - LDAP . . . . . . . . . . . . . . 312.4.10 GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.11 PyGTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Plataformas Tecnológicas 333.1 iPortalDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.2 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.3 Permissões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.4 Tipos de Documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.5 Introdução de Documentos . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 IPBrick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.1 IPBrick.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.2 IPBrick.C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.3 IPBrick.GT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.4 IPBrick.4CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.5 IPBrick.KAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.6 IPBrick.SOHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.7 IPBrick.SCHOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.8 IPBrick for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.2 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Outras Opções Tecnológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.1 Sistemas de Gestão Empresarial . . . . . . . . . . . . . . . . . . . . . . 443.4.2 Sistemas de Gestão Documental e Workflow . . . . . . . . . . . . . . . . 46

4 Planeamento 494.1 Ordem do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Requisitos do OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Implementação e Testes Efetuados 535.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3 Sincronização de Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3.1 IPContactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3.2 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.4 Sincronização dos Documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Conclusões e Trabalho Futuro 656.1 Conclusão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A Máquina Virtual 67

B OpenERP 69


CONTEÚDO xi

Referências 71


xii CONTEÚDO


Lista de Figuras

2.1 Classes de informação. Retirada de "Um referencial para o planeamento de siste-mas de informação" [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Workflow de realização de uma encomenda. . . . . . . . . . . . . . . . . . . . . 102.3 Caraterísticas de um Sistema de Gestão Workflow. Retirada de "The Workflow

Reference Model" [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Modelo de Referência de um Workflow. Retirada de "The Workflow Reference

Model" [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 A evolução do ERP. Retirada de "ERP : making it happen : the implementers

guide to success with enterprise resource planning" [23] . . . . . . . . . . . . . 182.6 Estrutura típica de um ERP. Retirado de "Putting the enterprise into the enterprise

system" [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7 Estrutura em árvore de um documento XML. . . . . . . . . . . . . . . . . . . . 252.8 Exemplo de documento XML com a estrutura da Figura 2.7. . . . . . . . . . . . 252.9 Arquitetura do XML-RPC. [33] . . . . . . . . . . . . . . . . . . . . . . . . . . 272.10 Exemplo de pergunta XML-RPC. . . . . . . . . . . . . . . . . . . . . . . . . . 282.11 Exemplo de resposta XML-RPC. . . . . . . . . . . . . . . . . . . . . . . . . . . 292.12 Estrutura de uma mensagem SOAP. Retirado de "Programming Web services with

SOAP" [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Arquitetura do iPortalDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Arquitetura do OpenERP . Baseado em [52] . . . . . . . . . . . . . . . . . . . . 433.3 Menu de instalação inicial do OpenERP onde é possível escolher os módulos a

instalar. [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4 Quotas de mercados de soluções ERP [55] . . . . . . . . . . . . . . . . . . . . . 45

5.1 Exemplo do comando "NOTIFY". . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 Exemplo do comando "LISTEN". . . . . . . . . . . . . . . . . . . . . . . . . . 545.3 Interface de instalação da IPBrick aquando a instalação do pacote postgresql-9.1-

for-ipbrick-1.0.deb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Interface de instalação da IPBrick aquando a instalação do pacote openerp-v6.0.3-4ipbrick-1.0.deb. 565.5 Interface de gestão de base de dados do OpenERP . . . . . . . . . . . . . . . . . 575.6 Interface de gestão do módulo users_ldap. . . . . . . . . . . . . . . . . . . . . . 585.7 Interface de gestão de sincronização de entidades do IPContactos . . . . . . . . . 605.8 Interface de gestão de sincronização de entidades do OpenERP . . . . . . . . . . 615.9 Interface de configuração de sincronização de documentos do OpenERP . . . . . 625.10 Interface de exibição da informação de um documento do iPortalDoc no OpenERP . 635.11 Listagem de documentos exportados do OpenERP para o iPortalDoc . . . . . . . 645.12 Listagem de documentos do iPortalDoc no OpenERP . . . . . . . . . . . . . . . 64

xiii

xiv LISTA DE FIGURAS

B.1 Interface principal do OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 69B.2 Módulos criados para o OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . 70


Lista de Tabelas

4.1 Dependências para o servidor aplicacional OpenERP , "openerp-server" . . . . . 504.2 Dependências para o cliente Web OpenERP , "openerp-web" . . . . . . . . . . . 504.3 Outras dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Tempos de instalação do OpenERP na IPBrick . . . . . . . . . . . . . . . . . . . 575.2 Tempos de sincronização completa de entidades entre o IPContactos e o OpenERP . 61

A.1 Caraterísticas da máquina virtual utilizada. . . . . . . . . . . . . . . . . . . . . . 67

xv

xvi LISTA DE TABELAS


Abreviaturas e Símbolos

API Application Programming InterfaceCRM Customer Relationship ManagementDHCP Dynamic Host Configuration ProtocolDMZ DeMilitarized ZoneDNS Domain Name SystemERP Enterprise Resource PlanningFTP File Transfer ProtocolGB GigabyteGHz GigahertzGIMP GNU Image Manipulation ProgramGTK GIMP toolkitHTTP Hypertext Transfer ProtocolHTTPS Hypertext Transfer Protocol SecureIDS Intrusion Detection SystemIMAP Internet Message Access ProtocolISDN Integrated Services Digital NetworkJVM Java Virtual MachineLDAP Lightweight Directory Access ProtocolMB MegabyteMoodle Modular Object-Oriented Dynamic Learning EnvironmentMRP Material requirements planningMRP II Manufacturing Resource PlanningPBX Private Branch ExchangePDF Portable Document FormatPHP Hypertext PreprocessorPOP3 Post Office ProtocolQoS Quality of ServiceRDBMS Relational Database Management SystemRFC Request for CommentsRPC Remote Procedure CallRTP Real-time Transport ProtocolSaaS Software as a ServiceSAF-T PT Standard Audit File for Tax purposesSGML Standard Generalized Markup Language

xvii

xviii ABREVIATURAS E SÍMBOLOS

SIP Session Initiation ProtocolSMB Server Message BlockSMTP Simple Mail Transfer ProtocolSO Sistema OperativoSOAP Simple Object Access ProtocolSQL Structured Query LanguageSSL Secure Sockets LayerTCL Tool Command LanguageTLS Transport Layer SecurityUCoIP Unified Communications over IPURL Uniform Resource LocatorVoIP Voice over Internet ProtocolVPN Virtual Private NetworkW3C World Wide Web ConsortiumWAPI Workflow APIs and Interchange FormatsWfMC Workflow Management CoalitionWSDL Web Services Description LanguageWWW World Wide WebXML Extensible Markup Language


Capítulo 1

Introdução

Neste capítulo será apresentada uma introdução ao trabalho a desenvolver, bem como uma

descrição da sua motivação e os objetivos a cumprir ao longo da sua realização.

O presente trabalho foi desenvolvido na empresa iPortalMais - Soluções de Engenharia para

Internet e Redes, Lda. Enquadra-se num protocolo estabelecido entre a empresa e a Faculdade de

Engenharia da Universidade do Porto, e teve início no mês de Setembro de 2011 terminando agora

nos finais de Janeiro de 2012.

1.1 Motivação

No contexto atual da gestão empresarial, devido ao aumento da competitividade e à forma

dinâmica como os negócios têm evoluído, surgem novos desafios a serem enfrentados pelas em-

presas. Para fazer frente a estes desafios é necessário uma maior cooperação entre funcionários,

dirigentes e outros intervenientes na cadeia de produção.

Com o auxílio das novas tecnologias surgem importantes ferramentas estratégicas que auxi-

liam a coordenação entre as diferentes áreas levando a uma melhoria da eficiência e de organização

da empresa causando consequentemente uma redução de custos.

Uma forma de atingir estes objetivos é a utilização de ferramentas de planeamento de recur-

sos (Enterprise Resource Planning). Ferramentas deste tipo auxiliam as empresas na integração

e sincronização dos processos de produção isolados de forma a diminuir ou mesmo desfazer a

complexidade resultante da sua agregação num processo virtual único que permite a geração do

produto final das empresas.

OpenERP é uma solução de gestão empresarial de código aberto que inclui aplicações de

vendas, Customer Relationship Management (CRM), gestão de projetos, gestão de materiais, con-

tabilidade, recursos humanos entre outras.

1

2 Introdução

1.2 Objetivos

O objetivo deste projeto consiste na integração de software ERP com software de Gestão

Documental e Workflow, para produzir uma solução integrada funcional. Como concretização

utilizou-se o software aberto OpenERP no sistema operativo IPBrick.IC e o Sistema de Gestão

Documental e Workflow iPortalDoc .

Na solução concreta integrada e final a desenvolver estão previstas as seguintes funcionalida-

des:

• Instalação do OpenERP no sistema operativo IPBrick.IC , garantindo a sua parametrização

automática de acordo com as configurações pré-definidas neste.

• Integração bidirecional dos dados das entidades entre o sistema iPortalDoc e a aplicação

OpenERP .

• Introdução e classificação automática no iPortalDoc de todos os documentos gerados pelo

OpenERP .

• Integração dos documentos contabilísticos com origem nos fornecedores e terceiros, no

sentido do iPortalDoc para o OpenERP .

• Abertura de documentos arquivados no Sistema de Gestão Documental e Workflow iPortal-

Doc diretamente através do OpenERP de forma direta.

• Actualização automática na aplicação de ERP do estado dos documentos, tendo em conta a

evolução do workflow, deles no iPortalDoc .

Como resultado pretende-se que no final do projeto uma organização que disponha do sistema

operativo IPBrick.IC , Sistema de Gestão Documental e Workflow iPortalDoc e OpenERP , possa

disponibilizar à sua Administração e Departamento Financeiro a possibilidade de obter de forma

simples e rápida toda a informação relevante para a sua actividade.

1.3 Estrutura do documento

Este relatório encontra-se organizado em seis capítulos, sendo o primeiro dos quais a introdu-

ção.

No segundo capítulo é descrita a arquitetura geral do sistema bem como uma descrição das

principais tecnologias utilizadas no desenvolvimento do projeto.

No terceiro capítulo são expostas as plataformas tecnológicas presentes no desenvolvimento

deste projeto, bem como algumas alternativas tecnológicas.

No quarto capítulo é exposto o planeamento a seguir durante a execução do projeto.

No quinto capítulo é descrita a implementação do projeto e também alguns testes realizados.

Por fim, o sexto capítulo apresenta as conclusões de todo o trabalho efetuado ao longo deste

projeto e sugere algumas perspetivas de desenvolvimento para o futuro.


Capítulo 2

Arquitetura Geral e PrincipaisTecnologias

A arquitetura do sistema consiste em duas aplicações distintas, Sistema de Gestão Documental

e Workflow, SGDW, e um Sistema de Gestão Empresarial, ERP que no final devem funcionar em

conjunto. Tendo como principais funcionalidades, a sincronização bidirecional de entidades entre

os dois sistemas e o envio de documentos gerados pelo Sistema de Gestão Empresarial para o

Sistema de Gestão Documental e Workflow para que deste modo este armazene devidamente toda

a informação gerada.

Neste capítulo irá ser feita uma revisão conceptual sobre Sistema de Gestão Documental, SGD,

seguido pelos Sistemas de Gestão de Workflow, SGW, e Sistemas de Gestão Empresarial, ERP.

Após a apresentação destes sistemas apresenta-se algumas das tecnologias utilizadas no desenvol-

vimento deste projeto.

2.1 Gestão Documental

Esta secção tem como objetivo apresentar alguns conceitos relativos à gestão documental.

Iniciando-se esta secção com uma introdução à gestão documental, sendo feita de seguida uma

breve resenha histórica. De seguida é feita uma abordagem aos sistemas de gestão documental,

descrevendo alguns dos seus conceitos, funcionalidades básicas que este deve suplantar e, por fim,

algumas vantagens da sua utilização.

2.1.1 Introdução

Um dos fatores fundamentais na evolução de qualquer empresa é a organização e disponibi-

lização atempada de informações relevantes a todos os intervenientes no processo de produção.

Desde há muito tempo que é, necessária a utilização de múltiplos documentos para o funciona-

mento de uma empresa. Este uso excessivo de documentação conduz a que ocorram diversos

3

4 Arquitetura Geral e Principais Tecnologias

problemas, tal como, o extravio de documentos, diversas versões não controladas, crescentes cus-

tos de cópias e armazenamentos, entre outros. Para evitar ou minorar tais problemas é necessário

um sistema capaz de recolher, armazenar, gerir e disponibilizar toda a documentação recebida ou

produzida na empresa.

Os sistemas de gestão documental permitem que as empresas e os seus utilizadores usufruam

de uma maior rapidez, eficácia, organização, segurança e fiabilidade no acesso à informação. Num

sistema deste género os documentos são guardados num formato eletrónico, permitindo que a in-

formação esteja organizada e seja classificada segundo as suas caraterísticas permitindo uma dis-

tribuição mais eficaz e eficiente. A gestão documental segue um conjunto de passos bem definidos:

os documentos são recebidos em papel, digitalizados para passarem para formato eletrónico, é-lhe

atribuída uma classificação, são definidos os vários estados do ciclo de vida do documento e, por

fim, é disponibilizado o acesso aos utilizadores de todo o material através de um serviço como,

por exemplo iPortalDoc1.

2.1.2 História

A informação tem adquirido ao longo dos tempos cada vez mais importância. A partir da

segunda metade do século XIX, a arquivologia desenvolveu-se como uma disciplina, podendo-se

dizer que o seu aspeto mais importante é a gestão de documentos.

Apesar da sua conceção teórica e aplicação prática se ter desenvolvido após a Segunda Guerra

Mundial, a gestão documental já era utilizada nos finais do século XIX, em função de problemas

detetados nas administrações públicas dos E.U.A e do Canadá, no que se referia à gestão e uso

de informação. Na primeira metade deste século criaram-se comissões governamentais com o

objetivo de encontrar soluções que proporcionassem uma melhor eficácia no que toca ao uso de

documentos pela administração pública. É importante referir que, durante este período, as institui-

ções arquivistas públicas caracterizavam-se pela sua função de apenas apoio à pesquisa, estando

comprometidas somente com a conservação e o acesso a documentos classificados como de valor

histórico. Este modo de funcionamento não contemplava documentos de cariz administrativo, cu-

jos problemas eram considerados de alçada exclusiva dos órgãos da administração pública que os

produziam e utilizavam.

Conforme mencionou Ricks num trabalho apresentado no VIII Congresso Internacional de Ar-

quivos, realizado em Washington, em 1976 [1], A gestão de documentos criou maior consciência

em todo o governo, no caso norte-americano, quanto ao significado dos documentos, qualquer

que fosse seu suporte, e às suas necessidades de conservação.

As instituições arquivísticas públicas, particularmente os arquivos nacionais dos EUA e do Ca-

nadá, passaram a utilizar uma nova maneira de trabalhar, assumindo também a função de órgão de

apoio à administração pública, com a competência de orientar programas de gestão de documentos

nos diversos organismos governamentais.

1Sistema de Gestão Documental e Workflow da empresa iPortalMais


2.1 Gestão Documental 5

Hoje, estas instituições dispõem de considerável prestígio e de grandes orçamentos, pois foi

reconhecido que, como instituições, economizam mais dinheiro do que gastam, em resultado de

suas atividades de gestão de documentos. Um exemplo: a rede de arquivos intermediários regio-

nais norte-americanos permite aos cofres públicos uma economia de cem milhões de dólares por

ano. O custo público da informação governamental tende a alcançar níveis reduzidos, aplicando-

se o princípio básico de gestão de documentos, segundo o qual a informação deve estar disponível

no lugar certo, na hora certa, para as pessoas certas e com o menor custo possível.

2.1.3 Sistemas de Gestão Documental

Um estudo do Comité Económico Europeu [2] revela que o volume de informação não estru-

turada produzida pelas organizações creste entre 65% a 200% por ano, dependendo do sector em

causa; outro estudo [2], revela que cada pessoa produz em média 800MB a cada ano que passa.

Ainda outros estudos [3] revelam que cada funcionário perde 12% do seu tempo à procura de do-

cumentos na secretária ou no arquivo, 90% dos documentos com que se trabalha no dia a dia estão

misturados com outros documentos, 80% dos documentos manuscritos nunca mais são consulta-

dos, 50% de todos os documentos no seu arquivo são duplicados ou encontram-se desatualizados

e 15% dos documentos manuseados perdem-se.

A esta grande quantidade de informação junta-se ainda a incapacidade das empresas a clas-

sificarem correta e eficazmente e perceberem se um determinado documento possui informação

importante ou se é apenas mais um ficheiro a sobre carregar o sistema. Também não têm co-

nhecimento se o documento já se encontra na versão final ou mesmo quem lhe teve acesso. Em

resumo, não é possível saber o ciclo de vida da informação, tendo como consequência o arrecadar

de custos, o que traz alguns riscos para a empresa. [4]

A gestão documental é, atualmente, o meio mais eficaz para gerir documentos, entendendo-

se por documentos todo o tipo de suporte utilizado que contenha informação. Estes podem-se

encontrar em vários formatos, papel, eletrónico ou ambos, contendo a mesma informação. Face

à especificidade de cada documento, eles devem ser tratados de formas diferentes, tendo como

objetivo final a salvaguarda da informação neles contida.

Através de uma solução de gestão documental, é possível consultar rapidamente qualquer

informação que esteja num documento e colocá-la em contexto com o processo de negócio em

que participa. As soluções de gestão documental são frequentemente procuradas para suportar o

arquivo documental associado a processos onde o volume de documentos é significativo.

2.1.4 Classificação da Informação

A informação deve ser classificada conforme o papel que desempenha nas atividades da orga-

nização, apresentando assim diferentes graus de importância como é possível ver na Figura 2.1.

A importância da informação pode conduzir a que as organizações a tentem colectar em ex-

cesso, fazendo com que esta se torne cada vez mais difícil de gerir. As organizações devem con-

centrar os seus esforços na manutenção das informações que apresentam um grau de importância



Figura 2.1: Classes de informação. Retirada de "Um referencial para o planeamento de sistemasde informação" [5]

mais elevado, ou seja, informação crítica, mínima e potencial. No entanto a classificação de toda

e informação em uma destas classes poderá ser um problema de difícil resolução. Para minimizar

este dificuldade é necessário compreender o valor da informação.

2.1.5 Conceitos Aplicados na Gestão Documental

A gestão documental electrónica é um processo abrangente que implementa diversos concei-

tos, de entre os quais se podem destacar alguns. A desmaterialização, que corresponde à passa-

gem de documentos do formato físico, por exemplo, o papel, ao formato eletrónico, por exemplo

segundo a norma ISO 32000-1:2008, vulgo PDF, Portable Document Format. Outro conceito im-

portante é a indexação, que implica uma catalogação e classificação dos documentos. Pode ser

feita a analogia entre um sistema de gestão documental eletrónico e um físico em que o arquivo

dos documentos é feito em pastas ordenando-os alfabeticamente ou por datas; no caso dos sis-

temas electrónicos o processo é facilitado, uma vez que se usufrui das vantagens dos sistemas

de informação. Outro conceito importante é o conceito de workflow, que consiste em definir-se

os vários estados pelos quais um documento tem de passar até atingir um estado final. Por fim,

um Sistema de Gestão Documental deverá implementar uma forma de pesquisa rápida e eficiente,

possibilitando o acesso aos documentos presentes no sistema.

2.1.6 Funcionalidades básicas dos Sistema de Gestão Documental

Os sistemas de gestão documental devem oferecer aos seus utilizadores um diverso conjunto

de funcionalidades a nível de utilização, encaminhamento, segurança e administração. [6]


2.1 Gestão Documental 7

Quando a funcionalidades relacionadas com a utilização e encaminhamento um Sistema de

Gestão Documental deverá oferecer a capacidade de criação e formatação de modelos (templa-

tes) de documentos sem que seja necessário que o utilizador tenha conhecimentos profundos em

programação.

Outra funcionalidade essencial é a criação de documentos com referência única e respetiva

validação, nomeadamente, tipo, designação, assunto, autor, classificação, numeração, versão, da-

tas de criação e revisão, encaminhamento, impressão e arquivo. Além disso, também deve ser

garantido o controlo de versões dos documentos contando com a revisão dos seus atributos. Os

documentos devem ser indexados, bem como as pastas onde estão armazenados por taxionomia

hierárquica de modo a serem facilmente encontrados durante todo o seu ciclo de vida.

Como ponto crucial, deve garantir-se o trabalho colaborativo, caso contrário o Sistema de Ges-

tão Documental perde boa parte do seu interesse, não oferecendo, por exemplo, possibilidades de

encaminhar documentos criados ou inseridos para outros utilizadores incluindo neste encaminha-

mento comentários, pareceres ou decisões. Dentro desta funcionalidade de colaboração, deverá

também ser possível notificar os intervenientes de tarefas que lhe estão atribuídas e que ainda não

foram concluídas.

Outro ponto de relevo é a importação e exportação de conteúdos de e para outras aplicações,

como por exemplo, ERP (Enterprise Resource Planning) ou CRM (Customer Relationship Mana-

gement), uma vez que são aplicações que geram muita documentação e determinante que está seja

armazenada e catalogada de forma lógica e fácil acesso.

Por fim, deverá ser possível colocar toda a informação contida no Sistema de Gestão Docu-

mental em papel ou noutro qualquer suporte físico comum.

Em termos de segurança, o sistema deve oferecer a capacidade de transmissão dos dados de

forma segura sem que a sua informação possa ser comprometida ou consultada por terceiros; para

este último efeito dever-se-á recorrer à cifra dos dados.

É circunstancial também que a autenticidade dos documentos seja salvaguardada adicionando-

lhe assinaturas digitais e carimbos temporais; desta maneira, há certeza que os documentos em

questão são originais.

Ainda no que concerna a questões de segurança, o sistema deverá ser capaz de controlar os

acessos a dados e documentos a diferentes níveis, utilizando para isso perfis de utilizadores, atri-

buindo diferentes níveis de acesso.

Além de todas as funcionalidades anteriormente descritas, um Sistema de Gestão Documental

deverá garantir funções de administração tais como, alteração de matrizes de documentos, taxiono-

mias, perfis de acesso e métricas de informação de todos os documentos servidos. Deverá também

estar garantido o uso de rotinas de auditoria, bem como interfaces parametrizáveis e amigáveis

para o utilizador.



2.1.7 Vantangens dos Sistema de Gestão Documental

Em resumo, a utilização de Sistemas de Gestão Documental traz inúmeras vantagens, sendo a

seguir nomeadas as principais: [7] [8]

• melhoria dos acessos, precisão e velocidade do fluxo de informação, reduzindo o tempo

gasto na procura de documentos críticos;

• aumento da produtividade, pela melhoria da comunicação entre diferentes utilizadores ou

mesmo diferentes departamentos, que possibilita uma troca de informação de forma rápida

e precisa;

• organização da informação por processos;

• uniformização e sistematização dos procedimentos;

• melhor controlo dos documentos e processos;

• possibilidade de medir a eficiência de recursos;

• redução do retrabalho devido a documentos com erros ou desatualizados;

• possibilidade de acesso à informação em qualquer lugar;

• aumento da segurança devido ao controlo de acesso a documentos sensíveis;

• redução dos custos em armazenamento;

• salvaguarda e recuperação de dados com recurso a cópias de segurança (backups).

2.2 Workflow

Nesta secção será feito um resumo dos diversos conceitos aplicados aos Sistemas de Workflow.

Iniciando-se esta secção com uma introdução aos workflows, sendo feita de seguida uma breve

resenha histórica. De seguida é feita uma abordagem aos sistemas de gestão de workflows, des-

crevendo algumas funcionalidades essenciais, categorias de workflows, requisitos que estes devem

cumprir e, finalmente, algumas vantagens.

2.2.1 Introdução

Workflow consiste numa sequência de passos que permite sistematizar de forma consistente

a informação, documentação ou tarefas entre utilizadores de acordo com uma série de regras,

permitindo tornar estes processos mais simples e intuitivos aos utilizadores. A automatização de

um processo exige a identificação das diversas atividades, regras a cumprir e dados usados para

gerir o ciclo de vida de um workflow.


2.2 Workflow 9

Um sistema workflow interpreta processos, cria e gere instâncias e interage com os participan-

tes das aplicações. Gere as atividades resultantes de um processo e as suas relações desde o início

até ao fim da sua utilização. Durante o seu ciclo de vida um processo, é atribuído a um participante

e são-lhe atribuídas tarefas que serão controladas pelo sistema de gestão de workflow assegurando

assim o seu correto desenvolvimento. [9]

A utilização de um sistema de workflow por uma empresa, permite-lhe automatizar processos

de negócio, a interação com os utilizadores e clientes, etc. Isto leva a que haja uma maior eficiência

a nível operacional, tendo como resultado uma melhoria da qualidade dos serviços prestados e,

consequentemente, um aumento da produtividade.

2.2.2 História

Os sistemas de workflow são bastante antigos, no entanto apenas nas últimas décadas co-

meçaram a ganhar popularidade devido à necessidade das organizações automatizarem os seus

processos de negócio.

Os sistemas de gestão de workflow tiveram origem na automação do trabalho. [10] Por natu-

reza, os processos empresariais eram monolíticos; e as políticas de negócio e acesso às informa-

ções estavam rigidamente definidas nas aplicações. Para além disso, estes sistemas normalmente

eram isolados, sem ligação com outros sistemas de workflow ou aplicações genéricas.

A primeira geração dos sistemas de workflow foram descritas como aplicações monolíticas de

uma área de domínio particular. A segunda geração dividiu os sistemas em diversos componentes,

mas estes ainda ficaram fortemente dependentes das aplicações. A terceira geração apresentou

máquinas de workflow genéricas que forneciam uma infraestrutura robusta para workflows orien-

tados à produção. Por fim, a quarta geração, seria a atual, caracterizada por sistemas de workflow

flexíveis capazes de fornecer uma diversa gama de serviços. [11]

Com a evolução natural dos sistemas, tornou-se necessário separar os processos de negócio

e as componentes de workflow das aplicações existentes, tendo como objetivo aumentar a fle-

xibilidade e o poder de manutenção destes sistemas. [11] Além disso, os sistemas passaram de

"sistemas orientados a dados" para "sistemas orientados a processos". Por fim a descentralização

das organizações, a necessidade de se obter informação detalhada sobre as atividades diárias, bem

como a utilização da arquitetura cliente/servidor, a relevância dos sistemas federados e a crescente

disponibilidade de tecnologia para o processamento distribuído, traçaram o fim do processamento

centralizado e monolítico. [12]

Atualmente os workflows têm um papel muito importante, resolvendo os problemas dos pro-

cessos e a sua automatização a todos os níveis das organizações.

2.2.3 Sistemas de Workflow

A utilização de workflows permite, de forma produtiva, flexível e integrada, modelar, automa-

tizar, integrar e otimizar os processos de negócio, quer parcialmente quer na sua totalidade. Desta



forma, a execução dum processo de negócio pode envolver diversos sistemas ligados, bases de da-

dos e aplicações, permitindo também a interação entre diferentes utilizadores, parceiros, clientes

e colaboradores. A implementação de um workflow é extremamente difícil de realizar devido à

necessidade de integrar com diversas aplicações distintas e interação com varias pessoas.

Nas empresas existem processos que são repetidos sucessivamente, e que possuem documen-

tos associados a cada uma das suas fases. Um processo de workflow é um processo que pode

ser pré-parametrizado, atribuindo responsáveis a cada um dos seus estados e no qual existem do-

cumentos que circulam entre os participantes. Esta abordagem, permite de forma eficiente, uma

redução de custos. [13]

Um exemplo de um processo de workflow é, por exemplo, a realização de uma encomenda, em

que processo passa por diferentes entidades, entre as quais o cliente, o colaborador e o distribuidor,

como representado na Figura 2.2.

Figura 2.2: Workflow de realização de uma encomenda.

Um workflow é definido como um conjunto de tarefas organizadas, que na sua totalidade e

seguindo uma ordem lógica, formam um processo de negócio, estando esta ordem também des-

crita no workflow. Algumas das tarefas podem ser automatizadas, sendo realizadas por sistemas

informáticos; no entanto, há tarefas que, devido às suas caraterísticas terão de ser realizadas por


2.2 Workflow 11

agentes humanos. [14]

Atualmente com o grande aumento da competitividade, as organizações lutam por desenvolver

workflows com o máximo de tarefas que possam ser realizadas de forma automática, isto é, sem

que necessitem de intervenção humana e que aproveitem ao máximo todos os recursos disponíveis

ou necessários à sua realização para que desta forma o seu rendimento seja maximizado. Alguns

exemplos de tarefas são, por exemplo, a solicitação de férias; compra de produtos ou ,até mesmo,

a definição de certas atividades que um colaborador deve desempenhar no decorrer de um projeto.

2.2.4 Sistema de Gestão de Workflow

O Sistema de Gestão de Workflow é definido como "um sistema que define, gere e executa com-

pletamente workflows, através da execução de software cuja ordem de execução é determinada

por uma representação informática da lógica do workflow". [15]

Estes sistemas têm como principal objetivo o suporte ao trabalho cooperativo, onde se enfatiza

a interação entre utilizadores, e não apenas a interação entre o utilizador e o sistema. Devem

também possibilitar a notificação do utilizador quando alguma tarefa lhe é atribuída, o sistema

também garante que as tarefas seguem a ordem outrora definida.

2.2.5 Funcionalidades de um Sistema de Gestão Workflow

Um Sistema de Gestão Workflow é um conjunto de ferramentas que tem como objetivo o

auxílio ao projeto implementando fluxos de trabalho, workflows, é, assim, responsável pela ins-

tanciação, coordenação e execução controlada das tarefas realizadas pelas diferentes ferramentas

disponíveis dentro do respetivo workflow.

A um nível conceptual, os Sistema de Gestão Workflow devem ser caracterizados como pos-

suindo suporte em 3 áreas funcionais, as quais são, funções de tempo de construção (build-time

functions), funções de controlo do tempo de execução (run-time control functions) e as funções de

interação durante o tempo de execução (run-time interaction functions).

As funções de tempo de construção (build-time functions), estão relacionadas com a definição

informática e, possível, modelação do processo de workflow e das suas atividades constituintes.

As funções de controlo do tempo de execução (run-time control functions), estão relacionadas

com a gestão dos processos de workflow em ambiente operacional e com a sequenciação das

diversas ações que fazer parte de cada processo. Por fim, as funções de interação durante tempo

de execução (run-time interaction functions), tratam da gestão de interação dos Sistema de Gestão

Workflow entre os utilizadores e as aplicações dos sistemas informáticos aquando o processamento

dos vários passos da actividade. [15]

Na Figura 2.3 é possível verificar as diversas relações e as principais funções e as respetivas

àreas funcionais dos Sistema de Gestão Workflow.

Apesar dos workflows estarem mais relacionados com atividades de escritório, muitas das

quais que necessitam de intervenção humana, também podem ser aplicados em outros ambientes



Figura 2.3: Caraterísticas de um Sistema de Gestão Workflow. Retirada de "The Workflow Refe-rence Model" [15]

como, por exemplo, ambientes de produção. Isto torna necessário que as aplicações sejam adap-

tadas de forma a satisfazer certas capacidades funcionais das organizações. Neste contexto, a falta

de standards dá origem a que sejam criadas diversas maneiras de automatizar processos, na pior

das hipóteses incompatíveis entre si.

Para dar resposta a este problema foi criado em Agosto de 1993 o Consórcio de Gestão de

Workflows ou Workflow Management Coalition - WfMC, com vista a identificar as áreas funci-

onais e desenvolver especificações para serem implementadas nos produtos de workflow. Estas

especificações destinam-se a que seja garantida a interoperabilidade entre diferentes produtos de

workflow e a melhorar a integração destes com outras aplicações informáticas, como por exemplo,

o correio eletrónico.

Para melhor percepção deste modelo está identificado na Figura 2.4 um modelo de workflow

padrão, onde é possível identificar os principais componentes funcionais do sistema bem como as

respetivas interfaces de uma arquitetura workflow.

As áreas funcionais são: Ferramentas de Definição de Processos (Process Definition Tools),

Aplicações Clientes de Workflows (Workflow Client Applications), Aplicações Invocadas (Invoked

Applications), Outros Serviços de Execução de Workflow (Other Workflow Enactment Services) e,

por fim, Ferramentas de Administração e Monitorização (Administration & Monitoring Tools).


2.2 Workflow 13

Figura 2.4: Modelo de Referência de um Workflow. Retirada de "The Workflow Reference Mo-del" [15]

As Ferramentas de Definição de Processos (Process Definition Tools), são ferramentas usadas

para criar e alterar as definições de processo; fornecem a capacidade de reutilizar elementos ar-

mazenados num fluxo de trabalho, e até mesmo subprocessos inteiros, desenvolver aplicativos de

fluxo de trabalho mais produtivos, uma vez que não é necessário reinventar a roda na construção

de fluxos de trabalho e integrá-los com outras aplicações. [16] Para que seja possível a comunica-

ção entre estas aplicações e os serviços de execução do workflow o modelo especifica um padrão

de interface para o efeito.

Aplicações Clientes de Workflows (Workflow Client Applications), são aplicações diretamente

correlacionadas com o motor do workflow; estas normalmente implementam funcionalidades bá-

sicas de workflow, tais como notificações e transferências de informação. [15] Para essa interface

foram definidas operações dentro da ideia da WAPI, Workflow API and Interchange Formats. A

WAPI pode ser considerada como um conjunto de construtores, através dos quais os serviços do

sistema de workflow podem ser acedidos, e que quais regulam as interações entre a maquina de

workflow e os outros componentes do sistema. [17]

As Aplicações Invocadas (Invoked Applications) são aplicações externas ao Sistema de Gestão

Workflow como, por exemplo, serviços de fax, correio eletrónico, entre outras aplicações. Para que

estas aplicações possam funcionar em conjunto com o Sistema de Gestão Workflow foram criadas

algumas operações dentro da WAPI, tais como, iniciar, suspender e abortar tarefas.

Na interface 4 é definida para a área funcional, Outros Serviços de Execução de Workflow



(Other Workflow Enactment Services), uma variedade de modelos que podem interagir com pro-

dutos de diversos fabricantes.

Por fim é especificado uma interface comum para as Ferramentas de Administração e Mo-

nitorização (Administration & Monitoring Tools), permitirá que uma mesma aplicação de gestão

tenha a possibilidade de controlar diferentes motores de workflow. O WfMC apresenta métodos

de acesso da WAPI projectados para estas funções de gestão, tais como delegação e suspensão de

privilégios a utilizadores e grupos, entre outras funções. [17]

2.2.6 Constituição de um Workflow

Um workflow é constituído fundamentalmente por atividades, que, por sua vez, pressupõem

actores que as executam. Ao longo da execução do workflow vão sendo gerados e processados do-

cumentos. Há também a existência de rotas que definem os destinos de cada fluxo de informação.

Por fim há as regras, que devem ser respeitadas durante toda a execução das tarefas do fluxo de

trabalho. [18]

ActividadesUma actividade num workflow corresponde à execução de uma tarefa dentro de um processo,

para isso deve ser possível definir no Sistema de Gestão Workflow os dados da actividade, tais

como, o seu nome, objetivos, documentos necessários à sua realização incluíndo as instruções a

serem seguidas durante a sua execução.

ActoresCada actividade deve ter pelo menos um actor responsável pela sua concretização. Esse actor

deve estar registado no Sistema de Gestão Workflow. A associação das atividades ao actor pode ser

realizada aquando da instanciação do workflow. Os actores podem ser utilizadores específicos ou

distinguidos pelos papeis que desempenham. Um papel é uma caracterização do conjunto de atri-

butos e responsabilidades que os utilizadores possuem. Por norma, os utilizadores estão associados

aos papéis que por sua vez estão associados às atividades. Um único utilizador pode desempenhar

vários papéis, bem como o inverso; um papel pode ser representado por vários utilizadores. Os ac-

tores não são necessariamente utilizadores humanos, podendo ser agentes informáticos ou outros

quaisquer dispositivos.

RotasA definição de workflow compreende o encadeamento de atividades, encadeamento este que

pode ser representado por um grafo. De um modo geral num grafo as atividades são representadas

pelos nós dos grafos e os caminhos/rotas representadas por linhas/arestas entre os nós. Depen-

dendo do workflow, as atividades são executadas sequencialmente, paralelamente ou combinando

os dois métodos anteriormente mencionados. Além disto, podem ser adicionadas condições de

execução nas arestas dos grafos.

RegrasA execução de atividades em ambientes organizados pressupõe a aceitação de determinadas

regras pré-estabelecidas. Desta forma é possível garantir que as atividades são executadas de

forma coordenada, mesmo quando executados por mais do que um actor. As regras definem que


2.2 Workflow 15

informações irão transitar por determinado fluxo de trabalho e sob que condições; no fundo, são

atributos que definem de que forma os dados são tratados pelas tarefas ou mesmo encaminha-

dos para atividades distintas no fluxo de trabalho. As regras são definidas no Sistema de Gestão

Workflow durante a modelação do processo.

2.2.7 Categorias de Sistema de Gestão Workflow

Os workflows podem ser classificados como sendo do tipo ad-hoc workflow, workflow de

produção e workflow administrativo. [14]

Os workflows do tipo ad-hoc, caracterizam-se por não existir uma estrutura pré-definida para o

processo e pela possibilidade de alterar ou criar novas regras dos procedimentos durante a execu-

ção do processo, embora exista na mesma prazos de execução, deadlines. Exemplos de aplicações

ad-hoc são por exemplo campanhas de marketing para lançamento de produtos.

Nos workflows de produção a maioria das regras estão definidas logo desde início; são ade-

quados a processos que tenham pouca ou mesmo nenhum intervenção humana, e em que estas,

quando ocorrem, são em pequena escala ou de curta duração. Este tipo de sistema serve para

administrar processos extremamente complexos e fortemente integrados com outros sistemas de

uma organização. Pode ser aperfeiçoado até atingir o nível de qualidade e precisão na execução de

tarefas repetitivas. [19] Um exemplo de tipos de fluxo de trabalho são, por exemplo, os sistemas

de empréstimos dos bancos.

Outro tipo de workflow é o do tipo administrativo; enquadra-se entre o workflow ad-hoc e o

workflow de produção, envolve atividades fracamente estruturadas, repetitivas e previsíveis, de

simples execução. [20] Um exemplo de um processo administrativo será a requisição de férias por

parte de um empregado, em que este submete o pedido para aprovação.

2.2.8 Requisitos Típicos numa Aplicação de Workflow

Tal como descrito em Presenting Windows Workflow Foundation [21], os requisitos típicos

numa aplicação baseada em workflow normalmente são:

• Aptidão para tomar decisões consoante as regras do negócio. Isto inclui regras simples, tais

como decisões tipo sim ou não, baseadas numa caixa de validação e regras mais complexas,

tais como análises de conjuntos de dados para obter uma decisão não definitiva mas perto

da decisão final.

• Formas de comunicar com outras aplicações e outros sistemas externos ao workflow. Por

exemplo, um pedido é recebido por parte de outra aplicação; isto requer comunicações

usando, por exemplo, web-services ou outras tecnologias.

• Métodos de interação com pessoas. Neste caso, um gestor, utilizador, deve aprovar ou vali-

dar algumas decisões. Deve existir uma interface que permita a interação de um utilizador

com a aplicação.



• A possibilidade de manter um estado durante a existência do workflow, especialmente quando

pessoas estão envolvidas. Um workflow pode demorar bastante tempo até que esteja finali-

zado e um utilizador pode ir de férias ou de fim-de-semana. O sistema deve ser escalável de

modo a ter a possibilidade de desactivar um workflow, mantendo o seu estado e depois ter a

capacidade de o reactivar, carregando o seu estado e fluir para o passo seguinte.

2.2.9 Vantagens dos Sistemas de Gestão de Workflows

Os Sistema de Gestão Workflow trazem inúmeras vantagens às organizações; entre todas

podem-se destacar as seguintes:

• Aumento da eficiência dos processos e garantia da sua integridade. Um sistema de workflow

garante que todas as atividades sejam realizadas na ordem prevista e que todas as regras

sejam cumpridas, levando a uma redução de custos e a uma maior capacidade de trabalho;

• Diminuição do tempo de espera entre atividades. Quando um processo é manual, o tempo

decorrido entre o final de uma tarefa e o início da tarefa seguinte pode ser bastante elevado

por envolver alguns passos burocráticos;

• Redução no volume de circulação de papel, havendo apenas uma cópia do documento em

formato eletrónico;

• Descentralização de funções e pessoal, através do acesso à rede a partir de qualquer es-

tação de trabalho. Esta descentralização permite uma maior integração entre as unidades

organizacionais, pois a utilização de um sistema de workflow permite que um processo de

negócio seja executado por participantes de diferentes unidades funcionais de uma mesma

organização de forma transparente;

• Facilidade na distribuição da informação por toda a organização.

Estas vantagens e outras não descritas, mas nem por menos importantes, convergem todas

numa melhoria do serviço prestado ao cliente. [22]

2.3 Enterprise Resource Planning, ERP

Nesta secção será feita uma breve resumo dos conceitos aplicados a um sistema de Enterprise

Resource Planning.

Começando por fazer uma introdução aos sistemas de gestão empresarial (ERP), sendo feita

de seguida uma breve resenha histórica. De seguida é descrita a sua estrutura básica, potenciali-

dades, passos para uma boa implementação e, por fim, os pontos críticos dos sistemas de gestão

empresarial.


2.3 Enterprise Resource Planning, ERP 17

2.3.1 Introdução

As organizações estão em constante evolução/mudança, com constantes integrações e atua-

lizações das suas políticas e processos de produção, de forma a dar resposta aos concorrentes e

aos novos requisitos dos mercados. As tecnologias de informação e processos de reengenharia

empresarial, usadas em conjunto, criaram importantes ferramentas estratégicas. Estas novas ferra-

mentas passaram a equipar as empresas com as capacidades necessárias para integrar e sincronizar

processos isolados, com o intuito de integrar o processo de negócio, de forma a tornarem-se mais

competitivas no mercado atual. Estas ferramentas são intituladas ERP, Enterprise Resource Plan-

ning.

ERP é um conjunto de ferramentas de gestão que permite equilibrar a oferta e a procura,

estabelecendo uma ligação entre clientes e fornecedores numa cadeia de produção, empregando

processos de negócio comprovados para a tomada de decisões, e fornecendo um alto grau de

integração interfuncional entre os diversos departamentos de uma empresa (marketing, produção,

operações, logística, finanças, desenvolvimento de novos produtos e recursos humanos). Com isto

conseguir-se-á que a empresa administre o seu negócio aos mais altos níveis de serviço ao cliente

e produtividade sem aumentar os custos, ou, até mesmo diminuindo-os, fornecendo bases para um

negócio mais lucrativo. [23]

2.3.2 História

No século passado, principalmente a partir da década de 60, as empresas passaram a utilizar

Sistemas de Informação com vista em melhorar o desempenho organizacional num mercado cada

vez mais competitivo.

Estes sistemas têm vindo a evoluir ao longo do tempo, desde o aparecimento, por volta da

década de 70, do MRP, Material Requirements Planning, passando, na década de 80, pelo MRP

II, Manufacturing Resources Planning, até finalmente ao aparecimento, na década de 90, dos ERP,

Enterprise Resource Planning.

Na Figura 2.5 é possível visualizar graficamente a evolução do ERP onde se pode verificar de

que os principais fundamentos surgem do MRP II, Manufacturing Resource Planning, diferindo

dele em alguns aspectos tais como, aplicação de um único conjunto de ferramentas de planea-

mento para toda a empresa, integração em tempo real de todos os departamentos e permitindo

uma aproximação entre consumidores e fornecedores.

O MRP, Material requirements planning, consiste num planeamento das necessidades materi-

ais com vista à otimização da gestão, de forma a minimizar os custos. Os principais objetivos do

MRP são, garantir que os materiais estão disponíveis para produção e os produtos estão disponí-

veis para entrega aos clientes, minimizar as quantidades em armazém, tanto de produtos como de

matérias e planear as atividades de produção tendo em conta os prazos de entrega.

O MRP II, Manufacturing Resource Planning, é basicamente uma expansão do MRP, in-

cluindo funções adicionais de planeamento de negócios, vendas e produção tendo em conta as



capacidades de mão-de-obra e de equipamento. Tem também a capacidade de simulação que per-

mitindo a execução de análises de sensibilidade, ou seja, simular diversos cenários de procura,

capacidade que herdou do Closed-loop MRP.

Figura 2.5: A evolução do ERP. Retirada de "ERP : making it happen : the implementers guide tosuccess with enterprise resource planning" [23]

2.3.3 Estrutura básica de um ERP

Um sistema ERP é a espinha dorsal da gestão da informação do negócio de uma organização.

Permite estabelecer e criar uma metodologia de trabalho segundo o padrão definido para o seu

sistema de informação. Dependendo das aplicações, o ERP pode permitir a gestão de um conjunto

de atividades que viabilizam o acompanhamento dos níveis de fabrico tendo em conta pedidos ou

previsão de vendas. Alguns exemplos destas atividades são, por exemplo, o desenvolvimento de

um produto, compra de matéria-prima, interação com clientes e fornecedores, gestão de stocks,

gestão contabilística e financeira, entre outros. Na Figura 2.6 está ilustrada uma estrutura típica de

um sistema ERP.

2.3.4 Potencialidades de um Sistema ERP

Um sistema ERP possui inúmeras potencialidades, sendo algumas das mais importantes:

• execução de tarefas críticas de uma empresa, aumentando a qualidade dos serviços prestados

aos clientes;

• facilidade na troca de informação em ambientes distribuídos;

• integração a de informação dos vários departamentos, escritórios, fábricas de uma empresa

bem como das várias empresas pertencentes a um grupo financeiro;



Figura 2.6: Estrutura típica de um ERP. Retirado de "Putting the enterprise into the enterprisesystem" [24]

• melhoria de eficiência na gestão de projetos;

• ajuste fácil a novas inovações tecnológicas;

• resolução de muitos dos comuns problemas numa empresa: gestão de produtos em arma-

zém, serviços a clientes, gestão financeira, controlo de qualidade, entre outros;

• acompanhamento das necessidades de uma empresa à constante evolução do mercado;

• fornecimento de ferramentas inteligentes, como por exemplo, ferramentas de suporte à de-

cisão, informação executiva, permitindo maior facilidade na tomada de decisões. [25]

2.3.5 Implementação de um Sistema ERP

Os sistemas ERP são parametrizados de formas distintas, de acordo com as caraterísticas de

cada empresa e o ramo em que esta está inserida. Para flexibilizar este facto, os sistemas ERP

foram desenvolvidos de modo a apresentar uma solução genérica, que possa ser parametrizada

em certo grau, sem esquecer que esta parametrização acaba por ser um compromisso entre os

requisitos da empresa e as funcionalidades oferecidas pelo sistema. Desta forma, é necessário

que alguns processos de negócio das empresas sejam redefinidos para que os seus requisitos se

enquadrem nas funcionalidades oferecidas pelo sistema.



Um software ERP típico é composto por módulos que poderão ser instalados separadamente;

em casos extremos existem módulos que dependem de outros. A primeira medida a tomar no pro-

cesso de instalação é a selecção dos módulos que serão instalados numa primeira fase. Contudo,

é possível que posteriormente sejam integrados novos módulos. De seguida, cada módulo insta-

lado é parametrizado para que se adeque da melhor forma ao processo de negócio da empresa.

No entanto, mesmo com uma parametrização específica, a solução final poderá não correspon-

der aos requisitos da empresa e, nesses casos, as empresas necessitam de utilizar outros sistemas

complementares ou optar pela utilização de processos genéricos. Por este motivo, a decisão de im-

plementar um sistema ERP só deverá ser tomada no seguimento de uma análise aprofundada dos

processos da empresa e das funcionalidades oferecidas pelas soluções do sistema em questão. [25]

No artigo "Sistemas ERP: caraterísticas, custos e tendências”, [26], são descritos dez fatores

considerados fulcrais para a boa implementação de um sistema ERP numa empresa:

• garantir uma participação activa por parte da gerência (Commitment);

• implementar uma gestão de mudança procurando reduzir a insegurança dos utilizadores

menos informados;

• identificar os administradores, que são utilizadores indispensáveis nos respetivos departa-

mentos;

• escolher um gestor de projeto, que deve ser um profissional experiente e respeitado, de

modo a descaracterizar o ERP como um sistema da área de Informática, e sim como uma

ferramenta de apoio gestão;

• planear a realização de testes ao sistema e formações aos utilizadores;

• definir claramente os diversos papéis na implementação do sistema, através da união de

conhecimentos e esforços para que se alcance com sucesso o objetivo desejado;

• adaptar o sistema à empresa e vice-versa, reflectindo sobre a realidade atual da empresa ou

a utilização das melhores práticas;

• escolher a consultoria adequada, ou seja, consultores que demonstrem ter o "saber-fazer"(know-

how) necessário à implementação a efetuar;

• garantir a qualidade dos produtos da empresa (Quality Assurance);

• simplificar em todos os sentidos: na definição de modelos, no desenho da solução e na

própria implementação do sistema.

2.3.6 Pontos Críticos de um Sistema ERP

Alguns pontos e caraterísticas importantes dos sistemas ERP devem ser cuidadosamente ana-

lisados no momento em que se decide implantar um sistema do género. De acordo com o artigo



"Sistemas ERP: caraterísticas, custos e tendências” [26], existe um conjunto de fatores críticos a

ter em conta num sistema ERP:

• são aplicações comerciais desenvolvidas a partir de modelos de processos padrão, que não

são específicos para determinadas necessidades, mas sim genéricos, podendo a empresa

onde o ERP será implementado adequar-se ou não a eles. Davenport [24] afirma que "é

o fornecedor que define o que é melhor, e não o cliente. Contudo, em alguns casos, as

definições do sistema podem atender aos objetivos da empresa".

• integram todas as áreas da empresa, sendo uma vantagem a utilização destas ferramentas.

A empresa obtém integridade e confiabilidade nas informações adquiridas através do sis-

tema, pois a entrada de um dado ocorre uma única vez; a partir de então, passa a atualizar

automaticamente todos os módulos necessários;

• permitem a adequação das funcionalidades existentes no sistema às da empresa, através

do processo de parametrização. Este processo consiste na definição de diversos valores

que são introduzidos no sistema, com o intuito de dimensionar o perfil da empresa e o

comportamento do sistema;

• eles possibilitam a personalização de determinados processos de software que não se adap-

tam à empresa, mesmo usando a parametrização. A personalização é a adaptação do sistema

às necessidades específicas da empresa, sendo necessário intervir com programas ou roti-

nas que se integram com ERP. Muitas atividades da empresa não são contempladas pelo

sistema, não bastando apenas configurá-lo através de parâmetros. Esta etapa nem sempre é

realizada pela empresa que desenvolve o ERP, e muitas vezes uma consultoria homologada

e conhecedora da solução é contratada para este fim;

• possuem custos elevados, destacando-se os custos de hardware e infraestrutura computacio-

nal, de aquisição da licença de uso do ERP, e de consultoria para a implantação. Um sistema

ERP apresenta muitas complexidades, sendo que a sua implementação deverá ser realizada

por profissionais que conheçam, não somente o negócio da empresa, como também a solu-

ção escolhida. Geralmente, as empresas optam por contratar consultores especializados no

produto escolhido. Também os utilizadores dos vários departamentos deverão passar por um

período no qual os esforços serão duplicados, uma vez que o trabalho deverá ser realizado

paralelamente no sistema antigo, mesmo que manual, e no novo.

• os fornecedores de sistemas ERP disponibilizam periodicamente atualizações que congre-

gam melhorias, correções de problemas e de erros do sistema. Este processo de atualização

deve ser flexível e permitir a adequação da nova versão com possíveis personalizações efe-

tuadas no produto.

• os sistemas ERP forçam, na maioria das vezes, alterações nos processos produtivos e admi-

nistrativos, pois é necessário tanto a adaptação do sistema aos processos da empresa, como



a adaptação da empresa a determinados processos do sistema. Estas alterações são comple-

xas e podem causar, no início, uma série de inconvenientes até que todos estejam adaptados

à nova realidade. É importante realçar também que estas alterações de processos devem

estar em conformidade com as estratégias da empresa e os seus objetivos de longo prazo,

merecendo, portanto, grandes cuidados em sua implementação.

• o ERP tem impacto sobre os recursos humanos da empresa, pois as pessoas terão que se

preocupar com o processo como um todo e não apenas com a sua actividade específica.

Devido à integração do sistema, um problema de uma área poderá refletir-se rapidamente

noutros departamentos, existindo o risco de chegar a afetar toda a empresa. O perfil dos

profissionais muitas vezes será alterado, uma vez que se exigirá multidisciplinariedade e

conhecimentos que nem sempre os atuais funcionários possuem. A empresa deverá optar

por reciclar os seus profissionais ou, em alguns casos, substituí-los. Esta última alternativa é

reforçada também pelo facto de que a partir da automação e, mais do que isso, da integração

entre os processos, muitas atividades que eram realizadas manualmente, no sistema anterior,

não serão mais necessárias. Muitas vezes, pode ocorrer resistência interna à adoção do ERP,

devido à desconfiança de perda de emprego ou de poder, uma vez que haverá maior partilha

da informação.

• os sistemas ERP apresentam dificuldades no cumprimento de prazos de instalação e orça-

mentos, devido a: resistência por parte das pessoas; rotatividade dos funcionários que foram

treinados no novo sistema ou que dominam o negócio da empresa; qualidade dos recursos

humanos internos e da equipa de consultoria contratada; limitações inerentes ao próprio pro-

duto ERP escolhido e dificuldade de integrar o ERP com outros sistemas existentes dentro

da empresa. Todos estes fatores não podem ser corretamente previstos com antecedência

no momento de elaboração dos cronogramas e orçamentos, e, por mais que se possa inserir

margens de segurança, eles podem comprometer a credibilidade do projeto.

2.4 Tecnologias

Nesta secção será dada uma breve descrição das ferramentas a utilizar no desenvolvimento

deste trabalho.

2.4.1 Python

Python é uma linguagem de programação de alto nível com semântica dinâmica, cuja filosofia

é facilitar a leitura do código mantendo um grande poder de programação, lançada em 1991 por

Guido van Rossum.

É uma linguagem de código aberto, sendo possível utilizar ou distribuir, mesmo que seja para

uso comercial. Corre na maioria dos sistemas operativos, tipicamente é implementado sobre a

linguagem de programação C, também conhecido por CPython, em versões .NET, conhecido por

IronPython e em máquinas virtuais Java (JVM) conhecido por Jython.


2.4 Tecnologias 23

É utilizada frequentemente como uma linguagem de script, suporta vários paradigmas da pro-

gramação como, por exemplo, orientação a objetos, programação imperativa e funcional.

Python contribui para um grande aumento da produtividade pois não existe fase de compilação,

acelerando a etapa de “edição-teste-depuração”. Além disso a fase de depuração é fácil, pois um

erro ou uma sintaxe errada nunca causa “segmentation-fault”, em vez disso quando o interpretador

descobre um erro lança uma exceção que, se não for capturada, pelo programa, dá origem a uma

impressão da pilha de chamadas. Um depurador ao nível de código fonte permite a inspeção de

variáveis locais e globais, avaliação de expressões arbitrárias, ajuste de interrupções, etc. Por

outro lado, a maneira mais rápida de depurar um programa é declarar expressões de impressão de

variáveis ao código, uma vez que a fase de “edição-teste-depuração” torna esta abordagem simples

e rápida. [27]

2.4.2 PHP, Hypertext Preprocessor

PHP, Hypertext Preprocessor, é uma linguagem de scripting de de uso livre utilizada básica

para gerar conteúdo dinâmico na Web. Foi uma das primeiras linguagens de scripting desenvolvi-

das que correm do lado do servidor e não do lado cliente, ou seja, o servidor interpreta do código

PHP que por fim gera a página web resultante.

Como descrito no livro “PHP: a beginner’s guide” [28], o PHP apresenta algumas caraterísti-

cas consideradas únicas a esta linguagem:

• Performance – os scripts escritos em PHP são mais rápidos que outros escritos noutras

linguagens de scripting;

• Portabilidade – o PHP está disponível para UNIX, Microsoft Windows, Mac OS e OS/2,

sendo que os scripts são executados independentemente da plataforma;

• Fácil utilização – apresenta uma sintaxe limpa e consistente, oferecendo também uma vasta

documentação, reduzindo assim a curva de aprendizagem;

• Código aberto – é uma linguagem desenvolvida por uma equipa de voluntários de todo o

mundo, estando o código fonte disponível na Web;

• Suporte em comunidade – o lado bom das linguagens que usufruem do suporte em comu-

nidade é a criatividade e imaginação de milhares de utilizadores pelo mundo inteiro;

• Suporte para outras aplicações – o PHP suporta outros tipos de aplicações como por

exemplo, interações com múltiplas base de dados, interação com diversos protocolos, POP3,

SMTP.

2.4.3 HTTP/HTTPS

HTTP ou Hypertext Transfer Protocol é um protocolo de comunicação, que se situa na camada

de aplicação segundo o modelo OSI, utilizado para a comunicação entre sistemas de informação



distribuída ou colaborativa. O desenvolvimento dos standards do protocolo foi coordenado pelo

IETF2, e pelo W3C3, culminando na publicação de vários RFCs, distinguindo-se o RFC2616, que

define a versão do protocolo HTTP em uso. [29]

HTTPS ou Hypertext Transfer Protocol secure é uma implementação do protocolo HTTP so-

bre a camada SSL, Secure Sockets Layer, ou TLS, Transport Layer Security. Esta camada adici-

onal garante que os dados são transportados através de uma ligação segura, cifrada, e garantindo

também a autenticidade dos dados através de certificados digitais. [30]

2.4.4 XML

O XML, eXtensible Markup Language, é considerado uma meta-markup language, uma lin-

guagem de anotação descritiva extensível, oferecendo todas as caraterísticas que tornam desejável

este tipo de linguagens: independência relativamente às plataformas de software e de hardware

utilizadas, longevidade, custos de manutenção reduzidos e fácil utilização. É uma linguagem que

disponibiliza um formato para a descrição de dados estruturados proposta pelo W3C, World Wide

Web Consortium.

O XML é uma metalinguagem que em qualquer momento permite acrescentar novos elemen-

tos à linguagem, o que torna esta linguagem, aberta e sem limitações do ponto de vista de extensi-

bilidade. [31]

Esta descente do SGML, Standard Generalized Markup Language, que foi o primeiro standard

de linguagens de notação de texto e o seu objetivo era normalizar a produção de documentos.

Os documentos XML têm uma estrutura lógica em forma de árvore, ou seja, existem sempre

um elemento que contém outros, como é possível ver na Figura 2.7.

À semelhança do HTML o XML permite a definição de tags ou delimitadores, que carac-

terizam os dados e a sua formatação. É possível criar um conjunto de tags de modo a obter a

formatação de um determinado conjunto de informação. Cada elemento, ou conjuntos de ele-

mentos, está relacionado e estruturado numa lógica de árvore ou hierarquia com dependências e

ramificações. Uma folha da árvore será o elemento que poderá conter dados, no caso do exemplo

da Figura 2.7, uma folha é por exemplo o “Título” da “Receita”. Com o XML pode-se criar uma

estrutura para um documento de texto, um registo de uma base de dados estruturado, entre muitos

outros exemplos, o XML oferece esta flexibilidade.

Na Figura 2.8 é possível analisar um exemplo de um documento XML com a mesma estrutura

da árvore apresentada na Figura 2.7.

Segundo é descrito em "Bases de Dados Web e XML" [32], o XML apresente inúmeras vanta-

gens, podendo-se destacar as seguintes:

• O XML é extensível, a possibilidade de criação de tags de um modo arbitrário (respeitando

sempre as regras de aninhamento), permite adaptar a estrutura de um documento XML a

praticamente qualquer situação por mais específica que seja;

2Internet Engineering Task Force3World Wide Web Consortium


2.4 Tecnologias 25

Figura 2.7: Estrutura em árvore de um documento XML.

Figura 2.8: Exemplo de documento XML com a estrutura da Figura 2.7.

• Os documentos XML são auto descritivos, ou seja, são relativamente fáceis de interpretar,

manipular e interrogar.



• Apesar da sua simplicidade, o XML permite criar estruturas bastante complexas (árvores ou

grafos de profundidade arbitrária e, eventualmente, cíclicos e recursivos);

• O XML é extremamente flexível, possibilitando a representação, quer de dados estruturados,

quer de dados semiestruturados;

• Recorrendo à definição de um esquema, é possível efetuar a validação de documentos.

• Esta característica revela-se de extrema importância para aplicações em que a verificação

estrutural de dados seja vital, como é o caso das bases de dados convencionais;

• O conteúdo de um documento XML pode ser facilmente manipulado pelas aplicações de

software (recorrendo a API’s existentes), o que torna possível atingir níveis de automação

bastante elevados;

• Uma vez que o XML tem uma natureza metalinguística, as organizações podem utilizá-la

para desenvolver padrões específicos (novas linguagens baseadas em XML, definindo es-

quemas comuns, de modo a trocarem eficientemente dados entre si. Estes esquemas podem

ser disponibilizados publicamente na web. O objetivo é utilizar o XML para a troca de dados

entre os sistemas de informação organizacionais;

• O XML é um padrão aberto. Os documentos XML são independentes das aplicações, dos

sistemas operativos, entre outros. Esta característica é muito importante na integração de

sistemas heterogéneos;

2.4.5 XML-RPC

O XML-RPC é uma especificação e um conjunto de implementações que permite que progra-

mas em sistemas operativos diferentes, utilizando diferentes ambientes, possam colaborar fazendo

chamadas de procedimentos através da Internet.

É um protocolo de chamada de procedimento remoto (RPC) que utiliza XML para codificar as

chamadas e HTTP como mecanismo de transporte. Este foi projetado para ser o mais simples pos-

sível permitindo a transmissão, processamento e resposta de estruturas de dados complexas. [33]

Uma chamada XML-RPC é realizada entre duas partes, o cliente (o processo de chamada) e

o servidor (o processo chamado). Um servidor é disponibilizado em uma determinada URL (por

exemplo, http://example.org:8080/rpcserv/4): Para utilizar os procedimentos disponi-

bilizados pelo servidor são seguidas a seguintes etapas:

1. O programa cliente faz uma chamada de procedimento usando um cliente XML-RPC, espe-

cificando um nome de método, parâmetros e um servidor de destino.

2. O cliente XML-RPC coloca o nome do método e os parâmetros numa estrutura XML, de

seguida emite um pedido HTTP através do método POST, este contendo as informações,

para o servidor de destino.4Um servidor HTTP a responder no porto 8080, cujo o endereço da máquina é example.org


http://example.org:8080/rpcserv/

2.4 Tecnologias 27

Figura 2.9: Arquitetura do XML-RPC. [33]

3. Um serviço HTTP no servidor de destino recebe o pedido e passa o conteúdo XML desta

para um ouvinte (listener) de XML-RPC.

4. O ouvinte XML-RPC analisa o XML para obter o nome do método e os parâmetros e chama

o método apropriado, passando os parâmetros.

5. O método retorna uma resposta ao processo de XML-RPC e este de seguida processa a

resposta como XML.

6. O servidor web retorna esse XML como a resposta ao pedido.

7. O cliente XML-RPC analisa o XML para extrair o valor de retorno e então passa o valor de

retorno de volta para o programa cliente.

8. O programa cliente continua o processamento com o valor de retorno.

O uso do protocolo HTTP para comunicação significa que os pedidos XML-RPC devem ser

síncronos, ou seja, um pedido XML-RPC é sempre seguido exatamente de uma resposta XML-

RPC e stateless, significa que nenhum contexto é preservado de um pedido para outro, ou seja, se

um cliente invoca um método e de seguida volta a invoca-lo, o XML-RPC trata os dois pedidos

como pedidos isolados. [34]

Uma invocação de um método remoto é acompanhada por dados na forma de parâmetros, e a

resposta a esse método contém dados como um valor de retorno. Apesar de um pedido pode conter

vários parâmetros, a resposta deve conter exatamente um valor de retorno. Para representar esses

valores, o XML-RPC define uma representação XML para os dados. Os tipos básicos definidos

por este são os seguintes:

• Integer – valores inteiros, representados pela notação <i4> ou <int>. Exemplo: <i4>2</i4>,

<int>2</int>;



• Double – valores não inteiros, ou seja, de dupla precisão com virgula flutuante, representa-

dos pela notação <double>. Exemplo: <double>2.0</double>;

• Boolean – valores booleanos, lógicos, 0 ou 1, representados pela notação <bolean>.

Exemplo: <bolean>1</bolean>;

• String – sequências de caracteres, representados pela notação <string>. Exemplo: <string>Hello,

World!</string>;

• Date-time – data e hora segundo a norma ISO 86015, representados pela notação <dateTime.iso8601>.

Exemplo: <dateTime.iso8601>19980717T14:08:55</ dateTime.iso8601>;

• Binary – dados binários codificados em base646, representados pela notação <base64>.

Exemplo: <base64>eW91IGNhbid0IHJlYWQgdGhpcyE=</base64>;

• Array – conjunto de valores, estes podem conter valores de outros tipos, representados pela

notação <array>. Exemplo: <array><data><value><string>Hello, World!</string></value></data></array>;

• Struct – estrutura de dados, também conhecido por vector associativo, estes tipo de da-

dos são compostos por um conjunto de membros, representados pela notação <struct>.

Exemplo: <struct><member><name>Foo</name><int>1</int></member></struct>. [34]

Na Figura 2.10 é possível ver um exemplo de uma pergunta feita por um cliente a um servidor

XML-RPC, sendo possível ver na Figura 2.11 uma resposta, em caso de sucesso, do servidor à

pergunta anteriormente feita.

Figura 2.10: Exemplo de pergunta XML-RPC.

2.4.6 NET-RPC

O NET-RPC é um protocolo de chamada de procedimento remoto (RPC) baseado no módulo

cPickle do Python sendo este relativamente mais rápido que o XML-RPC. [35]

5Norma internacional para representação de data e hora emitida pela Organização Internacional para Padronização(International Organization for Standardization, ISO)

6Método para codificação de dados para transferência na Internet


2.4 Tecnologias 29

Figura 2.11: Exemplo de resposta XML-RPC.

2.4.7 SOAP

O SOAP, Simple Object Access Protocol, é um protocolo de comunicação entre aplicações,

independentemente do sistema operativo ou da linguagem de programação utilizada nestas.

Em termos históricos o SOAP é o sucessor do XML-RPC, tendo-se tornado uma recomenda-

ção do W3C7 a 24 de Junho de 2003. [36]

Para a comunicação entre as aplicações a informação é estruturada sob a forma de um docu-

mento XML, esse documento é constituído por um envelope (envelope), um cabeçalho (header),

opcional e um corpo (body) como é possível verificar na Figura 2.12.

Figura 2.12: Estrutura de uma mensagem SOAP. Retirado de "Programming Web services withSOAP" [37]

O SOAP define também um padrão chamado WSDL8, Web Services Description Language,

que descreve de forma precisa os objetos e métodos disponíveis, através de páginas XML aces-

síveis através da Web. Basicamente, quando o cliente deseja enviar uma mensagem para um

determinado Web Service, ele obtém a descrição do serviço, através da localização do respetivo

7World Wide Web Consortium8É uma especificação desenvolvida pelo W3C que permite descrever os Web Services segundo um formato XML.



documento WSDL, e de seguida constrói a mensagem, passando os tipos de dados corretos de

acordo com a definição encontrada no documento.

Na maioria das situações o HTTP é utilizado como protocolo de transporte, contudo a men-

sagens SOAP podem "viajar"segundo outros protocolos de comunicação, como por exemplo o

SMTP, Simple Mail Transfer Protocol.

2.4.8 PostgreSQL

PostgreSQL é um sistema de gestão de base de dados de código aberto que conta com mais

de quinze anos de desenvolvimento, tendo sido lançada a primeira versão (0.0.1) a 1 de Maio de

1995,tornando-o numa arquitetura com resultados comprovados de grande fiabilidade garantindo a

integridade e exatidão dos dados. Como se trata de um software de código aberto, pode ser usado,

distribuído ou mesmo modificado de acordo com os desejos de cada utilizador tendo garantido o

apoio por parte de uma grande comunidade de colaboradores. Neste momento é possível utili-

zar o PostgreSQL na maioria dos sistemas operativos. Este fornece diversos recursos como, por

exemplo, consultas complexas, garantia da integridade dos dados, triggers, vistas, procedimentos

armazenados, heranças singulares ou de múltiplas tabelas; também oferece suporte para objetos

de grande dimensão como por exemplo imagens ou vídeos. [38]

O PostgreSQL é amplamente considerado o sistema de base de dados de código aberto mais

avançado do mundo. Oferecendo caraterísticas que normalmente só são encontradas em base de

dados comerciais, tais como DB29 ou Oracle10. Sendo algumas dessas caraterísticas as seguin-

tes [39]:

• aborda os dados com um modelo do tipo objeto relacional, sendo capaz de lidar com rotinas

complexas e regras. Alguns exemplos das suas funcionalidades avançadas são consultas

SQL declarativas, controlo de concorrência multi-versão, suporte multi-utilizadores, transa-

ções, otimização de consultas, herança e matrizes;

• extensível; o PostgreSQL suporta operadores, funções, métodos de acesso e tipos de dados

definidos pelo utilizador;

• abrangente; suporta a especificação SQL:199911 bem como outras caraterísticas avançadas

como, por exemplo, a operação JOIN criada na especificação SQL-9212;

• suporta integridade referencial, usada para garantir a validade dos dados na base de dados;

• API flexível, a flexibilidade da API do PostgreSQL tem permitido que os fornecedores forne-

çam facilmente suporte ao desenvolvimento do PostgreSQL RDBMS, Relational Database

Management System;

9Sistema gestão de base de dados desenvolvida pela IBM10Sistema de gestão de base de dados desenvolvida pela Oracle Corporation11Standard SQL, também conhecido como SQL3.12Terceira revisão do Standard SQL.


2.4 Tecnologias 31

• tem suporte para linguagens processuais, sendo a linguagem nativa o PL/pgSQL,outra van-

tagem é a possibilidade de utilização das linguagens Perl, Python ou TCL (Tool Command

Language) como linguagens processuais embebidas;

• MVCC, Multi-Version Concurrency Control, é a tecnologia que o PostgreSQL utiliza para

evitar o bloqueio da base de dados desnecessariamente. Noutra base de dados como, por

exemplo, o MySQL13 ou o Access14, um utilizador que pretenda fazer uma leitura tem de

esperar primeiro que o utilizador que está a escrever acabe;

• o PostgreSQL utiliza uma arquitetura do tipo cliente/servidor. Para gerir as ligações existe

um processo mestre que se bifurca para criar novas ligações;

• oferece a funcionalidade de Write Ahead Logging, aumenta a fiabilidade da base de dados

registando as alterações antes de estas serem escritas na base de dados. Esta funcionalidade

garante que, caso ocorra uma falha da base de dados, há um registro das transações efetuadas

para que seja possível restaurar a base de dados.

2.4.9 Lightweight Directory Access Protocol - LDAP

Lightweight Directory Access Protocol, LDAP, tal como o nome indica, é um protocolo utili-

zado para atualizar e aceder a diretórios de informação. Diretórios de informação são uma estru-

tura de armazenamento organizada de forma hierárquica, que facilita o armazenamento e busca de

informações.

Este serviço é usado para armazenar todos os dados da rede como, por exemplo, palavras-

passe, nomes de utilizadores (usernames), nomes, endereços, entre outros, sendo considerada

umas das principais funcionalidades do LDAP a capacidade de oferecer autenticação dos utiliza-

dores em diversas aplicações recorrendo à sua base de dados. [40]

2.4.10 GTK+

GTK+ é uma ferramenta multiplataforma para a criação de interfaces gráficas. Foi inicial-

mente desenvolvida para o GIMP15, ficando com o nome “GIMP Toolkit”. É uma aplicação de

código aberto escrito na linguagem de programação C mas desenhada para poder ser ligada a

código de outras linguagens. [41]

2.4.11 PyGTK

PyGTK é uma biblioteca que contém um conjunto de ligações, entre o GTK+ e a lingua-

gem de programação Python. Oferecendo um conjunto completo de elementos gráficos e outras

facilidades de programação, como a manipulação de texto internacionalizado. É um software

13Sistema de Gestão de base de dados desenvolvido pela Oracle Corporation14Sistema de Gestão de base de dados desenvolvido pela Microsoft15Programa de edição gráfica



multiplataforma de código aberto. A sua grande vantagem é que oferece um ótimo desempenho,

fornecendo também elementos ricos e agradáveis à vista. [42]


Capítulo 3

Plataformas Tecnológicas

Neste capítulo será feita uma descrição das plataformas tecnológicas utilizadas no desenvolvi-

mento deste projeto. São também descritas outras opções tecnológicas semelhantes às desenvol-

vidas.

3.1 iPortalDoc

O iPortalDoc é um Sistema de Gestão Documental e Workflow para empresas e instituições,

que permite aos seus utilizadores a gestão dos fluxos dos documentos como também, simples-

mente, proceder ao seu arquivo para posterior gestão. Para um bom funcionamento do sistema, é

vital que este seja bem organizado. Este sistema de gestão de documentação encara a informação

digital como um substituto do papel, e não uma tecnologia adjacente. [43]

Algumas das caraterísticas mais importantes do iPortalDoc são, a facilidade de utilização,

formação reduzida, integração no ambiente de trabalho dos utilizadores, redução drástica de do-

cumentação em papel, e controlo de processos com utilização de workflows, segurança, no acesso

e ações sobre documentos.

3.1.1 Arquitetura

O iPortalDoc funciona em conjunto com o sistema operativo IPBrick , dele utilizando um con-

junto de serviços. Como pode ser observado na Figura 3.1 o iPortalDoc necessita de um sistema

de gestão de base de dados de suporte ao sistema de ficheiros, para armazenar os documentos.

Além disto, está integrado com um servidor web, um servidor de correio eletrónico, servidor de

ficheiros e um servidor de informação e gestão de domínios.

É na interface de configuração da IPBrick que é feita a gestão dos utilizadores do iPortalDoc ,

bem como dos grupos aos quais eles pertencem. Também é aí que serão geridos os dados das

entidades, através da aplicação IPContactos , e respetivos contactos com as quais a instituição

interage, e que também são necessários durante a actividade no iPortalDoc .

33

34 Plataformas Tecnológicas

Figura 3.1: Arquitetura do iPortalDoc .

Para além dos componentes básicos acima referidos, o iPortalDoc trabalha com um servidor

web (HTTP), um servidor de correio eletrónico próprio (SMTP, Simple Mail Transfer Protocol –

POP3, Post Office Protocol / IMAP, Internet Message Access Protocol), um servidor de fichei-

ros (SMB, Server Message Block) e um servidor de informação e gestão de domínios (LDAP,

Lightweight Directory Access Protocol). Está ainda coordenado com os serviços de gestão de no-

mes lógicos (DNS, Domain Name System) e atribuição de endereços IP às estações de trabalho

(DHCP, Dynamic Host Configuration Protocol), entre outros.

3.1.2 Segurança

Ao nível de acessos à aplicação iPortalDoc como um serviço de rede de comunicações que

é, está diretamente ligada à segurança existente para os utilizadores da Intranet1, ou seja, com

recurso ao serviço de diretório (Active Directory) da IPBrick ou outro qualquer presente na rede.

Ao nível de gestão documental, a segurança está associada aos perfis de utilizadores definidos

pelo administrador, aos estados do fluxo de trabalho e utilizadores associados a este. Por exemplo,

enquanto o fluxo não termina, só os utilizadores que participam no fluxo é que têm acesso ao

documento, de acordo com o perfil e ações que podem executar no documento. Em resumo, esta

visão da segurança avançada tem portanto três níveis:

• segurança de rede (autenticação de acessos através de qualquer interface de comunicações);

• perfil de utilização no gestor (gestão dos acessos aos documentos);

• presença no fluxo e ações disponíveis (controlo das ações a executar sobre os documentos).

1Rede de computadores privada.


3.1 iPortalDoc 35

Os perfis podem ser definidos e adaptados de acordo com os requisitos de cada organização,

através da combinação de um conjunto de permissões: criação, leitura, exclusão para documentos,

secções e documentos na secção. De realçar a possibilidade dos documentos poderem herdar as

permissões gerais dos documentos na secção; isto é essencial para aumentar o desempenho do

sistema em secções com milhares de documentos.

Outro ponto de interesse em relação à segurança é a possibilidade de integração do iPortalDoc

e da IPBrick com sistemas de autenticação biométricos, tal permite que o acesso ao gestor docu-

mental possa ser controlado através da impressão digital do utilizador, há ainda a possibilidade de

definir ações de aprovação de documentos mediante autenticação biométrica.

3.1.3 Permissões

Os documentos no iPortalDoc são armazenados segundo uma estrutura hierárquica. A hierar-

quia tem uma diretoria raiz e, dentro desta, podem ser criadas outras diretorias e assim sucessi-

vamente. Esta organização de diretorias é configurada de acordo com a necessidade da entidade

utilizadora e, desta forma, pode manter todos os documentos organizados. A árvore de direto-

rias é sempre apresentada ao utilizador, que a pode, assim, navegar facilmente. A hierarquia é

apresentada de forma personalizada, isto é, acordo com as permissões de cada utilizador.

Após o utilizador se autenticar no sistema, são-lhe concedidas diferentes permissões, depen-

dendo do perfil lhe está atribuído em cada diretoria.

Existe um conjunto de perfis pré-definidos [43]:

• Administrador (Super User) - um utilizador ao qual está atribuído um perfil com permissões

totais sobre todas as funcionalidades do sistema. O administrador pode, entre outros, con-

figurar e alterar os workflows, criar, remover, ou alterar grupos de utilizadores; introduzir,

alterar ou remover dados de um utilizador do sistema; criar, remover ou alterar perfis;

• Coordenador - um utilizador que disponha de um perfil que lhe permita efetuar todas as

operações numa determinada diretoria (criar, alterar, remover documentos/diretorias), é re-

ferido como sendo o Coordenador desta. O coordenador pode associar perfis e workflows

a utilizadores, na diretoria que coordena. Um utilizador que apresente este perfil, pode

visualizar todos os documentos, independentemente do seu estado no workflow;

• Sub-Coordenador - um utilizador que dispõe deste perfil tem permissão para efetuar todas

as operações com exceção de apagar diretorias. Um Sub-Coordenador pode associar perfis

e workflows, na diretoria que coordena;

• Leitor Absoluto - Um utilizador que possua este perfil tem permissão para ler todos os

documentos das diretorias existentes no sistema, mesmo que não tenha neles intervenção.

No entanto, não lhe é permitido criar, alterar ou remover documentos ou diretorias;

• Editor - para além das permissões associadas a um Leitor, este ainda pode inserir documen-

tos;



• Navegador - tem apenas permissão para ver as diretorias, não podendo criar nem apagar.

Não tem qualquer ação sobre os documentos.

Cada utilizador pode ter perfis distintos, dependendo da diretoria, ou seja, um utilizador numa

diretoria pode ser Coordenador e noutra apenas Leitor. O facto de serem atribuídos perfis nas

diretorias existentes, permite gerir o acesso aos documentos existentes nessas mesmas diretorias.

Além destes perfis pré-definidos há a possibilidade de criar novos com diferentes permissões.

Em cada diretoria são associados utilizadores com o tipo de perfil pretendido. É possível asso-

ciar um grupo de utilizadores à diretoria ou então fazer a associação individual de cada utilizador.

As diretorias possuem utilizadores associados, sendo que em cada uma, os utilizadores podem

ter um conjunto de tipos de documentos associados. A associação do tipo de documento ao utiliza-

dor nessa diretoria pode ser aplicada pelas restantes subdiretorias, ou seja, os tipos de documentos

associados à diretoria raiz são aplicados recursivamente por todas as suas diretorias.

Cada utilizador pode ter associado vários workflows, ou nenhum, dependendo do seu perfil

nessa diretoria. Por exemplo, se for associado um utilizador com o perfil Leitor Absoluto, não será

possível associar workflows ao utilizador para essa diretoria, uma vez que nesta situação o utiliza-

dor poderá ler documentos mas não pode neles efetuar operações. Como acontece na associação

de tipos de documentos, quando é efetuada a associação, pode ser efetuada a um grupo de utiliza-

dores ou então individualmente. A associação também pode ser recursiva pelas subdiretorias.

3.1.4 Tipos de Documentos

O tipo de documento é uma informação que aparece sempre que o utilizador introduzir um

documento no iPortalDoc , sendo esta uma característica importante de classificação para os do-

cumentos introduzidos no Sistema de Gestão Documental e Workflow. O utilizador ao aceder a

esta funcionalidade pode criar, alterar ou remover tipos de documentos desde que no formulário

de criação de tipos de documentos sejam especificados um conjunto de campos:

• Descrição - descrição tipo do documento;

• Sigla - sigla associada ao tipo de documento;

• Código - esta opção permite definir como irá ser efetuada a gestão dos códigos do tipo de

documento, sendo que o utilizador pode configurar o código como entender de acordo com

um conjunto opções disponíveis;

• Modelo de geração automática - nesta opção, permite ao utilizador indicar qual o formu-

lário que está associado a este tipo de documento, ou então indicando que o documento é

carregado através da rede para o sistema;

• Permissão - Tipo Doc. - esta opção, quando selecionada, permite alterar o tipo de docu-

mento e código atribuído a um documento já inserido;


3.1 iPortalDoc 37

• Permissão - Info - permite definir a possibilidade de alterar a informação de classificação

do documento no decorrer do workflow;

• Alterar informação - permite definir a possibilidade da informação do documento ser alte-

rada;

• Tipo Registo - esta opção define que o documento nunca poderá ser actualizado;

• Check In/Check Out - funcionalidade que permite bloquear a edição dos documentos deste

tipo, isto é, quando um utilizador faz Check In só ele é que pode editar o documento em

causa, não permitindo que outros utilizadores editem este documento, podendo-o apenas

fazer quando o utilizador que fez Check In fizer Check Out;

• Arquivar - permite especificar o tempo ao fim do qual os documento associados a este tipo

são arquivados no Sistema de Gestão Documental e Workflow;

• Remover - permite especificar o tempo ao fim do qual os documento associados a este tipo

são eliminados do Sistema de Gestão Documental e Workflow;

• Tamanho máximo do ficheiro - especifica o tamanho máximo permitido dos ficheiros inse-

ridos.

3.1.5 Introdução de Documentos

Para introduzir um documento no iPortalDoc o utilizador deve verificar a diretoria na qual

este deve ser introduzido. Ao introduzir um documento o utilizador acede a uma interface que

possibilita fazer a classificação do mesmo para posterior introdução.

Qualquer documento ao ser introduzido no Sistema de Gestão Documental e Workflow tem

de passar por um processo de classificação. Cada documento deverá, assim, ser devidamente

classificado para que possa ser encontrado facilmente através do motor de busca. Para efetuar este

processo existem um conjunto de campos obrigatórios e um outro conjunto de carácter opcional.

Os campos obrigatórios são os seguintes:

• Tipo de documento - ao ser atribuído um tipo de documento é gerado automaticamente um

código para o documento em questão;

• Workflow - o fluxo de trabalho que o documento a inserir terá de percorrer;

• Título - corresponde ao título com o qual o documento será listado;

• Ficheiro - é o campo onde o utilizador carrega o documento para o sistema.

Além dos campos obrigatórios, existem outros campos que ajudam a complementar a descri-

ção de um documento:



• Tipo de Entidade - onde o utilizador seleciona o ramo da entidade ao qual está associado o

documento;

• Entidade – onde o utilizador seleciona a entidade a associar ao documento que está a ser

inserido;

• Assunto - nesta opção é possível inserir o assunto a que se refere o documento que vai ser

introduzido;

• Campo extra - campo extra para introduzir dados que sejam necessários a uma qualquer

funcionalidade extra introduzida no sistema;;

• Ordem – através desta funcionalidade, o utilizador pode especificar a ordem em que apareça

o documento dentro da secção em que será introduzido.

• Edição – neste campo o utilizador pode definir o número de edição do documento;

• Código – código automaticamente gerado aquando seleccionado o tipo de documento;

• Valor – através desta opção o utilizador pode definir um valor para o documento introduzido,

como por exemplo, o valor monetário de uma proposta;

• Autor – utilizador que insere o documento, tipicamente é o utilizador que está autenticado

no momento da inserção;

• Elaborado em – é o campo onde se coloca a data de criação do documento;

• Sumário e Descrição – são campos onde o utilizador pode expor o conteúdo do documento,

sendo que, por norma, o sumário é mais sucinto do que a descrição;

• Localização física – é o campo onde o utilizador deve referir o local onde se encontra o

formato físico do documento (por exemplo, a localização no arquivo de um documento em

papel);

• Palavras-chave – é o campo destinado à colocação de palavras que melhor descrevem o

documento e que poderão ser úteis para encontrar o documento em pesquisas.

Um dos elementos de classificação apresentado foi a Entidade. Para gerir as entidades, o

sistema operativo IPBrick disponibiliza uma aplicação designada IPContactos , que permite gerir

todas as entidades de uma organização, nesta são definidos os perfis associados às respetivas en-

tidades. Para introduzir entidades, é necessário inserir, numa primeira fase, os tipos de entidades.

Os tipos de entidades são categorias nas quais o utilizador pode organizar as entidades relaciona-

das com a sua organização, por exemplo clientes, fornecedores, entre outros. O iPortalDoc utiliza

a informação desta aplicação para classificar os documentos, nomeadamente para preencher os

campos tipo de entidade e entidade.


3.2 IPBrick 39

3.2 IPBrick

O IPBrick é uma solução comercial para servidores de Intranet e comunicações disponibili-

zada pela empresa iPortalMais . Assenta no sistema operativo Unix, na sua variante Linux que,

devido ao seu potencial, robustez, usabilidade e visto ser uma distribuição de código aberto é

uma opção bastante fiável, proporcionando às empresas uma experiência de comunicação segura

e completamente integrada.

IPBrick tem como principais caraterísticas, software para servidores de Intranet e comunica-

ções, gateway de comunicações com serviços de Firewall e Proxy para acesso à Internet, gateway

para telefonia VoIP e PBX, instalação automática, interface Web funcional e recuperação do sis-

tema. [44]

Para a gestão de todos os serviços prestados pela IPBrick existe uma interface de uso simples;

desta forma, as empresas não necessitam de peritos informáticos para manter a espinha dorsal

do negócio em funcionamento com elevada disponibilidade. As configurações mais específicas

podem ser realizadas por técnicos qualificados através da interface avançada.

3.2.1 IPBrick.I

A IPBrick.I gere a Intranet de uma empresa fornecendo serviços de correio eletrónico, fichei-

ros, impressoras, base de dados, domínio, bem como aplicações de apoio ao negócio.

Em resumo, a IPBrick.I oferece os seguintes serviços:

• servidor de áreas de trabalho individuais e de grupo;

• servidor LDAP (gestão de máquinas, utilizadores e grupos);

• servidor de correio eletrónico;

• servidor de impressoras;

• servidor de base de dados;

• servidor de DHCP (Dynamic Host Configuration Protocol);

• servidor de DNS (Dynamic Network Services);

• servidor de imagens de estações de trabalho;

• servidor de Groupware (Calendário e Livro de Endereços);

• servidor de backup;

• gestor de projetos.



3.2.2 IPBrick.C

O IPBrick.C é um servidor de comunicações com o exterior oferecendo serviços de relay de

correio eletrónico, webmail2, serviços de telefonia, servidor Web, FTP, File Transfer Protocol, e

Instant Messaging. Para além destes serviços disponibiliza sistemas de Firewall, deteção de intru-

são (IDS, Intrusion Detection System), Antispam e Antivírus, e VPN, Virtual Private Network. [45]

A IPBrick.C pode ser colocada numa DMZ (DeMilitarized Zone) protegida por firewall, como

um servidor de comunicações protegida pela firewall, ou mesmo como um servidor completo de

comunicações e sistema de firewall integrado.

Em resumo, a IPBrick.C oferece os seguintes serviços:

• Relay de correio eletrónico;

• Webmail;

• Servidor Web;

• Servidor Proxy (HTTP, HTTPS, FTP com estatísticas);

• Traffic shaping;

• Port security (packet based firewalling);

• IDS (Intrusion Detection System);

• Servidor de VoIP (RTP bases routing);

• Integração transparente com PBX (ISDN e linhas analógicas).

3.2.3 IPBrick.GT

A IPBrick.GT é um complemento à solução IPBrick.IC (IPBrick.I + IPBrick.C) com hard-

ware dedicado para permitir uma integração otimizada de voz e dados. Este responde às exigências

necessárias de integração entre a telefonia tradicional e a mais recente tecnologia VoIP fornecendo

assim uma implementação UCoIP, Unified Communications over IP. A IPBrick.GT implementa

tecnologia de gestão de largura de banda QoS, Quality of Service, para além de serviços de VPN,

servidor Web e Firewall. [46]

Em resumo as caraterísticas da IPBrick.GT são:

• Comunicação de dados VoIP baseada em protocolos standard de Internet (SIP, Session Ini-

tiation Protocol, RTP, Real-time Transport Protocol);

• Transferência segura de dados VoIP através de túneis VPN definidos;

• Negociações Voice Call inteligentes para servidores VoIP estrangeiros, Fornecedores de SIP

e redes de telefone tradicionais;2Interface que permite ao utilizador ler e escrever correio eletrónico usando um navegador


3.2 IPBrick 41

• Controlo da ligação entre a linha RDIS/Analógica e o seu PBX;

• Uma evolução da migração, incorporando a herança dos telefones RDIS/Analógicos e PBX

para a tecnologia VoIP;

• Integração com operadores de VoIP;

• Caraterísticas avançadas de QoS com integração de gestão de largura de banda.

3.2.4 IPBrick.4CC

A IPBrick.4CC é uma plataforma que permite criar, instalar gerir e recuperar em ambiente

de suporte de Cloud Computing. Com este é possível criar diversos servidores virtuais com dife-

rentes caraterísticas, reduzindo assim custos na aquisição de hardware dedicado; ainda é possível

também definir políticas em caso de falha escolhendo máquinas virtuais criticas que devem migrar

para outro servidor físico. A IPBrick.4CC potencia o modelo SaaS, Software as a Service, isto

significa que o utilizador pode aceder às suas aplicações sem se preocupar onde estão alocados

esses recursos. [47]

3.2.5 IPBrick.KAV

IPBrick.KAV é um complemento de segurança fornecida pelo sofware de segurança Kas-

persky, agregando as caraterísticas de um servidor de comunicação com um serviço de segurança,

oferecendo deste modo segurança a nível do correio eletrónico, acesso à Web bem como na Intra-

net. [48]

3.2.6 IPBrick.SOHO

A IPBrick.SOHO é uma solução para pequenos escritórios fornecendo os serviços essenciais

à sustentação deste, PBX e Fax, para além disso fornece servidor de correio eletrónico, Web e de

Instant Messaging. [49]

3.2.7 IPBrick.SCHOOL

É uma solução pensada para um ambiente escolar, onde professores e alunos podem trabalhar

em terminais ligeiros com sessões simultâneas em Windows e Linux. Além disto estudantes e

professores podem partilhar conteúdos, como por exemplo, agenda, contactos e ficheiros tudo a

partir do mesmo servidor implementando assim um ambiente de aprendizagem colaborativa. A

IPBrick.SCHOOL inclui também suporte para o Moodle, um software de código aberto para apoio

à aprendizagem permitindo administrar atividades educacionais. [50]

3.2.8 IPBrick for Oracle

A IPBrick for Oracle é uma distribuição IPBrick baseada em tecnologia Oracle, este oferece

todo o potencial do Oracle Enterprise Linux, Oracle DB e Oracle Application Server. O Oracle



Enterprise Linux oferece grandes garantias de robustez, alta performance e fiabilidade mas devido

à sua complexidade deixa de ser uma opção válida para muitos utilizadores. Com a IPBrick for

Oracle isto deixa de ser um obstáculo visto ser fácil de instalar, gerir e recuperar em caso de falha

(Disaster Recovery). [51]

3.3 OpenERP

Hoje em dia, riscos e custos de integração são barreiras importantes à implementação de ser-

viços de Enterprise Resource Planning, visto serem sistemas extremamente dispendiosos, tanto

de adquirir e instalar como de manter. Mas pelas grandes vantagens que oferecem no apoio ao

negócio, justifica-se a sua utilização. No entanto, as pequenas empresas não podem arriscar-se

com grandes sistemas ERP, como por o exemplo o SAP3, considerado até ao momento o melhor

sistema de gestão empresarial, uma vez que é extremamente caro.

O OpenERP , inicialmente conhecido como Tiny ERP, é uma solução de código aberto que

disponibiliza várias ferramentas de gestão empresarial (Enterprise Resource Planning), tais como,

contabilidade, gestão de materiais, gestão de vendas e compras, gestão dos recursos humanos.

Além destas opções oferece também uma solução CRM, Customer Relationship Management.

Visto ser uma solução de código aberto e graças à sua estrutura modular, que o torna fácil de

adaptar a diferentes tipos de comércio, ele é uma opção válida para pequenas e médias empresas,

uma vez que não implica custos tão elevados de aquisição, instalação e manutenção como outras

soluções disponíveis no mercado.

3.3.1 Arquitetura

O OpenERP é baseado numa arquitetura do tipo cliente-servidor, utilizando uma interface

XML-RPC ou NET-RPC para a comunicação entre as partes.

Este sistema é formado por três principais componentes, como é possível observar na Fi-

gura 3.2: um servidor de base de dados PostgreSQL, que contém toda a informação bem como

algumas das configurações do sistema, um servidor aplicacional que contém toda a logística da

empresa e assegura que o sistema funciona corretamente e, por fim, um servidor Web que propor-

ciona o acesso ao sistema a partir de navegadores Web tradicionais sem ser necessário a utilização

de um cliente GTK.

A parte do servidor aplicacional é escrita na linguagem de programação Python, sendo as

diferentes funcionalidades de negócio organizadas por módulos. Um módulo define a estrutura de

dados, relatórios, procedimentos, workflows, entre outros, e utiliza ficheiros XML.

Para aceder ao servidor OpenERP existem duas maneiras: através de um navegador/cliente

Web, e uma aplicação cliente (cliente GTK), baseado em PyGTK, instalada localmente em cada

posto de trabalho. Existem pequenas diferenças entre os tipos de clientes: o cliente Web é mais

apropriado a utilizadores que estão mais distantes do servidor visto este ser mais tolerante a atrasos

3Sistema de Gestão Empresarial da empresa SAP AG


3.3 OpenERP 43

Figura 3.2: Arquitetura do OpenERP . Baseado em [52]

de tempos de resposta, enquanto o cliente GTK é mais ágil caso o utilizador esteja mais próximo

do servidor. [52]

3.3.2 Módulos

Como dito anteriormente, o OpenERP é modular, permitindo que sejam instalados diferentes

módulos adaptando-se, assim, às necessidades de cada cliente. Durante a instalação inicial são

disponibilizados alguns módulos essenciais de base, como se pode verificar na Figura 3.3.

Para além destes módulos é possível instalar outros disponíveis em http://apps.openerp.

com/ ou mesmo desenvolver os próprios módulos a utilizar. É de destacar também módulos desen-

volvidos especificamente para Portugal dos quais se destacam os módulos SAF-T PT e Assinatura

Digital [53]. O primeiro módulo implementa a exportação de um ficheiro de dados para efeitos de

auditoria fiscal, de acordo com a portaria 1192/2009 de 8 de Outubro do Ministério das Finanças,

sendo este ficheiro necessário para a certificação de software de facturação [54], ou seja, para um

programa ser certificado tem de ser capaz de emitir um SAF-T.


http://apps.openerp.com/

http://apps.openerp.com/


Figura 3.3: Menu de instalação inicial do OpenERP onde é possível escolher os módulos a insta-lar. [52]

3.4 Outras Opções Tecnológicas

3.4.1 Sistemas de Gestão Empresarial

Nesta secção serão mencionadas outras soluções de Enterprise Resource Planning, comerciais

e de código aberto, destacando apenas as mais usadas, uma vez que existem inúmeras soluções

deste género.

Sistemas deste tipo tiveram uma grande taxa de crescimento na década de 90, uma vez que

as empresas preferiram investir em novos sistemas ERP em vez de preparar o seu atual, para o

problema do ano 2000.

Atualmente, as cinco soluções comerciais com mais quota de mercado, segundo um estudo

efetuado pelo Instituto Gartner, pertencem às seguintes empresas, SAP, Oracle, Sage, Infor e

Microsoft. No entanto, existem outras soluções comerciais e de código aberto, como se pode

verificar na Figura 3.4, onde é possível observar com mais pormenor as percentagens de utilização

de cada uma.

• SAP

SAP ERP é um sistema integrado de gestão empresarial, construído pela empresa alemã

SAP AG. Neste momento é a empresa com mais quota de mercado neste tipo de aplicações,

sendo a maior parte dos clientes grandes empresas.

Trata-se de um software com uma licença comercial, acarretando custos às empresas que o

queiram implementar, tanto na aquisição das licenças como em contractos de manutenção.


3.4 Outras Opções Tecnológicas 45

Figura 3.4: Quotas de mercados de soluções ERP [55]

O SAP ERP funciona numa arquitetura do tipo cliente-servidor, sendo o servidor constituído

por uma base de dados e um sistema aplicacional, o lado do cliente é constituído por uma

aplicação apelidada “front end”.

Este ERP apresenta uma constituição modular, adaptando as soluções base às necessidades

dos clientes. [56]

• Oracle

A solução ERP da Oracle é conhecida como Oracle E-Business, e consiste num conjunto

de aplicações informáticas de suporte a ERP, CRM e SCM4.

Trata-se de uma solução com licença comercial, com custos de aquisição de licenças e

manutenção.

Tal como a solução da SAP, também esta é constituída por módulos licenciados separa-

damente; ou seja, é apenas necessário adquirir os módulos adequados às necessidades do

cliente. [57]

• Sage

Sage é a terceira opção de ERP mais usada, construída pela empresa inglesa The Sage Group

plc. Esta contem três variantes, Sage ERP MAS, Sage ERP Accpac e Sage ERP X3, estando

cada uma das opções adaptada a diferentes tipos e dimensões de negócio. [58]

• Infor

A Infor Global Solutions é uma empresa dos Estados Unidos da América, especializada em

software de gestão empresarial, ERP, dispondo de várias soluções para diferentes tipos e

dimensões de empresas. [59]

4 Supply-Chain Management



• Microsoft

O Microsoft Dynamics é uma linha de software de gestão empresarial desenvolvida pela

Microsoft no qual está inserido o Microsoft Dynamics ERP. Este é sobretudo direccionado

para empresas de média dimensão. [60]

O Microsoft Dynamics ERP é constituído por quatro produtos básicos, o Microsoft Dyna-

mics AX projetado para ajudar as organizações a fazer negócios em diferentes locais e países,

padronizando os processos, o Microsoft Dynamics GP para ajudar as empresas na adaptação

a novas oportunidades e ao crescimento do mercado, o Microsoft Dynamics NAV projetado

para ajudar as organizações a otimizar processos de negócio específicos da indústria e o

Microsoft Dynamics SL que serve para obter relatórios e análises de negócios e automatizar

projetos ao longo de toda a organização. [60]

Para além destas soluções destacam-se a Primavera e a Gestix, uma vez que são de origem

portuguesa. Por outro lado, existem outras não comerciais, ou seja, de código aberto, como por

exemplo, Compiere, Dolibarr, Openbravo, WebERP, entre outras.

3.4.2 Sistemas de Gestão Documental e Workflow

• Filedoc

O Filedoc é um sistema de gestão documental, de processos e workflow desenvolvido e

comercializado pelo Grupo webuild. Integra as funcionalidades de arquivo e gestão do ciclo

de vida dos mais diversos formatos de conteúdos. O sistema é desenvolvido com recurso

tecnologias da Microsoft para ambientes Web e é totalmente integrável com as ferramentas

do Microsoft Office. [61]

• KnowledgeTree

O KnowledgeTree é um sistema de gestão do conhecimento, com gestão documental e con-

trolo de fluxos de trabalho através de alertas sobre documentos. Este sistema permite carre-

gar documentos, editá-los com controlo de versões, a criação de alertas sobre documentos

para controlo de processos de trabalho e ainda a criação de pastas partilháveis. Também ofe-

rece a possibilidade de aceder aos documentos armazenados na plataforma KnowledgeTree

através das aplicações do Microsoft Office. [62]

• Quidgest

As soluções de Gestão Documental da Quidgest permitem fazer uma gestão eficaz dos fluxos

informacionais das organizações. Os módulos de Gestão Documental da Quidgest tanto

podem funcionar unicamente enquanto solução central de registo de correspondência, onde

toda a documentação é centralizada pelo serviço de expediente e de arquivo, como também

podem salvaguardar o registo mais abrangente e eficaz da informação da organização, de

forma a responder com êxito a todos os desafios atuais. [63]


3.4 Outras Opções Tecnológicas 47

• Document Locator

O Document Locator consiste num sistema de gestão de conteúdos empresariais, com o ob-

jetivo de aumentar a eficiência colaborativa e comunicativa das organizações. Algumas das

caraterísticas são: gestão de documentos; gestão de correio eletrónico; gestão de conteú-

dos; controlo de versões; controlo de conteúdos; gestão de fluxos de trabalho; associação de

fluxos de trabalho a conteúdos. [64]

• Alfresco

Alfresco, é um sistema de gestão de conteúdo empresarial multiplataforma de código aberto

desenvolvido em Java. É uma alternativa para a gestão de documentos, de arquivos, de

colaboração e também de conteúdos Web. [65]




Capítulo 4

Planeamento

Neste capítulo será apresentado o planeamento da solução encontrada para a resolução do

problema.

4.1 Ordem do Trabalho

A primeira parte do planeamento foi escolher a versão do OpenERP a instalar e averiguar qual

o procedimento a seguir para o instalar no sistema operativo IPBrick , visto que este era um dos

principais objetivos. Ao analisar o procedimento fez-se um levantamento dos requisitos essenciais

ao bom funcionamento do OpenERP no sistema operativo.

Após levantadas as dependências, o próximo passo seria a sua instalação no sistema operativo.

Resolvidas as dependências, o próximo passo a tomar seria a criação do pacote de instalação

do OpenERP , garantindo que este se integra perfeitamente com o sistema operativo IPBrick , e

proceder à sua instalação.

Após instalado o OpenERP e verificado o seu bom funcionamento, a próxima etapa seria

estudar qual a melhor forma de sincronizar as entidades entre os dois sistemas.

O último objetivo seria a exportação dos documentos gerados pelo OpenERP para o iPortal-

Doc e garantir a possibilidade de aceder aos documentos de carater contabilístico presentes no

iPortalDoc diretamente do OpenERP .

4.2 Requisitos do OpenERP

O primeiro passo efetuado, antes de iniciar qualquer tentativa de instalação do OpenERP , foi o

levantamento dos requisitos mínimos exigidos por este de modo a que seja garantida uma execução

sem qualquer tipo de problemas ou erros. A versão do OpenERP escolhida para instalação foi

a última versão estável, ou seja, v6.0.3. Nas Tabelas 4.1 e 4.2 é possível verificar um resumo

das dependências necessárias à instalação da versão escolhida do OpenERP no sistema operativo

49

50 Planeamento

IPBrick , para o servidor aplicacional e para o cliente Web, respectivamente. Estão disponíveis as

versões das dependências necessárias à execução do OpenERP ("Versão Necessária"), a versão

da dependência no repositório da IPBrick , se for o caso, ("Versão ipbrick") e a versão instalada

("Versão Utilizada")

Tabela 4.1: Dependências para o servidor aplicacional OpenERP , "openerp-server"

VersãoDependência Necessária IPBrick UtilizadaPostgreSQL 8.2 8.1.8 9.1.1Python 2.5 2.4 2.6lxml - 1.1.1-1 2.2.6.1Mako 0.2.4 0.2.2-1 0.5.0psycopg2 - 2.0.5.1-6 2.4.2PyChart - 1.39 1.39pydot - 0.9.10-1 1.0.25reportlab - 2.0dfsg-1 2.5vobject - 0.4.4-1.1 0.8.1cPyYAML - - 3.10egenix-mx-base - 2.0.6-4 3.2.1python-ldap - 2.2.0-3 2.4.6

Tabela 4.2: Dependências para o cliente Web OpenERP , "openerp-web"

VersãoDependência Necessária IPBrick UtilizadaPython 2.5 2.4 2.6CherryPy 3.1.2 2.2.1-3 3.2.2Mako 0.2.4 0.2.2-1 0.5.0Babel 0.9.4 - 0.9.6FormEncode 1.2.2 0.6-1 1.2.4simplejson 2.0.9 1.3-0.1 2.2.1pyparsing 1.5.0 1.4.2-1.1 1.5.6


4.2 Requisitos do OpenERP 51

Além das duas tabelas mencionadas (dependências necessárias à instalação das aplicações Ope-

nERP ) estão disponíveis na Tabela 4.3 outras dependências necessárias, mas que não estão direta-

mente ligadas à aplicação em questão ("openerp-server"ou "openerp-web") ou não são necessárias

ao funcionamento básico destas. Como, por exemplo, o caso da dependência setuptools que não

é diretamente um requisito do OpenERP mas sim um requisito de outros requisitos exigidos pelo

OpenERP . Outro exemplo, é o caso da dependência SOAPpy que não é um requisito básico do

OpenERP mas é necessário para o funcionamento dos módulos criados.

Tabela 4.3: Outras dependências

VersãoDependência Necessária IPBrick Utilizadasetuptools - 0.6c3-3 0.6c11MarkupSafe - - 0.15python-dateutil - 1.1-1 1.5pytz - - 2011kxlwt - - 0.7.2imaging - 1.1.5-11 1.1.7PyWebDAV - - 0.9.4Django - 0.95.1-1etch2 1.3.1fpconst - - 0.7.2wstools - - 0.3SOAPpy - 0.11.3-1.7 0.12.5graphviz - 2.8-2.4 2.8-2.4


52 Planeamento


Capítulo 5

Implementação e Testes Efetuados

Neste capítulo será descrita a toda a implementação feita durante a execução do projeto bem

como os testes efetuados.

Verificou-se que a base de dados existente na IPBrick não era compatível com a necessária à

boa execução do OpenERP , tendo-se para isso criado um pacote de instalação de uma versão mais

recente desta (Secção 5.1).

Verificadas todas dependências, o próximo passo foi a criação do pacote de instalação do

OpenERP , garantindo a sua parametrização automática com o sistema operativo IPBrick (Sec-

ção 5.2).

Após criado e instalado o pacote do OpenERP , seguiu-se a sincronização bidirecional das

entidades entre o OpenERP e o IPContactos (Secção 5.3).

Finalmente é feita a integração dos documentos gerados pelo OpenERP no iPortalDoc e a

visualização no OpenERP de documentos de teor contabilístico presentes no iPortalDoc . (Sec-

ção 5.4).

5.1 PostgreSQL

Como foi possível verificar na secção 4.2, "Pré-requisitos do OpenERP", a versão do sistema

de gestão de base de dados PostgreSQL existente na IPBrick não era compatível com o OpenERP .

Posto isto, a solução encontrada, foi a criação de um pacote de instalação de uma versão do

PostgreSQL igual ou superior à exigida pelo OpenERP . Tendo sido escolhida para tal a versão

9.1.1, que é a versão mais atual, estável, do sistema de gestão de base de dados. Outro fator de

escolha desta versão foi uma nova e interessante funcionalidade: a possibilidade de implemen-

tação do sistema de notificação com uma mensagem opcional (payload) como, por exemplo, o

identificador (ID) de um registo alterado numa tabela. Este sistema permite notificar um ou mais

clientes que estejam à escuta de um canal previamente definido.

53

54 Implementação e Testes Efetuados

Nas Figuras 5.1 e 5.2 é possível visualizar um exemplo de uma mensagem transmitida através

do canal intitulado "virtual". Trata-se de um exemplo bastante simples executado com duas con-

solas de PostgreSQL; um exemplo mais real poderia ser, por exemplo, um daemon que estivesse

à escuta de um determinado canal e que executava determinadas ações conforme a notificações

que recebesse do servidor; estas, por sua vez, poderiam ser despoletadas por um gatilho (trigger)

presente numa tabela.

Figura 5.1: Exemplo do comando "NOTIFY".

Figura 5.2: Exemplo do comando "LISTEN".

Feita a escolha da versão foi então criado um pacote de instalação para o sistema operativo

IPBrick segundo as diretrizes deste.

Outro fator importante foi a parametrização automática do sistema de gestão de base de dados

no sistema sem que seja necessária a intervenção de um utilizador avançado, situação que acontece

sempre é que é instalado um sistema do género, com passos como, por exemplo, criação de um

utilizador, criação do cluster1 da base de dados, entre outras configurações. Para confrontar tal

problema foi criado um script que é executado durante a instalação do pacote no sistema operativo.

Criado o pacote, o próximo passo foi a sua instalação na IPBrick ; para isso recorreu-se à

interface criada para o efeito (Advanced Configurations -> IPBrick -> Update).

Na Figura 5.3 é possível verificar o decorrer da instalação do pacote no sistema operativo,

ficando a interface da IPBrick bloqueada enquanto decorre a instalação; no final é pedido que se

apliquem as configurações (Apply Configurations) para que o sistema assuma todas as alterações

efetuadas pelo pacote.

Por fim, é importante garantir a salvaguarda dos dados presentes neste sistema de base de

dados, uma vez que a sua perda traria graves problemas à organização que o utiliza. Para tal foi

criado um script que cria uma cópia das bases de dados geridas por este sistema; este script é

executado diariamente com recurso ao programa cron2. Desta forma, caso haja um problema com

o sistema de base de dados haverá sempre uma cópia dos dados, perdendo-se apenas os dados

criados ou modificados desde a última cópia considerada "boa", até ao momento do restauro.

1Conjunto de ficheiros e estrutura de diretórios onde ficaram as base dados geridas pelo sistemas de gestão de basede dados.

2Programa que permite o agendamento de tarefas.


5.2 OpenERP 55

Figura 5.3: Interface de instalação da IPBrick aquando a instalação do pacote postgresql-9.1-for-ipbrick-1.0.deb.

5.2 OpenERP

Recolhidas todas as dependências necessárias à execução do OpenERP (Secção 4.2), o pró-

ximo passo foi a criação do pacote de instalação do OpenERP na IPBrick . O método de instalação

em si é semelhante ao utilizado na instalação de qualquer atualização na IPBrick (Update).

O pacote a ser instalado é constituído pelas aplicações servidor ("openerp-server") e cliente

Web ("openerp-web"), bem como todas as dependências anteriormente mencionadas, estando a

instalação a cargo de um script que verifica as dependências, uma a uma e instalando apenas as

que ainda não existem no sistema.

Em resumo, para que a aplicação fique pronta a usar após a conclusão da instalação, o script

executa as seguintes ações:

• criação uma regra de autenticação no sistema de gestão de base de dados, postgresql-9.1-

for-ipbrick, previamente instalado;



• geração dos ficheiros de configuração do OpenERP com os dados para autenticação no

PostgresSQL;

• criação de um utilizador e de um grupo de utilizadores no sistema operativo para a execução

dos serviços ("openerp-server"e "openerp-web");

• configuração para que os serviços se iniciem aquando o arranque do sistema;

• configuração de um host virtual no servidor Web.

Na Figura 5.4 é possível verificar o decorrer da instalação do pacote no sistema operativo. A

interface da IPBrick fica bloqueada enquanto decorre a instalação, que demora entre cinco a sete

minutos para estar concluída, dependo do desempenho da máquina utilizada, uma vez que têm de

ser processadas todas as dependências, bem como a instalação das duas aplicações em causa. No

final é pedido que se apliquem as configurações para que o sistema assuma todas as alterações

efetuadas pelo pacote.

Figura 5.4: Interface de instalação da IPBrick aquando a instalação do pacoteopenerp-v6.0.3-4ipbrick-1.0.deb.


5.2 OpenERP 57

Na Tabela 5.1 é possível verificar o tempo de instalação decorrido durante a realização dos

testes. Verifica-se que os tempos obtidos nos testes são um pouco superiores aos previstos, isto

deve-se ao facto dos testes serem executados numa máquina virtual onde o processamento da

máquina física que a suporta não é apenas dedicado aos processos desta máquina virtual.

Tabela 5.1: Tempos de instalação do OpenERP na IPBrick .

Teste (número) Tempo (segundos)1 374,42 354,23 360,64 392,05 352,4

Média 366,7

Após aplicadas as configurações (Apply Configurations), é possível aceder à interface Web

do OpenERP com recurso a um navegador (browser), acedendo, por exemplo ao URL http://

openerp.domain.com3, onde é possível autenticar-se numa base de dados previamente criada

ou criar, excluir, salvaguardar ou repor uma base de dados, caso se tenha permissões, como é

possível verificar na Figura 5.5.

Figura 5.5: Interface de gestão de base de dados do OpenERP .

5.2.1 Autenticação

Um dos requisitos impostos era garantir a possibilidade dos utilizadores registados na IPBrick

ficarem imediatamente autenticados no OpenERP ; desta forma o utilizador não teria de saber outra3Endereço da interface Web do OpenERP instalada na máquina cujo responde ao nome “domain.com”


http://openerp.domain.com

http://openerp.domain.com


credencial de autenticação para aceder ao sistema.

Para satisfazer este requisito recorreu-se a um módulo do OpenERP útil para o efeito, users_ldap;

este módulo permite a autenticação dos utilizadores registados num sistema de diretório LDAP no

OpenERP , tendo este sido programado para ser instalado aquando a criação da base de dados, uma

vez que se trata de um módulo essencial ao funcionamento do OpenERP com o sistema operativo

IPBrick .

A utilização deste módulo requer algum conhecimento avançado por parte do utilizador, mas

uma vez que o conceito da IPBrick é que o utilizador não necessite de conhecimentos avançados

para a gerir houve a necessidade de parametrizar o módulo de forma automática. A solução en-

contrada foi a criação de um script que é executado sempre que este módulo é instalado, que por

sua vez, gera um ficheiro com as configurações necessárias ao bom funcionamento do módulo.

Um exemplo dessas configurações pode ser verificado na Figura 5.6.

Figura 5.6: Interface de gestão do módulo users_ldap.

Entre as várias opções do módulo, é oferecida a possibilidade de criar um utilizador segundo

as regras de um utilizador modelo existente no OpenERP . Esta funcionalidade cria um utilizador

no OpenERP caso este não exista e se a autenticação foi feita com sucesso no servidor LDAP.

Se esta opção for desativada, é necessário criar previamente no OpenERP os utilizadores que lhe

devam ter acesso; depois de criados, a autenticação continua a ser feita com recurso ao serviço de

diretório LDAP.

Em resumo, o significado dos campos exigidos para a correta configuração do módulo são os

seguintes [66]:

• Endereço do servidor LDAP - endereço da máquina onde se encontra o servidor LDAP;

• LDAP binddn - utilizador com permissões para pesquisar no diretório LDAP;

• LDAP base - especifica que parte da árvore de diretório deve ser consultada;

• Criar utilizador - opção de criar ou não utilizador;

• Sequência - prioridade para a configuração especificada, uma vez que o OpenERP permite

que seja configurado mais que um servidor LDAP;

• Porto do servidor LDAP - porto ao qual o servidor LDAP está à escuta de ligações;


5.3 Sincronização de Entidades 59

• Senha LDAP - senha de autenticação do utilizador especificado no binddn;

• Filtro LDAP - expressão que será utilizada para a pesquisa no diretório; no caso da figura,

a pesquida é feita pelo "uid"(Unique Identifier);

• Utilizador modelo - utilizador modelo que será utilizado na criação de utilizadores caso a

opção "Criar utilizador"esteja selecionada.

Como se trata de um módulo essencial ao funcionamento do OpenERP com a IPBrick , foi

programado para ser instalado aquando a criação da base de base de dados, tal como são instalados

os módulos essenciais ao funcionamento do OpenERP .

5.3 Sincronização de Entidades

Outro dos objetivos deste projeto era a integração bidirecional das entidades entre o OpenERP

e o iPortalDoc . Para tal foi criado um módulo para o IPContactos4 e outro para o OpenERP com

o objetivo de trabalharem em conjunto.

5.3.1 IPContactos

Este módulo foi desenvolvido em PHP, sendo a sincronização dos dados das entidades presen-

tes no IPContactos para o OpenERP feita com recurso aos web services do OpenERP , sendo estes

baseados no protocolo XML-RPC (Subsecção 2.4.5).

Para configurar a sincronização no sentido IPContactos para o OpenERP basta aceder ao menu

de administração deste (Administration) e de seguida escolher o separador de gestão de sincroni-

zação (Management Syncronism). Na Figura 5.7 é possível verificar um exemplo de configuração

para que o IPContactos sincronize os dados das entidades com o OpenERP .

Configurado corretamente o módulo o IPContactos está então habilitado a sincronizar as enti-

dades com o OpenERP .

É também disponibilizada a função de forçar a sincronização (Force Sync), que serve, tal como

o nome diz, para forçar uma sincronização completa. Ela verifica se todas as entidades existem

no OpenERP ; se existirem, é criado um mapeamento entre OpenERP e o IPContactos . Esta

verificação inicial é feita tomando em conta o Número de Identificação Fiscal, NIF; se a entidade

não existir no OpenERP , é então criada, e o mapeamento feito como explicado anteriormente.

5.3.2 OpenERP

Este módulo foi desenvolvido em Python, parte funcional, e em XML, o desenho da interface

de configuração, sendo a sincronização dos dados das entidades presentes no OpenERP para o

IPContactos feita com recurso aos web services do IPContactos , baseados no protocolo SOAP

4Aplicação onde é possível gerir as entidades da IPBrick .



Figura 5.7: Interface de gestão de sincronização de entidades do IPContactos .

(Subsecção 2.4.7). Além dos existentes (web services do IPContactos), foram criados alguns

necessários para uma correta sincronização dos dados.

Para configurar a sincronização no sentido OpenERP para o IPContactos basta aceder ao menu

(Administração) e, de seguida, escolher o separador de gestão de sincronização com o IPContac-

tos (IPContactos). Na Figura 5.8 é possível verificar um exemplo de configuração para que o

OpenERP sincronize os dados das entidades com o IPContactos .

Configurado corretamente o módulo o OpenERP está então habilitado a sincronizar as entida-

des com o IPContactos . Assim, sempre que for criada ou editada uma entidade no OpenERP esta

informação irá ser replicada para o IPContactos .

Após configurados corretamente os módulos nos dois sistemas (OpenERP e IPContactos),

procedeu-se à realização de alguns testes de desempenho dos módulos. O teste consistiu em sin-

cronizar diversas quantidades de entidades (Force Sync), entre os dois sistemas, executando dois

testes distintos: o primeiro teste consistiu em exportar as entidades do IPContactos para o Ope-

nERP ou seja, no OpenERP não existia entidade nenhuma; o segundo teste consistiu em executar

apenas o mapeamento das entidades entre os dois sistemas, ou seja, as entidades já existiam nos


5.3 Sincronização de Entidades 61

Figura 5.8: Interface de gestão de sincronização de entidades do OpenERP .

dois sistemas mas não existia nenhuma correspondência entre elas.

Na Tabela 5.2 é possível verificar o tempo necessário para a execução dos diferentes testes

para o mesmo número de entidades. À medida que o número de entidades aumenta verifica-se

um aumento exponencial do tempo necessário para a execução da tarefa, isto deve-se ao facto

de existir uma maior quantidade de entidades a verificar se existe correspondência entre os dois

sistemas.

Tabela 5.2: Tempos de sincronização completa de entidades entre o IPContactos e o OpenERP .

Tempo (segundos)Quantidade de entidades Sincronização Completa Apenas Mapeamento

100 19,3 2,2200 36,7 3,1400 73,5 9,4800 152,8 17,21600 280,35 44,2



5.4 Sincronização dos Documentos

Os próximos objetivos do projeto estavam relacionados com a integração dos documentos en-

tre o OpenERP e o iPortalDoc . Para cumprir este objetivo foi criado um módulo para o OpenERP

que se encarregaria de exportar os documentos gerados pelo OpenERP para o iPortalDoc , bem

como a possibilidade de integrar todos os documentos de caracter contabilístico presentes no iPor-

talDoc com o OpenERP , garantido funcionalidades como, abrir os esses documentos diretamente

no OpenERP e visualizar o estado destes tendo em conta a sua evolução no workflow.

Como resolução a este problema, foi criado um módulo para o OpenERP que irá comunicar

diretamente com o iPortalDoc através de web services criados para o efeito, sendo estes baseados

no protocolo SOAP. Além das funcionalidades implementadas, o módulo cria também um menu

novo OpenERP , onde poderão ser feitas a respetivas configurações e visualizar a listagem dos

ficheiros que se encontram no iPortalDoc; posteriormente é também possível aceder individual-

mente à informação detalhada de cada documento, e também descarregá-lo.

Para completar a integração, o primeiro passo necessário é configurar o iPortalDoc , criando

diretórios para os documentos exportados pelo OpenERP e, de seguida, configurar o módulo do

OpenERP introduzindo as credenciais necessárias bem como a descrição dos documentos a im-

portar do iPortalDoc para o OpenERP . Na Figura 5.9 é possível verificar um exemplo de confi-

guração introduzida no OpenERP .

Figura 5.9: Interface de configuração de sincronização de documentos do OpenERP .

Após completadas todas as configurações, a sincronização dos documentos poderá ser efe-

tuada; assim, cada vez que for gerado um documento no OpenERP , este será automaticamente

exportado para o iPortalDoc . Também serão importados todos os documentos do tipo "Fatura" pre-

sentes no iPortalDoc para o OpenERP , sendo possível analisar a sua informação detalhada e

descarregá-los para ver o ser conteúdo. É também disponibilizada uma ação de "Atualizar" a

informação do documento; ao executar esta ação é feito um pedido ao iPortalDoc de atualização

da informação do documento como, por exemplo, o estado do workflow em que o documento se


5.4 Sincronização dos Documentos 63

encontra. Na Figura 5.10 é possível verificar um exemplo de um documento presente no iPortal-

Doc . Além da visualização detalhada das informações do documento, também é possível verificar

a listagem de todos os documentos de teor contabilístico presentes no iPortalDoc .

Figura 5.10: Interface de exibição da informação de um documento do iPortalDoc no OpenERP .

O significado dos campos apresentados é:

• Entidade – entidade à qual está atribuído o documento em causa;

• Título – título do documento;

• Data da elaboração – data de elaboração do documento;

• Autor – utilizador responsável pelo documento em causa no iPortalDoc;

• Código – código atribuído ao documento consoante o tipo de documento (Subsecção 3.1.4)

a que este pertence;

• Diretoria – diretoria no iPortalDoc onde o documento se encontra armazenado;

• Workflow - workflow atribuído ao documento;

• Estado do worfkflow – estado do workflow no qual se encontra o documento.

Para testar as funcionalidades implementadas pelo módulo desenvolvido, foram criadas al-

gumas faturas de débito de crédito (devolução) no OpenERP . Esta operação permitiu testar as

duas funcionalidades básicas do módulo: exportar documentos do OpenERP para o iPortalDoc; e

visualizar no OpenERP os documentos de teor contabilístico presentes no iPortalDoc .

Na Figura 5.11 é possivel verificar uma listagem de documentos presentes no iPortalDoc que

foram exportados do OpenERP .

Também possível verificar na Figura 5.12 uma listagem dos documentos de teor contabilístico

presente no iPortalDoc através do OpenERP .



Figura 5.11: Listagem de documentos exportados do OpenERP para o iPortalDoc .

Figura 5.12: Listagem de documentos do iPortalDoc no OpenERP .


Capítulo 6

Conclusões e Trabalho Futuro

Neste capítulo é feita uma conclusão geral do trabalho elaborado. Também serão apresentadas

algumas perspetivas de trabalho futuro.

6.1 Conclusão geral

Os sistemas de gestão empresarial são uma mais-valia para as organizações, contribuindo para

uma significativa redução de custo e consequente aumento dos lucros. Contudo, aplicações deste

carater têm elevados custos de aquisição e implementação, sendo inviável para empresas de menor

dimensão adquirir soluções deste gênero. Uma solução, de mais baixo investimento, são as opções

de código aberto, que é o caso do OpenERP , mas tem de se saber instala-los e operá-los

As empresas recebem e produzem uma enorme quantidade e tipo de informação. A organi-

zação e tratamento de toda a informação é muito importante no mundo empresarial, sendo que

os sistemas de gestão documental e workflow são um poderoso auxiliar para qualquer empresa.

Desta forma, a interligação destes sistemas com outras aplicações torna-se um passo importante e

inevitável no desenvolvimento das empresas.

O principal objetivo do trabalho realizado foi a instalação do sistema de gestão empresarial

OpenERP no sistema operativo IPBrick , garantido a sua parametrização segundo os padrões da

IPBrick . Outro objetivo, não menos importante, foi a integração do OpenERP com o iPortalDoc .

No final do projeto pode-se afirmar que todos os objetivos e requisitos foram atingidos. Desde

modo é possível colocar em funcionamento no sistema operativo IPBrick o sistema de gestão

empresarial OpenERP garantindo também a sua integração com o iPortalDoc .

Neste momento a solução OpenERP for IPBrick esta a ser testada por colaboradores para que

num futuro próximo possa ser comercializada. Em relação ao módulo criado para o IPContactos

que providencia a migração de entidades para o OpenERP já se encontra numa atualização da

IPBrick , estando neste momento a ser distribuída pelos diversos clientes.

65

66 Conclusões e Trabalho Futuro

6.2 Trabalho Futuro

Algumas de perspetivas de desenvolvimento futuro são:

• garantir o acesso seguro ao OpenERP através de encriptação SSL, Secure Sockets Layer;

• sincronizar as agendas da IPBrick com as do OpenERP através do protocolo CalDAV;

• integrar o OpenERP com o OpenOffice para criação e edição de relatórios personalizados;

• criação uma interface amigável (drag-and-drop) no OpenERP para a introdução de utiliza-

dores registados na IPBrick .


Anexo A

Máquina Virtual

Na Tabela A.1 é possivel verificar as caraterísticas da máquina virtual utilizada no decorrer

dos testes;

Tabela A.1: Caraterísticas da máquina virtual utilizada.

Característica DescriçãoSistema Operativo IPBrick v5.3

Memória Base 1024 MBMemória Gráfica 12 MB

Processadores 4x 2.40 GHzDisco Rígido 10 GB (alocado dinâmicamente)

67

68 Máquina Virtual


Anexo B

OpenERP

Neste anexo é possível verificar algumas das interfaces criadas de modo a corresponder aos

objetivos do projeto.

Figura B.1: Interface principal do OpenERP .

69

70 OpenERP

Figura B.2: Módulos criados para o OpenERP .


Referências

[1] Ariel Ricks. La administracion de documentos como función archivistica, 1976. CongressoInternacional de Artigos (8o: 1976: Washington).

[2] PortalPME.pt. Sistemas de gestão documental, 2007. Disponível em http://wiki.portalpme.pt/twiki/bin/view/Main/Artigos/SistemasGest%C3%A3oDocumental, acedido a última vez em 12 de Janeiro de 2012.

[3] Grupo webuild. Vantagens de uma solução de gestão documental, 2011. Disponível emhttp://www.webuild.pt/conteudo.aspx?caso=contextual&lang=pt&id_object=348&name=Vantagens-de-uma-solucao-de-gestao-documental,acedido a última vez em 14 de Janeiro de 2012.

[4] Ana Joaquim. Gestão documental ganha maturidade, 2005. Disponível em http://www.semanainformatica.xl.pt/730/est/100.shtml, acedido a última vez em 18 deJaneiro de 2012.

[5] Luís Amaral. Praxis: um referencial para o planeamento de sistemas de informação. Relató-rio técnico, Universidade do Minho, 1994.

[6] Maria Manuela Pedro & Ana Sezinando. Sistemas de gestão de documentos eletrónicos.Informação e Informática, 2004.

[7] Karen Shegda. Integrated document management software: Perspective. Relatório técnico,Gartner Research, Abril 2001.

[8] Sara Piteira Mota. Gestão documental. Suplemento Digital, Diário Económico, páginasI–XI, Julho 2005.

[9] David Hollingsworth. Workflow management coalition - the workflow reference model,Janeiro 1995.

[10] C. Mohan. Recent trends in workflow management products, standards and research. Relató-rio técnico, Proc. NATO Advanced Study Institute (ASI) on Workflow Management Systemsand Interoperability, 1998.

[11] Ahmed Elmagarmid e Weimin Du. Workflow management: State of the art versus state ofthe products. Em Asuman Dogaç, Leonid Kalinichenko, M. Tamer Özsu, e Amit Sheth,editores, Workflow Management Systems and Interoperability, NATO ASI Series. SpringerBerlin Heidelberg, 1998.

[12] T.A.S. Coelho e M. Endler. Gerenciamento de workflow em redes com mobilidade e conec-tividade intermitente, Outubro 2002. In: IV Workshop de Comunicação Sem Fio e Compu-tação Móvel, 2002, São Paulo.

71

http://wiki.portalpme.pt/twiki/bin/view/Main/Artigos/SistemasGest%C3%A3oDocumental



http://www.webuild.pt/conteudo.aspx?caso=contextual&lang=pt&id_object=348&name=Vantagens-de-uma-solucao-de-gestao-documental

http://www.webuild.pt/conteudo.aspx?caso=contextual&lang=pt&id_object=348&name=Vantagens-de-uma-solucao-de-gestao-documental

http://www.semanainformatica.xl.pt/730/est/100.shtml

http://www.semanainformatica.xl.pt/730/est/100.shtml

72 REFERÊNCIAS

[13] André Parreira e João Parreira. Porquê gestão documental?, 2006. Disponível em http://2.ibt.pt/cache_imagens/XPQwqBgXX540UTIDk8FzrFZKU.pdf, acedido a últimavez em 18 de Janeiro de 2012.

[14] Mirella Moura Moro. Workflow, 1998.

[15] David Hollingsworth. The workflow reference model. Relatório técnico, Workflow Mana-gement Coalition, Janeiro 1995.

[16] Margie S. Virdell. Business processes and workflow in the web services world, Janeiro 2003.Disponível em http://www.ibm.com/developerworks/webservices/library/ws-work/index.html, acedido a última vez em 15 de Janeiro de 2012.

[17] Workflow Management Coalition. Workflow handbook. John Wiley & Sons, 1997.

[18] Luiz Antônio M. Pereira e Marco Antonio Casanova. Sistemas de gerência de workflows:Características, distribuição e exceções. Relatório técnico, Pontifícia Universidade Católicado Rio de Janeiro, Março 2003.

[19] Gregory Alan Bolcer e Richard N. Taylor. Advanced workflow management technologies.Software Process: Improvement and Practice, 1998.

[20] G. Alonso, D. Agrawal, A. El Abbadi, e C. Mohan. Functionality and limitations of currentworkflow management systems. IEEE Expert, 12, 1997.

[21] P. Andrew, S. Woodgate, J. Conrad, e J. Flanders. Presenting Windows Workflow Foundation.Sams, 2005.

[22] L. Fischer e Workflow Management Coalition. Workflow handbook, 2002. Future Strategies,2002.

[23] Thomas F. Wallace e Michael H. Kremzar. ERP : making it happen : the implementers guideto success with enterprise resource planning. Wiley, New York, 2001.

[24] Thomas H. Davenport. Putting the enterprise into the enterprise system. Harvard Bus. Rev.,76:121–131, July 1998.

[25] Carlos Sousa. Erp, Janeiro. Disponível em http://trabalhoerpismag2004.no.sapo.pt/, acedido a última vez em 16 de Janeiro de 2012.

[26] Thais Cássia Cabral Padilha e Fernando Augusto Silva Marins. Sistemas erp: características,custos e tendências. Produção, 15:102 – 113, 04 2005.

[27] Python Software Foundation. About python, 2011. Disponível em http://www.python.org/about/, acedido a última vez em 27 de Junho de 2011.

[28] V. Vaswani. PHP: a beginner’s guide. Beginner’s Guide. McGraw Hill, 2008.

[29] The Internet Society. Hypertext transfer protocol – http/1.1, 1999. Disponível em http://www.ietf.org/rfc/rfc2616.txt, acedido a última vez em 27 de Junho de 2011.

[30] The Internet Society. The secure hypertext transfer protocol, 1999. Disponível em http://www.ietf.org/rfc/rfc2660.txt, acedido a última vez em 27 de Junho de 2011.


http://2.ibt.pt/cache_imagens/XPQwqBgXX540UTIDk8FzrFZKU.pdf

http://2.ibt.pt/cache_imagens/XPQwqBgXX540UTIDk8FzrFZKU.pdf

http://www.ibm.com/developerworks/webservices/library/ws-work/index.html

http://www.ibm.com/developerworks/webservices/library/ws-work/index.html

http://trabalhoerpismag2004.no.sapo.pt/

http://trabalhoerpismag2004.no.sapo.pt/

http://www.python.org/about/


http://www.ietf.org/rfc/rfc2616.txt




REFERÊNCIAS 73

[31] José Carlos Ramalho e Pedro Rangel Henriques. XML & XSL: da teoria à prática. Sé-rie Tecnologias de Informação ISBN-972-722-347-8. Editora FCA, 1st ed. edição, Outubro2002.

[32] Artur Afonso de Sousa. Bases de Dados Web e XML. Editora FCA, 2002.

[33] UserLand Software Inc. Xml-rpc.com, 2003. Disponível em http://www.xmlrpc.com/,acedido a última vez em 27 de Junho de 2011.

[34] S.S. Laurent, J. Johnston, e E. Dumbill. Programming web services with XML-RPC. O’ReillySeries. O’Reilly, 2001.

[35] Tiny SPRL. Open Object Developer Book. OpenERP, 2009.

[36] Nilo Mitra. Soap version 1.2 part 0: Primer, 2003. Disponível em http://www.w3.org/TR/2003/REC-soap12-part0-20030624/, acedido a última vez em 18 de Janeiro de2011.

[37] J. Snell, D. Tidwell, e P. Kulchenko. Programming Web services with SOAP. O’Reilly Series.O’Reilly & Associates, 2002.

[38] PostgreSQL Global Development Group. About postgresql, 2011. Disponível em http://www.postgresql.org/about/, acedido a última vez em 27 de Junho de 2011.

[39] J. Drake e J. Worsley. Practical PostgreSQL. O’Reilly Media, 2011.

[40] G. Carter. LDAP system administration. O’Reilly Series. O’Reilly, 2003.

[41] The GTK+ Team. What is gtk+, and how can i use it?, 2011. Disponível em http://www.python.org/about/, acedido a última vez em 27 de Junho de 2011.

[42] The GNOME Project e PyGTK Team. About pygtk, 2009. Disponível em http://www.pygtk.org/about.html, acedido a última vez em 27 de Junho de 2011.

[43] iPortalMais Serviços de Internet e Redes Lda. Manual do iPortaDoc. 2007.

[44] iPortalMais. IPBrick , 2010. Disponível em http://www.iportalmais.pt/index.php?oid=89, acedido a última vez em 21 de Janeiro de 2012.

[45] iPortalMais. IPBrick.IC comunicações empresariais, 2010. Brochura do sistema IPBrick.IC .

[46] iPortalMais. IPBrick.GT , 2009. Brochura do sistema IPBrick.GT .

[47] iPortalMais. IPBrick.4CC , 2011. Brochura do sistema IPBrick.4CC .

[48] iPortalMais. IPBrick.KAV , 2010. Disponível em http://www.ipbrick.pt/index.php?oid=341, acedido a última vez em 10 de Junho de 2011.

[49] iPortalMais. IPBrick.SOHO , 2011. Disponível em http://www.ipbrick.pt/index.php?oid=342, acedido a última vez em 10 de Junho de 2011.

[50] iPortalMais. IPBrick.SCHOOL , 2011. Disponível em http://www.ipbrick.pt/index.php?oid=2017, acedido a última vez em 10 de Junho de 2011.

[51] iPortalMais. IPBrick for Oracle , 2011. Disponível em http://www.ipbrick.pt/index.php?oid=2077, acedido a última vez em 10 de Junho de 2011.


http://www.xmlrpc.com/

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

http://www.postgresql.org/about/

http://www.postgresql.org/about/



http://www.pygtk.org/about.html

http://www.pygtk.org/about.html

http://www.iportalmais.pt/index.php?oid=89

http://www.iportalmais.pt/index.php?oid=89

http://www.ipbrick.pt/index.php?oid=341








74 REFERÊNCIAS

[52] Fabien Pinckaers e Geoff Gardiner. Open ERP, a modern approach to integrated businessmanagement. OpenERP, 2011.

[53] Paulino Ascenção. Openerp portugal, 2010. Disponível em https://launchpad.net/openerp-pt, acedido a última vez em 25 de Junho de 2011.

[54] Direcção Geral de Impostos. Certificação de software de facturação, 2011. Disponí-vel em http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/CertificacaoSoftware.htm, acedido a última vez em 25 de Junho de 2011.

[55] Quora. What are the most common erp systems used by largecompanies?, 2011. Disponível em http://www.quora.com/What-are-the-most-common-ERP-systems-used-by-large-companies,acedido a última vez em 21 de Janeiro de 2012.

[56] SAP AG. Erp software from sap, 2011. Disponível em http://www.sap.com/solutions/business-suite/erp/index.epx, acedido a última vez em 05 de Julhode 2011.

[57] Oracle. Oracle e-business suite, 2011. Disponível em http://www.oracle.com/us/products/applications/ebusiness/index.html, acedido a última vez em 05 deJulho de 2011.

[58] Sage. Sage erp solutions, 2011. Disponível em http://www.sageerpsolutions.com/, acedido a última vez em 05 de Julho de 2011.

[59] Infor. Enterprise resource planning solutions from infor, 2011. Disponível em http://www.infor.com/solutions/erp/, acedido a última vez em 05 de Julho de 2011.

[60] Microsoft. Microsoft dynamics erp solutions, 2011. Disponível em http://www.microsoft.com/en-us/dynamics/erp.aspx, acedido a última vez em 05 de Julhode 2011.

[61] Grupo webuild. Filedoc - gestão documental, processos e arquivo, 2011. Disponívelem http://www.webuild.pt/conteudo.aspx?caso=contextual&lang=pt&id_object=495&name=Filedoc---Gestao-documental,-processos-e-arquivo, acedido a última vez em 22 de Janeiro de 2012.

[62] Grupo webuild. Knowledgetree, 2012. Disponível em http://www.knowledgetree.com, acedido a última vez em 22 de Janeiro de 2012.

[63] Quidgest. Gestão documental, 2009. Disponível em http://www.quidgest.com/e_documentPT.asp, acedido a última vez em 22 de Janeiro de 2012.

[64] ColumbiaSoft. Document locator, 2012. Disponível em http://www.documentlocator.com/, acedido a última vez em 22 de Janeiro de 2012.

[65] Inc Alfresco Software. Alfresco, 2012. Disponível em http://www.alfresco.com,acedido a última vez em 22 de Janeiro de 2012.

[66] Zimbra. Ldap authentication, 2011. Disponível em http://wiki.zimbra.com/wiki/LDAP_Authentication, acedido a última vez em 23 de Janeiro de 2012.


https://launchpad.net/openerp-pt

https://launchpad.net/openerp-pt

http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/CertificacaoSoftware.htm

http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/CertificacaoSoftware.htm

http://www.quora.com/What-are-the-most-common-ERP-systems-used-by-large-companies

http://www.quora.com/What-are-the-most-common-ERP-systems-used-by-large-companies

http://www.sap.com/solutions/business-suite/erp/index.epx

http://www.sap.com/solutions/business-suite/erp/index.epx

http://www.oracle.com/us/products/applications/ebusiness/index.html

http://www.oracle.com/us/products/applications/ebusiness/index.html

http://www.sageerpsolutions.com/

http://www.sageerpsolutions.com/

http://www.infor.com/solutions/erp/

http://www.infor.com/solutions/erp/

http://www.microsoft.com/en-us/dynamics/erp.aspx

http://www.microsoft.com/en-us/dynamics/erp.aspx

http://www.webuild.pt/conteudo.aspx?caso=contextual&lang=pt&id_object=495&name=Filedoc---Gestao-documental,-processos-e-arquivo



http://www.knowledgetree.com

http://www.knowledgetree.com

http://www.quidgest.com/e_documentPT.asp

http://www.quidgest.com/e_documentPT.asp

http://www.documentlocator.com/

http://www.documentlocator.com/

http://www.alfresco.com

http://wiki.zimbra.com/wiki/LDAP_Authentication

http://wiki.zimbra.com/wiki/LDAP_Authentication

Documents

Integração de OpenERP Enterprise Resource …paginas.fe.up.pt/~ee05128/dissertacao/wp-content/uploads/2012/02/...FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Integração de