I have an application that uses a variety of external resources (web services, filesystem, database), and therefore can be quite difficult to configure. The plan is to add a self-diagnostic tool to the application so it can report problems with the configuration and allow the user to correct it. Are there any design patterns, libraries, examples, etc, that I should consider when designing such a feature?
The application is written in C# and ASP.NET.
You might consider a rules engine -- expert systems have long been used for diagnostics and trouble shooting. This allows rules to be modified and extended rather than changing the code base, as you are very likely to overlook many cases and the environment can change requiring new rules to be added.
One way could be to have, in the admin area of your site, a set of pages that report on the state of these external resources. For example, it might tell you the database it is configured to connected to (and if it could establish a connection), what server it is running on (if loadbalanced), and so on).
For web services, I have a little service that runs and every couple of minutes "pings" the web service to see if it is still there. If it isn't I get a text message on my phone (through another third party service incidentally) and a detailed error report in an email - You might prefer that than having to know to check a web page on the site.
I don't know if there are any specific design patterns for this, I just add this reporting element to the normal layers in the application.
If they can see you, you can see them
Add a layer to your (external) apps that sends asynchronous "pings" out in some form. Could be a messaging, topic-like middleware tool.
If you don't have control over the external systems, possibly add a sep-A-RAT-e "facade" app that does the diagnostics (eg calling a http connection with a timeout) and then send out pings on the external apps behalf.
Add a listener to your central app with a configurable list of remote apps (message types) that are expected to ping in and raise an alert if one of them fails to do so.
Just make sure, to run all of this in separate threads and asynchronously. You don't want blocking UI threads or too many open network connections that wait for a timeout.
This way your central app has very little overhead. It doesn't need to do the polling itself, just sits there with a queue listener and a map of apps and when they last called in. If one of them reaches a threshold for not having called in lately, you have a problem and your app has some way to let you know.
Assuming you just mean static configuration,
add a customer-acessible unit test that exercises all the system interfaces. You already have one , right ?
Call it "validate configuration". or something.
Hope this helps.