FS 292887 ePOD Exception Handling
OBS Logistics Ltd
ePOD Exception Handling
CALIDUS ePOD
17th October 2011 - 1.0
Reference: FS 292887
Contents
Functional Overview
Client Requirement
The ePOD system does not currently handle exceptions within any processes. This results in the PDA having absolute control over all Jobs on the current working load. In situations where a Job is cancelled on the list or details of the job change there is not way of updating this data. A solution needs to be implemented to allow for additions, cancellations and changes to Loads, Jobs, Services, Containers and Products to be made within the Admin system, to be distributed to the PDA client.
Solution Overview
The server will now only move the PDA users current job to status In Progress, which will allow users of teh administrative system to edit other jobs on the load.
The PDA will handle exceptions through the following two processes:
- A Send and Wait message trigger when starting a job. This process will send a message to lock the job and check for any updates.
- A threaded process to request any updates for the current load on a timer.
Scope
- The changes will be made in the latest version of the CALIDUS ePOD system.
- The system will be written in Microsoft Visual Studio 2008, with the intended initial device configuration of Microsoft Windows Mobile 6.x, and a screen resolution of 320*240 pixels only.
Set-up
Pre-requisites
There are no additional prerequisites for this new functionality other than those of the initial system.
Menu Structure
No menu structure changes will be made to the PDA or Admin systems.
Server
There will be changes to the Loads, Jobs, Containers, Products and Message Process DAL objects. A new version of the server will need to be distributed.
Data
None
Functional Description
Process 1: Job Locking
This mechanism will perform the first process to handle exceptions.
PDA Process
At the point of the user clicking the OK button within the Job Details screen, the status of the network will be checked. If network access is available then the PDA will attempt to send a Job Lock Message, as a send and wait message. Following this there are four scenarios:
- The PDA receives a message advising that the Job is now locked (changed to status I), at this point the PDA will continue with the standard process and allow the user to process a job.
- The PDA receives a message advising that the Job is now locked and requires updating. The message will contain the updated information which at this point will be decoded and used to update the Job Object. Once this process is complete the user will be advised that the Job has been updated and this process will exit, leaving the user in the Job Details menu, refreshing the data allowing the user to review changes before clicking the OK button to continue with the Job as usual.
- A NAK is received advising of a error trying to lock the record. At this point the PDA should prompt the user if they wish to retry. If the user selects to retry then this process will begin again. If not then the user will be able to continue with the Job as usual. In this scenario the Job Lock message will be added to the pending data table, to be sent later.
- If no response is received then the process for a NAK will be followed.
If there is no network access available then the PDA will add a Job Locking Message with a request for no update date to the pending data table without any interaction with the user, and the standard job process with continue.
Server Process
When the server receives a Job Lock message, it will initial create the Job Object and apply the lock (change status to I), preventing users from changing this job. At this point it will follow one of two processes:
- If the Job Lock Request has a flag for no job updates, then the process will send a Job Lock response without checking for updates.
- If the message has the updates flag, then the system will use the job object to check for updates recursively against the job, service, containers, and products. Any elements that have been updated will be added to the response message. Any elements that haven’t been changed will be added as a single record, allowing the PDA to identify deleted records. It will then respond with this message.
Admin Process
The admin interface will need to be altered to allow for handling for exceptions for jobs in two ways:
- It will require in any menus that allow users to edit or delete load, jobs, services, container and products, to have a mechanism that will start a transaction on the record, and then check the status on the Job, if at status I this must be cancelled and the transaction rolled back.
- The Service and Job screens will be modified to allow for admin users to change the status of loads and jobs at the status of In Progress, as well as allow for a user to deallocate a PDA user from a Job or Load. This will be to prevent Jobs being locked in the system.
Process 2: Load Update
This mechanism will perform the second process to handle exceptions.
Database
The Load, Job, Service, Product and Container records will be modified to include Last Changed Date/Time fields. These will be identical in design and naming convention to the records added to the Site table.
PDA Process
This process will run in a threaded process similar to the pending data process. As with the pending data process a parameter will need to be set to control the occurrence of the Load Update Process. Once every X seconds, if the network is available the PDA client will send a Load Update message, and wait for a response. From which the following scenarios can occur:
- The PDA receives a message advising that there are no updates, in which case there is no processing to be done and the process ends.
- The PDA receives a message advising that there are updates. At this point the PDA would need to create the Load object and decode and apply the changes. If the user is in the Job List, this list can simply be refreshed to reflect the changes.
- If the user is processing a Job, the process must do one of two things:
- In the case where the job has been deleted the user must immediately be prompted. At this point the job will be deleted from the device and the user will be returned to the Job List.
- In the case where the job, this will include any containers, products or service records, the user will be prompted that there has been a update and will be returned to the first tab of the menu they are using.
- The PDA receives a NAK due to a error. At this point the application should ignore the update and end the process.
- The PDA receives no response. At this point the application should ignore the update request and end the process.
Admin
All updates to jobs on a load, removing jobs, resetting statuses, or changes to containers and products result in the load changed date being modified. Any modified details of a job, service, product or container record will result in a last changed time against that record being updated. Service Details, Products and Containers will be modified to receive the Job number, so that it can be submitted with the update, so the server can update the load changed date and time.
Server Process
When the server receives a Load Update message, it will initial create the Load Object. Then the system will use the Load object to check for updates recursively against the job, service, containers, and products. Any elements that have been updated will be added to the response message. Any elements that haven’t been changed will be added as a single record, allowing the PDA to identify deleted records, as they will not be present. It will then respond with this message.
The Server will get the Load DAL object for the load on the message request.
For the load record:
- If last changed date > date on record, send details of the load to PDA
- For each job on Load:
- Add a Job tag
- If last changed date > date on job record:
- Include all data
- If job is not service:
- For each container in job:
- Add a Container tag
- If last changed date > date on container record or job has changed:
- Include all data
- For each product in container:
- Add a Product tag
- If last changed date > date on product record or container has changed:
- Include all data
- Next
- Next
- For each Loose Product in job:
- Add a Product tag
- If last changed date > date on product record or job has changed:
- Include all data
- Next
- For each container in job:
- Else
- If last changed date > date on service record or job has changed:
- Add a Service tag
- Include all data
- If last changed date > date on service record or job has changed:
- End If
- Next
- For each job on Load:
- End If
So the XML data will always have an empty Job, Product, Container and Service tags if nothing has changed on those records. It will always have the full data tag for the Load, as the change will always be reflected against the load.
XML Schema
Job Lock Message
Job Lock Request
<JOB_LOCK_REQUEST ID="X" SITE="XXX" USER="XXX" PASSWORD="XXX"> <UPDATE_REQUIRED>Y|N</UPDATE_REQUIRED> <LOAD_ID>XXXXX</LOAD_ID> <JOB_ID>XXXXX</JOB_ID> <LAST_UPDATE>XXXXX</LAST_UPDATE> <REQUEST_TIME_DATE>XXXXX</REQUEST_TIME_DATE> </JOB_LOCK_REQUEST>
Job Lock Response
<JOB_LOCK_REQUEST ID="X">
<RESULT>ACK</RESULT>
<EPOD_JOB>
..Job Details
<EPOD_CONTAINERS>
<EPOD_CONTAINER>
..Container Details
<EPOD_PRODUCTS>
<EPOD_PRODUCT>
..Product Details
</EPOD_PRODUCT>
</EPOD_PRODUCTS>
</EPOD_CONTAINER>
</EPOD_CONTAINERS>
<EPOD_SERVICES>
..Service Details
<EPOD_SERVICES>
</EPOD_JOB>
</JOB_LOCK_REQUEST>
Load Update Message
Load Update Request
<LOAD_UPDATE_REQUEST ID="X" SITE="XXX" USER="XXX" PASSWORD="XXX"> <LOAD_ID>XXXXX</LOAD_ID> <LAST_UPDATE>XXXXX</LAST_UPDATE> <REQUEST_TIME_DATE>XXXXX</REQUEST_TIME_DATE> </LOAD_UPDATE_REQUEST>
Load Update Response
<LOAD_UPDATE_RESPONSE ID="X">
<RESULT>ACK</RESULT>
<EPOD_LOAD>
..Load Details
<EPOD_JOBS>
<EPOD_JOB>
..Job Details
<EPOD_CONTAINERS>
<EPOD_CONTAINER>
..Container Details
<EPOD_PRODUCTS>
<EPOD_PRODUCT>
..Product Details
</EPOD_PRODUCT>
</EPOD_PRODUCTS>
</EPOD_CONTAINER>
</EPOD_CONTAINERS>
<EPOD_SERVICES>
..Service Details
<EPOD_SERVICES>
</EPOD_JOB>
</EPOD_JOBS>
</EPOD_LOAD>
</LOAD_UPDATE_RESPONSE>
Appendix A: Quote & Document References
| Cost Details | |||
| Activity | No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
| Requirements | 0.00 | 0 | £0.00 |
| Change Request Evaluation | 0.00 | 0 | £0.00 |
| Functional Specification | 2.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0 | £0.00 |
| Development | 14.00 | 0 | £0.00 |
| Testing and Release | 2.00 | 0 | £0.00 |
| Implementation | 0.00 | 0 | £0.00 |
| Project Management | First argument to "number_format" must be a number. | 0 | £First argument to "number_format" must be a number. |
| TOTAL | First argument to "number_format" must be a number. | £First argument to "number_format" must be a number. | |
| Estimate excludes training, release to live and go live support. |
A.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 |
A.2 Glossary
| Term | Definition |
|---|---|
| EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
| CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
| PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
| DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
| GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
| GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
A.3 Authorised By
Tony Walker | OBS Consultant | _____________________________ |
