Introduction Message stores in WSO2 ESB is important in implementing various scenarios like store & forwarding, and reliable delivery. They can be used to persist messages during mediation or even after. Currently synapse uses in-memory message stores, which is incapable of persists after execution. It is also consuming memory too. JMS message stores can save messages, but […]
Tag Archives: ESB
One of the most often-asked questions we receive is “I want to add my custom DLLs into a separate folder instead the instance folders root; how do I do that?” A DLL is a method to encapsulate logic for re-use. In many cases, you may have existing logic in a DLL or rather than having large amounts of code in a Business Process Step, you may elect to host your code in a DLL. In this blog post, I’m going to address that question in detail. For purposes of this post, we’ll assume we are working with a 64 bit instance named DEFAULT. To understand where to make the necessary changes, you have to first understand how the various Neuron ESB EXE’s are configured.
The main reason you would want to host your DLLs in a custom folder is to make deployments easier. Otherwise, you need to host your DLLs in the instance root (along with all of the DLLs Neuron ESB requires) or the Global Assembly Cache (GAC). For the record, our recommended guidance is to avoid using the GAC!
If you have been playing around with integration frameworks, you are probably aware of Apache Camel, as it is one of the two big open source players together with the Spring Integration framework. While benchmarking Talend ESB and Redhat Fuse ESB products, which both include Apache Camel in their stack, I had the opportunity to dive a bit more into the concepts of the framework and figured there was some interesting material for a blog post !
The purpose of this post is to provide some guidelines to build a custom Camel component for your enterprise integration needs. Our example will show how to poll an external JSON-based REST API – in this case, the Feedly API – to periodically retrieve and process information – in this case, to log retrieved RSS feed titles.
This post is the application of the IoT reference architecture shown in the previous post about Internet of things Arduino Android and ESB. What if we want to read a remote sensor connected to arduino board using our smartphone? As explained previously, we can connect directly our Android smartphone to arduino and read the sensor data or we can use a different approach where there is an Enterprise Service Bus (ESB) that stands in the middle between the arduino board and the smartphone. Even if the system is a little bit more complex as stated in the previous post using ESB we have a lot of advantages. It is time to show things work:
- an ESB proxy using WSO2 ESB that send HTTP request to arduino board and transforms response from arduino board to our smartphone
- Arduino Webserver that handle HTTP connection and read the temperature sensor
- Android app that shows the temperature value in our smartphone
Every integration architect or developer should be familiair with Enterprise Integration Patterns (EIP)as described by Gregor Hohpe and Bobby Woolf. One of the patterns is the ‘Content Message Filter’ (not to be confused with the Message Filter pattern).
There are multiple ways to achieve this in WSO2 with different Mediator. One way is using the XSLT Mediator where you can simply use an XSLT to do the filtering. The other one (not so obvious based on the name of it) is the Enrich Mediator.