monografia - automação bancária - intercâmbio eletrônico de dados entre bancos e empresas...
TRANSCRIPT
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:
<?xml version =”1.0”>
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 “>”, 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
<?xml version =”1.0”>
<!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
DESCRICAO POSIÇÃO CONTEÚDO
TIPO REGISTRO 001-001 FIXO = 1
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É
DESCRICAO POSIÇÃO CONTEÚDO
TIPO REGISTRO 001-001 FIXO = 9
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.
• <!--Document Type Definition para o arquivo exemplo de
pagamentos baseado em XML--> : trata-se de um comentário explicando
a finalidade da DTD;
<?xml version="1.0" encoding="UTF-8"?> <!--Document Type Definition para o arquivo exemplo de pagamentos baseado em XML--> <!ELEMENT pagamentos (cabecalho, lancamento+, rodap e)> <!--O cabecalho deverá conter informações sobre a e mpresa que fará os pagamentos--> <!ELEMENT cabecalho (empresa, cnpj, nr_banco, nome_ banco, nr_agencia, nr_conta, data_arquivo, nr_arquivo)> <!ELEMENT empresa (#PCDATA)> <!--Informar somente os números do CNPJ com 14 posi ções--> <!ELEMENT cnpj (#PCDATA)> <!--Informar o número do banco na câmara de compens ação com 3 posições--> <!ELEMENT nr_banco (#PCDATA)> <!ELEMENT nome_banco (#PCDATA)> <!--Informar o numero da agência com 4 posições sem o dígito verificador--> <!ELEMENT nr_agencia (#PCDATA)> <!--Informar o número da conta com ate 12 posições com o dígito verificador sem tracos ou pontos--> <!ELEMENT nr_conta (#PCDATA)> <!--Informar a data da geração do arquivo no format o DDMMAAAA--> <!ELEMENT data_arquivo (#PCDATA)> <!--Informar o número sequencial do arquivo--> <!ELEMENT nr_arquivo (#PCDATA)> <!--Os registros detalhes conterão informações sobr e cada lançamento de pagamento--> <!ELEMENT lancamento (nr_banco, nr_agencia, nr_cont a, nome_favorecido, valor_credito, data_lancamento)> <!--Para cada lançamento deverá ser atribuído um at ributo NR_LANCAMENTO sequencial--> <!ATTLIST lançamento nr_lancamento CDATA #REQUIRED > <!--Informar o nome do creditado--> <!ELEMENT nome_favorecido (#PCDATA)> <!--Informar o valor com até 15 posições e 2 cadas decimais, sem vírgula ou ponto--> <!ELEMENT valor_credito (#PCDATA)> <!--Informar a data da lançamento no formato DDMMAA AA--> <!ELEMENT data_lancamento (#PCDATA)> <!ELEMENT rodape (nr_lancamentos, valor_total)> <!--Informar o número de lançamentos do arquivo--> <!ELEMENT nr_lancamentos (#PCDATA)> <!--Informar o somatório dos lançamentos do arquivo --> <!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.