Understanding the LEADTOOLS Cloud Database

The Cloud database is responsible for storing any information related to jobs in the cloud. The LEADTOOLS Cloud framework will handle all communication with the database but in some cases, you may want to create a relationship between the Cloud's JobTable and another table in your application. Refer to the following table for column definitions and usage.

Column Name	Data Type	Usage
cGuid	uniqueidentifier	Unique ID of the job. This is the primary key of the table.
cStatus	nvarchar(50)	Status of the job. This value will be one of the JobStatus enumerations.
cWorker	nvarchar(50)	Name of the worker machine which last worked on the job.
cAttempts	int	Number of times this job has been attempted. The configuration file allows you to specify the number of times a job should be attempted. For more information, refer to LEADTOOLS Cloud Settings.
cPercentage	int	Current progress of a job as reported by the UpdatePercentage Method.
cAddedTime	datetime	Date/Time the job was added. To add jobs, call the AddJob Method.
cLastStartedTime	datetime	Last Date/Time processing started for this job.
cLastUpdatedTime	datetime	Last Date/Time the cPercentage or cStatus column was updated.
cCompletedTime	datetime	Date/Time the job was successfully completed. Call the SetCompletedStatus Method from your worker assembly to update a job as completed.
cFailedTime	datetime	Date/Time the job was marked as Failed. Call the SetFailureStatus Method from your worker assembly to update a job as failed.
cFailedErrorID	int	Error code when the job has failed to process. Call the SetFailureStatus Method from your worker assembly to update a job as failed.
cFailedMessage	nvarchar(MAX)	Error message when the job has failed to process. Call the SetFailureStatus Method from your worker assembly to update a job as failed.
cMustAbort	bit	Indicates if the job should be aborted. Call the AbortJob Method from the client, and the SetAbortedStatus Method from your worker assembly to abort a job. For more information, refer to AbortJob.
cAbortReason	nvarchar(MAX)	Reason a job was aborted. Call the AbortJob Method from the client, and the SetAbortedStatus Method from your worker assembly to abort a job. For more information, refer to AbortJob.
cUserToken	nvarchar(MAX)	Any information related to the user that submitted the job (email address, username, user ID, etc). If your database architecture contains a separate table for user information, this column can be used to join a user's jobs with the user's information from another table.
cJobMetadata	nvarchar(MAX)	Metadata related to how the job should be processed. For example, if the objective of the cloud is to convert files from one format to another, this could contain the target format, source file path, target file path, etc. This data can be structured any way you like but since it is stored in the cloud database as a string, it is recommended you use a structure or class which can be serialized to a string.
cWorkerMetadata	nvarchar(MAX)	Metadata containing any extra information about the job as reported by the worker. For example, if the objective of this cloud is to convert large files from one format to another, you may want to provide the user with progress more detailed than the overall percentage. This column could be used to specify the current page or frame being converted (Page 1 of 25 for example).
cJobType	nvarchar(100)	'JobType' for the current job. Refer to 'Using Multiple Job Types' below for more information on job types.

Using Multiple Job Types

Each Windows Service can be set up to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. In a typical scenario, one would configure a job type for each unique task which the cloud is designed to process.

For example, you may set up a job type for performing OCR, and another job type for converting multimedia files. One option would be to write a single worker assembly capable of handling both types of jobs. Your assembly would simply identify the job type of the job, and process it accordingly. Another option would be to create a worker assembly for each type of job. Each windows service can only be configured to load a single worker assembly. However, if you choose to use multiple worker assemblies, you would need to set up a windows service for each type of job. Regardless of the configuration you choose, all windows services can share the same central server and database.

Consider the case where the cloud is converting files from one format to another, but the files are located at a remote location and must first be downloaded. You could configure a single job type which first downloads the file, then converts it all in a single pass. The alternative would be to split these two tasks into separate job types. The advantage of splitting these tasks is that it allows you to control each task independently. For example, you may only want 4 files being downloaded at any one time, but 8 files can be converted at one time. The workflow would look like the following:

A client adds a new job with a job type of "Download".
The job is picked up by a worker configured to accept jobs of type "Download".
Once your worker assembly has downloaded the file, it will call the ResetJob Method with a new job type of "Convert". Calling ResetJob will also update the status of the job to JobStatus.New, indicating it is again ready for processing.
The job is picked up by another worker configured to accept jobs of type "Convert".
The job is converted successfully and its status is updated to JobStatus.Completed.

Using separate job types allows you to accomplish this by defining each job type in Workers.xml and configuring a windows service for each job type. For more information on the Workers.xml configuration file and configuring the windows service for specific job types, refer to LEADTOOLS Cloud Settings. For more information on creating worker assemblies, refer to Creating Cloud Worker Assemblies.