The following document will go through the functionality found within JetTrac DispatchLog and JetTrac DispatchLogNotReturned. The purpose of this module is to record whenever JetTrac processes a job (let’s call it a Work Order) that “dispatches” a PDF form package to a field technician to a Dispatch Log. Then when that same package is returned JetTrac DispatchLog records that it came back by inserting a “Date Returned” value.
JetTrac DispatchLogNotReturned is a separate but related module that can run on a scheduled job that will go through the Dispatch Log and find all Work Orders that have been sent but not returned. The purpose of this is for an Admin person to track outstanding Work Orders and to take whatever action is needed to close out that work Order.
To run the program, you will need to have the following files located in the same directory:
The DispatchLog.exe and ExitHandler.dll are files required for the program to run and should never be edited.
JetTrac DispatchLog reads a configuration file and the input XML then inserting or updating a record in the Dispatch Log. JetTrac DispatchLogNotReturned reads only the Dispatch Log and creates a separate, identically formatted Dispatch Log containing only the dispatches that have not been returned.
When setting up a job step using JTDispatchLog in JobConfig the only two lines of the config you need to worry about are the Config file and the Input XML. If left as an asterisk * the input will be whatever file is in the data folder that triggered the job running. This works well if it’s the first step but if the input is also the output of a previous job step you would need to specify the fully qualified path of the input file. Eg: C:\JetTrac\…\input.xml
In JobConfig, file paths entered should not be in quotes.
As with all modules, there is a dropdown to select whether or not the job should stop completely if this step fails. If you select Yes, any error will terminate the job process and write to the log file what happened, if no, then the job will try to continue anyways. However if any steps further down the line rely on the output of a job set to not stop on error, they may not work properly.
For more specifics go to the JetTrac BYODJobConfig page.
The command line to run JetTrac DispatchLog contains the location of the .exe file, the configuration .ini file, the location to save the output XML file, and the log file. The following is an example of the command line used to run this module:
“C:\JTDispatchLog.exe” “C:\JTDispatchLog_Input.xml” “C:\JTDispatchLog_Insert.ini” “C:\JTDispatchLog.log”
Each part of the command line is separated by at least one space and contains the fully qualified file path to the file you are referencing surrounded by quotes (in case there are any spaces in the path of file name).
There is one configuration file for Insert mode and one configuration file for Update mode. Here is a configuration file example for Insert mode:
The values are as follows:
- LogFileName: Fully qualified name of Dispatch Log.
- ExceptionFileName: Fully qualified name of the file that contains any exceptions.
- LogList: List of XML tag (field) names to be inserted in the Dispatch Log.
- LookupFields: The key index field(s) that are used to find out if an existing record already exists in the Dispatch Log with these same key values.
- AddedFields: The field(s) that are added in Update mode
- ProcessingType: Either Insert for inserting new records or Update for recording a Work Order that has come back from the technician.
Open the input XML file and read all fields into memory
Based on the fully qualified filename of the log file specified in the config file keyword LogFileName, open it if it exists or create it if it does not exist. If we create the log file also create the header record.
If the config file indicates “Insert” this means that a new record will be written to the bottom of the file. Gather all the field names that are indicated in the config file keyword LogList then go to the XML data and retrieve all the data then write the new record. Important note: The program will read through the entire Dispatch Log to see if there is a record that already exists with matching LookupFields as indicated in the config file. If there is an existing record then that record will be updated with any data from the input XML that is different than what was there before.
If the config file indicates “Update” this means that an existing record will be looked up and updated based on the keyword LookupFields indicated in the config file. Look at the XML data for these key fields then go find the record in the CSV and update/write the additional fields that are applicable only to Update. Don’t touch any of the original fields in that record that were put there by an Insert option.
If there is no matching record found then we want to write a record to the Exception file. Under normal operating procedures there should never be a case when an Update will not find a record that needs to be updated. However, if the log file was accidentally deleted, or opened and some records deleted or some other circumstance that would cause a record to not be found we want to be able to log these exceptions.
A job can be scheduled in JetTrac JobController to run on a periodic basis that will run the program DispatchLogNotReturned. This program would read through the entire DispatchLog for all entries that have NOT been returned and create a new CSV file that is then emailed to the Admin person for review.
Here is a sample config file for JetTrac DispatchLogNotReturned:
- The LogFileName is the fully qualified name of the Dispatch Log
- HeaderTitles is a list of all field names/titles – this will appear as the first record of the file that is emailed
- SortField are the fields that you want to sort by