FS 292887 ePOD Exception Handling: Difference between revisions
No edit summary |
No edit summary |
||
| Line 110: | Line 110: | ||
==== Job Lock Response ==== | ==== Job Lock Response ==== | ||
{{comment|text=All child elements from EPOD_JOB are not required | |||
|sign=[[User:Milesl]]|date=5/9/2011 17:4:44}} | |||
<JOB_LOCK_REQUEST ID="X"> | <JOB_LOCK_REQUEST ID="X"> | ||
<RESULT>ACK</RESULT> | <RESULT>ACK</RESULT> | ||
<EPOD_JOB> | <LOAD_ID>XXXXX</LOAD_ID> | ||
<JOB_ID>XXXXX</JOB_ID> | |||
<EPOD_JOB> | |||
..Job Details | ..Job Details | ||
<EPOD_CONTAINERS> | <EPOD_CONTAINERS> | ||
Revision as of 18:07, 14 October 2011
OBS Logistics Ltd
ePOD Exception Handling
CALIDUS ePOD
14th October 2011 - 0.1
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
Menu Structure
Data
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 canceled and the transaction rolled back.
- Two new screens will need to be added 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.
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 occurence 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 recieves a message advising that there are no updates, in which case there is no processing to be done and the process ends.
- The PDA recieves 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 imeditatley 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 promted that there has been a update and will be returned to the first tab of the menu they are using.
- The PDA recieves a NAK due to a error. At this point the application should ignore the update and end the process.
- The PDA recieves no response. At this point the applcation should ignore the update request and end the process.
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.
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
All child elements from EPOD_JOB are not required—User:Milesl, 5/9/2011 17:4:44
<JOB_LOCK_REQUEST ID="X">
<RESULT>ACK</RESULT>
<LOAD_ID>XXXXX</LOAD_ID>
<JOB_ID>XXXXX</JOB_ID>
<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>
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 | 0.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0 | £0.00 |
| Development | 0.00 | 0 | £0.00 |
| Testing and Release | 0.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 | _____________________________ |
