Tuesday, October 27, 2015

How to use Switch Mediator in WSO2 ESB

Whenever in ESB logic a conditional filter is required and based on the value of the filter a particular functionality needs to be executed, switch mediator can be used. This switch mediator is same like as we have for other programming language in java, .net, php etc. so overall concept is same in WSO2 as well.

In WSO2 ESB, switch mediator filters the XPATH or JSON. We can pass an expression value in it to filter the value and based on the value of an expression a case is executed if it is matched with filtered string.


You can add switch mediator by the UI configuration it comes in the Filter category.




There are some parameter you need to pass to use this Switch Mediator like Source Xpath and number of case as per your logic. At the last there is a default mediator option you can use that to execute if no match is found.



Example:

<switch source="get-property('GetServiceName')">
<case regex="GetEmployeeDetail">
<send>
<endpoint>
<address uri="http://localhost:8280/services/getEmployeeDetail"/>
</endpoint>
</send>
</case >
<case regex="GetDepartmentDetail">
<send>
<endpoint>
<address uri="http://localhost:8280/services/getDepartmnetDetail"/>
</endpoint>
</send>
</case>
<case regex="GetITHeadDetail">
<send>
<endpoint>
<address uri="http://localhost:8280/services/getITHeadDetail"/>
</endpoint>
</send>
</case>
<default>
<send/>
<drop/>
</default>
</switch>


In above example we are trying to call the different service based on the ‘'GetServiceName'’ parameter. If the string value of 'GetServiceName' variable is ‘GetEmployeeDetail’ then call ‘getEmployeeDetail’ service and if value is ‘GetDepartmentDetail’ then call ‘getDepartmnetDetail’ service. There is a default case in which we are dropping the response back to the client. If no case is found by the filtered parameter then default case is executed.

Monday, October 26, 2015

How to use drop mediator in WSO2 ESB

Drop mediator is used to stop the process. Once drop mediator is executed, it sends the Http 202 Accepted response to the client. No mediator will be executed written after drop mediator.


There are some scenario in programming like just stop the process and send response back to the client, drop mediator can be used.


Example:

<filter xpath="string-length(get-property('getBlogName'))='shriwithjava'">
<then> 
<send>
<endpoint>
<address uri="http://localhost:8280/services/getEpmList"/>
</endpoint>
</send>
</then>
<else>
<send/>
<drop/>
</else>
</filter>

In the above example we are trying to match the condition like is blog name is ‘shriwithjava’ then send it to get employee list service otherwise drop the message right there.

How to use property mediator in WSO2 ESB

WSO2 ESB provides Property mediator to use is in your code. It is like a variable in programming language. You can set a value into it or also you can remove value from it. If you have enabled the logs, you can see the property variable’s value coming into the logs at what stage what value is assigned for this this variable.

To use a property mediator you can edit a sequence and go to ‘’Add Child then Core then Property mediator as mentioned below.



You will get a below screen in which you can pass the property name, Action (Add or Remove) property type (String, Boolean, Integer, float, long etc.)


  • In Action you can set or remove a value of the property
  • In Set Action as : you can assign a value or can get a value from the expression
  • You can also get a value from other property by using expression="get-property('symbol')" expression.



You can see the property mediator value by putting logs in synapse.


Wednesday, October 14, 2015

How to use log mediator in WSO2 ESB

You can log all the information which is mediated in your ESB logic written in synapse. You can define the category of the logs, this is same as other programming language like DEBUG, ERROR, and INFO etc.

All the below category you can define in “log4j.properties” file location in below location.
wso2esb-4.0.3\lib\log4j.properties or \repository\conf\log4j.properties

  •  TRACE: It is similar to DEBUG but provide more information it is normally used in the time of deployment
  • DEBUG: It provides the most useful information when application is executed for debugging
  • INFO: It provides high level information
  • WORN: It generates the logs in case of harmful situation
  • ERROR: It provides error information in your application
  • FATEL: very severe error events that will presumably lead the application to abort

You can define the log level as well including Full, simple, header and custom. Custom is used only for the property mediator however full includes all attribute including “simple” log level

Example (Full):

<log level="full">
<property name="RequestId" expression="//swj:RequestId/text()" type="STRING" xmlns:swj="http://shriwithjavablogspot.co.nz/logpropertyexample/"/>
</log>

In this example we are trying to get the value of RequestId from the request payload, because property value is being fetched from the request expression so we need to pass xml namespace as well to get the value of RequestId.

Example (Custom):

<log level="Custom">
<property name="RequestId" expression="//swj:RequestId/text()" type="STRING" xmlns:swj="http://shriwithjavablogspot.co.nz/logpropertyexample/"/>
<property name=" RequestId" expression="get-property(RequestId)"/>
</log>

In above example we are trying to get again property value from expression and as well as from property mediator.

You can change your log setting in log4j.property file like INFO, DEBUG and ERROR etc. there are some other configuration like if you want to create another separate file you can put it into property file and you will see that another separation file will be created.

log4j.property File:

# Configure the service logger at INFO level. Writes only run-time/mediation-time audit messages
log4j.category.SERVICE_LOGGER=INFO, SERVICE_APPENDER
log4j.additivity.SERVICE_LOGGER=false
log4j.appender.SERVICE_APPENDER=org.apache.log4j.RollingFileAppender
log4j.appender.SERVICE_APPENDER.File=${carbon.home}/repository/logs/${instance.log}/wso2-esb-service${instance.log}.log
log4j.appender.SERVICE_APPENDER.MaxFileSize=1000KB
log4j.appender.SERVICE_APPENDER.MaxBackupIndex=10
log4j.appender.SERVICE_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.SERVICE_APPENDER.layout.ConversionPattern=%d{ISO8601} [%X{ip}-%X{host}] [%t] %5p %c{1} %m%n



Tuesday, October 13, 2015

WSSecurityEngine: Invalid timestamp The security semantics of the message have expired

This issue normally comes when your Client machine and server machine timing is not in sync. When request reaches to server with different time then server expire the message and sends the same response with error message.
To avoid this error please make sure your client time and server time should be in sync.


Logs:


<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The message has expired (WSSecurityEngine: Invalid timestamp The security semantics of the message have expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>