To set up the connector, first the API token needs to be generated in Dsync, linked to a System and saved in the connector. Secondly, the schema needs to be requested in Dsync while the relationships need to be created. This is done automatically when the system is added onto the canvas for the first time.
Process ID and Node Synchronization
All incoming and outgoing requests will register themselves in request tables for each type of request: “incoming destination data” and “outgoing source data” respectively. All incoming requests will have the Process ID already while outgoing requests will receive the Process ID in the response.
The connector will receive updates about the status of the synchronization with other connectors. The status update will be received after all nodes have been updated and failed updates will notify the end user and be visible in an administrative view.
For further details on notifications please refer to the attached source.html & destination.html ‘Send/Add a process notification’ web service.
All failed incoming (destination) and outgoing (source) requests will be stored in a table that has been created by the connector. There will be a predetermined amount of retries on failed requests and once that is complete the end user will be notified about the failure. The failed requests will be visible in an administrative view so all failed jobs can be manually retried.
Although it is up to the connector itself to show a status to an administrator, the following are recommended to be available for process notifications:
- The process completed without any issues on the source and destination side and received notification that it is complete.
- Pending Retry
- The process encountered an issue processing the data and is waiting to be retried on the system side. The process should be able to be canceled.
- Pending Notification
- The process complete without any issues on the source system side and is waiting for notification on the status from the destination system side about the status.
- There is an error on the destination system side for a process. The process should be able to be retried manually.
- Unrecoverable Error
- There is an error on the source system side that prevents processing at all (i.e item not found on a update etc).
Incoming Data (Destination)
The connector will have an API built in to handle incoming destination data requests. The api will have specific endpoints depending on the entity types available and perform actions on specified entities based on the method that is specified in the POST request from Dsync. All incoming requests to create, update, or delete data will receive a Process ID which will be saved on the request table.
All authentication for incoming requests will be handled by the connector. The connector will use the generated token from Dsync to validate incoming requests and modify entities on the connectors side. The token will need to be saved in the connector.
All incoming requests to the connector will be in JSON with the response returned in JSON as well.
Failed Incoming Request Handling
The connector must be able to handle asynchronous tasks and maintain a queue of pending requests and responses in order to prevent and handle failures.
Failed incoming requests will try to be run again until they are successful by a background process (cron/php-resque/etc) for a predetermined number of times set in the connector. Failed requests will use the Dsync ID, the entity type, the request and the method that has been saved on the request table. After the max retries the end user is notified of error where they are able to rerun it manually.
Will be used if incoming request is specified as “create”.
Will be used if incoming request is specified as “update”.
Will be used if incoming request is specified as “delete”.
The connector needs the ability to save a job id for each entity when a relation is created in Dsync. For more details on this web service please refer to the ‘Add job for entity’ section within the attached destination.html file.