Resultados da busca

3 Ferramentas Interessantes na sua iniciativa de APIs Nas iniciativas de APIs das empresas, podemos observar algumas ferramentas que podem facilitar muito a nossa vida nas implementações de nossos projetos. Desenho de APIs: “API First” Uma das estratégias mais importantes numa iniciativa de APIs é poder criar seus contratos antes. Estes contratos podem ser definidos no formato JSON ou YAML, e seguem as especificações padrões de mercado chamadas respectivamente de Swagger(versão 2.0) Open API Specification (versão 3.0). Confira um post sobre API First aqui. Uma das ferramentas mais populares, se não a mais, é sem dúvida o Swagger Editor, você pode ver a versão on-line desta ferramenta aqui: https://editor.swagger.io. Swagger Editor Online Ainda que seja uma solução extremamente popular, até mesmo embarcada em alguns produtos de APIs, ou mesmo a versão colaborativa no Swagger.io, quando o assunto é Swagger ainda existem uma certa curva de aprendizagem, afinal de contas, muitas pessoas neste momento estão migrando para o novo mundo das APIs. 1. Alternativa ao Swagger Editor: StopLight Testamos uma ferramenta que até o momento vem apresento uma incrível produtividade quando o questão é documentar suas APIs com Swagger ou OAS: StopLight: StopLight Studio Uma ferramenta gratuita, produzida pela empresa StopLight(https://stoplight.io), que ainda possui outras duas ferramentas bem interessantes para o público de APIs: Spectral: https://stoplight.io/open-source/spectral/ (Validação de JSON, YAMLs, configurações Kubernetes etc) Prism: https://stoplight.io/open-source/prism/ (Criação de Mocks) 2. Alternativa ao Postman: TestMace Uma outra ferramenta consagradíssima é o Postman, mas para aqueles que precisam de uma alternativa, que pode ajudar a organizar de uma forma um pouco mais lógica seu projetos, e adicionar até outros recursos, como documentações (arquivos .MD) etc, esta é uma opção super interessante também: Test Mace (Alternativa ao Postman) Você pode encontrar o download em: https://testmace.com . Existem alguns planos pagos, mas tenho usado a ferramenta na versão gratuita e tem funcionado super bem. Uma grande vantagem que eu observei é a capacidade de conectar-se ao portal de projetos da testmace, e criar seus projetos como se fosse um repositório de time, desta forma todos terão a mesma visão dos seus endpoints, parâmetros e variáveis, que por mais que o Postman permite a exportação, em muitas vezes ainda temos o sentimento, ou frustração do famoso “Works in My Machine”. Neste post: https://dev.to/dimansny/why-testmace-is-better-than-postman-2412 , o autor descrever alguns pontos dos porquês do TestMace ser melhor que o Postman. Spoiler: A única coisa que percebemos, é que o Postman responde mais rápido, ou pelo menos esta é a sensação que tivemos ao usar as duas ferramentas. Se o tempo estiver livre, faça o teste e tire suas conclusões também 🙂 3. Suas APIs são realmente Seguras? A pergunta 1 milhão de dólares quando você lança sua iniciativa de APIs, e aí entra em cena uma solução praticamente que pioneira e única no mercado: 42Crunch: Console da plataforma 42Crunch A solução permite verificar se o contrato da sua API (lembra do Swagger/Open API Spec?) possui brechas de segurança, ou se de alguma maneira sua API apresenta alguma fragilidade de ataques. Lembre-se: Grande parte do tráfego das aplicações são entregues através de APIs, portanto, Web Application Firewalls tradicionais, ou proteções apenas na camada Mobile ou Web App já não são suficientes contra ataques de hackers e usuários maliciosos. Em 2019, uma grande operadora de telecom e tv a cabo do Brasil , deixou vazar dados de ex-clientes, quando falamos de 8 milhões de registro, o termo vazamento pode ser tratado como uma enxurrada de dados que foram expostos. A plataforma 42Crunch permite validar sua API desde o processo de desenvolvimento, passando pelos seus pipelines CI/CD até mesmo quando seu API Gateway, seja ela qual for, está trafegando suas APIs, Tokens etc. Plataforma 42Crunch: Acesso para verificações de Swaggers/OAS gratuitos A Skalena é parceiro e distribuidor oficial na América Latina da 42Crunch. Conclusão Estas são apenas 3 das ferramentas que nossa equipe vem usando em projetos em nosso dia-a-dia, se você se interessou por alguma delas, ou gostaria de conversar como podemos ajudar de alguma forma em suas iniciativas de APIs, Micro-serviços, Integração e Gestão de Identidade, entre em contato com a gente aqui: https://www.skalena.com/contato #API #Ferramentas

Zero-Bank : Plataforma Open & Digital Banking Skalena Lançamos hoje dia 05/11/2019 a plataforma 0-Bank(Zero-Bank) que é uma plataforma que reúne componentes que conseguem conectar e gerar soluções digitais para os mercados financeiros. Nós estamos capturando como padrão e referência algumas soluções que a Skalena leva para o mercado como uma Arquitetura de Referência. Nós entendemos que esta arquitetura necessita de: Gestão/Gateway de APIs Gestão de Tokens e Gestão de Consentimento de acessos Firewall de APIs Contratos (Swagger/Open API Spec) de Serviços Financeiros Plataforma de Privacidade de Dados Em nossa arquitetura propomos o seguinte padrão: Arquitetura de Referência No Brasil nós temos inúmeros Cores Bancários, desde Consignados, Derivativos, Conta-Corrente, Investimento etc. Uma grande dificuldade de nossos clientes é exatamente criar um formato e contratos JSON e APIs que podem expor estas informações de forma simples e ágil; para expor estas informações através de contratos e formatos (dados) já usados em vários lugares no mundo, estamos usando o Apache Fineract e outros componentes da WSO2 e 42Crunch. Aplicabilidade A exemplo de exposição de dados, nós usamos funcionalidades do WSO2 Micro-Integrator para transformar dados dos Cores Bancários com as transações do Apache Fineract: Mapeamento dos Dados dos Cores Bancários com os contratos Apache Fineract Developer Portal sobre as APIs do Apache Fineract Developer Portal com Documentação de acordo com a Linguagem de Consumo Nosso maior objetivo é aproximar de clientes, integradores, fabricantes de softwares de finanças e bancos para ajudar na criação de um padrão ágil e que possa ser uma base com aplicabilidade comprovada de contratos já usados em outros mercados e geografias no mundo. Em breve, ainda em Novembro de 2019 haverá uma nova consulta pública do Banco Central sobre Open Banking no Brasil, vamos acompanhar essa evolução para deixar nossa plataforma sempre o mais aderente possível. Fique atento e para falar com a gente, nos envie uma mensagem em nosso formulário de contato. #OpenBanking #WSO2

Apresentando WSO2 Enterprise Integrator 7.0 Nesta semana a WSO2 lançou a versão 7.0 do consagrado produto WSO2 Enterprise Integrator, neste post vamos observar algumas novidades e mudanças nesta nova versão. Novos Instaladores A WSO2 agora disponibiliza os instaladores via instaladores dos sistemas operacionais, além dos mais populares gerenciadores de pacotes de mercado. Instaladores Disponíveis No meu caso, eu instalei no MacOs. Se você usar os Instaladores, eles vão informar o local de Instalação do seu ambiente, no meu ambiente, a instalação ficou neste caminho: /Library/WSO2/EnterpriseIntegrator/7.0.0/ Nova Abordagem do Produto Nesta nova versão nós temos os seguintes “profiles”: Ballerina Integrator Micro Integrator Streaming Integrator Profiles do novo EI 7.0 Esta nova versão do Enterprise Integrator, traz para cada profile uma diferente abordagem de integração: Estilos para as Integrações Programação: Para quem prefere o estilo de criar código, programar essencialmente a comunicação dos protocolos, criar os testes unitários, você utilizará a linguagem Ballerina, que foi criada pelo time da WSO2. Esta linguagem foi criada pensada na implementação de Arquiteturas “Cloud Native”, que permite a criação de micro-serviços que podem de maneira fácil ser exportado para ambiente Docker e Kubernetes. Para novos usuários da plataforma e a nova geração de desenvolvedores que estão habituados com Node.js, Python, go etc, esta opção poderá ser facilmente aprendida. Configuração: Para os desenvolvedores que já usam a plataforma WSO2 há mais tempo, já devem estar habituados com a linguagem de mediação chamada Apache Synapse, que é baseada em XML. Desta forma, é possível continuar usando tanto a programação visual usando o Eclipse, e claro, o Visual Studio. O modelo de execução do Micro-Integrator, permite com que uma aplicação (CAR file) possa ser executada de forma exclusiva num runtime Docker ou mesmo num ambiente de Pods do Kubernetes/OpenShift etc. Streaming: O conceito de Streaming começa a fazer muito sentido para alguns casos de uso que exigem uma performance ao extremo e uso de notificações em tempo real, entre os casos de uso para este modelo de integração temos exemplos como: CDC(Change Data Capture), Processo de leituras complexas de arquivos, consumo e publicação no KAFKA etc. Papel do Enterprise Integrator O EI continua sendo um provedor de implementação Backends/Integrações que podem ser expostas através de um API Gateway, como o WSO2 API Manager ou qualquer outra solução. Estas integrações podem ser incrivelmente acelerada pelo uso dos conectores prontos que acompanham a solução. Papel do EI continua o mesmo, porém com uma roupagem modernizada Uma nova forma de pensar Micro-serviços e Ambientes Cloud Native Conversando com nosso time, uma das coisas que mais achamos interessante é o ecossistema de ferramental que permite as Arquiteturas usarem vários recursos aderentes a DevOps e Observability. Dentro da implementação do próprio serviço é possível definir o comportamento de testes unitários, criação de imagem docker, Kubernetes, além da comunicação com ferramentas como Jaeger, Prometheus, Grafana e o stack ELK. Suporte ao Visual Studio Code A boa experiência do desenvolvedor é garantida com o uso do Plugin disponível para o Visual Studio Code, que permite renderizar os códigos e ainda recursos como renderização das APIs Rest já de acordo com o Open API Specification: Código vs de Fluxo Open API Spec vs Fluxo Demonstração Simples Primeiramente executo a opção de build do Ballerina Lang, observe na imagem abaixo, que os testes unitários são executados, e é gerado um jar file, que pode ser executado como um “Uber jar”, na mesma forma que um jar SpringBoot: Executando o exemplo Veja abaixo a sequência de execução do Exemplo: Backend/API sendo executado na porta 9090 Conclusão Em breve outros colegas do time irão publicar alguns tutoriais e resultados de implementações que estamos trabalhando. Se quiser conversar com a gente como transformar suas integrações, mande uma mensagem para nós, será um prazer tomar um café com você. Boas Integrações e até a próxima. #ei #WSO2

O mundo está cada dia mais expondo APIs (Open), Segurança de APIs é crítico e vamos entender estas razões: Gartner prevê que até 2022 as APIs serão os pontos #1 de ataques de hackers Existem brechas de APIs a toda semana – Veja alguns exemplos na newsletter da https://apisecurity.io/ . Abaixo alguns exemplos: Equifax teve uma brecha de vulnerabilidade oriunda do uso de uma biblioteca sem suporte do Apache Struts (popular framework de desenvolvimento web Java) mais especificamente nos cabeçalhos http . A empresa aceitou pagar uma multa de 700 Milhões de Dólares, O valor da Equifax, um gigante na área financeira foi considerável reduzido. Sistema Governo Frances Tchap foi hackeado por não forçar a validação de um parâmetro de dado de e-mail, permitindo que pessoas de forma do domínio pudessem te acesso ao sistema de forma indevida (entrada não validada: (fs0c131y@protonmail.com@elysee.fr). LandMark White – Foi hackeada devido a uma falha de segurança no backend, eles perderam marketshare, valor das ações caíram, tendo ficado fora do mercado por período de tempo, e seu CEO teve que sair. Por que é tão difícil aplicar segurança em APIs? APIs são distribuídas – Empresas possuem dezenas, centenas o milhares de APIs externas (através do uso de API Gateways como WSO2, Sensedia, CA, Axway, AWS, Azure etc), que são desenvolvidas e mantidas em alguns casos por times diferentes. APIs usam um stack variado de implementações: AWS API gateway, AWS Lambda & EC2, linguagens de programação (Node.js, Go, Python), etc. APIs são “frontends” de dados críticos, incluindo pessoais (LGDP, GDPR) O uso correto ou fraudulento de APIs está específico muitas vezes na implementação, não existe uma forma de uma regra única e universal para saber se uma mensagem(payload) esperada pela API é algo esperado ou é proveniente de um ataque. Teoricamente, é possível ter todos os desenvolvedores exaustivamente treinados em segurança de APIs que apliquem todos e quaisquer testes de segurança (autenticação, autorização, transporte, JWT, cada pedaço do dato indo e voltando) e todos os possíveis pontos de entrada (formato de todos os cabeçalhos, valores fora de uma faixa ou padrão etc) – Na realidade atentar de forma humana e manual é sem dúvida pouco prática e impossível. O custo em termos de esforço manual e o risco de erros humano tem se tornado quase que proibitivos em termos de custos. A Skalena é o distribuidor da Plataforma 42Crunch na América do Sul, quando nós trouxermos essa parceria para região, o nosso maior objetivo é fazer com que os nossos mercados cada vez mais possam abrir suas APIs sem as possíveis e recorrentes dúvidas a respeito de segurança e acesso. Nós estamos cada vez vivendo a era “Open”, já temos o Open Banking a caminho de uma regulação no Brasil, e na sequência temos a Open Insurance (para seguros), e agora recente vimos a Open Retail Initiative. De modo geral a democratização do acesso a informação, trará enormes benefícios, mas também mazelas de segurança que temos que evitar a todo o custo. E como a plataforma 42Crunch pode ajudar você de forma resumida? É integrável com qualquer API Gateway/Manager de mercado, se você usa Sensedia, WSO2, CA, 3Scale, Apigee, Kong, Tyq etc, o papel de segurança e prevenção de ataques do 42Crunch está para para uma API, assim como um WAF(Web Application Firewall) está para suas aplicações Web. Sim, o 42Crunch é um API Firewall, uma categoria de software ainda nova no mercado, mas de suma e extrema importância para quem estiver subindo APIs na rede. Se você não tiver nenhum API Gateway, o 42Crunch pode servir com este propósito, adicionando OAuth, rate limit, proteção de Dos e ainda outras políticas básicas como IP Whitelist, tamanho de mensagem HTTP e WAF) A plataforma 42Crunch analisa o contrato da sua API (Swagger, RAML ou OAS – Open API Specification), e antes de ir passar até mesmo para a fase de Mock da sua API, já lhe informa suas potenciais falhas de design e segurança. No relatório gerado, é apontado exatamente o que, onde e a justificativa de mudar ou adaptar algo). Todos os contratos das APIs nas fases de DEV, QA, Prod já aderente aos seus pipelines DevOps são verificados para garantir a consistência dos mesmos. Este modelo aplica um modelo de Security by Design , ou seja, a premissa é que segurança é um item inegociável. Como a solução é centralizada, mesmo que a organização tenha mais de 1 API Manager/Gateway, todos os contratos serão auditados, “scaneados” pela plataforma. 100% aderente a todas as práticas de DevOps dentro de uma organização. A Skalena em seu portfólio de soluções tem na 42Crunch uma aliança estratégica para entregar uma plataforma de Microserviços e APIs segura e robusta em todos os aspectos. Como nós utilizamos nossa ferramenta própria de aceleração de desenvolvimento: Mapperidea, todos nossos contratados Swagger e OAS já nascem dentro das recomendações da 42Crunch. Ficou interessando? Vamos bater um papo sobre o assunto, e será um prazer convidar meu amigo e ex-colega da WSO2: Dmitry Sotnikov (VP of Cloud da 42Crunch) para fazer parte da conversa. #42Crunch #API

WSO2 Stream Processor : Primeiros Passos Uma das primeiras perguntas que você pode fazer é: “Onde e quando posso usar o Stream Processor? A resposta em resumo pode estar nos seguintes casos de uso abaixo: (apenas para começar): Dashboards para visualização de Dados Alertas em tempo real de fontes de dados temporais e espaciais ou até mesmo anomalias Extract, Transform, Load (ETL) ou Real Time ETL IoT (Dispositivos e Eventos) Event Sourcing pattern Neste exemplo vamos focar um pouco em Real Time ETL. A performance do WSO2 SP é impressionante, tanto é que que já foi utilizado por empresas como Uber, em casos de uso de detecção de fraude. O WSO2 Stream Processor é uma ferramenta que permite o processo de Eventos Complexos em tempo real, ou como também conhecemos como CEP (Complex Event Processing) . O Stream Processor, como projeto de comunidade é conhecido como Siddhi (evento em Singalês) , desenvolvido inicialmente pela WSO2, esta plataforma permite ser embarcada como biblioteca em aplicações Java, Python e também expõe informações através de REST. Baixando e Rodando a Ferramenta Para começar, vamos começar realizando o download da ferramenta. Para isto vá até o seguinte site: https://wso2.com/analytics-and-stream-processing/ , lá você encontrará os instaladores do Stream Processor. Para fins de aprendizagem, recomendo o binário, por ser um zip de fácil entendimento e uso. Executando o Stream Processor pela primeira vez Quando acabar o download, descompacte o zip, e vá até a pasta bin execute o utilitário editor.sh. (Nota Importante: Você deve ter o JDK 1.8.x instalado em sua máquina). Quando acabar o download, descompacte o zip, e vá até a pasta bin execute o utilitário editor.sh. (Nota Importante: Você deve ter o JDK 1.8.x instalado em sua máquina). cd /bin ./editor.sh Aqui o WSO2 Stream Processor Inicializado Abra o seguinte link na sua máquina: http://localhost:9390/editor, e ai você poderá ver o editor de programas Siddhi. Você verá a interface inicial, na qual você pode clicar no menu File/New para ter um novo “Programa” Siddhi, chame seu novo arquivo de ETLStreamApp: Interface Principal do Editor Vamos entender alguns conceitos de um programa/app Siddhi: Exemplo Básico A idéia da app em si, é que ela terá 1 ou n (sources) origens de dados, com estas origens, nós construiremos streams, e estes streams quando filtrados podem dar origem a novos streams, estes por sua vez podem ser persistidos em repositórios de saída, desde um novo arquivo texto, chamada HTTP, Bancos de Dados ou um tópico do Kafka. Exemplo 1 Neste primeiro exemplo, vamos realizar a seguinte tarefa: a) Ficar “escutando” uma pasta para quando um arquivo chegar b) Ao chegar o arquivo, este deve ser carregado para memória com a definição do stream inicial c) O arquivo carregado, tem cerca de 7500 linhas com crimes da cidade de Sacramento, vamos filtrar para termos apenas os crimes de ID 5400 d) Apenas os crimes com este critério serão salvos num banco de dados, para o exemplo, eu usei o MySQL. A seguir veja o código do exemplo: @App:name('ETLStreamApp') @App:description('ETL from CSV ') @source(type = 'file', mode = 'line', tailing = 'false', dir.uri = 'file:/Users/edgar/Desktop/trash/poc-cliente/arquivos/IN', action.after.process = 'delete', @map(type = 'csv', header = 'true', @attributes(distrito = '2', endereco = '1', latitude = '7', crime = '5', dataHora = '0', codigocrime = '6', longitude = '8'))) define stream CargaInicialCrimesStream (dataHora string, endereco string, distrito string, crime string, codigocrime string, latitude string, longitude string); @sink(type = 'log', priority="info") define stream DitritoCrime5400 (dataHora string, endereco string, crime string, latitude string, longitude string, totalCount long); @sink(type = 'log', priority="info") define stream TotalDeLinhasStream (totalCount long); @store(type="rdbms", jdbc.url="jdbc:mysql://localhost:3306/streamdb", username="root", password="mysql",jdbc.driver.name="com.mysql.jdbc.Driver", pool.properties="maximumPoolSize:30") @Index('dataHora') define table CrimesMonitorados (dataHora string, endereco string, crime string, latitude string, longitude string, totalCount long); -- Count the incoming events @info(name = 'QueryTotalDeLinhas') from CargaInicialCrimesStream select count() as totalCount insert into TotalDeLinhasStream; -- Distrito 54000 @info(name = 'QueryCodigoCrime5400') from CargaInicialCrimesStream[(codigocrime == '5400')] select dataHora, endereco, crime, latitude, longitude,count() as totalCount insert into CrimesMonitorados; Para que este exemplo funcione adequadamente, você precisará dos seguintes passos: 1- Copiar o driver JDBC do MySQL ou seu banco desejado para a pasta lib do WSO2_SP_HOME, 2 – Configurar seus diretórios locais para que não fiquem como está no exemplo: file:/Users/edgar/Desktop/trash/poc-cliente/arquivos/IN , por favor, use o arquivo do seguinte link: https://github.com/edgars/SP/blob/master/SacramentocrimeJanuary2006.csv 3- Crie o Banco de Dados MySQL que está configurado no código fonte. 4 – Clique no botão executar do Stream Processor Editor 5 – Copie o arquivo para a pasta configurada de Source e em alguns milissegundos você terá os dados preenchidos no MySQL. Como referência você pode usar um repositório GitHub de Exemplo: https://github.com/edgars/SP Aqui o exemplo em execução: Até a próxima!