When working on IT projects in any organisation, one of the most common complaints I hear about 3rd party product vendors is that their support is _______ (enter adjective of your choice)
Developers hate dealing with first-line support because it is usually inadequate at best. In fact, I dealt with one vendor’s support team (NOT MuleSoft!!!) who flat-out ignored my support ticket until the SLA had lapsed. Then they sent me an email asking if they could close the ticket, presumably, on the grounds that I had given up begging them for a response.
When I told them they could, since I had resolved the issue on my own without their help, they had the temerity to ask me how I had resolved the problem.
I politely told the engineer that I charge for Support.
Dealing With Mulesoft Support
Now, I have heard similar accusations leveled against MuleSoft support but, in all honesty, when I look at the support tickets that the developers in question raised with the vendor I am not the least bit surprised.
More often than not, the support ticket amounts to little more than a message that says, ‘Something went wrong in my Mule flow. It’s not working. Can you fix it?’
What sort of response do you expect when you submit a ticket like that? What usually follows is a long, drawn-out ping-pong rally of messages requesting further information — with mounting frustration on the developer’s part.
Here’s How to Short-Cut the Process
Apart from the obvious — by which I mean a detailed explanation of the problem in your initial ticket description — your MuleSoft Support ticket should contain the following at a minimum:
- A zip archive version of your project
- A copy of the application’s log files
- A Properly (and honestly) Completed Form including
- Product
- Component
- Sub-Component
- Version
- Mule Runtime Version (NB!)
- Severity
Form Completion
Understand, with incorrect form information, you could have the support team barking up the wrong tree for days. Support use this information to direct your request to the correct team. They are on your side here. So give them the information they need to resolve your issue quickly.
Archived Project File
This may seem obvious but I am astounded at how often developers don’t even bother to include this. How is a support team supposed to advise you if they don’t have a copy of the offending code? When you don’t send this, you are likely to receive a stock response asking for all the things you did not supply the first time around.
This slows the process and causes frustration to build in your team.
Save yourself the aggravation and send them the project files as part of the initial request.
Log Files
This is arguably the single most important aspect of your support ticket.
A lot of support tickets originate during the implementation, or Proof of Concept phase, before a project is deployed to a target server. This usually happens on a developer’s local machine
When it comes to finding the log files on their local development machine, a lot of developers don’t know where to look. So they don’t send them. And when the Support team asks for the log files, along with everything else that was not sent on the initial submission, they just hear crickets. The developer gets annoyed because the support team is requesting information they can’t find…. and the ticket wallows in the doldrums for a few weeks until it eventually goes to that place where Support Tickets go to die.
For the record, the logs are relatively easy to find.
When you fire up your Mule application, watch the console. At some point the following lines will appear
Navigate to this location on your file system.
From there, go to the /logs directory and look for <your-app-name>.log. That is the file you want to upload.
TIP: Whisper! Before adding this file to your ticket, do the following:
- Go back to your project and update /source/main/resources/log4j2.xml
- Change any relevant AsyncLogger tags ( E.g. <AsyncLogger name=”com.mulesoft” level=”INFO”/> ) to level=”DEBUG”
- Then run your application again and generate the error at Runtime. This will create a much richer set of logs for your support engineer.
- Finally, grab the latest version of your log file and add it as an attachment to your ticket.
Reap the Reward
Now that you are armed with a rock-solid description of the problem, along with a copy of your project code and a relevant log file, you are ready to submit your ticket.
A properly completed form should take care of the rest.
This time, your immediate response from the good folk over at MuleSoft Support won’t be a stock reply asking for a raft of additional files and information. It will be an intelligent response that should go a long way towards resolving your issue.