Yes, I agree.
Someone suggested that I store the dates in the asset records instead. "If you add new Assets, you want to know if the individual record has been updated or not. Have the synchronization update the current date into that field."
I really like this idea, and I was actually doing this originally.
In the Maximo ASSET table, I created a field called LastSyncDate, and populated it automatically (using the current date) via the JSON mapping, whenever the record got synced. https://stackoverflow.com/a/58122864/10936066
In the external system, I used a dblink (in the external system-->Maximo) and joined from the external system's table -to- the Maximo ASSET table. So in the external system, I had access to the last_edited_date field —and— the Maximo LastSyncDate field.
So in the external system, in the view/web service that I use to serve up records to the Maximo cron task, I was able to create a SYNC_NEEDED column:
case
when gis.last_edited_date > maximo_asset.lastsyncdate or maximo_asset.lastsyncdate is null then 1
else 0
end as sync_needed
That seemed to work quite well. I could determine what records needed to be synced just by comparing the dates in the records (between the two tables).
However, my technical experts hoped there might be a way to do the syncs without the dblink.
- There is a dblink for each of our environments (sandbox, dev, test, prod, etc.).
- And there are several views on the Maximo side —and— several views on the external system side...for each of the tables that are synced (assets, locations, service addresses).
So it was making things complicated from an administrative standpoint.
But I think the safest way is just to compare the dates on a record-to-record basis (via the dblink). And not use a broad/risky approach like LastRunTime or LastSuccessfulSync.
#AssetandFacilitiesManagement#Maximo