VersionStamp questions

#1

Hello,

A couple questions here on the VersionStamp property that is present on most data entities. We are intending to keep track of a list of the VersionStamps for all records for each data entity that we will be integrating to our Accounting system in a local database table. We will then compare each record’s VersionStamp in Quantify to that data table, to see if a record has changed (since Quantify does not support push integrations).

My general question is this: I am primarily concerned about the performance of this, so I am curious how other large companies like us have handled this sort of integration, or what Avontus advises from a performance standpoint. We are a $4 billion company, and although only one of our subsidiaries is using Quantify as of now, we hope to scale our integration to a larger portion of our company soon, so I would anticipate thousands of invoices and product transactions needing to be looped through many times per day the way we are doing it.

My more pointed question is: we are currently intending to loop through the Collection objects of each data entity (for example Shipments or Movements), running GetMovement, GetShipment, etc. to get the individual item, grabbing the VersionStamp for each, and sending that to be compared against the VersionStamp list from our last run. How fast is the Quantify API for calls such as GetMovement or GetShipment? What happens if we are running GetMovement/GetShipment 10,000 times each, every 10 minutes or so (whatever the frequency we set our integration to be at)?

In my mind it would be more efficient if the VersionStamp property was located on the Collection/List objects for data entities as well as the individual data entity objects - but perhaps there is a reason I am not seeing for this, or better yet, a more efficient approach we should be using.

Please let me know if anything I explained above is not clear, or if you need code examples or more information from me on how we are architecting our integration.

Thanks so much for your assistance,
Alex

#2

One additional question related to VersionStamps - It looks like each VersionStamp is a length 8 byte array, with varying entries populated (typically towards the end).

If I want the most recent VersionStamp from a record, should I be grabbing the last index in that byte array?

#3

Hi Alex.

VersionStamp is basically SQL Server data type timestamp, not null under the hood. This is intended to be only used reliably for = or ≠ checks to identify if a row has been modified. I’ll discuss with the team and get back to you on the initial question.

Thanks for posting.

#4

Hi Alex.

We will be exposing VersionStamp property in lists from the next version onwards.
Also, FYI, a core list of changes to Shipments and Transactions/Movements with the respective datetimes are available through LogEntryList object.

#5

Ok excellent, that is good news those are getting added into the list objects. Do you know when the next version will be released, and do we need to manually update to that version or does Quantify typically auto-update for this sort of thing?

I want to make sure I’m fully understanding here, though - can you please provide me a code example of how to identify if a jobsite record has been modified through the VersionStamp property? What we are doing now is creating a SQL table to house all of our VersionStamp values, but to give it a value I have been extracting the last entry in the VersionStamp byte array, as follows:

foreach (StockingLocationListItem jobsiteItem in all_jobsites)
{
StockingLocation jobsite = StockingLocation.GetStockingLocation(jobsiteItem.StockingLocationID, false);
string myJobsiteNumber = jobsite.Number;
DataRow myNewRow = dt.NewRow();
myNewRow[“Entity”] = “Job”;
myNewRow[“QuantifyID”] = myJobsiteNumber;
myNewRow[“Version”] = jobsite.VersionStamp[jobsite.VersionStamp.Length - 1].ToString();

            dt.Rows.Add(myNewRow);

            //***** Build Dictionary *****
            if(!myJobsDictionary.ContainsKey(myJobsiteNumber))
            {
                myJobsDictionary.Add(myJobsiteNumber, jobsite);
            } 
        }

Then, in a SQL stored procedure, we compare the versions coming in vs. the versions we have stored in our SQL table, and see which are different. The version stamp ends up being a number, not a timestamp. Does that sound correct to you?

Thanks,
Alex

#6

Disregard the above - we think we figured this out. The byte array needs to be converted back to a timestamp (or equivalent string) and compared as a whole, not just grabbing pieces of the byte array. We implemented this and it seems to be working when we update a job in Quantify; our process is able to determine that record changed and integrated.