Avatar

Correct answer by
Level 4

Hi @Sukrity_Wadhwa,

Below are the details of the custom approach:


The solution works by exposing a custom API method on the tracking server that reads the tracking log entries from the tracking log files on the server. This API method is called from the application server via a scheduled workflow running every 1 hour.

This method takes 4 input parameters which determine which of the logs should be read from the tracking log files and returns the logs in the form of a JSON string which are then saved in a new field in the nms:trackingLogRcp schema.

 

The parameters of the API method are as follows:

 

Input parameter(s): startPointer (the pointer value from where to start parsing the next logs), lastSyncDateTime (timestamp of the last successful synced log), maxLogs (maximum number of logs to retrieve in one API call), 

endPointer (last pointer value synced from the tracking server

by the OOTB tracking update process).

Output parameter(s): logsStr (JSON String with logs and the updated input parameters to

be used to make the next API call)

 

 

The endPointer value in the input parameter is taken from the xml stored in the OOTB option variable "nmsTracking_Pointer". Other input parameters are also configured in option variables for reading and setting them with new values with every execution.

Drawbacks (as I see it): Tracking log files have to be read twice. Once by the OOTB tracking update workflow, and the second time by this custom workflow. An overhead which I do not know how it could be avoided.

 

Benefits: gets the work done pretty fast, without pausing any OOTB process.

 

P.S.: Do not hesitate to comment if there is a better way to do this.

 

Thanks,

Ishan

View solution in original post