Skip to main content

Adding error sequence to a custom sequence

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-template="http://www.mocky.io/v2/597058891000001b0471d8fc/countryCode/{uri.var.countryCode}"/>
        </endpoint>
    </call>
<property name="uri.var.country" expression="json-eval($.country)"/>
<property name="uri.var.isfulltext" expression="json-eval($.fullText)"/>
<log level="full"/>
</sequence>


Then we need to create the sequence countryErrorSequence. Save the content in this link in a file and save it as countryErrorSequence.xml. You can modify the highlighted section with any error message which you like.


<?xml version="1.0" encoding="ISO-8859-1"?>
<sequence xmlns="http://ws.apache.org/ns/synapse" name="countrySequence">
    <log level="custom">
        <property name="STATUS" value="Executing default 'fault' sequence"/>
        <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
        <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
    </log>
    <filter source="get-property('MESSAGE_FORMAT')" regex="soap1[1-2]">
        <then>
            <property name="SOAP_FAULT_CODE" value="Server"/>
            <makefault>
                <code expression="$ctx:SOAP_FAULT_CODE"/>
                <reason expression="$ctx:ERROR_MESSAGE"/>
            </makefault>
        </then>
        <else>
            <payloadFactory>
                <format>
                    <CountryDetailsError>
                        <code>$1</code>
                        <type>Error Encountered</type>
                        <message>An error occurred when trying to get the details of the requested country</message>
                    </CountryDetailsError>
                </format>
                <args>
                    <arg expression="$ctx:ERROR_CODE"/>
                </args>
            </payloadFactory>
                <property name="messageType" value="application/json" scope="axis2"/>
        </else>
    </filter>


After saving the file you need to copy this file into the location wso2am-2.1.0/repository/deployment/server/synapse-configs/default/sequences/ if you are creating this API in the tenant mode then you need to copy this sequence to the location

wso2am-2.1.0/repository/tenants/{tenant_id}/synapse-configs/default/sequences

Further more you can handle custom error codes and provide different messages for them as well. The error codes returned can be found here.
   

Comments

  1. UnknownJuly 26, 2017 at 1:51 AM

    Hi Shenavi, thanks for the useful blow, but can you please tell me how to handle a situation in which I want to expose two APIs by WSO2 API Manager to the external customers - one as REST (JSON) and the other as SOAP (XML) based and in case of REST based, I need that all types of errors including the invalid input being entered, authorization issue, API blocked, subscription throttling issue to be send as a JSON response and in case of SOAP, to be sent as SOAP based. Please let me know on this.

    ReplyDelete
    Replies
    1. Shenavi de MelJanuary 8, 2018 at 10:09 PM

      In summary what you need is for your JSON based API to return a JSON formatted fault message and your SOAP based API to send an XML based message? In that case you can add the following property to your fault sequence which will simply do the transformation for you. Set the messageType property to application/json or application/xml accordingly

      Refer https://docs.wso2.com/display/ESB481/Generic+Properties#GenericProperties-messageType

      Delete

Post a Comment

Popular posts from this blog

Processing large payloads with the esb script mediator iteratively

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 ...
Post a Comment
Read more

Invoking external endpoints using the call mediator in wso2 api manager

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"        ...
1 comment
Read more

Configure WSO2 Identity Server for single sign on with Moodle - Part I

Introduction Moodle is a learning platform designed to provide educators, administrators and learners with a single robust, secure and integrated system to create personalized learning environments.[1]. This is commonly used in the education sector and there might be occurrences where it would require to use SAML to login to Moodle instead of the default basic authentication. For this we would need to have an Identity Provider capable of issuing such SAML tokens and Moodle configured to accept the tokens in order to do the authentication I will be discussing this in two parts. Part I - How to configure moodle for SSO with WSO2 Identity Server Part II - How to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server Let's see how this can be achieved using a SAML authentication plugin provided by one login. Prerequisite  You need to have a working version of Moodle installed. If you want to try this tutorial from scratch you can ...
1 comment
Read more