Enterprise Integration for Beginners

Distributed systems (to be exact, distributed computer systems) has come a long way from where it was started. At the very beginning, one computer could only do one particular task at a time. If we need multiple tasks to be done in parallel, we need to have multiple computers running in parallel. But running them parallel was not enough for building a truly distributed system since it requires a mechanism to communicate between different computers (or programs running on these computers). This requirement of exchanging (sharing) data across multiple computers triggered the idea of the message-oriented communication where two computers share data across using a message which wraps the data. There were few other mechanisms like file sharing, database sharing also came into the picture. Source: https://dzone.com/articles/building-integration-solutions-a-rethink Then came the era of multitasking operating systems and personal computers. With Windows, Unix, Linux operating s

WSO2 API Manager recently added a feature to control the visibility and the management of the API publisher interface which allows multiple teams within a same organization to independently develop their APIs without allowing others to edit or modify APIs. Even though separate teams can achieve the same (or higher) level of isolation through multi tenancy, it is not a viable option for most user scenarios where they need to expose APIs through the same tenant without dealing with the tenant level complexities. The basic requirement to achieve team level isolation is to create a role per team with necessary permissions to create and publish APIs. You can do this by log in to the WSO2 API manager carbon console ( https://localhost:9443/carbon ) and then creating a role for team1 and then assigning API creation and publishing permissions.                           View user roles created within the API manager                           Permission assignment to role created for

WSO2 API Manager throttling implementation is done in a manner so that API designers have the full flexibility to throttle API consumers at all levels. It supports throttling at  API level Resource level Application level Subscription level Oauth2 token level with out of the box throttling tiers and configurations. Users can manage throttling at above mentioned levels using the OOTB functionalities available in the product. The below 2 figures explains how the throttling is applicable across different levels and how they are executed during the runtime. WSO2 API Manager throttling levels and applicability The different throttling levels which are configured from the API manager will apply during the runtime as depicted in the below figure. WSO2 API Manager throttling execution flow In this article, I’m going to discuss how to implement custom throttling rules to throttle API requests based on users. To do this, users needs to log in to the admin interface of the WSO2 AP

WSO2 API Manager components API Publisher: Used by API owners. Create, Publish and Manage API lifecycle. URL = https://localhost:9443/publisher. API Store (Developer Portal): Used by API users. Discover, register and subscribe to APIs. URL = https://localhost:9443/store. API Gateway: Used by API consumers. All the requests comes here and security, throttling enforced here. URL = https://localhost:9443/carbon  . Key Manager: Used by API Gateway to validate subscriptions, OAuth tokens, and API invocations. Provides a token API to generate OAuth tokens that can be accessed via the Gateway. URL = https://localhost:8243/token Traffic Manager: Used by API Gateway to enforce throttling. Features a dynamic throttling engine (Siddhi) to process throttling policies in real-time. URL = https://localhost:9443/admin API Manager Analytics: Provides a host of statistical graphs, an alerting mechanism on predetermined events and a log analyzer. API Manager component interatio