Some of you may remember my last New England Code Camp presentation based on a client proposal titled "Building Business Applications with Community Server." That proposal recently turned into a project of mine, and it's been very interesting extending Community Server for non-conventional purposes. We essentially purchased a Community Server Commercial license to use the framework and none of the applications, and worth every penny.
For an example of leveraging the Community Server framework for other purposes, the Project Management application requires importing data from an Access-based Accounting system into Community Server. We wanted to initiate the update process manually, so I created a one-click administrative function, with the import and conversion processing performed in background Community Server tasks. I wrote an Access Provider for Community Server to retrieve the data and a Custom SQL Provider to take the hand-off of the Business Generic Objects from the Access Provider to perform the SQL updates. The idea of using an Access Provider with Community Server is nutty, I know, but it works like a charm. What's really powerful though, is leveraging CS Event Logs and Exception Reporting to monitor the tasks.
As I said, an "Update Jobs" administrative button starts the import process from the Access Tables. A queue number is displayed to the admin if they want to track the process. (Click any of the images to enlarge.) Of course, since the processing is done in the background, the action is instantaneous to the user. The tasks actually check the queue every couple of minutes, but the user can do other work while the processing occurs.
By leveraging Community Server Event Logging, the tasks that make up the import and conversion process can now be tracked. We can create as many events as we want at each stage, of course, but that becomes just so much noise. If any errors occur during any of the sub-processes, as you can see from the items in red below, I write those events to the log. Otherwise, I found it best to report when the Access Data is imported into SQL and when the final processing is complete. That's all we really need.
We can leverage Community Server Exceptions for even more detail as you can see below. Details of a SQL error I created purposely to trip up the process and logged as a CSException are circled in red. You may also notice that we can create our own Exception Type categories, as in "Jobs Import Update Data Processing" in the screenshot. This type of detailed reporting information makes system management much easier and can potentially reduce maintenance costs substantially. Or put another way, with this kind of information readily available, I'll be spending less time investigating import errors.
Leveraging Community Server tasks, event logs and exception handling. Even more boss than creating an Access Data Provider! Well, almost.