Given the ever broadening capabilities and functionality of Anypoint Platform, even the most experienced MuleSoft developers will be challenged to remember all the features and tricks the product suite provides. Especially on fast-paced implementations, one can easily be caught up with the ebbs and flows of the daily project tasks and ironically, forget to leverage that one tool that can really help with productivity – documentation. In services, we often get questions that our documentation often does a better job of answering. There are dozens of examples; we have picked just a couple below that we’ve been asked lately.
The first example is about session variable. Most developers are well aware that session variables persist through the entire message lifecycle. However, some often forget about this part in the documentation:
… a variable that is tied to the current message for its entire lifecycle, across multiple flows, applications, and even servers…”
The example here demonstrates how session variables can travel across servers. There are two independent Mule applications. The first one sets a session variable, then publish it to a JMS queue.
We are using ActiveMQ but all other JMS brokers behave the same way. The second application receives messages from the same queue.
Note that the applications and ActiveMQ can reside on three different servers, in three different networks. As shown in the screenshots below, the session variable was propagated across.
This is a powerful capability for transmitting information across, at the same time, one must be careful with what information is being shared when sending payloads outbound. Below is a screenshot of how the message will appear in the JMS admin console.
The second example is around Anypoint Connectors. For many Anypoint Connectors, connection parameters can be passed in at the core operation calls level, in addition to setting it in the configuration element. This is a very useful feature that can significantly streamline your Mule applications if you need to process messages the same way from the same endpoints but with different credentials. Using the Saleforce.com Connector as an example, the document states:
Connection Parameters: These are only required if you didn’t specified them at the configuration element. They are also useful for overriding the values of the configurations or even if you need to extract them from the Mule message since they support expression evaluation.
The following is a simple Mule app to demonstrate this handy feature. In the app, we use the same flow to retrieve information from two different Salesforce.com organizations.
Using this pattern, a Mule app can easily store the credentials in a database or encrypted file, and dynamically retrieve data from as many Salesforce.com organizations as needed, as shown in the results:
These are just a couple of examples of the many things that we developers encounter daily that our documentation does a really good job of addressing. So whether you are just starting on the journey of Mule implementation or already way down the road, please keep our documentation in mind. It can significantly smoothen your ride along the way!