This documentation is for WSO2 Enterprise Service Bus 3.0.0. View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

Synapse supports Mediators implemented in a variety of scripting languages such as JavaScript, Python or Ruby. There are two ways of defining the Script Mediators:

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.

  • Achieve the same functionality via a Class mediator.
  • If the original message consists of repetitive sections, you can use the Iterate mediator to generate a relatively small payload using those repetitive sections. This will then allow you to use the Script mediator.

1. With the script program statements stored in a separate file, which is referenced via the Local or Remote Registry entry.

 2. With the script program statements embedded inline within the Synapse configuration.

Synapse uses the Apache Bean Scripting Framework for the scripting language support, any script language supported by BSF may be used to implement the Synapse Mediator. With the Script Mediator you can invoke a function in the corresponding script. With in these functions, it is possible to access the Synapse predefined in a script variable named "mc." This "mc" represents an implementation of the MessageContext, named That contains following additional methods that can be accessed within the script by mc.methodName.

  • public Object getPayloadXML() - Gets the XML representation of SOAP Body payload.
  • public void setPayloadXML(Object payload) - Sets the SOAP body payload from XML.
  • public void addHeader(boolean mustUnderstand, Object content) - Adds a new SOAP header to the message.
  • public Object getEnvelopeXML() - Gets the XML representation of the complete SOAP envelope
  • public void setTo(String reference)
  • public void setFaultTo(String reference)
  • public void setFrom(String reference)
  • public void setReplyTo(String reference)

Implementing a Mediator with a script language can have advantages over using the built in Synapse Mediator types or implementing a custom Java class Mediator. The Script Mediators have all the flexibility of a class Mediator with access to the Synapse MessageContext and SynapseEnvironment APIs, and the ease of use and dynamic nature of scripting languages allows rapid development and prototyping of custom mediators. An additional benefit of some scripting languages is that they have very simple and elegant XML manipulation capabilities, for example, JavaScript E4X or Ruby REXML, so this makes them well suited for use in the Synapse mediation environment. For both types of script mediator definition the MessageContext passed into the script has additional methods over the standard Synapse MessageContext to enable working with the XML in a way natural to the scripting language. For example when using JavaScript getPayloadXML and setPayloadXML, E4X XML objects and when using Ruby, REXML documents.


Script Mediator Using a Script of the Registry
<script key="string" language="js" [function="script-function-name"]/>

The attributes of of the <script>:

  • "key" - The registry key to load the script.
  • "language" - Specifies the scripting language of the script code (e.g. "js" for Javascript, "rb" for ruby, "groovy" for Groovy, "py" for Python..).
  • "function"  - Optional attribute defining the name of the script function to invoke, if not specified it defaults to a function named "mediate." The function is passed a single parameter, which is the Synapse MessageContext. The function may return a boolean, if it does not, then true is assumed and the script mediator returns this value.
Script mediator using a In-lined script
<script language="js"><![CDATA[...script source code...]]><script/>

UI Configuration

Script Type
  • #Inline - Specifies the script inline.
  • #Registry - Stores the script in registry and refer it using the key.
If Inline Selected

The following options are available:

  • Language - Choose from variety of scripting languages supported:
    • JavaScript
    • Groovy
    • Rooby
  • Source - If inline selected as the Script type, specify the source.
If Registry Selected

Following options are available:

  • Function - Function of the script language to execute.
  • Key - Registry location of the source. You can click on the "Configuration Registry" or "Governance Registry" link to choose the source from the "Registry Tree". See more information in Registry Browser and Namespace.
  • Include Keys - Scripts sources to be included.


You can configure the Mediator using XML. Click on "switch to source view" in the "Mediator" window.



<script language="js"><![CDATA[mc.getPayloadXML()..symbol != "IBM";]]><script/>

The above configuration is an example of an inline mediator using JavaScript/E4X which returns false if the SOAP message body contains an element named symbol which has a value of IBM would be:


<script language="js"

In the above example, script is loaded from the registry by using the key repository/conf/sample/resources/script/test.js. The script is written in Java script. The function to be invoked is testFunction. As example for test.js shown in the bellow.


function testFunction(mc) {
     var symbol = mc.getPayloadXML()..*::Code.toString();
        <m:getQuote xmlns:m="http://services.samples/xsd">

  • No labels