Projects:OfflineImprovements/Technical Specification

Contents 1 Introduction 2 Components that need to be changed/developed 2.1 Main connectivity control infrastructure 2.2 User feedback components 2.3 Changes in the login process

Introduction

To implement the required changes, several components of the Web POS will need to be changed. This document will list the current tasks that will need to be implemented.

Components that need to be changed/developed

Main connectivity control infrastructure

• ConnectedToERP flag will be preserved, but managed differently. Instead of changing it every time a request succeeds or fails, it will be modified only by specific transitioning functions.
• RequestRouter will not launch remote requests if ConnectedToERP is false. If ConnectedToERP is false, the failure callback will be executed immediately.
• The following asynchronous functions need to be developed:
  • shouldTransitionToOffline()
  • shouldTransitionToOnline()
  • executeTransitionToOffline()
  • executeTransitionToOnline()

• Every time a remote request fails, the function shouldTransitionToOffline() will be called. If it returns true (to its corresponding callback) the function transitionToOffline() should be called.

• All four functions should be extensible via hooks in the client side. In the case of shouldTransition*, the hooks will be able to provide additional criteria to decide if transition should happen. In the case of executeTransitionTo*, the hooks will be able to specify additional actions which should happen on the Web POS when the transition occurs.

• All functions should have concurrency control, so that if another call occurs while an existing call is being processed, it should be automatically rejected.

• In the current implementation, apart from executing their corresponding hooks, executeTransitionTo* functions will just change the value of ConnectedToERP flag to the proper value. However, they provide a global point of code which will allow in the future to add more logic to control and manage the transition between states.

• In the current implementation, shouldTransitionToOffline will do the following:
  • Each time a request fails, a counter will be increased.
  • If the counter is equal to the maximum allowed failed requests, it will return true.
  • Every configurable interval of time, the counter will be reset.
  • The following preferences will be added to configure this process:
    • Web POS Number of failed requests to go offline(default: 1, min: 1 sec)
    • Web POS Interval to reset counter of failed requests (default: 60, min: 5 sec)

• In the current implementation, shouldTransitionToOnline will initiate an asynchronous process which will test the network and server to verify if both are stable, and only in that case will return true to its corresponding callback.

• The process to check if the state should transition to online will consist on the following:
  • Several remote requests over the course of some period of time will be triggered.
  • If any of these requests fails, the process fails and shouldTransitionToOnline returns false.
  • The requests will be done to a backend class which will execute several simple queries, which should return in very short time, to test both that the server is able to respond quickly, and that the network is also fine.
  • This backend class will be extensible via hooks, that will be able to add additional checks specific for each customer.
  • These requests will have a short timeout. If timeout is reached, the request fails, and shouldTransitionToOnline fails.
  • When the reconnect attempt fails we will increase the time to go online in order to ensure that the connection is stable enough.
  • The following preferences will be added to configure this process:
    • Web POS Default time to go online (default: 30, min: 3 sec)
    • Web POS Max time to go online (default: 300, min: 30 sec)
  • The above defined values will not be used by the forced transition to online (Forced by the user through menu button). The forced transition will do a short and no fully reliable transition to online. The aim of this having this ability of forcing the transition is to go ahead in a situation where we need urgently to do a request to backend. In case this transition fails we will start with the default transition to online attempt.

• A new API should be created to build external requests (to other servers) instead of using enyo.Ajax directly. This API would allow developers to specify whether the external request should be managed by the offline/online controller of the Web POS.

• The requests to the hardware manager should not be affected by these changes
• If a system is in Synchronized Mode, it should also not be affected by these changes

User feedback components

• The Web POS will clearly show on the screen whenever the state changes to offline, or to online.
• If the state changes to offline, a widget will be shown until the connectivity changes back to online.
• This widget will show the number of seconds until next attempt to go online.
• This widget will also show a button which the user can use to force attempt to go online.
• The button will not force the transition to online directly. Instead the attempt will be forced (so, the usual shouldTransitionToOnline + executeTransitionToOnline, only on success), and the timeout will be refreshed.
• The widget will also show if the transition to online is already being executed, and the progress of this transition will also be shown via some animated icon.

Changes in the login process

• The login process must be refactored so that if connectivity is lost it automatically fails back gracefully to the offline flow.
• Current check to detect if another session exists when doing the LoginHandler request breaks the offline transition, so it must be reevaluated