I came across something interesting lately while playing with the WSO2 ESB cache mediator. Since this would be a very common scenario I thought of writing about it. Following is a small description of the problem and the solution.

When a browser sends a request for a certain resource the server replies with the resource with an HTTP ETag value (e.g. ETag: d9537e6b) header. This allows the browser to make conditional requests. The next time the browser sends an HTTP GET request to the same resource it will send a new HTTP header called If-None-Match (e.g. If-None-Match:d9537e6b). The server will…


Photo by JJ Ying on Unsplash

Background

Continuous integration and continuous deployments have become a popular DevOps approach for increasing the efficiency of the software development lifecycle. Using Maven for builds, releases, and deployments is the most predominant CI/CD approach for WSO2 integration artifacts. Having said that, certain reasons such as aligning your organization’s existing CI/CD process to align with WSO2 releases can prompt the DevOps to take alternate approaches to CI/CD.

In this article, we will see how a non-maven based approach can be implemented to support CI/CD using Bitbucket Server and Jenkins. The enablement of this approach is done by the Bitbucket Branch Source Plugin.


Organizations who already own Identity and Access Management solutions would want to keep it and use it as a third party key manager integrated with WSO2 API Manager to handle clients, security and Oauth tokens. API Store communicates with the Key Manager to create/manage Oauth applications/clients, generate Oauth tokens and validate the tokens upon API invocations using the generated tokens. It is a decoupled highly cohesive component which takes care of Oauth client management and the key management.

Writing a custom Key Manager for WSO2 can be simply done by extending the following class in the API Manager.

org.wso2.carbon.apimgt.impl.AbstractKeyManager

Mainly…


Photo by Adem AY on Unsplash

This post describes how a proxy service deployed in WSO2 ESB can be invoked using a SMS message sent from a SMSC.

Following steps will guide you through this process.

1) Please use the following SMS transport receiver in the <ESB_HOME>/repository/conf/axis2/axis2.xml to enable SMS receiving in the ESB.

<transportReceiver name="sms"
class="org.apache.axis2.transport.sms.SMSMessageReciever">

2) Download axis2 SMPP transport jar from here and copy it to <ESB_HOME>/repository/components/lib folder.

3) Download JSMPP from [1] unzip it and copy the jsmpp-2.1.0.jar to <ESB_HOME>/repository/components/lib folder. JSMPP is a java implementation of the SMPP protocol which provides and API to communicate with the SMSC.

Now when you…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store