WSO2 ESB - How to check whether a string is encoded or not?

The following sample demonstrate how to encode a string in WSO2 ESB and how to check whether a string is encoded or not.

<property name="string" value="abcd"/>
<property name="encodedString" expression="base64Encode('abcd')"/>
<log level="custom">
  <property name="encodedString" expression="get-property('encodedString')"/>
</log>
<filter source="get-property('encodedString')"
     regex="^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)$">
  <then>
     <log level="custom">
        <property name="encoded?" value="yes"/>
     </log>
  </then>
  <else>
     <log level="custom">
        <property name="encoded?" value="no"/>
     </log>
  </else>
</filter>

This is based on the regular expression given here to check whether a string is encoded or not.

WSO2 ESB - How to print the current thread id in proxy?

You might want to print the current thread id for testing purposes in WSO2 ESB. It might be useful in cases where you want to make sure that the same thread is used for all the operations and no new threads were created. You can add following script mediator in your proxy to print the current thread id.

    <script language="js">java.lang.System.out.println(java.lang.Thread.currentThread().getId());</script>

WSO2 ESB - How to put the current thread into sleep in proxy?

You can add the following script mediator in your proxy to sleep the current thread.

    <script language="js">java.lang.Thread.sleep(10000);</script>

WSO2 ESB - Dynamic JMS Endpoint

Address endpoint doesn't support dynamic endpoints. Hence if you want to have dynamic endpoint for your JMS queue, you can use default endpoint together with a "To" header which you can set dynamically. Here is a sample JMS proxy.

<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="StockQuoteProxy"
       transports="http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <property name="OUT_ONLY" value="true"/>
         <property name="sendToThisQueue" value="SimpleStockQuoteService"/>
         <header name="To"
                 expression="fn:concat('jms:/', get-property('sendToThisQueue'), '?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&amp;java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;java.naming.provider.url=tcp://localhost:61616')"/>
         <send>
            <endpoint name="dynamicQueue">
               <default>
                  <timeout>
                     <duration>300000</duration>
                     <responseAction>fault</responseAction>
                  </timeout>
                  <suspendOnFailure>
                     <errorCodes>-1</errorCodes>
                     <initialDuration>0</initialDuration>
                     <progressionFactor>1.0</progressionFactor>
                     <maximumDuration>0</maximumDuration>
                  </suspendOnFailure>
                  <markForSuspension>
                     <errorCodes>-1</errorCodes>
                  </markForSuspension>
               </default>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/>
   <description/>
</proxy>          

The idea behind is that you can set "To" header dynamically and the default endpoint will send the messages out to the endpoint found in "To" header.

WSO2 ESB - Logging VFS Transport Logs to a Different Log File

If you enable DEBUG logs for VFS transport, it might poison the default wso2carbon.log file. Instead, you can do the following configurations to write VFS transport logs to a different log file, while these logs won't be written to default wso2carbon.log

1. Add the following configurations to $ESB_HOME/repository/conf/log4j.properties file

log4j.logger.org.apache.synapse.transport.vfs=DEBUG, CARBON_VFS_LOGFILE
log4j.additivity.org.apache.synapse.transport.vfs = false
 
log4j.appender.CARBON_VFS_LOGFILE=org.wso2.carbon.logging.appenders.CarbonDailyRollingFileAppender
log4j.appender.CARBON_VFS_LOGFILE.File=${carbon.home}/repository/logs/${instance.log}/wso2carbon-vfs${instance.log}.log
log4j.appender.CARBON_VFS_LOGFILE.Append=true
log4j.appender.CARBON_VFS_LOGFILE.layout=org.wso2.carbon.utils.logging.TenantAwarePatternLayout
log4j.appender.CARBON_VFS_LOGFILE.layout.ConversionPattern=TID: [%T] [%S] [%d] %P%5p {%c} - %x %m {%c}%n
log4j.appender.CARBON_VFS_LOGFILE.layout.TenantPattern=%U%@%D [%T] [%S]
log4j.appender.CARBON_VFS_LOGFILE.threshold=DEBUG

2. Restart ESB
3. A new wso2carbon-vfs.log file will be created in $ESB_HOME/repository/logs directory.

WSO2 ESB and RabbitMQ

The Scenario of Interest

1. Client submits an API request with a correlation id and a call back queue to RabbitMQ
2. ESB receives the request from RabbitMQ
3. ESB forwards the request to Endpoint
4. ESB receives the response from Endpoint
5. ESB if receives a response from Endpoint, publishes it at the call back queue specified in the request with the correlation id of the request
6. ESB if doesn't receive a response in timely manner posts an error in the Dead Letter MQ with the correlation id of the request
7. Client receives the response from the call back queue
8. Since request and response have the correlation id, client knows which response is for which request

* Configure the ESB to use rabbitmq transport as explained in https://docs.wso2.com/display/ESB481/RabbitMQ+AMQP+Transport

* Start axis2 server and deploy SimpleStockQuote Service as explained in https://docs.wso2.com/display/ESB481/Setting+Up+the+ESB+Samples

* Go to the management console of ESB and click on 'Source View'

* Copy paste the following synapse configuration into the 'Source View" and click update

* Now you have deployed a rabbitmq proxy service which will,
      consume messages from a queue called "rpc-queue"
      calling the back end simple stock quote service for the symbol found in that request message
      receiving response from back end
      setting the correlation id of the request to the response
      publishes the response to the call back queue found in the request
      if ESB is not getting any response from back end, it will publish an error message, with the correlation id of the request, to a queue called "dead-queue"

* Now run the following RPCClient.java

* Now login to the management console of the rabbitmq server (http://localhost:15672)

* You will see that there is message in your call back queue. This message is the response sent by the ESB.

* Now run the following RPCReceiver.java

* You will get the message in your console. This is the message RPCReceiver pulled from your call back queue. This will have the correlation id of the request too.

* Have a look at in rabbitmq management console, the previous message will not be there, as it is pulled by the RPCReceiver.

* Now shutdown axis2 server

* Run RPCClient.java

* Have a look at rabbitmq management console, you will find that there is a message in a queue called "dead-queue". Since the back end service is unavailable, ESB sends the response to dead queue with the correlation id of the request

I will explain this scenario in detail soon.