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.
After resolving the previous issue with the Content-Type defect in the Azure Logic App’s storage connector, I ran into a second problem: The Web pages being generated were populated with the correct content type, but the incorrect content. I quickly discovered that was partly caused by a race condition and with how memory is managed by Azure.
By default, a Logic App will run up to twenty instances of a ‘For Each’ loop in parallel, but this is multi-threading instead of true parallel processing.
One of our Logic Apps, which we developed as a static site generator, began writing the Web pages to the storage account as octet stream files, and I narrowed down the problem to a defect in the storage account connector.
I believe (but I’m not 100% certain yet) Microsoft’s developers hadn’t implemented the ‘"headers": {"Content-Type": "text/html"}’ code for the storage account connectors, and the file type, therefore, always defaults to octet stream.
One of the central claims made by Moxie Marlinspike, during his discussion at the Black Hat conference appears nonsensical, because he referred to two entirely different meanings of ‘abstraction’, and was thus comparing two entirely different things:
‘We spent the past 20 years onboarding people into software by putting them into black box abstraction layers, and then putting them into organizations composed of black box abstraction layers, […] Marlinspike posited that security researchers, who routinely probe beneath surface-level abstractions, are better positioned to drive innovation in software development.
Recently I was asked to look into changing the authentication method to OAuth 2.0 for an integration service. It’s something I’d done enough times in Azure to know what’s involved: The service would need an app registration, which should provide a client ID and secret, an OAuth token request stage, and modifications to include the token in the Authorization header field of whatever was originally being sent.
After a little digging, it turned out the integration was a simple batch script, running on a Windows server, and it used curl to send data to a third-party service.
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.
Something unexpected happened this week: I was offered my first senior engineer position. I’ll be focussed mainly on the project management and planning side of things, and I’m being encouraged to delegate the software development work. I’m still prepared to get my hands dirty with the coding and systems administration, if anyone gets stuck on a tricky problem, and I’ll likely be working on a couple of .NET applications as personal projects.
One of the harder software engineering concepts to understand is that of interfaces. I once struggled to understand what interfaces are, how they work, and why a software engineer might use them. Most the explanations I could find on the Web didn’t make a lot of sense - some were more complicated than they needed to be, and others attempted to explain it in terms of other things I hadn’t grasped (i.
One of my Logic Apps originally had just three steps:
HTTP trigger Deserialise HTTP request JSON payload Send objects from the request payload to a Service Bus queue Another Logic App would read the objects from the Service Bus queue, use them to query another source for data, then send a email to whatever address was in the initial request. I used this approach because there could be more requests than a Logic App can handle concurrently, and it made sense, therefore, to queue the requests.
The security configuration of Azure services is a fairly broad subject area, and this is more of an introduction to how it works for a Resource Group, in the context of a Logic App that needs to interact with multiple resources. If a DevOps team, instead of the developers, is managing the security, a considerable amount of time will be spent planning and designing services beforehand, and later trying to figure out which security configurations are preventing the services working.
