Getting used to Anypoint Studio

Development

Anypoint Studio, as a development tool, comes with a steep learning curve - it’s essentially a rebranded version of Eclipse, with a lot of custom Java packages (there are a lot for the Mulesoft server) and a package manager pointing at the Exchange repo.

Putting together a Mulesoft application, using the ’low code’ designer and DataWeave is easy enough, though I haven’t done any advanced data transformations yet. Currently it relays data from another Mulesoft API to an external service in a different format.

Configuring the application to do anything is the tricky part, as there are five places where the configurations are stored:

  • global.xml
  • pom.xml
  • src/main/resources/config
  • src/main/resources/config.secure
  • Anypoint Studio runtime configurations

The global.xml file contains the dependency/package manifest, references to the other configuration files and a few other things.

The config and config.secure paths contain .yaml files related to the external services the application is interacting with - URIs, port numbers, OAuth values, etc. There will be .yaml files for local, development, staging and production environments, and the context will be set by whatever server is running the application, as part of its runtime configuration. I’m still getting the error message about ‘${mule.env}’ having a missing configuration property.

Secure configurations aren’t straightforward. I need to use the Secure Properties Generator on CloudHub to encrypt the ClientID and Client Secret, copy those into the .yaml files and add the encryption key in the Run Configurations as the ‘${mule.key}’ variable.

The secure configuration should look something like:

my-api:
  clientId: ![encrypted Client ID]
  clientSecret: ![encrypted Client Secret]

Basic MUnit tests are actually quite easy to set up. Basically a test is a flow reference to the main components, however many assert steps, and a payload step that references a JSON file elsewhere.