Shenavi's Blog

In my previous posi i explained how to call an endpoint using the call mediator. Usually when errors are thrown from the call mediator we can handle them using a custom sequence. When call mediators fails the execution stops hence handling errors is very essential. For this post I will be modifying the same sequence which i created in the blog post [1] The change which we need to do is we need to modify the sequence definition to map with the error sequence as shown below. You can find the modified sequence here . <sequence xmlns="http://ws.apache.org/ns/synapse" name="countrySequenceWithError" onError="countryErrorSequence"> <property name="uri.var.countryCode" expression="$url:countryCode"/> <property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>     <call blocking="true">         <endpoint>             <http method="get" uri-temp...

Introduction In the real world we require to create use cases where we need to invoke more than one endpoint to get the response we need for the API. We may require to get the response from one endpoint and manipulate that response and send it to another. In order to demonstrate this sample let's consider the following flow. We need to design an API which returns details about a country when a country code is entered by a user. One limitation we have is the endpoint which returns the country details expects a country name to be passed. Therefore to accomplish this task we need an intermediate service which gives us the country for the given country code (Service A). After we get the country name then we can pass it to our actual backend service. (Service B) Flow of events.  User needs to input a country code  We need to pass that entered value to the service A which returns the corresponding name of the country back to us. This is the format it will return. {"country...

Self Registration is an important feature when in comes to commercial applications. This feature allows the users the priviledge of being a part of your community without you having to go through the hassle of adding them. Mentioning ihis Identity Server also allows the capability to restrict or revise the approvals before granting access but we will be discussing that in a seperate post. This post will guide you on how you can enable the Self Registration feature using the self registration REST APIs at a global level for the WSO2 Identity Server 5.3.0. You can try the Rest service through Identity Server login page (https://localhost:9443/dashboard) There are two ways in which you can enable the feature. 1. Enable it at a global level across the whole platform. 2. Enable it per tenant basis. Let's discuss how to enable it a global level across the whole platform.. Pre requisite  Extracted WSO2 Identity Server 5.3.0. Let's name this as <WSO2_IS_HOME> ...

In this post i will be explaining how we can transform a SOAP based backend to receive requests in a restful manner through the WSO2 API Cloud. Steps. First log into the WSO2 Cloud and navigate to the API Cloud. In the API cloud select the option to add a new API. We will be creating an API to demonstrate an invocation to the backend soap service ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl Give a name, context and version to the API and add a resource name with a GET Method. The resource name can be anything which you like since we will invoke the actual service usiing a custom sequence. Mention the URI template as indicated in the below screenshot. Next go to the implement tab. And select the endpoint type as HTTP/SOAP Endpoint and specify the endpoint as http://ws.cdyne.com/phoneverify/phoneverify.asmx. There is an important step we need to do here. We need to set the SOAP version for this request. In order to do that we need to select the advanced option ...

WSO2 Identity server provides the capability to recover user accounts with the help of security questions. This feature is important when we forget the password and need some evidence that the actual user who had forgotton the password is indeed the right owner of the account. There are three such ways in which we can set these challenge questions for the users. You can read more details about each of these methods in this documentation. From the  UserIdentityManagementAdminService  SOAP API By manually creating registry resources for questions From Identity Server Management Console In this blog I will be guiding you through how to use the  UserIdentityManagementAdminService SOAP API to set the challenge questions. But we will be doing this with a slight twist. We are going to set these questions using an API created in the WSO2 ESB with the help of some custom sequences.  For the setting of the challenge questions using the admin service this is ...

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 ...