Mulesoft Development Course - Part I

Development

It took a while to get everything set up for the Mulesoft Development course, with the following being required:

  • Anypoint Studio
  • Anypoint Platform account (separate to the training account)
  • Salesforce account
  • Advanced REST Client (Probably wasn’t needed, because I already had Postman installed)

There are a few things to be aware of:

  • A considerable amount of disk space is required for Anypoint Studio and the training files. I reckon it’s somewhere around 4GB.
  • Anypoint Studio should be downloaded and installed to a root directory, otherwise there’ll be long filepath errors during installation. The same applies to the training files.
  • The Salesforce developer account requires a password reset link to access the first time. The link won’t work from a corporate Outlook account, so a personal email address must be used.
  • The API Manager view is stuck in a constant reload loop when it’s first accessed. The fix for this is to assign all API Manager permissions (Design and Sandbox) to your account in the Access Management view.

There is a ton of material to get through, but almost no coding involved so far, aside from adding a small amount of JSON/RAML to a blank API spec - that was just for defining endpoint names and query parameters. I think it’s Anypoint Studio that’s used for developing the API logic and data transformations.

The first part of the training covers stuff most developers already know about REST APIs, because Mulesoft integrations are essentially REST APIs with a multi-layer architecture.

The whole Mulesoft thing looks incredibly complicated, but I’ve made some sense of it. There are three main parts:

  • Design: Anypoint Studio and API Designer
  • Management: Exchange, probably
  • Runtime: Mulesoft Runtime

Looking at the architecture, the complexity and all the overhead that goes into setting up Mulesoft integrations, whether it’s actually easier than the old-fashioned way of just developing and maintaining standard .NET APIs from a specification document.

From what I’ve learned so far: A developer/designer creates an API spec in Anypoint Platform’s Design Center, and this is defined as RAML. I think this is just for defining endpoints, resources, query parameters and required values for GET and POST requests.

The API spec can be published to the Exchange portal and imported into the Anypoint Studio IDE. Anypoint Studio is used for developing the actual APIs/integrations from the API spec. I think this will be needed for adding data transformation functions anyway. It’s likely there’ll be some drag-and-drop ’low code’ automation things involved here.

The APIs/integrations are later deployed on Mulesoft Runtime, which is a Java application server that uses Spring as a dependency.

As someone who hasn’t done much with Java or Eclipse for about ten years, I find Anypoint Studio a bit daunting to look at. There are a ton of Java dependencies listed for an example project that I thought was quite simple. I do wonder if that’s because it includes an instance of of Mulesoft Runtime.