The enterprise edition of Mule ESB 2.2.2 has been released and is now ready for download. This release is the most stable release of Mule to date and includes over 100 bug fixes, the most significant of which are listed here. We have also released version 1.0 of Mule High Availability, which we blogged about last month when we first made it available for customers to try out.
SAP users, rejoice! Our esteemed partners at Osaka Gas Information System Research Institute Co., Ltd (OGIS) in Japan have created the SAP transport for Mule 2, available for download from MuleForge.
Yuji Yamano, the project lead on the SAP transport, explained how it works:
“The SAP transport provides connectivity with SAP ERP 6.0. Users can send an XML message that is equivalent to a BAPI function request and receive an XML message that is equivalent to a BAPI function response.
Do you have high availability requirements for your Mule application? Mule High Availability provides basic failover capability for Mule. When the primary Mule instance become unavailable (e.g., because of a fatal JVM or hardware failure or it’s taken offline for maintenance), a backup Mule instance immediately becomes the primary node and resumes processing where the failed instance left off. After a system administrator has recovered the failed Mule instance and brought it back online,
When you’re working with Mule, you’re usually concerned about responding to messages that come in and making sure you’re routing them correctly from service to service. But what if you just want to trigger a service component on a set interval? What if its method doesn’t require any incoming data at all?
The Mule framework provides all the extract/transform/load (ETL) tools you need for connecting to data sources, extracting and transforming data, and passing it along on any number of channels.
This is a guest blog entry by David Dossot, co-author of the soon-to-be-released book Mule in Action.
I recently had the opportunity to integrate a bunch of REST resources and came to further appreciate what I consider to be Mule’s power tools: scripting and expressions (there is a third tool in my power box, Spring, but I won’t discuss it here).
Scripting, and more precisely Groovy,
Mule provides different approaches to handling errors. You can set exception strategies for connectors, models, and individual services. You can use the exception router to specify where the message goes when an error occurs. And you can use the exception type filter for fine-grained control. Following is an introduction to these approaches.
When wiring your Mule services together, new users sometimes get confused about when to use an outbound router and when it’s sufficient to simply get a reply. Following is a description of the three message styles you can use to get a response from your Mule services.
The Mule development team is pleased to announce that Mule 2.2.0 is now available for download. This release includes:
Note that this approach is no longer recommended if you are using Mule 3.0.0 or later. Instead you can use the ObjectStore. This allows use to store objects in memory, in a persistent store or across Mule HA clusters automatically. You can learn more about Mule 3.0 here and download it here.
Recently, there was a great question on one of the Mule mailing lists about where to store runtime data that can be used across the app.
