Monografia - Automação Bancária - Intercâmbio eletrônico de dados entre bancos e empresas usando XML

SOCIEDADE EDUCACIONAL E CULTURAL DE DIVINÓPOLIS FACULDADES INTEGRADAS DO OESTE DE MINAS - FADOM

SISTEMAS DE INFORMAÇÃO

AUTOMAÇÃO BANCÁRIA - INTERCÂMBIO ELETRÔNICO DE DADO S ENTRE BANCOS E EMPRESAS USANDO XML

RENATO FARIA LOPES

Divinópolis, dezembro, 2003

SOCIEDADE EDUCACIONAL E CULTURAL DE DIVINÓPOLIS FACULDADES INTEGRADAS DO OESTE DE MINAS - FADOM

SISTEMAS DE INFORMAÇÃO

AUTOMAÇÃO BANCÁRIA - INTERCÂMBIO ELETRÔNICO DE DADO S ENTRE BANCOS E EMPRESAS USANDO XML

RENATO FARIA LOPES

Monografia apresentada às Faculdades Integradas do Oeste de Minas como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação.

Orientador: Professor Nesley Daher

Divinópolis, dezembro, 2003

FOLHA DE AVALIAÇÃO

Nome do aluno: Renato Faria Lopes

Nr. de matrícula: 02000094 Curso: Sistemas de Informação

Título do Trabalho: Automação Bancária - Intercâmbio Eletrônico de Dados entre

bancos e empresas usando XML

Orientador: Professor Nesley Daher

Orientador Metodológico: Professora Patrícia Ferreira Santiago

CONCEITO:

1º. Avaliador: ______________________________________ Grau: ________________

2º. Avaliador: ______________________________________ Grau: ________________

CONCEITO FINAL: __________________________

Divinópolis, _______ de ______________________ de __________

_______________________________________________________

_______________________________________________________

_______________________________________________________

DEDICATÓRIA

Aos meus pais, que deram as primeiras lições de minha vida.

AGRADECIMENTOS

Aos professores que compartilharam seu conhecimento e me

motivaram a trilhar o caminho do desenvolvimento intelectual.

Aos professores Nesley e Patrícia, que me orientaram na

conclusão deste trabalho.

Agradeço a minha esposa Virgínia e minhas filhas Maria Clara

e Letícia pelo apoio e paciência que tiveram durante todo o curso.

SUMÁRIO

GLOSSÁRIO ................................................................................................................ VII

LISTA DE TABELAS .................................................................................................. X

LISTA DE ABREVIATURAS E SIGLAS .................................................................. XI

LISTA DE FIGURAS ................................................................................................... XII

RESUMO ...................................................................................................................... XIII

INTRODUÇÃO ............................................................................................................ 14

1. EDI – ELECTRONIC DATA INTERCHANGE...................................................... 16

1.1. EDI – Um diferencial no mundo dos negócios .......................................... 16

1.2. Definições................................................................................................... 16

1.3. O EDI no mundo ......................................................................... 18

1.4. O EDI no Brasil ........................................................................... 19

1.5. Componentes de um sistema EDI .............................................................. 20

1.5.1. Mensagens Padronizadas ............................................................. 20

1.5.2. Software EDI ............................................................................... 21

1.5.3. Rede de Comunicação de Dados ................................................. 22

1.6. EDI entre bancos e empresas ..................................................................... 23

1.6.1. Mensagens padronizadas – CNAB240 ....................................... 23

1.6.2. Software EDI – Sistema próprio x aplicativos dos bancos ......... 25

1.6.3. Redes de comunicação de dados– Office Banking 25

2. XML (EXTENSIBLE MARKUP LANGUAGE) .................................................... 27

2.1. Linguagens de Marcação – Conceitos ....................................................... 27

2.2. SGML (Standard Generalized Markup Language) ……………………… 28

2.3. HTML (Hyper Text Markup Language) ………………………………… 28

2.4. XML (Extensible Markup Language) ........................................................ 29

2.4.1. Características ............................................................................. 30

2.4.1.1. Extensibilidade ............................................................. 30

2.4.1.2. Legibilidade .................................................................. 31

2.4.1.3. Formato texto ................................................................ 31

2.4.1.4. Estrutura rígida e coesa ................................................ 31

2.4.1.5. Estrutura hierárquica .................................................... 32

2.4.1.6. Separação entre estrutura/conteúdo da apresentação ... 32

2.4.2. Componentes XML ..................................................................... 33

2.4.2.1. Elementos ..................................................................... 33

2.5.3.2. Atributos ....................................................................... 34

2.5.3.3. Entidades ...................................................................... 34

2.5.3.4. Comentários .................................................................. 34

2.5.3.5. DTD (Document Type Definitions) ............................. 35

2.4.3. Processadores XML .................................................................... 36

2.4.4. Ferramentas XML ....................................................................... 36

2.4.5. Aplicações XML ......................................................................... 37

2.4.5.1. Iniciativas XML pelo mundo ........................................ 38

3. EDI ENTRE BANCOS E EMPRESAS USANDO XML ........................................ 40

3.1. Objetivos .................................................................................................... 40

3.2. Metodologia ............................................................................................... 40

3.3. Estudo de caso - CNAB240....................................................................... 42

3.4. Documento XML ....................................................................................... 45

CONCLUSÃO .............................................................................................................. 49

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 51

OBRAS CONSULTADAS ........................................................................................... 53

VII

GLOSSÁRIO

ANSI (American National Standards Institute): uma organização afiliada à ISO e que é

a principal organização norte-americana envolvida na definição de padrões (normas

técnicas) básicos.

Aplicativo XML: uma implementação específica do XML que é uma DTD ou conjunto de

DTD´s desenvolvidas para servirem a um propósito específico. Também conhecido como

vocabulário XML.

CNAB240: padrão para troca eletrônica de dados entre bancos e empresas desenvolvido

pela FEBRABAN.

DTD (Document Type Definitions): uma especificação XML para um documento que

organiza elementos estruturais e definições de marcação de modo que elas possam ser

usadas para criar documentos.

EDI (Electronic Data Interchange): é uma forma de intercâmbio de dados entre uma

empresa e seus parceiros, de um computador para outro através de redes públicas ou

privadas dedicadas, de acordo com um padrão reconhecido internacionalmente.

FEBRABAN (Federação Brasileira das Associações de Bancos): é uma entidade de

natureza civil, que opera em âmbito nacional, com o objetivo de representar os bancos e

contribuir para o aperfeiçoamento de suas atividades.

GML (Generalized Markup Language): meta-linguagem de marcação genérica baseada

em texto que deu origem a SGML.

Hipertexto: Forma não linear de apresentar informações. Tópicos de um texto podem ter

vínculos com outras partes do mesmo documento ou outros documentos, que por sua vez

podem estar vinculados a outras informações.

VIII

HTML (Hypertext Markup Language): l inguagem de marcação simples usada para criar

documentos de hipertexto que são independentes de plataformas, normalizada pelo W3C

(World Wide Web Consortium).

Processador XML: módulo de software que é usado para ler documentos XML e fornecer

acesso a suas estruturas internas, podendo ainda validar e analisar sua sintaxe. Também

pode ser chamado de interpretador, analisador sintático ou parser.

SGBD (Sistema Gerenciador de Banco de Dados): termo genérico para designar todo

software responsável pelo gerenciamento (armazenamento e recuperação) dos dados em

um banco de dados. Oracle, DB2 e SQL Server são exemplos de SGBDs.

SGML (Standard Generalized Markup Language): meta-linguagem de marcação

genérica baseada em texto usada para descrever o conteúdo e a estrutura de documentos.

Site: conjunto de páginas que identificam um endereço web.

UN/EDIFACT (United Nations Electronic Data Interchange For Administration,

Commerce and Transport): padrão para mensagens EDI desenvolvido sob o patrocínio

da ONU (Organização das Nações Unidas) utilizado em mais de 60 países.

X12: padrão para mensagens EDI desenvolvido pela ANSI americana, utilizado

principalmente nos Estados Unidos e Canadá.

XML (Extensible Markup Language): linguagem de marcação derivada da SGML, que

fornece uma forma padrão de codificar conteúdo altamente estruturado.

XSL (Extensible Style Language): mecanismo de folhas de estilo que permite

transformar documentos XML em documentos para exibição em dispositivos e sistemas

diferentes.

W3C (World Wide Web Consortium): é um consórcio formado por mais de 400

membros, formado em outubro de 1994, que tem como objetivo disciplinar e desenvolver o

IX

uso da WWW. O estabelecimento de padrões de linguagens voltadas para o

desenvolvimento de aplicações na Web, como HTML e XML, tem sido uma de suas

grandes contribuições.

Web: vide WWW.

WWW (World Wide Web): literalmente, teia de alcance mundial. Baseada em

hipertextos, integra diversos serviços que oferecem acesso, através de hiperlinks, a

recursos multimídia. Responsável pela popularização da rede, que agora pode ser acessada

através de interfaces gráficas de uso intuitivo, como o Internet Explorer ou Netscape.

X

LISTA DE TABELAS

1. Trecho do manual CNAB240 da FEBRABAN 22

2. Exemplo de especificação similar ao CNAB240 41

XI

LISTA DE ABREVIATURAS E SIGLAS

ABAC Associação Brasileira de Automação Comercial

ANSI American National Standards Institute

CNAB Centro Nacional de Automação Bancária

DTD Document Type Definitions

EAN European Article Numbering

EDI Electronic Data Interchange

UN/EDIFACT United Nations Electronic Data Interchange For Administration,

Commerce and Transport

FEBRABAN Federação Brasileira das Associações de Bancos

GML Generalized Markup Language

HTML Hyper Text Markup Language

ISO Interrnational Standard Organization

RENPAC Rede Nacional de Pacotes

SGML Standard Generalized Markup Language

RVA Redes de Valor Agregado

W3C World Wide Web Consortium

WWW World Wide Web

XML Extensible Markup Language

XSL XML Style Language

XII

LISTA DE FIGURAS

1. Troca de informações sem padronização ............................................................... 18

2. Troca de informações padronizadas ....................................................................... 18

3. Funcionamento de um software EDI .................................................................... 19

4. Componentes de um sistema EDI .......................................................................... 20

5. Estrutura hierárquica de um documento XML ....................................................... 29

6. Separação do conteúdo da apresentação em documentos XML ............................ 30

7. Janela de criação de documentos XML do aplicativo XML Spy ........................... 38

8. Estrutura básica de um arquivo padrão CNAB240 ................................................ 39

9. Exemplo de arquivo texto de campos de largura fixa .......................................... 41

10. DTD contendo regras de estrutura para documentos XML ................................. 42

11. Exemplo de documento XML .............................................................................. 43

12. Janela de mensagem do aplicativo XML Spy (1) ................................................ 44

13. Janela de mensagem do aplicativo XML Spy (2) ................................................ 44

14. Estrutura hierárquica do documento XML .......................................................... 45

XIII

RESUMO

Este trabalho analisa as vantagens da adoção da linguagem XML (Extensible

Markup Language) no desenvolvimento de aplicações para troca de informações entre

bancos e empresas, em substituição ao padrão atual de arquivos texto de campos de largura

fixa. Essa linguagem de estruturação de documentos, proposta em 1996 pelo W3C (World

Wide Web Consortium), vem sendo adotada, no mundo todo, como padrão para o

desenvolvimento de aplicações onde seja necessário o intercâmbio de informações entre

sistemas heterogêneos. O tema é desenvolvido a partir do levantamento bibliográfico sobre

intercâmbio eletrônico de dados, ou EDI (Electronic Data Interchange), como é

mundialmente conhecido, sua evolução e utilização pelos bancos brasileiros. Logo em

seguida, é feita uma apresentação da linguagem de marcação XML, seu histórico,

características, principais componentes e recursos, além de uma lista com algumas

iniciativas XML pelo mundo. Com base nesse referencial teórico, é desenvolvida uma

pequena aplicação de pagamentos diversos que serve de base para comparações entre o

modelo atual de arquivos texto de campos de largura fixa e o modelo de documentos XML.

Por fim, a conclusão traz algumas análises sobre a viabilidade e vantagens de

implementação de soluções baseadas em XML, fornecendo subsídios para novos trabalhos

na área de engenharia de software.

Palavras Chaves: informática, automação bancária, redes de comunicação, Internet,

intercâmbio eletrônico de dados, engenharia de software, EDI, XML, CNAB,

FEBRABAN.

14

INTRODUÇÃO

Atualmente, a troca eletrônica de informações entre empresas, ou EDI (Electronic

Data Interchange) como é mundialmente conhecido, tornou-se fundamental. A necessidade

de automatizar processos a fim de reduzir custos e aumentar a eficiência em toda cadeia

produtiva virou prioridade dentro dos planos de negócios das organizações. Dentre todos

os segmentos empresariais, se destaca na vanguarda dessa tecnologia o segmento bancário,

devido ao alto índice de automação e pela sua longa história e experiência em EDI.

Desde a década de 1980, os bancos brasileiros já oferecem aos clientes pessoa

jurídica a opção de substituírem a troca de papéis pela troca de dados via computador. O

grande problema, desde então, tem sido compatibilizar a troca de informações entre bancos

e empresas. Para isso, os bancos criaram padrões baseados em arquivo texto com campos

fixos que devem ser seguidos pelas empresas para troca de arquivos.

Surge, assim, um novo problema: a geração e o tratamento desses arquivos

segundo as normas estabelecidas pelos bancos. Essas normas envolvem esforço no estudo

de padrões de formatação e posterior codificação de rotinas que tratem cada tipo de

arquivo. Além disso, se uma empresa trabalha com mais de um banco, geralmente tem que

desenvolver uma rotina específica para cada um deles, visto que o “padrão” adotado por

essas instituições não é muito “padronizado”. Isso se traduz em custos que a empresa tem

de assumir para poder trocar informações com seu banco.

O objetivo desse trabalho é analisar as vantagens proporcionadas pela adoção da

linguagem XML (Extensible Markup Language) como padrão para o desenvolvimento de

aplicações para troca de informações entre bancos e empresas em substituição ao formato

atual. Padrão de indústria, desenvolvido pelo renomado consórcio W3C (World Wide

Web Consortium) em 1996, a XML fornece uma forma simplificada de codificar

documentos altamente estruturados. Além disso, características como simplicidade,

flexibilidade, portabilidade, alta legibilidade para máquinas e homens, facilidade de

aprendizado e rapidez no desenvolvimento de aplicações, tornam a XML ideal para troca

de informações entre sistemas heterogêneos.

15

Tal estudo se justifica, porque acredita-se que com a adoção da XML pelos

bancos, as empresas terão uma significativa redução de custos e tempo de desenvolvimento

de aplicações para EDI. Pequenas empresas que não podem desenvolver sistemas próprios,

tem de se contentar com os aplicativos oferecidos pelos bancos, não se beneficiando

totalmente do EDI. Para os bancos, a flexibilidade e simplicidade proporcionada pela XML

poderão ser traduzidas em mais negócios, através da popularização do EDI.

Para tanto, foi feita pesquisa bibliográfica com a finalidade de colher informações

suficientes sobre o EDI e a XML. Na primeira parte do trabalho, é mostrado o histórico do

EDI no Brasil e no mundo, os principais componentes de um sistema EDI, seu

funcionamento, e a forma como o mesmo é utilizado pelos bancos brasileiros. Como

suporte teórico foi utilizado os trabalhos acadêmicos GUIMARÃES (1994) e MARQUES

(2003), além do manual EAN BRASIL (2003).

Na segunda parte, é feita uma introdução à linguagem a XML, sua especificação

formal, características técnicas, principais componentes e alguns exemplos de aplicações

baseadas nessa linguagem. O suporte teórico veio dos livros PITTS-MOULTIS (2000),

CARLSON (2002) e MCGRATH (1999), dos trabalhos acadêmicos SANTOS (2002) e

MARQUES (2003), além da especificação BRAY (2000).

Na terceira parte, são avaliadas as dificuldades em desenvolver aplicações

compatíveis com os sistemas dos bancos, utilizando-se o padrão atual de arquivos, através

de um estudo de caso baseado no manual FEBRABAN (2002). Logo em seguida, é

apresentado um protótipo de aplicação XML utilizado para efetivação de pagamentos

(transferência de fundos). Através de comparações entre o método atual e a solução

proposta, são analisados os reais benefícios advindos da utilização do XML em aplicações

EDI.

A parte final é destinada à conclusão do trabalho, onde é determinada a

viabilidade de implementação da solução baseada em XML. Com isso, esse estudo se

apresenta como base para futuras reflexões na área de troca de informações entre sistemas

heterogêneos, bem como ponto inicial para o desenvolvimento de soluções de intercâmbio

eletrônico de dados entre bancos e empresas usando XML.

16

1. EDI – ELECTRONIC DATA INTERCHANGE

Este capítulo traz uma breve descrição sobre intercâmbio eletrônico de dados, ou

EDI (Electronic Data Interchange), definições, histórico, evolução da tecnologia no Brasil

e no mundo, padrões utilizados e principais componentes. Aborda também o utilização do

EDI dentro do setor bancário brasileiro.

1.1. EDI – Um diferencial no mundo dos negócios

Tradicionalmente, empresas de todos os tipos e tamanhos geram e processam

uma grande quantidade de documentos em papel. A maioria já utiliza os computadores

para gerenciar processos de negócios, editar documentos e textos, normalmente através da

digitação manual de dados. Em outras palavras, encontram no computador apenas uma

nova ferramenta para continuar suas atividades da maneira antiga.

Encontrar uma maneira de automatizar processos manuais e diminuir os gastos

com emissão e processamento de documentos em papel certamente é uma idéia que atrai

executivos de qualquer empresa que deseja aumentar sua produtividade e lucratividade. O

EDI foi criado justamente com foco nestes simples conceitos. Por exemplo, em vez de

datilografar uma ordem de compra e enviar via Correios ou fax para o fornecedor, a

empresa envia através da Internet uma representação digitalizada desta, que é processada

automaticamente pelos computadores do fornecedor.

1.2. Definições

O EDI pode ser definido de maneira simples como a troca de dados padronizados

entre dois computadores. Apesar de verdadeira, essa definição não é esclarecedora nem

abrangente o suficiente. Autores de áreas diversas como administração, finanças e

tecnologia, já apresentaram suas definições para o EDI. Vejamos as definições de alguns

autores, citadas em GUIMARÃES (1994, p.22):

17

a) CASH & KONSYNSK (1985): “É um sistema de informações

automatizadas que envolve duas ou mais empresas.”

b) GELFOND e DAVIS (1987): “É um sistema que permite que documentos

padronizados possam ser mandados do computador de uma empresa para o

de outra.”

c) KASTIEL (1987): “É uma nova forma de comunicação mais efetiva e

menos onerosa. Suas aplicações referem-se à comunicação entre empresas,

tornando-se suporte, inclusive, para outras tarefas, como produção e

treinamento.”

d) MONZKA, CARTER (1988): “É a transmissão eletrônica direta,

computador para computador, de papéis padronizados como ordens de

compra, pedidos, etc. entre duas organizações.”

e) MOORE (1987): “EDI é usualmente definido como a transferência direta

de dados negociais estruturados entre computadores por meios

eletrônicos.”

Para esse trabalho, uma definição mais clara e completa sobre EDI é a

apresentada pela EAN Brasil:

“A transferência de dados estruturados, pelos padrões acordados de

mensagens, de um aplicativo de computador a outro por meio eletrônico e com

um mínimo de intervenção humana.”(EAN BRASIL, 2003, p.8).

Como se pode ver, o conceito básico de EDI é a transferência eletrônica de dados

padronizados entre computadores de empresas diferentes. Processamento e resposta

imediatos não são necessários. Os dados podem ser armazenados pelo computador destino

para processamento posterior. Esses dados são representações digitais de documentos

impressos diversos tal como ordens de compra, faturas e pagamentos.

18

Dentre as principais características do EDI, a mais importante delas é a

padronização. O estabelecimento de normas e padrões para troca de dados soluciona vários

problemas, como incompatibilidade entre sistemas heterogêneos, além de reduzir custos no

desenvolvimento de sistemas de EDI. Foi o estabelecimento de padrões que viabilizou a

aceitação e utilização do EDI por empresas de todo o mundo. Entre os principais padrões

adotados estão o UN/EDIFACT, mais utilizado na Europa e Ásia e escolhido pela ONU

para ser o padrão mundial, e o ANSI X12, adotados por Canadá e Estados Unidos.

1.3. O EDI no mundo

O EDI surgiu no final da década 1960 nos Estados Unidos, com a General Motors

interagindo com alguns de seus fornecedores e com mais oito bancos (GUIMARÃES,

1994, p.23). Desde então, várias empresas começaram a implantar sistemas EDI baseados

em formatos próprios e redes proprietárias. A medida que o número de parceiros

comerciais foi aumentando, o custo com a tradução de mensagens trocadas foi crescendo

numa escala bem maior, forçando as mesmas a desenvolverem iniciativas setoriais de

padronização de mensagens.

Esse movimento de iniciativas setoriais, que ocorreu de forma praticamente

simultânea nos Estados Unidos e Europa na década de 1970, gerou vários padrões para

troca de dados entre empresas de um mesmo segmento de mercado. Entre eles podemos

citar:

• Estados Unidos:

� TDCC (Transport Data Co-ordinattion Committee) – criado em 1975 para o

setor de transportes;

� UCS (Uniform Communication Standard) – criado entre 1977 e 1982 para o

setor de supermercados;

� foram criados ainda outros padrões para setores bancários, automotivo,

seguros, entre outros.

• Europa:

19

� DAKOM – criado na Suécia em 1972 para o setor de varejo e distribuição;

� GENCOD – criado na França em 1974 para o setor de varejo e distribuição;

� ODETTE – setor automotivo;

� SWIFT – setor bancário.

Com a rápida disseminação do EDI, logo surgiu a necessidade de integração de

sistemas entre empresas de segmentos diferentes do mercado. Com isso, surgiram projetos

para unificação dos padrões setoriais. Nos Estados Unidos, a ANSI começou a

desenvolver, em 1978, um padrão mais amplo para EDI que foi chamado de X12.

No início da década de 1980, as Nações Unidas formaram um grupo de trabalho

para definir um padrão internacional multi-setorial para o EDI. A partir dos trabalhos deste

grupo, nasceu o padrão UN/EDIFACT (United Nations Electronic Data Interchange for

Administration, Commerce and Transport). Endossado pela ISO (Interrnational Standard

Organization) em 1987, como a norma ISO 9735, hoje o padrão UN/EDIFACT contempla

mais de 200 documentos diferentes, atendendo as necessidades de vários segmentos de

mercado, sendo adotado por mais de 60 países. (EAN BRASIL. 2003. p.15).

1.4. O EDI no Brasil

No Brasil, os bancos foram os primeiros a utilizar o EDI. A primeira implantação

de um sistema de troca eletrônica de informações ocorreu no ano de 1964. Em 1979, a

FEBRABAN (Federação Brasileira das Associações de Bancos), através de seu órgão de

assessoria CNAB (Centro Nacional de Automação Bancária), desenvolveu o padrão

CNAB, ainda hoje adotado por todos os bancos brasileiros.

Em 1987, a ABAC (Associação Brasileira de Automação Comercial) , atualmente

EAN Brasil, formou um grupo de trabalho com representantes do comércio, indústria,

bancos e prestadores de serviços de telecomunicações, com a finalidade de instituir o que

foi chamado na época de “linguagem comum” nas operações de negócios. Por estar filiada

a EAN Internacional desde 1985, a escolha recaiu sobre o padrão de mensagens

UN/EDIFACT , que estava em vias de ser lançado (GUIMARÃES. 1994. p.23).

20

Em 2001, o Banco Central do Brasil instituiu o SPB (Sistema de Pagamentos

Brasileiros), onde os integrantes do Sistema Financeiro Nacional passaram a informar em

tempo real todos os lançamentos de liquidação financeira na conta “Reservas Bancárias” 1.

Para a troca de mensagens padronizadas, o Banco Central do Brasil adotou o XML 2 como

linguagem básica, demonstrando uma tendência mundial (Banco Central do Brasil. 2000.

p.6).

Desde então, tem havido uma gradual introdução das práticas do EDI entre as

empresas brasileiras. Com a popularização dos microcomputadores, propriciada pela

rápida evolução da tecnologia da informática, além do advento da Internet, mais e mais

empresas tem tido acesso a soluções antes só disponíveis para grandes corporações.

1.5. Componentes de um sistema EDI

De acordo com o EAN BRASIL (2003, p.9-11), um sistema EDI é composto de

três itens básicos: mensagens padronizadas, software de EDI e meios de comunicação.

1.5.1. Mensagens Padronizadas

As mensagens padronizadas são o principal componente de um sistema EDI.

Como já escrito anteriormente, no início do EDI, cada empresa estabelecia seus padrões

para troca de dados com parceiros comerciais. À medida que o número de parceiros

aumentava, crescia também os custos com o desenvolvimento de novos conversores dos

dados destes novos parceiros. Além disso, controlar todos estes padrões ficava cada vez

mais difícil.

21

Empresa 1

Empresa 2

Empresa 3

Empresa 4

Empresa 1

Empresa 2

Empresa 3

Empresa 4

Padrão EDI

Figura 1 - Troca de informações sem padronização

Fonte - EAN BRASIL, 2003, p.9

Utilizando-se uma linguagem comum para troca de informações, as empresas

diminuem drasticamente os custos e prazos para implantação de um sistema EDI com um

novo parceiro. Basta desenvolver um conversor EDI uma única vez que já se está

preparado para trocar informações quaisquer parceiros comerciais.

Figura 2 - Troca de informações padronizadas Fonte - EAN BRASIL, 2003, p.10

1.5.2. Software de EDI

Também chamado de conversor de EDI, o software de EDI tem como finalidade

básica traduzir as mensagens recebidas num determinado padrão, como o UN/EDIFACT

ou CNAB, para o formato de dados utilizado pelos sistemas internos de uma empresa, e

vice-versa. Além disso, ele deve ser flexível o suficiente para conter informações de

22

parametrização de perfis de diversos parceiros comerciais, e até mesmo um módulo de

comunicação direta com a rede de comunicação utilizada para troca das mensagens. Deve

ter ainda recursos para gerenciamento dos documentos digitais trocados, ferramentas de

auditoria e controle de acesso através do uso de senhas.

Figura 3 - Funcionamento de um software EDI Fonte - Definido pelo autor

1.5.3. Redes de Comunicação de Dados

Os dados convertidos através do software EDI para mensagens padronizadas

deverão ser enviados da empresa remetente para a empresa destinatária através de uma

rede de comunicação de dados. De acordo com a viabilidade técnica e econômica, as

empresas podem trocar as informações de várias maneiras: linhas privadas alugadas ponto

a ponto, redes de telefonia pública ou mesmo Internet.

Existem, ainda, as Redes de Valor Agregado (RVA), criadas com o objetivo de

reduzir os custos e facilitar a troca de mensagens EDI entre empresas. As RVA’s

funcionam de forma análoga aos Correios. Cada empresa que contrata seus serviços recebe

uma caixa postal eletrônica onde irá receber as mensagens de seus parceiros. Da mesma

forma, para enviar uma mensagem para um parceiro, basta endereçar a mensagem para a

caixa postal do destinatário, que oportunamente irá receber a referida mensagem.

Sistema interno

Software EDI

Mensagem EDI

23

Rede de Comunicação

Empresa 1

Software EDI

Dados internos

Mensagem EDI

Empresa 2

Software EDI

Dados internos

Mensagem EDI

Figura 4 - Componentes de um sistema EDI Fonte - EAN BRASIL, 2003, p.11

1.6. EDI entre bancos e empresas

Atualmente, os bancos oferecem uma ampla gama de serviços e produtos através

de troca eletrônica de dados direcionados para o segmento pessoa jurídica. São serviços e

produtos que vão desde cobrança bancária e extratos de conta corrente, até pagamentos

diversos. Como vantagens na utilização destes serviços de EDI podemos citar a agilidade,

segurança e redução de tarifas.

1.6.1. Mensagens padronizadas – CNAB240

Como padrão na troca de arquivos, os bancos adotam atualmente o formato

CNAB240 definido pela FEBRABAN. Esse padrão, na versão 5.0 de 16/04/2003,

contempla vários produtos e serviços, tais como cobrança bancária, pagamentos através de

crédito em conta, extratos e débito em conta.

O manual contendo as especificações do formato CNAB240 tem

aproximadamente 150 páginas e está disponível no site http://www.febraban.org.br. Ele

traz informações detalhadas para a elaboração de arquivos texto contendo registros (linhas

de um arquivo texto) e campos de largura fixa. As instruções sobre os registros e campos

24

são apresentados no formato de tabelas, geralmente com as seguintes informações: nome

do campo, posição inicial e final (coluna no arquivo texto), casas decimais, formato

(alfanumérico ou numérico), valor padrão e descrição do campo. Segue abaixo um trecho

de especificação de um registro do formato CNAB240:

Campo

Posição Nº Nº Formato Default Des-

De Até Dig Dec crição

01.9 Banco Código do Banco na Compensação 1 3 3 - Num G001

02.9 Lote Lote de Serviço 4 7 4 - Num '9999' *G002

03.9

Controle

Registro Tipo de Registro 8 8 1 - Num '9' *G003

04.9 CNAB Uso Exclusivo FEBRABAN/CNAB 9 17 9 - Alfa Brancos G004

05.9 Qtde. de Lotes Quantidade de Lotes do Arquivo 18 23 6 - Num G049

06.9 Qtde. de Registros Quantidade de Registros do Arquivo 24 29 6 - Num G056

07.9

Totais

Qtde. de Contas Concil. Qtde de Contas p/ Conc. (Lotes) 30 35 6 - Num *G037

08.9 CNAB Uso Exclusivo FEBRABAN/CNAB 36 240 205 - Alfa Brancos G004

Tabela 1 - Trecho do manual CNAB240 da FEBRABAN Fonte - FEBRABAN, 2002, p.6

Com base nessas informações, empresas e bancos desenvolvem sistemas que

geram e processam arquivos neste formato. Aqui se encontra o principal problema do

padrão CNAB: ao desenvolver os sistemas, cada banco incorpora características e recursos

próprios, distorcendo o padrão. Com isso, empresas que desenvolvem sistemas para

trabalhar com um banco, geralmente tem de refazer todo o trabalho quando trocam de

banco. Daí advém a principal dificuldade dos desenvolvedores de software ao criar

sistemas compatíveis com os bancos nacionais.

1.6.2. Software EDI – Sistema próprio x aplicativos dos bancos

A fim de disseminar com maior velocidade a adoção do EDI pelas empresas, os

bancos desenvolveram uma série de aplicativos compatíveis com o padrão CNAB240, para

distribuição gratuita entre as empresas que não possuem recursos para o desenvolvimento

de aplicativos EDI. Esses aplicativos permitem a impostação manual dos dados a serem

enviados para o banco, bem como rotinas de processamento dos arquivos recebidos.

Como principal vantagem, as empresas não precisam gastar recursos no

desenvolvimento de sistemas compatíveis com os bancos. Como desvantagem, as empresas

3 Rede de comutação de pacotes da Embratel, utilizada para troca de mensagens padronizadas de sistemas EDI.

25

não se beneficiam totalmente do EDI, visto que as mesmas tem um trabalho adicional de

digitar manualmente as informações que serão enviadas aos bancos. Dessa forma, somente

as instituições financeiras se beneficiam totalmente do EDI.

A empresa também pode optar por desenvolver um sistema próprio para troca de

informações com o banco. Neste caso, ela arca com todos os custos de desenvolvimento.

Como em qualquer projeto de engenharia de software, o desenvolvimento aplicativo

próprio pelas empresas normalmente passa por cinco etapas: análise, codificação, testes,

colocação em produção e manutenção. Destas etapas, a mais crítica é a etapa de testes, que

neste caso envolve as equipes técnicas da empresa e do banco. Nesta etapa, a empresa deve

enviar ao banco vários arquivos de testes que serão validados pelos técnicos do banco antes

que o sistema seja colocado em produção.

1.6.3. Redes de comunicação de dados– Office Banking

Os bancos, normalmente, oferecem uma solução proprietária para troca de dados

com as empresas. Geralmente chamados de Office Banking, estes aplicativos trafegam

dados sobre a Internet, e oferecem uma interface simples para a transferência de arquivos

padronizados.

Como alternativa, os bancos também oferecem a troca de arquivos através de

RVA´s, mais notadamente o serviço RENPAC 3 da Embratel. A principal vantagem desse

serviço, está na utilização de somente um aplicativo para troca de informações, mesmo que

a empresa opere com vários bancos.

26

2. XML (Extensible Markup Language)

Neste capítulo, serão apresentados os conceitos teóricos por trás das linguagens

de marcação e um breve histórico. A seguir, tem-se um breve relato sobre duas linguagens

antecessoras a XML, a SGML e a HTML. Então, é apresentada a linguagem de marcação e

estruturação de dados XML (Extensible Markup Language), suas características e

principais recursos. Finalmente, são mostradas algumas iniciativas de desenvolvimento de

aplicações utilizando XML.

Essa fundamentação teórica se faz necessária para a construção de um protótipo

de aplicação XML para troca de informações entre bancos e empresas, apresentada no

capítulo 3.

2.1. Linguagens de Marcação - Conceitos

Quando se escreve algo num editor de texto qualquer, várias informações

referentes à formatação, tais como fontes, margens, parágrafos, etc, vão sendo adicionadas

junto ao texto automaticamente. Essas informações são utilizadas para controlar a

aparência final do documento durante sua visualização ou impressão. Esse conjunto de

informações são chamadas de marcações.

Mais do que controlar a formatação de documentos, as marcações também

podem conter informações acerca do significado de trechos de documentos. Com base

nestas informações, pode-se controlar a forma como estes trechos devem ser processados

pelos programas.

Segundo CARLSON (2002, p.15), “a característica mais (sic) fundamental de

uma linguagem de marcação é sua capacidade em descrever símbolos ou marcadores

inseridos em um documento de texto e definir o significado que aqueles símbolos dão ao

texto associado”.

27

Baseado neste conceito, várias linguagens vem sendo criadas desde a década

de 1960. Entre elas podemos citar a SGML, HTML e a XML.

2.2. SGML (Standard Generalized Markup Language)

A SGML foi desenvolvida a partir da idéia original era criar uma meta linguagem

de marcação universal, que servisse de modelo para criação de outras linguagens de

marcação. Seu desenvolvimento começou na década de 1960, quando a IBM trabalhava na

linguagem GML (Generalized Markup Language). A IBM procurava uma forma fácil e

padronizada para descrever e trocar documentos com a maioria dos formatos existentes. A

IBM continuou desenvolvendo a linguagem até que em 1986 a ISO adotou a GML como

linguagem de marcação genérica, estabelecendo o padrão ISO 8879, e trocando seu nome

para SGML (PITTS-MOULTIS, 2000, p.34).

A SGML tem uma enorme quantidade de recursos incorporados, fato que a torna

muito poderosa e abrangente, mas também muito complexa. Essa complexidade torna sua

implementação muito difícil em qualquer aplicação.

Para contornar essa complexidade, foram criados subconjuntos da SGML

direcionados para aplicações específicas. HTML e XML são exemplos de linguagens

criadas a partir dos conceitos fundamentados pela SGML.

2.3. HTML (Hyper Text Markup Language)

A HTML foi lançada em 1990 por Tim Berners-Lee, com o propósito de criar

uma linguagem simples para publicação de documentos na web, baseada na linguagem

SGML. Com um conjunto reduzido de marcações, a HTML oferece recursos para

formatação de documentos, além de navegação entre documentos através de ligações de

hipertexto. Devido a sua simplicidade e ao padrão aberto, logo ela tornou-se um sucesso na

comunidade Internet, até ser oficialmente proclamada um padrão pelo W3C em 1995, com

o lançamento do padrão HTML 2.0 (SANTOS, 2002. p.11).

28

Apesar de ser muito utilizada ainda hoje, a HTML tem várias limitações. Seu

conjunto reduzido de marcações não permite muita flexibilidade. Além disso, suas

marcações esclarecem muito pouco a respeito do significado e estrutura dos dados contidos

num documento. Pensando nisso, os engenheiros de software começaram a imaginar uma

nova linguagem que tivesse o poder e flexibilidade da SGML e a simplicidade da HTML.

A essa nova linguagem foi dado o nome de XML.

2.4. XML (Extensible Markup Language)

A linguagem XML foi desenvolvida em 1996 pelo Grupo de Trabalho XML,

instituído pelo W3C, liderado por Jon Bosak da Sun Microsystems. Baseada na SGML, a

XML “descreve uma classe de dados chamada documentos XML e descreve parcialmente

o comportamento de programas de computador que os processa” (BRAY, 2000).

Para o desenvolvimento da XML, o W3C estipulou objetivos principais que

guiaram a construção da linguagem. Esses objetivos, citados em BRAY (2000), são os

seguintes:

a) a XML deve ser utilizado de forma direta e objetiva na Internet;

b) a XML deve suportar uma ampla gama de aplicativos;

c) a XML deve ser compatível com a SGML;

d) a XML deve ser fácil o bastante para escrever programas que processem

documentos XML;

e) o número de recursos adicionais na XML deve ser mantido em um nível

mínimo, idealmente zero;

f) os documentos XML precisam ser legíveis e relativamente claros;

g) o projeto da XML deve ser preparado rapidamente;

h) o design da XML deve ser formal e conciso;

i) os documentos XML devem ser fáceis de ser criados;

j) a concisão na marcação da XML é de pouca importância.

29

2.4.1. Características

O poder e flexibilidade da linguagem XML reside em suas muitas características.

As principais são apresentadas a seguir.

2.4.1.1. Extensibilidade

Ao contrário das outras linguagens de marcação, que tem um conjunto fixo de

marcas, a XML permite que os desenvolvedores criem suas próprias marcações de acordo

com suas necessidades. (MARQUES, 2003, p.12).

A figura 5 abaixo mostra um exemplo de documento XML criado para armazenar

uma agenda de telefones.

Figura 5 - Exemplo de código XML Fonte - Definido pelo autor

Nesse exemplo, foram criadas livremente as marcas <agenda> , <nome>,

<telefone>, <residencial> e <comercial>. Essas marcas atendem as

necessidades para criação de uma agenda de telefone simples.

<?xml version =”1.0”>

<agenda>

<nome>FULANO</nome>

<telefone>

<residencial>37-3333-4444</residencial>

<comercial>37-3333-5555</comercial>

</telefone>

<nome>BELTRANO</nome>

<telefone>

<residencial>37-3333-6666</residencial>

<comercial>37-3333-7777</comercial>

</telefone>

</agenda>

30

Observação importante: todo documento XML começa com a seguinte

declaração:


2.4.1.2. Legibilidade

Conforme se pode ver pelo exemplo da figura 5, os documentos XML são

altamente legíveis para o ser humano. Uma boa escolha para os nomes de elementos,

fazem com que os documentos sejam praticamente auto-descritíveis, dispensando na

maioria das vezes uma documentação anexa para entender a estrutura desses documentos.

Essa característica atende ao objetivo “f” estabelecido pelo W3C (BRAY, 2000).

2.4.1.3. Formato texto

Os documentos criados com a XML são arquivos de texto puro, tornando-os

compatíveis com qualquer plataforma de hardware e software.

2.4.1.4. Estrutura rígida e coesa

Apesar da liberdade na criação de marcas, o XML tem uma estrutura rígida que

deve ser seguida obrigatoriamente. Duas regras básicas determinam essa estrutura:

primeiramente, deve existir um único elemento raiz que contém todos os outros elementos.

No exemplo acima, temos o elemento raiz <agenda> . Em segundo lugar, toda marca de

abertura tem sua correspondente marca de encerramento. Por exemplo, <nome> e

</nome> . Essa estrutura rígida evita ambigüidades e facilita o desenvolvimento de

aplicações que processem documentos XML (MARQUES, 2003, p.13).

Quando um documento segue estas duas regras básicas de sintaxe, pode-se dizer

que o documento é bem formado (existem outras regras de sintaxe XML a serem seguidas

mas não são importantes para o presente trabalho).

4 Uma folha de estilo fornece informações sobre o estilo e a apresentação do documento para o pacote de software usado para processar o documento

31

2.4.1.5. Estrutura hierárquica

A estrutura rígida e coesa da XML determina outra importante característica: todo

documento XML tem uma estrutura física hierárquica (MCGRATH, 1999, p.89). Isso fica

claro quando se transcreve um documento XML para um diagrama.

A figura 6 mostra o diagrama do documento XML da figura 5.

Figura 6 - Estrutura hierárquica de um documento XML Fonte – Definido pelo autor

2.4.1.6. Separação entre estrutura, conteúdo e apresentação

Outra característica importante da XML é a separação entre estrutura, conteúdo e

apresentação dos dados (MCGRATH, 1999, p.13). Um documento XML contém a

estrutura e o conteúdo, que são as marcações e os dados de caracteres, respectivamente.

Normalmente, a apresentação é tratada através da linguagem acessória chamada XSL

(Extensible Style Language). Essa separação entre conteúdo, estrutura e apresentação

permite que os dados sejam formatados de acordo com necessidades específicas.

A figura 7 mostra um exemplo de como usar folhas de estilo 4 XSL para exibir o

conteúdo de um documento XML em vários dispositivos diferentes.

Agenda

Nome Nome Telefone Telefone

Residencial Comercial Residencial Comercial

32

Figura 7 - Separação do conteúdo da apresentação em documentos XML Fonte – Definido pelo autor

2.4.2. Componentes XML

A linguagem XML oferece alguns componentes para a construção de documentos

estruturados. A seguir, são apresentados alguns desses componentes, que serão usados no

desenvolvimento do trabalho.

2.4.2.1. Elementos

Os elementos são os blocos elementares para construção de documentos XML

(MCGRATH, 1999, p.94). Um elemento é uma estrutura que descreve um dado. No nosso

exemplo, temos o elemento <agenda>...</agenda> que armazena todos os dados

contidos no documento. Um elemento é também definido como um contêiner para

armazenamento de dados, sempre composto de uma marca inicial e final. Um elemento

pode conter uma seqüência de caracteres, outros elementos ou uma mistura dos dois, o que

caracteriza a estrutura hierárquica da XML. Temos ainda o conceito de elemento vazio,

que não armazena nenhum dado, sendo representado da seguinte forma: <vazio/>.

Esse elemento significa o mesmo que <vazio></vazio>.

Documento XML (estrutura/conteúdo)

Folhas de estilo XSL (apresentação)

Navegador web

Palm Top

Celular

Impressora

Processador XSL

33

2.4.2.2. Atributos

Segundo PITTS-MOULTIS (2000, p.32), “atributos são basicamente simples

fontes de informações adicionais sobre um elemento”. São representadas na forma [nome

do atributo] “=” [valor do atributo]. A partir do exemplo da figura 5,

pode-se adicionar um atributo ao elemento <residencial> da seguinte forma:

<residencial alugado=”nao”>37-3333-4444</residencia l>

Essa informação adicional informa se o telefone residencial desse contato é

alugado ou não.

2.4.2.3. Entidades

Entidades são quaisquer conjuntos de caracteres que se quer referir num

documento XML (PITTS-MOULTIS, 2000, p.32). Podem ser utilizadas de duas maneiras:

• digitação de caracteres especiais no conteúdo de um elemento XML, para serem

processadas corretamente pelo processador XML;

• automatizar a inserção de dados repetitivos dentro de um documento XML.

No primeiro caso, se for necessário digitar o caractere “<” dentro do conteúdo de

um elemento, sem causar erro do processador, deve-se substituir o caractere “<” pela

entidade genérica “&gt”, embutida na XML.

No segundo caso, o usuário pode definir suas próprias entidades genéricas para

especificar quaisquer dados de caracteres. Depois de definida, a entidade pode ser incluída

dentro de um documento XML uma ou mais vezes através de uma referência de entidade.

Uma entidade é referenciada na forma &[nome da entidade] .

34

2.4.2.4. Comentários

Como qualquer linguagem, a XML permite a inserção de comentários ao longo

de um documento. Eles possuem a mesma forma dos comentários HTML (MCGRATH,

1999, p.102). Exemplo:

<! -– comentário -- !>

Observação importante: a seqüência de dois traços (“--") não pode ocorrer dentro

de um comentário, pois isso ocasionará uma mensagem de erro do processador.

2.4.2.5. DTD (Document Type Definitions)

A XML possui um mecanismo especial que permite aos desenvolvedores

definirem regras que controlam a forma como os documentos devem ser estruturados. Esse

mecanismo, chamado de DTD - Document Type Definitions (definições de tipos de

documentos), define um vocabulário específico de marcações e permite que se façam

verificações na estrutura lógica de um documento XML (MARQUES, 2003, p.15).

Uma DTD pode conter regras que definem quais os elementos permitidos para

um documento, qual a ordem em que devem aparecer, qual o conteúdo e atributos desses

elementos e as entidades que podem ser usadas (SANTOS, 2002, p.15).

A partir do exemplo da figura 5, pode-se criar uma DTD com as seguintes regras:

a) o documento tem um elemento raiz chamado agenda, que possui um ou mais

elementos nomes e telefones, nesta ordem;

b) o elemento fone possui dois elementos, residencial e comercial, nesta ordem;

c) os elementos nome, comercial e residencial aceitam dados do tipo caractere

(#PCDATA).

35

Uma DTD com estas regras ficaria mais ou menos como na figura 8:

Figura 8 - Exemplo de uma DTD Fonte – Definido pelo autor

Existem dois tipos de DTD: interna e externa. Uma DTD é considerada interna

quando suas declarações são incluídas dentro do próprio documento XML. DTD externa é

aquela que é armazenada num arquivo separado do documento XML, geralmente com a

extensão “.dtd”.

Para que um documento seja validado por um processador XML, deve-se incluir

uma declaração de tipo de documento no início do mesmo, conforme abaixo:

<!DOCTYPE agenda SYSTEM “nome_da_DTD”>

Quando um documento é bem formado e segue as regras definidas numa DTD,

dizemos que o mesmo é válido.

2.4.3. Processadores XML

Os processadores XML, também chamados interpretadores ou analisadores

sintáticos, são uma classe especial de software interpretam arquivos XML. Segundo

MCGRATH (1999, p. 200), interpretar um documento XML “refere-se ao processo por

meio do qual os caracteres que formam o documento XML são categorizados tanto como

marcação ou dados de caracteres”. Eles separam as marcações dos dados de caracteres,

para em seguida enviá-los a algum aplicativo cliente, como um navegador web.

Além disso, eles tem a tarefa de verificar se os documentos XML são bem

formados e/ou válidos. Como já visto anteriormente, documentos XML são bem formados


<!ELEMENT agenda (nome+, fone+)>

<!ELEMENT fone (residencial, comercial)>

<!ELEMENT nome #PCDATA>

<!ELEMENT residencial #PCDATA>

<!ELEMENT comercial #PCDATA>

36

quando atendem as regras básicas da sintaxe XML. Já os documentos XML são válidos

quando além de serem bem formados, também atendem a todas as restrições de validade

(regras) estabelecidas por uma DTD relacionada. Quando um documento não é bem

formado e/ou válido, o processador XML reporta uma mensagem de erro fatal ao

aplicativo cliente (ou ao usuário), com a informação da linha onde o erro se encontra.

Existem dois tipos de processadores XML: os processadores de validação

verificam se os documentos são válidos e bem formados; já os processadores de não-

validação somente verificam se os documentos são bem formados.

Entre os processadores XML existentes no mercado podemos citar o MSXML da

Microsoft, Larval da Textuality, o XP de James Clark e o TclXML de Steve Ball.

2.4.4. Ferramentas XML

Existem hoje disponíveis uma infinidade de ferramentas que oferecem suporte ao

desenvolvimento em linguagem XML. Grandes empresas de software, como Microsoft,

Sun Microsystems, Oracle e Inprise, já demonstraram apoio irrestrito a linguagem XML

lançando pacotes de produtividade e desenvolvimento compatíveis com a linguagem.

Visual Studio .Net (Microsoft), Borland Delphi (Inprise) e Java Enterprise Edition (Sun

Microsystems) são exemplos de linguagens de programação que possuem recursos de

desenvolvimento compatíveis com a XML. Sistemas gerenciadores de bancos de dados

(SGBD) como Oracle, SQL Server (Microsoft) e DB2 (IBM) também suportam a

linguagem. Até mesmo o famoso pacote de escritório Microsoft Office na versão 2003 já

possui recursos para criação de documentos XML.

Existem ainda ferramentas de desenvolvimento específicas para XML, como por

exemplo o Bonfire Studio da NZ Software, XML Spy da Altova GmbH e o ADEPT-Editor

da ArborText, todas elas disponíveis para download na Internet.

37

2.4.5. Aplicações XML

Depois de compreender alguns conceitos fundamentais da XML, fica a pergunta:

o que é uma aplicação ou um aplicativo XML? Basicamente, uma DTD pode ser

considerada uma aplicação XML. Uma aplicação XML define um vocabulário e uma

gramática específicos com o objetivo de representar objetos dentro do universo definido

pelo desenvolvedor.

“Um aplicativo XML é uma DTD ou um conjunto de DTDs com um objetivo

específico. Além disso, há um acordo tácito entre as partes que usam o

aplicativo de que todos seguirão as mesmas regras. Os pacotes de software são

então desenvolvidos para funcionar com os dados analisados sintaticamente,

de acordo com a DTD do aplicativo” (PITTS-MOULTIS, 2000, p.133).

2.4.5.1. Iniciativas XML

Por causa da simplicidade e poder proporcionados pela XML, empresas e

governos de todo o mundo vem adotando a linguagem para desenvolver aplicações em

todas as áreas. Segue abaixo alguns exemplos de alguns vocabulários XML já

desenvolvidos:

• CDF (Channel Definition Fomat): vocabulário XML desenvolvido pela

Microsoft que permite ao desenvolvedor usar uma variedade de mecanismos de

remessa para publicar conjuntos de informações chamadas canais de qualquer

servidor web para qualquer aplicação compatível com a Internet.

• CML (Chemical Markup Language): vocabulário XML baseado em conteúdo e

apresentação que é usado para descrever e processar dados de compostos químicos.

• GedML (Genealogical Data in XML): vocabulário XML criado para fornecer um

método padrão de apresentação, intercâmbio e manipulação de dados genealógicos

através de uma rede.

• MathML (Mathematical Markup Language): vocabulário XML baseado em

conteúdo e apresentação que é usado para descrever e processar dados

matemáticos.

38

• OFX (Open Financial Exchange): vocabulário XML desenvolvido pela

Microsoft, Intuit e Checkfree objetivando a padronização do formato de dados

disponibilizados por instituições financeiras.

• PGML (Precision Graphics Markup Language): vocabulário XML que fornece

uma linguagem gráfica 2D e que pode ser ampliada, desenvolvida para oferecer

elementos gráficos vetoriais e especificações gráficas precisas para artistas.

• SPB (Sistema de Pagamentos Brasileiro): sistema desenvolvido pelo Banco

Central do Brasil que utiliza a linguagem XML para troca de mensagens com

instituições financeiras.

• TML (Tutorial Markup Language): vocabulário XML desenvolvido

especificamente para criar e trabalhar com aplicativos educativos.

• XML/EDI: iniciativa que procura compatibilizar as mensagens UN/EDIFACT com

a XML.

39

3. EDI ENTRE BANCOS E EMPRESAS USANDO XML

Neste capítulo é mostrado um exemplo de aplicação XML como alternativa ao

padrão adotado hoje pelos bancos de arquivos texto de campos de largura fixa. Essa

pequena aplicação consiste na definição de uma DTD padrão, que contém regras para

construção de documentos XML para transferência de fundos entre uma empresa fictícia e

seus fornecedores.

3.1. Objetivos

O objetivo da construção dessa aplicação XML é fazer um comparativo entre os

dois métodos de estruturação de dados para EDI – arquivos texto de campos de largura fixa

e documentos XML, a fim de verificar as vantagens e desvantagens de cada um.

3.2. Metodologia

Para o desenvolvimento desse trabalho, foi feita uma breve análise sobre o padrão

atual para troca de dados entre bancos e empresas. Para isso, foi utilizado como referência

o manual FEBRABAN (2002), disponível no site http://www.febraban.org.br. Como já

abordado no capítulo 1, esse documento contempla o padrão CNAB240, que abrange

diversos serviços, desde cobrança bancária e extratos de conta até pagamentos diversos

através de transferência eletrônica de fundos.

Devido abrangência e complexidade desse padrão - são quase 150 páginas de

especificações - , decidiu-se pela elaboração de um padrão simplificado para pagamentos

diversos através de transferência entre contas. Esse padrão foi codificado na forma de um

pequeno manual, que contém instruções sobre registros e campos utilizados em

transferências entre contas correntes. Depois, foi criado um pequeno arquivo texto com

alguns lançamentos para transferência de fundos, baseado nesse padrão fictício.

40

Logo em seguida, foi elaborada uma pequena aplicação XML baseada numa

DTD. Essa DTD contém regras que definem um padrão simplificado para construção de

documentos XML de pagamentos diversos, de forma análoga ao padrão de arquivo texto

de campos fixos citado no parágrafo anterior. Essa DTD foi construída com o auxílio do

aplicativo XML Spy Home Edition (figura 9), versão 5.2, da Altova GmbH, disponível

para download em http://www.xmlspy.com/download_spy_home.html (acesso em 22 nov.

2003).

Finalmente, foi construído um documento XML seguindo as regras definidas na

DTD criada. O documento, também elaborado no aplicativo XML Spy, contém os mesmos

lançamentos de pagamentos existentes no arquivo de formato fixo citado anteriormente.

Dessa forma, foi possível fazer um comparativo entre os dois métodos.

Figura 9 - Janela de criação de documentos XML do aplicativo XML Spy

41

3.3. Estudo de caso – CNAB240

O padrão atual para troca de dados entre bancos e empresas é o chamado

CNAB240 – ele possui este nome porque cada linha de texto do arquivo deve ter 240

caracteres. As regras estabelecidas por este padrão são constituídas dos registros e campos,

seu tamanho e posição dentro de um arquivo texto. Para efeito de comparação, os registros

e campos são como linhas e colunas numa tabela, respectivamente. A figura 10 mostra a

estrutura em camadas de um arquivo CNAB240.

Figura 10 - Estrutura básica de um arquivo padrão CNAB240 Fonte – FEBRABAN, 2002, p.3

O registro header (cabeçalho) do arquivo contém informações sobre a empresa

que mantém o convênio EDI com o banco, data e número seqüencial do arquivo, além de

outras informações. Corresponde a primeira linha do arquivo.

O registro header (cabeçalho) do lote também contém informações sobre a

empresa, além de informações sobre natureza do lote de lançamentos que vem a seguir,

que podem ser lançamentos de cobrança, pagamentos diversos, extratos, débito em conta,

entre outros. Normalmente, corresponde a segunda linha do arquivo. Um arquivo

CNAB240 pode ter um ou mais lotes.

O(s) registro(s) detalhe(s) do lote trazem informações sobre os lançamentos

presentes no arquivo. Normalmente, cada linha corresponde a um lançamento distinto. Um

arquivo CNAB240 pode ter uma ou mais linhas de registros detalhe.

Registro header do arquivo

Registro header do lote

Registro detalhe(s) do lote . . .

Registro trailer do lote

Registro trailer do arquivo

42

O registro trailer (rodapé) do lote contém informações sobre o lote, como o

número de lançamentos e valor total do lote. Normalmente, corresponde a penúltima linha

do arquivo.

O registro trailer (rodapé) do arquivo, que contém informações sobre todo o

arquivo, como número de lançamentos e valor total do arquivo. Corresponde a última linha

do arquivo.

Para facilitar a compreensão de como funciona um arquivo de campos fixos como

o CNAB240, segue abaixo uma especificação simples para construção de arquivos texto

para transferência entre contas (tabela 2).

FORMATO DE ARQUIVO PARA TRANSFERÊNCIA ENTRE CONTAS

REGISTRO CABEÇALHO

DESCRICAO POSIÇÃO CONTEÚDO

TIPO REGISTRO 001-001 FIXO = 0

NOME DA EMPRESA 002-030 ALFANUMÉRICO

CNPJ 031-044 NUMÉRICO

NR. BANCO 045-047 NUMÉRICO

NR. AGÊNCIA 048-051 NUMÉRICO

NR. CONTA 052-061 NUMÉRICO

DATA GRAVAÇÃO 062-069 NUMÉRICO (DDMMAAAA)

NR. ARQUIVO 070-074 NUMÉRICO

REGISTRO DETALHE



NR. LANÇAMENTO 002-007 NUMÉRICO

NR. BANCO 008-010 NUMÉRICO

NR. AGÊNCIA 011-014 NUMÉRICO

NR. CONTA 015-024 NUMÉRICO

NOME CREDITADO 025-051 ALFANUMÉRICO

VALOR CREDITADO 052-066 NUMÉRICO

DATA CRÉDITO 067-074 NUMÉRICO (DDMMAAAA)

43

REGISTRO RODAPÉ



NR. LANÇAMENTOS 002-008 NUMÉRICO

VALOR TOTAL 009-023 NUMÉRICO

Tabela 2 - Exemplo de especificação similar ao CNAB240 Fonte – Definido pelo próprio autor

A partir da especificação da tabela 2, pode-se construir um arquivo texto que siga

estas orientações. A figura 11 mostra um exemplo de arquivo criado conforme o padrão da

tabela 2. Observação: uma “régua” foi colocada após o fim do arquivo para facilitar a

localização dos dados.

Figura 11 - Exemplo de arquivo texto de campo de largura fixa

Fonte – Definido pelo autor

A partir do exemplo da figura 11, pode-se fazer algumas observações:

• dados são codificados no formato texto;

• o arquivo isolado não é capaz de nos informar nada a respeito de sua estrutura e

significado dos dados ali contidos;

• estrutura frágil: o simples deslocamento de um caractere para esquerda ou direita

provoca a total desorganização de seu conteúdo;

• a análise do conteúdo do arquivo através de inspeção visual, mesmo com o auxílio

do manual de especificações, é extremamente difícil;

• se for preciso modificar a especificação de um arquivo deste tipo, geralmente será

necessário modificar toda sua estrutura.

0EMPRESA E CIA LTDA 123456780001129998888 00007777773012200300010

100000199988880000111111JOAO SILVA 00000000000500001122003

100000299988880000222222JOSE SILVA 00000000000800001122003

100000399988880000333333MARIA SILVA 00000000000700001122003

90000006000000000020000

--------------------------------------------------- ----------------------- 123456789012345678901234567890123456789012345678901 23456789012345678901234 1 2 3 4 5 6 7

44

3.4. Documento XML

A partir da análise do exemplo da tabela 2 e figura 11, segue abaixo uma

aplicação XML elaborada de acordo com as mesmas especificações. A aplicação consiste

numa simples DTD, criada com o auxílio da ferramenta XML Spy. Como se trata de um

arquivo texto, a mesma poderia ter sido elaborada através de um editor de textos qualquer.

Essa DTD é apresentada na figura 12.

Figura 12 - DTD “pagamentos.dtd” Fonte – Definido pelo autor

Segue abaixo alguns detalhes da criação da DTD, que ajudam na compreensão de

seu funcionamento.

•  : trata-se de um comentário explicando

a finalidade da DTD;

<?xml version="1.0" encoding="UTF-8"?>  <!ELEMENT pagamentos (cabecalho, lancamento+, rodap e)>  <!ELEMENT cabecalho (empresa, cnpj, nr_banco, nome_ banco, nr_agencia, nr_conta, data_arquivo, nr_arquivo)> <!ELEMENT empresa (#PCDATA)>  <!ELEMENT cnpj (#PCDATA)>  <!ELEMENT nr_banco (#PCDATA)> <!ELEMENT nome_banco (#PCDATA)>  <!ELEMENT nr_agencia (#PCDATA)>  <!ELEMENT nr_conta (#PCDATA)>  <!ELEMENT data_arquivo (#PCDATA)>  <!ELEMENT nr_arquivo (#PCDATA)>  <!ELEMENT lancamento (nr_banco, nr_agencia, nr_cont a, nome_favorecido, valor_credito, data_lancamento)>  <!ATTLIST lançamento nr_lancamento CDATA #REQUIRED >  <!ELEMENT nome_favorecido (#PCDATA)>  <!ELEMENT valor_credito (#PCDATA)>  <!ELEMENT data_lancamento (#PCDATA)> <!ELEMENT rodape (nr_lancamentos, valor_total)>  <!ELEMENT nr_lancamentos (#PCDATA)>  <!ELEMENT valor_total (#PCDATA)>

45

• <!ELEMENT pagamentos (cabecalho, lancamento+, rodap e)> :

esta declaração estabelece que o elemento pagamentos deve conter um elemento

cabecalho, um ou mais elementos lancamentos, (sinal de +) e um elemento rodape,

nesta ordem;

• <!ELEMENT empresa (#PCDATA)> : esta declaração estabelece que o

elemento empresa deve conter dados de caracteres.

Todas as outras declarações presentes na DTD seguem os mesmos princípios.

A partir da DTD acima, já se pode elaborar um documento XML que siga suas

regras de estruturação. A figura 13 mostra um documento XML elaborado de acordo com

as regras definidas na DTD da figura 12.

Figura 13 - Exemplo de documento XML - “pagamentos.xml” Fonte – Definido pelo autor

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pagamentos SYSTEM "pagamentos.dtd"> <pagamentos> <cabecalho> <empresa>EMPRESA E CIA LTDA</empresa> <cnpj>123456780000112</cnpj> <nr_banco>999</nr_banco> <nome_banco>BANCO BRASILEIRO</nome_banco> <nr_agencia>8888</nr_agencia> <nr_conta>777777</nr_conta> <data_arquivo>30112003</data_arquivo> <nr_arquivo>10</nr_arquivo> </cabecalho> <lancamento nr_lancamento="1"> <nr_banco>999</nr_banco> <nr_agencia>8888</nr_agencia> <nr_conta>111111</nr_conta> <nome_favorecido>JOAO SILVA</nome_favorecido> <valor_credito>5000</valor_credito> <data_lancamento>01122003</data_lancamento> </lancamento> <lancamento nr_lancamento="2"> <nr_banco>999</nr_banco> <nr_agencia>9999</nr_agencia> <nr_conta>222222</nr_conta> <nome_favorecido>JOSE SILVA</nome_favorecido> <valor_credito>8000</valor_credito> <data_lancamento>01122003</data_lancamento> </lancamento> <lancamento nr_lancamento="3"> <nr_banco>999</nr_banco> <nr_agencia>9999</nr_agencia> <nr_conta>3333333</nr_conta> <nome_favorecido>MARIA SILVA</nome_favorecido> <valor_credito>7000</valor_credito> <data_lancamento>01122003</data_lancamento> </lancamento> <rodape> <nr_lancamentos>3</nr_lancamentos> <valor_total>20000</valor_total> </rodape> </pagamentos>

46

Através da análise do exemplo da figura 13, vê-se que ele segue rigorosamente as

regras básicas de sintaxe XML: possui um único elemento raiz <pagamentos> ; todos

os elementos possuem um marcação de abertura e uma de fechamento (por exemplo,

<nr_conta> ... </nr_conta> ). Desta forma, podemos dizer que o documento é

bem formado.

Além disso, o documento também pode ser considerado válido, pois segue todas

as regras de estruturação contidas na DTD relacionada (“pagamentos.dtd”). Por exemplo, o

elemento <pagamentos> possui um elemento <cabecalho> , três elementos

<lancamentos> e um elemento <rodape> .

Submetendo o documento acima ao processador XML do aplicativo XML Spy,

verifica-se que o arquivo é válido e conseqüentemente bem formado. Para ser validado,

um arquivo deve ter uma DTD relacionada. No exemplo da figura 13, a declaração da

DTD aparece na segunda linha do documento:

<!DOCTYPE pagamentos SYSTEM "pagamentos.dtd">

Na figura 14, temos a mensagem do aplicativo XML Spy informando que o

documento é bem formado.

Figura 14 - Janela de mensagem do aplicativo XML Spy (1) Fonte – Aplicativo XML Spy

Na figura 15, o XML Spy informa que o documento também é válido.

Figura 15 - Janela de mensagem do aplicativo XML Spy (2) Fonte – Aplicativo XML Spy

47

Ao contrário da estrutura em camadas do formato de arquivo texto de campos

fixos, o documento XML tem uma estrutura hierárquica (figura 16).

Figura 16 - Estrutura hierárquica do documento XML Fonte – Aplicativo Bonfire Studio

A partir do exemplo mostrado na figura 13, pode-se fazer algumas considerações:

• os dados são codificados no formato texto;

• um documento XML é auto-descritível e possui alta legibilidade. Mesmo sem

conhecer as especificações que levaram à sua construção, tem-se condições de

deduzir sua estrutura e significado de seu conteúdo. Facilidade de análise visual;

• maior flexibilidade, já que o tamanho dos campos não é fixo;

• para modificar a especificação, basta alterar na DTD o elemento desejado, sem a

necessidade de modificar toda sua estrutura;

• com uma simples DTD e um processador XML pode-se verificar a validade de um

documento.

48

CONCLUSÃO

A utilização da linguagem XML como padrão para troca eletrônica de dados

entre bancos e empresas traz uma série de vantagens sobre o padrão atual de arquivos texto

de campos de largura fixa. A maioria delas corresponde diretamente aos objetivos

estabelecidos pelo W3C ao desenvolvê-la. Abaixo são listadas algumas destas vantagens:

• os dados são armazenados em documentos XML no formato texto, fazendo com

sejam automaticamente compatíveis com qualquer plataforma de hardware e

software;

• os documentos XML são altamente legíveis para o ser humano, o que facilita sua

leitura e análise;

• um documento XML é auto-descritível. Através de uma simples inspeção visual

podemos deduzir sua estrutura e o significado de seu conteúdo;

• a XML é compatível com a maioria dos softwares disponíveis no mercado;

• a XML é de fácil aprendizado;

• ampla gama de ferramentas de desenvolvimento;

• possui recursos de auto-validação de estrutura através de DTD.

A última vantagem listada possibilitaria diminuir o tempo de

desenvolvimento de software compatível com os bancos, já que os testes de arquivos

seriam feitos, exclusivamente, no ambiente das empresas. Dessa maneira, os bancos

colocariam a disposição das empresas as DTD contendo as regras para a geração de

documentos XML. As empresas utilizariam essas DTD para efetuar os testes de validação,

evitando o envio de arquivos de teste para as equipes técnicas dos bancos. Geralmente, a

fase de testes é a que demanda maior tempo tanto das equipes técnicas das empresas

quanto dos bancos.

Nos últimos anos, tem havido uma verdadeira convergência mundial em

direção à linguagem XML. Desde que foi lançada em 1996, várias iniciativas de

desenvolvimento de soluções baseadas em XML tem surgido pelo mundo afora. O poder e

simplicidade da XML tem sido os principais motores de uma revolução silenciosa que vem

acontecendo no mundo da tecnologia. Ficar de fora dessa revolução parece um contra-

49

senso. Parece apenas uma questão de tempo para que os bancos, através da entidade

FEBRABAN, venham a adotar a linguagem XML como padrão para troca eletrônica de

dados com as empresas.

Por fim, esse trabalho demonstra a simplicidade de se desenvolver soluções

baseadas em XML. Aplicações poderosas podem ser criadas com relativa facilidade,

limitadas tão somente pela criatividade dos desenvolvedores. As informações aqui

presentes podem ainda servir de fonte de consulta para futuros trabalhos que envolvam

EDI e/ou XML.

50

REFERÊNCIAS BIBLIOGRÁFICAS

1 BANCO CENTRAL DO BRASIL. Sistema de Pagamentos Brasileiro – Catálogo

de Mensagens. Brasília, 2000. Disponível em: < http://www.entendaospb.com.br/

tecnologia/ ABBC%20-%20cat%C3%A1logo%20mensagens.pdf>. Acesso em: 25

out. 2003.

2 BRAY, Tim, PAOLI, Jean, SPERBERG-MCQUEEN, C.M. XML (Extensible

Markup Language) 1.0. 2a. Edição. W3C. 2000. Disponível em:

<http://www.w3.org/TR/2000/ REC-xml-20001006>. Acesso em: 08 nov. 2003.

3 CARLSON, David. Modelagem de Aplicações XML com UML. Tradução: Rogério

Maximiliano dos Santos e Celso Roberto Paschoa. 1a. Edição. Editora Makron

Books, 2002. 362 p. ISBN 85-346-1406-7.

4 EAN BRASIL. Guia de Implantação do EDI. São Paulo, 2003. 71 p. Disponível

em: http://ww.eanbrasil.org.br/html/contentManagement/files/Biblioteca/guia_

implanta_edi.pdf>. Acesso em: 26 out. 2003.

5 FEBRABAN – Federação Brasileira de Bancos. Intercâmbio de Informações entre

Bancos e Empresas – Padrão FEBRABAN 240 posições – Versão 5. Brasília,

2002. 144 p. Disponível em: <http://www.febraban.org.br/Arquivo/

Servicos/Downloads/download_lista.asp?id_comissao=4>. Acesso em: 10 out.

2003.

6 GUIMARÃES, Ilse Maria Biason. O Papel do Intercâmbio Eletrônico de Dados no

Relacionamento Banco-Cliente. 1994. Dissertação (Mestrado em Administração).

Faculdade de Ciências Econômicas, Universidade Federal do Rio Grande do Sul.

Porto Alegre. 101 p. (mimeo).

7 MARQUES, Pedro Filipe de Jesus Vieira. Troca de Informações de Negócio para

Negócio – Do EDI ao XML/EDI e ebXML. 2003. Monografia (Licenciatura em

51

Engenharia da Comunicação). Universidade Fernando Pessoa. Porto. Portugal. 123

p. Disponível em: <http://www2.ufp.pt/~lmbg/monografias/ebxml.pdf>. Acesso

em: 09 nov. 2003.

8 MCGRATH, Sean. XML Aplicações Práticas. Tradução: Vitor Hugo da Paixão

Alves. 2a. Edição. Editora Campus. 1999. 368 p. ISBN 85-352-0408-3.

9 PITTS-MOULTIS, Natanya. XML – Black Book Solução e Poder. Tradução:

Ariovaldo Griesi. 1a. Edição. Editora Makron Books. 2000. 627 p. ISBN 85-346-

1262-5.

10 SANTOS, Domingos Sávio Apolônio. RDF na Interoperabilidade entre Domínios

na Web. 2002. Dissertação (Mestrado em Ciências). Universidade Federal de

Campina Grande. Campina Grande. 107 p. Disponível em:

<http://www.dsc.ufcg.edu.br/~copin/pesquisa/bancodissertacoes/2002/domingossav

io.pdf>. Acesso em: 09 nov. 2003.

Documents

Monografia - Automação Bancária - Intercâmbio eletrônico de dados entre bancos e empresas usando XML