Embedded Files
*** Specific functionality for some e-commerce sites ***
The purpose of synchronizing SocrateCloud with the Site is to make certain modifications in SocrateCloud visible to external informatics systems, in real time (with a variable delay, depending on the number of changes, network, etc.), via the web services (defined in the external informatics system).
If you wish to synchronize the products between a site and SocrateCloud, for example, the previous method was to interrogate SocrateCloud at regular time intervals. In order to avoid repetitive interrogation (sometimes without obtaining any new information), SocrateCloud can answer to the product modifications and access the web services in the site.
To exemplify the configuration options, we will start with the following scenario:
The site contains an active web service for the synchronization of products;
The necessary information are the name of the product and its stock.
Configuring the services
The configuration is done by following the path in the menu: Data Exchange Interface -> Site Sync Configuration:
The data are sent under JSON format in POST ['info'], by accessing the available web service indicated in the URL. The number of columns and the data type are those defined for the published table. You can only send a single line with each connexion to the web service.
{
"data": [
{"row": [
<val col1>,
<val col2>,
...
<val colN>
]}],
"metadata": {
"column-count": <N>,
"column-definition": [
{
"column-index": 1,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
},
{
"column-index": 2,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
},
.....
{
"column-index": N,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
}
]
}
}
After defining the web service, move on to indicate the data that will be synchronized. In the Tabels tabs, indicate the tables and columns that will launch the connections to the web services. The validation code limits the number of processed changes.
The synchronisation Log
In the synchronization log you will find the records of all the modifications that have launched connections to the web services. We will present all the steps that lead to the creation of a record in the log and its processing.
Modify the name of a product from the SocrateCloud interface.
Before saving, based on the columns indicated to launch the synchronization, verify whether a modification to be processed has arisen.
After saving, if there are any modifications to be processed, apply the validation defined in the Table tab (self-service product).
If you pass the validation stage, save the new record in the log (indicating the web service and the product ID - the key column).
A synchronization request will be added to the waiting list.
The synchronization will be executed after committing.
Interpreting the Log:
When creating the record, the Data and Response fields are not filled in, and the Active, Processed and Synchronised checkboxes are not selected. When executing the synchronization request (that receives as parameters the accessed web service and the record ID for the interrogation of the published table), all the logs with the above parameters and without the Synchronized checkbox will be selected. Since the user only clicks on the Save button once, while the record can be saved multiple times, there will be multiple entries in the log. As there is a single modification, there is no point in accessing the web service for each separate saving. The connection takes place for a single log record (the active one). The other ones become inactive (are considered processed/synchronized).
The active log becomes processed if it receives an answer from the accessed web service (no matter which this may be). If the answer is {“status”:”OK”}, the log is marked as synchronized. All the log entries must be synchronized, otherwise a synchronization job will start every minute. The History Counter field indicates the number of synchronization attempts. Normally, this needs to be equal to 1. In order to see the root of the synchronization mismatch, you can consult the History tab of the log. ThreadCount indicates the number of active synchronizations (in the modules that has processed the synchronization) at the moment the respective log is being processed.
The Data field is filled in with the data received from interrogating the temporary table, filtered by the Record ID. Note: when modifying the status of a shipment, the Record ID is not the ID of the shipment, but of a product from the respective shipment (each product with its own log).
Note: In order to keep the order of the saves in the database and in the site, you can simultaneously run multiple synchronizations with the same web service and Record ID. All the corresponding logs will be processed sequentially.
Scheduler
The Delete Site Sync Log and Check Unsynchronized Site Sync Log processes must be added to the scheduler. The first erases the log older than the number of days specified in the parameters and the inactive one. The second verifies whether there is any unsynchronized log older than the number of minutes specified in the parameters. If so, it will also send warning e-mails to the specified addresses.
Page updated
Report abuse