Job Queue

As you know by now, Dime.Scheduler has a loosely coupled architecture. This implies there are communication channels between Dime.Scheduler's main (planning) application and its plugins (such as the back office or Exchange plugins).

Even though the advantages outweigh the disadvantages by a long shot, there are some risks involved with this architecture. Arguably the most important one is availability. With multiple nodes in the chain - especially when they run on other hardware - there is a chance of downtime for one of the nodes. For Dime.Scheduler, this could result in a long and unprocessed queue of appointments which haven't been sent to the back office.

The job queue view is where you can find more information about this communication channel between Dime.Scheduler and its ecosystem. It mainly contains technical information and reporting, like which and how many jobs succeeded:

You can even drill down, right down to the lowest level, the source code:

It also allows you to retry a job in case something went wrong, for instance when a service was interrupted due to a system failure:

It is unlikely problems will occur on this level if the installation was done correctly on a reliable IT infrastructure. And if it does it will probably be caused by a human error - such as manually restarting the back office or service bus Windows services. But when something goes wrong unexpectedly, then this dashboard can be a good place to start the investigation.