Page Comparison

...

For example, to change the message type of authorization errors, open the <API-M_HOME>/repository/deployment/server/synapse-configs/default/sequences/_auth_failure_handler.xml  file and change  and change  application/xml to something like  application/json .

...

900800

900801

900900

900901

900909

900902

900905

900906

900907

900908

900902

900905

900906

900907

900910

900908

900909

900910

Sequences error Sequences error codes

900901

400

403

In addition to the above error codes, we have engaged Synapse-level error codes to the default fault sequence and custom fault sequences (e.g., _token_fault_.xml ) of the API Manager. For information, see  Error Handling  in WSO2 Enterprise Integrator (WSO2 EI) documentation.

Transport error codes

If the HTTP PassThrough transport is used, and a connection-level error occurs, the error code is calculated using the following equation:

Error code = Base error code + Protocol State

Following are the possible protocol states and the description for each:

...

These Transport error codes are used in Advanced Configurations of Endpoints.

Custom error messages

To send a custom message with a custom HTTP status code, you execute an additional sequence that can generate a new error message. You then override the message body, HTTP status code and other values.

The following steps demonstrate how demonstrate how to override a throttled-out message's HTTP status code as a custom error message:

1. Start the WSO2 API Manager.

2. Go to <API-M_HOME> /repository/deployment/server/synapse-configs/default/sequences directory and create the file convert.xml as follows.

   Code Block
   language xml
   <sequence xmlns="http://ws.apache.org/ns/synapse" name="convert"> <payloadFactory media-type="xml"> <format> <am:fault xmlns:am="http://wso2.org/apimanager"> <am:code>$1</am:code> <am:type>Status report</am:type> <am:message>Runtime Error</am:message> <am:description>$2</am:description> </am:fault> </format> <args> <arg evaluator="xml" expression="$ctx:ERROR_CODE"/> <arg evaluator="xml" expression="$ctx:ERROR_MESSAGE"/> </args> </payloadFactory> <property name="RESPONSE" value="true"/> <header name="To" action="remove"/> <property name="HTTP_SC" value="555" scope="axis2"/> <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="Access-Control-Allow-Origin" value="*" scope="transport"/> <property name="Host" scope="transport" action="remove"/> <property name="Accept" scope="transport" action="remove"/> <property name="X-JWT-Assertion" scope="transport" action="remove"/> <property name="messageType" value="application/json" scope="axis2"/> <send/> </sequence>

   Tip
   Alternatively, you can use the Source View of the API-M Management Console as follows to edit the synapse configuration: Start the API Manager and log Sign in to the Management Console. (https://<Server Host>:9443/carbon). Go to Manager -> Source View. Copy the content of the sequence in convert.xml, paste it as a new sequence in the source view and update it.

3. Check the terminal logs to see whether there are issues in the deployment. 
   If the deployment is successful, you see a message similar to the following in the system logs:

   Code Block
   INFO - SequenceDeployerDependencyTracker Sequence named: 'convert' haswas beenadded deployedto from the Synapse configuration successfully INFO - SequenceDeployer Sequence named 'convert' has been deployed from file : <API-M_HOME>/repository/deployment/server/synapse-configs/default/sequences/convert.xml

4. Include the sequence that you just deployed in a sequence of your choice.
For this example, let's add this custom sequence in the _auth_failure_handler_ sequence.

   Code Block
   <sequence name="_auth_failure_handler_" xmlns="http://ws.apache.org/ns/synapse"> ... <sequence key="convert"/> <drop/> </sequence>

5. Check the terminal and see whether there are any errors with the _auth_failure_handler_ sequence deployment.
   If the deployment is successful, you see a message similar to the following in the system logs:

   Code Block
   INFO - DependencyTracker Sequence : _auth_failure_handler_ was added to the Synapse configuration successfully INFO - SequenceDeployer Sequence: _auth_failure_handler_ has been updated from the file: <API-M_HOME>/repository/deployment/server/synapse-configs/default/sequences/_auth_failure_handler_.xml

6. Invoke the API with the respective criteria in order to trigger the sequence. 
   In this example, let's view the menu on the PizzaShack API and invoke the API with an incorrect token.

   Localtabgroup

   Localtab active true id format-menu title Format Code Block curl -v -H "Authorization: Bearer <Access_Token>" http://localhost:8280/<API_name>/<version>/<context> Localtab id example-menu title Example Code Block curl -k -v -X GET "https://localhost:8243/pizzashack/1.0.0/menu" -H "accept: application/json" -H "Authorization: Bearer fb119e84-9542-3194-93dc-1ddddaaa1111" Localtab id SampleResponse title Sample Response Code Block * Trying ::1... * TCP_NODELAY set * Connection failed * connect to ::1 port 8243 failed: Connection refused * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8243 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=CA; L=Mountain View; O=WSO2; CN=localhost * start date: Jul 19 06:52:51 2017 GMT * expire date: Jul 17 06:52:51 2027 GMT * issuer: C=US; ST=CA; L=Mountain View; O=WSO2; CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. GET "https://localhost:8243/pizzashack/1.0.0/menu" -H "accept: application/json" -H "Authorization: Bearer fb119e84-9542-3194-93dc-1ddddaaa1111" Localtab id SampleResponse title Sample Response Code Block > GET /pizzashack/1.0.0/menu HTTP/1.1 > Host: localhost:8243 > User-Agent: curl/7.54.0 > accept: application/json > Authorization: Bearer fb119e84-9542-3194-93dc-1ddddaaa1111 > < HTTP/1.1 555 < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: GET < Access-Control-Allow-Headers: authorization,Access-Control-Allow-Origin,Content-Type,SOAPAction < Content-Type: application/json; charset=UTF-8 < Date: Fri, 04 Jan 2019 09:53:56 GMT < Transfer-Encoding: chunked < {"fault":{"code":900901,"type":"Status report","message":"Runtime Error","description":"Invalid Credentials"}}

...