Tag Archives: API Management

WSO2 API Microgateway 3.0 is Released

The WSO2 API Manager team recently released version 3.0 of its WSO2 API Microgateway. This blog takes a closer look at the key attributes of a microgateway, changes in the new release, new features available, use cases of microgateway, and what to expect in the future from WSO2 API Microgateway.

Key Attributes

Cloud native

  • Comes as lightweight containers (fast boot-up times, low memory footprint, and low distribution size
  • Designed in a stateless manner
  • Isolated from underlying system/OS
  • Can be deployed on self-service, elastic, and cloud infrastructure
  • Agile DevOps and CI/CD
  • Automated capabilities for deployment
  • Developed with frameworks suited for cloud (based on Ballerina)

Developer-centric and enables the following:

  • Creation of microservices
  • Define the open API definition for microservices
  • Initiate the microgateway project from the open API definition
  • Build the microgateway project
  • Locally test the service exposed via microgateway

Decentralized

  • Decentralized per API gateway, with a dedicated gateway for each service
  • Contains a private jet gateway, with a dedicated gateway for clusters of same microservices
  • Contains sidecar gateways, gateways that are deployed in the same node with microservices
  • A gateway for subset of APIs only, to expose several services/APIs using a single API

Immutability

  • Rebuild required if API changes, new resource added
  • Finalize open API definitions prior to deploying
  • Immutable containers
  • Immutable runtime artifacts for non containerized runtimes

Scalability

  • Serves traffic independently (acts without key manager with self contained tokens, local rate limiting capabilities, and stores analytics data)
  • Independent scaling sans the need to scale other components
  • Can be scaled with microservices when used as private jet or side car mode
  • Inbuilt support for container orchestration tools to manage scaling

What Has Changed in the New Release?

1. Introduction of a developer-first approach

The 2.x series of WSO2 API Microgateway depended on the WSO2 API Manager publisher portal when designing APIs to be exposed via the microgateway. WSO2 API Microgateway 3.0 takes a developer-first approach. The API developer who is designing APIs and defining the interfaces of the APIs is now able to develop a microgateway based on the interface of his/her APIs.

In this new version, the microgateway toolkit will accept a valid open API definition of developer services or microservices, with WSO2 specific open API extensions. Then the toolkit will translate this open API definition into an executable format which is accepted by the microgateway runtime component. Once the API developer adds WSO2 specific open API extensions to the open API definition of the microservices, microgateway will add QoS like authentication, authorization, rate limiting, transformations, analytics, etc.

2. Separation of toolkit and runtime into two distributions

The 2.x series of WSO2 API Microgateway had a single distribution where both toolkit and runtime resided. The toolkit created runtime distribution for the user, containing all the APIs which the user had to add to the project. This has changed in WSO2 API Microgateway 3.0, which has two separate distributions, one for the toolkit and the other for the runtime. I’ve explained this in detail in the section below.

  • Microgateway toolkit

Microgateway toolkit is a command line tool designed for API developers to create micro gateway projects by adding open API definitions. This cli creates a project structure for the API developer once the project is initiated. If the API developer has a single open API definition or multiple open API definitions, these can be copied to this newly created project. Once the project is finalized, the cli can be used to build this project which will create an executable file that is accepted by the microgateway runtime.

  • Microgateway runtime

This is the component which actually serves the API requests. Runtime component cannot be run without providing the output created by the toolkit. The runtime component can be dowloaded as a zip file or as a docker image. When using a zip file, the executable file created by this toolkit should be provided as an input argument for the startup scripts of the runtime. When using the docker image, the executable file should be mounted into the docker container.

You can refer to the quick start guide to expose your first API with microgateway in a few steps here:

New Features

Define per resource endpoints

In the microservices world, developers might want to expose their microservices as APIs to the outside world. The API developer will define an interface of these services using open API definitions. Several microservices will be contained in a single open API definition which defines a single API for a particular use case (for example, online store). So when defining the microservices in the open API definition as REST resources, users should be able to define different back ends based on the resource.

Open API extension (“x-wso2-production-endpoints”, “x-wso2-sandbox-endpoints”) introduced by WSO2 enables users to define back end services at the resource level. This way, users can logically collect his microservices into a single API and these can be exposed via the microgateway. Refer to the documentation here.

HTTP2 support

WSO2 API Microgateway is upgraded to support HTTP/2 together with HTTP/1.1 as the incoming and outgoing transport protocol. WSO2 API Microgateway is able to process requests faster and simpler with HTTP/2 enablement. For more information on HTTP/2 and its benefits, refer to the HTTP/2 homepage. It supports both client -> gateway and gateway -> back end communication using http2. Refer to the documentation here.

Mutual SSL based authentication

Microgateway is enabled to serve requests from trusted clients without providing OAuth2 tokens. After sharing the certificates of the trusted client partners are, requests from these trusted certificates will be served. Microgateway can impose the mutual ssl as required or as optional. If required, then requests from only trusted clients will be served, and if it is optional, the trusted client will be served without OAuth2 tokens and untrusted clients (the client who has not shared their public certificates) will need a valid OAuth2 token.

Config based basic authentication support

Microgateway allows users to invoke APIs using their basic authentication credentials, apart from OAuth2 tokens as well. The basic authentication support can be defined per API using the open API definition. Microgateway supports the open API security schemes in order to define the basic authentication for the APIs. Refer to the documentation here.

Response and request schema validation

Microgateway can intercept responses and requests, and validate these against the models defined in the open API definition. Microgateway stores the open API definitions added to the microgateway project and cross check the request and response payloads against the schema models defined in the open API definitions. Refer to the documentation here.

Service discovery with ETCD

One challenge we face with microservices architecture is that the services are dynamic. Services do not have a fixed connection url, it changes with time, and are mostly maintained in a ETCD server as a key value pair. Since microgateway is immutable, it should be able to route traffic to these dynamics endpoints without having to rebuild. Connecting with the ETCD server and resolving dynamic micro services urls in real time are both supported by the microgateway. Refer to the documentation here.

Global throttling

Up to date, the microgateway was able to perform the rate limiting locally using memory. Each gateway maintained its own set of counters and throttling decision were taken in an independent manner. With this new release, the microgateway enables the publication of throttle events to the WSO2 API Manager traffic manager component, and take decisions based on traffic manger subscriptions.

Integration with third party key managers

By default all the APIs in the microgateway are OAuth2 protected. Hence API consumers require a valid OAuth2 token in order to invoke the APIs. Microgateway supports self contained jwt OAuth2 access tokens from any trusted key manager. In order to validate the jwt token sent by the key manager, microgateway requires the public certificate of the key manager in its trust store.

Request and response transformations

Microgateway now has the first class support to plugin external functions written in Ballerina, as interceptors during the request in-flow and the response out-flow. API developers can manipulate request/response headers, body, etc. prior to sending to the back end or responding to the client.

API/Resource level throttling

Earlier versions of microgateway only supported application and subscription level throttling. With this new version onwards, API developers can define new policies in the policy.yaml file of their project and attach them to the APIs using the open API extensions.

JWT revocation

Microgateway self validates the jwt tokens issued by the trusted key manager. It validates the JWT tokens signature using the public certificate of the key manager which signed the JWT. Due to this self validation mechanism microgateway will accept revoked tokens until they are get expired. So there should be a mechanism to notify microgateway about revoked jwt tokens. There are two mechanisms supported by microgateway:

  • Persistant notification via ETCD server

Microgateway can connect an ETCD server during startup and fetch all revoked tokens from the ETCD server. In the key manager component which issues and revokes tokens, there should be an extension point to add the revoked token into an ETCD server. When revoked tokens are added with their validity period, the ETCD server automatically removes them upon the expiration, hence mitigating the aggregation of revoked tokens on the ETCD server.

  • Real time notification via JMS

Microgateway can be configured to subscribe to a JMS topic to fetch details about tokens that are revoked during the runtime. This way, microgateway is notified about the tokens that get revoked after the server startup. In the key manager component, there should be an extension point to add the revoked token to the JMS topic.

Microgateway Deployment Use Cases

1.Monolithic centralized deployments

2.Use in microservices architecture as a private jet or sidecar gateway

3.Exposure point for the microservices as APIs in service mesh

What to Expect in the Near Future

  • GRPC support
  • Observability with Prometheus and Grafana
  • Cookie based authentication for SPAs
  • CI/CD with APIM import export tool and publish to WSO2 API Manager
  • Improved toolkit to fetch open API definitions from any URL
  • K8s CRDs with enhanced dev focussed design

Learn more about WSO2 API Microgateway here.

Accessibility Requirements in WSO2 API Management

Accessibility standards in the world of web and internet are quite important as it allows people to access web resources without any difficulty, irrespective of their disabilities. There are many standards put forward to help developers implement accessibility into web-based resources. Some of these are:

  • Section 508 of the Rehabilitation Act of 1973
  • W3C Web Content Accessibility Guidelines (WCAG) 2.0 level A
  • W3C Web Content Accessibility Guidelines (WCAG) 1.0
  • W3C Authoring Tools Accessibility Guidelines (ATAG 1.0)

As a middleware vendor we’ve often been asked by Government customers and Federal Agencies in the United States, Europe and other parts of the world, if we are compliant with Section 508, WCAG 1.0/2.0, and ATAG 1.0 to enable a wider audience to use our software. These standards describe the desired accessibility required from information technology based services and products to make them accessible to differently-abled people.

A small explanation for those who can’t relate directly; sometimes you may ask if our software doesn’t touch end users, then why bother? Our software is predominantly catered towards developers and architects and they are the people who engage with our software on a technical level. So for instance, if you’re catering to a colorblind developer, having software complying to Section 508 ensures their disability is addressed.

What Do These Standards Say?

Section 508 states that it “requires Federal Agencies to make their ‘electronic and information technology’ accessible to people with disabilities”. However, this not only applies to Federal Agencies, but also impacts any company that conducts business with a Federal Agency like private contractors, and financial, healthcare, and legal organizations among others.

Section 508 was made part of the Rehabilitation Act of 1973 in 1998. It was revised in 2017 to include requirements for information and communication technology (ICT) in the federal sector. The guidelines were also updated to extend to the telecommunications sector, hence Section 508 was reorganized (along with Section 255) to better align with and reflect recent communication technology innovations.

Similarly, WCAG 1.0/ 2.0 documentation defines how to make ‘web content’ more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Web “content” generally refers to the information on a web page or web application, including:

  • Natural information such as text, images, and sounds
  • Code or markup that defines structure and presentation

It is primarily intended for web content developers (page authors, site designers, etc.), web authoring tool developers, web accessibility evaluation tool developers and others who want or need a standard for web accessibility, including for mobile accessibility.

The WCAG 1.0 is organized around guidelines that have checkpoints while 2.0 is organized around four design principles of web accessibility. The basis of determining conformance of the former are the checkpoints and the latter are the success criteria.

Overall, these different accessibility standards apply in different circumstances but are designed to complement each other. Often, these standards improve over time which is why you come across different versions.

In the open source community, we are as open to individual differences as we are to heterogeneous technologies. WSO2 API Manager, being one of the key products of the WSO2 Integration Agile Platform, has widespread deployments and has also been adopted by Governments and federal organizations. Hence, we designed WSO2 API Manager to be compliant with Section 508 so that it is accessible to all sorts of intended users regardless of their differences. The following section presents how each of the guidelines has been achieved in the product.

Section 508 Compliance in WSO2 API Manager

I have presented the basic guidelines from Section 508 and indicated how WSO2 API Manager has been designed to achieve this particular requirement. In this guideline, only the applicable parts have been discussed.

Addressing the requirements of Subpart B:

Section 508 Technical Standard WSO2 API Manager Achievement (with a few examples)
Software applications and operating systems
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. WSO2 API Manager can be started up and executed using the command line (Windows)/ terminal (Mac), where the keyboard is the primary tool used to operate the application. Once started up, the API manager functions can be performed using the keyboard. For instance, the API design and implementation can be executed using the keyboard where you use the tab to move to each field where you want to specify API metadata. This is demonstrated in the sample API provided at the first-time launch of the product.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. WSO2 API Manager is a web-based application. It does not interfere, disable or disrupt the operation of other applications or operating system on which it is running and vice versa.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

Yes, on the startup screen, a walk-through to create an API is presented for first-time users. This shows the current focus and guides the user to the next item after completion of each step.

For experienced users, the tab key can be used to identify the current focus and navigate through the interfaces. When a text field is focused, it shows the cursor in the particular textbox and the textbox is outlined in blue. For dropdowns, the list of options is expanded and shown to the user.

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. Yes, this is made available where necessary.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance. Yes, the images used for APIs and their meanings are often consistent. The first letter of the API name is reflected in the image if it is not uploaded separately.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. Yes, textual information is provided through operating system functions. As a minimum, we provide:

  • Short text labels
  • Sample text that reflects the type of input required
  • Text input location identified using the cursor
  • Simple and consistent text attributes for titles, labels, validations, and descriptions across all WSO2 API Manager components
(g) Applications shall not override user selected contrast and color selections and other individual display attributes. WSO2 API Manager shows the default screens, however only affected by the contrast and color selections of the user’s screen/ monitor’s configuration.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. Not applicable as animations are not part of WSO2 API Manager.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Information is conveyed in different means, such as text, color, images and other items. For instance, the action to start creating an API (on the Publisher) is indicated as a rectangular button with text that says ‘Start Creating’.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. Not applicable as adjusting color and contrast settings are not part of WSO2 API Manager.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. Not applicable as flashing and blinking text, objects or other elements are not used in WSO2 API Manager.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. Screen magnification is available as the interface can be zoomed in and out as preferred. Assistive technology is not built into the WSO2 API Manager however, it can work with such tools available with the OS/browser to enhance such capabilities.

The above table is based on WSO2 API Manager v2.6.0. If you do have any feedback, please email us at bizdev@wso2.com

Lindex: Innovating with APIs in the Fashion Retail Industry

Fashion is a dynamic industry and any fashion retail business needs to be as agile as possible, particularly in the present era of e-commerce and instant customer gratification. This is a reality that the Scandinavian based fashion chain Lindex is all too aware of, having been around since the 1950s. Currently Lindex has 470 stores in Scandinavia, Central Europe, Baltic states, Middle East, and the UK, with an employee base of over 5,000. Their business is underscored by sustainability, as 55% of their clothing is made from sustainable materials. Lindex decided to enhance their digital services by exposing APIs over their existing monolithic architecture. This enabled them to build applications that improved user experiences for both customers and employees.

Move With The Times

15 years ago, Lindex began their first foray into e-commerce. This was very much an experimental project, where a team was tasked with designing a platform and more importantly, monitoring customer responses to such a platform. Lindex started with a monolithic architecture which had worked satisfactorily for a decade. But there was a snag – they had accumulated a lot of technical debt over the years and moreover, security models had changed. It was time to try something new. Lindex considered open source, as they understood that it provides greater extensibility and flexibility when building a solution.

That something new was the development of a customer loyalty app – their change agent. Lindex wanted an omni-channel app which gave users a hassle free experience, with product information, prices, and promotions being shared between the app, website, and stores. They were clear that they did not want to integrate this new system with the existing monolith and furthermore, they also knew that a new team was needed.

The new platform consisted of customer loyalty app, the new ‘My Store’ app, and other customer experience solutions on the top layer, all to be exposed via an API layer. Once Lindex had completed the implementation of this first set of APIs it immediately became apparent that different levels of complexity within the backend systems would require different versioning of each of the created API’s moving forward as each monolithic application was adapted to become digital. It was recognized that the team would require some form of management for the API framework and a business case was undertaken to assess a number of API Manager systems which complied with industry standards and more importantly, would work seamlessly with their existing customer repository. Lindex also had a preference for a security solution that was able to work seamlessly with their existing customer repository. These requirements, along with the need for an open source solution, led them to WSO2 API Manager (which addresses API management, development, and integration). They also chose WSO2 Identity Server, which is optimized for identity federation and single-sign.

Multiple Teams for Multiple Customer Experiences

While the app team was developing the new application, Lindex’s team responsible for their existing monolithic architecture was busy refactoring the code in order to expose functionality in the customer shopping experience – i.e. features like shopping cart, wish list, pricing, promotions, and order details. They also had other development teams working on other areas of customer experience simultaneously. The ‘My Store’ program was upgraded, they were able to create a ‘My Stock’ app and a ‘My Customer’ app (when in-store personnel were acting on behalf of customers). During the complex process of setting up multiple levels of authentication across different user groups, Lindex found that WSO2 Identity Server provided the authentication capabilities needed for these apps. In total, there were 5 teams working on enhancing customer experience and there are plans for expansion.

Like their initial venture to e-commerce, this project has also been an experimental one for Lindex, to understand what works best and adds business value. They now believe that a gradual replacement of backend functionality is what works for them. “Thanks to WSO2 and the open source model, this has been a breeze. It’s been risk-free for us. The middleware has been rock solid from the get-go really,” says Johan Edling, an enterprise IT architect at Lindex.

Some Lessons Learnt Along the Way

Lindex gained some valuable insights when they worked on this project, and if they were to return to square one, their key advice to others starting this journey would be as follows:

  • Set up API statistics right at the start of the project, even if it looks expensive at first glance. Failing to do so is not the best course of action.
  • Time is always important – time must not only be allocated to the development of API resources, but to changes you anticipate as well.
  • Perform automatic testing of API resources and ensure that teams working on the project have the relevant API development skills are things to consider.
  • Document error handling guidelines.

With the new API design in place, Lindex now offers a modern shopping experience for their customers.

For more details, watch Johan’s talk.

WSO2 was named a Leader in The Forrester Wave ™: API Management Solutions, Q4 2018 report. Check it out here and learn about WSO2 Identity Server here.

Why We Make Our Product Roadmaps Public

“Can you please share your roadmap?”

“What are your plans to engineer feature xxx?”

“Great product, but does your vision match ours?”

We get these questions all the time, from customers, partners, and analysts.

As the leading open source API integration company, it seemed antithetical to be open and transparent about our code, financials, and priorities, but not about our actual product roadmaps.

So we’ve now opened-up our product and solution visions and roadmaps for each of our integration-related products, all part of our Integration Agile platform:

Why would we do this?

There are a number of reasons we chose to take this bold step – a step that most high-tech companies shun as competitively risky, and thus guard their plans with absurd paranoia.

  • Public roadmaps are consistent with our open source community
  • We trust our community to work with us, and they can only do so if they know our plans. That way they are always involved in the technology and will be able to best deliver meaningful new features, contributions, and roadmap suggestions.

  • Public roadmaps signal our transparency
  • Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know we’re pulling no punches with our direction. It’s also consistent with our no-lock-in approach… and that means there’s no lock-in to our roadmap either. With a transparent set of roadmaps, our technology partners know what to expect… and have a proactive vehicle to comment on the direction.

  • Public roadmaps are good for our customers’ trust
  • When our customers buy-in to our integration platform, they’re putting technology direction on the line. They want to know if we’ll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, we’re “opening the kimono” and boldly stating direction.

  • Public roadmaps show our pride, confidence, and vision
  • WSO2’s technology has been evolving for over 13 years. Over 350 engineers currently work on technologies like API management, identity management, ESBs, enterprise integration, and related integration architectures. This is one way of showing-off our vision and capabilities.

  • Public roadmaps are good for business
  • In sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “Yup, we’re working on supporting it” is always received with skepticism. Our public roadmaps put our money where our mouth is… either it’s on the roadmap, or it’s not. Or, we work with our partners to change the roadmap… for everyone else to see.

Next, what’s on our Roadmap roadmap?

This is the first of many more steps we’ll be taking toward increased openness and transparency. But the other critical component is your feedback. So if you have thoughts about our roadmap- positive or negative – there are many avenues you can use, including our Contact Us button – and include your feedback.

Medical Device Integration for Better Decision Making in the Healthcare Industry: A Case Study From Engineering Ingegneria Informatica S.p.A

Medical devices that communicate with one another…sounds futuristic (or like something from a science fiction movie or novel), but it’s happening today. Engineering Ingegneria Informatica S.p.A, an Italian based software solutions provider, developed a Medical Device Integration (MDI) solution that enables devices to communicate securely, efficiently, and intelligently, enhancing patient care and monitoring capabilities. And to create their solution, they rely on the entire WSO2 Integration Agile platform.

Medical Device Integration with the WSO2 Integration Agile Platform

MDI comes with its distinctive set of challenges. Communication between medical devices is complex, hence each device needs a standard and secure communication protocol based on multiple channels. Then there’s the issue of processing thousands of events. A large hospital has a multitude of patient data, generated from thousands of sources. Engineering Ingegneria Informatica S.p.A needed to analyze these events and view patient data in the form of trend lines on customized dashboards. Also needed were monitoring dashboards displaying data regarding the status of devices.

The architecture behind MDI makes use of WSO2 Identity Server, WSO2 API Manager, WSO2 Enterprise Integrator, and WSO2 Stream Processor, along with WSO2’s IoT platform (now developed and supported by Entgra). To begin with, WSO2 Identity Server – a holistic identity and access management product – makes this solution and communication between components secure by using protocols such as OAuth2 with JWT tokens. This identity platform also generates tokens to access WSO2 API Manager.

WSO2 Enterprise Integrator facilitates all the communications in this solution and comes with integration runtimes, message brokering, and business process modeling capabilities. This agile integration platform is responsible for communicating with external modules, between the various devices and the central MDI system, and with Terminology Services to perform compensation and transformation of incoming/outgoing streams. Furthermore, WSO2 Enterprise Integrator provides technology for this solution to generate alerts or notifications from MDI to application solutions.

WSO2 Stream Processor – a lightweight stream processing platform – analyzes clinical messages from the device driver in real-time. Technical and clinical information has been divided into different complex event processing (CEP) flows. This makes it possible to manage technical warnings or CEP feeds of clinical data, and the machine learning component acquires and refines classified algorithms to help predict critical situations. WSO2 Stream Processor, in particular, has helped Engineering Ingegneria Informatica S.p.A to address the challenges of processing and analyzing the many events and the need for a customized dashboard.

The IoT capabilities are used to develop device drivers with installation packages. Each device driver has a health module that transmits technical information (which ranges from data like the heartbeat to the status of components). Each driver is also able to transform specific device protocols (such as RS232, HL7, etc.) into an encrypted generic platform message, thereby eliminating the need for MDI to identify each protocol.

The Benefits for Patients in Real Life

There’s quite a complex architecture in operation, so how does it function in a real-life situation? Marco Mastroianni, a software architect at Engineering Ingegneria Informatica S.p.A, explains how their solution applies to an Intensive Care Unit (ICU). Patients in the ICU are dependent on monitoring and life-sustaining devices where the use of information from combined (or integrated) data sources play a critical role in predicting a patient’s condition. Underpinning everything is time and the speed of communication. In such environments, monitoring capabilities and notification mechanisms come to the foreground. The data generated by these devices appear in the form of signals which is of value to signal processing techniques. Therefore, this process helps to both monitor patients and design algorithms that are used to implement patient alarms.

Patient monitoring is not limited to hospital premises – the MDI solution helps to monitor them in their homes too. Monitoring is dependent on communication between devices, how they’re managed, and how patient data is received by medical professionals. An MDI solution such as this reduces the probability of errors (particularly human errors) – greatly supporting the wellbeing of patients and the quality and speed of decision making.

You can listen to Marco’s presentation for more details on the MDI solution built by Engineering Ingegneria Informatica S.p.A.

WSO2 offers an open source integrated platform for digitally driven organizations who want to become integration agile. Everything you need to know is here.

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!

Delighting Customers with an API First Approach at Proximus

Proximus, the largest telecommunications provider in Belgium, has been around since 1930. At present, Proximus provides internet, TV, telephone, and network-based ICT services. Their brand portfolio includes Scarlet, NBRACE, tango, ClearMedia, TeleSign, Davinsi Labs, telindus, BEMOBILE, and bics. Collectively, these brands have presence beyond Europe – in the Middle East, Americas, Africa, and APAC.

APIs Are Great – Again

Proximus has 2,000 to 3,000 applicators in the entire organization, integrating internally and externally with partners, competitors, and customers. Most importantly, these integrations have to be managed. The scenario that would result in not doing so is endless difficulty and inconvenience. A decade ago, Proximus designed their architecture for managing commodity services such as authentication, authorization, routing, and monitoring. So far, so good.

Change came in the form of agile business transformation. By becoming more agile, they were looking to deliver services faster, of better quality, and at lower cost. Proximus achieved business agility by building functionality shaped building blocks that are re-usable and loosely coupled. These building blocks are used to provide their digital solutions, all at lower costs and higher quality. Agile transformation has been made possible by WSO2 API Manager, which supports any spectrum of the API lifecycle, and WSO2 Identity Server, a holistic identity and access management (IAM) solution. Both are open source.

“We had to rethink what we were doing and essentially look at making APIs great again,” says Sean Kelly, an enterprise architect at Proximus. They’ve already worked with APIs, mainly to offer services – but agile transformation means approaching everything differently. This began by bringing together architectural domains that are well-defined and separate. For one, there was a functional domain which operated on specific blocks of functionalities (such as customer address management). Then there was an important security domain that is responsible concerns such as GDPR compliance. The application domain handles patching, upgrading, migrations, and such. And finally, the infrastructure domain is needed for deployment.

Functional Domain in Detail

Sean explains the new approach at Proximus by using the functional domain as an example. The team at Proximus documented all business capabilities and they first defined the characteristics of a capability. For starters, a capability must be a subject matter expert i.e. a customer address management capability is the owner and master of this specific block of data. This capability is the single source of data for the particular function, with a specific team attached to it. Furthermore, business capabilities are also mutually exclusive – unique, but independent, self-contained, and well defined.

The implementation of this new API-first approach happened in a very structured manner. APIs at Proximus are lightweight and powerful, with simpler life cycles and release cycles. Product teams were empowered and the API management platform is more agile. Although the API management platform is a self-service one, there are certain controls in place. Collaboration plays a big role too. Given the number of architectural domains, collaboration could be a challenge and it required a shift in mindset across the organization.

Organizational Change from Service Orientation (SOA) to Resource-Based Architecture

Proximus adopted the Bimodal practice to deal with organizational change. Introduced by Gartner, Bimodal refers to the strategy of coping with change and it’s comprised of two modes (modes 1 and 2). As per Gartner’s definition, these 2 modes are cycles, and not separate groups or departments in the company. “Mode 1 is the marathon runner, that is, it refers to APIs that perform core business functions. Mode 2 is more like a sprinter. These are the APIs that respond to the environment, are closer to your customers, more agile, and typically more disruptive,” Sean explains. At Proximus, mode 1 is applied to internal APIs and existing SOA services. Mode 2 is applied to external APIs and this is where they publish their digital products, with a strong focus on security.

Apart from the Bimodal practice, Proximus has also adopted several principles. There’s no domain dumping model at Proximus, and they use concepts that are known and understood within the organization. They design for loose coupling, as vendor-neutral APIs are preferred and it allows them to change one component to another with minimal impact. Proximus also use industry standards such as O-Auth2, XACML, SID, JWTE, etc. Another is the use of smart endpoints and dumb pipes, which is to avoid business logic in a centralized middleware. Security is coded, rather than configured. As such, the code is typically only written once and then validated by security, making it easier to manage this process as well. Proximus also do not use the latest version of a particular technology offered – they prefer to trail behind the bleeding edge, as they’re on the lookout for the first round of patches and use the functionality with greater confidence at a later time. And finally, Proximus only builds components or purchases software that is cloud native.

Delighting Customers

The team at Proximus are satisfied with their API first approach and the resulting API marketplace. “We’re focusing on delighting our customers, delivering value, and doing all this at a lower cost. We use WSO2 to do what they do best. For us, WSO2 is an API management platform and we let them handle that while we focus on the business,” says Sean. As with any innovative business, there are more changes afoot at Proximus and they’re looking to take WSO2 along with them as their business evolves.

Watch Sean’s presentation for more information about the transformation at Proximus.

Check out our product pages for WSO2 API Manager and WSO2 Identity Server to find out how you can use these products in your enterprise.

The API-driven World: WSO2 Integration Summit is Coming to a City Near You!

Starting in March, the WSO2 team, our partners, and I will be hitting the road for the 2019 WSO2 Integration Summit world tour. The 2018 Summit series was our biggest yet, featuring customer success stories from enterprises that have used our technology to fulfill digital transformation strategies and create innovative experiences for their customers. Refusing to sit back and relax, we’re making the 2019 Summits even better. We will be visiting at least 24 cities in 20 countries and 6 continents to show how you can achieve API-driven integration agility.

We are scaling our efforts by collaborating with our partners on each of our summits. We started this year by inviting all our partners for WSO2 Sales Bootcamp. For the first time ever, we had partners from all around the world participating in the 2019 kickoff alongside our own teams. Insights were gained, strategies were discussed, plans were made, and the summit tour was born. Because of our partners’ global presence, we are able to reach six of the seven continents (the penguins in Antarctica didn’t show much interest in WSO2!).

Group picture from Sales Bootcamp 2019

Summit Theme: The API-driven World

APIs are touching every facet of our society and the underlying trends are going to generate nearly 1 billion APIs in the coming years. All digital transformation depend on APIs and integration technologies underpin their evolution. Each WSO2 Summit will comprise a full day of vision and practical use cases focused on integrating a world of disaggregated APIs, cloud services, and data. We will discuss topics such as transforming integration projects from waterfall to agile, by moving from the centralized model to a decentralized architecture and methodology; combining enterprise integration, API management, and identity solutions; writing microservices that integrate APIs using Ballerina; and using open source technology for greater customization and flexibility. The summits will also feature guest speakers from digital-native organizations who will talk candidly about their API-driven transformations.

We’ll show you how to navigate current trends and use them to deliver innovation and new opportunities. Listen to visionary keynotes by WSO2 senior leadership, meet and network with industry experts and others who are striving to solve similar enterprise problems, and learn how integration agility could help with maximizing revenue and productivity. Join our interactive discussions to empower your team and stay one step ahead of evolving business needs.

While the the underlying themes of each summit remains the same, the agenda differs from location to location. The interactive sessions are tailored to each region, helping you gain relevant information on what matters to you and your enterprise. From open banking to retail and healthcare, our plan is to cover it all.

WSO2 Integration Summit 2019 global locations

If you are a customer or a community user and would like to speak at one of the summits, please let us know, as we have a limited number of spots still available. Get in touch with us at cfp@wso2.com.

I look forward to seeing you soon.

Space is limited, so save your spot today.

Follow @wso2 on Twitter to get the latest updates. We are using the #WSO2Summit hashtag.

Macmillan Learning and Ribbonfish: Solving Diverse Integration Needs to Help Students and Instructors Better

Macmillan Learning is a leader in the education publishing and EdTech industries, with a target market of over 9,000 colleges and 50,000 high schools in USA and Canada. Their partnerships with many of the world’s best researchers, educators, and administrators, as well as their emphasis on top quality content drive their business. Macmillan Learning teamed up with Ribbonfish, who specializes in offering service solutions to the media and publishing industries, to answer the changing needs of the education industry – helping both students and instructors improve their outcomes.

A Technology Strategy for an Evolving Industry

Macmillan Learning observed how the education industry has been evolving over the years and realized that they need a strategy to answer to the rapid developments that are taking place in this industry. Key among their goals was responding to market needs faster and providing students with interactive digital solutions to support their education.

However, the education industry is a seasonal one and Macmillan Learning wanted to ensure their new solutions caused the least amount of disruption, particularly during peak times. Another important consideration was the internal organizational structure. “You can’t develop a technology strategy in isolation, we need to be mindful of both the structure and culture of an organization. The culture needs to be improved, particularly when partnering with others and the structure needs to be standardized across the various teams,” says Sagar Bujbal, VP technology at Macmillan Learning.

Like any other business, Macmillan Learning integrates with many disparate systems. “Around 60 to 80% of your time is spent on supporting these various systems, rather than concentrating on innovation. When thinking about the right solutions implement, we really need to quantify the strengths and weaknesses of each of these systems,” says Paul King, a solutions architect at Ribbonfish. Both Paul and Sagar stress on the point that seamless integration in such a context requires architectural guardrails and governance. They explain that a well-defined target reference architecture (prior to development) with a long term vision, taking into account changes that will have to be encountered over the years, is a solid starting point. Best practices and utilizing out-of-box platform capabilities are further requirements for seamless integration.

Sagar and Paul presenting at WSO2Con USA

Selecting the Right Technology

Both Sagar and Paul believe that an enterprise integration platform is one of the most strategic technology decisions that a business makes. They were looking to build a target reference architecture that was business driven, rather than focusing on a particular technology and evaluated several technology vendors based on this. Macmillan Learning and Ribbonfish considered factors such as platform capabilities, maturity of the product, type of agility provided for developers, quality of production support, costs, and the vendor’s willingness to work closely with a business to solve their particular needs. Both were of the view that WSO2 Enterprise Integrator, with its integration runtimes, message brokering, business process modeling, and analytics capabilities, catered to their requirements.

Achieving Seamless Integration

Given the fact that integration needs at Macmillan Learning were diverse, Sagar and Paul decided on APIs as the de-facto standard for integrating all their systems. They also made sure that there was no direct coupling. Their current architecture includes the Macmillan Learning integration layer composed of WSO2 Enterprise Integrator along with Salesforce. Paul explains that one of their main goals when building the new architecture was to not over complicate things and using WSO2 helped, “One of the big things we really took from it when we selected WSO2 as a platform and service was that there are plenty of solutions within WSO2 itself.”

Paul and Sagar state that documenting the inventory of business processes and interactions contributed a lot to their success, as it helped them to better define their target reference architecture. They also believe that defining their integration techniques, constant communication with their engineering team, and weekly reviews of what they implemented helped them immensely.

More innovation is planned for Macmillan Learning and Ribbonfish. The huge scale of transformation at Macmillan Learning means that there is a continuous demand to meet these requirements. Proactive customer service plays a key role in this transformation. Macmillan Learning and Ribbonfish gain insights from interactions between customer care agents, students, and instructors to improve this transformation process and customer satisfaction. And as mentioned earlier, they will continue to review what they do for the best possible outcomes.

To learn more about how Macmillan Learning and Ribbonfish are working together, watch this video:

Everything you need to learn about WSO2 Enterprise Integrator 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.