FS 292887 ePOD Exception Handling: Difference between revisions

From Calidus HUB
VisualWikitext
(Created page with "<div class="noprint"> {{#vardefine:Client|PROD}} {{#vardefine:ClientName|OBS Logistics Ltd}} {{#vardefine:System|''CALIDUS'' ePOD}} {{#vardefine:Doc_Title|ePOD Exception Handling...")
 
(v1.0 - Issued after final updates)
 
(22 intermediate revisions by 2 users not shown)
Line 4: Line 4:
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|ePOD Exception Handling}}
{{#vardefine:Doc_Title|ePOD Exception Handling}}
{{#vardefine:Version|0.1}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|14th October 2011}}
{{#vardefine:Date|17th October 2011}}
{{#vardefine:Reference|292887}}
{{#vardefine:Reference|292887}}
</div>
</div>
Line 22: Line 22:


== Client Requirement  ==
== 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  ==
== 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  ==
== 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.


<!-- NEW PAGE -->  
<!-- NEW PAGE -->  
Line 32: Line 44:


== Pre-requisites  ==
== Pre-requisites  ==
There are no additional prerequisites for this new functionality other than those of the initial system.


== Menu Structure  ==
== 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  ==
== Data  ==
None


<!-- NEW PAGE -->  
<!-- NEW PAGE -->


= Functional Description  =
= Functional Description  =


== Functional Area 1  ==
== 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.


<!-- MEDIA LANDSCAPE YES -->
=== 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.


= Appendix A: TEST PLAN  =
===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.


{{TestPlan_Header
=== Server Process ===
|Title={{#var:Doc_Title}}
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.
|Log={{#var:Reference}}
 
|Description=description of what is to be achieved
The Server will get the Load DAL object for the load on the message request.
|MenuAccess=Where on the menus the item can be found
 
|Prerequisites=The prerequisites of the test
For the load record:
|Objective=The details of what each group of tests is to achieve
:If last changed date > date on record, send details of the load to PDA
}}
::For each job on Load:
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
:::Add a Job tag
{{TestPlan_CycleHeader
:::If last changed date > date on job record:
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
::::Include all data
|Title=Area being tested in this cycle
:::If job is not service:
|Notes=Any notes or prerequisites for the tests following.
::::For each container in job:
}} <!--INSERT TESTS HERE --> {{TestPlan_Test
:::::Add a Container tag
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
:::::If last changed date > date on container record or job has changed:
|Action=The actions to follow
::::::Include all data
|Result=The expected result
:::::For each product in container:
|Remarks=
::::::Add a Product tag
|PassFail=
::::::If last changed date > date on product record or container has changed:
}} {{TestPlan_Test
:::::::Include all data
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
:::::Next
|Action=The actions to follow
::::Next
|Result=The expected result
::::For each Loose Product in job:
|Remarks=
:::::Add a Product tag
|PassFail=
:::::If last changed date > date on product record or job has changed:
}} {{TestPlan_Test
::::::Include all data
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
::::Next
|Action=The actions to follow
:::Else
|Result=The expected result
::::If last changed date > date on service record or job has changed:
|Remarks=
:::::Add a Service tag
|PassFail=
:::::Include all data
}} {{TestPlan_CycleFooter}}
:::End If
::Next
: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>


<!-- MEDIA LANDSCAPE NO -->  
<!-- NEW PAGE -->  
{{Doc_Appendix
{{Doc_Appendix
|Appendix=B
|Appendix=A
|Estimate=Y
|Estimate=Y
|Glossary=WCS
|Glossary=EPOD
|Ref1=Reference1
|Ref1=
|RefV1=0.1
|RefV1=
|RefDate1=01/01/2011
|RefDate1=
|REQ=0
|REQ=0
|EST=0
|EST=0
|FS=0
|FS=2.0
|TS=0
|TS=0
|DEV=0
|DEV=14.0
|ST=0
|ST=2.0
|IMP=0
|IMP=0
|Client={{#var:Client}}
|Client={{#var:Client}}
|Year=
|Year=2011
|FSEST=Y
|FSEST=N
|Rev1=Rev1
|Rev1=Tony Walker
|Rev1Title=Rev1 Title
|Rev1Title=OBS Consultant
}}</div>  
}}</div>  
[[Category:{{#var:Client}} FS]]
[[Category:{{#var:Client}} FS]]

Latest revision as of 11:19, 17 October 2011




Aptean Logo.png







OBS Logistics Ltd

ePOD Exception Handling

CALIDUS ePOD

17th October 2011 - 1.0
Reference: FS 292887











































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
Else
If last changed date > date on service record or job has changed:
Add a Service tag
Include all data
End If
Next
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 NoDocument Title & IDVersionDate
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		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_292887_ePOD_Exception_Handling&oldid=265’