WSO2 ESB Dynamic End Point Resolution

From WSO2 ESB 4.7.0 onwards, support dynamic end point resolutions.

If you have multiple deployment environments (DEV, QA, Production), then you may end up having many endpoints and will have to change them once you migrate your synapse configs to other environment. As a simple solution for this time consuming problem (for Call out mediator and send mediator only), you can initialize end points as jvm parameters at the server start up.

Ex:

  1. SEND Mediator

    <send>
                <endpoint name="MyEp"
                          template="endPointTemplete"
                          uri="http://{system.prop.bpm.stock.host}:{system.prop.bpm.stock.port}/services/SimpleStockQuoteService"/>
             </send>

    You have to create a endpoint template in order to use this feature for send mediator. When you start the ESB, you can initialize the {system.prop.bpm.stock.host} and {system.prop.bpm.stock.port} by using JVM parameters as follows. And then those end points will be initialized correctly.

    -Dbpm.stock.host=.............    - Dbpm.stock.port=..................

  2. CALLOUT Mediator
Callout mediator will be same as send mediator. you can initialize the parameters with jvm parameters

   <callout serviceURL="http://{system.prop.bpm.stock.host}:{system.prop.bpm.stock.port}/services/SimpleStockQuoteService"
                  action="urn:getQuote">
            <source xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
                    xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
                    xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
            <target xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
                    xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
                    xpath="s11:Body/child::*[fn:position()=1] | s12:Body/child::*[fn:position()=1]"/>
         </callout>



Comments

Post a Comment

Popular posts from this blog

WSO2 ESB Removing full soap header using enrich mediator.

WSO2 ESB supports many mediators, and we can use them to achieve most of our use cases. The following message template illustrates the structure of a SOAP Envelope: <soap:Envelope   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Header> <!-- optional -->     <!-- header blocks go here... -->   </soap:Header>   <soap:Body>     <!-- payload or Fault element goes here... -->   </soap:Body> </soap:Envelope> Even though soap header is optional, you might receive the soap envelop with soap headers. And you might need to remove the soap header element including <soap:Header></soap:Header> element. You can achieve this by using enrich mediator and payload factory mediator. We first extract the body from the soap envelop and assign it to a property using enrich mediator. Then we create an empty soap envelop using payload factory. At last enrich mediator is again used to put the soap b
Read more

Getting started with WSO2 Device Cloud APIs

Image
Introduction WSO2 Device Cloud is the latest addition to WSO2’s Cloud offering. It aims to provide device integration and management to rest of the WSO2 cloud. As of now, it allows integrating and managing Android & iOS powered devices. Device Cloud offers an UI to manage connected devices. Fig 1: Device Management Dashboard Page on Device Cloud Fig 2: Listing of all registered devices But the functionality is not limited to a web application. All device management capabilities are offered as OAuth2 protected REST APIs as well.   This tutorial explains how to make programmatic use of these APIs. In order to proceed with examples, you need to have a WSO2 Cloud account ( https://cloud.wso2.com ).  If you do not possess an account please use the following url to register one. https://cloudmgt.cloud.wso2.com/cloudmgt/site/pages/index.jag   API Store All apis related to device management are available in the API Store part of WSO2 Cloud. https://api.
Read more

Running a Standalone WSO2 IoT Server.

WSO2 IoT Server  can be run on single instance with simple configurations.  WSO2 IoT server  consists of 3 major services. IoT Core — This service includes all the major device management capabilities such as operation, policy management etc. It also includes the security and API management capabilities. Analytics — This service includes components for data gathering and analysis in both real-time and batch. It also includes the capability to do machine learning as well complex event processing and fraud detection. Broker — This service acts as the message exchanger between server and devices. By default, WSO2 IoT server uses OAuth as the security mechanism. When a user login into the devicemgt user interface, it uses the OAuth token to validate the user in the underlying infrastructure. It supports few OAuth grant types and by default devicemgt application user the JWT token grant type. And by default WSO2 IoT Server runs as with the hostname as localhost. If you do not
Read more