Mule is typically used on the receiving end of service requests. Mule flows, for instance, are generally initiated by external events like a JMS message being sent to a queue, a POSTed HTTP request, or the firing of a Quartz trigger. Since Mule is usually deployed as a server this behavior should be expected. What isn’t so obvious, however, is using Mule as a client of these services. We’ll see in this blog post how MuleClient can be embedded in a non-Mule application to send and consume messages as a client.
Tag: Mule ESB
Hello friends! How’s it going?
Has the following ever happened to you? You show up to work one morning and your boss tells you, “I need you to take this data and turn it into XML.” Well, this has happened to me, and in this blog post I’m going to show you how to do this quickly.
The architecture of Mule is driven by the principles of Industrial Best Practice as outlined in the well-known Enterprise Integration Patterns which have identified the most common building blocks for every integration problem. These building blocks are what make up Mule Flows, the executable units inside Mule Applications. No matter what the problem, wiring them together into an integration solution is extremely easy and by exploiting the power of Mule’s native support for the Drools Rules Engine, the Integration Developer has a very powerful set of tools to tackle even the most complex of integration problems with the greatest of ease. With this post I hope to be able to demonstrate this to you!
Today we’re interviewing Geoff Clitheroe, GeoNet Systems Development Manager at GNS Science in New Zealand. What does this beautiful but quake-prone island country have to do with Mule? This is where Geoff’s work comes into play: he’s leading a team of developers with whom he’s been building GeoNet, an advanced geological hazards monitoring system. And Mule is at the core of it.
If you are looking to get started with Mule ESB quickly, we have lots of resources to get you moving. First off, you should be aware we have a free self-paced training course for people looking to get to grips with Mule through a structured program.
We also have video tutorials for the major concepts in Mule. You can download Mule and Mule Studio to get started. The following tutorials are a great place to start. Each session introduces a core concept namely endpoints, components, filters, transformers and the Mule message. Note that these tutorials are applicable to Mule ESB and Mule iON.
Why do I want this?
This connector is mainly aimed to situations in which systems integration requires executing shell commands into a remote system. Examples are:
- Config changes (passwords, permissions, accounts, etc)
- Resource provisioning
- File System operations on non FTP-mapped drives or folders
As evident by some prominent web applications PHP remains a popular choice when implementing the front-end of a web application. PHP’s lacks a bit, however, when it comes to implementing the backend of such applications. While some very nice frameworks are beginning to fill this gap, the Java ecosystem is often a better choice for implementing the backend of a PHP application.
Despite this, however, integrating PHP and Java isn’t a straightforward task. A robust PHP implementation for the JVM doesn’t exist. HTTP based protocols like SOAP and REST can work, but we usually want something reliable for messaging behind the firewall. JMS might seem like an obvious answer, but most brokers only support Java. Stopgaps like Stomp also exist but, it too, isn’t a reliable transport. What we really need is a reliable transport that works natively with PHP and Java.
We often see the need to reuse a component configuration between 2 applications deployed to Mule. For example, let’s say you have two Mule applications deployed in your Mule server. The first one, called AppA, gets information from Salesforce and stores it in a database. The second AppB modifies your Salesforce campaign information. Both applications share the same Salesforce credentials, so what happens if those credentials change? (for example, because you are switching from the SFDC sandbox to the live instance) You need to modify both applications because you have your Salesforce cloud connector configuration duplicated.
The other day I helped a customer figure out a little XPath problem: they had an XML document and wanted to process it depending on an XPath expression. Here’s the Mule config that shows what we were trying to achieve:
Last month we released Mule 3.3 M1, our first milestone on the way to Mule 3.3. While for production you should use Mule 3.2.1, we hope these milestones are a great way to play around with the latest and greatest features. This is a great opportunity to provide feedback and have an impact on what we are doing for the Mule 3.3 release.