General Structure of Quartz.NET and How To Implement It

General Structure of Quartz.NET and How To Implement It

 

1. Simple job schedule structure

 

                                            Simple job schedule graph_01

 

The demo structure about the graph above could be:

 

 The most important snippets are in “Example.cs” file :

 And “SimpleJob.cs” would like :

 

It will run while user delivery the “Run()” in “Example.cs”. And we would see she screen shot like this:

 

 

 

2. Remote job schedule structure

 

                                         Remote job schedule graph_02

 

The Demo structure could dive into two parts, the one is the client and the other is the server. The demo structure should be:

 

 

 

The most important code snippets in “clientExample.cs” are:

 

 

Note: If you do not use DB to store the data of schedule you can comment out the content named “set db info”.

 

This line is used to set the instance name, it is costumed.

 

This part is used to set the thread info about the job. It should be set both client side and server side code.

 

If you plan to use DB as your persistent level to store the scheduler data the part above is very necessary, otherwise, you could get rid of it from your code.

The first line is to tell quartz that you are going to store your scheduler data into the DB through ADO.NET.

The second line of this part, tell the quartz that you would use the default method to store your schedule data into DB. Because ADO.NET is default method to store the data in Quartz.NET, so we use default as the property.

The third line tells the quartz that your table name prefix. E.g. If there is a table named QRTZTest_Hello”, through the ‘QRTZTest_’ prefix, quartz would find it while running.

The fourth line tells the connection string to access your DB where the scheduler data stored.

The last line tells quartz that the DB is MSSQL. Because now quartz supports many different DB, e.g. Oracle, MySQL, SQLite, MSSQL etc. so this property is important.

Note: All the properties above about DB, should be set in client demo and server demo when you use DB as the persistent level to store your schedule data.

              

These properties are used to set remote exporter. And in server, should set following properties for suite. 

      

At last, all the jobs in server could be able to delivery by the method in client. Yes, you should start two instances when you debug it. Client instance first, and then the server instance.

And you can see the result in the server instance. 

      

Note: You must add “TopShelf” namespace into the server code.

 

While if the DB has been used as persistent level. The scheduler data could be seen in the table like this:

 

Additionally, how to run the server as a service by “Topshelf”

1) Compile the server project.

2) Find the executable file produce by the first step

3) Then run cmd prompt as administrator and input the like this:

The executable file name could be replaced by any of yourselves.

4) At last you could find it has been installed in your Services: