This documentation is for WSO2 API Manager 2.1.0 View documentation for the latest release.
Page Comparison - API Gateways with Dedicated Backends (v.1 vs v.2) - API Manager 2.1.0 - WSO2 Documentation

All docs This doc

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reviewed

We can extend Multiple Gateway environments feature  extend the multiple gateway environments feature by utilizing dynamic endpoint capabilities of WSO2 API Manager to have each gateway point to a different back-end endpoint. API Gateway is the actual runtime of the APIs to which that are developed and Published published from the API Publisher. WSO2 API Manager is capable of publishing APIs to different gateways were the Gateways where API users connect to those API Gateways in order to do the actual API calls through the applications to which they are subscribed. Refer Maintaining Separate Production and Sandbox Gateways for more information on publishing to multiple gateways. 

However, when the API publisher Publisher can only provide a single static Endpoint endpoint for an API in the implementation. Therefore, which ever the gateway that the API is deployed, the API  the API call is directed to a single endpoint in whichever Gateway the API is deployed in, as depicted in the diagram below.

But However, in most situations, you would want to have each Gateway proxying to a dedicated Back-End backend API. To provide that capability, WSO2 API Manager provides the ability to specify dynamic endpoint URLs at the time of specifying the API endpoint URL. This UEL will be is resolved at the runtime with the details  details (host and port) we specify in the statup specified at the startup of each gatewayGateway. With that  each gateway will point to dedicated backend  APIs Each gateway then points to a dedicated backend API, as depicted in the digram below.

Configuring

...

dynamic endpoints

Follow the steps below step to Configure configure a dynamic endpoint as the API endpoint.

  1. Start the WSO2 API Manager Server which server that includes the API Publisher Component component and create an API.
  2. Go to the implement stage of Implement tab of the API and replace Host the host and Port port of the API endpoint with {uri.var.host} and {uri.var.port} respectively, as shown below.
  3. Save and Publish publish the API. 

    Tip

    Refer Create and Publish an API for more information on creating and Publishing the API.

  4. Go to <AMNavigate to the <API-M_HOME>/repository/deployment/server/synapse-configs/sequences directory of each Gateway and create the following sequence.

    Code Block
    <sequence xmlns="http://ws.apache.org/ns/synapse" name="WSO2AM--Ext--In">
            <property name="uri.var.host" expression="get-property('system','host')" />
            <property name="uri.var.port" expression="get-property('system','port')" />
    </sequence>
    Note

    We use Java system properties which will be set are used at the server start-up process of each Gateway to resolve the variables which that are defined as properties in this sequence.

    Info

    Alternatively, you can resolve this host and port using a class mediator. To do that, follow the steps below steps as an alternative of to step 4.

    1. Create a java class extending the AbstractMediator class of org.synapse.core as shown below and create the jar JAR file out of it.

    Code Block
    import org.apache.synapse.MessageContext;
    import org.apache.synapse.mediators.AbstractMediator;
    
    public class EnvironmentResolver extends AbstractMediator {
    
        @Override
        public boolean mediate(MessageContext messageContext) {
    
            String host = System.getProperty("environment.host");
            String port = System.getProperty("environment.port");
    
            messageContext.setProperty("uri.var.host", host);
            messageContext.setProperty("uri.var.port", port);
    
            return true;
        }
    
        @Override
        public boolean isContentAware(){
            return false;
        }
    }

    2. Add the created jar into <AMJAR file into the <API-M_HOME>/repository/components/lib folder of each Gateway. You can download a sample jar JAR file created from here.

    3. Add the following sequence to <AMthe <API-M_HOME>/repository/deployment/server/synapse-configs/sequences folder of each Gateway.

    Code Block
    <sequence xmlns="http://ws.apache.org/ns/synapse" name="WSO2AM--Ext--In">
            <class name="org.wso2.carbon.env.EnvironmentResolver"/>
    </sequence>
    Note

     org.wso2.carbon.env.EnvironmentResolver is the fully qualified name of the class that contains the code responsible for converting system variables into properties. It is a special class we created which that needs to be extended from the org.apache.synapse.mediators.AbstractMediator class and requires overriding of the 'mediate' function. 

  5. Execute the following command when starting up each Gateway to set the system variables at the server start up from within the <APIM <API-M_HOME>/bin directory by replacing the following values.

    <ip_of_backend_environment><port_of_backend_environment>
    host IP of the Gatewayport where the Gateway is running in the dedicated machine or VM
    Code Block
    ./wso2server.sh -Dhost=<ip_of_backend_environment> -Dport=<port_of_backend_environment>
    Note

    If you have used the class mediator to configure API Gateways in step 4, use the command given below commands instead of the one above described in this step.

    Code Block
    ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>

    Now the Gateways have started with the dedicated backend host/port combinations.

  6. Invoke the API.

You will get receive the response from the API, which has is sent to through the dedicated backend through , from the Gateway that this API is published.