Shenavi's Blog

The default behaviour of GREG is to show all the menu options related to each asset. Even though you can enable/disable the asset type based on the user permissions you cannot manage the different options of the individual asset. Prerequisite In order to try this use case first you would need to download the Governance Registry Product. You can download it here [1] Overview For each asset the GREG publisher would show the following menu. This is the menu shows for a esdl based soap service. If we have a requirement where we need to control the users who are able to create Associations there is no direct way in which this is supported. In other words there is no way of managing these menu items based on role permissions. But the good news is this can be accomplished by doing a few customizations in the GREG. Below steps will guide you through how you can allow/disable the Association tab based on user permission with GREG. Let's get started 1) First let's crea

Overview WSO2 ESB uses Rhino engine to execute JavaScripts. Rhino engine converts the script to a method inside a Java class. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters, since the Script mediator converts the payload into a Java object. However, you can use the following alternative options to process large JSON data volumes. The script mediator which is used in ESB is powered by the Rhino engine. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters which is a limitation in the script mediator being used in the esb versions less than 5.0.0. In ESB 5.0.0 there is a higher capability to process larger payloads using script mediator. In order to process such large payloads we can follow the below two approaches. 1. Replace the javascript tranformation logic using java code by writing a custom mediator. [1] 2. Break down the large payload and execute them as sections using

Overview You can add custom error messages for an API by following the post [1] but when the error is thrown inside the custom in or out sequence we add as the mediation extension this custom error sequence which we specify for the API does not get invoked. Therefore we need to specify the error sequence seperately for the custom sequence. This blog will explain how to carry out this use case. Let's get started To demonstrate this I will be using the call mediator inside the custom sequence. Since when an invalid endpoint is invoked with the call mediator it would generate an error in the API Manager which would be received inside our custom sequence. 1) You can follow my previous tutorial [2] to get a better understanding and configurations needed to use the call mediator using wso2 api manager 1.10.0. Create the API as mentioned in the sequence above and subscribe and generate keys for the API in the store. 2) Now what we are going to do is, we are going to provide an

Introduction In API Manager if you need to do any service chaining use cases the call mediator comes in handy. If you need to use the response received by invoking one endpoint and then use it to invoke another endpoint you can use the call mediator in API Manager. The call mediator behaves in a synchronous manner. Hence, mediation pauses after the service invocation and resumes from the next mediator in the sequence when the response is received. You can read more about the call mediator in the wso2 esb documentation [1] . In api manager 1.10.0 the call mediator works in the blocking mode. Prerequisite Before we can use the call mediator in API Manager 1.10.0 we need to make the following changes to some configs. We need to comment the jms transport sender in axis2_blocking_client.xml found in the location APIM_HOME/repository/conf/axis2. This will resolve the jms sender initialization issues.   <!--transportSender name="jms"                      class

Instead of requesting the authorization straight from the resource owner (resource owner's credentials), in this grant type, the client directs the resource owner to an authorization server. The authorization server works as an intermediary between the client and resource owner to issues an authorization code. After obtaining this authorization code then the client can call the token endpoint. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner granted or denied the client's access request. After which the client can call the /token endpoint and request an access token. [1] Tutorial  Let's see how we can demonstrate this scenario using a sample application. 1. For this I will be using the oauth2 playground application. You can setup the application as instructed in this doc [2] or you can download the war file from here . 2. Once you have set up this sample application let's log into API

API Cloud provides the authorization of the APIs published using basic auth. But what do we do if our back-end is also secured using a different mechanism. In this blog i will explain how we can create and API and invoke a back-end when the back-end has been secured using a user name and password. To demonstrate this sample i will be using a JAX-RS based service used in the WSO2 APP cloud. It is a basic jax-rs application very much like the one found here . It is a service that can be used to get the id and name of a customer when the id is passed as a parameter which is the operation I will be using to demonstrate the example. This service cannot be accessed unless we provide the credentials. The service was secured in the manner explained in this blog . A security constraint tag was included to the web.xml of the jax-rs service which will require credentials if we need to invoke the methods of this service using our API. First Let’s create our API to demonstrate the scenario

The API Gateway has a default mediation flow for the API invocation requests that it receives. You can extend this default mediation flow to do additional custom mediation for the messages in the API Gateway. An extension is provided as a synapse mediation sequence. You design all sequences using a tool like WSO2 Developer Studio and then add the sequences to the API. Prerequisite Download WSO2 Developer Studio (version 3.7.1 is used here) from http://wso2.com/products/developer-studio/ and open it by double clicking the Eclipse.app file inside the downloaded folder. Need to have an existent account with the WSO2 API Cloud. Steps: In the normal manner create the API providing a name and context. (You can follow the tutorial here [1])  Before specifying the resource select the ‘Implement’ button. You will be asked whether to include a wild card resource select yes and proceed to the next step.  In the ‘Implement’ section provide the endpoint as http://appserver.dev.cl

This blog explains how we can create a single API in the API Cloud and make it call multiple endpoints based on a version header passed in the request. Therefore we will not need to create an API per backend endpoint version and can use a custom sequence for the API to route to the required destination. Pre requisite. 1. You need to make sure you have an account with the WSO2 Cloud. If you do not have an account then you first need to create one. You can find the steps here under 'How to create an Account with WSO2 Cloud'. Lets see how we can configure the API cloud to carry out this requirement.  In order to demonstrate the scenario i have used an endpoint of a service which is hosted in WSO2 App Cloud and have created two different versions [1] [2] of the endpoint and invoked accordingly by including this sequence to the API. I have used the default version as [1]. The versions are customerservice-default-SNAPSHOT and customerservice-1.1.0 respectively. Please

It's a common use case where enterprise applications that have SAML2 based SSO infrastructures sometimes need to consume OAuth-protected resources through APIs. However, these apps prefer to use the existing trust relationship with the IDP. Even if the OAuth authorization server is entirely different from the IDP. The API Cloud leverages this trust relationship by exchanging the SAML2.0 token to an OAuth token with the authorization server. WSO2 API Cloud has an token API which is exposed to the users in order to create and renew user and application access tokens. The response of the Token API is a JSON message. You extract the token from the JSON and pass it with an HTTP Authorization header to access the API. In this example we will be using the SAML extension grant type to generate the tokens. In this blog i will explain the steps on how you can successfully carry out the SAML to OAuth2 token exchange with the API Cloud. Let's take a look at how this can be achie