Output Monitors give you a quick way to watch action output and change the behaviour of the action depending on what you see. This lets you extend built-in actions in powerful ways.
Unlike my normal "pie in the sky" examples, this one is based on a real problem. This morning we had a customer in our chatroom who had a problem deploying to QA:
when a user's connection to the database breaks, or if a user is accessing some of the files in QA and connected to a different database (different to the one we are checking against) the FinalBuilder project will try and deploy the files and get a sharing violation which causes the build to fail
Summary: the customer needed a way to tell if one or more files were open on a remote machine.
SysInternals Tools Are Awesome
SysInternals make PsTools and a raft of other excellent Windows "power administrator tools". If you haven't checked them out, you should. It's no wonder that Microsoft bought the company.
For my solution to the above problem, I made use of two great SysInternals tools:
- PsExec (part of PsTools) can deploy and run an executable on a remote machine. There's a PsExec action built into FinalBuilder, although you still need to download and install PsTools.
- Handle is a great little command line tool that dumps (among other things) all of the open files on a system. An excellent debugging aid.
Use PsExec to deploy and execute handle.exe on the remote computer, and use FinalBuilder to scan the output for the file(s) we need to check for.
Here's the complete project, including my verbose comments. Because of the powerful Output Monitor (and the awesome Sysinternals tools), almost everything happens inside the PsExec action:
To check for our file(s), we need to configure an Output Monitor on the PsExec action. We have two variables:
- fileName - The filespec or filename that we want to check for. This variable is set by the user.
- fileInUse - The details of the file that's in use, if there is one. This variable is set when the PsExec action runs.
Every action in FinalBuilder 6 has an option on the Runtime tab called "Monitor Action Output":
Click the button to edit the Output Monitors for that action:
For our monitor (shown above), we're checking for any content which contains %fileName% and saving the first match to the variable fileInUse.
There are lots of other options for output monitor behaviour. Click on the dropdown for a full list:
... For example, if we wanted a list of all matching lines, we could use the "Save All Matches to Variable" behaviour.
As configured, the output monitor supports wildcard matching with * and ?. If we wanted it to be really powerful, we could change it to use a regular expression - grep-in-a-box!
You can download the FinalBuilder 6 project file here.
Sometimes you need more powerful output processing, and Output Monitors are not up to the task. You can always use the OnStatusMessage script event to run some script every time the action outputs data. I actually did a blog post about this a couple of weeks ago.