Server-side Preferences

When connecting a mobile device to an OMD configuration, the device will receive updates on the agenda using a Push mechanism. This means that the device does not have to poll for information on a regular basis, the updates are only sent if new data is available.

To turn push behavior off, one may set the push2Device preference to false. If turned off, new tasks will only be retrieved if the mobile worker has sent new attachments or if the Refresh menu option has been selected.

When using the push functionality, OMD sends a message to the related devices within the same transaction by default. Since posting a message is still an asynchronous process, this will not decrease performance. In fact, not having to store the events in a separate table usually results in a performance gain anyway.

However, if database buffering is preferred, each change to the calendar of a resource can be stored temporarily in separate table. Once the transaction is committed, the Push Connector asynchronously posts a message to the resources devices to inform about the change. Change the preference push2DeviceSendImmediately to false to store events in a temporary table.

It can be useful to convert the Start of the Day and End of the Day attachments into a break to make these events visible to the planner. Note that the travel calculation of the trip will ignore this break since it is floating (yet to be implemented).

In order to avoid intensive route calculations between departure or arrival locations and the location the Start of the Day or End of the Day was pressed, the preference createSodEodBreakCheckDistance can be used to define a range distance (in meters). Whenever the location of the Start of the Day or End of the Day event is within this range around the departure or arrival location, the position of the departure or arrival is taken as the position for the break.

Information about the current location of devices running OMD Mobile is stored on OMD to provide the Track & Trace functionality, if the preference omdAllowTracking is activated.

Note that the OMD Mobile App sends the location of each device in an interval specified in the process flow preference locationSendInterval¹. Only if this value is 0, the location is not sent. In all other cases, the mobile devices will send their location to OMD. However, OMD will refuse this information if the omdAllowTracking preference is turned off, which is the default. The reason for letting OMD Mobile send the location regardless of this preference is that the preference can be turned on temporarily when a device is lost or stolen, in which case the device can be traced back.

Communication of data to the mobile device is implemented by using a transfer of deltas, i.e. the server identifies those objects that have changed since the last synchronization. This mechanism is fast and reliable, but does not allow for identification of deleted objects. Therefore, OMD keeps tracks of deleted objects and ensure that mobile devices are informed accordingly during background synchronization.

Deleted objects on the OMD server environment are purged after 10 days by default. Note that historic data on the mobile device is automatically purged after 7 days.

If the storePostedXML preference is set (see OMD Configuration Guide), OMD does not store uploads of mobile users unless the storePostedXMLMobile preference is set.

In case the mobile client supports it, the server is able to include customer-related data in the response to a request for data refresh. The response will include the entities Customer, Contract, Contact and ContractLine. This option is switched on by the preference mobileDataIncludesCustomer.

Additionally, the response may include unplanned tasks by setting the preference mobileDataIncludesUnplannedTask.

Additionally, the response may include resource work patterns (rosters), work patterns and working hours per day by setting the preference mobileDataIncludesWorkPattern.

Additionally, the response may include break types and break type translations by setting the preference mobileDataIncludesBreakType.

Additionally, the response may include resource work patterns of overnight stays by setting the preference mobileDataIncludesOvernightStay.

Additionally, the response may include present to future resource work patterns, by setting the preference mobileDataIncludesResourceWorkPattern. The future resource work patterns are limited by the current plan scope. This information can be used on the device, in conjunction with the process-flow preference viewScopeWorkingDays.

A list of certified device models can be specified to warn when using an uncertified device. Specifying the preference as a server-side preference will cause the territory manager and the application managers to be informed. Setting the preference on process flow preference will cause the mobile worker to be informed.

In case a mobile device has invalid system date settings, the preference mismatchDateDuration can be used to inform about the minimum time deviation in minutes after which a notification is sent. Defining the preference on preference level will cause the application managers to be informed about the mismatch. Specifying this preference as a process flow preference will cause the mobile worker to be notified on the device itself.

¹. This preference is described in the OMD Mobile section. ↩