References ▼
The Job Processor database is responsible for storing any information related to jobs in the Job Processor. The LEADTOOLS Distributed Computing (Job Processor) SDK will handle all communication with the database but in some cases, you may want to create a relationship between the Job Processor'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 Job Processor 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 whether 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 Job Processor is to convert files from one format to another, the metadata could contain the target format, source file path, target file path, etc. The metadata can be structured any way you like but since it is stored in the Job Processor database as a string, it is best to 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 the Job Processor 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 metadata 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 the 'Using Multiple Job Types' section 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. There are no limitations to the number of Windows Services from the LEADTOOLS Distributed Computing Framework which can be installed on a single machine. In a typical scenario, a job type is configured for each unique task the Job Processor is designed to process.
For example, you could set up one job type for performing OCR, and another job type for converting multimedia files. One option would be to create 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.
As an example, consider a case where the Job Processor is converting files from one format to another, but the files are located at a remote location and must first be downloaded. One solution is to configure a single job type which first downloads the file and then converts it, all in a single pass. An alternative would be to split these two tasks into separate job types. The advantage of splitting these tasks is that doing so allows each task to be controlled independently. For example, perhaps you want only 4 files to be downloaded at any one time, but want to convert 8 files at one time. The workflow would look like the following:
A client adds a new "Download" job.
The job is picked up by a worker configured to accept "Download" jobs.
After the worker assembly has downloaded the file, it will call the ResetJob Method with a new, "Convert" job. 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 a worker configured to accept "Convert" jobs.
The job is converted successfully and its status is updated to JobStatus.Completed.
Using separate job types allows workflows to be created 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 Job Processor Settings. For more information on creating worker assemblies, refer to Creating Job Processor Worker Assemblies.
Programming with the LEADTOOLS Distributed Computing (Job Processor) SDK
LEADTOOLS Job Processor Settings
Creating Job Processor Worker Assemblies
Deploying LEADTOOLS Distributed Computing (JobProcessor) Applications