Few weeks back I was working on a proof of concept to demonstrate a long running workflow based orchestration scenario. More about the architecture behind the PoC can be found at WSO2 solutions architecture blog. But this blog is not related to the architecture, this is simply about delivering the proof of concept in a completely contained environment.
What inspired me to do this: As a day to day job I happened to show how enterprise solutions architectures work in real world. I cook up a use-case in my machine, often with couple of WSO2 products (like the ESB/DSS/DAS/API-M) and some other non-WSO2 ones, then demonstrate the setup to who ever the interested party. I always thought it would be cool if the audience can run this themselves after the demo without any hassle (They can run it even now with bit of work 😉 but thats time someone can easily save). The other motivation is to save my own time by re-using the demos I’ve build.
Docker ! Docker ! Docker !
I’ve been playing with docker on and off, thought its a cool technology and I found that creating and destroying containers in a matter of milliseconds is kind of fun 😀 okey jokes aside I was looking for a way to do something useful with Docker, and finally found inspiration and the time.
I took the orchestration PoC (Bulk ordering work-flow for book publishers) as the base model that I am going to Dockerize.
I made sure that I cover my bases first with making everything completely remotely deployable. If am to build a completely automated deployment and a start up process I shouldn’t configure any of the products from the management UI.
There seems to be a false alarm spreading over the online forums that WSO2 ESB cannot handle messages larger than 16K and results a corrupted response. This situation occurs only when a user enables one of the synapse properties which is disabled by default.
Streaming XPATH option is the aforesaid culprit, which is a newly introduced feature to optimize the performance in different message filtering / routing scenarios. However this does not effect the default workings of WSO2 ESB which does handle large messages successfully in thousands of enterprise deployments with the default XPATH implementation that ships out of the box.
As any new component achieve perfection with time, WSO2 ESB team have fixed all reported issues against streaming XPATH component (in ESB v4.8.0) and thrives to be the fastest ESB and the integration platform.
Recently was working on a project where I had a to read an XML file from an FTP location, transform it and expose it as an API. Used WSO2 ESB 4.6.0 for this usecase; and I thought of documenting it for later reference. So here it goes
First the proxy that read the file from FTP and dump it to a defined location, (VFSProxy.xml)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters