Universidade do Minho Cartão Bancário como Título de Transporte Pós-Pago ago ós-p te P io como ranspor tão Bancár Car Título de T

Transcrição

1 Universidade do Minho Escola de Engenharia Alexandre Vilela Ribeiro Cartão Bancário como Título de Transporte Pós-Pago UMinho 2010 Alexandre Vilela Ribeiro Cartão Bancário como Título de Transporte Pós-Pago Outubro de 2010

2

3 Universidade do Minho Escola de Engenharia Alexandre Vilela Ribeiro Cartão Bancário como Título de Transporte Pós-Pago Tese de Mestrado Ciclo de Estudos Integrados Conducentes ao Grau de Mestre em Engenharia Electrónica Industrial e Computadores Trabalho efectuado sob a orientação do Professor Doutor Sérgio Adriano Fernandes Lopes Universidade do Minho Co-Orientador: Engenheiro Ricardo Filipe Peixoto Jorge Urge-Serviços Outubro de 2010

4 Resumo Esta dissertação enquadra-se num projecto resultante de uma parceria entre a Caixa Geral de Depósitos (CGD), os Transportes Urbanos de Braga (TUB) e a URGE Serviços (URGE). No âmbito desta parceria, foi já desenvolvido um sistema que permite aos passageiros utilizarem como título de transporte o cartão Caixa Universidade Politécnico, com tecnologia de proximidade Mifare, que é previamente carregado/pago nos postos de venda TUB. O objectivo deste projecto é expandir o actual sistema de forma a que todos os clientes da CGD possam utilizar directamente cartões bancários como títulos de transporte válidos no sistema de bilhética dos TUB. Nesse sentido, irá ser introduzido um novo tipo de cartão bancário, que integrará as funcionalidades de cartão Multibanco e título de transporte Mifare. O passageiro utilizará esse cartão de forma transparente a bordo dos veículos TUB, e os custos das viagens realizadas serão automaticamente debitados na sua conta CGD, seguindo-se assim um modelo comercial póspago. Este trabalho de dissertação consiste no desenvolvimento de um sistema de informação que faça a ponte entre a base de dados de bilhética dos TUB e a CGD. Para tal foi necessário desenvolver uma aplicação back-office que processe as transacções de bilhética referentes a cartões bancários e implementar um serviço robusto e seguro de troca de ficheiros de informação com a CGD. Os objectivos iniciais deste trabalho incluíam a integração de diferentes tecnologias informáticas para desenvolvimento de um sistema back-office, a utilização de ferramentas Microsoft que suportam essas tecnologias. Em termos funcionais, pretendia-se fazer chegar à CGD a informação que permitisse a realização dos débitos relativos a viagens nos TUB e fornecer aos TUB uma aplicação back-office que fizesse a triagem de todas as transacções dos equipamentos embarcados dos TUB, recolhendo somente a informação relativa às transacções efectuadas com o cartão CGD-TUB. Em suma, os objectivos foram atingidos e o sistema desenvolvido está pronto para ser posto a funcionar. Palavras-chave: Base de dados SQL, Programação em VB.net, XML, XML schema, VPN. ii

5 Abstract This thesis part of a project that resulted from a partnership between Caixa Geral de Depositos (CGD), Transportes Urbanos de Braga (TUB) and URGE Serviços (URGE). During this partnership, a system has been developed that allows passengers to use their Caixa Universidade Politécnico cards with Mifare contactless technology as transport ticket. These cards must be previously loaded on TUB s kiosks. The objective of this project is to expand the current system so that all CGD costumers may use directly their bank cards as valid titles on TUB s ticketing system. For that, a new type of bank card will be introduced, which integrates the features of bank card and Mifare transport card. Passengers will use the card in a transparent way on TUB s vehicles and travelling costs will be automatically debited on passenger s CGD bank account, thus offering a post-paid business model. This work consists on developing an information system to build a bridge between TUB s ticketing database and CGD system. For that, it was necessary to build a back-office application to process the ticketing transactions corresponding to bank card usage and to configure a reliable and safe service for exchanging information files with CGD. The goals that were set at the start of the project include the integration of different technologies to develop a back-office system and to use Microsoft tools that support those technologies. In functional terms, the system should send to CGD information that allowed the execution of bank debits of travels and provide TUB with a back-office application to filter transactions made by CGD-TUB card from the whole transaction information set. Finally, the objectives were accomplished and the developed system is ready to start operating. Key words: SQL databases; VB.net, XML, XML Schema programming; VPN. iii

6 Agradecimentos Para a realização deste trabalho em muito contribuiu o auxílio prestado pelas seguintes pessoas e instituições, às quais manifesto o devido agradecimento: Aos meus pais, irmãos e namorada pela presença constante na minha vida, pelo estímulo permanente na procura do alcançar dos objectivos pessoais; Ao Prof. Sérgio Adriano Fernandes Lopes, orientador, pela disponibilidade, pelos esclarecimentos prestados e dados disponibilizados; Ao Eng. Ricardo Filipe Peixoto Jorge, pela disponibilidade e auxílio no desenvolvimento do projecto e na estruturação da tese; À empresa URGE - Serviços Electricidade e Electrónica, Lda., pela oportunidade concebida que permitiu a participação neste projecto. iv

7 Índice RESUMO... II ABSTRACT... III AGRADECIMENTOS... IV ÍNDICE... V LISTA DE FIGURAS... IX LISTA DE TABELAS... XI ABREVIATURAS E SÍMBOLOS... XII CAPÍTULO I... 1 APRESENTAÇÃO CONCEPTUAL DO PROJECTO Introdução Problema /contexto Objectivos... 4 CAPÍTULO II... 6 LINGUAGEM UTILIZADA PARA TROCA DE FICHEIROS XML extensible Markup Language XML schema Elementos Elemento simples... 9 v

8 Elemento complexo Atributos Restrições Indicadores Analogia CAPÍTULO III ESPECIFICAÇÃO DE FICHEIROS XML/XSD Arquitectura da troca de ficheiros Especificação dos Ficheiros Ficheiros Plásticos Estrutura do Ficheiro de Plásticos Descrição do Elemento Plásticos Descrição do sub-elemento Plástico Ficheiro de Retorno Status Plásticos Estrutura do Ficheiro de Retorno Status Plasticos Retorno Status Plásticos Elemento RetPlastico Informação detalhada em caso de CodigoErro diferente de zero Ficheiro de Transacções Estrutura do Ficheiro de Transacções Transacções Transacção Ficheiro de Retorno Status TRANSACÇÕES Estrutura do Ficheiro de Retorno Status Transacções Retorno Status Transacções Retorno Status Transacção Ficheiro de MOVIMENTOS Estrutura do Ficheiro de Movimentos Movimentos vi

9 Movimento Ficheiro de Retorno Status MOVIMENTOS Estrutura do Ficheiro de Retorno Status Movimentos Retorno Status Movimentos Retorno Status Movimento Nomenclatura dos Ficheiros Validação Offline CAPÍTULO IV FERRAMENTAS E LINGUAGENS DE DESENVOLVIMENTO UTILIZADAS VB.net Linguagem orientada a objectos Bases de dados Base de dados relacional SQL SQL Server Conexões à base de dados e execução de comandos SQL SQL Server Jobs Leitura e criação de ficheiros XML VPN (Virtual Private Network) CAPÍTULO V IMPLEMENTAÇÃO Base de dados da bilhética dos TUB Lista negra de cartões Criação e adição das tabelas vii

10 5.2 Tratamento dos Ficheiros Análise do Ficheiro Plásticos Análise das Transacções e Ficheiro Transacções Análise do Ficheiro Movimentos Modelo de validação do Status dos ficheiros Plásticos Utilização de Job SQL Configuração do Job SQL Aplicação desenvolvida Processamento dos ficheiros recebidos Tratamento ficheiro Plásticos Tratamento ficheiro Movimentos Processamento das transacções Troca de ficheiros entre os sistemas TUB e CGD CAPÍTULO VI CONCLUSÕES TRABALHO FUTURO BIBLIOGRAFIA ANEXO I RETORNO STATUS PLÁSTICO ANEXO II - TRANSACÇÃO ANEXO III RETORNO STATUS TRANSACÇÕES ANEXO IV RETORNO STATUS TRANSACÇÃO viii

11 Lista de Figuras Figura 1 Fluxo de informação... 4 Figura 2 Analogia XML / XSD receita culinára Figura 3 Troca de ficheiros Figura 4 Aplicação de validação ficheiros XML Figura 5 Criação tabela na base de dados Figura 6 Tratamento informação ficheiro PLST Figura 7 Diagrama funcional de uma Transacção Figura 8 Tratamento das Transacções Figura 9 Tratamento informação ficheiro Movimentos Figura 10 Diagrama de estado do Status do plastico Figura 11 Diagrama de processos Figura 12 Utilização Job SQL Figura 13 Criação de plano de manutenção Figura 14 Configuração de plano de manutenção Figura 15 Inserção de comandos SQL Figura 16 Programação dos ciclos de execução Figura 17 Separador Menu Figura 18 Separador Dir./Ficheiros Figura 19 Separador Servidor Figura 20 Separador Opções Figura 21 Separador Log Figura 22 Fluxograma tratamento dos ficheiros Plásticos Figura 23 Fluxograma tratamento dos ficheiros Movimentos Figura Figura Figura Figura Figura Figura Figura ix

12 Figura Figura Figura x

13 Lista de Tabelas Tabela 1 Formato Tabela 2 - Plasticos Tabela 3 - Plastico Tabela 4 - RetPlasticos Tabela 5 - RetPlastico Tabela 6 - Transaccoes Tabela 7 - Transaccao Tabela 8 - RetTransaccoes Tabela 9 - RetTransaccao Tabela 10 - Movimentos Tabela 11 - Movimento Tabela 12 - RetMovimentos Tabela 13 - RetMovimento Tabela 14 Nomenclatura utilizada para os ficheiros xi

14 Abreviaturas e Símbolos ATF BO CGD DTD EF EMV FTP HTML HTTP Plástico SB SGML SIBS TB TUB XML XSD VPN Aplicação de Software do Equipamento de Bilhética Embarcado Back-Office Caixa Geral de Depósitos Document Type Definition Embbed-Framework camada aplicacional da ATF destinada exclusivamente ao tratamento de transacções de cartões sem-contacto. Chip que guarda a informação bancária do cartão File Transfer Procol Hyper Text Markup Language Hypertext Transfer Protocol Cartão emitido pela SIBS no âmbito deste projecto Sistema de Bilhética Standard Generalized Markup Language Sociedade Interbancária de Serviços Título de Bordo disponível no Sistema de Bilhética dos TUB Transportes Urbanos de Braga Extensible Markup Language XML schema Virtual Private Network xii

15 Capítulo I Apresentação conceptual do projecto 1.1 Introdução O transporte público de passageiros em Portugal registou uma redução de clientes nas últimas duas décadas. As causas são várias, destacando-se por exemplo: a massificação da utilização do automóvel, a incapacidade dos transportadores públicos em acompanhar a evolução do quotidiano, nomeadamente, através da reestruturação das redes e adaptação destas às novas necessidades de mobilidade. Para fazer face a este problema, os transportadores públicos de passageiros tentam encontrar novas formas de incentivar as populações a utilizar os transportes públicos, inovando a oferta comercial existente e oferecendo aos utentes novas modalidades de título de transporte, que permitam uma utilização fácil e cómoda por parte dos primeiros. Através do recurso a novas tecnologias, as empresas apetrecham as suas redes com equipamentos capazes de auxiliar na gestão, emissão e validação dos títulos de transporte. Esta tecnologia é denominada de Bilhética [1] e consiste na integração de vários equipamentos electrónicos num sistema de informação com o objectivo de simplificar os processos, obter informação estatística em termos de receitas e número de passageiros transportados. Outra finalidade dos sistemas de bilhética é disponibilizar uma oferta flexível e diversificada de títulos de transporte, indo ao encontro das necessidades específicas dos utentes, permitindo ao mesmo tempo uma cada vez maior facilidade de acesso e utilização dos títulos de transporte. Um dos principais objectivos dos sistemas de bilhética é proporcionar um controlo de acessos automatizado que ajude à prevenção da fraude. Neste capítulo, há uma tecnologia que tem sido largamente utilizada em Portugal, que é o cartão de chip sem contacto. A adopção desta tecnologia consiste no desenvolvimento de modelos de dados que permitem codificar nos chips sem contacto os títulos de transporte que anteriormente eram impressos em papel: passes e cartões de viagens (pré-comprados). Através da utilização do cartão de chip sem contacto, o 1

16 passageiro ao embarcar é obrigado a validar electronicamente o seu título em equipamentos instalados nos veículos. A validação electrónica tem dois objectivos: verificação automática da validade do título; registo da informação relativa à transacção para posterior tratamento estatístico. As principais razões do sucesso da tecnologia de cartões chip sem contacto em relação a outro tipo de suportes electrónicos (nomeadamente: cartões de banda magnética, cartões de chip com contacto) são: a redução dos custos em virtude da massificação desta tecnologia e a maior durabilidade do cartão, já que não existe contacto mecânico com o validador. Para além disso, o validador de cartões de chip sem contacto tem também um menor custo de manutenção, quando comparado com o dos validadores dos outros suportes, devido à ausência de contacto. No que diz respeito ao modelo de negócio, até ao momento as empresas de transporte têm utilizado um modelo denominado pré-pago, que consiste no pagamento do título de transporte pelo utente antes da sua utilização. Por exemplo: um utente que pretenda adquirir um passe mensal para viajar num determinado mês, terá que adquirir o passe antes de começar a usufruir dele. O mesmo se passa com o utente que pretenda adquirir um título multi-viagens, ou seja, adquire X viagens, sendo-lhe debitada uma unidade em cada viagem realizada. Contudo, a necessidade cada vez maior de diversificar a oferta comercial como forma de incentivar a utilização dos transportes públicos, conduz a uma procura de soluções inovadoras. Uma dessas soluções é abordada nesta dissertação e consiste na utilização de um cartão bancário, dotado de dois chips: um chip sem contacto (com funcionalidade de interface com a aplicação Mifare 1k) e um chip EMV (com informação bancária). Este novo conceito de cartão permite uma utilização como cartão bancário e como cartão de transporte. Desta forma, o utente de transporte público deixa de ter necessidade de possuir dois cartões, um para utilização bancária e outro para utilização no transporte, tendo disponível um cartão que integra essas duas funcionalidades. Paralelamente com a introdução do novo cartão, surge também um novo conceito comercial que envolve simultaneamente a empresa de transporte público e a entidade bancária. Trata-se do modelo de pagamento pós-pago, ou seja, após um primeiro acordo comercial entre o cliente e a entidade bancária e um segundo entre a entidade bancária e a empresa de transportes, o cliente da entidade bancária poderá usufruir da rede de transportes, validando o seu cartão nos equipamentos de bilhética. 2

17 1.2 Problema /contexto Os transportadores públicos procuram estabelecer parcerias ao nível tecnológico e comercial com o objectivo de disponibilizar novas soluções em termos de produto. Os TUB, a CGD e a URGE desenvolveram uma parceria cujo objectivo principal é implementar um título de transporte inovador que consistirá na capacidade de utilização dos cartões bancários no sistema de bilhética dos TUB, em alternativa aos títulos de transporte tradicionais. O novo modelo de cartão que se pretende implementar será configurado com um único título de transporte electrónico cujo funcionamento se baseia no modelo pós-pago. A configuração deste título de transporte é realizada pela CGD durante a fase de emissão e não será sujeita a alteração pelo sistema de bilhética dos TUB. Ou seja, nesta fase não poderão ser configurados no cartão outros tipos de transporte para além do original configurado pela CGD. Em termos de sistema de bilhética dos TUB, o tratamento deste tipo de cartão consistirá na validação abordo dos veículos e tratamento das transacções registadas. As transacções serão registadas pelos equipamentos instalados a bordo dos veículos de transporte e enviadas para o sistema de informação central, que por sua vez enviará para a entidade bancária os dados referentes às transacções de cartões bancários. Após o tratamento dessa informação, a entidade bancária irá debitar automaticamente o valor das viagens na conta do cliente. Finalmente, a entidade bancária pagará à empresa de transporte os valores correspondentes às viagens realizadas pelos passageiros, de acordo com o acordo celebrado entre as empresas. Em suma, o modelo pós-pago tem como característica principal o facto de o cliente só pagar os custos das viagens (neste caso através de debito directo em conta) após as realizar. 3

18 1.3 Objectivos O objectivo deste trabalho é o desenvolvimento de um sistema de informação que faça a ponte entre a base de dados de bilhética dos TUB e a CGD. Figura 1 Fluxo de informação Este objectivo principal pode ser dividido em objectivos mais elementares. Em termos da arquitectura do sistema, pretende-se: Desenvolvimento de uma aplicação back-office que processe as transacções de bilhética referentes a cartões bancários. Configuração de um serviço robusto e seguro de troca de ficheiros de informação com a CGD. 4

19 Em termos funcionais, pretende-se que o sistema: Faça chegar à CGD a informação que permita a realização dos débitos relativos a viagens nos TUB. Forneça aos TUB uma aplicação back-office que faça a triagem de todas as transacções dos equipamentos embarcados dos TUB, recolhendo somente a informação relativa às transacções efectuadas com o cartão CGD-TUB. Em termos de conhecimento, este trabalho inclui a integração de diferentes tecnologias para desenvolvimento do sistema back-office, bem como a utilização de várias ferramentas Microsoft que suportam essas tecnologias. 5

20 Capítulo II Linguagem utilizada para troca de ficheiros Inicialmente os computadores trocavam dados entre si através de ficheiros que continham informação separada por espaços, traços ou também parágrafos que significariam, por exemplo, uma nova informação. Contudo, estes ficheiros eram muito complexos e incompreensíveis. Com o aparecimento da internet foi necessário criar uma linguagem universal, surgindo o SGML, tendo este sido a base para a criação posterior do HTML. O HTML é uma linguagem que descreve a exibição de uma página Web. Para além da informação propriamente dita, a linguagem HTML contém informação adicional referente à apresentação e layout gráfico de texto e imagem. Contudo, o HTML apresenta uma lacuna no que toca à definição do conteúdo dos dados. Para fazer face a esta lacuna, surgiu o XML para se obter uma melhor gestão de informação. 2.1 XML extensible Markup Language O XML é, como o próprio nome indica, uma linguagem de marcação de dados onde todas as pessoas podem criar a sua linguagem para descrever dados estruturados [2], como por exemplo, o que acontece com empresas aeronáuticas onde criam a sua própria linguagem XML para trocar informações sobre dados técnicos dos aviões. O mesmo se passa no meio financeiro, nas trocas de informações relativas a transacções, mais concretamente, tem-se o exemplo do XHTML que é um HTML baseado em regras do XML. Podemos então reunir algumas características do XML [3]: define o conteúdo de dados tags descrevem os dados 6

21 extensível, ou seja, permite um número ilimitado de tags, pois qualquer pessoa pode criar novas tags o XML é independente da plataforma informática utilizada (Windows, Linux, Mac, etc.) o XML é flexível, pois pode ser utilizado por qualquer tipo de área de negócios, ou seja, pode representar uma grande variedade de informação. Um ficheiro XML contém elementos, sendo que estes podem estar divididos em subelementos, e atributos que permitem qualificar os dados e dar-lhes um sentido. Os elementos podem tomar dois formatos [4]: com conteúdo ou vazio. Um elemento vazio pode ser, por exemplo, <nomeelemento/> ou <nomeelemento></nomeelemento>. Se o elemento tiver conteúdo, então este encontrase entre a tag inicial <nomeelemento> e a tag final </nomeelemento>. Os atributos [5] estão dentro da tag inicial do elemento e possuem um nome e um valor que tem que estar dentro de aspas. Para uma melhor compreensão, considere seguinte exemplo de XML: <Plasticos IDFicheiro=" " IDUltimoFich=" "> <Plastico> <ReferenciaMov>200</ReferenciaMov> <DataEmissao> </DataEmissao> <DataExpiracao> </DataExpiracao> <DataStatus> </DataStatus> <Status>E</Status> </Plastico> </Plasticos> O elemento raiz [5] do XML é a tag <Plasticos> e é constituído por um subelemento <Plástico>. O sub-elemento <Plastico> possuí 5 sub-elementos. O elemento <Plasticos> possui dois atributos: IDFicheiro e IDUltimoFich tendo estes como valor e respectivamente. Nos sub-elementos podemos verificar por exemplo que o conteúdo do sub-elemento <Status> é E. Um ficheiro XML tem que obedecer a algumas regras de boa-formação, como por exemplos: 7

22 case-sensitive, ou seja, existe diferenciação entre maiúsculas e minúsculas [5] um elemento não pode começar por um algarismo [4] todos os elementos têm de ser fechados pela ordem de abertura. Por exemplo, <Plasticos><Plastico><Plastico/><Plasticos/> [6] o valor dos atributos tem de estar escrito dentro de aspas [5]. Um documento XML, como o do exemplo anterior, obedece a estas regras, logo é dito bem formado [7], no entanto isso não significa que seja válido. Na troca de ficheiros XML entre dois sistemas informáticos independentes, como é o caso do projecto descrito nesta dissertação, é necessário estabelecer regras neutras que definem os elementos e atributos válidos, ou seja, estabelecer regras gramaticais. Voltando ao exemplo anterior, a construção XML está bem-formada, isto é obedece às regras acima enunciadas, mas os dados podem não estar. Por exemplo se definirmos que o elemento ReferenciaMov é do tipo numérico, caso o respectivo conteúdo seja um valor tipo texto, a informação contida no ficheiro não poderá ser interpretada correctamente pelo sistema de destino. Neste caso, o ficheiro não é válido. O mesmo acontece relativamente à hierarquia de elementos, por exemplo, se o elemento DataEmissao não estiver definido como sub-elemento de Plastico. Para fazer a validação de documentos XML existem dois métodos, o DTD e o XML- Shema. De seguida será abordada o método utilizado neste projecto. 2.2 XML schema A XML Schema ou XML Schema Definition (XSD) é uma linguagem que permite definir o formato de um tipo de ficheiro XML. Um XML shema é um ficheiro escrito nessa linguagem e que descreve a estrutura e conteúdo do respectivo tipo de ficheiros XML. Todo o ficheiro XML que respeite o formato definido pelo XML schema é então dito válido [7]. 8

23 Na generalidade, um ficheiro XSD descreve [7]: os elementos e atributos que podem estar presentes num documento XML hierarquia entre os elementos ordem e quantidade dos sub-elementos o tipo de dados dos elementos e atributos os valores por defeito, formato ou a restrição dos valores de um elemento ou de um atributo Elementos A raiz de um ficheiro XSD é o elemento <xs:schema>. Todos os elementos e atributos de um XML são representados num schema Elemento simples Um elemento do tipo simples [7], é um elemento XML que somente pode conter um valor, sem sub-elementos ou atributos, como por exemplo: XML <elemento> valorelemento </elemento> XSD schema <xs:element name= elemento type xs:string /> Os tipo de dados xs:string, xs:decimal e xs:integer são dos mais frequentes nos elementos simples. Estes elementos podem ter valores fixos, <xs: element name= elemento type= xs:string fixed= valorelemento />, ou valores atribuídos por defeito, <xs: element name= elemento type= xs:string default= valorelemento />. Um valor por defeito é um valor standard que é atribuído ao 9

24 elemento, sendo que este pode conter outro valor. No caso do valor fixo, o elemento tem que forçosamente conter esse valor. Logo, se constar na escrita XML um valor nesse elemento diferente do fixo, ou se o valor por defeito não corresponder ao tipo de dados estabelecido, então o ficheiro XML não é válido Elemento complexo Os elementos do tipo complexo [7] são elementos XML que contém outros elementos e/ou atributos, utilizam a tag <xs:complextype>. De seguida verifica-se um exemplo de um elemento sem conteúdo e com um atributo. XML <elemento nomeatributo= valoratributo > </elemento> XSD <xs:element name= elemento > <xs:complextype> <xs:attribute name= nomeatributo type= string /> </xs:complextype> </xs:element> Atributos Tal como os elementos os atributos [7] podem ter valores fixos ou valores por defeito, seguindo as mesmas regras de atribuições explicadas anteriormente nos elementos. Existe a possibilidade de declarar atributos como sendo obrigatórios, <xs: attribute name= atributo type= xs:string use= required />, ou opcionais, <xs: attribute name= atributo type= xs:string use= optional />. 10

25 2.2.3 Restrições As restrições [7] são importantes na medida em que permitem definir o comportamento dos elementos e dos atributos de forma mais específica. A seguir serão abordados alguns tipos de restrições. A restrição do tipo de dados é das mais utilizadas, criando uma restrição ao conteúdo do elemento/atributo. Por exemplo, se um elemento é do tipo xs:integer e num documento XML o seu valor é 23s2 (um tipo de dado xs:string), então a restrição do tipo de dado não é cumprida, e o ficheiro XML não é válido. A restrição de valor consiste em obrigar um elemento a ter um valor pertencente a um intervalo entre dois valores numéricos limite. XML <Quantidade>15</Quantidade> XSD <xs:element name= Quantidade > <xs:simpletype> <xs:restriction base = xs:integer > <xs:mininclusive value= 10 /> <xs:maxinclusive value= 20 /> </xs:restriction> </xs:simpletype> </xs:element> A Restrição de lista de valores significa que um elemento poderá ter um determinado valor desde que esteja presente numa lista de valores. 11

26 XML <DiaSemana>Sábado </DiaSemana> XSD <xs:element name= DiaDaSemana > <xs:simpletype> <xs:restriction base = xs:string > <xs:enumeration value= Segunda-feira /> <xs:enumeration value= Terça-feira /> <xs:enumeration value= Quarta-feira /> <xs:enumeration value= Quinta-feira /> <xs:enumeration value= Sexta-feira /> <xs:enumeration value= Sábado /> <xs:enumeration value= Domingo /> </xs:restriction> </xs:simpletype> </xs:element> A Restrição de comprimento serve para restringir o comprimento de um elemento, ou seja, a quantidade de caracteres desse elemento, independentemente do tipo de dados utilizado, <xs: lenght value= Valor comprimento />. XML <Pin>1234</Pin> XSD <xs:element name= Pin > <xs:simpletype> <xs:restriction base = xs:string > <xs:length value= 4 /> </xs:restriction> </xs:simpletype> </xs:element> Indicadores Os indicadores [7] permitem controlar o fluxo de utilização dos elementos. Os indicadores utilizados nesta dissertação pertencem aos indicadores de ordem e de ocorrência. Para além destes existe ainda os indicadores de grupo. 12

27 Os indicadores de ordem servem, como o próprio nome deixa antever, para definir a ordem do aparecimento dos elementos. Existem três tipos: xs:all, os sub-elementos têm que aparecer uma vez, e a ordem não é relevante xs:choice, somente um dos sub-elementos pode aparecer no ficheiro XML xs:sequence, os sub-elementos devem aparecer numa ordem específica. Os indicadores de ocorrência servem para restringir a quantidade de vezes que um elemento ou sub-elemento podem aparecer. maxoccurs, número máximo de vezes que um elemento ou subelemento pode surgir. Por defeito é 1 e para ser um valor ilimitado utiliza-se maxoccurs= unbounded minoccurs, número mínimo de vezes que um elemento ou subelemento pode surgir. Por defeito é Analogia Para melhor compreensão deste capítulo, será realizada de seguida uma analogia entre uma sobremesa chamada Pudim Abade de Priscos e o XML/XML schema. O Pudim Abade de Priscos é uma sobremesa minhota concebida pelo Abade de Priscos, Manuel Joaquim Machado Rebelo, pároco da freguesia de Priscos, concelho de Braga, considerado como um dos maiores cozinheiros portugueses do séc. XIX. Os ingredientes desta sobremesa podem ser expressos no seguinte XML válido, 13

28 <Sobremesa nome= Pudim Abade de Priscos > <gemasovos>15</gemasovos> <açucar>500</açucar> <toucinho>50</toucinho> <água>meiolitro</água> <cálicevinhoporto>1</cálicevinhoporto> <cascalimão>1</cascalimão> <paucanela>1</paucanela> <caramelo>200</caramelo> </Sobremesa> Por analogia, a receita do Pudim abade de Priscos é representada num XML schema, <xs:element name="sobremesa"> <xs:complextype> <xs:sequence> <xs:element name="gemasovos" type="xs:positiveinteger" fixed= 15 /> <xs:element name="açucar"> <xs:simpletype> <xs:restriction base ="xs:positiveinteger"> <xs:mininclusive value= "400"/> <xs:maxinclusive value= "600"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="toucinho" type="xs:positiveinteger" fixed= 50 /> <xs:element name="água" type="xs:string"/> <xs:elemento name="cálicevinhoporto" type="xs:positiveinteger" fixed= 1 /> <xs:element name="cascalimão" type="xs:positiveinteger" fixed= 1 /> <xs:element name="paucanela" type="xs:positiveinteger" fixed= 1 /> <xs:element name="caramelo"> <xs:simpletype> <xs:restriction base ="xs:string"> <xs:enumeration value= "200"/> <xs:enumeration value= "CarameloLiquido"/> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> <xs:attribute name="nome" type="xs:string" use="required"/> </xs:complextype> </xs:element> 14

29 <Sobremesa nome= Pudim Abade de Priscos > <gemasovos>16</gemasovos> <açucar>500</açucar> <toucinho>50</toucinho> <água>meiolitro</água> <cálicevinhoporto>1</cálicevinhoporto> <cascalimão>1</cascalimão> <paucanela>1</paucanela> <caramelo>200</caramelo> </Sobremesa> Para se confeccionar um Pudim Abade de Priscos são necessários os seguintes ingredientes: 15 gemas de ovos, entre 400 a 600 gramas de açúcar, 50 gramas de toucinho fresco, +/- meio litro de água, um cálice de vinho do Porto, uma casca de limão, um pau de canela e 200 gramas de açúcar extra para fazer o caramelo, ou utilizar caramelo líquido. Todos os valores têm que ser inteiros positivos excepto a água e o caramelo que podem ser inteiro positivo ou texto. Validação Erro na validação Figura 2 Analogia XML / XSD receita culinára No esquema acima, verifica-se um erro na validação, visto que a sobremesa não respeita os dados dos ingredientes contidos na receita. A quantidade de gemas de ovos é o motivo do erro na validação. No XML schema (receita) existem vários tipos de restrições. Restrições do tipo de dados ( Todos os valores têm que ser inteiros positivos excepto a água e o caramelo que pode ser inteiro positivo ou um texto ), restrição de valor ( entre 400 a 600 gramas de açúcar ), e restrição de lista de valores ( 200 gramas de açúcar extra para fazer o caramelo ou utilizar caramelo líquido ). Por último existe um elemento complexo chamado Sobremesa que contém um atributo obrigatório para especificar o tipo de sobremesa, contém também oito sub-elementos dos quais alguns possuem valor fixo como é o caso das gemas de ovos, do toucinho, do cálice de vinho do Porto, da casca de limão e do pau de canela. 15

30 Capítulo III Especificação de ficheiros XML/XSD O presente capítulo tem como objectivo apresentar a arquitectura de comunicação, a especificação dos ficheiros XML bem como o respectivo XML schema, e a aplicação que permite a validação offline de ficheiros gerados utilizando XML schema. 3.1 Arquitectura da troca de ficheiros A figura 3 apresenta o fluxo de informação da troca de ficheiros. Figura 3 Troca de ficheiros 16

31 Como se observa na figura existe uma troca de ficheiros bidireccional através da internet. Para tal é criado um túnel de comunicação para impedir acesso aos dados de agentes externos que se encontrem na rede. A tecnologia qua permite estabelecer este canal de comunicação de forma segura designa-se por VPN. O fluxo de informação será visto mais ao detalhe no capítulo Especificação dos Ficheiros Na tabela 1 descreve-se o formato e a quantidade de atributos ou sub-elementos dos dados utilizados nas mensagens. Tabela 1 Formato Formato Descrição N(x) Valor numérico até x dígitos. Str(x) Valor alfanumérico até x caracteres. N(x) D(y) Valor numérico com x dígitos para a parte inteira e y dígitos para a parte decimal. 1,1 Pode conter somente 1 atributo ou sub-elementos 1,N(x) Pode conter de 1 até N atributos ou sub-elementos 0,N(x) Pode conter de 0 até N atributos ou sub-elementos De salientar que todos os ficheiros possuem dois atributos em comum, o IDFicheiro e IDUltimoFich. O IDFicheiro, representa o número de identificação de cada ficheiro que permite correlacionar o ficheiro em questão com o respectivo ficheiro de retorno. O IDUltimoFich corresponde ao último ficheiro enviado. O formato destes dois atributos é: AAAAMMDDSSSS, em que: AAAA representa o ano, MM o mês, DD o Dia e SSSS o número de sequência diário. 17

32 3.2.1 Ficheiros Plásticos O ficheiro Plasticos é enviado pelo sistema CGD para o sistema TUB, com informação relativa a novos plásticos emitidos e alterações de status dos plásticos com chip contactless. O envio deste ficheiro depende da existência de registos na CGD a enviar para actualizar a base de dados dos TUB, sendo realizado quando se verificar uma ou mais das seguintes situações: a SIBS informar a CGD de novos plásticos emitidos com chip contactless ; algum dos plásticos com chip contactless for cancelado ; algum dos plásticos com chip contactless estiver em incumprimento (temporariamente cancelado) ; algum dos plásticos com chip contactless for reactivado (pelo pagamento da dívida). Após a recepção deste ficheiro serão adicionados novos cartões ao sistema e será feita a actualização dos estados dos cartões já existentes Estrutura do Ficheiro de Plásticos Direcção da Mensagem: CGD -> TUB 18

33 Descrição do Elemento Plásticos A tabela 2 possui o formato dos dois atributos do elemento Plasticos bem como o subelemento Plastico. Tabela 2 - Plasticos <Plasticos> Formato 1,1 Atributo IDFicheiro N(12) 1,1 Atributo IDUltimoFich N(12) 1, N(x) Sub-elemento Plastico Ver tabela nº 3 Exemplo: <Plasticos IDFicheiro=" " IDUltimoFich=" "> <Plastico> </Plastico> </Plasticos> Descrição do sub-elemento Plástico A tabela 3 possui os 5 sub-elementos pertencentes ao elemento Plastico: ReferenciaMov representa o número de referência CGD. Este número é atribuído ao cartão a quando da emissão e é um número único no sistema. DataEmissao, DataExpiracao e DataStatus possuem o formato AAAAMMDDSSSS, descrito anteriormente. Ao que toca o sub-elemento DataEmissao como o nome indica é a data de emissão do cartão, o sub-elemento DataExpiracao é a data de fim de validade do cartão CGD e por sua vez o sub-elemento DataStatus é a data de actualização do status do cartão, logo é a data em que o status foi gerado pela primeira vez ou actualizado. 19

34 Status é o estado em que o cartão se encontra. Pode possuir os seguintes estados: C Cancelado E Emitido T Temporariamente Cancelado R - Reactivado Tabela 3 - Plastico <Plastico> Formato 1,1 ReferenciaMov N(9) 1,1 DataEmissao N(8) 1,1 DataExpiracao N(8) 1,1 DataStatus N(8) 1,1 Status Str(1) Exemplo: <Plastico> <ReferenciaMov>8</ReferenciaMov> <DataEmissao> </DataEmissao> <DataExpiracao> </DataExpiracao> <DataStatus> </DataStatus> <Status>C</Status> </Plastico> 20

35 3.2.2 Ficheiro de Retorno Status Plásticos Este ficheiro é produzido pelo sistema TUB para o sistema CGD sempre que for processado um ficheiro com alteração de status de um plástico com chip contactless, quer tenham ocorrido ou não erros. Se o ficheiro foi tratado correctamente, é adicionado um registo no ficheiro Retorno Status Plasticos, no elemento RetPlasticos, com a seguinte informação: <RetPlasticos IDFicheiro=" " IDUltimoFich=" " CodigoErro="0"></RetPlasticos> Caso seja detectado algum erro com a informação dos plásticos presentes no ficheiro PLST, será adicionado um registo de detalhe no elemento RetPlastico, que inclui os dados do registo original que apresenta erros. Cada erro é classificado em função da sua especificidade Estrutura do Ficheiro de Retorno Status Plasticos Direcção da Mensagem: TUB -> CGD Retorno Status Plásticos A tabela 4 possui os formatos dos 3 atributos do elemento RetPlasticos bem como o sub-elemento RetPlastico. O atributo CodigoErro representa o erro associado ao ficheiro Plasticos. Pode possuir os seguintes código de erros: 0 - Ficheiro Pasticos válido 1 - Ficheiro Plasticos inválido 3 - Erro na sequência 6 - Conteúdo do Plastico contendo erros 21

36 Tabela 4 - RetPlasticos <RetPlasticos> Formato 1,1 IDFicheiro N(12) 1,1 IDUltimoFich N(12) 1,1 CodigoErro Str(2) 0, N(x) RetPlastico Ver tabela nº 5 De salientar que os códigos de erro descritos na tabela não são sequenciais. Com efeito, o elemento CodigoErro passa de 1 para 6 devido ao facto de existirem outros códigos de erro alheios ao sistema dos TUB. Esses códigos foram sugeridos pela CGD durante o processo de definição do protocolo, porque fazem parte de uma nomenclatura utilizada pela CGD noutros sistemas. Exemplo: <RetPlasticos IDFicheiro=" " IDUltimoFich=" " CodigoErro="1"> <RetPlastico> </RetPlastico> </RetPlasticos> Elemento RetPlastico Informação detalhada em caso de CodigoErro diferente de zero A tabela 5 possui o formato dos 6 sub-elementos do elemento RetPlastico. Cada elemento RetPlastico repete a descrição de um cartão (campos do elemento Plastico) que consta do ficheiro Plásticos e que originou erro, contendo as mesmas referências vistas no ponto

37 O último sub-elemento deste elemento é o código que descreve o erro. Este subelemento CodigoErro possui vários tipos de códigos de erros: 1 - Referência Movimento inválida (por exemplo, actualização do estado para C de um plástico que nunca foi registado com o estado E ) 2 - Data de Emissão Inválida 3 - Data de Expiração Inválida 4 - Data de Alteração de Status Inválida 5 - Novo Status Inválido (o código de Status enviado no ficheiro não corresponde com a nomenclatura definida no protocolo ex: Status A ) 6 - Alteração de Status Inválida (por ex., passagem de C para R ) Tabela 5 - RetPlastico <RetPlastico> Formato 1,1 ReferenciaMov N(9) 1,1 DataEmissao N(8) 1,1 DataExpiracao N(8) 1,1 DataStatus N(8) 1,1 Status Str(1) 1,1 CodigoErro Str(2) Ver exemplo no anexo I. 23

38 3.2.3 Ficheiro de Transacções Ficheiro enviado do sistema TUB para o sistema CGD, com informação relativa às transacções efectuadas no universo TUB. Diariamente, o sistema irá consolidar a informação de todas as transacções de validação efectuadas, gerando um único ficheiro com todas as transacções referentes a validações de cartões CGD-TUB processadas. Este ficheiro é depois enviado para o sistema CGD Estrutura do Ficheiro de Transacções Direcção da Mensagem: TUB -> CGD Transacções A tabela 6 possui o formato dos dois atributos do elemento Transaccoes bem como o sub-elemento Transaccao. Tabela 6 - Transaccoes <Transaccoes> Formato 1,1 IDFicheiro N(12) 1,1 IDUltimoFich N(12) 1, N(x) Transaccao Ver tabela nº 7 Exemplo: <Transaccoes IDFicheiro=" " IDUltimoFich=" "> <Transaccao> </Transaccao> </Transaccoes> 24

39 Transacção A tabela 7 contém os 12 sub-elementos pertencentes ao elemento Transaccao: TipoTransaccao - representa o tipo de transacção efectuada, sendo atribuído pela CGD o número 05. RefTUB - é a referência TUB, esta referência identifica univocamente a transacção no sistema TUB. ReferenciaMov - representa o número de referência CGD. Este número é atribuído ao cartão a quando da emissão e é um número único no sistema. CodigoOperador - é o código atribuído à entidade de transportes públicos, neste caso é atribuído o CodigoOperador 1 TUB. CodigoMaquina - é o código da máquina de Venda/Validação/Personalização do operador. TipoTransaccaoTUB - representa o tipo de validação do cartão, isto é, se a validação é efectuada à entrada ou à saída do veículo. O TipoTransaccaoTUB pode tomar dois valores: 0 Saída 1 Entrada Neste caso só existirá o tipo 1 (Entrada), já que todas as validações serão realizadas à entrada do veículo.os veículos dos TUB não têm validadores à saída. DataMovimento é a data em que foi efectuado o movimento, tem oformato visto anteriormente: AAAAMMDD. HoraMovimento é a hora em que foi efectuado o movimento, tem o formato: HHMMSS, em que: HH representa a hora, MM os minutos e SS os segundos. ValorTarifaBase é como o nome indica o valor da tarifa base. DescLocalizacao descreve a localização do equipamento. ValorMovimento é o valor efectivamente cobrado. Calculado no servidor a partir do valor da tarifa base e conforme as regras de negócio acordadas entre as duas entidades. CodigoMoeda é o código de moeda inicialmente atribuído pela CGD. 25

40 Tabela 7 - Transaccao <Transaccao> Formato 1,1 TipoTransaccao N(2) 1,1 RefTUB Str(40) 1,1 ReferenciaMov N(9) 1,1 CodigoOperador Str(1) 1,1 CodigoMaquina Str(5) 1,1 TipoTransaccaoTUB Str(2) 1,1 DataMovimento N(8) 1,1 HoraMovimento N(6) 1,1 ValorTarifaBase N(11) D(02) 1,1 DescLocalizacao Str(40) 1,1 ValorMovimento N(11) D(02) 1,1 CodigoMoeda Str(3) Ver exemplo no anexo II Ficheiro de Retorno Status TRANSACÇÕES Este ficheiro é produzido pelo sistema CGD para o sistema TUB sempre que for processado um ficheiro do tipo transacções, quer tenham ocorrido, ou não, erros no processamento das transacções. Se o ficheiro foi tratado correctamente, é adicionado um registo no ficheiro Retorno Status Transaccoes, no elemento RetTransaccoes, com a seguinte informação: <RetTransaccoes IDFicheiro=" " IDUltimoFich=" " CodigoErro="0"></RetTransaccoes>. 26

41 Caso seja detectado algum erro com a informação das transacções presentes no ficheiro TRAN, será adicionado um registo de detalhe no elemento RetTransaccao, que inclui os dados do registo original que apresenta erros. Cada erro é classificado em função da sua especificidade Estrutura do Ficheiro de Retorno Status Transacções Direcção da Mensagem: CGD -> TUB Retorno Status Transacções A tabela 8 possui o formato dos 3 atributos do elemento RetTransaccoes bem como o sub-elemento RetTransaccao. O atributo CodigoErro representa o erro associado ao ficheiro Transaccoes. Pode possuir os seguintes código de erros: 0 - Aceite 1 - Ficheiro Transaccoes inválido 6 - Conteúdo da Transaccao contendo erros Tabela 8 - RetTransaccoes <RetTransaccoes> Formato 1,1 IDFicheiro N(12) 1,1 IDUltimoFich N(12) 1,1 CodigoErro Str(2) 0, N(x) RetTransaccao Ver tabela nº 9 Ver exemplo no anexo III. 27

42 Retorno Status Transacção A tabela 9 possui o formato dos 13 sub-elementos do elemento RetTransaccao. Os 12 primeiros sub-elementos repetem o formato e características descritas no ponto O último sub-elemento, CodigoErro, representa o código de erro da transacção. Este subelemento CodigoErro possui vários tipos de códigos de erros: 1 - Tipo de transacção inválida 2 Referência do movimento inválido 3 - Data do movimento inválido 4 Código de moeda inválido Tabela 9 - RetTransaccao <RetTransaccao> Formato 1,1 TipoTransaccao Str(2) 1,1 RefTUB Str(40) 1,1 ReferenciaMov N(9) 1,1 CodigoOperador Str(2) 1,1 CodigoMaquina Str(5) 1,1 TipoTransaccaoTUB Str(2) 1,1 DataMovimento N(8) 1,1 HoraMovimento N(6) 1,1 ValorTarifaBase N(11) D(2) 1,1 DescLocalizacao Str(40) 1,1 ValorMovimento N(11) D(2) 1,1 CodigoMoeda Str(3) 1,1 CodigoErro Str(2) Ver exemplo no anexo IV. 28

43 3.2.5 Ficheiro de MOVIMENTOS Ficheiro enviado pelo sistema CGD para o sistema TUB, com os créditos efectuados na conta bancária dos TUB. A periodicidade deste ficheiro depende da existência de transacções e do acordo comercial entre a CGD e os TUB relativamente ao pagamento por parte da CGD das transacções realizadas no sistema de bilhética dos TUB Estrutura do Ficheiro de Movimentos Direcção da Mensagem: CGD -> TUB Movimentos A tabela 10 possui o formato dos dois atributos do elemento Movimentos bem como o sub-elemento Movimento. Tabela 10 - Movimentos <Movimentos> Formato 1,1 IDFicheiro N(12) 1,1 IDUltimoFich N(12) 1, N(x) Sub-elemento Movimento Ver tabela nº 11 Exemplo: <Movimentos IDFicheiro=" " IDUltimoFich=" "> <Movimento> </Movimento> </Movimentos> 29

44 Movimento A tabela 11 possui os 3 sub-elementos pertencentes ao elemento Movimento: ValorMovimento é a quantia paga pela CGD aos TUB. DataMovimento é a data do movimento tendo o formato e características vistas anteriormente. NIB é o número de identificação bancária para o qual a CGD transfere o valor do movimento. Tabela 11 - Movimento <Movimento> Formato 1,1 ValorMovimento N(11) D(2) 1,1 DataMovimento N(8) 1,1 NIB Str(21) Exemplo: <Movimento> <ValorMovimento>110.00</ValorMovimento> <DataMovimento> </DataMovimento> <NIB> </NIB> </Movimento> Ficheiro de Retorno Status MOVIMENTOS Este ficheiro é produzido pelo sistema TUB e enviado para o sistema CGD sempre que for processado um ficheiro de movimentação da conta bancária dos TUB, quer tenham, ou não, ocorrido erros. Os registos de detalhe incluem os dados do registo original que apresenta erros. 30

45 Estrutura do Ficheiro de Retorno Status Movimentos Direcção da Mensagem: TUB -> CGD Retorno Status Movimentos A tabela 12 possui o formato dos 3 atributos do elemento RetMovimentos bem como o sub-elemento RetMovimento. O atributo CodigoErro representa o erro associado ao ficheiro Movimentos. Pode possuir os seguintes código de erros: 0 - Ficheiro Movimentos válido 1 - Ficheiro Movimentos inválido 3 - Erro na sequência 6 - Conteúdo de Movimento contendo erros Tabela 12 - RetMovimentos <RetMovimentos> Formato 1,1 IDFicheiro N(12) 1,1 IDUltimoFich N(12) 1,1 CodigoErro Str(2) 0, N(x) Movimento Ver tabela nº 13 Exemplo: <RetMovimentos IDFicheiro=" " IDUltimoFich=" " CodigoErro="06"> <RetMovimento> </RetMovimento> </RetMovimentos> 31

46 Retorno Status Movimento A tabela 13 possui o formato dos 4 sub-elementos do elemento RetMovimento. O sub-elemento CodigoErro é o código que descreve o erro. Este sub-elemento CodigoErro possui dois tipos de códigos de erros: 1 - NIB inválido 2 - Data do Movimento Inválida Tabela 13 - RetMovimento <RetMovimento> Formato 1,1 ValorMovimento N(11) D(2) 1,1 DataMovimento N(8) 1,1 NIB Str(21) 1,1 CodigoErro Str(2) Em relação aos códigos de erro, pode acontecer o caso da CGD enviar um NIB que não corresponda à conta bancária dos TUB, ou ainda que falte um digito no NIB. Ao que toca o código de erro relacionado à data de movimento, acontece como o próprio nome indica sempre que a data não apresenta o formato estabelecido no modelo de dados. Exemplo: <RetMovimento> <ValorMovimento>110.00</ValorMovimento> <DataMovimento> </DataMovimento> <NIB> </NIB> <CodigoErro>01</CodigoErro> </RetMovimento> 32

47 3.3 Nomenclatura dos Ficheiros os ficheiros. O protocolo definido com a CGD inclui, também, a definição de uma nomenclatura para Na tabela em baixo demonstra-se a nomenclatura a utilizar para cada tipo de Ficheiro. Tabela 14 Nomenclatura utilizada para os ficheiros Tipo de Ficheiro Plásticos Retorno Plásticos Transacções Retorno Transacções Movimentos Retorno Movimentos Nomenclatura PLST_2_TUB _AAAAMMDDSSSS.xml EPST_2_TUB _AAAAMMDDSSSS.xml TRAN_2_TUB _AAAAMMDDSSSS.xml ETRN_2_TUB _AAAAMMDDSSSS.xml DSTR_2_TUB _AAAAMMDDSSSS.xml EDTR_2_TUB _AAAAMMDDSSSS.xml 3.4 Validação Offline A validação offline é um método auxiliar de teste criado para testar a correcta geração dos ficheiros XML. Esta validação é realizada para verificar a coerência dos ficheiros XML e se estes foram correctamente gerados, respeitando as normas e restrições previstas no respectivo XML schema. Assim, foi desenvolvida uma aplicação chamada XML_XSD para visualização do processo de validação do ficheiro XML através do respectivo XML schema. Esta ferramenta será útil sempre que seja necessário realizar alterações na aplicação principal por motivo de necessidade de alterar o modelo de dados actual. Os novos ficheiros gerados poderão ser testados com esta aplicação, a partir do novo XSD que for definido no protocolo. 33

48 A figura 4 apresenta o aspecto da aplicação XML_XSD. Figura 4 Aplicação de validação ficheiros XML Como a figura 4 ilustra, existe um conjunto de separadores que possui três separadores (Menu, Dir./Ficheiros,log). Inicialmente, tem que se seleccionar o separador número 2, ou seja, seleccionar o separador Dir./Ficheiros para seleccionar os ficheiros XML e os respectivos XSD para validação. O separador Log permite monitorizar o resultado das validações. Após escolher os ficheiros no separador Dir./Ficheiros, o utilizador pode passar para o separador Menu, onde existem três botões com as seguintes funções: Botão Iniciar a Aplicação Executa o arranque do processamento. Botão GravarLog Permite gravar registar num ficheiro as diversas operações executadas pela aplicação. Botão Terminar Aplicação Permite encerrar a aplicação. 34

49 Capítulo IV Ferramentas e linguagens de desenvolvimento utilizadas As linguagens de programação utilizadas neste trabalho foram o VB.net e SQL. A ferramenta de desenvolvimento foi o Microsoft Visual Studio A base de dados do sistema e todo o desenvolvimento realizado ao nível da estruturação das tabelas e programação de tarefas foi realizado através do editor Microsoft SQL Server Management Studio, incorporado na plataforma Microsoft SQL Server A base de dados do sistema funciona sobre esta plataforma. O sistema a implementar, assim como as aplicações referidas nesta dissertação, serão instalados num servidor com sistema operativo Microsoft Windows Small Business Server 2003 [8]. Relativamente ao mecanismo de troca bidireccional de ficheiros entre o sistema TUB e o sistema CGD, inicialmente tinha-se optado pelo serviço FTP, por se tratar de um protocolo largamente utilizado nas redes e de relativa facilidade de implementação. No entanto, no seguimento dos contactos com a CGD no âmbito da coordenação dos dois sistemas, esta entidade sugeriu a utilização do mecanismo de partilha de pastas de rede. Esta funcionalidade existe no sistema operativo do servidor TUB e apresenta-se ainda mais simples de implementar do que através do protocolo FTP. O acesso às pastas partilhadas do servidor TUB é realizado através de uma VPN estabelecida a partir do sistema CGD para o sistema TUB. 4.1 VB.net O Visual Basic.net [9] é uma linguagem de programação orientada a objectos incorporada no ambiente integrado de desenvolvimento Visual Studio.net 2005, que por sua vez faz parte da plataforma Microsoft.NET. Esta tecnologia permite simplificar a criação, distribuição e evolução contínua de aplicações Windows, aplicações Web e serviços Web seguros. 35

50 4.1.1 Linguagem orientada a objectos A linguagem orientada a objectos apareceu nos anos 90 para trazer algo de revolucionário na área da programação, novas características e funcionalidades que não existiam na linguagem de programação da geração anterior, denominada por estruturada. Mas afinal o que são os objectos? A resposta a esta pergunta pode ser encontrada nas coisas que rodeiam o quotidiano das pessoas, podendo-se fazer uma analogia entre os objectos do mundo real e os objectos do mundo virtual. No mundo real existem objectos de vários tipos, objectos simples como por exemplo uma caneta, objectos mais complexos como por exemplo um computador, um carro. Por sua vez no mundo virtual podemos considerar qualquer coisa como sendo um objecto, por exemplo, animais, plantas, seres vivos, etc. Neste mundo virtual o papel fundamental dos objectos pode ser resumido a duas coisas: primeiramente os objectos podem ter características, tais como uma cor, tamanho, número de telefone, etc.; segundo, podem realizar tarefas e serem modificados, por exemplo num carro, podemos abrir uma porta, ligar o carro, as luzes. Os objectos podem ser agrupados numa categoria, num grupo desde que têm as mesmas características e que realizem as mesmas tarefas, no mundo virtual esse grupo é chamado por Classe. Como exemplo podemos utilizar os carros. Todos os carros têm um chassi, rodas, motor, cor, etc. e possuem todos a funcionalidade de locomoção e de poderem transportar algo. Logo, mesmo tendo vários carros com atributos e funcionalidades diferentes, ao fim ao cabo possuem certas características e funcionalidades em comum que possibilita agrupá-los numa Classe (grupo) chamada Automóveis. Se definir então uma Classe contendo atributos e funcionalidades dos automóveis, podese a partir da Classe criar vários tipos de automóveis diferentes uns dos outros mas que terão sempre em comum serem veículos motorizados que podem transportar algo. 36

51 Para finalizar, uma linguagem orientada a objectos tem todas as características da linguagem de programação estruturada, mais algumas: maior agilidade aumento da produtividade devido à diminuição da complexidade maior reutilização de código possibilita criar classes, definindo atributos e funcionalidades criação de objectos a partir de classes manipular características dos objectos. 4.2 Bases de dados Com o aumento do desenvolvimento da sociedade, da população e da tecnologia, os dados gerados pela actividade humana aumentaram de uma forma exponencial. Na era em que se vive hoje, a informática tem um papel fundamental para o armazenamento e tratamento desses dados. É ela umas das principais causas, se não a principal, causa do aumento drástico da quantidade de dados que a sociedade consome e trata. Para armazenar esses dados surgiram as bases de dados. Uma base de dados é um conjunto de informação armazenada e estruturada informaticamente. Esses dados devem poder ser utilizados por programas e utilizadores, permitindo uma grande flexibilidade em termos de pesquisa, leitura e escrita. De salientar que o conceito de armazenamento de dados existe muito antes da era informática. Mas, ainda não se denominavam de base de dados. Para armazenar a informação, utilizavam-se fichas reagrupadas em caixas chamadas ficheiros. As fichas eram tratadas, trilhadas manualmente e depois surgiram os cartões perfurados passando a triagem a ser feita de uma forma mecânica e depois de uma forma electromecânica. Estas tecnologias ficaram ultrapassadas com o desenvolvimento de base de dados informaticamente. 37

52 4.2.1 Base de dados relacional Uma base de dados relacional rege-se por um modelo relacional. Assim, o conteúdo dos dados pode ser sintetizado através de operações de álgebra relacional. O modelo relacional tem vários objectivos e vantagens [10]: propor esquemas de dados fáceis de utilizar optimizar o acesso à base de dados melhorar a integridade e confidencialidade independência sobre linguagens de programação, e dos sistemas de gestão de base de dados estabilidade em caso de alterações na base de dados pode ser utilizada por várias aplicações. Pode-se então de uma forma informal definir o modelo relacional da seguinte forma [10]: a base de dados é composta por tabelas e associações entre elas as tabelas são compostas por linhas e colunas que contêm valores (os dados) os dados são manipulados através de operações de álgebra relacional o estado coerente da base de dados é definida por regras de integridade SQL O SQL (Structured Query Language) [11] é uma linguagem destinada a criar, armazenar, manipular e encontrar dados presentes numa base de dados relacional. SQL é chamada linguagem standard, visto que todas as características e atributos da linguagem são idênticos em todos os fabricantes de sistemas gestores de base de dados relacionais (SGBDR). 38

53 Resumindo em alguns pontos, pode-se afirmar que o SQL possibilita: criar, remover e alterar base de dados inserir, alterar e apagar dados consultar dados. assegurar a consistência e integridade dos dados SQL Server 2005 O SQL Server 2005 é o SGBDR da plataforma Microsoft.net. As Principais características são: criar e colocar em produção aplicações seguras, eficazes e fiáveis colocar à disposição dos programadores um ambiente de desenvolvimento rico em funcionalidades, flexível e moderno que permite criar aplicações de base de dados seguras partilhar dados entre diversas plataformas, aplicações e sistemas para facilitar conexões internas e externas Conexões à base de dados e execução de comandos SQL A execução automática de comandos SQL através da aplicação Urge Trata XML implica a incorporação de código associado a estes comandos no código VB.net. Para permitir à aplicação executar comandos SQL, implementou-se uma função com objectivo de estabelecer uma conexão à base de dados SQL Server e executar os comandos SQL referentes às diversas operações. Esta função é genérica, pois, permite a sua reutilização em diversos pontos da aplicação. 39

54 Em termos gerais, esta função realiza a ligação (conexão) SQL com a base de dados, a qual requer os seguintes parâmetros: "Provider método de acesso a dados DataSource - nome de rede do servidor InitialCatalog - nome da base de dados SQL UserId - nome do acesso/login à base de dados SQL Password - código de acesso referente ao utilizador referido anteriormente. Os comandos SQL que a função deve executar são construídos através de uma cadeia de texto, que depois é passada como parâmetro à função. Essa cadeia de texto pode conter qualquer tipo de sintaxe SQL válida SQL Server Jobs Num mundo tão competitivo, em constante evolução e modificação, as empresas têm que estar em alerta para continuarem competitivas e para poderem agarrar novas oportunidades de negócio. Para tal, têm que estar a par da evolução das novas tecnologias, melhorar a estratégia da empresa tendo um conhecimento do mercado sempre actualizado, tentando inovar tanto a nível da organização, como a nível de novas ideias a desenvolver. Neste contexto, para tornar um dia de trabalho mais competitivo, eliminando tarefas repetitivas e que têm que ser realizadas numa determinada parte do dia, é fundamental conhecer e utilizar todas as funcionalidades e ferramentas que certos produtos oferecem. O caso do SQL Server é um bom exemplo. Todas as empresas que utilizam o SQL Server, necessitam de realizar backups periódicos, exportação/importação de dados num determinado horário, actualizações, etc. Para ajudar nestas tarefas, o SQL server possui uma funcionalidade muito útil chamada SQL Server Jobs. Um Job é então um mecanismo automático programável para realizar tarefas repetidas num determinado período de tempo. 40

55 De realçar que muitas pessoas confundem um Job com um Trigger. O Trigger é outra funcionalidade presente no SQL Server, possibilitando também realizar tarefas automáticas, mas ao contrário dos Jobs, para um Trigger ser executado deve ocorrer um determinado evento na base de dados. Ou seja, deve ser autónomo, tomar certas medidas e decisões em algumas situações, aquando de um comando de Insert, Delete ou Update for executado na base de dados. Resumindo, um Job é um comando programável que é executado automaticamente consoante a parametrização que foi utilizada pelo administrador da base de dados. Exemplo: Suponhamos que temos uma tabela com a informação do nome do cliente, data de inscrição, anos de contrato e termo de contrato. Uma aplicação de software regista o nome, a data de inscrição e os anos de duração do contrato. Poder-se-á programar um Trigger para executar uma operação de cada vez que seja introduzido um novo registo na tabela. Neste caso a operação consistiria em calcular a data de termo de contrato a partir da data de inscrição e do número de anos introduzido. Poder-se-á também programar um Job de periodicidade mensal, ou semanal, com o objectivo de detectar quais os contratos que estão em vias de terminar. 4.3 Leitura e criação de ficheiros XML Para leitura dos ficheiros XML é utilizada a função VB da Microsoft.Net Framework ReadXml() contendo uma cadeia de texto que indica a localização dos ficheiros para leitura. Utiliza-se um DataSet para armazenar os dados contidos nos ficheiros. 41

56 Para escrita dos ficheiros XML é utilizada a classe XmlTextWriter. Esta classe possui os métodos necessários para introduzir qualquer de elemento num ficheiro XML. Em suma para criar um ficheiro XML a partir da classe XMLTextWriter são realizados os seguintes passos: criar um documento incluir elementos incluir sub-elementos incluir atributos fechar o documento. Exemplo para criar o ficheiro Sobremesa visto no ponto 2.2.5: 'cria um objecto objxml Dim objxml As New XmlTextWriter("Sobremesa.xml", Nothing) 'inicia ficheiro xml objxml.writestartdocument() 'escreve o marcador de inicio do elemento raiz writer.writestartelement("sobremesa") 'escreve o atributo objxml.writeattributestring("nome", "Pudim Abade de Priscos") 'escreve os sub-elementos objxml.writeelementstring("gemasovos", "15") objxml.writeelementstring("acucar", "500") objxml.writeelementstring("toucinho", "50") objxml.writeelementstring("agua", "MeioLitro") objxml.writeelementstring("calicevinhoporto", "1") objxml.writeelementstring("cascalimao", "1") objxml.writeelementstring("paucanela", "1") objxml.writeelementstring("caramelo", "200") 'escreve o marcador de fim do elemento raiz objxml.writeendelement() 'desabilitar o objecto objxml.close() 42

57 4.4 VPN (Virtual Private Network) O objectivo da utilização das redes privadas virtuais é permitir a interligação de dois computadores remotos como se estivessem na mesma rede física local, sendo esta comunicação realizada através da internet (redes públicas). Trata-se de uma alternativa segura, garantindo confidencialidade e integridade dos dados nas comunicações através de redes públicas. O estabelecimento de uma VPN entre dois computadores, ou dois sistemas, assemelha-se à criação de um túnel na internet [12]. Ou seja, esse túnel permite a comunicação entre dois pontos, impedindo quem está de fora de ver ou aceder aos dados que estão a ser trocados entre os sistemas nas extremidades do túnel. A segurança no acesso aos dados é garantida através de um sistema de codificação eficaz proporcionado por esta tecnologia, garantindo assim a protecção de dados privados durante a circulação destes através da internet. Uma das grandes vantagens da utilização da internet é a redução substancial de custos de comunicação entre redes fisicamente distantes, mas partilhadas por entidades ou até pela mesma entidade, como por exemplo: a comunicação entre a rede da casa-mãe e as filiais de uma multinacional. A alternativa às VPN seria a ligação entre as redes através de linhas físicas dedicadas, o que acarreta custos substanciais. 43

58 Capítulo V Implementação Neste capítulo serão abordados temas relacionados com a base de dados de bilhética dos TUB, bem como o tratamento dos ficheiros e fluxo de dados consoante as necessidades para a implementação das trocas de informação entre os sistemas CGD-TUB. Também será apresentada a filosofia adoptada para a criação do programa para processamento dos ficheiros recebidos da CGD e das transacções referentes aos cartões bancários CGD efectuados no sistema da bilhética dos TUB. 5.1 Base de dados da bilhética dos TUB A área da bilhética tem estado em constante evolução. As necessidades que esta área apresentava há 10 anos atrás estão completamente ultrapassadas. De facto, nos tempos de hoje com a presença da informatização a uma escala global e temas já abordados anteriormente, a bilhética tornou-se em algo complexo, que utiliza tecnologias muito avançadas. Essa evolução reflecte-se na quantidade de informação que passa a estar armazenada na base de dados. As informações mais importantes a armazenar numa base de dados de um sistema de bilhética são: transacções de títulos de transporte (vendas e validações) passageiros transportados receita monetária das vendas dados de exploração (serviços, linhas, circulações). A base de dados deve estar estruturada de tal forma que os dados anteriormente expostos sejam facilmente acessíveis e relacionados entre si, como por exemplo: consultar o 44

59 número de passageiros transportados em cada linha, ou circulação, durante um período de tempo; o valor da receita das vendas realizadas por um motorista, etc. A estrutura da base de dados dos TUB não será abordada em detalhe neste documento, já que esta é de cariz confidencial. As únicas estruturas de informação dessa base de dados abordadas serão as relativas ao tema da dissertação. Para este projecto foram criadas e adicionadas sete novas tabelas à base de dados da bilhética dos TUB. Os nomes foram escolhidos consoante as características das tabelas e nomenclaturas de nomes já adoptadas na base de dados. De seguida serão descritas as 7 tabelas adicionadas à base de dados. Salienta-se que a nomenclatura e estrutura de dados utilizada para as tabelas são praticamente idênticas às dos ficheiros XML, com excepção da tabela CorrespondenciaPlasticos. CorrespondenciaPlasticos: Nesta tabela são guardados os registos de todos os Plásticos introduzidos no sistema. O Plástico é definido pelo número de referência da CGD e pelo número de série do chip. Este ultimo é um número universal, ou seja, não existe no mundo outro com o mesmo número, já que esta numeração obedece a uma norma que garante essa unicidade. Todos os cartões sem contacto do sistema de bilhética dos TUB são identificados por este número de série do chip. Acontece que o ficheiro de Plásticos enviado pela CGD apenas indica o número de referência CGD, não indica o número de chip. Quando se faz o processamento de um ficheiro de Plásticos vindo da CGD, são inseridos na tabela CorrespondenciaPlasticos registos de novos números de referência CGD que ainda não existam na base de dados, sendo que o campo referente ao número de série do chip fica temporariamente vazio (null). O campo de informação relativo ao número de série do chip será preenchido posteriormente. A associação do número de referência CGD com o número de série do chip será realizada com base na informação da tabela de transacções da base de dados do sistema de bilhética dos TUB. Esta tabela de transacções contém a informação de todas as validações de cartões realizadas nos equipamentos de bilhética dos TUB. Nesta tabela encontram-se registados tanto o número de série do chip, como o número de referência CGD. Aquando do processamento das transacções, o sistema verifica se existem números de série CGD sem o correspondente número de chip. Ao encontrar, preenche depois esse campo 45

60 na tabela, já que como foi dito anteriormente o registo da transacção contempla estes dois números. A chave primária desta tabela é o número de referência da CGD, pois, o número de série do chip só é preenchido posteriormente e, além disso, a CGD garante a unicidade deste campo. Por outro lado, existe a necessidade de relacionar estes dois números já que a chave da tabela de transacções dos TUB é o número de série do chip. Os restantes cartões em circulação no sistema de bilhética dos TUB não possuem a informação do número de referência da CGD. Logo, este campo de informação não poderia ser chave da tabela de transacções do sistema de bilhética dos TUB. HistoricoStatusPlasticos: Guarda toda a informação contida nos ficheiros PLST que foram processados, quer esse processamento tenha sido realizado com sucesso, ou não, já que também se guarda um histórico das situações de erro. Esta informação de histórico serve de base à construção dos ficheiros de retorno obrigatórios no protocolo acordado entre as partes. A chave desta tabela é composta por três campos: o identificador do ficheiro, o nome do ficheiro e o número de referência da CGD. HistoricoRetornoStatusPlasticos: Tabela com informação a partir da qual serão gerados os ficheiros XML contendo os dados de retorno. Transaccoes: Nesta tabela serão guardadas todas as transacções efectuadas com o cartão CGD e servirá de base para a construção do ficheiro XML de transacções. Esta informação será utilizada pela CGD com o objectivo de determinar os valores a debitar na conta do utente e realizar os pagamentos à TUB pelos serviços prestados. Esta tabela irá conter apenas os registos das transacções que estejam em processamento. TransaccoesHst: Esta tabela tem a mesma estrutura da tabela anterior e contem os dados de todas as transacções processadas correctamente e que são movidas a partir da tabela transacções. MovimentosConta: Esta tabela contém a informação do ficheiro Movimentos. 46

61 HistoricoRetornoMovimentos: Esta tabela contém a informação do ficheiro RetornoMovimentos Lista negra de cartões A lista negra de cartões consiste num conjunto de números de série de chip contactless, para os quais se pretende impedir a utilização no sistema de bilhética. A introdução de um cartão em lista negra é um processo realizado, normalmente, devido a situações de furto ou perda do cartão, e ausência de pagamento. No caso de sistema de bilhética dos TUB, essa informação está armazenada numa tabela, a qual regista igualmente os eventos de introdução e retirada de cartões em lista negra. Saliente-se que o sistema de bilhética dos TUB permite retirar da lista negra um cartão que nela tenha sido introduzido. Por exemplo: um cartão foi introduzido na lista negra após um utente ter comunicado a perda, sendo depois retirado quando o utente informou ter encontrado o mesmo. Em termos da gestão dos cartões CGD-TUB, os respectivos números de série de chip contacless terão que ser adicionados, ou retirados, da lista negra também em função do status actual identificado pelo ficheiro Plásticos da CGD. No ponto 5.3 Modelo de validação do Status dos ficheiros Plásticos será explicado quais os estados do cartão que resultam na entrada em lista negra Criação e adição das tabelas Para adicionar à base de dados dos TUB as tabelas envolvidas neste projecto, foi utilizada a aplicação Microsoft SQL Server 2005 Management Studio. Para executar comandos na base de dados, tem que se seguir os seguintes passos: 1 - abrir o Microsoft SQL Server 2005 Management Studio 2 - fazer o login de acesso ao SQL Server 3 - seleccionar a base de dados na qual se quer trabalhar 47

62 4 - escrever o código SQL do comando 5 - pressionar as teclas Ctr+F5 para verificar se existem erros 6 - pressionar a tecla F5 para executar o comando SQL. Na figura 5 apresenta-se como exemplo a criação da tabela HistoricoStatusPlasticos. Figura 5 Criação tabela na base de dados 5.2 Tratamento dos Ficheiros Nesta secção descreve-se o processamento dos ficheiros recebidos da CGD e geração de ficheiros para a CGD, conforme o modelo acordado para troca de dados entre os sistemas TUB e CGD. 48

63 5.2.1 Análise do Ficheiro Plásticos Este ficheiro é enviado pelo sistema CGD para o sistema TUB, com informação relativa a novos plásticos emitidos e alterações de status dos plásticos com chip contactless. A figura 6 representa o fluxo de dados produzido pelo tratamento da informação dos Ficheiro PLST e respectivo preenchimento das respectivas tabelas da base de dados TUB. Figura 6 Tratamento informação ficheiro PLST Após processar correctamente o ficheiro PLST, a informação contida neste ficheiro é inserida na tabela HistoricoSatusPlasticos. Caso haja erro no processamento de algum registo do ficheiro, a informação não é introduzida na tabela. Para cada elemento Plastico são tratadas duas situações: 1- no caso de ser um Plastico novo, então será encaminhado para a tabela CorrespondenciaPlasticos. 2- no caso de ser um Plastico já existente e existir alteração do status para C ou T, então o registo associado será encaminhado para a tabela ListaNegra. 3- no caso de ser um Plastico já existente e existir alteração do status para R, então o registo associado será retirado da tabela ListaNegra. 49

64 Por fim, é criado um ficheiro XML com os retornos dos Plasticos para a CGD e guardado o conteúdo desse ficheiro na tabela HistoricoRetornoStatusPlasticos Análise das Transacções e Ficheiro Transacções As transacções no universo TUB são processadas e, a partir destas, são gerados ficheiros de transacções enviados pelo sistema TUB para o sistema CGD. O diagrama da figura 7 representa todos processos relacionados com a utilização do Cartão CGD-TUB, desde as operações mais básicas ao nível dos utilizadores, até à troca de informação de transacções entre as entidades envolvidas (TUB e CGD). Figura 7 Diagrama funcional de uma Transacção 50

65 Na figura 8 apresenta-se o fluxo de dados associados ao processamento das transacções no sistema de bilhética dos TUB. Figura 8 Tratamento das Transacções Todas as transacções provenientes dos equipamentos de bilhética embarcados são guardadas na base de dados numa tabela denominada BilheteHst, tal como é demonstrado na figura 8, quer sejam de cartões bancários no âmbito deste projecto, quer sejam de cartões emitidos pelos TUB ou outras entidades associadas. Para além disso, são também registadas na mesma tabela, já existente na base de dados dos TUB, as transacções da venda de bilhetes em papel. Uma vez que todas as transacções de títulos serão introduzidas na Tabela BilheteHst, existe um Job SQL que diariamente irá fazer a triagem entre todas as transacções, preenchendo a Tabela Transaccoes somente com transacções efectuadas com o cartão CGD-TUB. Na tabela Transaccoes existe um campo (EmProcessamento) que indica se a transacção já está, ou não, a ser processada em algum ficheiro. O campo EmProcessamento é do tipo binário: toma valor 0 - Falso ou 1 - Verdadeiro. Quando uma transacção proveniente do sistema de bilhética é inserida na tabela Transaccoes, o campo toma, por defeito, o valor 0. As transacções cujo valor do campo EmProcessamento seja 0 irão ser adicionadas ao ficheiro XML TRAN que será enviado para o sistema CGD. Por sua vez, o sistema CGD irá enviar um ficheiro de retorno. Se os registos das transacções contidas no ficheiro de retorno 51

66 apresentarem o elemento CodigoErro=0, significa que essas transacções foram correctamente processadas pelo sistema CGD. Então, o campo EmProcessamento é actualizado com valor 1. Existe um outro JOB SQL que diariamente verifica o estado do campo EmProcessamento. As transacções que tomam o valor 1 são movidas da tabela Transaccoes para a tabela TransaccoesHst. Se o ficheiro de retorno (RetTransaccoes) da CGD contiver registos com CodigoErro diferente de 0, então as transacções correspondentes serão mantidas na tabela Transaccoes e o campo EmProcessamento permanecerá com valor 0 (EmProcessamento=False). Nestes casos, as transacções são verificadas pela manutenção do sistema e corrigidos eventuais erros, permitindo assim gerá-las correctamente noutro ficheiro XML Análise do Ficheiro Movimentos Ficheiro enviado pelo sistema CGD para o sistema TUB, com os créditos efectuados na conta débito à ordem dos TUB. A figura 9 representa o fluxo de dados produzido pelo tratamento da informação dos Ficheiros Movimentos e respectivo preenchimento das tabelas da base de dados TUB correspondentes. 52

67 Figura 9 Tratamento informação ficheiro Movimentos Após efectuar a leitura do ficheiro Movimentos, os dados nele constantes são ser inseridos na Tabela MovimentosConta. Depois é gerado o ficheiro XML RetornoMovimentos, para enviar à CGD, com o retorno da leitura efectuada, e finalmente, é realizado o preenchimento da respectiva tabela (HistoricoRetornoMovimentos). Em termos de relação entre a informação das transacções e a dos movimentos, as entidades TUB e CGD acordaram o seguinte: existe em termos de contabilidade uma conta aberta na qual o montante das transacções é considerado um débito, sendo o montante dos movimentos considerado um crédito. O controlo de débitos e créditos é gerido contabilisticamente, este sistema de informação não prevê nenhum tipo de controlo neste âmbito. Assim ficou acordado entre as duas entidades. 53