Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


titleAdding a non-blocking send operation

In this example, the Send mediator, which is in the proxy service, transfers a file to a Virtual File System (VFS) transport endpoint, using the VFS transport. By default, VFS is a non-blocking transport, which means a new thread is spawned for each outgoing message. The Property mediator, which is added before the Send mediator, removes the ClientAPINonBlocking property from the message to perform the mediation in a single thread. This is required when you want to avoid out-of-memory failures that occur when the file that you are transferring is large.

Code Block
   <property name="ClientApiNonBlocking"
      <endpoint name="FileEpr">
         <address uri="vfs:file:////home/shammi/file-out"/>


Creating per-API extensions


When you invoke your REST API via a REST Client, configure that client to have a custom header (Authentication) for your basic authentication credential and configure the Authorization header to contain the bearer token for the API. When you  send the Authentication and Authorization headers, the Gateway drops the Authorization header, converts the Authentication to Authorization headers and sends to the backend.


Class Mediator is one specific example of mediation extension. When creating a class mediator, we are allowed to write a Java class which extends the org.apache.synapse.mediators.AbstractMediator class.

This class implements the mediate() function which access the message context and provide the facility to customize the mediation flow of the API. Through that we can read properties of the message context into variables and perform operations.

Code Block
    package samples.mediators; 
    import org.apache.synapse.MessageContext;
    import org.apache.synapse.mediators.AbstractMediator;
    import org.apache.axiom.soap.SOAPFactory;
    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
    import javax.xml.namespace.QName;
    public class SimpleClassMediator extends AbstractMediator {

        private String variable1 = xxx;       

        private static final Log log = LogFactory.getLog(SimpleClassMediator.class);
        public SimpleClassMediator(){}
        public boolean mediate(MessageContext mc) {
            // Do somthing useful..
            // Implementation of Reading the propertly values of Message context and modifying request / logging properties
            return true;
        public String getType() {
            return null;
        public void setTraceState(int traceState) {
            traceState = 0;
        public int getTraceState() {
            return 0;

        public void setVariable1(String newValue) {
        public String getVariable1() {
            return variable1;

Then we can export this class as a jar file and add as a library to <API-M_HOME>/repository/components/lib directory.

By refering this class with the fully qualified class name in a class mediator in the API as below, we can execute it in the insequence or outsequence of the API globally or per API as described above.

Code Block
<class name="samples.mediators.SimpleClassMediator">                
	<property name="propertyName" value="propertyValue"/>

If any properties are specified in the java class of the class mediator, the corresponding setter methods are invoked once on the class during initialization.


You can use the Class mediator for user-specific, custom developments only when there is no built-in mediator that already provides the required functionality, because maintaining custom classes incurs a high overhead. Therefore, avoid using them unless the scenario is frequently re-used and very user-specific.


Your class mediator might not be picked up and updated, if you use an existing package when creating it.