FS 353641 WEBFLEET Concurrent Updates to EPOD

From Calidus HUB





Aptean Logo.png







OBS Logistics Ltd

WEBFLEET Concurrent Updates to EPOD

CALIDUS ePOD

8th November 2018 - 1.0
Reference: FS 353641











































Functional Overview

Client Requirement

This is a product enhancement.

To enhance WEBFLEET integration to filter and accept status updates from both WEBFLEET and the CALIDUS ePOD mobile device application.

The WEBFLEET update interface was developed for Greene King which does not include the CALIDUS ePOD mobile application, so for example an arrival message from TomTom and ePOD mobile device applications can overwrite each other when they are processed into CALIDUS ePOD.

We require the ability to select which messages are accepted from which source when ePOD mobile is implemented alongside TomTom WEBFLEET, so we have a generic integrated solution.

This requirement arose from the sale to AB Texel.


Solution Overview

EPOD has functionality to:

  • Create WEBFLEET orders assigned to a vehicle
  • On-device integration
    • Show maps (ad hoc)
    • Switch to WEBFLEET
    • Get User
    • Get Vehicle
  • Get updates in from WEBFLEET (based on WEBFLEET orders above)

The interface currently works as follows, with the restrictions as shown below:

  • WEBFLEET orders are assigned to a vehicle, not a trailer or driver.
  • WEBFLEET always updates the applicable dates if we get the messages in, so a job completion will update the END date in EPOD, a job start will always update the START date, etc.
  • C-ePOD mobile devices also always update the dates when the data is received in:
    • Job Lock always sets the Actual Start Date and Time and GPS
    • Job Arrival always sets the Arrival Date and Time and GPS
    • Job Update always sets the Actual Start and End Date and time.
  • Therefore both updates will overwrite the other, depending on which update is processed into the system first- there is currently no way or predicting which will process first, given the delay receiving data from WEBFLEET.
  • It is not possible to control which order updates the system receives from WEBFLEET - the system either receives ALL the order updates or none of them.
  • Although it is possible to control the WEBFLEET workflow i.e. remove job completion, it is believed that this simply marks the job as complete when the drivers arrive at the order's address and therefore the system would still receive a final order completion update message, which for certain operations (like AB Texel) is undesirable.


The development required is to acknowledge that there are updates from multiple sources and identify which source is the primary source of data. The data being controlled by this will be:

  • Actual Start Date/Time
  • Arrival Date/Time
  • Actual End Date/Time

This will be configured against the site.

The WEBFLEET updates import and EPOD Device web service will be modified to obey the following rules:

  • When primary, ALWAYS update data fields being affected.
  • When not primary, ONLY update data if there is nothing already in the data fields being affected.

Additionally, the WEBFLEET updates import process will include configuration within the WEBFLEET import configuration itself to control which order update messages the process will deal with, so that the process can block WEBFLEET Complete messages.

Additional time will be added for analysis and testing of this change.


Scope

It should also be noted that certain parts of this WEBFLEET update interface are explicitly blocked from working when running alongside the CALIDUS ePOD mobile device application, namely:

  • Status Updates (i.e. order rejections, cancellations and completions on WEBFLEET to not update the status in EPOD).
  • Ad Hoc Breaks created in WEBFLEET do not create when EPOD is working.

Changes to these areas are not included as part of this change.

This change assumes that each process can update only once from the core messages (WEBFLEET and C-ePOD Mobile Device).

The changes specified here will allow control of which interface is the primary source of data for Start, Arrival and End Date only and the configuration of whether messages are processed ONLY. The changes here do not allow for storing the data from both systems concurrently for later viewing. If the primary source of data for those fields has been provided, it will be stored and displayed. If the primary source of data for those fields has not been provided and the secondary source has, then the secondary source will be stored and displayed.


Set-up

Pre-requisites

Menu Structure

Data

The following Import/Export Interface Configuration is required:

  • C-ePOD Import and Export interfaces will be configured to send orders to WEBFLEET and to accept updates from WEBFLEET.

Note that the expected configuration of the TomTom Orders Update interface (inbound direction) is expected to be configured for the primary implementation for Start and Arrival message types ("S|A") only.

The following Site configuration is required:

  • C-ePOD NOT set up as PvA system.
  • C-ePOD set up to have no Arrive functionality.
  • WEBFLEET Updates configured.

Note that the expected configuration for the primary implementation for WEBFLEET to be the primary source of Start and Arrival data only.

The following Standing Data is required:

  • WEBFLEET Object IDs must be configured against the vehicles in C-ePOD.
  • WEBFLEET user names and C-ePOD PDA user names must be the same for automatic logon to WEBFLEET devices to work.


The following TomTom WEBFLEET configuration is required:

  • The WEBFLEET work-flow modified to have Start and Arrive but no Complete stage.
  • A listening queue is created in WEBFLEET through the web services.
  • WEBFLEET user names and C-ePOD PDA user names must be the same for automatic log-on to WEBFLEET devices to work.


Functional Description

Database/DAL

New fields will be added to EPOD_SITE:

  • EPL_XFI_START_IND - int, default 0
  • EPL_XFI_ARRIVAL_IND - int, default 0
  • EPL_XFI_END_IND - int, default 0

These fields will be added to all stored procedures in the database that require them.

These fields are not required on the device.

These fields are not required to be contained within the Export.

These fields are not required to be used when filtering data for selection.


C-ePOD Admin

Site Configuration Screen

The Site configuration screen (Site.aspx) will be modified to allow the new Site flags to be maintained.

A new tab will be added to the Tab Group, labelled as "Import/Export".

The existing flags in Import/Export panel of the Admin tab will be moved here.

The new tab will be organised in two sections:

  • The left will be the existing flags
  • The right will be WEBFLEET-related flags, labelled as such.

The new flags will be added to the WEBFLEET area. Each will be added as check boxes, with pop-up help

  • Field EPL_XFI_START_IND, Label "WEBFLEET Update Job Start", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job Start Date and Time?".
  • Field EPL_XFI_ARRIVAL_IND, Label "WEBFLEET Update Job Arrival", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job Arrival Date and Time?".
  • Field EPL_XFI_END_IND, Label "WEBFLEET Update Job End", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job End Date and Time?".

The default state of these flags will be unchecked.

Each flag will allow the following values:

  • "Primary" (checked)
  • "Secondary" (unchecked)


All tabs affected will be checked to ensure that the fields are displayed using available space on multiple window sizes - a clean display using available space is required.


Import/Export Interface Screen

The Import/Export Interface screen (XF_Config.aspx) will be modified for this change.

Field EPL_EXPORT_JOB_TYPES will be enabled for "TO" ID configurations, Inbound direction (value "I") only. This will control what types of updates are processed:

  • "S" - Job Start
  • "C" - Job Complete
  • "A" - Job Arrival
  • "X" - Job Cancel/Reject

Each value will be specified in the parameter if the messages of this type are to be processed, typically in a single string, for example:

  • "SCAX" - all updates allowed
  • "SAX" - all except Complete messages
  • "SA" - Start and Arrival only

It is recommended that these values are delimited with vertical bar for clarity, for example:

  • "S|C|A|X"

The entry field (currently txtExportJobTypes) will be displayed with a label "Message Types" and will have a custom validator to validate the entry (in this case) to variants of "S", "C", "A", "X" or a blank field.


Mobile Device Update Process

The web services processing update messages from the mobile devices will be modified for this change.

The following message types are affected:

  • JOB_LOCK_REQUEST - when a job is started
  • JOB_ARRIVAL_REQUEST - when a job is arrived
  • JOB_UPDATE - when a job is finally updated as complete or cancelled.

These are processed in MessageProcess.cs.

When processing Job Lock messages (in function ProcessJobLockRequest), the process will check the site configuration. If EPL_XFI_START_IND is set to 0, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 1, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.


Note that this process is also responsible for the setting of Arrival date and time (in EPL_ARRIVAL_DATE/TIME). When updating arrival date and time from this message, the process will check the site configuration. If EPL_XFI_ARRIVAL_IND is set to 0, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.


Job Update processing can be used to set Job Start, Arrival and End dates, as it is a final update of all data after the job is completed.

When processing Job Update messages (in function ProcessJobUpdate), the process will check the site configuration.

When updating the Start Date and Time, if EPL_XFI_START_IND is set to 0, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 1, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.

When updating the Start Date and Time, if EPL_XFI_ARRIVAL_IND is set to 0, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.

When updating the End Date and Time, if EPL_XFI_END_IND is set to 0, then the process will over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME. If EPL_XFI_END_IND is set to 1, then the process will check the value of EPL_END_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME.


Auto-Import Process

The Auto-Import process will be modified to handle this new configuration.

The core changes are to module EPOD_TOMTOM_WEBFLEET.cs, in the following procedures:

  • ProcessTomTomWEBFLEETImport
  • ProcessMsgQueueResponse
  • PopulateFromMsgQueueResponse

These processes require an additional parameter passed to them (from EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES) to pick up the message types that the process is going to deal with (and more importantly to filter out).

Class OrderType is used defines the types of messages - the process uses this to determine what action to take based on the message from WEBFLEET.

The parameter set from EPL_EXPORT_JOB_TYPES will be checked for the configuration of which messages to process.

  • If the field is empty, all messages will be processed as now.
  • If the field contains "S", messages of OrderType.JobStart will be processed.
  • If the field contains "A", messages of OrderType.JobArrival will be processed.
  • If the field contains "C", messages of OrderType.JobComplete will be processed.
  • If the field contains "X", messages of OrderType.JobCancelOrReject will be processed.

When processing OrderType.JobStart messages, the process will check the site configuration. If EPL_XFI_START_IND is set to 1, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 0, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.

When processing OrderType.JobArrival messages, the process will check the site configuration. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 0, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.

When processing OrderType.JobComplete messages, the process will check the site configuration. If EPL_XFI_END_IND is set to 1, then the process will over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME. If EPL_XFI_END_IND is set to 0, then the process will check the value of EPL_END_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME.

Regardless of the setting of these new Site flags, the process will log the message from TomTom WEBFLEET in the audit log as now.


Appendix A: TEST PLAN

Test Script / Scenario ReferenceWEBFLEET Concurrent Updates to EPODCall Number(s): 353641
Test Script / Scenario DescriptionA test of WEBFLEET and EPOD updating together.PASS / ISSUES / FAIL
Menu Access  
Pre-requisitesA configured and connected EPOD and WEBFLEET system and a TomTom PRO device.Tested By:
 
Test ObjectiveThe test is designed to check the functionality as required by the primary implementation only.Date:
 



Step Action Result Remarks P/F
1 Job Updates      
  Configure as the primary implementation requires (as identified in the specification).      
1.01 Create a Load and a Job. Assign the load to a vehicle linked to a WEBFLEET vehicle. on the PRO device, ensure that the device is logged in to WEBFLEET. Start EPOD and log in (if not automatically logged in) The load is assigned to the user/vehicle in EPOD, as status "In Progress". The order is seen against the vehicle in WEBFLEET.    
1.02 Select the job in EPOD, then click the Map icon in Job Details WEBFLEET starts on the device.    
1.03 Select the order from the work list. Accept it, the start it. EPOD is updated with the Start Date and Time.    
1.04 Arrive the job in WEBFLEET. EPOD is updated with the Arrival Date and Time.    
1.05 Return to the EPOD application on the PRO device and click Start. The start date and time in EPOD is not overwritten.    
1.06 Complete the job on EPOD. EPOD is updated with the End Date and Time. The start and Arrival dates and times in EPOD are not overwritten.    


Appendix B: Quote & Document References

Cost Details
Activity Estimate
No. of Days		 No. of Days Rate per Day (£) Cost (£ Exc. VAT)
Requirements 0.00 0.00 0 £0.00
Change Request Evaluation 0.00 0.00 0 £0.00
Functional Specification 1.00 1.00 0 £0.00
Technical Specification 0.00 0.00 0 £0.00
Development 3.00 3.00 0 £0.00
Testing and Release 1.75 1.75 0 £0.00
Implementation 0.50 0.50 0 £0.00
Project Management 0.25 0.25 0 £0.00
 
TOTAL 6.50 6.50   £0.00
Estimate excludes training, release to live and go live support.

B.1 References

Ref NoDocument Title & IDVersionDate
1   


B.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.


B.3 Authorised By


Matt Turner
CALIDUS ePOD Account Manager		_____________________________

Barry Preece
Primary Implementation Project Manager		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_353641_WEBFLEET_Concurrent_Updates_to_EPOD&oldid=6556’