Skip to main content

WSO2 ESB learning part1-Usage of a class mediator in a makeFault mediator

Class Mediator-The class mediator creates an instance of a custom specified class and sets it as a mediator. The class must implement the org.apache.synapse.api.Mediator interface.For more info

makeFault mediator-The fault mediator transforms the current message into a SOAP fault message.but does NOT send it. The mediator needs to be invoked to send a fault message created this way.For more info

Sample makeFault mediator

Below is the sample fault mediator that we are going to use in ESB sequence.


Creating a new class mediator

There is a good article on how to create a new class mediator which can be found here.Hence I'm not going to repeat those steps.But for your easier,i'll give the overview of a class mediator.Any class mediator must have to extend 'AbstractMediator' abstract class and hence such a mediator need to implement the method 'mediate()'.The purpose of creating the class mediator here,is to set the property value 'ERROR_CODE' which is going to use as the fault code value in above makeFault mediator.How we have done it using the class mediator is shown as below.
package org.wso2.carbon.mediator;


import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;
import javax.xml.namespace.QName;

public class SynapseMessageContextMediator extends AbstractMediator{
public boolean mediate(MessageContext messageContext) {
QName qname=new QName("http://www.w3.org/2003/05/soap-envelope","soap12Env:Receiver");
messageContext.setProperty("ERROR_CODE",qname);
return true;

}
}
Since ESB supports SOAP 1.2,based on SOAP 1.2 specification,the fault code value should contains the same prefix of the SOAP envelope namespace.Hence we have set 'ERROR_CODE' property value as a QName,which has a namespace and a prefix.

How to make usage of created class mediator into the makeFault mediator.

To do this we have to add above both class mediator and fault mediator into synapse.xml file.Then add a log mediator exactly after the makeFault mediator.Then once we have accessed http://localhost/8280 we can see the SOAP fault[which follows SOAP 1.2 specification] which is corresponding to the above created makeFault mediator in ESB server log as below.



You can see the above soap envelope fault code value has set to 'soap12Env:Receiver' by using the class mediator we have created.






Comments

Popular posts from this blog

Convert an InputStream to XML

For that we can use DocumentBuilder class in java. By using the method parse(InputStream) ; A new DOM Document object will return. InputStream input; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document dc= parser.parse(input); In the above code segment,by using the created Document object,the corresponding XML file for the inputStream can be accessed. References: http://www.w3schools.com/dom/dom_intro.asp http:// download.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html

CORS support from WSO2 API Manager 2.0.0

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources  on a web page to be requested from another domain outside the domain from which the first restricted resource was served. For example, an HTML page of a web application served from http://domain-a.com makes an <img src >  request for a different domain as 'domain-b.com' to get an image via an API request.  For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts as in above example and only allows to make HTTP requests to its own domain. To avoid this limitation modern browsers have been used CORS standard to allow cross domain requests. Modern browsers use CORS in an API container - such as  XMLHttpRequest  or Fetch - to mitigate risks of cross-origin HTTP requests.Thing to  note is it's not only sufficient that the browsers handle client side of cross-origin sharing,but also the servers from which these resources getting need to handl

[WSO2 AM] APIStore User Signup as an approval process

In previous versions of WSO2 APIManager before 1.6.0, it was allowed any user who's accessible the running APIStore come and register to the app.But there will be requirement like,without allowing any user to signup by him/her self alone,first get an approve by a privileged user and then allow to complete app registration.Same requirement can be apply to application creation and subscription creation as well.To fulfill that,we have introduced workflow extension support for  WSO2 APIManager  and you can find the introductory post on this feature from my previous blog post on " workflow-extentions-with-wso2-am-160 " . From this blog-post,I'll explain how to achieve simple workflow integration with default shipped resources with  WSO2 APIManager 1.6.0 and WSO2 Business Process Server 3.1.0 with targeting "user-signup" process. Steps First download the WSO2 APIManager 1.6.0[AM] binary pack from product download page . Extract it and navigate to