SOCIEDADE EDUCACIONAL E CULTURAL DE DIVINPOLIS FACULDADES INTEGRADAS DO OESTE DE MINAS - FADOM SISTEMAS DE INFORMAO

AUTOMAO BANCRIA - INTERCMBIO ELETRNICO DE DADOS ENTRE BANCOS E EMPRESAS USANDO XML

RENATO FARIA LOPES

Divinpolis, dezembro, 2003

SOCIEDADE EDUCACIONAL E CULTURAL DE DIVINPOLIS FACULDADES INTEGRADAS DO OESTE DE MINAS - FADOM SISTEMAS DE INFORMAO

AUTOMAO BANCRIA - INTERCMBIO ELETRNICO DE DADOS ENTRE BANCOS E EMPRESAS USANDO XML

RENATO FARIA LOPES Monografia apresentada s Faculdades Integradas do Oeste de Minas como requisito parcial para a obteno do ttulo de Bacharel em Sistemas de Informao.

Orientador: Professor Nesley Daher

Divinpolis, dezembro, 2003

FOLHA DE AVALIAO

Nome do aluno: Renato Faria Lopes Nr. de matrcula: 02000094 Curso: Sistemas de Informao

Ttulo do Trabalho: Automao Bancria - Intercmbio Eletrnico de Dados entre bancos e empresas usando XML Orientador: Professor Nesley Daher Orientador Metodolgico: Professora Patrcia Ferreira Santiago

CONCEITO: 1. Avaliador: ______________________________________ Grau: ________________ 2. Avaliador: ______________________________________ Grau: ________________

CONCEITO FINAL: __________________________

Divinpolis, _______ de ______________________ de __________

_______________________________________________________ _______________________________________________________ _______________________________________________________

DEDICATRIA

Aos meus pais, que deram as primeiras lies de minha vida.

AGRADECIMENTOS

Aos professores que compartilharam seu conhecimento e me motivaram a trilhar o caminho do desenvolvimento intelectual. Aos professores Nesley e Patrcia, que me orientaram na concluso deste trabalho. Agradeo a minha esposa Virgnia e minhas filhas Maria Clara e Letcia pelo apoio e pacincia que tiveram durante todo o curso.

SUMRIO

GLOSSRIO ................................................................................................................ LISTA DE TABELAS .................................................................................................. LISTA DE ABREVIATURAS E SIGLAS .................................................................. LISTA DE FIGURAS ...................................................................................................

VII X XI XII

RESUMO ...................................................................................................................... XIII INTRODUO ............................................................................................................ 1. EDI ELECTRONIC DATA INTERCHANGE...................................................... 1.1. EDI Um diferencial no mundo dos negcios .......................................... 1.2. Definies................................................................................................... 1.3. O EDI no mundo ......................................................................... 1.4. O EDI no Brasil ........................................................................... 1.5. Componentes de um sistema EDI .............................................................. 1.5.1. Mensagens Padronizadas ............................................................. 1.5.2. Software EDI ............................................................................... 1.5.3. Rede de Comunicao de Dados ................................................. 1.6. EDI entre bancos e empresas ..................................................................... 1.6.1. Mensagens padronizadas CNAB240 ....................................... 1.6.2. Software EDI Sistema prprio x aplicativos dos bancos ......... 1.6.3. Redes de comunicao de dados Office Banking 2. XML (EXTENSIBLE MARKUP LANGUAGE) .................................................... 2.1. Linguagens de Marcao Conceitos ....................................................... 2.2. SGML (Standard Generalized Markup Language) 2.3. HTML (Hyper Text Markup Language) 2.4. XML (Extensible Markup Language) ........................................................ 2.4.1. Caractersticas ............................................................................. 2.4.1.1. Extensibilidade ............................................................. 2.4.1.2. Legibilidade .................................................................. 2.4.1.3. Formato texto ................................................................ 2.4.1.4. Estrutura rgida e coesa ................................................ 2.4.1.5. Estrutura hierrquica .................................................... 14 16 16 16 18 19 20 20 21 22 23 23 25 25 27 27 28 28 29 30 30 31 31 31 32

2.4.1.6. Separao entre estrutura/contedo da apresentao ... 2.4.2. Componentes XML ..................................................................... 2.4.2.1. Elementos ..................................................................... 2.5.3.2. Atributos ....................................................................... 2.5.3.3. Entidades ...................................................................... 2.5.3.4. Comentrios .................................................................. 2.5.3.5. DTD (Document Type Definitions) ............................. 2.4.3. Processadores XML .................................................................... 2.4.4. Ferramentas XML ....................................................................... 2.4.5. Aplicaes XML ......................................................................... 2.4.5.1. Iniciativas XML pelo mundo ........................................ 3. EDI ENTRE BANCOS E EMPRESAS USANDO XML ........................................ 3.1. Objetivos .................................................................................................... 3.2. Metodologia ............................................................................................... 3.3. Estudo de caso - CNAB240....................................................................... 3.4. Documento XML ....................................................................................... CONCLUSO .............................................................................................................. REFERNCIAS BIBLIOGRFICAS ......................................................................... OBRAS CONSULTADAS ...........................................................................................

32 33 33 34 34 34 35 36 36 37 38 40 40 40 42 45 49 51 53

VII

GLOSSRIO

ANSI (American National Standards Institute): uma organizao afiliada ISO e que a principal organizao norte-americana envolvida na definio de padres (normas tcnicas) bsicos.

Aplicativo XML: uma implementao especfica do XML que uma DTD ou conjunto de DTDs desenvolvidas para servirem a um propsito especfico. Tambm conhecido como vocabulrio XML.

CNAB240: padro para troca eletrnica de dados entre bancos e empresas desenvolvido pela FEBRABAN.

DTD (Document Type Definitions): uma especificao XML para um documento que organiza elementos estruturais e definies de marcao de modo que elas possam ser usadas para criar documentos.

EDI (Electronic Data Interchange): uma forma de intercmbio de dados entre uma empresa e seus parceiros, de um computador para outro atravs de redes pblicas ou privadas dedicadas, de acordo com um padro reconhecido internacionalmente.

FEBRABAN (Federao Brasileira das Associaes de Bancos): uma entidade de natureza civil, que opera em mbito nacional, com o objetivo de representar os bancos e contribuir para o aperfeioamento de suas atividades. GML (Generalized Markup Language): meta-linguagem de marcao genrica baseada em texto que deu origem a SGML.

Hipertexto: Forma no linear de apresentar informaes. Tpicos de um texto podem ter vnculos com outras partes do mesmo documento ou outros documentos, que por sua vez podem estar vinculados a outras informaes.

VIII

HTML (Hypertext Markup Language): linguagem de marcao simples usada para criar documentos de hipertexto que so independentes de plataformas, normalizada pelo W3C (World Wide Web Consortium).

Processador XML: mdulo de software que usado para ler documentos XML e fornecer acesso a suas estruturas internas, podendo ainda validar e analisar sua sintaxe. Tambm pode ser chamado de interpretador, analisador sinttico ou parser.

SGBD (Sistema Gerenciador de Banco de Dados): termo genrico para designar todo software responsvel pelo gerenciamento (armazenamento e recuperao) dos dados em um banco de dados. Oracle, DB2 e SQL Server so exemplos de SGBDs.

SGML (Standard Generalized Markup Language): meta-linguagem de marcao genrica baseada em texto usada para descrever o contedo e a estrutura de documentos.

Site: conjunto de pginas que identificam um endereo web.

UN/EDIFACT (United Nations Electronic Data Interchange For Administration, Commerce and Transport): padro para mensagens EDI desenvolvido sob o patrocnio da ONU (Organizao das Naes Unidas) utilizado em mais de 60 pases.

X12: padro para mensagens EDI desenvolvido pela ANSI americana, utilizado principalmente nos Estados Unidos e Canad.

XML (Extensible Markup Language): linguagem de marcao derivada da SGML, que fornece uma forma padro de codificar contedo altamente estruturado.

XSL (Extensible Style Language): mecanismo de folhas de estilo que permite transformar documentos XML em documentos para exibio em dispositivos e sistemas diferentes.

W3C (World Wide Web Consortium): um consrcio 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 padres de linguagens voltadas para o desenvolvimento de aplicaes na Web, como HTML e XML, tem sido uma de suas grandes contribuies.

Web: vide WWW.

WWW (World Wide Web): literalmente, teia de alcance mundial. Baseada em hipertextos, integra diversos servios que oferecem acesso, atravs de hiperlinks, a recursos multimdia. Responsvel pela popularizao da rede, que agora pode ser acessada atravs de interfaces grficas de uso intuitivo, como o Internet Explorer ou Netscape.

LISTA DE TABELAS

1. Trecho do manual CNAB240 da FEBRABAN 2. Exemplo de especificao similar ao CNAB240

22 41

XI

LISTA DE ABREVIATURAS E SIGLAS

ABAC ANSI CNAB DTD EAN EDI

Associao Brasileira de Automao Comercial American National Standards Institute Centro Nacional de Automao Bancria Document Type Definitions European Article Numbering Electronic Data Interchange

UN/EDIFACT United Nations Electronic Data Interchange For Administration, Commerce and Transport FEBRABAN GML HTML ISO RENPAC SGML RVA W3C WWW XML XSL Federao Brasileira das Associaes de Bancos Generalized Markup Language Hyper Text Markup Language Interrnational Standard Organization Rede Nacional de Pacotes Standard Generalized Markup Language Redes de Valor Agregado World Wide Web Consortium World Wide Web Extensible Markup Language XML Style Language

XII

LISTA DE FIGURAS

1. Troca de informaes sem padronizao ............................................................... 2. Troca de informaes padronizadas ....................................................................... 3. Funcionamento de um software EDI .................................................................... 4. Componentes de um sistema EDI .......................................................................... 5. Estrutura hierrquica de um documento XML ....................................................... 6. Separao do contedo da apresentao em documentos XML ............................ 7. Janela de criao de documentos XML do aplicativo XML Spy ........................... 8. Estrutura bsica de um arquivo padro CNAB240 ................................................ 9. Exemplo de arquivo texto de campos de largura fixa .......................................... 10. DTD contendo regras de estrutura para documentos XML ................................. 11. Exemplo de documento XML .............................................................................. 12. Janela de mensagem do aplicativo XML Spy (1) ................................................ 13. Janela de mensagem do aplicativo XML Spy (2) ................................................ 14. Estrutura hierrquica do documento XML ..........................................................

18 18 19 20 29 30 38 39 41 42 43 44 44 45

XIII

RESUMO

Este trabalho analisa as vantagens da adoo da linguagem XML (Extensible Markup Language) no desenvolvimento de aplicaes para troca de informaes entre bancos e empresas, em substituio ao padro atual de arquivos texto de campos de largura fixa. Essa linguagem de estruturao de documentos, proposta em 1996 pelo W3C (World Wide Web Consortium), vem sendo adotada, no mundo todo, como padro para o desenvolvimento de aplicaes onde seja necessrio o intercmbio de informaes entre sistemas heterogneos. O tema desenvolvido a partir do levantamento bibliogrfico sobre intercmbio eletrnico de dados, ou EDI (Electronic Data Interchange), como mundialmente conhecido, sua evoluo e utilizao pelos bancos brasileiros. Logo em seguida, feita uma apresentao da linguagem de marcao XML, seu histrico, caractersticas, principais componentes e recursos, alm de uma lista com algumas iniciativas XML pelo mundo. Com base nesse referencial terico, desenvolvida uma pequena aplicao de pagamentos diversos que serve de base para comparaes entre o modelo atual de arquivos texto de campos de largura fixa e o modelo de documentos XML. Por fim, a concluso traz algumas anlises sobre a viabilidade e vantagens de implementao de solues baseadas em XML, fornecendo subsdios para novos trabalhos na rea de engenharia de software.

Palavras Chaves: informtica, automao bancria, redes de comunicao, Internet, intercmbio eletrnico de dados, engenharia de software, EDI, XML, CNAB, FEBRABAN.

14

INTRODUO

Atualmente, a troca eletrnica de informaes 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 eficincia em toda cadeia produtiva virou prioridade dentro dos planos de negcios das organizaes. Dentre todos os segmentos empresariais, se destaca na vanguarda dessa tecnologia o segmento bancrio, devido ao alto ndice de automao e pela sua longa histria e experincia em EDI.

Desde a dcada de 1980, os bancos brasileiros j oferecem aos clientes pessoa jurdica a opo de substiturem a troca de papis pela troca de dados via computador. O grande problema, desde ento, tem sido compatibilizar a troca de informaes entre bancos e empresas. Para isso, os bancos criaram padres baseados em arquivo texto com campos fixos que devem ser seguidos pelas empresas para troca de arquivos.

Surge, assim, um novo problema: a gerao e o tratamento desses arquivos segundo as normas estabelecidas pelos bancos. Essas normas envolvem esforo no estudo de padres de formatao e posterior codificao de rotinas que tratem cada tipo de arquivo. Alm disso, se uma empresa trabalha com mais de um banco, geralmente tem que desenvolver uma rotina especfica para cada um deles, visto que o padro adotado por essas instituies no muito padronizado. Isso se traduz em custos que a empresa tem de assumir para poder trocar informaes com seu banco.

O objetivo desse trabalho analisar as vantagens proporcionadas pela adoo da linguagem XML (Extensible Markup Language) como padro para o desenvolvimento de aplicaes para troca de informaes entre bancos e empresas em substituio ao formato atual. Padro de indstria, desenvolvido pelo renomado consrcio W3C (World Wide Web Consortium) em 1996, a XML fornece uma forma simplificada de codificar documentos altamente estruturados. Alm disso, caractersticas como simplicidade, flexibilidade, portabilidade, alta legibilidade para mquinas e homens, facilidade de aprendizado e rapidez no desenvolvimento de aplicaes, tornam a XML ideal para troca de informaes entre sistemas heterogneos.

15

Tal estudo se justifica, porque acredita-se que com a adoo da XML pelos bancos, as empresas tero uma significativa reduo de custos e tempo de desenvolvimento de aplicaes para EDI. Pequenas empresas que no podem desenvolver sistemas prprios, tem de se contentar com os aplicativos oferecidos pelos bancos, no se beneficiando totalmente do EDI. Para os bancos, a flexibilidade e simplicidade proporcionada pela XML podero ser traduzidas em mais negcios, atravs da popularizao do EDI.

Para tanto, foi feita pesquisa bibliogrfica com a finalidade de colher informaes suficientes sobre o EDI e a XML. Na primeira parte do trabalho, mostrado o histrico 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 terico foi utilizado os trabalhos acadmicos GUIMARES (1994) e MARQUES (2003), alm do manual EAN BRASIL (2003).

Na segunda parte, feita uma introduo linguagem a XML, sua especificao formal, caractersticas tcnicas, principais componentes e alguns exemplos de aplicaes baseadas nessa linguagem. O suporte terico veio dos livros PITTS-MOULTIS (2000), CARLSON (2002) e MCGRATH (1999), dos trabalhos acadmicos SANTOS (2002) e MARQUES (2003), alm da especificao BRAY (2000).

Na terceira parte, so avaliadas as dificuldades em desenvolver aplicaes compatveis com os sistemas dos bancos, utilizando-se o padro atual de arquivos, atravs de um estudo de caso baseado no manual FEBRABAN (2002). Logo em seguida, apresentado um prottipo de aplicao XML utilizado para efetivao de pagamentos (transferncia de fundos). Atravs de comparaes entre o mtodo atual e a soluo proposta, so analisados os reais benefcios advindos da utilizao do XML em aplicaes EDI.

A parte final destinada concluso do trabalho, onde determinada a viabilidade de implementao da soluo baseada em XML. Com isso, esse estudo se apresenta como base para futuras reflexes na rea de troca de informaes entre sistemas heterogneos, bem como ponto inicial para o desenvolvimento de solues de intercmbio eletrnico de dados entre bancos e empresas usando XML.

16

1. EDI ELECTRONIC DATA INTERCHANGE

Este captulo traz uma breve descrio sobre intercmbio eletrnico de dados, ou EDI (Electronic Data Interchange), definies, histrico, evoluo da tecnologia no Brasil e no mundo, padres utilizados e principais componentes. Aborda tambm o utilizao do EDI dentro do setor bancrio brasileiro.

1.1. EDI Um diferencial no mundo dos negcios

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 negcios, editar documentos e textos, normalmente atravs da digitao 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 emisso e processamento de documentos em papel certamente uma idia 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 atravs da Internet uma representao digitalizada desta, que processada automaticamente pelos computadores do fornecedor.

1.2. Definies

O EDI pode ser definido de maneira simples como a troca de dados padronizados entre dois computadores. Apesar de verdadeira, essa definio no esclarecedora nem abrangente o suficiente. Autores de reas diversas como administrao, finanas e tecnologia, j apresentaram suas definies para o EDI. Vejamos as definies de alguns autores, citadas em GUIMARES (1994, p.22):

17

a) CASH & KONSYNSK (1985): um sistema de informaes 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 comunicao mais efetiva e menos onerosa. Suas aplicaes referem-se comunicao entre empresas, tornando-se suporte, inclusive, para outras tarefas, como produo e treinamento.

d) MONZKA, CARTER (1988): a transmisso eletrnica direta, computador para computador, de papis padronizados como ordens de compra, pedidos, etc. entre duas organizaes.

e) MOORE (1987): EDI usualmente definido como a transferncia direta de dados negociais estruturados entre computadores por meios eletrnicos.

Para esse trabalho, uma definio mais clara e completa sobre EDI a apresentada pela EAN Brasil:

A transferncia de dados estruturados, pelos padres acordados de mensagens, de um aplicativo de computador a outro por meio eletrnico e com um mnimo de interveno humana.(EAN BRASIL, 2003, p.8).

Como se pode ver, o conceito bsico de EDI a transferncia eletrnica de dados padronizados entre computadores de empresas diferentes. Processamento e resposta imediatos no so necessrios. Os dados podem ser armazenados pelo computador destino para processamento posterior. Esses dados so representaes digitais de documentos impressos diversos tal como ordens de compra, faturas e pagamentos.

18

Dentre as principais caractersticas do EDI, a mais importante delas a padronizao. O estabelecimento de normas e padres para troca de dados soluciona vrios problemas, como incompatibilidade entre sistemas heterogneos, alm de reduzir custos no desenvolvimento de sistemas de EDI. Foi o estabelecimento de padres que viabilizou a aceitao e utilizao do EDI por empresas de todo o mundo. Entre os principais padres adotados esto o UN/EDIFACT, mais utilizado na Europa e sia e escolhido pela ONU para ser o padro mundial, e o ANSI X12, adotados por Canad e Estados Unidos.

1.3. O EDI no mundo

O EDI surgiu no final da dcada 1960 nos Estados Unidos, com a General Motors interagindo com alguns de seus fornecedores e com mais oito bancos (GUIMARES, 1994, p.23). Desde ento, vrias empresas comearam a implantar sistemas EDI baseados em formatos prprios e redes proprietrias. A medida que o nmero de parceiros comerciais foi aumentando, o custo com a traduo de mensagens trocadas foi crescendo numa escala bem maior, forando as mesmas a desenvolverem iniciativas setoriais de padronizao de mensagens.

Esse movimento de iniciativas setoriais, que ocorreu de forma praticamente simultnea nos Estados Unidos e Europa na dcada de 1970, gerou vrios padres 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 padres para setores bancrios, automotivo, seguros, entre outros.

Europa:

19

DAKOM criado na Sucia em 1972 para o setor de varejo e distribuio; GENCOD criado na Frana em 1974 para o setor de varejo e distribuio; ODETTE setor automotivo; SWIFT setor bancrio.

Com a rpida disseminao do EDI, logo surgiu a necessidade de integrao de sistemas entre empresas de segmentos diferentes do mercado. Com isso, surgiram projetos para unificao dos padres setoriais. Nos Estados Unidos, a ANSI comeou a desenvolver, em 1978, um padro mais amplo para EDI que foi chamado de X12.

No incio da dcada de 1980, as Naes Unidas formaram um grupo de trabalho para definir um padro internacional multi-setorial para o EDI. A partir dos trabalhos deste grupo, nasceu o padro 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 padro UN/EDIFACT contempla mais de 200 documentos diferentes, atendendo as necessidades de vrios segmentos de mercado, sendo adotado por mais de 60 pases. (EAN BRASIL. 2003. p.15).

1.4. O EDI no Brasil

No Brasil, os bancos foram os primeiros a utilizar o EDI. A primeira implantao de um sistema de troca eletrnica de informaes ocorreu no ano de 1964. Em 1979, a FEBRABAN (Federao Brasileira das Associaes de Bancos), atravs de seu rgo de assessoria CNAB (Centro Nacional de Automao Bancria), desenvolveu o padro CNAB, ainda hoje adotado por todos os bancos brasileiros.

Em 1987, a ABAC (Associao Brasileira de Automao Comercial) , atualmente EAN Brasil, formou um grupo de trabalho com representantes do comrcio, indstria, bancos e prestadores de servios de telecomunicaes, com a finalidade de instituir o que foi chamado na poca de linguagem comum nas operaes de negcios. Por estar filiada a EAN Internacional desde 1985, a escolha recaiu sobre o padro de mensagens UN/EDIFACT , que estava em vias de ser lanado (GUIMARES. 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 lanamentos de liquidao financeira na conta Reservas Bancrias 1. Para a troca de mensagens padronizadas, o Banco Central do Brasil adotou o XML 2 como linguagem bsica, demonstrando uma tendncia mundial (Banco Central do Brasil. 2000. p.6).

Desde ento, tem havido uma gradual introduo das prticas do EDI entre as empresas brasileiras. Com a popularizao dos microcomputadores, propriciada pela rpida evoluo da tecnologia da informtica, alm do advento da Internet, mais e mais empresas tem tido acesso a solues antes s disponveis para grandes corporaes.

1.5. Componentes de um sistema EDI

De acordo com o EAN BRASIL (2003, p.9-11), um sistema EDI composto de trs itens bsicos: mensagens padronizadas, software de EDI e meios de comunicao.

1.5.1. Mensagens Padronizadas

As mensagens padronizadas so o principal componente de um sistema EDI. Como j escrito anteriormente, no incio do EDI, cada empresa estabelecia seus padres para troca de dados com parceiros comerciais. medida que o nmero de parceiros aumentava, crescia tambm os custos com o desenvolvimento de novos conversores dos dados destes novos parceiros. Alm disso, controlar todos estes padres ficava cada vez mais difcil.

21

Empresa 1

Empresa 3

Empresa 2

Empresa 4

Figura 1 - Troca de informaes sem padronizao Fonte - EAN BRASIL, 2003, p.9

Utilizando-se uma linguagem comum para troca de informaes, as empresas diminuem drasticamente os custos e prazos para implantao de um sistema EDI com um novo parceiro. Basta desenvolver um conversor EDI uma nica vez que j se est preparado para trocar informaes quaisquer parceiros comerciais. Empresa 1 Empresa 3

Padro EDI

Empresa 2

Empresa 4

Figura 2 - Troca de informaes padronizadas Fonte - EAN BRASIL, 2003, p.10

1.5.2. Software de EDI

Tambm chamado de conversor de EDI, o software de EDI tem como finalidade bsica traduzir as mensagens recebidas num determinado padro, como o UN/EDIFACT ou CNAB, para o formato de dados utilizado pelos sistemas internos de uma empresa, e vice-versa. Alm disso, ele deve ser flexvel o suficiente para conter informaes de

22

parametrizao de perfis de diversos parceiros comerciais, e at mesmo um mdulo de comunicao direta com a rede de comunicao utilizada para troca das mensagens. Deve ter ainda recursos para gerenciamento dos documentos digitais trocados, ferramentas de auditoria e controle de acesso atravs do uso de senhas.

Sistema interno

Software EDI

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

1.5.3. Redes de Comunicao de Dados

Os dados convertidos atravs do software EDI para mensagens padronizadas devero ser enviados da empresa remetente para a empresa destinatria atravs de uma rede de comunicao de dados. De acordo com a viabilidade tcnica e econmica, as empresas podem trocar as informaes de vrias maneiras: linhas privadas alugadas ponto a ponto, redes de telefonia pblica 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 RVAs funcionam de forma anloga aos Correios. Cada empresa que contrata seus servios recebe uma caixa postal eletrnica onde ir receber as mensagens de seus parceiros. Da mesma forma, para enviar uma mensagem para um parceiro, basta enderear a mensagem para a caixa postal do destinatrio, que oportunamente ir receber a referida mensagem.

23

Empresa 1

Empresa 2

Dados internos

Dados internos

Software EDI Rede de Comunicao

Software EDI

Mensagem EDI

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 servios e produtos atravs de troca eletrnica de dados direcionados para o segmento pessoa jurdica. So servios e produtos que vo desde cobrana bancria e extratos de conta corrente, at pagamentos diversos. Como vantagens na utilizao destes servios de EDI podemos citar a agilidade, segurana e reduo de tarifas.

1.6.1. Mensagens padronizadas CNAB240

Como padro na troca de arquivos, os bancos adotam atualmente o formato CNAB240 definido pela FEBRABAN. Esse padro, na verso 5.0 de 16/04/2003, contempla vrios produtos e servios, tais como cobrana bancria, pagamentos atravs de crdito em conta, extratos e dbito em conta.

manual

contendo

as

especificaes

do

formato

CNAB240

tem

aproximadamente 150 pginas e est disponvel no site http://www.febraban.org.br. Ele traz informaes detalhadas para a elaborao de arquivos texto contendo registros (linhas de um arquivo texto) e campos de largura fixa. As instrues sobre os registros e campos

24

so apresentados no formato de tabelas, geralmente com as seguintes informaes: nome do campo, posio inicial e final (coluna no arquivo texto), casas decimais, formato (alfanumrico ou numrico), valor padro e descrio do campo. Segue abaixo um trecho de especificao de um registro do formato CNAB240:

Posio Campo De 01.9 03.9 04.9 CNAB 05.9 06.9 07.9 08.9 CNAB Qtde. de Lotes Totais Qtde. de Registros Banco 02.9 Controle Lote Registro Cdigo do Banco na Compensao Lote de Servio Tipo de Registro Uso Exclusivo FEBRABAN/CNAB Quantidade de Lotes do Arquivo Quantidade de Registros do Arquivo Uso Exclusivo FEBRABAN/CNAB 1 4 8 9 18 24 30 36

Formato Default

Descrio

At Dig Dec 3 7 8 17 23 29 35 3 4 1 9 6 6 6 Num Num Num Alfa Num Num Num Alfa Brancos '9999' '9' Brancos

G001 *G002 *G003 G004 G049 G056 *G037 G004

Qtde. de Contas Concil. Qtde de Contas p/ Conc. (Lotes)

240 205

Tabela 1 - Trecho do manual CNAB240 da FEBRABAN Fonte - FEBRABAN, 2002, p.6 Com base nessas informaes, empresas e bancos desenvolvem sistemas que geram e processam arquivos neste formato. Aqui se encontra o principal problema do padro CNAB: ao desenvolver os sistemas, cada banco incorpora caractersticas e recursos prprios, distorcendo o padro. Com isso, empresas que desenvolvem sistemas para trabalhar com um banco, geralmente tem de refazer todo o trabalho quando trocam de banco. Da advm a principal dificuldade dos desenvolvedores de software ao criar sistemas compatveis com os bancos nacionais.

1.6.2. Software EDI Sistema prprio x aplicativos dos bancos

A fim de disseminar com maior velocidade a adoo do EDI pelas empresas, os bancos desenvolveram uma srie de aplicativos compatveis com o padro CNAB240, para distribuio gratuita entre as empresas que no possuem recursos para o desenvolvimento de aplicativos EDI. Esses aplicativos permitem a impostao manual dos dados a serem enviados para o banco, bem como rotinas de processamento dos arquivos recebidos.

Como principal vantagem, as empresas no precisam gastar recursos no desenvolvimento de sistemas compatveis com os bancos. Como desvantagem, as empresas

25

no se beneficiam totalmente do EDI, visto que as mesmas tem um trabalho adicional de digitar manualmente as informaes que sero enviadas aos bancos. Dessa forma, somente as instituies financeiras se beneficiam totalmente do EDI.

A empresa tambm pode optar por desenvolver um sistema prprio para troca de informaes com o banco. Neste caso, ela arca com todos os custos de desenvolvimento. Como em qualquer projeto de engenharia de software, o desenvolvimento aplicativo prprio pelas empresas normalmente passa por cinco etapas: anlise, codificao, testes, colocao em produo e manuteno. Destas etapas, a mais crtica a etapa de testes, que neste caso envolve as equipes tcnicas da empresa e do banco. Nesta etapa, a empresa deve enviar ao banco vrios arquivos de testes que sero validados pelos tcnicos do banco antes que o sistema seja colocado em produo.

1.6.3. Redes de comunicao de dados Office Banking

Os bancos, normalmente, oferecem uma soluo proprietria 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 transferncia de arquivos padronizados.

Como alternativa, os bancos tambm oferecem a troca de arquivos atravs de RVAs, mais notadamente o servio RENPAC 3 da Embratel. A principal vantagem desse servio, est na utilizao de somente um aplicativo para troca de informaes, mesmo que a empresa opere com vrios bancos.

Rede de comutao de pacotes da Embratel, utilizada para troca de mensagens padronizadas de sistemas EDI.

26

2. XML (Extensible Markup Language)

Neste captulo, sero apresentados os conceitos tericos por trs das linguagens de marcao e um breve histrico. A seguir, tem-se um breve relato sobre duas linguagens antecessoras a XML, a SGML e a HTML. Ento, apresentada a linguagem de marcao e estruturao de dados XML (Extensible Markup Language), suas caractersticas e principais recursos. Finalmente, so mostradas algumas iniciativas de desenvolvimento de aplicaes utilizando XML.

Essa fundamentao terica se faz necessria para a construo de um prottipo de aplicao XML para troca de informaes entre bancos e empresas, apresentada no captulo 3.

2.1. Linguagens de Marcao - Conceitos

Quando se escreve algo num editor de texto qualquer, vrias informaes referentes formatao, tais como fontes, margens, pargrafos, etc, vo sendo adicionadas junto ao texto automaticamente. Essas informaes so utilizadas para controlar a aparncia final do documento durante sua visualizao ou impresso. Esse conjunto de informaes so chamadas de marcaes.

Mais do que controlar a formatao de documentos, as marcaes tambm podem conter informaes acerca do significado de trechos de documentos. Com base nestas informaes, pode-se controlar a forma como estes trechos devem ser processados pelos programas.

Segundo CARLSON (2002, p.15), a caracterstica mais (sic) fundamental de uma linguagem de marcao sua capacidade em descrever smbolos ou marcadores inseridos em um documento de texto e definir o significado que aqueles smbolos do ao texto associado.

27

Baseado neste conceito, vrias linguagens vem sendo criadas desde a dcada 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 idia original era criar uma meta linguagem de marcao universal, que servisse de modelo para criao de outras linguagens de marcao. Seu desenvolvimento comeou na dcada de 1960, quando a IBM trabalhava na linguagem GML (Generalized Markup Language). A IBM procurava uma forma fcil 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 marcao genrica, estabelecendo o padro 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 tambm muito complexa. Essa complexidade torna sua implementao muito difcil em qualquer aplicao.

Para contornar essa complexidade, foram criados subconjuntos da SGML direcionados para aplicaes especficas. HTML e XML so exemplos de linguagens criadas a partir dos conceitos fundamentados pela SGML.

2.3. HTML (Hyper Text Markup Language)

A HTML foi lanada em 1990 por Tim Berners-Lee, com o propsito de criar uma linguagem simples para publicao de documentos na web, baseada na linguagem SGML. Com um conjunto reduzido de marcaes, a HTML oferece recursos para formatao de documentos, alm de navegao entre documentos atravs de ligaes de hipertexto. Devido a sua simplicidade e ao padro aberto, logo ela tornou-se um sucesso na comunidade Internet, at ser oficialmente proclamada um padro pelo W3C em 1995, com o lanamento do padro HTML 2.0 (SANTOS, 2002. p.11).

28

Apesar de ser muito utilizada ainda hoje, a HTML tem vrias limitaes. Seu conjunto reduzido de marcaes no permite muita flexibilidade. Alm disso, suas marcaes esclarecem muito pouco a respeito do significado e estrutura dos dados contidos num documento. Pensando nisso, os engenheiros de software comearam 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, institudo 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 construo da linguagem. Esses objetivos, citados em BRAY (2000), so 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 compatvel com a SGML; d) a XML deve ser fcil o bastante para escrever programas que processem documentos XML; e) o nmero de recursos adicionais na XML deve ser mantido em um nvel mnimo, idealmente zero; f) os documentos XML precisam ser legveis e relativamente claros; g) o projeto da XML deve ser preparado rapidamente; h) o design da XML deve ser formal e conciso; i) j) os documentos XML devem ser fceis de ser criados; a conciso na marcao da XML de pouca importncia.

29

2.4.1. Caractersticas

O poder e flexibilidade da linguagem XML reside em suas muitas caractersticas. As principais so apresentadas a seguir.

2.4.1.1. Extensibilidade

Ao contrrio das outras linguagens de marcao, que tem um conjunto fixo de marcas, a XML permite que os desenvolvedores criem suas prprias marcaes 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.
<?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>

Figura 5 - Exemplo de cdigo XML Fonte - Definido pelo autor Nesse exemplo, foram criadas livremente as marcas <agenda>, <nome>,

<telefone>, <residencial> e <comercial>. Essas marcas atendem as necessidades para criao de uma agenda de telefone simples.

30

Observao importante: todo documento XML comea com a seguinte declarao: <?xml version =1.0>

2.4.1.2. Legibilidade

Conforme se pode ver pelo exemplo da figura 5, os documentos XML so altamente legveis para o ser humano. Uma boa escolha para os nomes de elementos, fazem com que os documentos sejam praticamente auto-descritveis, dispensando na maioria das vezes uma documentao anexa para entender a estrutura desses documentos. Essa caracterstica atende ao objetivo f estabelecido pelo W3C (BRAY, 2000).

2.4.1.3. Formato texto

Os documentos criados com a XML so arquivos de texto puro, tornando-os compatveis com qualquer plataforma de hardware e software.

2.4.1.4. Estrutura rgida e coesa

Apesar da liberdade na criao de marcas, o XML tem uma estrutura rgida que deve ser seguida obrigatoriamente. Duas regras bsicas determinam essa estrutura: primeiramente, deve existir um nico elemento raiz que contm 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 rgida evita ambigidades e facilita o desenvolvimento de aplicaes que processem documentos XML (MARQUES, 2003, p.13).

Quando um documento segue estas duas regras bsicas de sintaxe, pode-se dizer que o documento bem formado (existem outras regras de sintaxe XML a serem seguidas mas no so importantes para o presente trabalho).

31

2.4.1.5. Estrutura hierrquica

A estrutura rgida e coesa da XML determina outra importante caracterstica: todo documento XML tem uma estrutura fsica hierrquica (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.

Agenda

Nome

Telefone

Nome

Telefone

Residencial

Comercial

Residencial

Comercial

Figura 6 - Estrutura hierrquica de um documento XML Fonte Definido pelo autor

2.4.1.6. Separao entre estrutura, contedo e apresentao

Outra caracterstica importante da XML a separao entre estrutura, contedo e apresentao dos dados (MCGRATH, 1999, p.13). Um documento XML contm a estrutura e o contedo, que so as marcaes e os dados de caracteres, respectivamente. Normalmente, a apresentao tratada atravs da linguagem acessria chamada XSL (Extensible Style Language). Essa separao entre contedo, estrutura e apresentao permite que os dados sejam formatados de acordo com necessidades especficas. A figura 7 mostra um exemplo de como usar folhas de estilo 4 XSL para exibir o contedo de um documento XML em vrios dispositivos diferentes.

Uma folha de estilo fornece informaes sobre o estilo e a apresentao do documento para o pacote de software usado para processar o documento

32

Documento XML (estrutura/contedo)

Navegador web

Palm Top Processador XSL Celular Folhas de estilo XSL (apresentao) Impressora Figura 7 - Separao do contedo da apresentao em documentos XML Fonte Definido pelo autor

2.4.2. Componentes XML

A linguagem XML oferece alguns componentes para a construo de documentos estruturados. A seguir, so apresentados alguns desses componentes, que sero usados no desenvolvimento do trabalho.

2.4.2.1. Elementos

Os elementos so os blocos elementares para construo 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 tambm definido como um continer para armazenamento de dados, sempre composto de uma marca inicial e final. Um elemento pode conter uma seqncia de caracteres, outros elementos ou uma mistura dos dois, o que caracteriza a estrutura hierrquica da XML. Temos ainda o conceito de elemento vazio, que no armazena nenhum dado, sendo representado da seguinte forma: <vazio/>. Esse elemento significa o mesmo que <vazio></vazio>.

33

2.4.2.2. Atributos

Segundo PITTS-MOULTIS (2000, p.32), atributos so basicamente simples fontes de informaes adicionais sobre um elemento. So 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</residencial>

Essa informao adicional informa se o telefone residencial desse contato alugado ou no.

2.4.2.3. Entidades

Entidades so quaisquer conjuntos de caracteres que se quer referir num documento XML (PITTS-MOULTIS, 2000, p.32). Podem ser utilizadas de duas maneiras: digitao de caracteres especiais no contedo de um elemento XML, para serem processadas corretamente pelo processador XML; automatizar a insero de dados repetitivos dentro de um documento XML.

No primeiro caso, se for necessrio digitar o caractere < dentro do contedo de um elemento, sem causar erro do processador, deve-se substituir o caractere < pela entidade genrica &gt, embutida na XML.

No segundo caso, o usurio pode definir suas prprias entidades genricas para especificar quaisquer dados de caracteres. Depois de definida, a entidade pode ser includa dentro de um documento XML uma ou mais vezes atravs de uma referncia de entidade. Uma entidade referenciada na forma &[nome da entidade].

34

2.4.2.4. Comentrios

Como qualquer linguagem, a XML permite a insero de comentrios ao longo de um documento. Eles possuem a mesma forma dos comentrios HTML (MCGRATH, 1999, p.102). Exemplo: <! - comentrio -- !>

Observao importante: a seqncia de dois traos (--") no pode ocorrer dentro de um comentrio, 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 (definies de tipos de documentos), define um vocabulrio especfico de marcaes e permite que se faam verificaes na estrutura lgica 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 contedo 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:
<?xml version =1.0> <!ELEMENT agenda (nome+, fone+)> <!ELEMENT fone (residencial, comercial)> <!ELEMENT nome #PCDATA> <!ELEMENT residencial #PCDATA> <!ELEMENT comercial #PCDATA>

Figura 8 - Exemplo de uma DTD Fonte Definido pelo autor Existem dois tipos de DTD: interna e externa. Uma DTD considerada interna quando suas declaraes so includas dentro do prprio documento XML. DTD externa aquela que armazenada num arquivo separado do documento XML, geralmente com a extenso .dtd.

Para que um documento seja validado por um processador XML, deve-se incluir uma declarao de tipo de documento no incio 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 vlido.

2.4.3. Processadores XML

Os processadores XML,

tambm chamados interpretadores ou analisadores

sintticos, so 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 so categorizados tanto como marcao ou dados de caracteres. Eles separam as marcaes dos dados de caracteres, para em seguida envi-los a algum aplicativo cliente, como um navegador web.

Alm disso, eles tem a tarefa de verificar se os documentos XML so bem formados e/ou vlidos. Como j visto anteriormente, documentos XML so bem formados

36

quando atendem as regras bsicas da sintaxe XML. J os documentos XML so vlidos quando alm de serem bem formados, tambm atendem a todas as restries de validade (regras) estabelecidas por uma DTD relacionada. Quando um documento no bem formado e/ou vlido, o processador XML reporta uma mensagem de erro fatal ao aplicativo cliente (ou ao usurio), com a informao da linha onde o erro se encontra.

Existem dois tipos de processadores XML: os processadores de validao verificam se os documentos so vlidos e bem formados; j os processadores de novalidao somente verificam se os documentos so 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 disponveis 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 lanando pacotes de produtividade e desenvolvimento compatveis com a linguagem. Visual Studio .Net (Microsoft), Borland Delphi (Inprise) e Java Enterprise Edition (Sun Microsystems) so exemplos de linguagens de programao que possuem recursos de desenvolvimento compatveis com a XML. Sistemas gerenciadores de bancos de dados (SGBD) como Oracle, SQL Server (Microsoft) e DB2 (IBM) tambm suportam a linguagem. At mesmo o famoso pacote de escritrio Microsoft Office na verso 2003 j possui recursos para criao de documentos XML.

Existem ainda ferramentas de desenvolvimento especficas para XML, como por exemplo o Bonfire Studio da NZ Software, XML Spy da Altova GmbH e o ADEPT-Editor da ArborText, todas elas disponveis para download na Internet.

37

2.4.5. Aplicaes XML

Depois de compreender alguns conceitos fundamentais da XML, fica a pergunta: o que uma aplicao ou um aplicativo XML? Basicamente, uma DTD pode ser considerada uma aplicao XML. Uma aplicao XML define um vocabulrio e uma gramtica especficos 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 especfico. Alm disso, h um acordo tcito entre as partes que usam o aplicativo de que todos seguiro as mesmas regras. Os pacotes de software so ento 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 aplicaes em todas as reas. Segue abaixo alguns exemplos de alguns vocabulrios XML j desenvolvidos: CDF (Channel Definition Fomat): vocabulrio XML desenvolvido pela Microsoft que permite ao desenvolvedor usar uma variedade de mecanismos de remessa para publicar conjuntos de informaes chamadas canais de qualquer servidor web para qualquer aplicao compatvel com a Internet. CML (Chemical Markup Language): vocabulrio XML baseado em contedo e apresentao que usado para descrever e processar dados de compostos qumicos. GedML (Genealogical Data in XML): vocabulrio XML criado para fornecer um mtodo padro de apresentao, intercmbio e manipulao de dados genealgicos atravs de uma rede. MathML (Mathematical Markup Language): vocabulrio XML baseado em contedo e apresentao que usado para descrever e processar dados matemticos.

38

OFX (Open Financial Exchange): vocabulrio XML desenvolvido pela Microsoft, Intuit e Checkfree objetivando a padronizao do formato de dados disponibilizados por instituies financeiras.

PGML (Precision Graphics Markup Language): vocabulrio XML que fornece uma linguagem grfica 2D e que pode ser ampliada, desenvolvida para oferecer elementos grficos vetoriais e especificaes grficas 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 instituies financeiras.

TML

(Tutorial

Markup

Language):

vocabulrio

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 captulo mostrado um exemplo de aplicao XML como alternativa ao padro adotado hoje pelos bancos de arquivos texto de campos de largura fixa. Essa pequena aplicao consiste na definio de uma DTD padro, que contm regras para construo de documentos XML para transferncia de fundos entre uma empresa fictcia e seus fornecedores.

3.1. Objetivos

O objetivo da construo dessa aplicao XML fazer um comparativo entre os dois mtodos de estruturao 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 anlise sobre o padro atual para troca de dados entre bancos e empresas. Para isso, foi utilizado como referncia o manual FEBRABAN (2002), disponvel no site http://www.febraban.org.br. Como j abordado no captulo 1, esse documento contempla o padro CNAB240, que abrange diversos servios, desde cobrana bancria e extratos de conta at pagamentos diversos atravs de transferncia eletrnica de fundos.

Devido abrangncia e complexidade desse padro - so quase 150 pginas de especificaes - , decidiu-se pela elaborao de um padro simplificado para pagamentos diversos atravs de transferncia entre contas. Esse padro foi codificado na forma de um pequeno manual, que contm instrues sobre registros e campos utilizados em transferncias entre contas correntes. Depois, foi criado um pequeno arquivo texto com alguns lanamentos para transferncia de fundos, baseado nesse padro fictcio.

40

Logo em seguida, foi elaborada uma pequena aplicao XML baseada numa DTD. Essa DTD contm regras que definem um padro simplificado para construo de documentos XML de pagamentos diversos, de forma anloga ao padro de arquivo texto de campos fixos citado no pargrafo anterior. Essa DTD foi construda com o auxlio do aplicativo XML Spy Home Edition (figura 9), verso 5.2, da Altova GmbH, disponvel para download em http://www.xmlspy.com/download_spy_home.html (acesso em 22 nov. 2003).

Finalmente, foi construdo um documento XML seguindo as regras definidas na DTD criada. O documento, tambm elaborado no aplicativo XML Spy, contm os mesmos lanamentos de pagamentos existentes no arquivo de formato fixo citado anteriormente. Dessa forma, foi possvel fazer um comparativo entre os dois mtodos.

Figura 9 - Janela de criao de documentos XML do aplicativo XML Spy

41

3.3. Estudo de caso CNAB240

O padro 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 padro so constitudas dos registros e campos, seu tamanho e posio dentro de um arquivo texto. Para efeito de comparao, os registros e campos so como linhas e colunas numa tabela, respectivamente. A figura 10 mostra a estrutura em camadas de um arquivo CNAB240.

Registro header do arquivo Registro header do lote Registro detalhe(s) do lote . . . Registro trailer do lote Registro trailer do arquivo Figura 10 - Estrutura bsica de um arquivo padro CNAB240 Fonte FEBRABAN, 2002, p.3 O registro header (cabealho) do arquivo contm informaes sobre a empresa que mantm o convnio EDI com o banco, data e nmero seqencial do arquivo, alm de outras informaes. Corresponde a primeira linha do arquivo.

O registro header (cabealho) do lote tambm contm informaes sobre a empresa, alm de informaes sobre natureza do lote de lanamentos que vem a seguir, que podem ser lanamentos de cobrana, pagamentos diversos, extratos, dbito 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 informaes sobre os lanamentos presentes no arquivo. Normalmente, cada linha corresponde a um lanamento distinto. Um arquivo CNAB240 pode ter uma ou mais linhas de registros detalhe.

42

O registro trailer (rodap) do lote contm informaes sobre o lote, como o nmero de lanamentos e valor total do lote. Normalmente, corresponde a penltima linha do arquivo.

O registro trailer (rodap) do arquivo, que contm informaes sobre todo o arquivo, como nmero de lanamentos e valor total do arquivo. Corresponde a ltima linha do arquivo.

Para facilitar a compreenso de como funciona um arquivo de campos fixos como o CNAB240, segue abaixo uma especificao simples para construo de arquivos texto para transferncia entre contas (tabela 2).

FORMATO DE ARQUIVO PARA TRANSFERNCIA ENTRE CONTAS REGISTRO CABEALHO DESCRICAO TIPO REGISTRO NOME DA EMPRESA CNPJ NR. BANCO NR. AGNCIA NR. CONTA DATA GRAVAO NR. ARQUIVO POSIO 001-001 002-030 031-044 045-047 048-051 052-061 062-069 070-074 CONTEDO FIXO = 0 ALFANUMRICO NUMRICO NUMRICO NUMRICO NUMRICO NUMRICO (DDMMAAAA) NUMRICO

REGISTRO DETALHE DESCRICAO TIPO REGISTRO NR. LANAMENTO NR. BANCO NR. AGNCIA NR. CONTA NOME CREDITADO VALOR CREDITADO DATA CRDITO POSIO 001-001 002-007 008-010 011-014 015-024 025-051 052-066 067-074 CONTEDO FIXO = 1 NUMRICO NUMRICO NUMRICO NUMRICO ALFANUMRICO NUMRICO NUMRICO (DDMMAAAA)

43

REGISTRO RODAP DESCRICAO TIPO REGISTRO NR. LANAMENTOS VALOR TOTAL POSIO 001-001 002-008 009-023 CONTEDO FIXO = 9 NUMRICO NUMRICO

Tabela 2 - Exemplo de especificao similar ao CNAB240 Fonte Definido pelo prprio autor A partir da especificao da tabela 2, pode-se construir um arquivo texto que siga estas orientaes. A figura 11 mostra um exemplo de arquivo criado conforme o padro da tabela 2. Observao: uma rgua foi colocada aps o fim do arquivo para facilitar a localizao dos dados.

0EMPRESA E CIA LTDA

12345678000112999888800007777773012200300010 00000000000500001122003 00000000000800001122003 00000000000700001122003

100000199988880000111111JOAO SILVA 100000299988880000222222JOSE SILVA 100000399988880000333333MARIA SILVA 90000006000000000020000

-------------------------------------------------------------------------12345678901234567890123456789012345678901234567890123456789012345678901234 1 2 3 4 5 6 7

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 observaes: dados so codificados no formato texto; o arquivo isolado no capaz de nos informar nada a respeito de sua estrutura e significado dos dados ali contidos; estrutura frgil: o simples deslocamento de um caractere para esquerda ou direita provoca a total desorganizao de seu contedo; a anlise do contedo do arquivo atravs de inspeo visual, mesmo com o auxlio do manual de especificaes, extremamente difcil; se for preciso modificar a especificao de um arquivo deste tipo, geralmente ser necessrio modificar toda sua estrutura.

44

3.4. Documento XML

A partir da anlise do exemplo da tabela 2 e figura 11, segue abaixo uma aplicao XML elaborada de acordo com as mesmas especificaes. A aplicao consiste numa simples DTD, criada com o auxlio da ferramenta XML Spy. Como se trata de um arquivo texto, a mesma poderia ter sido elaborada atravs de um editor de textos qualquer. Essa DTD apresentada na figura 12.
<?xml version="1.0" encoding="UTF-8"?> <!--Document Type Definition para o arquivo exemplo de pagamentos baseado em XML--> <!ELEMENT pagamentos (cabecalho, lancamento+, rodape)> <!--O cabecalho dever conter informaes sobre a empresa 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 nmeros do CNPJ com 14 posies--> <!ELEMENT cnpj (#PCDATA)> <!--Informar o nmero do banco na cmara de compensao com 3 posies--> <!ELEMENT nr_banco (#PCDATA)> <!ELEMENT nome_banco (#PCDATA)> <!--Informar o numero da agncia com 4 posies sem o dgito verificador--> <!ELEMENT nr_agencia (#PCDATA)> <!--Informar o nmero da conta com ate 12 posies com o dgito verificador sem tracos ou pontos--> <!ELEMENT nr_conta (#PCDATA)> <!--Informar a data da gerao do arquivo no formato DDMMAAAA--> <!ELEMENT data_arquivo (#PCDATA)> <!--Informar o nmero sequencial do arquivo--> <!ELEMENT nr_arquivo (#PCDATA)> <!--Os registros detalhes contero informaes sobre cada lanamento de pagamento--> <!ELEMENT lancamento (nr_banco, nr_agencia, nr_conta, nome_favorecido, valor_credito, data_lancamento)> <!--Para cada lanamento dever ser atribudo um atributo NR_LANCAMENTO sequencial--> <!ATTLIST lanamento nr_lancamento CDATA #REQUIRED > <!--Informar o nome do creditado--> <!ELEMENT nome_favorecido (#PCDATA)> <!--Informar o valor com at 15 posies e 2 cadas decimais, sem vrgula ou ponto--> <!ELEMENT valor_credito (#PCDATA)> <!--Informar a data da lanamento no formato DDMMAAAA--> <!ELEMENT data_lancamento (#PCDATA)> <!ELEMENT rodape (nr_lancamentos, valor_total)> <!--Informar o nmero de lanamentos do arquivo--> <!ELEMENT nr_lancamentos (#PCDATA)> <!--Informar o somatrio dos lanamentos do arquivo--> <!ELEMENT valor_total (#PCDATA)>

Figura 12 - DTD pagamentos.dtd Fonte Definido pelo autor Segue abaixo alguns detalhes da criao da DTD, que ajudam na compreenso de seu funcionamento. <!--Document Type Definition para o arquivo exemplo de pagamentos baseado em XML--> : trata-se de um comentrio explicando a finalidade da DTD;

45

<!ELEMENT pagamentos (cabecalho, lancamento+, rodape)> : esta declarao 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 declarao estabelece que o elemento empresa deve conter dados de caracteres.

Todas as outras declaraes presentes na DTD seguem os mesmos princpios.

A partir da DTD acima, j se pode elaborar um documento XML que siga suas regras de estruturao. A figura 13 mostra um documento XML elaborado de acordo com as regras definidas na DTD da figura 12.
<?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>

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

46

Atravs da anlise do exemplo da figura 13, v-se que ele segue rigorosamente as regras bsicas de sintaxe XML: possui um nico elemento raiz <pagamentos> ; todos os elementos possuem um marcao de abertura e uma de fechamento (por exemplo, <nr_conta> ... </nr_conta>). Desta forma, podemos dizer que o documento bem formado.

Alm disso, o documento tambm pode ser considerado vlido, pois segue todas as regras de estruturao contidas na DTD relacionada (pagamentos.dtd). Por exemplo, o elemento <pagamentos> possui um elemento <cabecalho>, trs elementos <lancamentos> e um elemento <rodape>.

Submetendo o documento acima ao processador XML do aplicativo XML Spy, verifica-se que o arquivo vlido e conseqentemente bem formado. Para ser validado, um arquivo deve ter uma DTD relacionada. No exemplo da figura 13, a declarao 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 tambm vlido.

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

47

Ao contrrio da estrutura em camadas do formato de arquivo texto de campos fixos, o documento XML tem uma estrutura hierrquica (figura 16).

Figura 16 - Estrutura hierrquica do documento XML Fonte Aplicativo Bonfire Studio A partir do exemplo mostrado na figura 13, pode-se fazer algumas consideraes: os dados so codificados no formato texto; um documento XML auto-descritvel e possui alta legibilidade. Mesmo sem conhecer as especificaes que levaram sua construo, tem-se condies de deduzir sua estrutura e significado de seu contedo. Facilidade de anlise visual; maior flexibilidade, j que o tamanho dos campos no fixo; para modificar a especificao, 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

CONCLUSO

A utilizao da linguagem XML como padro para troca eletrnica de dados entre bancos e empresas traz uma srie de vantagens sobre o padro atual de arquivos texto de campos de largura fixa. A maioria delas corresponde diretamente aos objetivos estabelecidos pelo W3C ao desenvolv-la. Abaixo so listadas algumas destas vantagens: os dados so armazenados em documentos XML no formato texto, fazendo com sejam automaticamente compatveis com qualquer plataforma de hardware e software; os documentos XML so altamente legveis para o ser humano, o que facilita sua leitura e anlise; um documento XML auto-descritvel. Atravs de uma simples inspeo visual podemos deduzir sua estrutura e o significado de seu contedo; a XML compatvel com a maioria dos softwares disponveis no mercado; a XML de fcil aprendizado; ampla gama de ferramentas de desenvolvimento; possui recursos de auto-validao de estrutura atravs de DTD.

ltima

vantagem

listada

possibilitaria

diminuir

tempo

de

desenvolvimento de software compatvel com os bancos, j que os testes de arquivos seriam feitos, exclusivamente, no ambiente das empresas. Dessa maneira, os bancos colocariam a disposio das empresas as DTD contendo as regras para a gerao de documentos XML. As empresas utilizariam essas DTD para efetuar os testes de validao, evitando o envio de arquivos de teste para as equipes tcnicas dos bancos. Geralmente, a fase de testes a que demanda maior tempo tanto das equipes tcnicas das empresas quanto dos bancos.

Nos ltimos anos, tem havido uma verdadeira convergncia mundial em direo linguagem XML. Desde que foi lanada em 1996, vrias iniciativas de desenvolvimento de solues baseadas em XML tem surgido pelo mundo afora. O poder e simplicidade da XML tem sido os principais motores de uma revoluo silenciosa que vem acontecendo no mundo da tecnologia. Ficar de fora dessa revoluo parece um contra-

49

senso. Parece apenas uma questo de tempo para que os bancos, atravs da entidade FEBRABAN, venham a adotar a linguagem XML como padro para troca eletrnica de dados com as empresas.

Por fim, esse trabalho demonstra a simplicidade de se desenvolver solues baseadas em XML. Aplicaes poderosas podem ser criadas com relativa facilidade, limitadas to somente pela criatividade dos desenvolvedores. As informaes aqui presentes podem ainda servir de fonte de consulta para futuros trabalhos que envolvam EDI e/ou XML.

50

REFERNCIAS BIBLIOGRFICAS

BANCO CENTRAL DO BRASIL. Sistema de Pagamentos Brasileiro Catlogo de Mensagens. Braslia, 2000. Disponvel em: < http://www.entendaospb.com.br/ tecnologia/ ABBC%20-%20cat%C3%A1logo%20mensagens.pdf>. Acesso em: 25 out. 2003.

BRAY, Tim, PAOLI, Jean, SPERBERG-MCQUEEN, C.M. XML (Extensible Markup Language) 1.0. 2a. Edio. W3C. 2000. Disponvel em:

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

CARLSON, David. Modelagem de Aplicaes XML com UML. Traduo: Rogrio Maximiliano dos Santos e Celso Roberto Paschoa. 1a. Edio. Editora Makron Books, 2002. 362 p. ISBN 85-346-1406-7.

EAN BRASIL. Guia de Implantao do EDI. So Paulo, 2003. 71 p. Disponvel em: http://ww.eanbrasil.org.br/html/contentManagement/files/Biblioteca/guia_

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

FEBRABAN Federao Brasileira de Bancos. Intercmbio de Informaes entre Bancos e Empresas Padro FEBRABAN 240 posies Verso 5. Braslia, 2002. 144 p. Disponvel em: <http://www.febraban.org.br/Arquivo/

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

GUIMARES, Ilse Maria Biason. O Papel do Intercmbio Eletrnico de Dados no Relacionamento Banco-Cliente. 1994. Dissertao (Mestrado em Administrao). Faculdade de Cincias Econmicas, Universidade Federal do Rio Grande do Sul. Porto Alegre. 101 p. (mimeo).

MARQUES, Pedro Filipe de Jesus Vieira. Troca de Informaes de Negcio para Negcio Do EDI ao XML/EDI e ebXML. 2003. Monografia (Licenciatura em

51

Engenharia da Comunicao). Universidade Fernando Pessoa. Porto. Portugal. 123 p. Disponvel em: <http://www2.ufp.pt/~lmbg/monografias/ebxml.pdf>. Acesso em: 09 nov. 2003.

MCGRATH, Sean. XML Aplicaes Prticas. Traduo: Vitor Hugo da Paixo Alves. 2a. Edio. Editora Campus. 1999. 368 p. ISBN 85-352-0408-3.

PITTS-MOULTIS, Natanya. XML Black Book Soluo e Poder. Traduo: Ariovaldo Griesi. 1a. Edio. Editora Makron Books. 2000. 627 p. ISBN 85-3461262-5.

10 SANTOS, Domingos Svio Apolnio. RDF na Interoperabilidade entre Domnios na Web. 2002. Dissertao (Mestrado em Cincias). Universidade Federal de Campina Grande. Campina Grande. 107 p. Disponvel em:

<http://www.dsc.ufcg.edu.br/~copin/pesquisa/bancodissertacoes/2002/domingossav io.pdf>. Acesso em: 09 nov. 2003.