PUSH DATA

To configure a push data logic, must open window "Push Data/Notification Configuration" in SocrateCloud and create new record with next settings

• • Name: Unique Name for Push Data configuration

  • URL: Remote web service URL

  • Table: table that trigger the push data

  • SDEI Published Table: Data content to be exported. To configure a publication see https://sites.google.com/a/bitsoftware.ro/manual-socrateopen/utilitare-extensii/02-servicii-web/22utilizarea-serviciilor-web/222publicarea-tabelelor

  • Document Value Logic: Context logic for data push. To check for available variables for a window you must go to Menu Settings -> Tools -> Context and select Tab Context

For a push data configuration for a specific table you could set Trigger columns. Only when a column specified in this tab is changed then push data starts

Push Data Log

For each push event a new log is created. Each log contains Record ID for record that was modified or added, Data from Published Table, using Record ID numeric parameter, Response from remote call (with text returned, maximum 1000 chars) and information about user that generate the push event and date when happens

If a push request failed than a backup service will make a new call for each active and not synchronized log every 5 minutes for maximum 20 attempts.

• • Synchronized: mark that data was posted to specified URL. Ok response is considered when status code from response is 2xx

  • Counter: count how many times the POST request was made to remote URL. After 20 tries, log became inactive

  • Active: no future post request will be made for inactive logs

SDEI Published Table

When configure a published table used for push data must respect one rule, must use one numeric parameter which is the ID from modified record that start push data event. Must add a new Where Params as numeric, see next imagine as example,

A maximum one of a push data processor can be defined at the tenant level!

For tenants who have not defined a push data processor, the push data records will be resent with the processor on the system level.

For tenants who have defined a push data processor but inactive, the records to be resent for that tenant will NOT be processed at all! This is in the idea that that tenant may want to stop sending push data temporarily.

If a tenant no longer wants to use his own push data processor but the one on the system level, then he will have to delete his own processor definition (it is not enough just to deactivate it).