Delta Query Support

Delta query means "give me all services that were created/changed/deleted since I last asked". In other words, the delta query protocol defines a pull-model protocol for clients to obtain changes from a store. Clients can poll the store for changes periodically or as required, or capable stores can provide change notifications to alert the client when changes are available to be pulled. The underlying design focuses on the ability of the store not to have to keep any per-client state. This delta query function can be used for the Catalog Service, for example.

The delta query is especially useful for projects where performance is critical and loading each time the full payload is not acceptable, for example for projects where the client often polls to get the latest data and any updates. Thus, for client and server performance it can be very useful to always show the current state in a poll-interaction but with the lowest overhead on both client and server.

The delta query protocol has the following components:

• Delta token

  The store generates a token that can be used to retrieve deltas from the current state of the store. This may be returned as part of a request for data or through some other store-defined means.

• Issuing a request with a delta token

  When the delta token is used to request data, changed or inserted results are returned ordered according to when the changes were made (older changes first).

For changed records, the result must include all changed fields and may contain additional unchanged fields from the record.

A delta token needs to be issued in a normal feed to signal to the client that it supports delta tokens.

The way the delta token is issued and constructed is done by the issuer and is of his choice. Typically it will be a date-time-token (for default cases). In case of a date-time-token you only need to take into account that the delta token should be related to one specific time zone, such as UTC.

A delta token call from a client needs to be handled appropriately. The delta token holds specific information which is known by the issuer. With this information it should be easy to extract the changed data.

Deleted records are not supported at present.

Example of issuing a date-time based delta token:

            *   determine delta token for catalog service.
    GET TIME STAMP FIELD lv_timestamp.
    convert time STAMP lv_timestamp TIME ZONE 'UTC   '
        INTO DATE lv_date
             TIME lv_time.
    CONCATENATE lv_date lv_time into es_response_context-deltatoken. 

         

Example of handling a delta token:

            data lo_delta_context type /IWBEP/IF_MGW_REQ_ENTITYSTDLTA 
* first get the delta token
lo_delta_context =? io_tech_request_context.
lv_delta_token = lo_delta_context->get_deltatoken( ). "converts it automatically into a datetime    
loop at ET_SERVICE_MODEL_INFOS REFERENCE INTO lr_svc_mdl_info.
      TRY .
        
        if lr_svc_mdl_info->*-last_modified le lv_delta_token.
*         then add it to the return table
          delete ET_SERVICE_MODEL_INFOS index sy-tabix.
        endif.
*       catch as much as possible
      CATCH cx_root INTO lx_exception.
*       service does not exist anymore or is not compileable --> put it to the deleted entries
        lr_svc_mdl_info->*-deleted = abap_true.
      ENDTRY.
    endloop.