The API Gateway has a default mediation flow, which you can extend by adding custom mediation sequences. You In API Manager there are 3 default sequences engaged as
fault. You create a custom mediation sequence either manually or using WSO2 tooling support (i.e., WSO2 Developer Studio), a tool such as the WSO2 API Manager Tooling Plug-in, and then engage it per API or globally to all APIs of a specific tenant. With custom mediation sequences you can modify the default mediation flow for different usabilities according to your requirement. Log the mediation flow, execute operations on Message context properties, to customize, format the requests and responses are some of them.
|Table of Contents|
Please note that following mediators are not usable within custom sequences since they are not supported by API Gateway custom mediations.
Default mediation flow
The address endpoint of the WSO2 API Manager cannot be constructed dynamically. To achieve the requirement of a dynamic endpoint, you can use the default endpoint instead. The default endpoint sends the message to the address specified in the To header. The To header can be constructed dynamically. For example,
In this example, you have constructed the
service_ep property dynamically and assigned the value of this property to the To header. The default endpoint sends the message to the address specified in the To header, in this case,
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.
Creating per-API extensions
You can also create a mediation sequence manually and upload it from the API Publisher itself. For instance, you can copy the above default mediation flow content into an XML file. In the Implement tab of the API, select the Enable Message Mediation check box and click Choose File in the the Upload In Flow or or Upload Out Flow field (for the example above, it needs to be uploaded to the
In flow). Once the file is uploaded, save and publish the API. When you invoke the API, the request is sent to the endpoint referred to in the To header.
Create manually and save in the file system
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.
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.
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.