In a previous blog we talked about the main sequence that will be called for call calls where there is no proxy defined. (e.g. calling /services/Depolyedproxy if the actual proxy is /services/Deployedproxy). We showed how to log the call in a database with a DBREPORT mediator and show on the console an error message using the LOG mediator. We said that we would extend this with a soap fault to the user using the MAKEFAULT or FAULT mediator.
But apart from the fault mediator there is also something called the fault sequence. It is the only sequence that can be defined both at the global ESB level (a default fault sequence) as well as a fault sequence per proxy or API that you are defining.
The default fault sequence can be found in the
wso2esb-4.9.0repositorydeploymentserversynapse-configsdefaultsequencesdirectory. Changing this sequence will create the default fault sequence that is invoked. An out of the box deployment of the ESB logs the error code and error message to the console and drops the message.
Like we did with the main sequence, we can also change the default fault sequence. In this case we will do the same and store the fault in a database / table.
<sql>insert into faults values (?,?,?)</sql>
<parameter expression="get-property('SYSTEM_DATE')" type="VARCHAR"/>
<parameter expression="get-property('ERROR_CODE)" type="VARCHAR"/>
<parameter expression="get-property('ERROR_MESSAGE')" type="VARCHAR"/>
This is a quick and dirty adaptation of the fault sequence because I basically used the same fields and database layout as used for the main sequence. The fields in the faults table are all defined as character fields with a length of 50 characters.
Here is the MYSQL code to create the database and table:
CREATE DATABASE faultseqcalls;
CREATE TABLE `faults` (
` date` varchar(50) DEFAULT NULL,
`errorcode ` varchar(50) DEFAULT NULL,
`error_message` varchar(50) DEFAULT NULL
When you want to create your own extension of each of these sequences (main and fault) you need to create a more fitting layout.
The fault mediator currently supports three types of formats or versions: SOAPL11, SOAP12 and plain old Xml (Pox).
<code (value="literal" | expression="xpath")/>
<reason (value="literal" | expression="xpath")>
I’ve decided to add a fault mediator the main sequence to give a soap message when a proxy , api or service is called that does not exist.
Because working with the main sequence can be annoying (you sometimes get errors when backing up the main sequence) I create the fault sequence as a standalone sequence that I call from the main sequence. I furthermore directly created it in the ESB. This because I wanted it to be directly accessible for this article and not part of a CAR.
To show what it looks like I copied this to Dev Studio. As you can see it is just a Fault Mediator in a Sequence.
The main sequence however has changed because of this new addition.
As you can see the log (that is part of the original main sequence is still there as is the Filter Mediator (that will let some undefined calls through) but a DBReport mediator and Sequence have been added. The sequence of course calls the Fault Mediator.
When I now use SOAPUI to call the non existing (AXIS2) service by adding ddd to a correct and existing ECHO service I get a SOAP Error Message in return. Informing me that there is indeed no service called /services/echoddd.
This is exactly what I wanted. I now get a soap11 message back.
Working daily with WSO2 products we sometimes encounter things that even we did not know yet, but in fact are so handy we want to share it with the whole world. We have created a new group of articles called WSO-2-EASY that will show some of best tips and tricks that will help you to either save time or create tidier code.