Translate

terça-feira, 12 de janeiro de 2021

Formação XFS no YouTube!!

 Para quem sempre pediu, agora tem formação XFS completa no YouTube: https://www.youtube.com/channel/UC-Z-QuAHLXG3q2wwZBcW0hQ

Não esqueçam de se inscrever e ceder um like!!!

segunda-feira, 25 de maio de 2020

Uma visão geral sobre: Configurando o JMX no Zabbix

Olá, nesse artigo deixo para vocês mais um link da série Zabbix, que mostra em poucos passos como configurar o JMX no Zabbix para monitoração de aplicações Java.

Bom vídeo a todos!!


domingo, 17 de maio de 2020

Zabbix: Installation in Development Environment - Basic

Olá, hoje posto um link para um vídeo de YouTube que mostra como montar um ambiente básico para desenvolvimento e testes do Zabbix.

Para quem não sabe, Zabbix é uma plataforma Open-Source para monitoração de qualquer tipo de dispositivos, incluindo ATM e Kiosk. 

Aproveitem o vídeo e até mais!!




sábado, 21 de maio de 2016

Protótipo de Placa de Sensores e LEDs: Hardware e Firmware

Olá leitores. Hoje trago um projeto simples de placa de sensores e leds, baseado na plataforma Arduino. O bacana desse projeto é que ele pode servir de base para exercitar vários dos conceitos que utilizamos na automação bancária. Por exemplo, podemos criar um device driver para controlar essa placa, e depois podemos criar um service provider implementando a classe SIU do XFS.

Antes de falar sobre o projeto, vou falar um pouco sobre a plataforma Arduíno. Aqueles que gostam de eletrônica certamente já ouviram falar de Arduíno. Trata-se de uma plataforma para prototipagem de projetos de eletrônica, muito utilizado também por entusiastas do "faça você mesmo". O Arduíno é open source e é fácil. Existe uma infinidade de versões de placa Arduíno, originais e compatível, que variam basicamente em relação a quantidade de entradas e saída que a placa pode controlar. Também existe uma infinidade de módulo de hardware, como sensores, motores DC e outros tipos de atuadores, que você acopla a sua placa Arduíno facilmente. Na parte da programação, existem muitas bibliotecas prontas que você pode reutilizar, e que vão auxiliá-lo na codificação do seu firmware, usando o compilador do Arduíno que é simples e bem intuitivo. Talvez a versão de placa Arduíno mais comum seja a Arduíno Unon da imagem a seguir. Essa é, inclusive, a versão de placa utilizada no nosso projeto.



Existem placas Arduíno originais (como essas da imagem) e existem também aquelas que são compatíveis. Como se trata de um projeto open source, qualquer pessoa um pouco mais hábil em eletrônica pode criar a sua própria "construção" de placa Arduíno. Assim, existem na Internet uma infinidade de placas compatíveis. Pode haver algumas variações de qualidade dos materiais e até mesmo em formato dos conectores, mas as placas compatíveis tem basicamente as mesmas capacidades da placa Arduíno original. Geralmente elas são mais baratas, então a escolha vai de cada um. Eu, por exemplo, preferi comprar a versão original até como uma forma de incentivo ao projeto Arduíno. Dai que minha placa é original e enviada direto da Itália.

Pois bem, abaixo exibo o esquema da placa de sensores e leds, mas antes de prosseguirmos fica um alerta: sou apenas um simples entusiasta de eletrônica, não um engenheiro eletrônico. Então, me perdoem por eventuais faltas de otimazação nesse circuito. O conceito desse esquema é servir a um Terminal de Consulta (kiosk), dotado de uma porta (para acesso ao micro, impressora e demais dispositivos), uma leitora de cartões, uma impressora térmica, sinalização luminosa e sonora, sensoriamento de luz, temperatura e nível.



A esquerda do esquema vemos a placa Arduino Uno. O projeto poderia ser feito com outras placas Arduino, inclusive com as versões menores como a Arduino Nano. Eu escolhi a Arduino Uno porque é esse o modelo que tenho em casa. Os demais componentes do projeto são:
  1. Leds: o objetivo desses leds é a sinalização para o usuário. Nesse projeto, eu considero que um desses leds é para indicar a inserção de cartão na leitora e o outro para indicar a saída de papel na impressora térmica;
  2. Buzzer: sinalização sonora para o usuário. Por exemplo: podemos soar um alarme caso a porta do cofre seja aberta sem a devida autenticação no sistema, ou podemos simplesmente chamar a atenção do usuário para uma ação requerida da parte dele. Podemos variar a intensidade do som que é emito pelo Buzzer, logo esse componente trabalha com valores contínuos, em uma escala que sai de 31 e vai até 65535, para a placa Arduino Uno;
  3. Button Switch: o papel desse componente é indicar porta do cofre ou gabinete aberto ou fechado. Esse componente portanto, só pode assumir dois valores: aberto ou fechado;
  4. Resistores: o papel desses componentes no circuito é evitar que os leds se queimem ou que haja curto circuito na placa, no caso do resitor ligado ao Button Switch;
  5. Potenciômetro: permite configurar a sensibilidade do sensor de temperatura. Em outras palavras, indica a partir de qual temperatura o sensor deve alarmar;
  6.  Sensor de Temperatura: indica a temperatura ao redor de um ponto. Esse sensor poderia estar espalhado pelo o equipamento em série, para indicar, por exemplo, tentativas de arrombamento com maçarico; Esse sensor pode ser configurado com um resistor ou potenciômetro, para alarmar somente quando a temperatura atingir um certo limite. Portanto, os valores fornecidos por esse sensor partem de um valor mínimo e vão até o limite máximo, que depende das características físicas do sensor. Normalmente consultamos o datasheet do modelo/fabricante do componente para obter esse tipo de informação;
  7. Sensor de Nível: indica se houve uma inclinação. Portanto, esse sensor fornece os valores: nivelado ou inclinado; 
  8. Sensor de Luz: indica a incidência de luz em um ponto. Esse também é um sensor que fornece valores de mínimo e máximo de acordo com o limite fisico do sensor, definido pelo modelo/fabricante;
  9. LCD: esse é um componente acessório no circuito. Eu o inclui apenas para mostrar os dados de entrada e saída da porta serial. Ou seja, o uso desse componente é complemente opcional;

Eu mantenho esse projeto no site AUTODESK 123D CIRCUITS. Esse site permite criar e simular circuitos Arduino, incluindo a parte do firmware. O link para o projeto da placa é esse: Sensor and LED's Board. É uma plataforma colaborativa também. Então, se quiserem fazer modificações, fiquem à vontade.

Segue abaixo um trecho do código fonte para controlar o firmware dessa placa. Trata-se de um código em C\C++ padrão Arduíno, e de fácil leitura. Quando falo firmware, me refiro ao software embarcado no microcontrolador da placa Arduino. É ele que permite controlar as entradas e saídas da placa de acordo com as necessidades do projeto. Cada pino de entrada ou saída recebe uma identificação no código. Dependendo do tipo de pino, você pode usar comandos de leitura ou aplicar uma tensão (ligar) algum componente conectado ao pino. O Arduino inclusive oferece algumas bibliotecas prontas para você fazer isso de forma mais facilitada e de acordo com o componente que estiver conectado nos pinos. LiquidCrystal.h é um exemplo de biblioteca Arduino para controle de LCD. Um firmware Arduíno tem basicamente a seguinte estrutura, conforme exemplo abaixo:



As funções setup() e loop() são obrigatórias. A função setup() é executada durante o carregamento do firmware e ocorre somente uma vez para cada carregamento, seja quando a placa é ligada ou quando é resetada. É um bom local para inicialização de variáveis e configurações em geral, já que será executado apenas uma vez. No exemplo acima, eu estou configurando os pinos que estarei utilizando, indicando quais serão pinos de entrada e quais serão de saída. Configuro também a velocidade da comunicação Serial e o tamanho do LCD que está acoplado a placa Arduíno; A função loop() será executada eternamente em laço, ou seja, assim que ela terminar sua execução, o microntrolador a executará novamente desde o início. Portanto, é nessa função que a inteligência do firmware deverá ser programada. No exemplo acima, eu verifico se há dados disponiveis na porta serial e os leio. Depois disso utilizo sub-funções (não exibidas ai nesse exemplo), para processar o dado recebido na porta Serial. Por fim, eu escrevo no LCD todas essas informações e finalizo o loop processando tarefas que estiverem pendentes. O firmware desse projeto foi programado para responder a seguinte lista de comandos:


Basicamente temos:
  • Comando "S": comando de leitura do status dos sensores. A resposta é uma String no formato "Sddddd", onde 'd' pode ser 0 ou 1, de acordo com o estado do sensor. Para os sensores de valores contínuos como o sensor de temperatura e luz, foi configurado um valor limite para considerar quando a resposta deve variar entre 0 e 1;
  • Comando "LCd": comando para ligar/desligar LED da leitora de cartão. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar piscante;
  • Comando "LPd": comando para ligar/desligar LED da impressora térmica. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar piscante;
  • Comando "Ad": comando para ligar/desligar BUZZER. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar alarme;


Acessando o projeto "Sensor and Led's Board" você consegue visualizar o código completo do firmware. Você consegue também executar e simular esse projeto, para exercitar esses comandos e o comportamento dos sensores e atuadores previstos no projeto. Basta cliclar em "Start Simulation", para que o circuito seja "ligado":


Clicando em "Code Editor" você tem acesso ao código fonte e também ao "Serial Monitor":


Por meio do "Serial Monitor" você pode simular o envio de dados na porta serial da placa. Basta digitar um texto e clicar em "Send". Com isso, você envia as Strings dos comandos mencionados anteriormente para ver o circuito ganhar vida. Exemplo: envie "S" para obter os status dos sensores. Envie "A2" para ouvir o BUZZER alarmar, e "LC1" ou "LP1" para ligar um dos LEDs. Se você tiver esses componentes em casa e uma placa Arduino, você pode também baixar o código fonte do firmware nesse mesmo link e instalá-lo no seu Arduino e dai fazer o teste no teu próprio hardware.

Com esses comandos básicos essa placa permite criar, por exemplo, um Service Provider XFS, que poderia ser facilmente integrado em uma aplicação FrontEnd para um Terminal de Consulta (kiosk). Para isso, basta primeiro criar um Device Driver para controlar essa placa. Ou seja, uma interface de comandos de alto nível que possam ser mais facilmente integradas em outro software. Poderiamos ter nesse Device Driver apenas duas funções públicas:

  • String readSensor();
  • void setIndicator(int indicatorID, int indicatorValue)

Com um device driver pronto, basta escrever um Service Provider XFS da classe SIU (Sensors and Indicator Unit Device), cuja especificação está contida no documento CWA 10 de cada versão da especificação XFS. Essa especificação pode ser baixada aqui, na sua versão mais recente: CWA 16926-10.

É isso. Espero que aproveitem esse projeto e façam suas próprias experiências.

Até mais!!!

quinta-feira, 26 de março de 2015

Fraudaram meu cartão de crédito

Olá leitores. No inicio de Fevereiro tive meu cartão de crédito (com chip) fraudado pela primeira vez na vida. Curiosamente, amigos meus reclamaram recentemente de terem seus cartões fraudados. Então, o objetivo desse post é tentar analisar como a fraude aconteceu. Antes de prosseguirmos, gostaria de frizar que eu não tenho experiência em sistemas TEF, portanto, talvez uma ou outra informação aqui não seja lá muito acertiva (fique a vontade para postar uma correção nos comentários).

A fraude ocorreu em um Sábado de poucas compras. Por isso, eu sei exatamente em qual loja a fraude ocorreu. O que importa saber dessa loja, é que tipo de sistema ela possui como meio de pagamentos. Nesse caso, a loja utilizava um sistema PDV (não sei o fabricante) com uma máquina para TEF, ou seja, um ETFPOS. Essa é uma configuração típica de lojas de médio porte, onde a manuntenção de estoque é importante. Pois bem, o processo de pagamento ocorreu como habitual, entreguei o cartão, a balconista introduziu o cartão na leitora e eu digitei a senha. Em nenhum momento o cartão saiu do alcançe de minha visão.

Na Segunda-feira seguinte a essa compra, recebi um telefonema do meu banco perguntando se eu havia feito uma compra de passagem aérea no Sábado e outra momentos antes da ligação. Eu disse que não e a operadora informou que meu cartão havia sido fraudado e que, portanto, ela queria permissão para cancelar o cartão. Permissão concedida de imediato e perguntei: as compras realizadas foram efetivadas, ou só ficaram na tentativa? Ela respondeu que nenhuma compra havia sido efetiva. De fato, mais tarde consultei o extrato online do meu cartão de crédito e nenhum lançamento anormal foi notado.

Pois bem, com essa descrição já é possivel supor o que ocorreu:

O fraudador não foi bem sucedido na captura de todos dados do meu cartão. Ele conseguiu apenas parte do conjunto de dados que seriam necessários para realizar uma transação fraudulenta mais tarde. Digo isso porque, provavelmente, as compras de passagem aérea que ele tentou realizar ocorreram em uma loja on-line e, como se sabe, para uma transação como essa são necessários diversos dados do cartão como: número do cartão, nome impresso no cartão, e data de validade do cartão, além do CVV. Algumas lojas inclusive exigem o endereço da fatura do cartão e o CPF (nem todas pedem essa parte). Desses dados, somente o número do cartão é armazenado eletronicamento no cartão. Normalmente, mas nem sempre, o número impresso no cartão coincide com o PAN que compõe os dados da Trilha 2 do cartão. Tentar realizar uma compra on-line sem qualquer uma dessas informações, tipicamente resultará em uma transação mal sucedida, e foi o que ocorreu. No entanto, o que me tirou alguns momentos de tranquilidade foi não entender como o fraudador conseguiu os dados eletronicos do meu cartão. Como ele conseguiu obter o PAN do meu cartão?

Suponho que ele tenha fraudado o sistema PDV do estabelecimento, colocando um programa espião no computador onde está instalado a aplicação PDV. Após a seleção da aplicação CREDITO do chip, a aplicação executa a leitura de uma série de dados do cartão, para compor os dados necessários para envio de uma transação EMV de autorização da compra junto a operadora do cartão. O envio dessas informações é encapsulado em uma mensagem, tipicamente no formato ISO 8583. O canal de comunicação entre o computador do PDV e o servidor da solução (ainda antes de chegar nos servidores da processadora de cartões) é, tipicamente, criptografado usando SSL ou uma VPN. Então, o que deve ter ocorrido é que o fraudador capturou os dados que compõe essa mensagem, antes dela ter sido enviada e diretamente no computador.

Por sorte, acredito que a balconista do estabelecimento não estava envolvida na tramóia. Se estivesse, então a fraude poderia ter sido completada com êxito. Afinal, passei a ela meu CPF (nota fiscal paulista), e ela já tinha meu nome completo e endereço (entrega da mercadoria comprada). Só faltariam CVV e validade do cartão, que podem ser facilmente memorizado em apenas uma ou duas olhadas no cartão. Normalmente entregamos o cartão à pessoa do outro lado do balcão e isso facilita essa captura de informações. Com a prática atual da nota fiscal paulista, que a maioria utiliza para praticamente todo o tipo de compra, a inserção do CPF é o caminho para obter o nome do possivel titular do cartão, uma vez que o própria receita federal oferece serviço de consulta pública a essa informação a partir do CPF. Assim, os demais dados do cartão (CVV e data de validade) e o teu endereço de cobrança são as únicas informações que podem evitar uma fraude, caso você tenha a infelicidade de ter seu cartão de crédito inserido em um sistema comprometido.

Você tem outra explicação para essa fraude? Poste abaixo os seus comentários...

Até mais!!!


quinta-feira, 5 de fevereiro de 2015

Retrospectiva 2014

Olá senhores leitores. Após um longo período de ausência por conta do desafio - superado - de um mestrado, eu estou de volta e espero poder publicar artigos com mais frequência a partir de agora.

Nesse primeiro artigo de retorno vamos abordar rapidamente os principais acontecimentos de 2014.

Ano passado (2014) foi um ano cheio de acontecimentos ruins para a área de automação bancária e autoatendimento. Demissões, problemas de fraude, aquisições, todas essas coisas juntas colocaram bastante pressão no profissional dessa área e, são fatos que devem desencadear um 2015 mais nervoso. Mas tivemos coisas boas também!! Acompanhem:

Demissões e outras mudanças no setor
Esse ultimo ano foi um ano cheio de rumores de demissões, algumas confirmadas e outras abafadas (não se encontra nada que confirme). Empresas importantes do setor demitiram em massa. Por exemplo, a Perto Periféricos para Automação demitiu uma enorme quantidade de funcionários, em praticamente todas as suas filiais no Brasil. O plano de demissões, ao que parece, atingiu todos os setores, pois foram para a rua desde técnicos de campo, passando por pessoas da área administrativa e chegando inclusive aos engenheiros e projetistas de software. A boa notícia é que uma boa leva desse contingente foi absorvida pelas demais empresas do setor. Tradicionalmente a Tecban é a empresa que mais contrata ex-funcionários Perto, mas é certo que outras empresas do setor também absorveu parte dessa mão de obra. Não se sabe (entenda-se: eu não sei), porque essas demissões ocorreram. Como um ex-funcionário da Perto, o que eu posso dizer é que ela é uma empresa que, até 10 anos atrás, tinha uma estrutura familiar, onde imperava a meritocracia. Com isso, as pessoas tinham acesso a promoções, desde que desempenhassem bem o seu papel. No entanto, depois de muitos anos na empresa, e parado em um mesmo cargo, o profissional começa a se tornar mais caro do que as opções no mercado, e dai a empresa realizava "ajustes", que resultavam em demissões. Normalmente a ordem era pegar em cada setor os colaboradores com maior salário, e simplesmente cortar os dois que estivessem encabeçando a lista. Isso ocorreu várias vezes nos quase 10 anos em que estive por lá, e pode ter sido isso o motivador dessa onda em 2014. Fato é que, todos os meus antigos colegas de trabalho foram embora nessa ultima leva :(

Outra empresa que demitiu forte ano passo foi a Scopus Serviços. O motivo ficou claro mais tarde: a Scopus Serviço foi vendida para a IBM. Essa é uma mudança importante no cenário nacional, pois marca o retorno de uma das grandes potências do mercado de automação bancária. A IBM já foi um grande player nesse mercado, mas nos últimos anos esteve concentrada em negócios de menor envergadura no setor. Com essa aquisição, ela volta a ter importância no setor, principalmente porque a Scopus Serviços era responsável pela manutenção do enorme parque de ATM (quase 35 mil) do Bradesco. Vale lembrar que a IBM vem correndo por fora no setor já há alguns anos, ou seja, ela nunca deixou de atuar nesse setor. Na parte de cooperativas bancárias, a presença dela é forte, principalmente no fornecimento de soluções de back-end. No grandes bancos, naturalmente, todos os que usam soluções baseadas em Mainframe, são clientes da IBM. No entanto, a importância dessa aquisição é que ela está aumentando a importância de seus negócios na outra ponta: ATM, embora mais concentrada em serviços (que é o negócio mais rentável).

No que se refere a aquisições, como se sabe, em 2013 a OKI Eletronic havia adquirido a maior parte da Itautec. Mas foi no ano passado, porém, que surgiu a nova empresa: OKI Brasil. Isso aqui foi uma boa notícia no setor, pois a OKI Brasil já nasce assim: grande. Trata-se de uma empresa que consegue oferecer soluções em praticamente todos os domínios da automação bancária e autoatendimento. Embora muito mais forte na automação comercial, parece que OKI Brasil trabalhou bem sua linha de produtos para conseguir sinergia entre as áreas (muitas empresa não conseguem fazer isso), e com isso aumentou fortemente sua oferta de produtos e serviços. Uma visita ao seu website deixa claro que eles vieram para comandar. Acabaram de completar 1 ano de vida, e nesse primeiro ano teve todo aquele trabalho de integração do seus mais de 4 mil funcionários e etc, mas agora 2015 pode ser o ano em que eles virão para cima dos demais players do mercado, aumentando a concorrência - o que é ótimo para nós, profissionais da área. Um desafio da OKI Brasil, que talvez não se imagine a princípio é: se manter como principal fornecedor do Itaú. Isso mesmo, a Itautec, naturalmente, era o principal fornecedor do Itaú e não só de ATM. Então, a OKI Brasil está ai, mas isso não quer dizer que eles irão assumir a posição de preferência da extinta empresa (não faria sentido para mim). Acho que o Itaú agora deve estar abrindo concorrência para empresas como a Diebold, quando o assunto é fornecimento de ATM e talvez esteja abrindo o mesmo tipo de concorrência para Unissys quando o assunto é o fornecimento de PC e estações de trabalho. Enfim, a OKI Brasil tem bastante trabalho para 2015, mas sem dúvida o projeto é vencedor, os Japoneses vieram para ficar.


Fraudes no autoatendimento
Esse é um assunto delicado pois, como profissional do setor, eu não posso falar o nome das entidades bancárias que foram acometidas por fraude. Mas posso sim falar do tipo de fraude que mais ocorreu em 2014 e de seus estragos. Realmente não temos muita novidade em termos de novas técnicas, os fraudadores exploraram falhas já bem conhecidas que não deveriam existir mais nos ATM e sistemas de autoatendimento. Isso reflete o maior defeito do ser humano: ele relaxa e esquece. Muitas das fraudes do ano passado foram baseadas em técnicas simples e já bem difundidas de ataque, tanto aqui no Brasil quanto em outros locais do mundo. Por exemplo: boot de um sistema operacional diferente a partir de um Pendrive; Acesso administrativo ao próprio sistema operacional do ATM e etc. Todas essas fraudes poderiam ser evitadas com soluções já bastante conhecidas: criptografia do HD associada a criptografia local do Dispensador de Cédulas, acesso restrito ao BIOS do PC e impossibilidade de boot a partir de USB. A parte relativa a criptografia do dispensador já é padrão atualmente. Todos os fabricante já entregam o seus dispensadores de cédulas com a opção de ativação do modo criptográfico. Já a criptografia do HD, no entanto, encontra resistência pois envolve investimentos relativamente altos: aquisição de um produto e visitação aos ATMs do parque para atualização tecnológica (talvez haja opções a isso). Quando o assunto é segurança, infelizmente, só há investimento depois que o ladrão mostra a cara. Então, os bancos afetados ano passado, todos eles, iniciaram projetos de atualização tecnológica voltada para segurança, incluindo sistemas de criptografia do HD. Tarde, já que estima-se no setor que algo em torno de 30 milhões de reais tenha sido roubado dos ATM, só em 2014, somando todas as fraudes e todos os bancos afetados. Seguramente esse número está subestimado, já que os bancos não revelam esses valores (vamos conhecendo nas conversas de corredor e etc). Ocorre que as fraudes, embora utilizem técnicas conhecidas e relativamente simples, têm sido cada vez melhor organizadas, envolvendo centenas de pessoas em várias localidades diferente em todo o território nacional e ao mesmo tempo! O desafio realmente, é se manter alerta, não relaxar, não achar que suas medidas são suficientes. Já se sabe há muito tempo que os fraudadores possuem em seus quadros: engenheiros, técnicos, projetistas, advogados e toda sorte de pessoas altamente capacitadas. Ou seja, hora ou outra, encontrarão outra brecha para atacar.

O que esperar para 2015?
Francamente, eu estou preocupado, há rumores negativos no setor, embora os principais bancos tenham registrado um aumento em seus lucros no último ano: Bradesco, Itaú-Unibanco, Santander. As empresas fabricantes, no entanto, não registram esses lucros gigantes e, como se viu em 2014, vem reduzindo seus quadros. Isso normalmente ocorre por dois motivos: perspectivas de problemas na economia e preparação para fusões. Estamos vivendo exatamente o primeiro cenário, há um clima crescente de incertezas na economia do Brasil, e isso é ruim para todos nós, profissionais do setor, pois se a economia vai mal, a indústria segura os investimentos, isso congela salários, isso segura novas contratações e, eventualmente, resulta em demissões. Enfim, o que podemos fazer é torcer para que passemos por esse período difícil mais ou menos sem sobressaltos em nossas carreiras.

É isso senhores, feliz 2015 para todos nós!!!

terça-feira, 3 de dezembro de 2013

Autoatendimento para o canal ATM: Overview sobre o Front-End

        Olá senhores leitores. Após um longo período de ausência, estou de volta com mais um artigo interessante sobre autoatendimento em terminais do tipo ATM. Vou falar um pouco sobre a arquitetura das soluções de autoatendimento, e com isso quero apresentar aos leitores, o que está envolvido nesse tipo de aplicação, quais são os principais elementos arquitetônicos da solução como um todo, e também localmente, quando se ajusta a lente para olhar mais próximo a composição da aplicação que controla os terminais. O objetivo deste artigo, como sempre, é mostrar para o jovem uma visão mais geral a cerca dessa indústria, e o que ela pode oferecer de desafios e recompensas. Agora vamos ao que interessa!

Uma solução completa de autoatendimento envolve dezenas de software dispostos em três pontos da arquitetura da solução: Front-End, Middleware e Back-End. Esses termos são utilizados largamente na engenharia de software para designar o propósito do software em questão, e na arquitetura de uma solução de autoatendimento, Front-End designa o software cujo propósito é oferecer algum tipo de interface (não necessariamente gráfica) para algum tipo de usuário (cliente, operador, gestor e etc). Por meio dessa interface, são oferecidos serviços que serão processados no Back-End. Esse termo designa, portanto, o software que executa normalmente em ambientes de servidores (pequenos, médios ou grande porte), mas que têm funções relativas ao processamento e efetivação das transações que compõem cada um daqueles serviços. Em uma solução de autoatendimento, essas são transações bancárias, típicas de produtos como depósito e conta corrente, os quais são exemplos de produtos bancários encontrados em sistemas que compõem o Back-End. Já o termo Middleware, normalmente está associado a qualquer tipo de serviço localizado entre as duas outras camadas citadas. A monitoração remota do terminal ATM, o serviço de parametrização desse terminal e também o serviço de atualização remota, normalmente estão localizados nessa camada.

Considerando a indústria das instituições bancárias, e sua estrutura de TI, fisicamente, o Back-End é representado, em muitos casos, por um computador de grande porte denominado Mainframe. Esse computador hospeda a maioria do software e demais elementos que compõem o Back-End na arquitetura. Esse software é responsável, por exemplo, por autorizar boa parte das transações, além de conter os principais programas responsáveis pelos produtos mais básicos de uma instituição financeira, como a conta-corrente e etc. O conjunto mais básico desses produtos bancários é designado como Core Banking, e todas as instituições bancárias possui uma solução dessa natureza, seja feita dentro da própria instituição, seja adquirida pronta no mercado. Não importa quantos canais de atendimento essas instituições possuam, por exemplo, ATM, atendimento telefônico, internet banking e etc. Todos eles terão, em algum ponto, que se submeter ao Mainframe, usando uma ou mais transações servidas por ele, acessando portanto, componentes do Back-End.

O Middleware é ponto da arquitetura onde normalmente se localizam sistemas de gestão dos canais. O gestor de cada produto da instituição, normalmente irá precisar de relatórios estáticos, e também configurar parâmetros de operação das transações. Bom, é aqui que começa a confusão. Veja, qualquer instituição tem diversos canais de atendimento como citei anteriormente. Imagine se essa instituição tiver que desenvolver no Back-End uma transação de saldo para Internet Banking, outra versão da transação de saldo para o canal ATM, e por fim, um para o canal de atendimento telefônico. Isso seria um caos, certo? Seria não, é! O fato é que muitos bancos encontram-se exatamente nessa situação, pois sua solução de autoatendimento não foi projetada para operar diversos canais ao mesmo tempo. É até fácil de entender, alguns canais só foram considerados bem recentemente, com o advento de alguma nova tecnologia. Por exemplo, smartphone é uma realidade agora, todo mundo tem um, mas não era assim há cinco anos. Revisar toda a arquitetura sai caro e, principalmente, pode resultar em muitos problemas para os clientes até estabilizar. Por isso, ocorre que muitas instituições acabam por manter estruturas com essas fragilidades arquitetônicas. Outras instituições que tiveram a chance de revisar sua arquitetura procuraram concentrar no middleware soluções de convergência entre os diversos canais. Componentes localizados no middleware intermediam as transações entre os diversos canais e o Mainframe. Assim, uma única versão, e um único formato de transação ficam disponíveis no Host, e o Middleware é o responsável por tornar essa transação acessível aos diversos canais, no formato que eles esperam. Isso é conhecido como solução multicanal.

O Front-End é a nossa praia. Esse ponto da arquitetura é onde se encontra a interface com o cliente em cada um dos canais. Assim, no canal ATM o Front-End é a aplicação de autoatendimento no terminal ATM, incluindo todas as demais aplicações utilitárias e de serviço que compõe os componentes desse ponto da arquitetura. Em um canal de atendimento telefônico, seria o sistema baseado em URA. Óbvio que o Front-End de cada um dos canais de atendimento tem suas complexidades, e eu vou detalhar aqui um pouquinho da complexidade envolvida no canal ATM. A aplicação de autoatendimento para o canal ATM é um dos principais componentes do Front-End na arquitetura de qualquer solução de autoatendimento quando falamos de automação bancária. A complexidade envolvida nessa aplicação pode ser observada na imagem a seguir. 


A primeira questão que se tem que observar é que a aplicação precisará controlar os periféricos do terminal de autoatendimento. O ATM na imagem pode ser um terminal caixa eletrônico ou um terminal eletrônico do tipo kiosk. Eles são normalmente encontrados em bancos, shopping centers, aeroportos ou até mesmo em lojas de conveniência. O conjunto de periféricos encontrados nesses terminais depende do modelo do terminal. Por exemplo, um ATM do tipo Full Fuction, normalmente possui módulo depositário, dispensador de cédulas, leitora de cartões, impressora térmica, placa de leds e sensores, painel do operador e pinpad. Já um terminal do tipo kiosk é encontrado normalmente na seguinte configuração: impressora térmica, pinpad e leitora de cartões. Claro que com o advento de novas tecnologias de hardware, diversos novos periféricos vem sendo adicionados a esses terminais: leitoras de smartcard, leitores biométricos, câmeras videofotográficas (normalmente uma WebCam) e etc. Veja que a configuração do terminal determina o escopo de atuação da aplicação. Para cada um dos periféricos contidos nessa configuração, será necessário um software controlador. Esse software é denominado como Device Driver. Na automação bancária é mais comum encontrar esses drivers escritos em C/C++, e operando em User Mode. No entanto, há uma separação de responsabilidade aqui. O Device Driver tem que conhecer detalhes relativos à comunicação serial ou paralela, e ainda conhecer o protocolo de operação do dispositivo. Esse tipo de preocupação está muito longe do negócio, que é oferecer serviços bancários. E, além disso, por questões de segurança, o protocolo de operação de dispositivos como o dispensador de cédulas é mantido sob segredo por muitos fornecedores. Por isso, normalmente essa camada de software é responsabilidade do fabricante do ATM.

Como cada dispositivo possui uma infinidade de opções de modelos e fornecedores, uma forma de separar essa complexidade da aplicação é por meio de uma camada middleware. Para o autoatendimento em terminais ATM, especialmente para bancos, é muito comum o uso de Service Providers CEN/XFS e Device Services J/XFS, nessa camada middleware. Eu falei um pouco sobre essa camada no artigo Guia para Automação Bancária para iniciantes. Eu também abordei, superficialmente, sobre o desenvolvimento de Service Providers no artigo Desenvolvendo Drivers XFS – Overview. O objetivo dessa camada de software é tentar livrar a aplicação da complexidade que há nessa diversidade que eu citei no paragrafo anterior. CEN/XFS e J/XFS são padrões largamente usados na indústria da automação bancária, e seu objetivo primário é abstrair essa complexidade (embora nem sempre haja sucesso). No entanto, muitas instituições bancárias aqui no Brasil não usam esses padrões. Instituições como o Banco do Brasil, Santander e outros, preferiram projetar sua própria camada Middleware. Nesse caso, essas instituições definem uma especificação, e repassam-na para qualquer fornecedor de ATM que pretenda vender seus equipamentos para ela. Também é comum encontrar instituições que usam um padrão aberto como o CEN/XFS e o J/XFS, e o alteram de acordo com suas necessidades, criando assim extensões para esses padrões. É o caso de instituições como o Itaú, Tecban e outros. Como eu já falei bastante sobre essa camada em artigos anteriores, para este artigo eu vou me concentrar na camada seguinte que é onde se localiza a aplicação.

A aplicação de autoatendimento para terminais ATM ou kiosk pode ser baseada em diversas tecnologias, e projetada com base em diversas estratégias arquitetônicas. Três dessas estratégias são bastante comuns: Fat Client, Thin Client e Hibrido. A estratégia Fat Client é a mais comum e está presente na grande maioria das soluções de autoatendimento das instituições bancárias no Brasil. Nessa estratégia, o software de autoatendimento está hospedado inteiramente no terminal de autoatendimento, fazendo forte uso dos recursos de armazenamento e processamento do terminal. Ou seja, uma solução Fat Client exige mais do hardware (a unidade de microprocessamento – computador) do terminal. Essa estratégia é a mais comum, pois as instituições sempre investiram pesado em seus terminais ATM. A maioria dessas instituições compram, todos os anos, novos ATMs para substituir parte de seu parque, já obsoleto. Ou seja, há um investimento contínuo em hardware, e por isso mesmo, as instituições em geral, preferem preservar esse investimento, e optam por soluções Fat Client. Já a estratégia Thin Client exige mais hardware em servidores e não nos terminais. Esse tipo de solução, na maioria das vezes, é projetado com base em alguma tecnologia Web, com fluxos transacionais, telas e imagens e a maioria dos recursos utilizadas na aplicação ficam hospedados em um servidor na rede. Assim, não há necessidade de muito poder de processamento e armazenamento nos terminais. Esse tipo de estratégia é bastante comum para o autoatendimento de domínios como o de venda de ingressos para cinema e shows, usando os terminais do tipo kiosk. Nesse caso, as unidades de processamento dos terminais normalmente contam com um mini computador (Ex. Raspberry Pi), com baixa capacidade de processamento e armazenamento de dados. Já a solução hibrida procura usar as duas estratégias. Normalmente aqueles serviços mais importantes (Ex.: saque, saldo e deposito e etc) da instituição tem seus recursos mantidos no terminal, e os serviços usados com menos frequência (Ex.: serviço de recarga de celular, publicidade e etc), ou com menos importância para o negócio, ou ainda que sofram alterações com mais frequência, tem seus recursos mantidos no servidor. A estratégia a ser escolhida realmente depende do tipo de negócio, dos recursos de hardware que o cliente já dispõe, e também de questões organizacionais.


Não importa qual a arquitetura da aplicação de autoatendimento. Seja ela qual for o software resultante terá, basicamente, os mesmos módulos mostrados na figura a seguir. Essa é a visão em camadas de uma aplicação de autoatendimento conceitual. São mostrados os componentes típicos de um sistema de autoatendimento para ATM, e como eles se relacionam entre si e sistemas externos encontrados nesses ambientes. Esse tipo de sistema têm, em geral, três tipos de usuários: Cliente, Operador e Gestor. A seguir faço uma descrição básica de cada um desses componentes.


Interface do Cliente é o componente responsável pela camada de apresentação do software para o cliente. Tipicamente, essa camada é construída com base em Java Swing ou seus equivalentes no caso de outras linguagens. No entanto, é comum também encontrar essa camada em construções Flash e HTML5 e, por vezes, uma combinação de todas elas. A tendência atual no meio do autoatendimento é utilizar interfaces cada vez mais interativas, semelhantes àquelas encontradas nos celulares smartphones. Essa tendência têm sido possível em razão da utilização de telas sensíveis ao toque, que simulam o mouse. Assim, o cliente não utiliza mais as teclas laterais para operar a aplicação. Ele toca diretamente em componentes gráficos na tela do terminal, aumentando a interação, e melhorando a experiência do usuário cliente com a aplicação de autoatendimento. Em edições recentes da CIAB, outras tecnologias foram apresentadas, ainda em forma de conceito, para melhorar ainda mais essa experiência do cliente. Uma dessas tecnologias utiliza sensores do tipo kinect que leem os movimentos do cliente, e permitem que a aplicação seja controlada sem a necessidade de tocar na tela do terminal.

Serviços para Cliente é o componente responsável por derivar todos os serviços que estarão disponíveis para o usuário cliente do software. São serviços típicos, o Saque e Depósito em dinheiro ou cheque, bem como extrato de movimentação bancária, transferências de recursos, pagamento de contas entre outros. Para falar de tendências, eu não poderia deixar de citar os movimentos convergentes que têm ocorrido na indústria do autoatendimento bancário. Por meio da convergência entre canais, um novo conjunto de serviços tem sido colocado à disposição do cliente. Os clientes podem iniciar transações de saque no canal Internet Banking e concluí-las nos terminais ATM. Em outras soluções o cliente também pode configurar uma operação de saque no smartphone e transferir esses dados via NFC para o terminal, que dispensará o dinheiro em seguida.

Publicidade é o modulo responsável por receber campanhas e vincular propagandas junto à interface do cliente. Essas campanhas, em geral, são construídas e parametrizadas em sistemas especialistas para os quais esse componente pode ter interface. Aqui a tendência é a utilização de sistemas especialistas cada vez mais inteligentes, que fazem recomendações cada vez mais assertivas para o cliente. O objetivo final de qualquer propaganda, é a venda de um produto. Os sistemas de publicidade são alimentados por informações oriundas de diversos canais da instituição, e quanto mais informação ele puder reunir a respeito do cliente, melhores podem ser suas recomendações e, portanto, as chances de realização de uma venda. Por outro lado, tenho visto soluções de autoatendimento que simplesmente negligenciam esse aspecto do negócio. Já vi aplicação recomendando empréstimo para cliente cujo saldo bancário mostra que ele não precisa disso, e também aplicações mostrando simples mensagem de aguarde, quando poderia estar vinculando uma mensagem publicitária. Acho que aqui, o autoatendimento bancário tem muito ainda por utilizar do conhecimento construído por outros domínios, como o de vendas pela Web, os quais utilizam poderosos sistemas de recomendação.

Monitor é o componente que monitora aspectos como estados dos dispositivos, disponibilidades de serviços e notifica essas informações para sistemas especialistas responsáveis pela monitoração remota dos terminais. Esse módulo é o responsável, por exemplo, por coletar informações que irão definir qual a disponibilidade do terminal em um determinado período. As instituições bancárias mantém contratos de SLA com equipes de manutenção (que as vezes pertencem aos próprios fabricantes dos terminais), e nesse contratos há um número mágico que indica qual é a disponibilidade mínima do terminal durante um período (normalmente um mês). Algumas instituições determinam multas para as equipes ou fabricantes, quando a disponibilidade de seus terminais fica abaixo do que está estipulado nesses contratos. Por isso, esse módulo tem um papel bastante importante na aplicação de autoatendimento.

Periféricos é o componente por meio do qual se tem acesso ao hardware periférico do equipamento. Esse componente é responsável por oferecer uma forma padronizada de acesso a esses periféricos, mesmo diante da diversidade de fabricantes, modelos e infraestrutura disponível no hardware. Bom, isso é o desejável, mas o que se vê muitas vezes em algumas soluções no mercado é uma fraca separação da camada de acesso ao hardware e o restante do negócio da aplicação. Se toda vez que um novo serviço for introduzido na aplicação, o programador tiver que se preocupar em incluir código condicional para cada um dos modelos de terminal, fabricantes e etc, então a manutenção da solução será um caos. Então, o melhor é que haja uma separação clara dos módulos de acesso ao hardware, e que eles abstraiam a complexidade que possa haver nesse hardware, como modelo e fabricante de equipamentos e dispositivos.

Gestor é o componente que controla e gere a operação dos demais componentes da aplicação. Esse componente é responsável por decidir, por exemplo, se a aplicação está em operação ou fora de operação por manutenção, e também por processar comandos remotos enviados por sistemas especialistas de gestão de terminais.

Autorizador é o módulo responsável por estruturar a comunicação com um sistema externo que autoriza as transações. Em geral, todos os serviços disponíveis para o Cliente e o Operador só podem ser acessados mediante processos de autorização, os quais podem ocorrer em diversas etapas. A cada etapa, dados são trocados entre o sistema autorizador e a aplicação de autoatendimento, e uma das responsabilidades do componente em questão é representar esses dados de maneira conveniente para acesso pelos os demais componentes do software.

Serviço para Operador é o componente responsável por derivar todos os serviços que estarão disponíveis para o usuário Operador. São serviços típicos, abastecimento de numerário, configuração do número do terminal ATM, e outros.

Interface do Operador é o componente responsável pela camada de apresentação do software para o operador. Em geral, essa interface é mantida por hardware periférico específico, denominado Painel do Operador. No entanto, em alguns modelos de ATM essa interface é apresentada no mesmo hardware periférico utilizado para a interface do usuário Cliente (ex.: monitor). Quer dizer, em equipamentos dotados de painel do operador, um dispositivo especializado contendo um teclado e um display, é o responsável por prover a interface necessária para o operador operar o terminal a partir da de sua parte traseira. Esse tipo de configuração é típico em ambiente de agencia bancária, onde os terminais ficam posicionados por traz de um drywall, com apenas sua parte frontal sendo exposta aos clientes. Nessa configuração, o operador trabalha na parte de traz do drywall, separado do contato com o cliente, mantendo a segurança da operação e o conforto dos clientes também. Já quando os terminais estão em ambientes de shoppings ou lojas de conveniência, é comum que o terminal fique encostado em uma parede, impedindo sua operação traseira. Nesse tipo de configuração, não há um painel adicional e o operador deverá realizar suas operações por meio da mesma tela e teclado operados pelo cliente.

É isso. Até mais.