Skip to main content

Adding custom error messages within a custom sequence in API Manager


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 invalid capital city. When the call mediator executes this since this is invalid and not found it would generate an error reponse in the swagger UI. This would execute the API Manager's default fault sequence.


3) Now since we need to change this default error code to display something more meaningful we need to create a custom error sequence. You can create a custom error sequence as instructed in the tutorial [1]. Below is the custom error sequence which I have used, you can download it from HERE.

       
<sequence xmlns="http://ws.apache.org/ns/synapse" name="customErrorSequence">           
    <payloadFactory>
        <format>
          <CapitalResponse>
                 <message>No result for the given capital: $1</message>
           </CapitalResponse>
        </format>
        <args>
             <arg expression="get-property('uri.var.capital')"/>
        </args>
    </payloadFactory>         
    <class name="org.wso2.carbon.apimgt.usage.publisher.APIMgtFaultHandler"/>
    <property name="RESPONSE" value="true"/>
    <property name="HTTP_SC" value="200" scope="axis2"/>
    <header name="To" action="remove"/>
    <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
    <property name="ContentType" scope="axis2" action="remove"/>
    <property name="Authorization" scope="transport" action="remove"/>
    <property name="Host" scope="transport" action="remove"/>
    <property name="Accept" scope="transport" action="remove"/>
    <property name="X-JWT-Assertion" scope="transport" action="remove"/>
    <sequence key="_cors_request_handler_"/>
    <send/>
</sequence>

4) We need to then add this sequence it from the management console using the source view. Or you can add the sequence .xml file to the location APIM_HOME/repository/deployment/server/synapse-configs/default/sequences. After adding this change you may have to wait for 15 mins for changes to get reflected or else you can restart the API Manager.


5) Nest we need to edit the in sequence we used previously to point to this fault sequence when a fault occurs withing the in sequence. For that we need to modify the <sequence> tag to mentioned which is the sequence to be executed when an error occurs. The modified call mediator sequence is as follows and you can download it from HERE . 

<sequence xmlns="http://ws.apache.org/ns/synapse" name="callMediatorSampleSequence" onError="customErrorSequence">
<property name="uri.var.capital" expression="$url:capital"/> 
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
    <call blocking="true">
        <endpoint>
            <http method="get" uri-template="http://restcountries.eu/rest/v1/capital/{uri.var.capital}"/>
        </endpoint>
    </call>
<log level = "custom">
<property name = "Sequence name" value="In the call mediator sequence"/>
<property name = "Capital name" expression="get-property('uri.var.capital')"/>
<property name="JSONPayload" expression="json-eval($.)"/>
</log>
</sequence>

6) Next we need to add the above modifed sequence to our API and re publish the API. 

7) Now when we invoke the API with an invalid value for the call mediator we will be able to see our custom error message.



Refernces 

[1] https://docs.wso2.com/display/AM1100/Error+Handling#ErrorHandling-Customerrormessages
[2] https://shenavid.blogspot.com/2016/08/invoking-external-endpoints-using-call.html
[3] https://docs.wso2.com/display/AM1100/Adding+Mediation+Extensions

Comments

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

Exposing a SOAP service as a REST API

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 for the e
2 comments
Read more