Deploy multiple traffic managers with load balance data publisher failover data receiver pattern.

Sending all the events to several receivers

Copy of Copy of traffic-manager-deployment-LBPublisher-failoverReciever.png
This setup involves sending all the events to more than one Traffic Manager receiver. This approach is mainly followed when you use other servers to analyze events together with Traffic Manager servers. You can use this functionality to publish the same event to both servers at the same time. This will be useful to perform real time analytics with CEP and to persist the data, and also to perform complex analysis with DAS in nearly real time with the same data.

Similar to load balancing between a set of servers, in this scenario you need to modify the Data Agent URL. You should include all DAS/CEP receiver URLs within curly braces ({}) separated with commas as shown below.

<DataPublisher>
           <Enabled>true</Enabled>
           <Type>Binary</Type>
<ReceiverUrlGroup>{tcp://127.0.0.1:9612},{tcp://127.0.0.1:9613} </ReceiverUrlGroup>
<AuthUrlGroup>{ssl://127.0.0.1:9712},{ssl://127.0.0.1:9713}</AuthUrlGroup>
           <!--AuthUrlGroup>ssl://${carbon.local.ip}:9712</AuthUrlGroup-->
           <Username>${admin.username}</Username>
           <Password>${admin.password}</Password>
           <DataPublisherPool>
               <MaxIdle>1000</MaxIdle>
               <InitIdleCapacity>200</InitIdleCapacity>
           </DataPublisherPool>
           <DataPublisherThreadPool>
               <CorePoolSize>200</CorePoolSize>
               <MaxmimumPoolSize>1000</MaxmimumPoolSize>
               <KeepAliveTime>200</KeepAliveTime>
           </DataPublisherThreadPool>
       </DataPublisher>

Deploy multiple traffic managers with load balance data publisher failover data receiver pattern.

Load balancing events to sets of servers  

Copy of traffic-manager-deployment-LBPublisher-failoverReciever(3).png


In this setup there are two group of servers that are referred to as Group A and Group B. You can send events to both the groups. You can also carry out load balancing for both sets as mentioned in load balancing between a set of servers. This scenario is a combination of load balancing between a set of servers and sending an event to several receivers. An event is sent to both Group A and Group B. Within Group A, it will be sent either to Traffic Manager -01 or Traffic Manager -02. Similarly within Group B, it will be sent either to Traffic Manager -03 or Traffic Manager -04. In the setup, you can have any number of Groups and any number of Traffic Managers (within group) as required by mentioning them accurately in the server URL.

Similar to the other scenarios, you can describe this as a receiver URL. The Groups should be mentioned within curly braces separated by commas. Furthermore, each receiver that belongs to the group, should be within the curly braces and with the receiver URLs in a comma separated format. The receiver URL format is given below.

 <DataPublisher>
           <Enabled>true</Enabled>
           <Type>Binary</Type>    <ReceiverUrlGroup>{tcp://127.0.0.1:9612,tcp://127.0.0.1:9613},{tcp://127.0.0.2:9612,tcp://127.0.0.2:9613} </ReceiverUrlGroup>
<AuthUrlGroup>{ssl://127.0.0.1:9712,ssl://127.0.0.1:9713}, {ssl://127.0.0.2:9712,ssl://127.0.0.2:9713}</AuthUrlGroup>
           <Username>${admin.username}</Username>
           <Password>${admin.password}</Password>
           <DataPublisherPool>
               <MaxIdle>1000</MaxIdle>
               <InitIdleCapacity>200</InitIdleCapacity>
           </DataPublisherPool>
           <DataPublisherThreadPool>
               <CorePoolSize>200</CorePoolSize>
               <MaxmimumPoolSize>1000</MaxmimumPoolSize>
               <KeepAliveTime>200</KeepAliveTime>
           </DataPublisherThreadPool>
       </DataPublisher>

Deploy multiple traffic managers with load balance data publisher failover data receiver pattern.

Load balancing events to a set of servers

Copy of Copy of traffic-manager-deployment-LBPublisher-failoverReciever(1).png

This setup shows load balancing the event to publish it to all Traffic Manager receivers. The load balanced publishing is done in a Round Robin manner, sending each event to each receiver in a circular order without any priority. It also handles fail-over cases such as, if Traffic Manager Receiver-1 is marked as down, then the Data Agent will send the data only to Traffic Manager Receiver-2(and if we have more node then for all of them) in a round robin manner. When Traffic Manager Receiver-1 becomes active after some time, the Data Agent automatically detects it, adds it to the operation, and again starts to load balance between all receivers. This functionality significantly reduces the loss of data and provides more concurrency.

For this functionality, include the server URL in the Data Agent as a general DAS/CEP receiver URL. The URL should be entered in a comma separated format as shown below.

 <DataPublisher>
           <Enabled>true</Enabled>
           <Type>Binary</Type>
           <ReceiverUrlGroup>tcp://127.0.0.1:9612,tcp://127.0.0.1:9613</ReceiverUrlGroup>
           <AuthUrlGroup>ssl://127.0.0.1:9712,ssl://127.0.0.1:9713</AuthUrlGroup>
           <Username>${admin.username}</Username>
           <Password>${admin.password}</Password>
           <DataPublisherPool>
               <MaxIdle>1000</MaxIdle>
               <InitIdleCapacity>200</InitIdleCapacity>
           </DataPublisherPool>
           <DataPublisherThreadPool>
               <CorePoolSize>200</CorePoolSize>
               <MaxmimumPoolSize>1000</MaxmimumPoolSize>
               <KeepAliveTime>200</KeepAliveTime>
           </DataPublisherThreadPool>
       </DataPublisher>

Deploy multiple traffic managers with fail over data publisher fail over data receiver pattern.


Like we discussed early gateway data receiver need to configure with fail over data receiver. But data publisher can be configured according to load balance or failover pattern. In this section we will see how we can publish throttling events to traffic manager in failover pattern.

Failover configuration

s8YuuoU022qL8M0comFZBpA.png

When using the failover configuration in publishing events to Traffic manager, events are sent to multiple Traffic Manager receivers in a sequential order based on priority. You can specify multiple Traffic Manager receivers so that events can be sent to the next server in the sequence in a situation where they were not successfully sent to the first server. In the scenario depicted in the above image, first events are sent to Traffic Manager Receiver-1. If it is unavailable, then events will be sent to Traffic Manager Receiver-2. Further, if that is also available, then events will be sent to Traffic Manager Receiver-3.


 <DataPublisher>
           <Enabled>true</Enabled>
           <Type>Binary</Type>
           <ReceiverUrlGroup>tcp://127.0.0.1:9612 | tcp://127.0.0.1:9613</ReceiverUrlGroup>
           <!--ReceiverUrlGroup>tcp://${carbon.local.ip}:9612</ReceiverUrlGroup-->
           <AuthUrlGroup>ssl://127.0.0.1:9712 | ssl://127.0.0.1:9713</AuthUrlGroup>
           <!--AuthUrlGroup>ssl://${carbon.local.ip}:9712</AuthUrlGroup-->
           <Username>${admin.username}</Username>
           <Password>${admin.password}</Password>
           <DataPublisherPool>
               <MaxIdle>1000</MaxIdle>
               <InitIdleCapacity>200</InitIdleCapacity>
           </DataPublisherPool>
           <DataPublisherThreadPool>
               <CorePoolSize>200</CorePoolSize>
               <MaxmimumPoolSize>1000</MaxmimumPoolSize>
               <KeepAliveTime>200</KeepAliveTime>
           </DataPublisherThreadPool>
       </DataPublisher>
          
<JMSConnectionParameters>              
<transport.jms.ConnectionFactoryJNDIName>TopicConnectionFactory</transport.jms.ConnectionFactoryJNDIName>
<transport.jms.DestinationType>topic</transport.jms.DestinationType>           
<java.naming.factory.initial>org.wso2.andes.jndi.PropertiesFileInitialContextFactory</java.naming.factory.initial>            
<connectionfactory.TopicConnectionFactory>amqp://admin:admin@clientID/carbon?failover='roundrobin'%26cyclecount='2'%26brokerlist='tcp://127.0.0.1:5673?
retries='5'%26connectdelay='50';tcp://127.0.0.1:5674?
retries='5'%26connectdelay='50''</connectionfactory.TopicConnectionFactory>
</JMSConnectionParameters>

Fail over Traffic Manager data receiver pattern for API Gateway.

The idea behind fail over data receiver endpoint is stopping single-point-of-failure in a system. As the broker deployed in each traffic manager and storing and forwarding the messages, if that server goes down entire message flowing of the system will go down no matter what other servers and functions are involved. Thus in order to make a robust messaging system it is mandatory to have a fail-over mechanism.

When we have few instances of Traffic Manager servers up and running in the system generally each of these server is having brocker. If one broker goes down then gateway automatically switch to the other broker and continue throttle message receiving. If that one also fails it will try next and so on. Thus as a whole system will not have a downtime.

So in order to achieve high availability for data receiving side we need to configure JMSConnectionParameters to connect multiple broker running within each traffic manager. So for that we need add following configuration to each gateway. If single gateway is communicating with multiple traffic manager this is the easiest way to configure gateway to communicate with multiple traffic managers.

To configure that you need to add following configuration to each gateway worker. Then it will pick updates from any of the traffic manager event if some of them not functioning.

<JMSConnectionParameters>              
<transport.jms.ConnectionFactoryJNDIName>TopicConnectionFactory</transport.jms.ConnectionFactoryJNDIName>
<transport.jms.DestinationType>topic</transport.jms.DestinationType>           
<java.naming.factory.initial>org.wso2.andes.jndi.PropertiesFileInitialContextFactory</java.naming.factory.initial>            
<connectionfactory.TopicConnectionFactory>amqp://admin:admin@clientID/carbon?failover='roundrobin'%26cyclecount='2'%26brokerlist='tcp://127.0.0.1:5673?
retries='5'%26connectdelay='50';tcp://127.0.0.1:5674?
retries='5'%26connectdelay='50''</connectionfactory.TopicConnectionFactory>
</JMSConnectionParameters>

WSO2 API Manager based solutions frequently asked questions and answers for them - 03

Can API Manager audit a source request IP address, and the user who made the request?
Yes, information on the request IP and user is captured and can be logged to a report.

Automation support for API setup and for configuring the API gateway?
Supported, setup can be automated through tools like Puppet. Puppet for common deployment patterns are also available for download.

Capability to run reports on API usage, call volume, latency, etc? 
Supported, API usage, call volume and latency can be reported. However information on caching is not reported.

Logging support and capability to integrate with 3rd party logging module?
By default our products use log4j for logging and if need we can plug custom log appenders. It is possible to push logs to an external system as well.

Billing and payment support & monitoring tools for API usage?
Billing and payment integration support is not available OOTB. But extension points are available to integrate with an external billing and payment systems. Currently WSO2 API Cloud (SaaS offering of WSO2 API Manager) is integrated with payment system successfully. So users can implement required extensions and get the job done.

Capability of message processing cycle control via pre/post processing?
Supported, it is possible to do some pre/post processing of messages based on what is available OOTB, however some pre/post processing would require custom capabilities to be written.

Does it support adapters or connectors to 3rd party systems such as Salesforce etc.
Supported by WSO2 ESB, WSO2 Integration Platform provides connectors to over 130 3rd party systems including Salesforce.com. The entire list of connectors can be accessed and downloaded from the following site.
https://store.wso2.com/store/assets/esbconnector"

Capability of monitoring and enforcing policy (i.e. message intercept).
Supported, it is possible to validate the message against a XSD to ensure that its compliant with a schema definition, it is also possible to audit and log messages and manage overall security by enforcing WS-Security on messages.

Multiple technology database support?
Database connectivity is provided via a JDBC adapter and multiple JDBC adapters can be used at the same-time. It is possible to change from one database technology to another as long as a JDBC adapter is available.

WSO2 API Manager based solutions frequently asked questions and answers for them - 02

Capability to create, manage and deploy both sandbox environments and production environments?
It is possible to manage a Sandbox and a Production environment simultaneously. Each of these environments can have its own API Gateway.

Can deploy application(s)/project(s) from one environment to another environment?
Applications and subscriptions cannot be migrate from one environment to another directly. But a RESTful API is available to get a list of applications and recreate them in another environment. However APIs can be imported/exported from one environment to another OOTB.

Capability to apply throttling to APIs and route the calls for different API endpoints?
Supported, Throttling can be applied to APIs based on a simple throttling rule such as number of requests allowed per minute or based on a complex rule which can consider multiple parameters such as payload size and requests per minute when throttling API calls.
API Gateway can apply throttling policies for different APIs and route the API calls for the relevant back end.

Supports  various versioning including URL, HTTP header, and Query parameter(s)?
API Manager supports URL based versioning strategy. If need we can implement our own

Capability to support API life cycle management including 'create', 'publish', 'block', and 'retire' activities?
API life cycle can be managed by the API Manager. By default it supports Created, Published, Depreciated, Blocked and Retired stages.

Can it manage API traffic by environments (i.e. sandbox, production etc.) and by Gateway?
Supported,Multiple API Gateways can be setup for Sandbox and Production environments to handle traffic of each environment separately. https://docs.wso2.com/display/AM200/Maintaining+Separate+Production+and+Sandbox+Gateways

Does it have throttling limit support?
Supported, Throttling enables users to create more complex policies by mixing and matching different attributes available in the message. Moreover, it supports throttling scenarios based on almost all header details. WSO2 API Manager 2.0 offers more flexibility when it comes to defining rules. In addition, the blocking feature will be very useful as well to protect servers from common attacks and abuse by users.

Provides rate limiting support?
Supported, rate limit support is available in the API Manager.

Capability to horizontally scale traffic in a clustered environment
Supported, a API Manager instance can handle over 3500 transactions per second when its fully optimized.

Support local caching for API responses (i.e. in non-clustered environment or when clustering not activated)?
Supported, it is possible to enable or disable API response caching for each API exposed.

Support distributed caching for API responses amongst nodes within a cluster?
Supported, caching is distributed to all Gateway nodes in the cluster.

Capability of auto-scaling via adding new nodes based on load ( i.e. auto spawning new instances and add to cluster)?
Autoscaling should be supported at underlying infrastructure level. The cluster allows any new node to join or leave the cluster whenever required.

Supports conversion from SOAP to REST?
Supported, SOAP to REST conversion is supported

Supports conversion from XML to JSON and JSON to XML within request and response payloads?
Supported, it is possible to convert the request and payload from XML to JSON and vice versa.
https://docs.wso2.com/display/AM200/Convert+a+JSON+Message+to+SOAP+and+SOAP+to+JSON

Supports redirecting API calls via the rewriting of URLs?
URL rewriting is supported with this it is possible to change final API destination dynamically based on a predefined condition and route requests. It is also possible to define parameterized URLs which can resolve a value in runtime according to an environment variable.

Ability to parse inbound URL for params including query parameters?
Supported, Query parameter, path parameter reading and modifications can be done before a request is sent to the backend.

Visual development, rapid mapping of activities and data?
Visual development and visual data mapper is available to develop the mediation sequences required. The visual development would be done via WSO2 Developer Studio which an Eclipse based IDE.

Custom activity - define custom code with input/output interface?
Supported, Custom code can be written as Java or Java scripts.

WSO2 API Manager based solutions frequently asked questions and answers for them - 01

OAuth support for REST API and WS-security token for SOAP/XML?
OAuth 2.0 support for REST API is available in WSO2 product platform. WS security, basic auth, xacml and other common authentication authorization implementations available in WSO2 solution and users can use them.

Support HMAC header signature or OAuth for REST API and WS-security message signature for SOAP service?
HMAC header signature validation and verification need to implement as separate handler and engage to API. That is not available as a OOTB solution. Both requirements can be fulfilled by writing a custom extension.

Support HTTPS for REST and ws-security message encryption for SOAP?
WSO2 supports WS Security and WS-Policy specifications. These specifications define a behavioral model for web services. A requirement for one proxy service may not be valid for another. Therefore, WSO2 provides the option to define service specific requirements. Security functionality is provided by the Security Management feature which is bundled by default in the Service Management feature of the WSO2 feature repository. The Security Management feature makes it easy to secure the proxy services of the ESB by providing twenty pre-defined, commonly-used security scenarios. These security policies are disabled by default.
https://docs.wso2.com/display/ESB481/Securing+Proxy+Services

Can safely publish APIs to external mobile applications?
Supported, APIs can be exposed to external mobile applications for consumption. Similarly a separate gateway can expose APIs for internal consumption as well.

Is it possible to integrate with external log systems or analyzing frameworks?
Users need to write custom log agent or use syslog agent to integrate with external tools. We have done similar integrations previously and use syslog agent for that.

Is it supports the 'API First' design with capabilities to publish API interfaces and/or import Swagger 2.0 definition(s)?
API first design capability is support with Swagger 2.0. It is possible to upload or refer a Swagger document and create the API based on this Swagger document.

Capability to support established open API documentation frameworks?
Supported, Swagger based documentation is supported. It is possible to create APIs based on a Swagger document. It is also possible to interactively test APIs through Swagger.

Can we deploy a prototyped API quickly without actual back end system?
"It is possible to deploy a new API or a new version of an existing API as a prototype.  It gives subscribers an early implementation of the API that they can try out without a subscription or monetization. Similarly in case if the actual back end service implementation is not available it is possible to create mock responses that can be sent as a response for API requests.
https://docs.wso2.com/display/AM200/Deploy+and+Test+as+a+Prototype"

Capability to browse and search APIs by provider, tag, name?
Supported, it is possible to search APIs and associated documentation as well as tag and filter APIs available in the portal.

Provides a developer portal with dashboard, subscription to API,  provisioning API keys capabilities & tokens?
API store (developer portal) provides a dashboard from which developers can  search, subscribe, generate API keys, rate and review APIs and view usage statistics from the API Store.

How API Manager supports community engagement with capabilities?
API Store (developer portal) allows users to self sign-up which can even be linked to an approval process where an authorized user's needs to approve the sign up before a user is allowed to access the portal. Users are able to view usage statistics, contribute towards the user forum, comment/review and rate APIs.

Capability to publish APIs to internal users only, external partners only and all users?
Supported, API visibility and subscription availability can be restricted based on user roles and tenants (if the API Manager is deployed in the multi-tenant mode).

Capability to provision API keys on demand?
Supported, API keys can be provisioned by users on-demand via the API Store or through the provided RESTful API.

Supports publishing and deploying APIs to multiple API Gateways?
Supported, it is possible to publish an API to a selected Gateway or to multiple Gateways. https://docs.wso2.com/display/AM200/Publish+through+Multiple+API+Gateways

How to manage multiple API Manager instances for different environment and use single external key Management server - WSO2 API Manager

Here i'm explaining solution for manage multiple API Manager environments and external key management server to build central API repository. Gateways in each environment can talk to different key managers as its just pointing key validation URLs.  In store we do not have concept of showing multiple consumer key/secret access tokens per environment. 
But like we discussed early we are using external key Manager as underlying key Manager and use it from WSO2 key Managers and gateways. So if we designed to have same application in store irrespective deployment it deployed we can achieve this requirement.

We have one API which can deployed in multiple environments. But can only one subscription for all environments and same set of tokens will work any environment. Still each environment have their own key manager and when it comes to validate again direct to same external key manager.

To understand more about API publisher publishing to multiple environment please refer this article.
https://docs.wso2.com/display/AM200/Maintaining+Separate+Production+and+Sandbox+Gateways

To study about deploying same API across multiple environments and URL to automatically resolve based on deployment refer this article.
http://sanjeewamalalgoda.blogspot.com/2016/07/how-to-define-environment-specific-url.html
http://nuwanzone.blogspot.com/2015/03/api-gateways-with-dedicated-back-ends.html

External key manager concept and more details.
https://docs.wso2.com/display/AM190/Configuring+a+Third-Party+Key+Manager

Display multiple gateway URLs in API store can achieve with external gateway concept.
Please refer following diagram for complete solution.


How to use Java scrip mediator to modify outgoing message body during mediation flow - WSO2 ESB/ API Manager

Here in this post we will see how we can use Java scrip mediator to modify outgoing message body during mediation flow.
Below is the sample API configuration i used for this sample. As you can see here i will extract password field from incoming message and send it as symbol to back end service. Since i need to check what actually pass to back end server i added TCPMon between gateway and back end server. That is why 8888 port is appear there. 
  <api name="TestAPI" context="/test">
      <resource methods="POST" url-mapping="/status" faultSequence="fault">
         <inSequence>
            <script language="js">var symbol = mc.getPayloadXML()..*::password.toString();
               mc.setPayloadXML(
                  &lt;m:getQuote xmlns:m="http://services.samples/xsd"&gt;
                     &lt;m:request&gt;
                        &lt;m:symbol&gt;{symbol}&lt;/m:symbol&gt;
                     &lt;/m:request&gt;
                  &lt;/m:getQuote&gt;);</script>
            <send>
               <endpoint name="test-I_APIproductionEndpoint_0">
                  <http uri-template="http://127.0.0.1:8888/"/>
               </endpoint>
            </send>
         </inSequence>
         <outSequence>
            <send/>
         </outSequence>
      </resource>
   </api>
Then i send request as follows. As you can see here password will have some data and i'm sending post request.
curl -v -X POST -H "Content-Type: application/json" -d '{"username":"xyz","password":"xyz & abc"}' http://127.0.0.1:8280/test/status
I can see my values pass to back end properly. Since i added TCPMon between ESB and back end to verify out going message i can see what going out from ESB. Also following is wore logs captured for my message.
[2016-08-10 14:30:21,236] DEBUG - wire >> "POST /test/status HTTP/1.1[\r][\n]"
[2016-08-10 14:30:21,236] DEBUG - wire >> "Host: 127.0.0.1:8280[\r][\n]"
[2016-08-10 14:30:21,236] DEBUG - wire >> "User-Agent: curl/7.43.0[\r][\n]"
[2016-08-10 14:30:21,236] DEBUG - wire >> "Accept: */*[\r][\n]"
[2016-08-10 14:30:21,236] DEBUG - wire >> "Content-Type: application/json[\r][\n]"
[2016-08-10 14:30:21,236] DEBUG - wire >> "Content-Length: 41[\r][\n]"
[2016-08-10 14:30:21,237] DEBUG - wire >> "[\r][\n]"
[2016-08-10 14:30:21,237] DEBUG - wire >> "{"username":"xyz","password":"xyz & abc"}"
[2016-08-10 14:30:21,245] DEBUG - wire << "POST /status HTTP/1.1[\r][\n]"
[2016-08-10 14:30:21,245] DEBUG - wire << "Content-Type: application/json[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "Accept: */*[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "Transfer-Encoding: chunked[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "Host: 127.0.0.1:8888[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "Connection: Keep-Alive[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "[\r][\n]"
[2016-08-10 14:30:21,246] DEBUG - wire << "2f[\r][\n]"
[2016-08-10 14:30:21,247] DEBUG - wire << "{"getQuote":{"request":{"symbol":"xyz & abc"}}}[\r][\n]"
[2016-08-10 14:30:21,247] DEBUG - wire << "0[\r][\n]"
[2016-08-10 14:30:21,247] DEBUG - wire << "[\r][\n]"

TCPMon output.













Empowering the Future of API Management: Unveiling the Journey of WSO2 API Platform for Kubernetes (APK) Project and the Anticipated Alpha Release

  Introduction In the ever-evolving realm of API management, our journey embarked on the APK project eight months ago, and now, with great a...