Resultados da busca

Create a blog post subtitle that summarizes your post in a few short, punchy sentences and entices your audience to continue reading. Welcome to your blog post. Use this space to connect with your readers and potential customers in a way that’s current and interesting. Think of it as an ongoing conversation where you can share updates about business, trends, news, and more. “Do you have a design in mind for your blog? Whether you prefer a trendy postcard look or you’re going for a more editorial style blog - there’s a stunning layout for everyone.” You’ll be posting loads of engaging content, so be sure to keep your blog organized with Categories that also allow visitors to explore more of what interests them. Create Relevant Content Writing a blog is a great way to position yourself as an authority in your field and captivate your readers’ attention. Do you want to improve your site’s SEO ranking? Consider topics that focus on relevant keywords and relate back to your website or business. You can also add hashtags (#vacation #dream #summer) throughout your posts to reach more people, and help visitors search for relevant content. Blogging gives your site a voice, so let your business’ personality shine through. Choose a great image to feature in your post or add a video for extra engagement. Are you ready to get started? Simply create a new post now.

Create a blog post subtitle that summarizes your post in a few short, punchy sentences and entices your audience to continue reading. Welcome to your blog post. Use this space to connect with your readers and potential customers in a way that’s current and interesting. Think of it as an ongoing conversation where you can share updates about business, trends, news, and more. Design with Ease “Do you have a design in mind for your blog? Whether you prefer a trendy postcard look or you’re going for a more editorial style blog - there’s a stunning layout for everyone.” Every layout comes with the latest social features built in. Readers will be able to easily share posts on social networks like Facebook and Twitter, view how many people have liked a post, made comments and more. With Wix, building your online community has never been easier. Create Relevant Content You’ll be posting loads of engaging content, so be sure to keep your blog organized with Categories that also allow readers to explore more of what interests them. Each category of your blog has its own page that’s fully customizable. Add a catchy title, a brief description and a beautiful image to the category page header to truly make it your own. You can also add tags (#vacation #dream #summer) throughout your posts to reach more people, and help readers search for relevant content. Using hashtags can expand your post reach and help people find the content that matters to them. Go ahead, #hashtag away. Stun Your Readers “Be original, show off your style, and tell your story.” Blogging gives your site a voice, so let your business’ personality shine through. Are you a creative agency? Go wild with original blog posts about recent projects, cool inspirational ideas, or what your company culture is like. Add images, and videos to really spice it up, and pepper it with slang to keep readers interested. Are you a programmer? Stay on the more technical side by offering weekly tips, tricks, and hacks that show off your knowledge of the industry. No matter what type of business you have, one thing is for sure - blogging gives your business the opportunity to be heard in a way in a different and unconventional way. Get Inspired To keep up with all things Wix, including website building tips and interesting articles, head over to the Wix Blog. You may even find yourself inspired to start crafting your own blog, adding unique content, and stunning images and videos. Start creating your own blog now. Good luck!

Create a blog post subtitle that summarizes your post in a few short, punchy sentences and entices your audience to continue reading. Welcome to your blog post. Use this space to connect with your readers and potential customers in a way that’s current and interesting. Think of it as an ongoing conversation where you can share updates about business, trends, news, and more. Design with Ease “Do you have a design in mind for your blog? Whether you prefer a trendy postcard look or you’re going for a more editorial style blog - there’s a stunning layout for everyone.” Every layout comes with the latest social features built in. Readers will be able to easily share posts on social networks like Facebook and Twitter, view how many people have liked a post, made comments and more. With Wix, building your online community has never been easier. Create Relevant Content You’ll be posting loads of engaging content, so be sure to keep your blog organized with Categories that also allow readers to explore more of what interests them. Each category of your blog has its own page that’s fully customizable. Add a catchy title, a brief description and a beautiful image to the category page header to truly make it your own. You can also add tags (#vacation #dream #summer) throughout your posts to reach more people, and help readers search for relevant content. Using hashtags can expand your post reach and help people find the content that matters to them. Go ahead, #hashtag away. Stun Your Readers “Be original, show off your style, and tell your story.” Blogging gives your site a voice, so let your business’ personality shine through. Are you a creative agency? Go wild with original blog posts about recent projects, cool inspirational ideas, or what your company culture is like. Add images, and videos to really spice it up, and pepper it with slang to keep readers interested. Are you a programmer? Stay on the more technical side by offering weekly tips, tricks, and hacks that show off your knowledge of the industry. No matter what type of business you have, one thing is for sure - blogging gives your business the opportunity to be heard in a way in a different and unconventional way. Get Inspired To keep up with all things Wix, including website building tips and interesting articles, head over to the Wix Blog. You may even find yourself inspired to start crafting your own blog, adding unique content, and stunning images and videos. Start creating your own blog now. Good luck!

Create a blog post subtitle that summarizes your post in a few short, punchy sentences and entices your audience to continue reading. Welcome to your blog post. Use this space to connect with your readers and potential customers in a way that’s current and interesting. Think of it as an ongoing conversation where you can share updates about business, trends, news, and more. Design with Ease “Do you have a design in mind for your blog? Whether you prefer a trendy postcard look or you’re going for a more editorial style blog - there’s a stunning layout for everyone.” Every layout comes with the latest social features built in. Readers will be able to easily share posts on social networks like Facebook and Twitter, view how many people have liked a post, made comments and more. With Wix, building your online community has never been easier. Create Relevant Content You’ll be posting loads of engaging content, so be sure to keep your blog organized with Categories that also allow readers to explore more of what interests them. Each category of your blog has its own page that’s fully customizable. Add a catchy title, a brief description and a beautiful image to the category page header to truly make it your own. You can also add tags (#vacation #dream #summer) throughout your posts to reach more people, and help readers search for relevant content. Using hashtags can expand your post reach and help people find the content that matters to them. Go ahead, #hashtag away. Stun Your Readers “Be original, show off your style, and tell your story.” Blogging gives your site a voice, so let your business’ personality shine through. Are you a creative agency? Go wild with original blog posts about recent projects, cool inspirational ideas, or what your company culture is like. Add images, and videos to really spice it up, and pepper it with slang to keep readers interested. Are you a programmer? Stay on the more technical side by offering weekly tips, tricks, and hacks that show off your knowledge of the industry. No matter what type of business you have, one thing is for sure - blogging gives your business the opportunity to be heard in a way in a different and unconventional way. Get Inspired To keep up with all things Wix, including website building tips and interesting articles, head over to the Wix Blog. You may even find yourself inspired to start crafting your own blog, adding unique content, and stunning images and videos. Start creating your own blog now. Good luck!

Recentemente temos participado de algumas concorrências para oferta de solução de Open Banking para nosso país, e alguns feedbacks nos comentam juntamente conosco que estão avaliando "produtos prontos 100% aderentes ao Open Banking Brasil". Esta afirmação nos soa no mínimo estranho e é este assunto que será abordado neste post. Regulação do Brasil em curso Na data deste post (4 de Maio de 2021), a regulação de Open Finance no Brasil ainda está em curso, portanto, é de se estranhar que possam haver produtos 100% prontos, nosso entendimento das hipóteses são as seguintes: Produto pronto para uma regulação existente, como a de UK e Europa, onde se espera que a regulação Open Finance do Brasil seja fidedigna à estas regulações, o que até o momento, por mais que exista uma semelhança e inspiração, ainda não é 100% igual. Isto nos leva a concluir que por mais mínimas que sejam, algumas customizações serão necessárias, e isto vai impactar em custos, e na nossa comum correria para adaptar e cumprir mudanças repentinas, e isto pode ser aceitável, e aconteceu por exemplo no PIX, e no Brasil, sempre tivermos orgulho de sermos resilientes e entendermos essas mudanças. Se a regulação está em curso, e mudanças ainda são esperadas, pensamos que nossa solução que é um Framework aberto para se adequar aos desafios dos clientes, e ao mesmo tempo ser resiliente as potenciais mudanças, ser uma decisão interessante para nosso mercado. Os componentes mais comuns de nossos framework, consistem em alguns componentes chave, como os listados abaixo: Aceleradores de Integrações para os Core-Bancários existentes, que vão desde Sinqia, Autbank, CRK etc, que permite conectar de forma fácil a esses componentes, e também a capacidade de converter dados(tabelas e stored procedures) e webservices mais antigos/legados em APIs 100% modernas e aderentes a regulação. API Gateway de altíssima performance , responsável em expor serviços existentes, dentro de padrões de segurança agora previsto pelo Open Banking. Componente de IDM/IAM capaz de se conectar as bases de usuários existentes dos Bancos Componentes de análise de processamento analítico para atender questões de SLA da regulação. E o mais importante impacto: O uso de FAPI - Financial Grade APIs para as questões de compartilhamento de dados cadastrais. Entenda um pouco sobre FAPI - Financial-Grade APIs “FAPI” para resumir, é um perfil OpenID Connect que fornece requisitos detalhados para os recursos de segurança necessários para realizar pagamentos e outras transações bancárias, percebemos que existem cabeçalhos FAPI já na Fase 2 do Open Banking no Brasil . CIBA, ou “Client Initiated Backchannel Authentication” - É um padrão OpenID usado para habilitar certos casos de uso na indústria do Open Banking. Imagine o caso de uso abaixo: Seu filho(a) está no shopping, e você está viajando, ele quer um sorvete, mas ele não tem dinheiro, nem cartões, mas ele tem o seu WhatsApp, para lhe avisar que ele vai digitar o seu número no pin pad, e você receberá um link para autorizar a transação do seu celular/mobile app. Assim como estes, vários outros casos de uso virão a tona, e para isso é necessário manter todas as pontas de interação de segurança, com certificados, e todos os elementos para garantir que é uma transação que se possa confiar. Além de todas os mecanismos de autorizações, é necessário ainda pensar nos fluxos de Consentimentos, pois alguns bancos vão querer trafegar todos os dados e atributos (claims), ou apenas os atributos mínimos para autorizações de transações. Nosso framework, pode usar os mecanismos de usuários (correntistas) existentes do Banco, fazendo com que nossas camadas de tratamento de OpenID Connect, FAPI-CIBA, possam ser camadas que interagem com estes repositórios legados. Por último, grande parte de nossa solução usa componentes open source, os quais temos as opções de suporte e suporte gerenciado destes deployments em nossos clientes. Conclusão Apresentamos aqui argumentos e assuntos que podem ser de seu interesse, para os Bancos S1 e S2, os prazos estão extremamente apertados, para os S3-S4, temos uma grande oportunidade de criarmos soluções mais econômicas e até mesmo mais inovadoras, que podem trazer grandes diferenciais competitivos para bancos de menor porte. Se estes, e outros assuntos relacionados ao Open Finance chamou a sua atenção, fale com a gente aqui, pois será um prazer poder conversar.

Este é um post para informar que acabou de sair do "forno" uma atualização da fase 2 do Open Banking no Brasil, para ser mais preciso, foram há algumas horas atrás: A propósito, este é o repositório no GitHub das novidades do Banco Central: https://github.com/OpenBanking-Brasil/ Uma das grandes novidades é a API de Consentimento do Open Banking, agora especificada e disponível para podermos adaptar alguns clientes e nossos produtos da área de Open Banking pro Brasil. O link do contrato Swagger é este aqui: https://openbanking-brasil.github.io/areadesenvolvedor-fase2/swagger/swagger_consents.yaml Verificando o Score de Segurança do Contrato da API de Consentimento Nós utilizamos a extensão gratuíta da extensão para o VS Code da 42Crunch, para verificar o relatório de auditoria de potenciais brechas de segurança no contrato swagger/open api spec que temos acesso. O relatório abaixo é difivido em 2 categorias: Segurança - 0 a 30 pontos Validação de Dados - 0 a 70 pontos O Score vai de 0 a 100, e é possivel ver que esta API, por não ter passado por um processo de DevSecOps focado no contrato da API, pode se dizer que a API tem um score bom, se considerado algumas outras APIs que já verificamos. O Score atual é 47 de 100, veja abaixo: Através da extensão do VSCode, e alguns ajustes de validações para não aceitarmos dados sem as devidas validações, faixas de aceitação, valores mínimos e máximos etc. Com estas ações será mais difícil para hackers e usuários maliciosos possam quebras as APIs dos bancos que tiverem esta atenção. Esta extensão da 42Crunch é gratuita. Veja a nova versão depois de alguns minutos de validações, saimos de 47 e chegamos a 91 de 100, e acreditamos poderiamos chegar bem próximo ou até mesmo em 100. Componentes do Skalena Consentment Gateway Para integrar com a plataforma de Consentimento, nós usamos nossos recursos de OAuth2 e OpenID Connect, além de APIs integradas para entregar a melhor experiência possível para nossos clientes. Além da seleção dos atributos que serão compartilhados, a qualquer momento os usuários podem revogá-los: Interface para que o usuário possa selecionar o que quer manter como dado compartilhado, a data de validade e ainda o controle de recibo de pedido de revogação de dados. Se pudermos ajudar na sua implementação da fase 2, ou ainda revisar a fase 1 e trabalharmos juntos nas fases 3 e 4, por favor, entre em contato com a gente: https://www.skalena.com/contato

Recentemente foi lançado o seguinte site: https://openbankingbrasil.org.br/, que visa trazer algumas informações importantes sobre o Open Banking no Brasil. Quando comparado a PSD2, e UK, o Open Banking do Brasil tem alguma similaridades, mas ainda algumas ações que podem ser desafios para nosso mercado, e é sobre isto que este post vai falar. Desafios do Brasil Diferente da Europa, Austrália, UK, no Brasil nós temos uma grande proliferação de vários players que quando junto, podem representar a figura do "core bancário", ou seja, não é somente um, dois, ou três e sim vários fornecedores para diferentes áreas do banco como: Conta-Corrente, câmbio, investimento, on-boarding/cadastro, crédito, tesouraria etc. Em nossa experiência já integramos inúmeros players distintos, entre eles: Sinqia AltBank Exchange Simply CRK etc Cada um destes, e de outros inúmeros outros produtos/soluções, possuem sua forma de integração, alguns deles já possuem APIs, outros, porém, ainda contam com informações em componentes de bancos de dados como Stored Procedures, Views, Triggers, e até mesmo ainda em sistemas legados em plataformas de mainframes. Levando em consideração a agenda acima da adoção, nós temos alguns Bancos que foram obrigados a entregar a fase 1 na data do dia 01/02/2021, porém, existem ainda vários outros bancos que vão perseguir essa corrida. O mesmo serve para todas as fases. Como nós acreditamos no modelo aberto de informação, este post visa compartilhar um pouco de nossa visão de como é possível implementar do ponto de vista técnico todos os objetivos de negócios em cada fase. Fase1 Alguns bancos basicamente capturaram views, ou mesmo ETLs, para expor isto como APIs para o mercado, seguindo diversos modelos. Em alguns clientes, usamos mecanismos de eventos com motores de mensageria como RabbitMQ e Kafka para centralizar dados, persistindo os dados em base de dados relacionais, e em alguns casos usando a plataforma MongoDB: Também existem Softwares de mercado, que oferecem APIs, e desta maneira, existem formas de criarmos serviços compostos, sejam com microserviços, ou até ferramentas que podem levantar serviços no modelo cloud-native. Em alguns clientes, é interessante já ter esses acessos protegidos por API Gateways, especialmente para implantar políticas que protegem os backends/APIs, especialmente de acessos inesperados, ou até mesmo bots. É parte de nossa recomendação, que mesmo informações públicas, o acesso seja protegido por um API_KEY, e que limite ao número X acesso em N tempo. Fase 2 Na fase 2, os consumidores poderão compartilhar(consentir) e disponibilizar suas informações entre instituições bancárias. Para que isto serve? Imagine quando você for tentar abrir uma conta num Banco A, ao invés de ter que informar tudo de novo, a gente poderá simplesmente dizer: Vou conectar com minha conta do Banco B. Consequência: Maior comodidade para os correntistas, todas as informações de forma mais rápida e eficiente. Pontos de Atenção: É importante que agora com a LGPD (Lei Geral de Proteção de Dados), as instituições possam atentar que o correntista(dono das informações) deve estar de acordo com esse compartilhamento (consentimento), e que também deve ser capaz de revogar a qualquer momento este consentimento. Principais Tecnologias Necessárias/Recomendadas Para esta fase, é importante que a organização tenha em mente alguns conceitos e tecnologias: a) Provedores de Autenticação OAuth2 : É importante que seu provedor de Autenticação possa estar aderente ao OAuth2, pois como a interoperabilidade será feita por APIs, é importante que as transações (requisições) e informações (scopes, tokens), possam ser protegidas por estas soluções. É extremamente mais fácil lidar com os IdPs, quando estes estão conectados a repositórios federados de identidades. b) Consentimento : Para atender a LGPD, e também levando em consideração que alguns bancos são filiais de bancos europeus (GDPR), é extremamente importante que o correntista possa ter a capacidade de "consentir", mas também revogar o uso das suas informações, e que a instituição possa manter um "recibo" de que esta ação foi solicitada. c) Composição de Serviços : Para atender as demandas de agregação de informações, pode ser interessante ter uma solução de busca de informações em diversas fontes, sejam de forma síncrona ou assíncrona. Eis que nesse cenário o uso de processamento com CDC (Change Data Capture) com Kafka, ou mesmo chamada a diversos endpoints, e armazenando num serviço de cache central pode ser uma grande alternativa. d) Segurança de APIs : De acordo com o Gartner: "Até 2022, as APIs serão os maiores vetores de ataques por Hackers", e como saber se suas soluções estão realmente seguras contra falhas de segurança e com o máximo de prevenção a ataque de hackers. A OWASP criou as Top 10 recomendações para segurança de API, e é muito importante que você atente que segurança não deve ser pensada apenas quando os serviços estão em produção, e que algumas vezes, o primeiro ataque pode ser o útimo. Ter suas APIs protegidas é fundamental. Vamos abordar a Fase 3 e Fase 4, na parte 2 deste post. Se quiser falar com agente, por favor, não deixe de nos escrever em https://www.skalena.com/contato, temos muito ainda para falar como ajudar na sua jornada de Open Banking.

Como prometido no post anterior, onde usamos o AWS API Gateway (https://skalena.net/blog/implementando-apis-do-openbanking-com-aws-api-gateway/) para expor nossos Backends de implementações das APIs de Open Banking de acordo com a Febraban: https://febraban.github.io/Open-Banking-/ . Nesta oportunidade vamos mostrar o Azure API Manager: Na página de produto https://azure.microsoft.com/pt-br/services/api-management/ , você pode encontrar mais detalhes da solução, assim como a capacidade de começar a usar a solução até mesma de forma gratuita. Você pode solicitar créditos de uso da Azure, que podem lhe ser úteis no uso de vários componentes de nuvem e como serviços providos pela Microsoft. Acessando o Portal de Gerenciamento de APIs Uma vez que você estiver conectado no seu ambiente com sua conta Azure, você poderá buscar por “API Manager”, assim como na tela abaixo: Console de Serviços da Azure O Processo de criação é extremamente simples, veja a imagem a seguir: Uma vez você passe pelo processo anterior de criação do serviço, você será direcionado para a página do recurso API Management: Relembrando o papel do API Gateway e do API Manager Estes dois termos algumas vezes podem gerar algumas confusões, pois algumas pessoas pensam que são a mesma coisa, e não são! Vale aqui uma breve explicação, do alcance de cada uma das soluções: API Gateway: É um componente que faz o papel de centralizar os acessos aos Backends: Imagem do papel do API Gateway: Fonte: https://microservices.io/i/Microservice_Architecture.png O API Gateway é também conhecido como um pattern(padrão), do popular catálogo de Microserviços do site Microservices.io( https://microservices.io/patterns/apigateway.html). Uma outra grande vantagem da centralização do API Gateway é o reaproveitamento de serviços comuns como: Segurança, Cache, controle de vazão, BFF (Backend for Front-end), etc, de forma que o Backend não precise se preocupar com estes aspectos e delegue esta tarefa para o Gateway central: A diferença de serviços comuns em cada Backend e todos centralizados pelo API Gateway Imagine dar manutenção em Microserviços/backends escritos em tecnologias diferentes, com diversas bibliotecas, em estágios de pipelines e entregas diferentes, imagine o trabalho e dor de cabeça que isto trazia para as organizações. API Manager : Espara-se desta categoria de produtos que alguns componentes além do API Gateway sejam entregues, como por exemplo: Serviços de informações analíticas, Portal de Desenvolvedor, componentes e/ou recursos de bilhetagem e medição de consumo das APIs, um provedor de chaves e autorização dos serviços etc. Pode-se dizer que o Azure API Manager, está mais para a categoria de um API Manager, do que apenas um API Gateway, visto alguns recursos que veremos agora. (ps- Em breve iremos falar de um projeto da Skalena que visa entregar um API Gateway de altíssima performance para o mercado, fique atento as nossas novidades.) Sempre começando pelo API:First Como uma de nossas práticas sempre usadas em nossos projetos, está sempre tentar começar as APIs pelos seus contratos, ou seja, pelo Open API Spec ou Swagger. No caso da API da Febraban, nós vamos utilizar o seguinte contrato: https://github.com/skalena/openbankingBR/blob/master/febraban/metrics.yaml Para importar este arquivo, podemos usar a opção Rawfile do GitHub: https://raw.githubusercontent.com/skalena/openbankingBR/master/febraban/metrics.yaml Em nossa interface de gestão, vamos selecionar a opção APIs, como é mostrado na imagem abaixo: Selecione a opção Open API de acordo a imagem apresentada a seguir, informe os valores de acordo: Informe o Swagger e um nóme válido, assim como display name (exibição) e API URL Sufix, que irá ser importante para o endereço da sua API Com o passo anterior, os recursos da sua Open API já estarão disponíveis para que você possa configurá-los. Como nossa API em questão é simples, você terá apenas um único resource do tipo GET com o nome metrics, de acordo com a seguinte imagem: Configuração do Resource HTTP Observe que a interface acima, lembra muito do AWS API Gateway, então, a configuração será tão intuitiva quanto. A esquerda temos a seção Frontend, que trata das configuração do recurso. Ao meio, na extremidade superior temos a seção Inbound processing que por sua vez, se destina a configurações da chegada da requisição, antes que esta seja enviada o Backend, que por sinal é a seção a nossa direita, que trata exatamente da capacidade de informar qual o endereço do Backend(microserviço, serviço, serverless etc) que irá processar a requisição. Por último, temos o Outbound processing que é a seção que trata quando o backend retornou a operação e possívelmente com dados de retorno para o originador da requisição. Para o Inbound processing, nós podemos adicionar inúmeras capacidades extra, como as apresentadas na image a seguir: Policies que você pode adicionar na chegada da requisição Dependendo do que você queira fazer, você já tem prontas inúmeras políticas que lhe permitem proteger e melhorar a entrega das suas APIs, entre as atividades que você pode fazer, podemos citar: Filtrar por IP que está chamando a API Limitar o número de chamadas a esta API Criar uma resposta Mock (exemplo/rascunho) apenas Adicionar parametros a URL de destino do Backend Adicionar cabeçalhos HTTP, por exemplo Basic Authorization, X-Qualquer-Header etc. Validar tokens JWT Permitir CORS Adicionar respostas a um Cache Políticas customizadas Etc Veja que em nosso exemplo, vamos adicionar uma Policy de Rate Limiting, dizendo que independente do IP, este só poderá realizar o máximo de 10 chamadas: Definição de Rate-Limiting Lembrando, que podemos adicionar ainda nossas políticas customizadas, a cada nova policy, caso você precise customizar, você poderá ver como está ficando um XML de customização de toda a configuração para você: Configuração de Policies : Request==> Policies ===> Backend Na seção de Backend, você irá apontar o destino do seu Backend. Que pode ser um Microserviço/Backend pronto, ou até mesmo uma Azure Logic Apps. Além do endereço, você ainda pode entrar com uma conta de usuário para autenticação HTTP Basic, ou até mesmo uma comunicação via certificado digital: Configuração do Backend Por último, assim como é possível adicionar politicas na chegada de dados, é possível também adicionar policies no retorno de dados, como por exemplo, adicionar cabeçalhos HTTP ou até mesmo outras políticas customizadas, veja a imagem a seguir: Configuração de Policies na seção Outobund Processing Como exemplo, vamos apenas adicionar um header customizado, como na imagem a seguir: Adicionando um Header customizado Finalizando nossa Publicação Como passos finais, podemos ver configurações gerais de nossa API na aba Settings, de acordo com a imagem a seguir: Configurações Finais da API No passo Subscription required, por hora, vamos deixar desmarcado. Além disto, nós ainda poderiamos habilitar a monitoração e o serviço de Azure Insights para esta nossa API, que neste momento, estará desabilitado também. Veja na aba seguinte Test, o resultado de nossa execução: Resultado executado com sucesso HTTP 200 – Nosso Backend retornou os dados de acordo Aqui o resultado no console/terminal para ficar exatamente o mesmo da execução do nosso post anterior, porém, observe que temos um Header a mais que é retornado pela nossa policy: Resultado de nosso Backend Para este Backend, nós estamos executando um serviço em nosso IPaaS: Skalena Cloud, que possui um serviço Kubernetes que executa nossas integrações a partir de uma imagem Docker. Lembrando, que adicionamos uma Policy que cada IP só pode fazer 10 chamadas por minuto. Como é sempre muito importante ter seu backend e infraestrutura protegida, vamos ver o resultado ao tentar executar mais de 10 vezes a partir do mesmo ip: Executamos o comando hey que por padrão envia 200 requests pro endereço, após isto, veja o resultado: O ambiente do Azure API Manager, recusou o atendimento, nos retornando um erro HTTP 429, com o código dizendo que o limite da quota de acesso foi excedido. Conclusão O Azure API Manager tem várias funcionalidades que poderiam ser exploradas neste post, mas nós tentamos deixar muito próximo das capacidades apresentadas também no post anterior que falamos do AWS API Gateway. Neste post nós usamos nossa própria camada de Backend as a Service da nossa solução Skalena Finance, que no caso do produto de Open Banking, combina alguns recursos e microserviços de MongoDB e APIs REST, ambos executados em nosso ambiente Kubernetes nuvem, porém, poderíamos também ter usado as capacidades do Azure Functions, que é o análogo ao AWS Lambda, porém, no ambiente da Microsoft. Se você tiver interesse e precisa de mais informações, sobre este post e qualquer outro assunto relacionado a Microserviços, APIs, OpenBanking no Brasil, por favor, entre contato com nosso time comercial aqui neste endereço: skalena.com/contato ou através de nosso e-mail direto: contato (a) skalena.com Um abraço do time Skalena! Bonus Métricas de Acesso aos Serviços A cereja do bolo: API DevPortal

Recentemente encontrei 2 Diagramas de Arquiteturas interessantes que gostaria de compartilhar aqui através destes post. Arquiteturas de Soluções Na figura abaixo, nós temos os seguintes componentes que podemos destacar: Canais de Consumidores: Aplicações de Canais e de Provedores Terceiros (TPP). Funcionalidades Comuns: UX Design – Experiência de Usuários DevOps – Modernização das Operações, Aplicações e Infraestrutura Segurança: Acesso, Tokens, Login Adaptativo, Detecção de Fraudes etc. Dados e Inteligência Artificial Cache de Dados Governança Infraestrutura de Cloud API Gateway Externo APIs de Open Banking e Serviços Produtos, Contas, Pagamentos, Clientes, ATMs, Agências etc. Developer Portal Acesso as APIs, Documentações, Gerações de Tokens, SDKs etc Sandbox Acesso a ambientes de Testes das APIs e execuções gratuitas. Autenticação Serviços de Geração de Tokens e chaves de acesso, usando padrões como OAuth2, JWT etc. Integração com provedores de Autenticação, on-premises ou soluções Cloud como Azure AD, Auth0, AWS Cognito etc. Consent Management : Com a entrada em vigo da Lei Geral de Proteção de Dados – LGPD no Brasil, por mas que o Open Baking não faça tanta referência a mesma, na fase 2 do Open Banking do Brasil, onde haverão compartilhamento de informações, estas por sua vez deverão ter o consentimento e possibilidade de revogação por parte dos usuários, que são os donos das suas informações, consequentemente, suas identidades. Gestão de Provedores Terceiros (TPP) Gestão de Serviços dos terceiros, on-boarding e exposição das suas APIs. Métricas/Relatórios/Auditoria : Apresentar dados de acessos das APIs, responder perguntas como “quem”, “o que”,”onde”, “quando” e “o porquê”, que possam realmente mostrar insigths do uso e consumos das APIs. Outras grandes disciplinas que podem ser atendidas nestes aspectos podem ser: Logs, Stream Analytics e Streaming/Messaging Processing (Kafka). API Gateway Interno Repositório de Serviços Internos, que podem estar protegidos e centralizados por um API Gateway Interno, que permita e esteja alinhado com todos os processos de DevOps, CI/CD, Cloud-Native etc. Core Bancários e Sistemas de Registros Integrar e Expor via APIs os Cores Bancários e sistemas existentes no Banco é fundamental para a habilitação de Open Banking. Um cliente uma vez fez um comentário que concordo totalmente: “O Open Banking nós já temos, só falta abrir”. Fora do Banco Diretórios de Open Banking Registros de Identidades Parceiros de Negócios Órgãos regulatórios Redes de Pagamentos Abaixo um diagrama que pode fazer você se encontrar na sua implementação atual: Arquitetura de Componentes em Camadas No Diagrama abaixo, eu gostaria de destacar as camadas de componentes e APIs, assim como o impacto ou necessidade do negócio envolvido: APIs de Experiência: Onde existe uma alta demanda de opiniões e orientação das áreas de negócios. APIs de Processo : Exposição de Processos via APIs, além de incorporar e/ou executar regras e tratamentos de exceções e erros. APIs de Sistemas: Basicamente expor os dados de seus protocolos, de forma mais unificada e com a possibilidade reuso. Aplicações, Protocolos e Dados: É importante ter um mecanismo, framework ou solução de integração com soluções SaaS, Mainframes(legados), trocas de dados com FTP, SFTP, uso de CDC(Change Data Capture) etc. Taxonomia de APIs usados por grandes Bancos O objetivo deste post é trazer para você uma espécie de espelho para idéias do que você pode e deve implementar em sua estratégia de Open Banking. Em termos de produtos e plataformas, vários deles podem ser usados para entregar sua solução de Open Banking, e lembrando, os mesmos conceitos podem ser usados para uma entrega de Open Health (Saúde), Open Insurance (Seguros), Open Government (Governo) etc. Precisando de qualquer ajuda, estamos por aqui em : https://skalena.com/contato . blog agora. Boa sorte!

Recentemente a Febraban disponibilizou um draft das APIs iniciais do Open Banking no Brasil. Estas APIs, de acordo com nosso entendimento, se referem bastante a Fase 1 do Open Banking no Brasil. Se você for neste link: https://febraban.github.io/Open-Banking-/ você consegue encontrar a documentação inicial e Swaggers. Neste post, iremos compartilhar algumas dicas de como disponibilizar seus dados através de APIs que podem ser hospedadas em seu ambiente AWS. AWS API Gateway O AWS API Gateway tem a finalidade de atender a necessidade de expor seus serviços através de APIs REST ou até mesmo WebSockets. A interface do AWS API Gateway é bastante intuitiva, e nela você consegue importar as definições Swagger/Open API Spec para servirem de base inicial da sua API. Importando o Swagger/OAS do Open Banking Brasil Aqui a API pode ser vista já importada: API importada Criando uma Lambda Function Vamos adicionar agora uma Lambda function, para atender ao recurso da API. Uma lambda, é uma função, ou pequeno código/componente que executa de maneira 100% como serviço, fazendo com que você não se preocupe com nada em relação a recursos, vms, loadbalancers, containers, etc. No exemplo abaixo estamos criando nossa function: impl-metrics: Criando a Função impl-metrics Em nosso exemplo, estamos adicionando uma informação como “hard-coded” ou “mock”, apenas para retorno com sucesso de nossa API, veja exemplo abaixo: Implementação de nossa função para o método GET /metrics Juntando as Peças: API-GW + Lambdas O importante é entender que cada componente, desempenha seu papel de forma isolada: A API em si, é controlada, definida no API Gateway, e nossa implementação está nas funções do AWS Lambda. Conexão entre os Componentes AWS O último passo agora é conectar nosso recurso /metrics no método http GET a lambda que acabamos de criar: API Gateway agora já conectado a função lamba No exemplo acima, a importação foi feita como HTTP Service, mas você pode especificar como REST API, onde os passos não irão mudar muito, e algumas funcionalidades interessantes, serão exibidas como esta: Importando o Swagger/OAS para gerar uma REST API Criando o Stage de Deployment Neste momento, estamos criando uma versão que já poderá ser nossa produção, ou você pode controlar seus versionamentos e estágios de deployment de inúmeras maneiras também. Aqui nossa configuração base: Criando o estágio V1 (que seria nossa produção) Aqui o nosso ambiente pronto para ser executado: Ambiente de Produção já habilitado Testando Agora vamos testar nossa API, como se fossemos um cliente acessando nossa URL já em produção: Testes 100% funcionais Recursos Adicionais Nós poderiamos ainda adicionar recursos como: Capacidade de Criação de Planos de Acesso Criação de API Keys para proteção de Recursos Dashboard de Execução O stack de soluções da AWS é gigantesco, mas essa combinação de API Gateway + Lambdas, para Open Banking, fase 1 do Brasil, poderá ajudar várias empresas e organizações que podem estar enfrentando dificuldades neste momento. Conclusão Neste post, vimos como importar o contrato de api do que foi publicado pela Febraban, e como podemos criar uma função Lambda para devolver os dados esperados. Vale ressaltar, que neste exemplo usamos apenas um Mock, porém, você consegue fazer literalmente qualquer coisa de dentro de uma lambda function na AWS. Para implementar seu caso real, você deveria ter uma View, ou repositório de dados, que pudesse ser conectado na função e poder buscar as informações de dados a quente. Como ponto de atenção, apenas tenha cuidado com a Governança e rollout de produção de suas funções, afinal de contas, você estará com o princípio “homem aranha” nas suas mãos ( “Com grandes poderes, vêm grandes responsabilidades”). PS- Tentaremos fazer em um novo post, a mesma abordagem usando Azure como solução Cloud. PS2 – Se você gostou de Lambdas, mas não gosta da idéia de ficar somente em uma núvem, dê uma olhada nos projetos KNative e Open FaaS . PS3 – Na plataforma Cloud da Skalena, você tem 100% das APIs da Febraban no modelo multi-tenant já pronto para uso: #API #OpenBanking

Monitorando Logs do WSO2 Enterprise Integrator com ELK Stack (Elasticsearch, Logstash, Kibana) + Filebeat Configuração e Instalação das ferramentas da ELK Stack ElasticSearch Acesse o site da ElasticSearch para download da versão 7.0.0(ou última) e escolha o arquivo de acordo com seu Sistema Operacional. 2. Logstash Acesse o site de download da Logstash da versão 7.0.0(ou última versão) e faça o download do arquivo TAR.GZ. 3. Kibana Acesse a página de downloads do Kibana na versão 7.0.0 e faça o download do arquivo de acordo com seu Sistema Operacional. 4. Filebeat Acesse a página de downloads do Filebeat na versão 7.0.0 e faça o donwload do arquivo. Após a instalação tenha sido realizada com sucesso, você deverá acessar através da linha de comando, entrar na pasta /bin no local de instalação do seu Elasticsearch e executar o seguinte comando: Ao fim da execução, você deverá ver uma tela parecida como a seguinte no seu terminal A seguir, acesse pelo seu navegador o link mostrado na linha de comando, o padrão é: http://localhost:9200. Caso você veja a tela abaixo, significa que seu elasticsearch está rodando normalmente. A seguir, devemos editar o arquivo kibana.yml dentro do diretório /config da pasta de instalação do Kibana no seu computador. Iremos procurar a propriedade elastisearch.hosts no arquivo e descomentá-la. O http://localhost:9200 é o endereço do Elasticsearch onde o Kibana irá se conectar Em seguida, devemos executar o comando kibana.bat (ou.sh) dentro do diretório /bin na pasta de instalação do seu Kibana. Após a execução com sucesso do comando, você deverá ver uma tela parecida com essa. Para acessar o kibana, basta abrir seu navegador no link padrão passado no CMD no final de sua execução. Na pasta /bin no diretório de instalação do Logstash, crie um arquivo chamado logstash.conf e adicione a configuração abaixo: input { beats { type => "test" port => "5044" } } filter { if [message] =~ "tat" { grok { match => ["message", "^(tat)"] add_tag => ["stacktrace"] } } } output { stdout { codec => rubydebug } elasticsearch { hosts => ["localhost:9200"] } } A configuração input vai estar lendo toda a informação gerada pelo Filebeat na porta 5044, enquanto no output toda a informação que o Logstash pegar, ele passa pro Elasticsearch na porta 9200. A seguir, acesse através da linha de comando a pasta /bin do diretório Logstash e execute o comando a seguir: Nesse comando passamos o arquivo logstash.conf que acabamos de criar Após a execução com sucesso do comando, você deverá ver uma tela parecida com essa: Integração com o WSO2 Enterprise Integrator 6.6.0 Agora, devemos editar o arquivo filebeat.yml que se encontra na pasta raiz do Filebeat, e adicionar a seguinte configuração: filebeat: inputs: - paths: - C://Enterprise Integrator/6.6.0/repository/logs/*.log input_type: log multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}' multiline.negate: true multiline.match: after output: logstash: hosts: ["localhost:5044"] Nessa configuração especificamos o caminhos dos logs para que o Filebeat leia e o host do Logstash Server que é a saída de onde essa informação será mandada. Feito isso, agora basta executar dentro da pasta raiz do Filebeat o seguinte comando: Caso a operação tenha sido um sucesso não irá aparecer nada no terminal, se houver erro, será mostrado. Integrando o ELK ao WSO2 Enterprise Integrator Ao final de todas as configurações, será possível visualizar os logs da Enterprise Integrator no seu Kibana, como mostrado abaixo: Tela mostrando os detalhes de um log específico Você também pode aplicar filtros a partir de ID, data e versão. Gráfico criado no Dashboard com base no timestamp dos logs das requisições Gráfico mostra a quantidade total de cada tipo de log trazido Conclusão Neste post, vimos rapidamente como é possível integrar o stack ELK com a plataforma de Integração WSO2. Se quiser conversar com a gente sobre estes e outros assuntos relacionado a WSO2 ou a plataforma Cloud da Skalena, fique a vontade de nos mandar uma mensagem em: https://www.skalena.com/contato Autores Contribuiram neste post: Larissa Menezes é Formada em Análise e Desenvolvimento de Sistemas pelo Instituto Federal de Educação, Ciência e Tecnologia do Amazonas – IFAM. É desenvolvedora na Skalena com expertise em desenvolvimento Full-Stack, Integrações e APIs. Patrick Clarindo é Formado em Tecnologia da Informação pela Universidade Cidade de São Paulo. É desenvolvedor na Skalena com expertise em desenvolvimento de APIs com SpringBoot, Integrações e APIs. #API #integracao #Monitoracao #WSO2

Configurado métricas do WSO2 Integrator com EI Analytics Jaeger Neste post vamos falar um pouco de Tracing com uma ferramenta extremamente popular no mercado: Jaeger. Veja os passos a seguir: Primeiramente é necessário a instalação do Jaeger em sua máquina correspondente ao seu sistema operacional: 2. Em seguida execute-o pelo CMD/terminal o arquivo jaeger-all-in-one.exe que irá rodar na porta padrão 16686. Para que o Enterprise Intergrator possa se comunicar com Jaeger é preciso adicionar suas configurações do Analytics no arquivo carbon.xml encontrado no seguinte diretório: confcarbon.xml (EI_HOME: Onde está instalado seu EI) Deixe Seu ServerURl como tcp://localhost:7612 E AuthServerURL como ssl://localhost:7712 Em seguida abra o arquivo synapse.properties encontrado em confcarbon.xml e adicione as informações do Jaeger por Default. opentracing.enable=true jaeger.sampler.manager.host=localhost jaeger.sampler.manager.port=5778 jaeger.sender.agent.host=localhost jaeger.sender.agent.port=6831 jaeger.reporter.log.spans=true jaeger.reporter.max.queue.size=100 jaeger.reporter.flush.interval=10000 Mude também as configurações dos Mediations encontrados no mesmo arquivo. mediation.flow.statistics.tracer.collect.payloads=true mediation.flow.statistics.tracer.collect.properties=true mediation.flow.statistics.collect.all=true mediation.flow.statistics.enable=true Feito isso agora basta executar os serviços encontrados no diretório bin e execute o analytics-worker: No final deverá ver uma tela como essa: Agora Execute o Enterprise Integrator (6.6.0): Deverá aparecer o seguinte resultado: Caso execute o Integrator antes do Analytics irá acontecer um erro de conexão já que ele não irá achar nada na porta 7712. Caso não aconteça nenhum erro de conexão então o Enterprise Integrator conseguiu se conectar com sucesso ao EI Analytics. Para que suas APIs (Serviços HTTP) possam ser vistas pelo Jaeger é preciso ativar Enable Tracing e Enable Statistics, como na imagem abaixo: Para finalizar e observar o tracing basta abrir o Jaeger no seu navegador http://localhost:16686. Ao executar qualquer requisição de APIs ou outro serviço do EI, os dados de tracing estarão disponíveis como na sequência de imagens abaixo: A tela de Finding Traces, mostra todas as interações feitas com a sua API. Tela de Finding Traces Para visualizar os detalhes de um trace específico, basta clicá-lo e a seguinte página será mostrada. Visualizando o EI Analytics Dashboard O próprio Enterprise Integrator possui uma ferramenta padrão para a visualização dos analytics de uma API e qualquer outro serviço. Execute os comandos abaixo para visualizá-la: Após a execução do comando, você deverá ver uma tela parecida com esta. Para acessar a tela de login do dashboard, acesse no seu navegador o link mostrado na linha de comando: https://192.168.56.1:9643/portal. O login padrão é admin e a senha admin. Como exemplo, usaremos uma API de Clientes, na tela abaixo é mostrado todas as requisições feitas na API que tiveram sucesso e as que falharam: Nessa segunda tela, é mostrado dois gráficos: o primeiro indicando os sucessos e falhas na requisição, o segundo é mostrado a latência da API, ou seja, o tempo que ela demorou para responder a requisição. Na parte inferior da página, é possível visualizar os messages id da API, bem como host e timestamp, podendo filtrá-las por data. Ao clicar num MessageId, você poderá visualizar o diagrama que mostra o fluxo da resposta da requisição feita. Caso queria exportar seus dados como PDF, basta clicar no menu inicial do EI Analytics e selecionar a opção “Generate Report”. Autores Neste post contribuiram: Larissa Menezes é Formada em Análise e Desenvolvimento de Sistemas pelo Instituto Federal de Educação, Ciência e Tecnologia do Amazonas – IFAM. É desenvolvedora na Skalena com expertise em desenvolvimento Full-Stack, Integrações e APIs. Patrick Clarindo é Formado em Tecnologia da Informação pela Universidade Cidade de São Paulo. É desenvolvedor na Skalena com expertise em desenvolvimento de APIs com SpringBoot, Integrações e APIs. #Monitoracao #tracing #WSO2