Startup sequence and caching approach

Starting with OnTime Group Calendar – Notes and OnTime Group Calendar – Team-at-a-Glance version 3.11.0 the startup sequence has been optimized and the ability to use HTTP for API transport added. Furthermore HTTP transport may be using the agent based or servlet based API. 

The below outlines the startup sequence for the clients after the change and what pieces of information are cached by the clients. Below "token" refers to an OnTime Group Calendar Access Token.

Startup sequence:

  1. Initiallize NRPC transport (Notes session)
    1. Read data from Notes session (username, mailserver, mailfile path)
    2. Create cache qualifier - (slightly modified base64 encoding of (username + mailserver + mailfile path))
    3. Initialize cache in state location (plugin directory under <notes data>/workspace/.metadata/.plugins/<plugin id>)
  2. Attempt to read cached endpoint information from cache location (endpoint.txt)
    1. If no endpoint configuration was found go to mail database and read enddpoint information
    2. If endpoint information indicates all NRPC based transport use that and start client now
    3. If endpoint information indicates use of HTTP save the endpoint information in cache (endpoint.txt)
  3. Attempt to read cached HTTP token from cache location (token.txt)
    1. If a cached token was found set it in the HTTP transport for use (we do not yet know if valid)

Please note: In step 2 above the decision to use NRPC only could be based on notes.ini having $OnTimeGC_ServletIgnore set to 1.

Call sequence:

  1. If no HTTP transport is initialized use NRPC as previous versions
  2. See if there is a token in the HTTP transport -
    1. If yes just continue.
    2. If no use the NRPC transport to access the OnTime Group Calendar Client database to obtain a token for the current user, set it in the HTTP transport and continue. Obtaining a token over NRPC is retried twice to rule out "server not responding" due to networking just coming up.
  3. Forward call to occur over HTTP. When a response comes back from the API check if it's a success -
    1. If yes (success) save the new token and return response to caller.
    2. If no (error) check whether the error is token related and is recoverable before returning the error to the caller. If the error is token related we can recover if:
      1. It's due to a token timeout. Solution is to use NRPC to obtain a new token and retry call.
      1. It's due to a wrong token ID. The token was invalidated by the OnTime administrator on the server. Solution is to use NRPC to obtain a new token and retry call.
      2. If we are unable to decrypt token meaning that the token has been corrupted or meddeled with. Solution is to use NRPC to obtain a new token and retry call.
      3. If it's due to invalid token time type meaning that the token has been corrupted or meddled with. Solution is to use NRPC to obtain a new token and retry call.
      4. If it's because OnTime couldn't match the token to a user the user might have changed on the workstation. Solution is to use NRPC to obtain a new token and retry call.
  4. If the error not recoverable (not something of the above) terminate the transport and return error to caller.

From the above you can see that the caching of the token on the client has no effect from day to day if the token expiration time is lower than the number of hours between the user leaving the office and coming back the next day. In any case a new token will be obtained with a small performance penalty. 

 
Tuesday, 16 December 2014 Posted in Notes Interface