António José dos Santos Marinho da...

60
António José dos Santos Marinho da Silva Integração de dados entre sistemas heterogéneos Tese de Mestrado Informática Industrial Trabalho efectuado sobre orientação do Doutor José Manuel Tavares Vieira Cabral Setembro de 2010

Transcript of António José dos Santos Marinho da...

António José dos Santos Marinho da Silva

Integração de dados entre sistemas

heterogéneos

Tese de Mestrado Informática Industrial

Trabalho efectuado sobre orientação do Doutor José Manuel Tavares Vieira Cabral

Setembro de 2010

ii

DECLARAÇÃO

Nome _António José dos Santos Marinho da Silva________________________________________________________

Endereço electrónico: [email protected]_______________ Telefone: _+351 962 582 960_ / ____________________

Número do Bilhete de Identidade: _10428984_____________

Título dissertação □/tese □

_ Integração de dados entre sistemas heterogéneos______________________________________________________

___________________________________________________________________________________________

___________________________________________________________________________________________

Orientador(es): _José Manuel Tavares Vieira Cabral_______________________________________________________

____________________________________________________ Ano de conclusão: _2010______

Designação do Mestrado ou do Ramo de Conhecimento do Doutoramento:

_Integração de dados entre sistemas heterogéneos_______________________________________________________

Nos exemplares das teses de doutoramento ou de mestrado ou de outros trabalhos entregues para prestação de

provas públicas nas universidades ou outros estabelecimentos de ensino, e dos quais é obrigatoriamente enviado

um exemplar para depósito legal na Biblioteca Nacional e, pelo menos outro para a biblioteca da universidade

respectiva, deve constar uma das seguintes declarações:

1. É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA TESE/TRABALHO APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;

2. É AUTORIZADA A REPRODUÇÃO PARCIAL DESTA TESE/TRABALHO (indicar, caso tal seja necessário, nº máximo de páginas, ilustrações, gráficos, etc.), APENAS PARA EFEITOS DE INVESTIGAÇÃO, , MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;

3. DE ACORDO COM A LEGISLAÇÃO EM VIGOR, NÃO É PERMITIDA A REPRODUÇÃO DE QUALQUER PARTE DESTA TESE/TRABALHO

Universidade do Minho, _15/_10/_2010_

Assinatura: ________________________________________________

iii

Agradecimentos

Quero expressar o meu sincero agradecimento a todas as pessoas que me apoiaram e

encorajaram, tornando este projecto possível, em especial, ao meu orientador, o Doutor José Manuel

Tavares Vieira Cabral.

Agradeço à Petrotec – Inovação e Industria, S. A., na pessoa do seu administrador Doutor José

Manuel Silva Bernardo Monteiro, pela disponibilidade de meios físicos e técnicos indispensáveis à

realização dos trabalhos que suportaram este projecto. Gostaria ainda de expressar os meus sinceros

agradecimentos ao colega desta instituição o Engenheiro José Gabriel Martins Machado, no apoio à

realização de alterações em bases de dados Lotus Notes, utilizadas em algumas das integrações referidas

neste projecto.

A todos, muito obrigada.

iv

Resumo

O projecto que serviu de base a esta dissertação consistiu no desenvolvimento de um conjunto de

ferramentas de integração de dados, com os seguintes objectivos: simplificar e automatizar processos,

reduzir substancialmente o trabalho de manutenção, realizar o registo automático de dados, integrar

aplicações e resolver problemas de acesso à informação. Este estudo surgiu na sequência da necessidade

de diminuição da carga de trabalho que a manutenção de dados provocava numa organização. Como

consequência deste estudo foram identificadas outras áreas onde surgiu a oportunidade de optimizar ou

melhorar processos recorrendo à integração de informação.

Foram criados e implementados diferentes métodos de integração de dados, entre várias

plataformas distintas, das quais se destacam as tradicionais bases de dados relacionais, bases de dados

documentais, diversos formatos de ficheiros como por exemplo XML, Excel, texto e PDF e ainda

equipamentos de rede activos. Dos vários trabalhos de integração realizados, são apresentados apenas

aqueles que, por um lado são os mais relevantes e demonstrativos de diferentes exemplos de integração

e, por outro, demonstram algumas das principais funcionalidades da ferramenta de integração utilizada, o

IBS Integrator® [1].

Palavras-chave (Tema): IBS Integrator, Integração de Dados

v

Abstract

The Project that served as a basis for this dissertation was based upon the development of several

data integration tools for the following purposes: simplification and automation of processes, substantial

reduction of maintenance, automatic recording of data, applications integration and the resolution of

problems regarding information access. This study was due to the necessary downsizing (reduction) of

maintenance tasks in the data management of an organization. As a result of this, other areas were also

identified, making it possible to optimize these processes as well, through the use of data integration.

Different methods of data integration were created and implemented, among these distinct platforms

were the traditional relational data base, document data base, several file extensions such as XML, Excel,

Text and PDF, as well as active network equipment/hardware. Of the various integration studies done, only

the most relevant and those that demonstrated the different examples of integration as well as the different

functionalities of the integration tool used, IBS Integrator® [1], are presented.

Keywords: IBS Integrator, Data Integration

vi Índice

Índice

Índice de Figuras ................................................................................................................ viii

Índice de Tabelas ................................................................................................................. ix

Índice de Acrónimos .............................................................................................................. x

1 Introdução .................................................................................................................... 1

1.1 Organização Acolhedora do Projecto ............................................................ 1

1.2 Enquadramento e Apresentação do Projecto ................................................... 2

1.3 Contributos do Trabalho .......................................................................... 2

1.4 Ferramenta de Integração Utilizada ............................................................. 3

1.5 Organização da Tese .............................................................................. 3

2 Estado da Arte .............................................................................................................. 5

3 Materiais e Métodos ..................................................................................................... 9

3.1 IBS Integrator® .................................................................................... 9

3.1.1 Visão Geral do IBS Integrator® .........................................................................9

3.1.2 IBS Integrator Design Studio ......................................................................... 10

3.1.3 IBS Integrator Web Administration ................................................................. 11

3.2 Actividades do Processo de Integração........................................................ 14

4 Discussão dos Resultados ........................................................................................... 19

4.1 Integração de Aplicações Lotus Notes/SAP ............................................... 19

4.1.1 Descrição do Processo ................................................................................ 19

4.1.2 Cenário de Integração ................................................................................ 20

4.1.3 Ganhos Obtidos com a Automatização do Processo ............................................. 21

4.2 Integração de Aplicações CRM/ERP ........................................................ 21

4.2.1 Descrição do Processo ................................................................................ 22

4.2.2 Cenário de Integração ................................................................................ 23

4.2.3 Ganhos Obtidos com a Automatização do Processo ............................................. 24

4.3 Envio de Encomendas a Fornecedores .................................................... 24

Índice vii

4.3.1 Descrição do Processo ................................................................................ 25

4.3.2 Cenário de Integração ................................................................................ 27

4.3.3 Ganhos Obtidos com a Automatização do Processo ............................................. 29

4.4 Controlo de Temperatura do Centro de Dados .......................................... 29

4.4.1 Descrição do Processo ................................................................................ 29

4.4.2 Cenário de Integração ................................................................................ 32

4.4.3 Ganhos Obtidos com a Automatização do Processo ............................................. 32

5 Conclusões ................................................................................................................. 33

5.1 Integração de Aplicações Lotus Notes/SA ................................................ 34

5.2 Integração de Aplicações CRM/ERP ........................................................ 34

5.3 Envio de Encomendas a Fornecedores .................................................... 35

5.4 Controlo de Temperatura do centro de dados .......................................... 36

6 Avaliação do Trabalho Realizado ................................................................................. 37

6.1 Objectivos Realizados ........................................................................ 37

6.2 Outros Trabalhos Realizados ................................................................ 37

6.3 Limitações e Trabalho Futuro .............................................................. 37

6.4 Apreciação Final .............................................................................. 38

Referências ........................................................................................................................ 39

Anexo A : Overview funcional do IBS Integrator .............................................................. 42

Anexo B : Código da classe de registo da temperatura do Centro de Dados: ................... 46

Anexo C : Overview do Centro de Dados do Grupo ........................................................... 48

viii Índice

Índice de Figuras

Figura 1 - Esquema simplificado de armazenamento de dados ..................................................... 5

Figura 2 - Esquema simplificado de base de dados virtual ......................................................... 6

Figura 3 – Tendência da Integração de Dados ao Longo do Tempo ................................................. 7

Figura 4 – Relação do IBS Integrator com os dados por ele suportados ............................................ 10

Figura 5 – IBS Integrator Design Studio .......................................................................... 11

Figura 6 - IBS Web Administracion, serviços ...................................................................... 12

Figura 7 – IBS Integrator Web Administration, Timer .............................................................. 13

Figura 8 – IBS Integrator Web Administration, Folder Watcher ..................................................... 14

Figura 9 – Actividades no desenho de integradores ............................................................... 15

Figura 10 - Cenários de integração possíveis ..................................................................... 16

Figura 11 – Cenário de integração por Web Services .............................................................. 21

Figura 12 – Cenário de integração por EAI ....................................................................... 24

Figura 13 – Fluxograma do processo de integração de encomendas de fornecedores ............................... 27

Figura 14 – Cenário de integração por EII (um destino) ........................................................... 28

Figura 15 – Cenário de integração por EII (vários destinos) ....................................................... 28

Figura 16 – Fluxograma do processo de integração de temperatura do centro de dados ............................ 31

Figura 17 – Cenário de integração por ETL ....................................................................... 32

Índice de Acrónimos ix

Índice de Tabelas

Tabela 1 – Registo da temperatura do centro de dados ........................................................... 30

Tabela 2 – Número de pedidos integrados por mês ............................................................... 34

Tabela 3 – Número de encomendas emitidas por mês ............................................................ 35

x Índice de Acrónimos

Índice de Acrónimos

ADO.NET ActiveX Data Objects (Conjunto de classes que podem ser utilizadas para troca de dados)

B2B Business to Business (sigla que identifica os negócios realizados entre empresas)

CRM Customeer Relationship Management (Gestão do Relacionamento com o Cliente)

DTS Data Transformation Services (Serviços de Transformação de Dados)

EAI Enterprise Application Integration (Interação de Aplicações Corporativas)

EDI Electronic Data Interchange (Troca Estruturada de Dados)

EII Enterprise Information Integration (Integração de Dados Empresariais)

ERP Enterprise Resource Planning (Sistema Integrado de Gestão Empresarial)

ETL Extract Transform and Load (Extracção Transformação e Carga)

FTP File Transfer Protocol (Protocolo de Transferência de Ficheiros)

GAV Global-as-View (consulta de dados Vista como Global)

HTTP Hyper Text Transfer Protocol (Protocolo de Transferência de HiperTexto)

HTTPS Hyper Text Transfer Protocol Secure (Protocolo de Transferência de HiperTexto Seguro)

IBM International Business Machines (Conhecida empresa americana do ramo da informática)

IS Integration Services (Serviços de Integração)

JDBC Java DataBase Connectivity (Conector de Base de Dados escrito em Java)

LAV Local-as-View (consulta dados Vista como Local)

ODBC Open DataBase Connectivity (Conector de Base de Dados)

OLE DB Object Linking and Embedding, Database (interface desenvolvido pela Microsoft® para acesso a

dados)

PDF Portable Document Format (Formato de Documento)

SAP Systeme Anwendungen und Produkte (Sistemas Aplicações e Produtos)

SCM Supply Chain Management (Gestão da Cadeia de Abastecimento)

SOA Service-Oriented Architecture) (Arquitectura Orientada a Serviços)

Índice de Acrónimos xi

SOAP Simple Object Access Protocol (Protocolo Simples de Acesso a Objectos)

TI Tecnologias de Informação

TXT Abreviatura para ficheiros de texto

XML eXtensible Markup Language (Standard que define formato de ficheiro de dados)

Introdução 1

1 Introdução

A integração de dados é um problema recorrente das organizações. São vários os factores que

contribuem para este tipo de problemas, sendo que o mais comum está relacionado com o crescimento

das organizações, associado à falta de investimento num sistema de gestão integrado ERP [2] (Enterprise

Resource Planning) que suporte todos os processos da empresa. Desta forma, são feitos investimentos em

ferramentas externas ao ERP, normalmente mais económicas, para informatizar processos que a maioria

dos ERP’s não suportavam anteriormente como por exemplo a gestão da qualidade, gestão ambiental,

avaliação de desempenho, recrutamento e selecção, entre outros. Outro exemplo típico, que leva as

organizações a investir em integração de dados, prende-se com a necessidade das empresas trocarem

informação com organizações com as quais existe algum tipo de relação comercial, ou motivadas pela

aquisição e integração de novas empresas.

1.1 Organização Acolhedora do Projecto

O Grupo Petrotec é um dos cinco maiores fabricantes mundiais, com tecnologia 100% própria, de

equipamentos para as áreas de distribuição e retalho da indústria petrolífera e o único em soluções

globais, desenvolvidas à medida de cada cliente.

O Grupo conta já com mais de duas décadas de actividade, abrangendo não só os segmentos de

Bombas de Combustível, Lavagem para Veículos e Sistemas para Frotas e Postos de Abastecimento, mas

também a oferta de soluções abrangentes e flexíveis que, aliadas à sua capacidade tecnológica, de

inovação e design, firmam a elevada notoriedade e prestígio alcançados.

Líder Ibérico, o Grupo está também representado a nível internacional, com afiliadas e

distribuidores em quatro continentes, assumindo-se, desta forma, como um "Player Global". As parcerias

estabelecidas asseguram uma rede de distribuição organizada, sustentada actualmente em mais de 50

países.

Com uma quota de mercado assinalável, o Grupo Petrotec tem-se afirmado pela dinâmica que tem

incutido a um sector, caracterizado por uma extrema competitividade, mas também pelo grau de

satisfação dos seus clientes, entre os quais fazem parte as maiores petrolíferas do mundo.

As suas unidades fabris caracterizam-se pela funcionalidade e tecnologia, enquanto a sua força de

trabalho é qualificada, jovem e altamente profissional, sendo a formação e renovação de conhecimentos

uma aposta contínua do Grupo.

2 Introdução

1.2 Enquadramento e Apresentação do Projecto

O principal objectivo deste projecto é o desenvolvimento de um conjunto de integradores que

permitam resolver alguns dos problemas de integração e acesso à informação existentes na organização,

nomeadamente a integração de dados de uma aplicação de controlo de assistência técnica com uma

aplicação semelhante de um dos seus clientes e, ainda, a integração de uma aplicação de CRM [3]

(Customeer Relationship Management) existente na empresa com o ERP.

A organização dispõe de várias bases de dados dispersas, adquiridas ou desenvolvidas “à medida”

para a empresa ao longo dos anos, no sentido de dar resposta a necessidades pontuais não suportadas

pelo ERP, ou quando suportadas, as funcionalidades são demasiado básicas para o nível de gestão

pretendido. Fazem parte dessas bases de dados as seguintes aplicações: gestão da qualidade, gestão

ambiental, gestão documental, gestão de higiene segurança e medicina no trabalho, avaliação de

desempenho, gestão do recrutamento e selecção, CRM, configurador de produtos e gestão da assistência

técnica. Adicionalmente, no decorrer do projecto, foram identificados processos, em que alguns deles são

suportados pelo ERP mas que foram alvo de melhoria, sendo automatizados pelo recurso a processos de

integração.

1.3 Contributos do Trabalho

Com a execução deste projecto foi possível reduzir custos para a organização através da eliminação

do trabalho de manutenção manual de dados em bases de dados externas ao ERP. Por outro lado, com a

adopção de integradores, a actualização de dados mestre nos sistemas periféricos deixou de ser manual

para passar a ser automática, o que garante que a informação se mantém consistente e actualizada. De

seguida apresentam-se alguns exemplos abordados neste projecto:

- O cadastro de colaborador era actualizado no ERP e, em simultâneo na aplicação de avaliação de

desempenho.

- A ficha de cliente, era actualizada no ERP, e em simultâneo na aplicação de CRM.

Foram também automatizados alguns processos de envio de documentos a entidades externas,

deixando de ser um processo manual e com recurso à impressão de papel, para passar a ser um

processo completamente automatizado e suportado por documentos electrónicos, como, por exemplo, o

envio de encomendas e notas de liquidação a fornecedores e o envio de encomendas, facturas e avisos de

vencimentos a clientes.

Introdução 3

1.4 Ferramenta de Integração Utilizada

A empresa já possuía uma ferramenta de integração de dados que era utilizada há já alguns anos

para realizar algumas integrações mais simples, tipicamente do tipo ETL [4] (Extract Transform and Load).

Esta ferramenta vem incluída no pacote de software do Microsoft® SQL Server que, nas versões 7.0 e

2000 se chamava DTS [5] (Data Transformation Services) mas que, a partir da versão do Microsoft® SQL

Server 2005, se passou a designar por IS [6] (Integration Services). Apesar desta ferramenta permitir a

ligação a diferentes bases de dados, incluindo a Lotus Notes, recorrendo a um driver da IBM® especifico

para o efeito, a gestão e o acesso a este tipo de dados revela-se difícil, e de certa forma limitado,

nomeadamente permitindo apenas leitura e não actualização. Esta limitação, juntamente com a

necessidade de realizar integrações via Web services, levou à decisão de adquirir uma nova ferramenta de

integração de dados.

Existem no mercado diversas ferramentas dedicadas à integração de dados. Uma rápida pesquisa na

Internet, permite-nos encontrar uma quantidade de empresas que apresentam ferramentas facilitadoras

de integração, que em alguns casos são “open source”, como por exemplo: CloverETL [7], Pentaho Data

Integration Enterprise Edition [8], iBOLT [9], SAS Enterprise Data Integration Server [10], SYBASE Data

Integration Suit – ETL [11]. É importante realizar uma escolha cuidadosa para garantir que a ferramenta a

utilizar seja o mais abrangente possível, fácil de utilizar, tenha uma curva de aprendizagem rápida e que

cubra todos os aspectos das integrações que se pretende implementar como, por exemplo, contenha

conectores para as bases de dados que se deseja utilizar.

Para este projecto foi escolhida a ferramenta de integração IBS Integrator®, principalmente por ser

fácil de utilizar e possuir uma curva de aprendizagem rápida. Além disso esta ferramenta tem a vantagem

de incluir conectores para bases de dados documentais, nomeadamente Lotus Notes, e de suportar

integrações por Web services. Adicionalmente, o IBS Integrator®, já inclui de base um conjunto de

funcionalidades que facilitam a integração com servidores iSeries [12],, o servidor que suporta o actual

ERP da organização.

1.5 Organização da Tese

No capítulo 2 apresenta-se o Estado da Arte, no qual se faz uma breve caracterização da evolução

da integração de dados ao longo dos últimos anos. São também referidos diferentes processos utilizados

na integração de dados e salientadas as principais características dos métodos de integração de dados

apresentados.

4 Introdução

No capítulo 3 é efectuada uma descrição geral da ferramenta de integração utilizada

nomeadamente, a apresentação da área de trabalho, menus e funcionalidades principais. São ainda

apresentados os principais conectores disponíveis nesta ferramenta e é dada uma panorâmica de como se

desenvolve um integrador com recurso à ferramenta em análise. Ainda neste capitulo é apresentado o

método utilizado no desenvolvimento dos integradores criados e a descrição de cada uma das fases desse

método.

No capítulo 4 são discutidos os resultados obtidos após a implementação dos integradores

desenvolvidos. São apresentados os ganhos obtidos em termos de redução de tempo, qualidade da

informação, redução da duplicação e manutenção da informação.

No capítulo 5 são apresentadas as conclusões deste trabalho, nomeadamente os resultados obtidos

em termos de ganhos de produtividade e ainda de redução de custos. Fazem-se ainda algumas

comparações entre os processos tradicionais de integração manual de dados com os mesmos processos

automatizados.

No capitulo 6 são apresentadas sugestões e perspectivas para trabalhos futuros.

Em anexo encontra-se informação suplementar: brochura da ferramenta de integração utilizada;

listagem do código criado de um dos processos de integração apresentados; imagem do centro de dados

da organização.

Estado da Arte 5

2 Estado da Arte

A integração de dados resulta da combinação de dados residentes em diferentes origens,

fornecendo aos utilizadores uma visão unificada desses dados. Este processo tem relevância numa

variedade de situações comerciais como por exemplo quando duas companhias necessitam de fundir as

suas bases de dados; e científicas, como por exemplo para combinar os resultados de diferentes

repositórios de dados de investigação. A frequência da integração de dados aumenta com o crescimento

das bases de dados e a necessidade de partilha dos mesmos. A integração de dados tornou-se o foco de

um extensivo trabalho teórico, onde alguns problemas continuam ainda por resolver. Nos círculos da

gestão, as pessoas referem-se frequentemente à integração de dados como EII [13] (Enterprise

Information Integration).

Os problemas de integração de dados entre sistemas de bases de dados heterogéneos já não são

novos. A rápida adopção de sistemas de bases de dados após a década de 1960, levou gradualmente à

necessidade de partilhar e convergir os repositórios de dados existentes. Esta fusão pode ocorrer em

vários níveis da arquitectura das base de dados. Uma solução vulgar é aquela que envolve o

armazenamento de dados (Figura 1). O sistema de armazenamento de dados (data warehousing) extrai,

transforma e carrega (ETL [4] Extract Transform and Load) dados de diferentes origens de dados num

único repositório pesquisável. Em termos de arquitectura esta é uma aproximação rígida porque todos os

dados se encontram num único repositório na fase da consulta. Esta arquitectura contem alguns

problemas de actualização de dados, isto é, sempre que os dados originais são alterados o sistema de

armazenamento de dados continua a apresentar os dados antigos até à próxima execução do ETL. Outra

dificuldade na construção de repositórios de dados reside no facto de existir uma interface por consulta de

dados não permitindo o acesso a todos os dados.

Data Source A

Data Source B

Data Source C

ETL

Data Datawarehouse

Figura 1 - Esquema simplificado de armazenamento de dados

6 Estado da Arte

A partir de 2009 tem-se verificado uma tendência na diminuição da integração por armazenamento

de dados e o aumento de um novo método baseado no método de esquema mediado [31]. Este novo

método, envolve o fornecimento de um interface que permite a consulta uniforme ao longo de um

esquema mediado (Figura 2), transformando a consulta em consultas específicas sobre as bases de dados

de origem. Pode-se chamar a este processo de visão baseada em consulta (view-based query-answering),

porque cada uma das origens de dados funciona como uma vista sobre o esquema mediado.

Formalmente os cientistas desta área chamam a esta abordagem LAV [14] (Local-as-View), onde local se

refere às origens de dados. Existe um modelo alternativo de integração de dados com esquema mediado,

com vistas sobre as fontes de dados. Esta abordagem, chamada como GAV [14] (Global-as-View), onde

global se refere ao esquema global. Devido à simplicidade envolvida em responder a consultas emitidas

sobre o esquema global, esta arquitectura tornou-se a mais atractiva. Contudo, deve-se reescrever a vista

para um esquema mediado sempre que for integrada uma nova fonte de dados e/ou sempre que um

esquema de uma fonte de dados é alterado. Alguns dos problemas da investigação em curso sobre

integração de dados estão relacionados com a semântica da integração. Este problema não aborda a

estruturação da arquitectura de integração pois está mais debruçado em resolver os conflitos de

semântica entre origens de dados heterogéneas. Por exemplo, se duas empresas fundirem as suas bases

de dados, alguns conceitos e definições dos seus respectivos esquemas de dados como o lucro poderão,

inevitavelmente ter significados diferentes. Numa base de dados pode significar lucros em euros (número

com vírgula flutuante), enquanto na outra base de dados pode representar o valor de vendas (número

inteiro). Uma estratégia comum para a resolução destes problemas, envolve o uso de ontologias que

explicitamente definem os termos do esquema e, assim, ajudam a resolver estes conflitos semânticos.

Já aqui foram referidos alguns tipos de integrações, nomeadamente ETL e EII [13] (Enterprise

Information Integration), no entanto, existem muitos outros, dos quais fazem parte os seguintes tipos EAI

Data Source A

Data Source B

Data Source C

Mediated Schema “Virtual Database”

Wrapper

Wrapper

Wrapper

Figura 2 - Esquema simplificado de base de dados virtual

Estado da Arte 7

[15] (Enterprise Application Integration), EDI [16] (Electronic Data Interchange), ou SOA [15] (Service-

Oriented Architecture). No decorrer da apresentação dos diversos integradores desenvolvidos, será

realizada uma referência ao tipo de integração em causa.

O gráfico da Figura 3 mostra a evolução e as tendências da integração de dados ao longo dos

últimos anos.

Exemplo

Considere uma aplicação Web onde o utilizador pode consultar uma variedade de informação sobre

as cidades, como por exemplo as estatísticas de criminalidade, clima, hotéis ou demografia.

Tradicionalmente a informação deveria existir numa única base de dados com um único esquema. Mas

qualquer empresa iria achar que informação desta amplitude sairia caro, difícil de recolher e manter.

Mesmo que existam os recursos para recolher e manter estes dados, provavelmente iriam duplicar as

bases de dados de criminalidade, sensos, e meteorológicas já existentes.

A solução de integração de dados pode resolver este problema, considerando esses recursos

externos como virtualizações materializadas ao longo de um esquema virtual mediado, resultando numa

integração de dados virtual. Isto significa que os programadores podem desenvolver um esquema virtual –

o esquema mediado – ou seja, o modelo que melhor responda às questões dos seus utilizadores. De

seguida, os programadores desenvolvem os adaptadores “wrapers” para cada uma das origens de dados,

como a base de dados da criminalidade, do site da meteorologia, etc. Estes adaptadores, apenas

Figura 3 – Tendência da Integração de Dados ao Longo do Tempo [30]

8 Estado da Arte

transformam os resultados da consulta local numa consulta a um site da Internet ou a uma base de

dados, devolvendo ao utilizador o resultado da sua consulta (Figura 2). Quando um utilizador, consulta

informação através de uma aplicação baseada em esquema mediado, a aplicação transforma essa

consulta em consultas ajustadas às respectivas bases de dados de origem. Finalmente, a aplicação virtual

combina o resultado das diversas consultas, fornecendo ao utilizador a resposta à consulta por ele

realizada.

Com esta solução torna-se simples adicionar novas bases de dados, bastando para tal construir

um novo adaptador para cada base de dados adicionada, o que contrasta com sistemas ETL ou com

soluções de bases de dados única, que exigem a integração e duplicação de todo o conjunto de dados

novos no sistema.

Materiais e Métodos 9

3 Materiais e Métodos

3.1 IBS Integrator®

A aplicação IBS Integrator® [1] é uma ferramenta que permite simplificar a complexidade relativa à

integração de sistemas, gestão e replicação de dados e processos de sincronização.

Entre os requisitos a que o IBS Integrator® dá resposta é de destacar a sua capacidade de

integração de sistemas, de integração e sincronização B2B [17] (Business to Business), de criação e

manutenção de bases de dados e de sincronização de processos de negócio SCM [18] (Supply Chain

Management). O produto permite ainda efectuar a integração do fluxo de trabalho e de informação e a

conversão de dados.

Esta solução da IBS inclui mais de 250 características e funções que tornam possível ler e

actualizar as bases de dados mais conhecidas, ler, criar e converter XML [19] (eXtensible Markup

Language), Microsoft® Excel ou qualquer outra informação em texto ou replicar e converter dados. É ainda

viável enviar, receber e extrair e-mails, utilizando FTP [20] (File Transfer Protocol), HTTP [21] (Hyper Text

Transfer Protocol), HTTPS [21] (Hyper Text Transfer Protocol Secure), Telnet [22], SOAP [23] (Simple

Object Access Protocol) ou mail encriptado, assinar e verificar documentos com total suporte de

encriptação, aceder a bases de dados Lotus Notes/Domino, suportar MQSeries, XML e Oracle Queue.

O IBS Integrator® está optimizado para controlar grandes volumes transaccionais e disponibiliza

conexões rápidas e nativas para as bases de dados mais populares, como AS400, Oracle, SQL Server,

DB2 e Lotus Notes/Domino. Esta é uma solução que também oferece funções especiais para integrar

qualquer base de dados ou sistema empresarial em Excel.

3.1.1 Visão Geral do IBS Integrator®

Como já foi referido o IBS Integrator® permite a ligação a vários tipos de bases de dados e suporta

diferentes formatos de ficheiros e de protocolos para troca de dados. A Figura 4 ilustra de um modo geral

de que forma o IBS Integrator® se relaciona com os dados e bases de dados por ele suportados.

10 Materiais e Métodos

Figura 4 – Relação do IBS Integrator com os dados por ele suportados [1]

3.1.2 IBS Integrator Design Studio

O IBS Integrator é composto por duas ferramentas distintas. A primeira, o Design Studio, é uma

plataforma de desenvolvimento de código, muito semelhante a um compilador. O Design Studio está

dividido em 4 áreas. A área 1 identificada na Figura 5 é a zona de exploração dos projectos já

desenvolvidos. Pode dizer-se que é a biblioteca de projectos realizados com recurso à ferramenta e das

classes associadas a cada um desses projectos. A área 2 é onde se encontra a biblioteca de funções

disponíveis para o desenvolvimento do código que compõe os integradores. O Design Studio dispõe de

base de uma biblioteca de funções muito vasta para o auxilio ao desenvolvimento dos projectos de

integração. A área 3 é a área de trabalho onde se realiza a programação do integrador. A programação

pode ser realizada em modo “gráfico” com recurso à biblioteca de funções ou em normal, ou seja,

escrevendo directamente o código na área de trabalho. Como se pode ver pela Figura 5, podemos a

qualquer altura passar do modo gráfico ou Visual para modo normal ou Java [24]. A linguagem de

programação com a qual se constroem os integradores com esta ferramenta é o Java. Finalmente a área

4 é a chamada janela de debug, onde todas as mensagens programadas ou de erro são apresentadas.

Esta área é muito útil na fase de teste onde se pode verificar passo a passo o comportamento do

integrador.

Materiais e Métodos 11

Figura 5 – IBS Integrator Design Studio

3.1.3 IBS Integrator Web Administration

O segundo interface de gestão é o Web Administration, tendo este funções distintas do primeiro, o

IBS Integrator® Design Studio. Enquanto que o primeiro se destina à criação dos programas de integração,

este interface destina-se a controlar todo o fluxo de informação, chamando um dos programas

desenvolvidos no Design Studio sempre que se verifiquem determinadas condições. O Web Administration

dispõe de vários tipos de serviços tais como Web Services, Folder Watcher, Timer, Socket Watcher, entre

outros, dos quais se descrevem apenas os serviços mais relevantes e utilizados no âmbito deste projecto.

A Figura 6 apresenta um dos ecrãs mais importantes do Web Administration, onde se podem ver os

serviços disponíveis e o seu estado. Os serviços activos estão precedidos de um quadrado verde e os

serviços inactivos por um quadrado cinza.

1

2

3

4

12 Materiais e Métodos

Figura 6 - IBS Web Administracion, serviços

3.1.3.1 Timer

O serviço Timer é vulgarmente usado em integrações do tipo ETL [4] (Extract Transform and Load).

Através deste serviço é definido um período de actualização da informação o que não é mais do que o

intervalo de tempo com que o Timer vai executar uma determinada classe de Java previamente

programada da qual resultará uma integração ou actualização de dados.

A Figura 7 mostra as configurações deste serviço e os respectivos serviços agendados.

Materiais e Métodos 13

Figura 7 – IBS Integrator Web Administration, Timer

3.1.3.2 Folder Watcher

O serviço Folder Whatcher é um serviço que, como o nome indica, está a monitorizar o conteúdo de

uma pasta específica. Quando for colocado nessa pasta um ficheiro que obedeça a determinadas

características, por exemplo nome e/ou extensão, o serviço activa uma classe previamente programada

para verificar/interpretar o ficheiro aí colocado. Posteriormente procede ao processamento do mesmo. O

processamento pode significar diversas operações, dependendo do destino que pretendemos dar ao

conteúdo do ficheiro, ou do programa ou classe associado a este serviço.

A Figura 8 seguinte mostra as configurações deste serviço, e os respectivos serviços agendados.

14 Materiais e Métodos

Figura 8 – IBS Integrator Web Administration, Folder Watcher

3.1.3.3 Web Services

O serviço Web Services permite realizar troca de dados entre sistemas que normalmente não se

encontram na mesma rede local e quando os sistemas pertencem a entidades diferentes. A troca de

informação entre os sistemas é realizada por meio de mensagens, normalmente em formato XML. No Web

Admistration é possível configurar o IBS Integrator® como um servidor ou fornecedor de Web Services ou

apenas como consumidor deste tipo de serviço.

3.2 Actividades do Processo de Integração

O processo de integração pode ser dividido em várias etapas, sendo apresentado na Figura 9 um conjunto

de fases fundamentais no desenho de processos de integração de dados. O facto de apresentar um

modelo dividido por diversas etapas não significa que todos os tipos de processos de integração passem

por todas elas.

Materiais e Métodos 15

Actividade 1: Identificar os dados de origem

A actividade 1 é uma das principais actividades do projecto de integradores, sendo nesta fase que

se identificam e avaliam os dados de origem relevantes ao processo de integração. Devem ser

seleccionados apenas os dados indispensáveis ao cumprimento dos requisitos da integração. Qualquer

informação não relevante ao processo de integração vai apenas prejudicar o desempenho do integrador,

tornando o processo mais lento e, por isso, menos eficiente.

Tendo em conta que os dados não indispensáveis ao processo de integração degradam o

desempenho do integrador, deve ser sempre questionada a sua pertinência e avaliada a razão

custo/beneficio, ou seja, o compromisso entre os dados que se pretendem integrar e o desempenho do

integrador.

1. Identificar os dados de origem

2. Identificar os dados destino

3. Mapear os dados origem/destino

4. Definir transformação de dados

5. Definir protocolo e tipo de integração

6. Implementar o integrador

7. Teste

Figura 9 – Actividades no desenho de integradores

16 Materiais e Métodos

Actividade 2: Identificar os dados destino

Esta actividade pode ser considerada em muitos dos problemas de integração como a actividade

principal de todo o processo, aparecendo em segundo lugar apenas por uma questão lógica,

origem/destino. No entanto, é ela que determina e condiciona quase sempre a selecção dos dados de

origem, o mapeamento entre dados de origem e destino, assim como a necessidade ao recurso à

transformação de dados.

Num processo de integração, a origem e destino de dados podem não ser únicos. Podem existir

diferentes tipos de cenários (Figura 10), uma origem e um destino, uma origem e vários destinos, um

destino e várias origens, várias origens e vários destinos ou, ainda, o mais comum numa integração, uma

ou várias origens/destinos de dados, em que cada uma das fontes envolvidas no processo de integração é

simultaneamente origem e destino.

Actividade 3: Mapear os dados origem/destino

O mapeamento de dados é a actividade responsável por estabelecer a correcta correspondência

entre os dados origem e o respectivo destino, sendo nesta fase que normalmente começam a surgir os

problemas de semântica relacionados com o processo de integração.

No caso de uma base de dados, ou de sistemas, que esperam receber dados estruturados, nem

sempre o mapeamento entre origem e destino é directo, sendo muito frequentemente necessário proceder

Uma origem, um destino

Data Base A

Data Base B

Origens e destinos simultâneos

Várias origens, um destino

Data Base C

Data Base A

Data Base B

Data Base A

Data Base B

Uma origem, vários destinos

Várias origens, vários destinos

Data Base A

Data Base B

Data Base C

Data Base A

Data Base B

Data Base C

Data Base D

Figura 10 - Cenários de integração possíveis

Materiais e Métodos 17

a alterações de tipos de dados para que estes correspondam ao mesmo tipo dos de destino. Nessa altura

recorre-se à actividade 4: “transformação de dados”.

Actividade 4: Definir transformação de dados

Sempre que existe uma relação directa entre a origem e o destino e o tipo de dados é o mesmo,

esta actividade não se aplica. No entanto, na maioria dos casos isso não acontece, sendo nesses casos

nesta actividade que se definem todas as transformações a que os dados vão estar sujeitos no sentido de

resolver os problemas de semântica encontrados na fase anterior.

A transformação de dados pode ser algo simples como a conversão do tipo de dados. Por exemplo

quando um determinado dado na origem é do tipo texto e no destino é do tipo inteiro, ou quando o dado

destino é o somatório de um conjunto de dados de origem segundo determinadas regras de agrupamento

ou, ainda, quando o símbolo decimal dos dados origem difere do símbolo decimal dos dados destino.

Em alguns casos a transformação de dados pode ser algo mais complexo. Tomemos como exemplo

uma aplicação de CRM [3] onde é gerido o processo desde a proposta até à encomenda e um sistema

ERP [2] onde é gerido o processo desde a encomenda até à facturação e respectiva liquidação. A

encomenda criada no CRM é integrada no ERP. No entanto as condições de pagamento têm códigos

distintos nos dois sistemas. Para resolver este problema é necessário criar uma tabela de relação entre os

códigos das condições de pagamento entre o CRM e o ERP que será usada para transformar o código de

origem no respectivo código destino.

Actividade 5: Definir protocolo e tipo de integração

Embora não seja obrigatório, sempre que acontece o acesso a dados num determinado sistema, ou

a troca de dados entre sistemas é conveniente identificar o tipo de integração em causa: ETL [4], EDI [16],

etc.. Para além do tipo de integração a utilizar, é necessário identificar ainda o protocolo, caso o acesso

directo à base de dados não seja possível. Os protocolos mais utilizados são SOAP e Web Services.

Quando existe acesso directo à bases de dados, é necessário identificar qual o tipo de acesso a utilizar,

ODBC [25] (Open DataBase Connectivity), JDBC [26] (Java DataBase Connectivity), OLE DB [27] (Object

Linking and Embedding, Database), ou ADO.NET [28] (ActiveX Data Objects). A escolha do tipo de acesso

é fundamental para o bom desempenho do integrador.

18 Materiais e Métodos

Adicionalmente, nos casos em que não existe qualquer tipo de acesso à base de dados de origem

e/ou destino é ainda necessário definir o formato de dados a trocar entre as aplicações, TXT, XML, etc.,

sendo actualmente o formato mais utilizado o XML.

Actividade 6: Implementar o integrador

Depois de definidas todas as actividades anteriores, é nesta actividade que se vai escolher a

ferramenta de integração a utilizar e desenvolver o integrador com a ferramenta escolhida.

A escolha da ferramenta de integração é muito importante. Existem no mercado uma variedade

muito grande de ferramentas disponíveis. No entanto, há que ter em atenção as especificidades da

integração que se pretende implementar e verificar se a ferramenta abrange essas especificidades. Por

exemplo, se se pretender integrar com uma base de dados em Lotus Notes ou então utilizar Web Services,

a ferramenta de integração deve conter conectores para este tipo de base de dados e suportar Web

Services.

Frequentemente, durante o desenrolar desta actividade é necessário voltar a actividades anteriores

para fazer algumas alterações de situações inicialmente não previstas, nomeadamente à actividade de

transformação de dados que, de certa forma, está extremamente relacionada com esta.

Actividade 7: Teste

Antes de colocar o integrador em produção, este deve ser executado em ambiente de testes.

Normalmente, durante a fase de testes, surgem erros que necessitam ser corrigidos, obrigando a retornar

a actividades anteriores.

Após a validação de todos os testes e de garantir que o processo não contém erros, passa-se o

integrador a produtivo, acompanhando e validando sempre as primeiras integrações, uma vez que nem

sempre se consegue reproduzir integralmente o processo real em ambiente de testes.

Discussão dos Resultados 19

4 Discussão dos Resultados

4.1 Integração de Aplicações Lotus Notes/SAP

O processo de integração apresentado de seguida trata-se de uma integração do tipo EAI [15]

(Enterprise Application Integration), estruturado em serviços SOA [15] (Service Oriented Architectures),

suportados em Web Services de um cliente da Organização.

4.1.1 Descrição do Processo

A Petrotec® Espanha, uma das empresas do grupo Petrotec®, dedicada à venda de equipamentos,

assistência e manutenção de postos de abastecimento de combustíveis, à semelhança da sua homologa

portuguesa Petroassist®, dispõe de uma ferramenta desenvolvida à medida para a gestão de todos os

processos relacionados com a assistência técnica prestada aos seus clientes. Até algum tempo atrás todos

os clientes submetiam os seus pedidos de assistência directamente para o help desk da Petrotec®, por

telefone, fax, email ou directamente no site da empresa destinado para o efeito. Entretanto um dos

principais clientes em Espanha, a Repsol®, decidiu concentrar nas suas instalações o help desk de todas

as estações de serviço da sua rede de distribuição, disponibilizando num site próprio para o efeito, todos

os pedidos de assistência entretanto registados e direccionados para cada um dos seus fornecedores,

entre os quais se encontra a Petrotec® Espanha, dependendo do tipo de avaria e equipamento avariado. A

partir dessa data, os colaboradores da Petrotec® tinham de autenticar-se no site da Repsol®, verificar

constantemente a existência de novos pedidos de assistência e, sempre que surgisse um novo, registá-lo

no seu próprio sistema de gestão da assistência GAMME (Gestão da Manutenção e Montagens Externas).

Para além disso, por cada alteração de estado do pedido de assistência no GAMME, tinham de o reflectir

manualmente no site da Repsol®. Toda a gestão deste processo era morosa e sujeita a erros e a atrasos

na actualização da informação.

Após várias reuniões entre a Petrotec® e a Repsol® no sentido de optimizar este processo, foi

acordado entre ambos que passariam a integrar as suas aplicações por um processo de integração com

recurso a Web Services. A Repsol® passou a disponibilizar um conjunto de funções via um servidor de Web

Services, ao qual a Petrotec® teria de recorrer para obter todos os novos pedidos de assistência, actualizar

o estado dos pedidos à medida que estes iam evoluindo no seu estado de resolução, até ao encerramento

dos mesmos.

20 Discussão dos Resultados

Foi definido que o formato das mensagens a trocar entre as duas entidades seria o XML [19],

entretanto a Repsol® criou e disponibilizou um conjunto de funções que se descrevem de seguida:

ObtenerDetalleAviso – Esta função permite obter o detalhe de um pedido de assistência,

a partir do seu código.

ObtenerTablasMaestras – Esta função permite obter as tabelas mestre relacionadas

com os pedidos de intervenção. Estas tabelas servirão para construir uma tabela de

correspondência de dados entre a aplicação da Repsol® e o GAMME, ou seja, as tabelas de

tradução de dados.

CrearAviso – Esta função permite a criação de um pedido de assistência a partir do

GAMME. Com a passagem do help desk da Petrotec® para a Repsol®, os pedidos de

assistência passaram a ser criados pela Repsol® e não pela Petrotec®. No entanto, em

alguns casos existe a necessidade de criar pedidos de assistência pela Petrotec®. Por

exemplo quando a equipa técnica chega ao local de intervenção e verifica que para além do

equipamento, que vai assistir encontra mais algum equipamento avariado para o qual

necessita abrir um pedido de assistência de imediato. Esta função serve para dar resposta

a esses casos.

ObtenerListaAvisos – Através desta função é possível obter a lista de todos os pedidos

num determinado estado, como por exemplo pedidos novos.

CrearOrden – Esta função permite criar uma ordem de reparação para um pedido de

intervenção.

NotificarOrden – Esta função tem como objectivo notificar uma ordem de reparação

sempre que existe alteração de estado de uma ordem.

ModificarPpto – Esta função permite modificar o orçamento quando o estado do pedido é

“Orçamento devolvido ao fornecedor”.

CrearParteReparacion – Esta função permite modificar o estado de um pedido cujo

estado é “Pendente de Fornecedor” se foi resolvido ou não telefonicamente.

4.1.2 Cenário de Integração

Uma vez que o centro de decisão, centro de dados, a equipa de desenvolvimento e suporte TI do

Grupo Petrotec® se encontram na sua sede em Guimarães, todo o controlo do processo é gerido a partir

deste site. Estão directamente envolvidos em todo o processo cinco servidores apresentados na Figura 11:

o servidor da aplicação de gestão da manutenção da Petrotec® (Lotus Notes) e o servidor da aplicação de

gestão da manutenção da Repsol® (SAP). Numa primeira análise o objectivo principal seria integrar

Discussão dos Resultados 21

informação comum destas duas máquinas. No entanto para que isso seja possível é necessário recorrer a

servidores adicionais para o efeito. Para além dos servidores aplicacionais, existem ainda três máquinas

responsáveis por gerir todo o processo de integração: o servidor de serviços Web disponibilizado pelo

cliente (Repsol®); o servidor que controla todo o processo de integração (IBS Integrator®); um servidor de

suporte, que não é mais do que um servidor de base de dados, onde estão guardadas as tabelas de

relação ou conversão de dados entre as duas aplicações a integrar.

4.1.3 Ganhos Obtidos com a Automatização do Processo

A informatização do processo de registo de pedidos de assistência permitiu à Petrotec® reduzir

significativamente o tempo dispendido com esta tarefa, reduzir erros ocorridos no tratamento manual da

informação, aumentar a qualidade dos dados, libertar os recursos para as tarefas de valor acrescentado

para a organização, nomeadamente a gestão da assistência técnica, o que se traduziu num ganho

substancial de produtividade e de satisfação e realização pessoal dos colaboradores directamente

envolvidos em todo o este processo.

4.2 Integração de Aplicações CRM/ERP

O processo de integração apresentado de seguida trata-se de mais uma integração do tipo EAI [15]

(Enterprise Application Integration), no entanto, ao contrário do exemplo anterior, neste caso não foi

necessário o recurso a Web Services uma vez que ambas as aplicações a integrar se encontram na

mesma rede e, para além disso, é possível o acesso directo às bases de dados de ambas as aplicações.

Servidor de Integração

Servidor Lotus Notes

Servidor Web Services

Internet

Petrotec Guimarães

Petrotec Madrid Repsol Madrid

Ligação Lógica Ligações Físicas

BD Tradução dados

Servidor SAP

Figura 11 – Cenário de integração por Web Services

22 Discussão dos Resultados

4.2.1 Descrição do Processo

Uma das empresas do Grupo Petrotec®, a Petrotec® – Inovação e Industria, S. A., decidiu adquirir

uma ferramenta para o controlo e gestão da sua força de vendas. Foi seleccionada para o efeito uma

ferramenta da Microsoft®, o Microsoft® Dynamics CRM [3]. Esta ferramenta para além da gestão de todos

os contactos estabelecidos com os clientes, faz também a gestão das propostas, sendo que as propostas

adjudicadas são convertidas posteriormente em encomendas ainda no CRM. Para dar seguimento a todo o

processo, desde a encomenda até à sua expedição e posterior facturação, a Petrotec® já dispunha de um

software para o efeito: um ERP [2] suportado por um servidor AS400 da IBM®. A partir da data da

implementação do software de CRM, a empresa ficou com um problema de integração de dados por

resolver, ou seja, todas as encomendas geradas no CRM eram posteriormente registadas manualmente no

ERP. Para além do problema das encomendas já referido, levantaram-se outros problemas de integração,

relativos à informação dos produtos e às listas de preços e contas, geridos e actualizados no ERP, e que

necessitavam de ser replicados para o CRM, de forma que a informação no CRM estivesse sempre

actualizada.

Foi necessário resolver os problemas de semântica existentes entre as duas aplicações relativos aos

dados a integrar tais como: condições de pagamento; meios de transporte; vendedor e proprietário de

conta. Os problemas de semântica foram resolvidos, à semelhança do exemplo anterior, com o recurso a

tabelas de relação de dados. Finalmente, foram criadas algumas funções, uma por cada área de

necessidade de integração nomeadamente, contas, listas de preços, produtos e encomendas, sedo esta

última a mais complexa de todas, pelo grande número de validações que a integração destes dados exige.

De seguida apresenta-se um resumo de cada uma dessas funções:

Contas – Esta função permite integrar todas as contas existentes no ERP para o CRM. O

sistema principal é o ERP, pelo que é este sistema quem manda nos dados mestre da

conta. Qualquer alteração realizada nos dados mestre da conta no ERP são replicadas no

CRM por intermédio desta função. No CRM existem nos dados da conta informação

complementar e que é mantida directamente neste sistema.

Encomendas – Esta é sem dúvida a função mais complexa deste integrador. É através

dela que as encomendas geradas no CRM são integradas no ERP. A quantidade de

validações e tradução de dados que são necessárias realizar para garantir a integridade dos

dados em ambas as aplicações é elevado. Ao nível do cabeçalho do documento é

necessário garantir que o armazém, vendedor, condições de pagamento e condições de

transporte são integrados de forma correcta. Para além disso, ainda é necessário gerar o

Discussão dos Resultados 23

número da encomenda com que vai ser integrada no ERP, respeitando a numeração

sequencial das encomendas. Relativamente às linhas de documentos, é necessário garantir

que todos os produtos têm código no ERP, já que as encomendas no ERP não permitem

adicionar produtos sem código. No entanto, no CRM isso é possível e são chamados

produtos de cotação. O comercial sabendo disso, quando converte no CRM uma cotação

em encomenda, devia ter o cuidado de atribuir código a todos os produtos de cotação a

todas as linhas da encomenda no CRM. Quando isso não acontece, esta função devolve um

email ao comercial responsável pela encomenda, referindo a encomenda e a descrição do

produto não integrado, assim como o motivo para a não integração.

PriceList – Esta função integra as listas de preços existentes no CRM. É uma função

relativamente simples, quando comparada com as anteriores, uma vez que não requer um

grande número de validações.

Produtos – Com esta função são integrados no CRM todos os produtos abertos no ERP e

que possam ser comercializados. Para não sobrecarregar a base de dados do CRM com

informação desnecessária, como por exemplo artigos fantasma, ou artigos existentes no

ERP destinados apenas a consumo interno ou produção; este tipo de artigos são logo à

partida excluídos da integração.

Uma das dificuldades da criação de novos dados no CRM por processo de integração tem a ver com

a forma como a Microsoft® gera as chaves primárias para esta aplicação de CRM. Estas são uma string do

tipo “d7efd579-c1af-dc11-91c5-005056ad244c” chamada de Windows Unic Identifier, e que é gerada a

partir da data e hora entre outras variáveis. Para resolver este problema foi utilizada uma das funções

disponíveis no IBS Integrator® que permitiu ultrapassar este problema sem grandes dificuldades.

4.2.2 Cenário de Integração

Estando todos os servidores envolvidos na mesma rede, e sendo possível o acesso directo às bases

de dados, através do servidor de integração, este cenário apresentado na Figura 12 foi mais simples de

implementar que no exemplo anterior. Para além do servidor de CRM e do servidor de ERP, foram

utilizados o servidor de Integração (IBS Integrator®) para controlar todo o processo de integração e, ainda,

um servidor de base de dados auxiliar (Microsoft® SQL Server) para gerir as tabelas de tradução de dados,

permitindo assim ultrapassar os problemas de semântica existentes entre ambas as aplicações integradas.

24 Discussão dos Resultados

4.2.3 Ganhos Obtidos com a Automatização do Processo

A informatização do processo de integração de encomendas de clientes do CRM no ERP, assim

como da informação relativa a tabelas de preços, contas e produtos do ERP para o CRM, permitiu reduzir

significativamente o tempo habitualmente dispendido nesta tarefa, reduzir erros ocorridos no tratamento

manual da informação, aumentar a qualidade dos dados, libertar os recursos para outras tarefas, o que se

traduziu num ganho substancial de produtividade.

4.3 Envio de Encomendas a Fornecedores

O processo de integração apresentado de seguida trata de um exemplo de integração do tipo EII

[13] (Enterprise Information Integration). Normalmente, este tipo de integrações combina dados de

diferentes repositórios de dados devolvendo esses dados combinados num relatório. Este é um exemplo

simples uma vez que a origem dos dados apresentados no documento gerado são todos provenientes do

mesmo repositório de dados.

Servidor de Integração

Servidor ERP

Servidor CRM

IBS Integrator

IBM AS400

Ligação Lógica Ligações Físicas

BD Tradução dados

Microsoft Dynamics CRM

MS SQL Server

Figura 12 – Cenário de integração por EAI

Discussão dos Resultados 25

4.3.1 Descrição do Processo

O processo de emissão de encomendas a fornecedores era um processo tradicional. As

encomendas eram emitidas no ERP, impressas em papel pré-timbrado e, de seguida, seguia-se um

processo de aprovação das encomendas de forma manual, ou seja, as encomendas aprovadas eram

rubricadas pelo responsável de compras e posteriormente, remetidas pelo administrativo ao fornecedor

por fax. Este processo, para além de moroso, implicava um desperdício enorme de papel, já que todas as

encomendas eram impressas para posterior aprovação e envio ao fornecedor.

A simplificação deste processo não se deveu apenas ao IBS Integrator®. Inicialmente foi

implementado um esquema de aprovação de encomendas no ERP, funcionalidade que o ERP já dispunha,

mas que faltava configurar. Foi configurado um limite em valor, a partir do qual todas as encomendas

teriam de ser aprovadas pelo responsável de compras. Posteriormente, foram configurados os menus e

permissões do módulo de compras para que apenas o responsável de compras tivesse permissões para

aprovar encomendas. As encomendas só podiam ser finalmente emitidas depois de devidamente

aprovadas.

Adicionalmente, com o recurso de uma aplicação que já existia na empresa (InterForm400 [29]),

mas que não estava devidamente aproveitada, deu-se um processo de conversão dos ficheiros de spool do

ERP (IBM AS400) para um ficheiro PDF, aplicando um layout ao documento com as mesmas imagens da

folha anteriormente pré-impressa, assim como um aspecto gráfico melhorado. O layout aplicado ao

documento depende da empresa em que o mesmo é emitido, já que o departamento de compras é

comum a todas as empresas do grupo em território nacional. O documento em PDF depois de gerado é

guardado numa pasta específica, previamente configurada. Nas versões actuais do InterForm400, é

possível por intermédio de alguma programação, enviam por correio electrónico o documento gerado. No

entanto, na versão existente na empresa isso não é possível e a actualização para a versão actual

representava um custo significativo.

Finalmente, para resolver o problema do envio das encomendas por correio electrónico, recorreu-se

ao IBS Integrator® para desenhar o integrador. O integrador monitoriza a pasta onde as encomendas são

geradas no formato PDF. Cada vez que surge um documento novo, o integrador “abre” o documento e

pesquisa no seu conteúdo informação vital para o resto do processo de integração, tais como: idioma da

encomenda; código da encomenda; empresa emissora da encomenda; código do fornecedor; colaborador

que emitiu o documento. De seguida, com base na informação recolhida é pesquisado no ERP na base de

dados da empresa origem da encomenda, no cadastro do fornecedor o seu endereço de correio

electrónico. No caso do endereço de correio electrónico existir, é enviada uma mensagem de correio ao

26 Discussão dos Resultados

fornecedor dando-lhe conta da encomenda, com o respectivo documento em anexo. Esta mensagem é

gerada em formato HTML, em inglês para fornecedores estrangeiros, com a assinatura institucional da

empresa, e personalizada de acordo com o utilizador que a emitiu; a mesma mensagem segue com o

conhecimento do emissor da encomenda. No caso do endereço de correio electrónico do fornecedor não

existir, a mensagem é enviada apenas para o colaborador que a emitiu com o respectiva encomenda em

anexo, dando-lhe conta que não foi enviada ao fornecedor por falta de endereço de correio electrónico.

Nestes casos o administrativo tem ainda a possibilidade de enviar a encomenda que recebeu em anexo

para o fornecedor por fax, mas desta vez por um sistema de fax de rede configurado entretanto para o

efeito, ou seja sem necessidade de imprimir o documento.

Todas as encomendas emitidas desta forma ficam arquivadas no servidor de ficheiros, segundo a

estrutura \\FileServer\...\%empresa_emissora%\%codigo_fornecedor%\%encomenda%.pdf. As strings

entre “%” representam variáveis recolhidas durante o processo de integração. O nome do ficheiro com que

a encomenda é guardas é alterado para um nome “inteligente” já que o nome do ficheiro original gerado a

partir do spool do ERP é genérico e, à primeira vista, não identifica minimamente o tipo ou conteúdo do

ficheiro.

Seguindo o sucesso do exemplo das encomendas a fornecedores, outros documentos da

organização foram automatizados segundo o mesmo processo, nomeadamente: notas de liquidação;

avisos de vencimento; encomendas de clientes; facturas.

A Figura 13 apresenta um diagrama simplificado do fluxo de informação deste integrador.

Discussão dos Resultados 27

4.3.2 Cenário de Integração

Este é um cenário um pouco diferente dos cenários apresentados anteriormente. Existe uma origem

clara de dados. No entanto, o destino não é assim tão evidente. Se considerarmos o destino como o

servidor de email responsável pelo envio das mensagens geradas pelo integrador, então o destino é único.

Fim

Inicio

Verifica ficheiro de origem

Recolhe variáveis do

ficheiro

Formato ok Não

Sim

Existe email Não

Sim

Envia encomenda ao

fornecedor

Envia encomenda ao

emissor

Arquiva enc. no file server

Procura email fornecedor

Figura 13 – Fluxograma do processo de integração de encomendas de fornecedores

28 Discussão dos Resultados

No entanto, podemos considerar como destino a caixa de correio de cada um dos fornecedores a quem

são enviadas as encomendas. Neste cenário os destinos são vários.

A Figura 14 apresenta um cenário simplificado, considerando o servidor de envio de correio como

destino.

A Figura 15 apresenta o cenário considerando a caixa de correio do destinatário como destino.

Servidor de Integração

Servidor ERP

Servidor Email

IBS Integrator

IBM AS400

Ligação Lógica Ligações Físicas

Microsoft Exchange

: :

Arquivo de Ficheiros

File Server

Internet

Fornecedores

Servidor de Integração

Servidor ERP

Servidor Email

IBS Integrator

IBM AS400

Ligação Lógica Ligações Físicas

Microsoft Exchange

Arquivo de Ficheiros

File Server

Figura 14 – Cenário de integração por EII (um destino)

Figura 15 – Cenário de integração por EII (vários destinos)

Discussão dos Resultados 29

4.3.3 Ganhos Obtidos com a Automatização do Processo

A informatização do processo de envio de encomendas a fornecedores, com recurso à integração

de dados, permitiu reduzir significativamente o tempo habitualmente dispendido nesta tarefa, melhorar a

relação com os fornecedores, permitir o arquivo digital dos documentos, reduzir significativamente os

custos com a redução de papel, já para não falar nos ganhos em termos ambientais e permitiu ainda

libertar os recursos para outras tarefas, o que se traduziu num ganho substancial de produtividade.

4.4 Controlo de Temperatura do Centro de Dados

O processo de integração apresentado de seguida trata-se de um processo simples do tipo ETL [4]

(Extract Transform and Load). São recolhidos dados numa determinada origem e posteriormente tratados

e guardados num repositório de destino para posterior consulta.

4.4.1 Descrição do Processo

O centro de dados do Grupo Petrotec®, como qualquer centro de dados, é de importância vital para

a organização, pelo que manter as boas condições de alojamento de todo o hardware existente é

fundamental. Nesse sentido é necessário que se mantenham as condições adequadas da sala,

nomeadamente a temperatura. O centro de dados dispõem de dois aparelhos de ar condicionado, como

forma de garantir alguma redundância, estes equipamentos estão por sua vez ligados a fontes de

alimentação ininterruptíveis, mas mesmo assim, é possível que reunidas determinadas condições

específicas, como por exemplo a avaria em simultâneo dos dois aparelhos de ar condicionado, provoquem

um aumento indesejado da temperatura no centro de dados.

Já existem equipamentos no mercado capazes de monitorizar a temperatura de um determinado

espaço e, quando a temperatura sair de determinados limites predefinidos, gerar alertas para que os

responsáveis pelo espaço tomem as devidas acções. O problema é que estes equipamentos ainda

representam um custo significativo.

Uma vez que na sala existem vários equipamentos com sensores de temperatura, nomeadamente

servidores, e equipamento de rede activo, em princípio bastaria tentar aceder aos valores registados por

esses equipamentos e tomar as acções necessárias sempre que os valores das temperaturas lidas

estivessem fora do intervalo de operacionalidade do hardware existente na sala. Foram identificados dois

switches de rede de um dos bastidores existentes, em que cada um dos equipamentos possuí dois

sensores de temperatura. O acesso aos valores de temperatura por eles registados pode ser realizado de

duas formas: ou entrando na pagina de gestão dos switches por um navegador de Internet, ou por

30 Discussão dos Resultados

intermédio de uma sessão de telnet [22]. Após alguma análise decidiu-se que o acesso ao valor da

temperatura registada pelos sensores seria realizado via sessão de telnet.

O integrador, liga-se ao primeiro switch, regista o valor dos dois sensores de temperatura, de

seguida estabelece sessão com o segundo switch e realiza o mesmo registo. No final calcula a média dos

quatro valores registados e guarda numa base de dados, a cada 30 minutos, o valor dos quatro sensores

de temperatura e a respectiva média. No caso da média ultrapassar um valor predeterminado, é gerada

uma mensagem de correio electrónico a todos os colaboradores do departamento de TI, dando conta dos

valores lidos, para que o responsável tome as acções necessárias à resolução do problema.

A Tabela 1 apresenta algumas das leituras registadas na base de dados durante um período de 9

horas de amostragem.

Evolução da Temperatura no Centro de Dados

Data Sensor01 Sensor02 Sensor03 Sensor04 TempMedia

11-08-2010 00:00:01 27 27 27 29 27

11-08-2010 00:31:25 25 26 26 27 25

11-08-2010 01:02:37 27 27 27 29 27

11-08-2010 01:33:50 26 27 27 28 26

11-08-2010 02:05:02 26 27 27 29 26

11-08-2010 02:36:12 26 27 27 29 26

11-08-2010 03:07:24 27 27 27 29 27

11-08-2010 03:39:07 27 28 28 29 27

11-08-2010 04:10:49 27 27 27 29 27

11-08-2010 04:42:29 27 28 28 30 27

11-08-2010 05:13:44 27 29 29 30 28

11-08-2010 05:44:59 28 29 29 30 28

11-08-2010 06:16:15 28 28 28 30 28

11-08-2010 06:47:31 27 28 28 30 27

11-08-2010 07:18:47 27 28 28 30 27

11-08-2010 07:50:02 28 29 29 30 28

11-08-2010 08:21:15 27 28 28 29 27

11-08-2010 08:52:28 25 26 26 28 25

Tabela 1 – Registo da temperatura do centro de dados

A Figura 16 apresenta um diagrama simplificado do fluxo de informação deste integrador.

Discussão dos Resultados 31

Fim

Inicio

Lê o valor dos 2 sensores

do Switch1

Lê o valor dos 2 sensores

do Switch2

Leitura OK Não

Sim

Não Sim

Calcula média dos

sensores <> 0

Notifica por email

colaboradores TI

Regista valores na base de

dados

Sensor SW1_01 = 0

Sensor SW1_02 = 0

Leitura OK

Sensor SW2_01 = 0

Sensor SW2_02 = 0

Sim

Sim Média <30º

Sim

Não

Figura 16 – Fluxograma do processo de integração de temperatura do centro de dados

32 Discussão dos Resultados

4.4.2 Cenário de Integração

Este é um cenário típico de uma integração do tipo ETL. Existem duas origens de dados que são os

equipamentos de rede activos e um destino de dados: a base de dados onde os dados recolhidos são

guardados, depois de tratados para posterior consulta. A Figura 17 apresenta este cenário de integração.

4.4.3 Ganhos Obtidos com a Automatização do Processo

Com a implementação deste integrador a Petrotec® passou a ter a temperatura da sala

constantemente monitorizada e a receber um alerta sempre que a mesma ultrapassa o valor predefinido

de 30ºC. Por outro lado, passou a ter disponível uma base de dados com o registo a cada 30 minutos dos

valores da temperatura da sala, o que permite realizar estatísticas e análises da evolução da temperatura

por intervalos temporais.

Servidor de Integração

IBS Integrator

Ligações Lógicas Ligações Físicas

Base Dados registo ºC

Equipamento de Rede MS SQL Server

Switch 01

Switch 02

Figura 17 – Cenário de integração por ETL

Conclusões 33

5 Conclusões

Devido à constante evolução e inovação tecnológica, têm surgido no mercado ferramentas que

permitem às organizações gerir cada vez mais complexidade com menos recursos, adoptando assim

modelos organizacionais mais flexíveis e tendencialmente mais globais. A maioria das organizações

actuais de média dimensão possuí diversos sistemas de informação, consequência de várias fases de

inovação, suportados em diferentes plataformas tecnológicas. Integrar este conjunto de plataformas exige

um esforço enorme, consumindo muitos recursos, constituindo por isso frequentemente um entrave à

mudança.

Os desafios do e-business obrigam a que as infra-estruturas de TI estejam preparadas para dar uma

resposta a estes desafios em tempo real. Processos de integração que tradicionalmente eram planeados e

programados para serem executados em processos batch, actualmente são pensados e programados para

serem executados em tempo real. A Internet, veio acelerar todo este processo, obrigando a comprimir o

factor tempo, facilitando a integração ao nível das aplicações em contraste com as integrações realizadas

ao nível dos dados.

O recurso a processos de integração por EAI [15] (Enterprise Application Integration) é um caminho

praticamente inevitável a seguir e para a maioria das organizações cada vez mais acessível. Este tipo de

integração faz cada vez mais sentido se for suportado por serviços SOA [15] (Service Oriented

Architectures), ou seja em Web Services, que poderão estar apenas disponíveis dentro da própria

organização, ou publicados na Internet, sempre que o objectivo da sua utilização é a partilha de

informação com parceiros, fornecedores ou clientes. De igual modo, permite às organizações para além

de publicar Web Services, consumir Web Services publicados pelos seus parceiros de negócio.

Atendendo a que se assiste a uma constante evolução das telecomunicações, nomeadamente na

existência de acessos cada vez mais rápidos, e a extensão da Internet a uma gama de dispositivos cada

vez mais alargada, iremos assistir a uma necessidade acrescida de alargar o domínio da integração de

aplicações, mas em simultâneo, a novas formas de expandir, gerir e fazer negócio.

Neste projecto desenvolveram-se um conjunto de integradores que possibilitaram à organização

reduzir custos e optimizar processos libertando recursos para outras tarefas, aumentando a produtividade,

e melhorando a qualidade e a integridade da informação.

34 Conclusões

5.1 Integração de Aplicações Lotus Notes/SA

O processo de integração de Lotus Notes com SAP foi sem dúvida um dos mais complexos de

implementar. Para além da construção das funções de integração propriamente ditas e das tabelas de

tradução de dados, foi ainda necessário realizar enumeras alterações à aplicação GAMME (Gestão da

Manutenção e Montagens Externas) da Petrotec® para que esta fosse capaz de registar informação, antes

não guardada, dos pedidos de assistência recebidos e, por outro lado, que pudesse produzir e

disponibilizar informação necessária à integração automática dos pedidos de assistência, que

anteriormente o processo de integração manual não o exigia. Uma rápida análise à tabela (Tabela 2) do

número de pedidos integrados por mês para o ano de 2010, concluímos que são integrados e

actualizados no seu estado sempre que estes se alteram, uma média de 333 pedidos por mês,

considerando 22 dias úteis por mês obtemos uma média de 15 pedidos de intervenção integrados e

actualizados por dia. Tendo em conta que o processo de registo dos pedidos no sistema da Organização, e

a posterior actualização manual dos vários estados no site do cliente demoravam em média cerca de 5

minutos, temos um ganho efectivo de tempo de 1:15h diário.

De seguida apresenta-se a tabela do número de pedidos de intervenção integrados por mês.

Pedidos por mês em 2010

Mês Nº Pedidos

Janeiro 312

Fevereiro 359

Março 366

Abril 322

Maio 289

Junho 292

Julho 388

Tabela 2 – Número de pedidos integrados por mês

5.2 Integração de Aplicações CRM/ERP

Se considerarmos apenas o número de encomendas de CRM [3] que são integradas no ERP [2], uma

média de 5 encomendas por mês, rapidamente chegamos à conclusão de que o esforço envolvido na

construção de um integrador entre estas duas aplicações foi um esforço em vão. O tempo e o custo

associados ao desenvolvimento deste integrador jamais será rentabilizado. No entanto, é bom relembrar

que a integração entre estas duas aplicações não se limitou apenas à integração das encomendas. Esse

foi apenas a ultima parte do processo. Antes das encomendas, foram ainda construídas funções de

integração das contas, produtos e listas de preços entre o ERP e o CRM, ou seja, a informação na qual era

Conclusões 35

dispendido mais esforço e mais tempo na actualização da informação de forma manual. Não nos

podemos esquecer ainda dos ganhos obtidos na qualidade e integridade da informação, só possíveis de

obter e garantir por processos automáticos de integração de dados.

5.3 Envio de Encomendas a Fornecedores

A informatização do processo de envio de encomendas a fornecedores, com o recurso a ferramentas

de integração, veio agilizar bastante este processo. A programação das funções de integração deste

processo foi relativamente simples, comparativamente com o processo de integração dos pedidos de

assistência e a do CRM com o ERP. No entanto, os ganhos foram significativos. São actualmente enviados

pelo integrador uma média de 933 encomendas por mês, considerando que um mês normal tem em

média 22 dias úteis, obtém-se uma média de 42 encomendas enviadas por dia de forma totalmente

automática. Tendo em conta que o processo manual de impressão e envio por fax da encomenda,

demorava em média cerca de 3 minutos, obtemos um ganho efectivo de tempo de cerca de 2:00h diárias,

e uma redução directa de custos com a diminuição do consumo de cerca de 1000 folhas de papel por

mês. Adicionalmente, obteve-se ainda uma redução no custo das comunicações, já que se enviam menos

42 faxes por dia, sendo que uma percentagem, ainda que pequena desses faxes eram internacionais. Se

considerarmos ainda os restantes documentos automatizados (notas de liquidação, avisos de vencimento,

encomendas de clientes e facturas) que eram anteriormente enviados por fax ou correio tradicional, então

a redução efectiva de custos e aumento de produtividade assumem ainda uma maior expressão.

A Tabela 3 apresenta o número das encomendas por mês para o ano de 2010. Desta análise foram

excluídas 3 empresas do grupo, pelo facto de que o número de encomendas emitidas por essas empresas

ser relativamente reduzido para poder influenciar a análise.

Encomendas por mês em 2010

Mês Petrotec Petroassist Total

Janeiro 563 272 835

Fevereiro 540 231 771

Março 662 319 981

Abril 672 319 991

Maio 774 290 1064

Junho 554 258 813

Julho 781 297 1078

Tabela 3 – Número de encomendas emitidas por mês

36 Conclusões

5.4 Controlo de Temperatura do centro de dados

De todos os processos abordados, o processo de controlo da temperatura do centro de dados é

aquele que não veio trazer uma redução efectiva de custos directos. No entanto, se considerarmos quanto

custaria realizar este controlo com equipamento específico para o efeito, ou os prejuízos que pudessem

resultar de um sobreaquecimento e consequente avaria dos equipamentos do centro de dados e todos os

prejuízos causados pela indisponibilidade do acesso à informação, então essa redução de custos pode

assumir proporções muito elevadas.

Avaliação do Trabalho Realizado 37

6 Avaliação do Trabalho Realizado

6.1 Objectivos Realizados

Com este projecto pretendeu-se optimizar um conjunto de processos: Integração de Aplicações CRM/ERP;

Integração de aplicações Lotus Notes/SAP; Envio de Encomendas a fornecedores; Controlo de

temperatura do Centro de Dados, utilizando uma ferramenta de integração o IBS Integrator® [1]. Os

integradores desenvolvidos introduziram alterações significativas na forma como os processos abrangidos

eram tradicionalmente tratados. Efectuou-se a optimização dos processos, sendo que os principais ganhos

foram em termos de tempo, redução de custos e aumento de produtividade, tendo-se obtido em alguns

casos processos mais atractivos em termos ambientais e, seguramente, em termos económicos.

6.2 Outros Trabalhos Realizados

A realização deste projecto permitiu também uma familiarização com outras tecnologias e

aplicações como sendo bases de dados documentais Lotus Notes, ferramentas de tratamento de dados de

impressão InterForm400 [29 e o standard de formato de dados XML [19]. Estas constituem ferramentas

importantes para engenheiros, num contexto de diversidade tecnológica existente actualmente.

6.3 Limitações e Trabalho Futuro

A principal limitação identificada na optimização de processos com o recuso ao IBS Integrator®

revelou-se nos integradores que dependem do serviço Folder Watcher da ferramenta de integração. Este

serviço esporadicamente deixa de responder, fazendo com que alguns ficheiros fiquem presos na fila de

processamento deste serviço, sendo por isso necessário verificar com alguma regularidade a existência de

ficheiros nesta fila de trabalho, assim como a sua antiguidade. Sempre que este problema ocorre, é

necessário remover estes ficheiros da fila de trabalho e colocá-los de novo na pasta de origem, sendo

ainda em alguns casos excepcionais necessário reiniciar o serviço de Folder Watcher do IBS Integrator®.

Em relação ao trabalho futuro, é importante realçar a necessidade de construir, com recurso à

própria ferramenta de integração IBS Integrator®, um integrador despoletado pelo serviço Timer, que

monitorize com alguma regularidade a fila de trabalhos do serviço Folder Watcher e, sempre que nele

forem encontrados ficheiros com mais do que 10 minutos na fila, deve notificar por email o responsável

de TI, já que significa que a fila de trabalhos contem ficheiros bloqueados e requer por isso alguma

atenção. Num futuro mais alargado, deve ser equacionada a migração dos integradores para ferramentas

38 Avaliação do Trabalho Realizado

de integração em Open Source que respondam aos requisitos exigidos pelos integradores já

desenvolvidos, no sentido de reduzir custos de manutenção de licenciamento do IBS Integrator®.

6.4 Apreciação Final

A realização deste projecto permitiu-me adquirir competências técnicas na área de integração de

dados entre sistemas heterogéneos, bem como na utilização de standards como JAVA script e XML. Estas

competências de desenvolvimento de integradores revelaram-se de extrema importância no decurso do

trabalho, na medida em que constitui uma base de conhecimento poderosa para a modelação e

optimização de processos com recurso a ferramentas de integração.

Foi possível cumprir com sucesso os objectivos definidos, estando parte desse êxito relacionado

com a total disponibilidade de meios físicos e técnicos necessários à realização dos trabalhos que

suportaram este projecto, por parte da Petrotec® bem como apoio e motivação constante por parte de

todos os colegas da Petrotec®.

Referências 39

Referências

[1] IBS Integrator [Consult. 9 de Jul. 2009]. Disponível em: http://www.ibs.net/solutions/supply-

chain-integration-and-collaboration/integrator

[2] O’Leary, Daniel - Enterprise Resource Planning Systems. 1ª ed. Cambridge : Cambridge

University Press. 2000. ISBN 0-521-79152-9

[3] Buttle, Francis - Customer Relationship Management. 2ª ed. Burlington : Butterworth-

Heinemann. 2008. ISBN 978-1-85617-522-7

[4] Kimball, Ralph/Caserta, Joe - The Data Warehouse ETL Toolkit: Practical Techniques for

Extracting, Cleanin. 1ª ed. Indianapolis : Wiley Publishing. 2004. ISBN 0-764-56757-8

[5] Rabeler, Carl - Microsoft SQL Server 2000 DTS Step by Step. 1ª ed. Washington : Microsoft

Press. 2003. ISBN 0-7356-1916-6

[6] Haselden, Kirk - Microsoft SQL Server 2008 Integration Services Unleashed. 1ª ed.

Indianapolis : Sams. 2009. ISBN 0-672-33032-6

[7] CloverETL - Data Integration Software [Consult. 9 Jul. 2009]. Disponível em:

http://www.cloveretl.com

[8] Pentaho - Data Integration Enterprise Edition [Consul. 11 Jul. 2009]. Disponível em:

http://www.pentaho.com/products/data_integration

[9] Magic Software - iBOLT [Consult. 12 Jul. 2009]. Disponível em:

http://www.magicsoftware.com/en/solutions/?catID=46

[10] SAS - Enterprise Data Integration Server [Consult. 12 Jul. 2009]. Disponível em:

http://www.sas.com/technologies/dw/entdiserver/index.html#section=1

[11] SYBASE - Data Integration Suit ETL [Consult. 12 Jul. 2009]. Disponível em:

http://www.sybase.com.br/products/dataintegration

[12] Hoskins, Jim/Dimmick, Roger - Exploring IBM Eserver Iseries and as/400e Computers.

10ª ed. Florida : Maximum Press. 2001. ISBN 1-885-06843-3

[13] S. Linthicum, David - Enterprise Information Integration (Information Technology). 1ª ed.

Toronto : Addison Wesley. 1999. ISBN 0-201-61583-5

40 Referências

[14] Cudré-Mauroux, Philippe – Emergnet Semantics (Computer and Communication

Sciences). 1ª ed. Washington : EFPL Press. 2008. ISBN 1-420-09227-8

[15] Yadav, Aditya - Essays on SOA and EAI - A Pocket Guide. 1ª ed. North Carolina : Lulu. 2010.

ISBN 0-557-33416-0

[16] Lientz, Bennet P. - Breakthrough Technology Project Management (E-Business

Solutions). 2ª ed. Burlington : Butterworth-Heinemann. 2001. ISBN 0-124-49968-6

[17] Coe, John - The Fundamentals of Business-to-Business Sales & Marketing. 1ª ed. New

York : McGraw-Hill. 2003. ISBN 0-071-40879-7

[18] Hugos, Michael – Essentials of Supply Chain Management. 2ª ed. New Jersey : John Wiley &

Sons. 2006. ISBN 0-471-77634-3

[19] Moller, Anders - An Introduction to XML and Web Technologies. 1ª ed. Essex : Addison

Wesley. 2006. ISBN 0-321-26966-7

[20] Loshin, Peter - Big Book of Internet File Transfer RFCs. 1ª ed. San Francisco : Morgan

Kaufmann. 2000. ISBN 0-124-55845-3

[21] Hall, Eric - Internet Core Protocols: The Definitive Guide. 1ª ed. Sebastopol : O'Reilly Media.

2000. ISBN 1-565-92572-6

[22] Held, Gilbert - The ABC’s of TCP/IP. 2ª ed. New York : Auerbach Publications. 2002. ISBN 0-

849-31463-1

[23] Brogden, Bill - SOAP Programming with Java. 1ª ed. New Jersey : John Wiley & Sons. 2002.

ISBN 0-782-12928-5

[24] Sierra, Kathy - Head First Java. 2ª ed. Sebastopol : O'Reilly Media. 2005. ISBN 0-596-00920-8

[25] Wood, Chuck - OLE and ODBC Developer's Guide. 1ª ed. New Jersey : John Wiley & Sons.

1999. ISBN 0-764-53308-8

[26] Bales, Donald - JDBC Pocket Reference. 1 ed. Sebastopol : O’Reilly Media. 2003. ISBN 0-596-

00457-5

[27] Nallet, Pierre - OLE DB Consumer Templates: A Programmer's Guide. 1ª ed. Toronto :

Addison Wesley. 2000. ISBN 0-201-65792-9

Referências 41

[28] Liberty, Jesse - Programming ADO.NET 3.5 Building Web Applications. 4ª ed. Sebastopol :

O’Reilly Media. 2008. ISBN 0-596-52956-2

[29] InterForm Products [Consult. 10 Fev. 2009]. Disponível em:

http://www.interform400.com/index.php/products/interform-400/overview

[30] Patrick Ziegler ; Klaus R. Dittrich: Data Integration — Problems, Approaches, and Perspectives. In John Krogstie, Andreas L. Opdahl, and Sjaak Brinkkemper, editors, Conceptual Modelling in Information Systems Engineering, pages 39–58. Springer, Berlin, 2007

[31] Data Integration [Consult. 9 Jul. 2009] Disponível em

http://en.wikipedia.org/wiki/Data_integration

42 Anexo A: Overview funcional do IBS Integrator

Anexo A : Overview funcional do IBS Integrator

Anexo A: Overview funcional do IBS Integrator 43

44 Anexo A: Overview funcional do IBS Integrator

Anexo A: Overview funcional do IBS Integrator 45

46 Anexo B: Código da classe de registo da temperatura no Centro de Dados

Anexo B : Código da classe de registo da temperatura

do Centro de Dados:

class TempDataCenter{

void main(){

String Text = ""; int Sw01Sens01 = ""; int Sw01Sens02 = ""; int Sw02Sens01 = ""; int Sw02Sens02 = ""; double AvgTemp = 0; IDate file_date = new IDate("MM/dd/yyyy HH:mm:ss",1,null,null,"",0,"Europe/Lisbon"); strDate = file_date.TEXT; //- Lê temperatura no SW01 TelnetConnection telnet1 = new TelnetConnection("192.168.0.243",23,1,"","","",""); Text = telnet1.wait("Fabric OS (swd77)\r\nFabos Version 6.1.0f\r\nswd77 login:",30); Text = telnet1.send("admin"); Text = telnet1.wait("Password:",5); Text = telnet1.send("#$/3%r(<d*´$!}"); Text = telnet1.wait("swfc01:admin>",5); Text = telnet1.send("tempshow"); Text = telnet1.wait("swfc01:admin>",5); telnet1.close(); if(Text == null){

mail.send("mail.petrotec.pt","[email protected]","[email protected]", "[email protected]; [email protected]; [email protected]","","Temperatura da Sala de Servidores","Não foi possivel ler a temperatura no switch01...",null,true, "Petrotec\\IBSIntegrator", "#$&%0xkZqLiI+ai42Qi5qc","25",false,false,null,null,null,false,false,false,false, true,"text/plain");

}else{ varx = Text.substring(115,133); varx = varx.trimBlanks(true,true,false,false,false); Sw01Sens01 = Integer.parseInt(varx); vary = Text.substring(148,166); vary = vary.trimBlanks(true,true,false,false,false); Sw01Sens02 = Integer.parseInt(vary); } //- Lê temperatura no SW02

TelnetConnection telnet2 = new TelnetConnection("192.168.0.244",23,1,"","","",""); Text = telnet2.wait("Fabric OS (swd77)\r\nFabos Version 6.1.0f\r\nswd77 login:",30); Text = telnet2.send("admin"); Text = telnet2.wait("Password:",5);

Anexo B: Código da classe de registo da temperatura no Centro de Dados 47

Text = telnet2.send("#$/3%r(<d*´$!}"); Text = telnet2.wait("swfc02:admin>",5); Text = telnet2.send("tempshow"); Text = telnet2.wait("swfc02:admin>",5); telnet2.close(); if(Text == null){

mail.send("mail.petrotec.pt","[email protected]","[email protected]", "[email protected]; [email protected]; [email protected]","","Temperatura da Sala de Servidores","Não foi possivel ler a temperatura no switch02...", null,true,"Petrotec\\IBSIntegrator" ,"#$&%0xkZqLiI+ai42Qi5qc","25",false,false,null,null,null,false,false,false,false, true,"text/plain");

}else{ varx = Text.substring(115,133); varx = varx.trimBlanks(true,true,false,false,false); Sw02Sens01 = Integer.parseInt(varx); vary = Text.substring(148,166); vary = vary.trimBlanks(true,true,false,false,false); Sw02Sens02 = Integer.parseInt(vary); } if(Sw01Sens01 == "" && Sw01Sens02 == 0){ AvgTemp = (Sw02Sens01 + Sw02Sens01) / 2; }else if(Sw02Sens01 == 0 && Sw02Sens02 == 0){ AvgTemp = (Sw01Sens01 + Sw01Sens01) / 2; }else{ AvgTemp = (Sw01Sens01 + Sw01Sens01 + Sw02Sens01 + Sw02Sens01) / 4; }

JDBCConnection jdbc1 = new JDBCConnection("jtds", "jdbc:jtds:sqlserver://DataServer01:1433/Intranet;useCursors=true","IBSIntegrator", "#$&%0xkZqLiI+ai42Qi5qc",null); jdbc1.executeCommand(1,"IT_DataCenterTemp",null,"Data=strDate;Sensor01=Sw01Sens01;Sensor02=Sw01Sens02;Sensor03=Sw02Sens01;Sensor04=Sw02Sens02;TempMedia=AvgTemp",1,true,true,false,true,true,1);

jdbc1.close(); if(AvgTemp >= 30){

Mail.send("mail.petrotec.pt","[email protected]","[email protected]", "[email protected]; [email protected]; [email protected]","","Temperatura da Sala de Servidores","A temperatura no interior da sala dos servidores é de |AvgTemp|º Centigrados.\r\n\r\nPor favor verificar os aparelhos de ar condicionado.\r\n\r\nData da leitura: |strDate|",null,true,"Petrotec\\IBSIntegrator","#$&%0xkZqLiI+ai42Qi5qc","25",false,false,null,null,null,false,false,false,false,true,"text/plain");

}

} }

48 Anexo C: Overview do Centro de dados do Grupo

Anexo C : Overview do Centro de Dados do Grupo