The power of a good devops team is that you can get fast, reliable, and repeatable deployments. It lays out a foundation for rapid iteration and quick releases. With that in mind, Lakeisha was pretty excited to start a new job working in devops.

She walked in the door, with visions of well architected, scripted flows, robust automated testing, and strict architectural guidelines. About fifteen minutes in, she learn that FISI guided their entire devops workflow. If it worked, it worked.

A few years back, someone had discovered MuleSoft's devops solutions and their "enterprise service bus". The ESB lets developers define "flows", which describe how messages pass between components in a large-scale, complex application.

That much was fine, but no one on the team decided to learn how to do things in Mule's tools. Any time there was a new requirement, someone would say, "We can build a Mule flow for that!" They'd then dig through the existing flows for any similar components, copy-and-paste them in a new order to create their new flow, and once it looked like it mostly worked, deploy it and move on.

Flows are designed in a graphical editor, but persisted as XML. Lakeisha sent us a block of common exception logging code, copy-and-pasted into every single flow.

<catch-exception-strategy doc:name="Catch Exception Strategy">
	<logger message="#['#DEBUG. ERROR Payload: '+message.payloadAs(java.lang.String]" level="INFO" doc:name="Logger payload ERROR"/>
	<logger message="#['#DEBUG. Failed '+exception.getVerboseMessage()]" level="INFO" doc:name="Logger verbose"/>
	<logger message="#['#DEBUG. flowVars: '+flowVars]" level="INFO" doc:name="Logger flowVars"/>
	<flow-ref name="jms_error_subFlow" doc:name="jms_error_subFlow"/>
</catch-exception-strategy>

This uses Log4j to actually handle the logging, which I bring up because Log4j is extremely flexible about how you can use logging levels. There's no reason to log everything to "INFO". To the contrary, that alone is enough to basically ensure the logs are full of useless spam. Log4j also allows categories, which would be really helpful for understanding any problems in your enterprise application, especially one that's wired together by a gigantic service bus. But we don't use that here.

And finally, every single log message starts with #DEBUG. Lakeisha adds: "This prefix is ALL over the place in every logging statement of literally every flow in the company; some developers even managed to define this prefix as a variable in a Java properties file."

Why? Because back before they officially adopted the tool as their standard, one of the developers experimented with it to see if it was fit-for-purpose. While experimenting, they slapped this logging block together, just to prove that it worked. When the company started building real flows using the tool, someone saw a logging block, copy/pasted it into their flow, and the rest is history.

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!