1

Say I'm writing a complex application that consists of 3 parts: Services (Web API), Scheduler (Windows Service) and Web (MVC Project). They all share the same DB. Services are used only for posting data to DB. Web is used to interact with DB: display data, modify it, set some flags in it. Scheduler has several jobs in it which it performs some actions based on the data and flags in the DB (send e-mails, maybe post some things to some web services - including our Services). All these parts work independently, they know nothing of each other, although I'm using the same db.Log table for logging.

Let's imagine that as part of my Scheduler job, I post something to Services.

public void MyHourlyJob(IDBContext db, IWebService service, ILogger logger)
{
    var files = db.GetUnsentFiles();
    foreach(var file in files)
    {
        try
        {
            bool success = service.Post(file);
            if(success)
                logger.Log($"file {file.Name} was posted");
            else
                logger.Log($"something on the back end went wrong while posting {file.Name}")
        }
        catch(Exception ex)
        {
            logger.Log(ex);
        }
    }
}

Let's say, if the error occurred in Services, I logged it back there, and since the result of post from Scheduler wasn't successful, I also log that something happened in the back end. In the DB I'll have two logs of the same error, one from the Scheduler (general one) and one from the Services (the detailed one). The thing is, that for debugging and maintaining purposes, I need to match those two in the database.

What design principles should I follow in order to be able to do that?

1

As part of your message (header), add a piece information that can be included as part of the payload.

One could call this a correlation Id. It's part of the message context. This id can be a GUID. As the information travels through the different systems and layers, use this ID for logging purposes.

Then, one can easily query for all messages with the same GUID (ID) and get various messages and group them together.

The client or the first system that generates the request can generate the ID which is passed through various services layers down stream.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.