All posts by WSO2 Team

Enterprise Integrator 6.5.0 Focuses on Integration Developer Productivity

We are pleased to announce the release of WSO2 Enterprise Integrator 6.5.0. Our latest release includes unified integration and a data integration runtime (Integrator) as well as a micro integration runtime (Micro Integrator) and a comprehensive tooling distribution (Integration Studio) to support both runtimes.

This release aims at addressing developer productivity and cloud native integration requirements more comprehensively than ever. This has been one of the most anticipated WSO2 Enterprise Integrator releases, as it brings new product components and features specifically targeted at improving integration developers’ productivity as well as helping developers easily build and deploy container-native integration solutions. Following are the major highlights.

WSO2 Integration Studio

The integration team invested significant time and effort with the objective of improving the user experience and developer productivity of WSO2 Enterprise Integrator tooling. Some implementation targets for the new tooling included adding runtime validation of code, improving the look and feel of the tool palette and development canvas, improving the utilization of screen space, providing selection options for every possible configuration option, reducing the clicks and configuration steps, and adding Docker and WSO2 Integration Cloud support. In addition to the Integration Studio, we have improved the integration and micro integrator runtime with feature additions as well.

Some major capability enhancements are listed below:

  • New design for a superior graphical developer experience
  • Built-in micro runtime to support improved testing and debugging of integration artifacts
  • Capability to build Docker images from the development tool itself using runtime artifacts
  • Seamless experience to deploy integration artifacts into WSO2 Integration Cloud
  • Built-in project templates for faster initiation of new integration projects and artifacts
  • Artifact validation and error detection during the development stage of integration projects

WSO2 Micro Integrator

WSO2 Micro Integrator runtime is a lightweight product based on the same technology as that of WSO2 Integrator. Hence, artifacts developed for WSO2 Integrator (ESB) are fully compatible with WSO2 Micro Integrator. The reduced size and rapid startup time make this the ideal solution for enterprises that are planning to move into microservices and container deployable solutions. WSO2 Micro Integrator has been streamlined for developing composite microservices by orchestrating several services within a microservice implementation.

Key capabilities of WSO2 Micro Integrator runtime include:

  • Reduced startup time (< 5s)
  • Seamless deployment of integration artifacts from WSO2 Integration Studio
  • Reduced distribution size (< 150 MB)
  • Ability to generate micro integrator Docker images from WSO2 Integration Studio with integration artifacts
  • REST API to monitor and manage micro integrator runtime
  • CLI tool to inspect artifacts of micro integrator
  • Built-in monitoring capabilities with Prometheus, ELK, and WSO2 Integration Analytics

WSO2 Integrator Runtime

WSO2 Integrator runtime is the most common deployment environment used by a majority of WSO2 Integration platform customers. In this new release, we are introducing the following key capabilities to enhance integration development.

  • A new mediator named Property Group that enhances the usability by providing the ability to configure multiple properties inside a single mediator
  • Native JSON support for Iterate, Aggregate, and Enrich mediators
  • Message Processor improvements to handle poison messages
  • Enhanced REST support for Data Service JSON payloads
  • OData Support for MongoDB
  • Support to monitor statistics with Prometheus
  • Security fixes and bug fixes implemented since the previous release

Other Runtimes Packaged with WSO2 Enterprise Integrator

Bug fixes and security fixes that were done since the previous WSO2 Enterprise Integrator release are incorporated into WSO2 Business Process and WSO2 Message Broker runtimes.

Furthermore, in this release, we are announcing the deprecation of WSO2 Microservices for Java (MSF4J) runtime packaged within WSO2 Enterprise Integrator. The compelling reason for this is because we see more value added to users from the WSO2 MSF4J GitHub project and its artifacts since many microservice developers will use it as a dependency rather than a server runtime. Hence, we believe MSF4J is more useful for developers in its GitHub-based release cycle, so it won’t be packaged with WSO2 Enterprise Integrator in future releases.

To learn more about the latest release, features, and what it means for your experience, join our webinar on June 6, 2019.

We have also organized a webinar series with comprehensive discussions on WSO2 Integration Studio and how it can be used for integration efforts in your enterprise.

Schneider Electric Uses API-driven Integration for Innovative Energy Management

Schneider Electric is the market leader in the digital transformation of the energy management and automation industry, with an annual revenue of over 25 billion Euros and around 150,000 employees in more than 100 countries. Schneider Electric makes it possible for IoT-enabled solutions to seamlessly connect, collect, analyze, and act on data in real-time. In doing so, they deliver enhanced safety, efficiency, reliability, and sustainability to their customers. The company helps its customers do three main things: enable them to to manage their efficiency better by optimizing their processes and energy usage; manage their energy supply better by integrating local production and managing energy sourcing; and lastly, manage their grid better through digitalization.

Addressing Changing Energy Needs Through Technology

Schneider Electric is keenly aware of the changing energy and technology landscape and knows that it needs to stay ahead of these changes in order to remain competitive. As the demand for energy continues to increase, Schneider Electric’s approach to solving this issue is to find ways of generating energy more efficiently. Using digitization and IoT, the company is looking at being three times more efficient in its energy demand going forward.
In 2015, Schneider Electric decided to move from solution-driven integration, to a service oriented architecture (SOA). This simplified how customers could access and consume services in a more standardized way, and also shielded them from the complexity of the back-end of the SOA systems. The digital team at Schneider Electric decided to use APIs to support the new SOA, and sought API publishers that would be able to expose APIs easily, and manage them effectively.

Schneider Electric chose WSO2 API Manager because it fulfilled all of their requirements while being open source and flexible in that it could be deployed on-premises or in the cloud. WSO2 API Manager was the ideal choice as it addresses full API lifecycle management, monetization, and policy enforcement as well as extensibility and customization.

They also decided to replace their legacy integration solution with WSO2 Enterprise Integrator in order to further support their API real-time strategy. WSO2 Enterprise Integrator is a comprehensive integration solution that enables communication between various disparate applications. Instead of having Schneider Electric’s various applications communicate directly with each other in all their different formats, WSO2 Enterprise Integrator would enable all of the disparate applications to communicate with the the product which handles transforming and routing of messages to their appropriate destinations. According to Tristan Solanet, integration platform owner at Schneider Electric, using WSO2 Enterprise Integrator has helped bring consistency across the company.

Deployment From Europe to the US and China

Schneider Electric began by deploying WSO2 API Manager and WSO2 Enterprise Integrator in a data center in Europe. The company uses both internal gateways and external gateways, the former for internal network usage and the latter has a subset of APIs published on them. As its customer base in the US expanded, Schneider Electric’s digital team decided to deploy select API gateways in North America using an Amazon virtual private cloud. This addressed the problem of latency that US customers had experienced when they had to call gateways in Europe in order to access information and support. The next step in Schneider Electric’s deployment strategy was to address the increasing demand from China. Taking into consideration the specificities of the Chinese context, Schneider Electric deployed additional gateways in China. Among the challenges the company faced was in making the connection between China and Europe work. The connection between the US and Europe through the company’s internal network had been a lot smoother than the one between China and Europe. Ultimately, it was decided that a second key manager be configured in China, in addition to the original one in Europe.

Schneider Electric’s partnership with WSO2 has enabled the company to share functional intelligence with their customers using log value. Custom dashboards have also been developed to suit the company’s needs using WSO2’s analytics capabilities. Metrics are monitored on a real-time basis on these dashboards and can be filtered for geographic region, period of time, and customer’s perspective.

EcoStruxure: An IoT Enabled Interoperable Platform

Schneider Electric also created EcoStruxure, an IoT-enabled, plug-and-play, open, interoperable architecture and platform. It is used in homes, buildings, data centers, and infrastructure industries and delivers innovation at multiple levels from Connected Products to Edge Control, and Apps, Analytics and Services. EcoStruxure has 6 domains of expertise – Power, IT, Building, Machine, Plant, and Grid and uses standard communication protocols to simplify the collection of data from intelligent devices around a customer’s organization. The data is then analyzed either locally using Edge Control or remotely in the cloud to provide the customer with critical insights to improve their business.

Interoperability is a key feature of EcoStruxure, facilitating the deployment of a range of agnostic applications, analytics, and services for seamless enterprise integration. To put it simply, EcoStruxure bridges IT and IoT and allows customers to maximize the value of their business data. Data is transformed into actionable intelligence which in turns leads to wiser business decisions. To date, deployment of EcoStruxure exceeds 450,000 installations, with the support of 9,000 system integrators, and over a billion connected devices.

mySchneider App: Showcasing Digital Transformation at Schneider Electric

The redesigned mySchneider App is one of the flagships of Schneider Electric’s digital transformation initiative. Distributors, partners, Schneider employees and increasingly, end-users use it to connect to the company’s digital hub. Based almost entirely on APIs, mySchneider App allows access to information on order management, support, partnership management, and a comprehensive product catalog. The app has been translated into 36 languages and has approximately 30,000 unique users a month. Each user has the ability to customize their interface with the app based on their user profile and country.

The benefits of an API-led connectivity approach include building reusable assets that save the company time and money, creating infrastructure that is flexible and designed for change, along with enhanced visibility, compliance, and governance. Projects are now delivered faster and team productivity is greater as a result.

Schneider Electric believes that by implementing SOA with an API-led connectivity approach, facilitated by WSO2, they have been able to drive business agility, provide customers with better customer experiences, and retain their competitive advantage as the world leader in the digital transformation of energy management and automation.

Watch Tristan’s talk to learn more about Schneider Electric’s plans to prepare for the future.

New to the WSO2 Integration Agile platform? Learn more about our technology for API management and enterprise integration, all open source!

Eagle Technology Group: Applying Agile Software Development Principles to WSO2 Products

Eagle TG is an information technology engineering and integration company based in New Braunfels, Texas. Owned by the Native American Modoc Tribe of Miami, Oklahoma, Eagle TG offers enterprise architecture, virtualization, and data center solutions. They are also a WSO2 Preferred Partner and carry an average of 18+ years of technology expertise per employee.

At WSO2Con USA 2018, Neil Custer, a senior enterprise systems engineer at EagleTG explored their agile process-based configuration management tool for WSO2 products, which they deploy and maintain for one of its largest customers — the headquarters of a branch of the US Department of Defense (DoD). Eagle TG harnessed its considerable in-house software development expertise to develop this new product.

The goal of the new configuration management product is to maintain the consistency of configurable items that affect the performance, functional capabilities and physical attributes of WSO2 products while taking into account operational concerns.

Managing Configurations Before WSO2 Update Manager (WUM)

The release of the WSO2 Update Manager (WUM) in late 2016, had a considerable impact on the way EagleTG did its configuration management. WUM is a simple command line tool that connects to the WSO2 Update service, determines which updates are new and relevant, and downloads them.

Prior to the arrival of WUM, Eagle TG used a painstaking manual process to capture configuration management changes. Using open source tools, EagleTG would evaluate the new out-of-the-box WSO2 product against what they had previously configured. They would then manually update a text file with all of the items that were changing.

The Impact of WUM

So, how did the release of WUM lead to Eagle TG rethinking its configuration management protocols?

WUM meant Eagle TG could no longer use an update patch and simply overlay a couple of files, and perhaps change a parameter or two in a configuration file to enable the product to work in both their lab and in their customer’s environment. With WUM, Eagle TG’s developers needed to wipe out the entire implementation of that product instance with the existing configuration, and do a complete reinstall of the product from scratch. They then had to test the new products in multiple environments.

Doing this with about 6 different WSO2 products was challenging, to say the least. Especially since many of their DoD customers worked in isolated environments where access to the Internet was not a given, which meant that they couldn’t use the Puppet scripts provided by WSO2 to automate the configuration process.

The New and Improved Configuration Management System

Eagle TG’s software and systems engineers realized they would need to rethink their configuration management process if they were to keep providing topnotch services and operations support to their DoD customer. After consulting the team at WSO2 they realized that they needed to script everything they can. The answer lay in harnessing the rich and varied software background of its personnel and recasting configuration management as software development. In other words, Eagle TG’s team decided to treat the items it had to configure in order to deploy a product into specific functions as source-code.

A shared, central repository was created to hold the configurable items for each product. This allowed all team members an efficient way to access these configurable items, modify them, as needed, and to push them back into the repository where others could do the same. All changes are tracked centrally, making it easy for team members to see what has been changed, by whom, when and why. With a simple right click, the repository history is viewable, listing every change that has been made by any team member, along with the date and reason for the change.

Branching while testing is another attractive feature of the new configuration management process. For example, engineers are now able to make a side-line configuration change that might get implemented at a later time, by essentially parking it in the repository in a separate branch. Meanwhile, the main branch stays intact until it is time to merge with the secondary branch.

They were initially going to store the entire zip file of the product home folder in the repository but quickly realized this was not feasible because of the large file size and the multiple products and environments they had to store for. They kept the size of the repository manageable by keeping only the items it has customized in it. A separate folder within the repository for certificate key stores was also set up. Within each key stores folder, every WSO2 product has its own separate environment where the product is deployed.

A cron job was created to ensure updates run smoothly. Set up to run three times a week, this interrogates WUM for any updates to relevant WSO2 products it supports for its customer. If the answer is yes, the updates are automatically pulled to a staging area and an email alert is sent out to everyone on the team. Then the previous fully-configured product instance is backed up. Finally, the new product release is deployed using configuration items and fully tested for the required capabilities.

Because Eagle TG had a strong development background, they were able to follow Agile principles in their configuration as code approach. These include having a shared repository where developers can collaborate, using scripts for “self-installing”, and leveraging Jenkins for continuous integration. They have also adopted continuous delivery and are offering the product as a service on AWS cloud.

To help create their code-based configuration system, they built standardized WSO2 Node “Deployers” for each product in each environment. A deployer is a single consolidated, distributable, compressed file (.zip) that helps deploy the fully-configured updated products. It contains

  • The folder structure for enabling the fully-configured product deployment
  • A README.txt file outlining the basic environmental requirements for scripts
  • Script files for carrying out the product installation
  • Configurable items for the product
  • WSO2 Product Source

95% of the deployer consists of the WSO2 Product Source, which means they have a low overhead of just 5% that is actually stored in their repository.

The Advantages of Adopting Agile Principles for Product Updates

Although the process of converting their configuration management from manual to automatic through their Agile configuration as code approach has been a long journey, it has proved to be advantageous for Eagle TG in many aspects.

Versioning and traceability of changes: By storing configuration code in a version control system, EagleTG is now able to see who changed what, when and why, which makes it easy to analyze code differences between versions. It is also able to use branches to isolate changes under consideration without affecting the main source code.

Increased security: Running the product as a service allows it to run in its own space with a no log-on user in the Linux environment, making it a lot harder to hack into.

Overall, using software principles in configuration management has allowed EagleTG to streamline processes and take advantage of automation. Each discrete activity is self-documenting, making the process vastly superior to the previously employed manual process that was constantly on the verge of having outdated changes in configuration.

New Businesses Opportunities

This system was among the first to get a fully operational suite migrated to Eagle TG’s DoD client’s managed cloud platform. Eagle TG, together with their client’s engineering team, helped change the DoD branch’s internal processes which made it a lot easier for other programs to migrate to the cloud.

As a technology services provider, Eagle TG’s early success also led to more opportunities such as the one to provide the DoD branch with an updated identity and access management solution. They were also able to show the many advantages of open source software which is yet to be realized in many US Government agencies that opt to go for commercial proprietary software.

Watch Neil’s session at WSO2Con USA 2018 here.

Veridium Develops World-Class Biometric Federated Authenticator for WSO2 Identity Server

Founded in 2016, Veridium is a provider of identity and access management software with a focus on biometrics. As a company, Veridium has essentially one goal: to protect organizations by reducing or eliminating identity as a major threat. It does this by replacing vulnerable passwords and tokens with biometric authentication. In other words, Veridium replaces what you know (passwords) and what you have (tokens) with what you are – your biometrics.

The Ascendency of Biometrics

Biometrics are fast replacing passwords and tokens as the go-to authentication method used by organizations looking to increase security and reduce fraud. This strategy is backed by research. According to a recent report by Verizon, 63 percent of data breaches could have been stopped if an alternative to passwords had been in place.

Veridium is at the forefront of the development of innovative biometrics-based platforms and has a global customer base representing a wide range of sectors including financial services, healthcare, government, and law enforcement all of whom have put their trust in Veridium’s password-free, single-step, frictionless biometric login.

Veridium offers its customers three flagship products: VeridiumID, VeridiumAD and 4 Fingers TouchlessID. VeridiumID is a server-side protocol for biometric authentication that works with a user’s smartphone. It is easily installed within a customer’s network and can provide authentication to enterprise applications, websites and even doors. VeridiumAD is an enterprise-ready solution that increases the security and convenience of Microsoft Active Directory access by replacing passwords with biometric authentication. Finally, Veridium’s trademarked 4 Fingers TouchlessID is an innovative new biometric that captures four prints simultaneously, providing unprecedented levels of security.

John presenting at WSO2Con USA

Effortless Integration of Veridium’s Biometrics with WSO2 Identity Server

Knowing that WSO2 Identity Server accommodated several different biometric configurations including primary authentication, 2FA, MFA or escalated transactions, Veridium first approached WSO2 to see how WSO2 Identity Server could enhance Veridium’s product offerings. John Callahan, Veridium’s Chief Technology Officer, was astounded by the ease by which his company was able to integrate with WSO2 Identity Server. Calling the integration, “one of the simplest things,” John said it took a single developer less than a month to create and execute the federated authenticator.

The result of the integration is the Veridium Authenticator (VA), a biometric authenticator developed to work with WSO2 Identity Server. The VA is IEEE 2410-2017 certified and provides biometric SSO capabilities for most iOS and Android devices using facial, voice and its proprietary 4Fingers™ recognition. VA comes with a vanilla app that is available for iOS and Android. It can also be embedded in customers’ existing apps via their software development kit. By securely linking users and their devices to their digital identities, Veridium’s innovative software-only MFA solution allows for improved and enhanced authentication.

Speaking about the collaboration between Veridium and WSO2 Identity Server, John says that “they just go well together.” Because the two companies share a common vision for the future where single sign-on (SSO) is either through SAML or Open ID Connect (OIDC) and there is movement towards API development, it is no surprise to him that the companies’ product offerings are in perfect alignment.

User-centric Biometric Authentication

The VA offers two types of single sign-on: QR-code and push notification. Both sign-on methods are part of the Biometric Open Protocol Standard (BOPS), the only protocol that specifies the use of an end-to-end system for authentication. In QR mode, a time-sensitive QR code is generated which the user scans and is then prompted for one or more biometric authenticators on their mobile phone. In push mode, the service provider (SP) redirection includes identity information for sending a push notification to the user’s mobile phone where they are then asked for biometric authentication. Successful authentication (for both sign-on methods), results in authorization via SAML or OIDC redirection back to the SP.

Identity and access management (IAM) is an evolving space. Callahan predicts an ascendency in biometrics as, in his words, “devices get scarily good at knowing it is you, and your device and [that] you are the one authenticating.” As the volume and intensity of cyber attacks increases, developers have to be more innovative and agile in their approach to authentication in order to provide their customers with the best protection. The collaboration between Veridium and WSO2 Identity Server in the form of the Veridium Authenticator is a perfect example of the type of forward thinking, adaptive authentication that will characterize the identity landscape of the future.

Watch John’s presentation to learn more about how Veridium and WSO2 worked together.

Everything you need to know about WSO2 Identity Server is here.

NewWave Taps API-driven Innovations to Develop Federally Compliant Healthcare Microservices for Centers for Medicare and Medicaid Services

The Centers for Medicare and Medicaid Services (CMS) is a federal agency in the United States Department of Health and Human Services that administers the Medicare program and works with state governments to administer Medicaid. It is the single largest payer for healthcare in the United States and provides services to over 130 million Medicare and Medicaid beneficiaries. Creating a stream of relevant and timely applications and products to service their significant customer base, while ensuring compliance with federal IT regulations, poses enormous challenges to CMS.

Traditionally, it takes several hundreds of hours of manual coding to develop an application that meets the federal government’s 3-zone architecture requirement. The process is so laborious and time consuming that the solution being developed often risks being obsolete before it has even deployed. Fortunately, CMS’ healthcare technology partner, NewWave, has devised an API-based solution that develops and deploys federally compliant healthcare microservices at hyper speed.

NewWave’s mission is to work with their clients to modernize their businesses and empower them to use technology in new ways. Donghwa Kim, director of application engineering at NewWave, says, “When we solve problems, we constantly remind ourselves of three things – people, processes, and tools. And of all three, people always comes first.” In keeping with this mission, the challenge of technological obsolescence at CMS was a natural fit for the company.

Donghwa discussing this solution at WSO2Con USA

Powered by Flexible APIs

Using API-driven innovations, NewWave developed SmartApp, a powerful development accelerator that streamlines application start-up and delivery at CMS. NewWave compared several vendors and settled on the open source WSO2 API Manager, as it had all the features they required for the new solution, which above-all needed to be flexible. WSO2 API Manager allows customization and extensibility, in addition to supporting full API lifecycle management. It’s designed to fit into microservices architectures. “Also, WSO2 provides great support,” says Donghwa.

Based on JHipster, a Yeoman generator for Sprint Boot applications, SmartApp uses best-in-breed components like Spring Boot, Spring Cloud Components, MongoDB, MySQL, HTML5, Angular JS, React, Bootstrap, and OAuth to generate responsive and cloud-ready Java applications. This saves developers hundreds of hours in manual coding. Compared to traditional application development which can take several sprints and up to fifteen weeks to complete, SmartApp compresses project set up/plumbing, basic CRUD Domain implementation and custom development into 2-3 weeks.

The beauty of SmartApp is its simplicity. The user selects an application’s desired features from a list of menu items which then generates a secure, unit-tested, and standardized project structure specific to the user’s specifications. A fully functional application can be built in minutes, with no coding required. Features include auto-populated project libraries, architectures and database back-ends. SmartApp is also available as a Vagrant-ready Docker image.

The infrastructure supporting SmartApp is called SPADE (Self-Provisioning And Dashboard Environment). SPADE is an open-source DevSecOps platform-as-a-service (PaaS) that deploys and manages SmartApp microservices. It supports modern containerized deployments while complying with the government’s three-zone architecture. This infrastructure is web-based, cloud-hosted, API-driven, vendor-agnostic, open-source, hosted on-premise, and has dashboard functionality. SPADE also enables SmartAPP users to develop, test, deploy, and maintain microservices.

Better, Faster Healthcare Apps

Both SmartApp and SPADE make up the complete solution by which CMS can develop, deploy, and manage federally compliant, secure healthcare applications in a matter of minutes. CMS is now able to automate the long-drawn out process of application development, and by reducing the time spent on time-consuming tasks, they can focus more on delivering value to their customers.

Learn more about SmartApp and SPADE in this video:

Find out more about WSO2 API Manager. We were named as a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report.