Random Learnings by Ralph Palomar

     Handling and processing large files via API can sometimes be challenging because the bytes of data need to be encrypted and sent over the network, which may have some bandwidth and security restrictions. However, in my experience it is still possible to send a moderately large file (less than 5 MB) using multipart/form-data POST request in Mule. This is possible because Mule supports streaming of data, which simply means that the whole data is NOT being read and loaded into memory; rather, the data are being read by chunks or buffers of a specific size in an efficient way. The HTTP Listener endpoint is one of those endpoints that support streaming. More technical details here .     File transfers of moderately large file size can be done in Mule. For very large files, I haven't explored this yet, but the most common solution in the past is using the secured FTP transfer. File transfers of very large files via API may be possible but may require a lot more worker size (maybe 1

 What is a Media Type?        Media Type is also known as MIME type, which stands for Multipurpose Internet Mail Extensions. It is a two-part identifier for file formats and contents transmitted over the Internet. Since APIs are network applications that are using the HTTP transport, media types are the identifiers that describe the request and response format that the API consumes and produces. You can indicate the media type in these HTTP headers: Content-Type and Accept. A common example of a media type is text/html; charset=UTF-8 , wherein text is the type and html is the subtype, which may also have optional parameters such as charset that indicate the character encoding, e.g. Unicode (8-bit, 16-bit), ASCII, etc.     Mule supports a lot of media types, not just XML or JSON. As per the MuleSoft documentation, below are the supported media types:     The great thing with Mule is that it is data agnostic, as long as you use one of the media/ MIME types in that list. Once the request

Exposing an API to be consumed by client applications entails a lot of challenges. Apart from a good API definition and documentation, you also need to ensure that the request payload submitted to your API endpoints are valid and conforms to the expected data structure. Although it is not required, I think some of the advantages to validate a request payload are: Establish a service contract which is a form of agreement between the service provider and the service consumer. This means that, in order to successfully consume an API, a client application needs to strictly follow a specification "for the request payload" called a data schema . Establish data integrity which ensures that all incoming data submitted to the API are "in a format that is expected". It doesn't make sense to process malformed data. For instance, if you are inserting data to a relational database, it would be more beneficial to first check mandatory (or required) fields before processing th

     DataWeave is the main expression language in Mule 4, and with the recent version 2.0, it is the sole transformation language in a Mule 4 application. DataWeave is a powerful and rich scripting language, which  supports a variety of useful functions for data manipulations and transformations. It employs a functional programming principle, which means that functions don't have states and side effects. DataWeave functions can also be called recursively (I have done some recursive functions before but will think of a simple concrete example).     If you want to read and study more about DataWeave, and familiarize yourself with the different supported functions, go to  https://docs.mulesoft.com/mule-runtime/4.2/dw-functions     The DataWeave related functions are organized into modules. There are core modules, string modules, binary, cryptography, and a lot more. DataWeave is quite extensible, and I think in future upgrades of Mule we will see additional modules that would address

     This article is about how to jump-start your Mule API development journey. It is assumed that you already know the prerequisites and have the fundamental Mule knowledge. If you're quite new to MuleSoft, API development, or integration in general, I would suggest to go through the official Mule documentation , which would greatly help you get a deep-dive about the platform. If you're entirely new to MuleSoft, I hope that this article will give you a conceptual overview about the platform.      The question I initially had when I was starting Mule development was "Is there a specific, standard, and consistent way of developing Mule APIs?" The answer is either YES or NO.       YES, because it establishes best practices, enables rapid development, and allows you to get past the "boilerplate codes" and be able to move on to the more important implementation of the business logic and requirements. Consistency also means readability in a way that other develop

You can write a Groovy custom function that can be used in Mule DataWeave (Transform Message). To do this, create a file with .mvel extension under src/main/resources, e.g. globalfunction.mvel. If you're familiar with Java, it is quite similar to Groovy, but with some differences such as type declaration is not required in Groovy and a statement doesn't have to be punctuated with a semi-colon as long as you write one statement per line. For example, we have the following Groovy function, which accepts a MongoDB ObjectId and converts it into a string value. This is useful when you just need to get the hexadecimal value and not the object itself, which gets serialized when transforming to JSON. def getObjectIdAsString(objectId) {     return ((org.bson.types.ObjectId) objectId).toString() }    In the Mule configuration file, add the below XML. You don't need to specify the complete path since src/main/resources automatically gets added to the classpath. <configur

If you have the REST & JSON Plug-in for TIBCO BusinessWorks, parsing and rendering a JSON string into XML is a straightforward task. We are often using XML in TIBCO, because XML is the most common format that is used to transform data using XSLT and XPath language. There are two ways we can parse and render JSON text: using an XML Schema, and using Java classes. Of course, XML Schema is already very handy, as we can always easily create one in TIBCO Designer. But, before we go to why we need to use Java classes, we need to examine first the nature of an XML Schema. An XSD describes the XML document in a strictly structured manner, which means that the sequence and nesting of the elements are important. However, for JSON, we cannot rely on the order of the elements, and we cannot force JSON to be that way. It’s just its character, and it maintains itself as an unordered collection of zero or more name/value pairs. That said, we cannot expect a JSON message to conform to the sp