Negative Confirmation: Show Me the Code

I’ve blogged the last couple of days about Negative Confirmation as a Sender of data. That is, I believe that the person or organization who sends a file should have some process whereby files expected to be sent are flagged when they fail to go.

To that end, I’ve mocked up a little something that will do just that. First, here’s an overview

1) An Interface ILogReader with a single (overloaded) method: ReadLog which accepts either a Stream or a string. This is to enable the reading of virtually any kind of data. It would probably need to be modified to read a DB, but since this was more in the nature of a Proof-of-Concept, I’m not too concerned about that.

2) A Class DelimitedLogReader which Implements ILogReader- for this PoC, I’m just reading a pipe-delimited file of my own design.

3) A Class LogEntry to define the structure of log entries. In real code, this should probably be a struct, now that I think about it…

4) Classes for handling the Scheduling- these need some work. At the moment, I have a class for the ScheduleConfigurationSettings (pulling from app.config- I tried some custom settings, but that wasn’t working and wasn’t worth pursuing for a PoC). I have a ScheduleMarshaller- which grabs the actual schedule data from app.config. Finally, I have a ScheduleResolver- the real meat of the solution- which compares the schedule as provided by the ScheduleMarshaller to the logged files provided by the DelimitedLogReader.

So this works like this: The application instantiates DelimitedLogReader and grabs the log entries from a file specified in app.config. The application then instantiates the ScheduleResolver which instantiates the ScheduleMarshaller to get whatever files were scheduled to be sent the previous day. The Resolver then compares the scheduled files to the log entries and provides a list of the expected files which did not go.

Here is ILogReader in its entirety

DelimitedLogReader implements ILogReader- you could do this any number of ways, here’s mine:

The ReadLog(string path) method just returns a call to ReadLog(Stream stream) by instantiating a FileStream based on the path provided.

Things get a little more interesting with the ScheduleMarshaller

The call to “translateToDayOfWeek” takes a formatted string from the ScheduleConfiguration object and then translates that as a DateTime.DayOfWeek. “translateToDate” takes the expected day and turns it into an actual DateTime object.

The Resolver then does the actual work:

With the list of strings “fileInError” you can then handle them however you want. In my case- for my PoC only, I just did a simple console application:

And there you have it- a more-or-less functioning Negative Confirmation process which will alert me as the Sender when I have failed to send a file.

In a real-ish scenario, I would add a module to the end of any process that sends a mission-critical file to write to the log the name of the file and the DateTime when it was sent. My Resolver would then run once a day- late enough that anything that hadn’t gone would be in error- and alert me (probably via email) of any files that didn’t go. Better- it would not send an empty email if there were no results- it would just quietly finish and wait for tomorrow’s run.