Finally got a working Mulesoft application
I've been feeling rather pleased with myself since this morning, having finally deployed a working Mulesoft application, and having managed to fix all the runtime errors that were frustrating me last night.
The first error was fixed by removing a duplicate Global Error Handler that I'd inadvertently left in there as a placeholder. The 'Error handling' section of the actual 'flows' need to be referencing the error handler.
Another issue was caused by an unused reference in global.xml to a HTTP Listener, which, in turn, referenced an entry that didn't exist in the config .yml files.
The low-code stuff and the data transformations themselves are quite easy. The thing is that nothing in the designer works without being compiled with the Java Server, all the dependencies that comes with it, and an environment that passes a load of variables during runtime. Configuration is about 80% of the work. You won't find much in the way of helpful documentation for this, either.
But we use Mulesoft because having a load of the Anypoint Platform is a central place to administrate a vast collection of APIs that are consistent in their design. It's preferable to having around 120 integrations that are a mix of .NET APIs, SSIS packages, PowerShell scripts and third-party things.
Deploying a Mulesoft application isn't straightforward. Before doing that, all the secure property keys need to be listed in mule-artifact.json.
After that, select the 'Deploy to CloudHub' option for the project.
In the deployment configurations, we select the Properties tab, and set the following:
- mule.env
- mule.key
- anypoint.platform.client_id
- anypoint.platform.client_secret
- project.version
It's a good idea to copy the values from the Text View, in case another deployment attempt needs to be made.