This is the fifth blog in the series on building custom MDM solution. This blog will talk in detail about the implementation of the operation processing workflow.
The operation processing workflow is represented by a state machine on the server. Here is how it works.
When the admin creates new operations for the device, the default state they start with is ‘pending’. When the devices get the notification, they request for operations. At this point, the ‘pending’ operations are returned to the tablet. When the device finishes processing the operations, it sends the status back to the server. Based on the status of the operation, the operation is marked as ‘success’ or ‘failure’. If the tablet is not able to finish processing the operation in a configurable amount of time, it is set to ‘timed out’.
One thing to note, is we do not make a distinction between newly created operations and that are currently being processed by the tablet. They are both represented by ‘pending’ state. This is intentional because from a operation processing workflow they are both the same. This means that every time the operation asks for its operations, we will be returning new operations and the ones it might already be processing. This works great for error conditions. It is possible that the tablet might have crashed while processing one of the operations and hence did not get a chance to acknowledge its status. In that case, the next time the tablet comes for its operations, it will be returned the pending operation. There is no downside to processing the same operation twice. In that respect, the operations are idempotent.
There is another state machine we use for the ‘notification workflow’. It is maintained on a per device basis. Here is how it works.
When new operations are created for a device, we mark the device as ‘notification required’. When notification is sent to the device, it is marked as ‘notification sent’. When the device comes to get its operations, it is marked as ‘notification not required’. If the device never comes to get its operations, because it is switched off or something like that, it is marked as ‘notification timed out’.
The notification workflow is implemented via a background job. It sends out notifications to the devices and manages the state machine. In addition, it also marks operations that have timed out accordingly.
Pingback: Mobile Device Management | Computellect