Suppose there is a some system where rows in a database are filled when something happens:
- when user simply logs in, a row is inserted to the database with type of login and time in table
- when operator make a call to the user, a row with operator id, user id and date insertted in database in table
- when operator does not answer to user call, a row with date, user id, and type call inserted into the database
Then after some time period is over, say month, we need a report on who called to who, how many calls were not answered, etc. What pattern should be used to organize this functionality?
At first glance this process seems like logging a lot, but logging is a process when we store a message with some format (date-processId-messageWithPlaceHolders). So using logging system for that is not very suitable.
From another point of view it looks like event processing, but it is not necessary to do any actions when "event" happens, no listeners, no queues. Just storing to database for further reporting.
So what pattern or technique should be used to implement this functionality effectively?
Your requirement is to to generate a who-called-who report monthly so that you can, e.g., understand the success of your calls (or whatever reason you have).
You don't need to think about resemblance to logging or event processing or anything. Just analyze the problem from top down to get the least amount of work you need to accomplish your task:
- You need to generate a report monthly
- For this you need to run a job which generates result at least once a month
- For this you need to store your events in a format that can be understood by your job.
So a good solution is to have a batch job run monthly. This can be a manually run java process, a cron job, a hadoop task, ... depends on your technology stack. Your events need to be stored at the time their happen. Again, depending on your stack, it can be a relational database, a key value store, a file with log lines..., whatever is the easiest to work with in your technology stack.
All of these options can be good ones, but some are probably better. E.g., I recommend against using pure string logging. You need to extract structured attributes like time, numbers, etc. so prefer a format which helps you keep type safety.