ECommerce Bridge - Delayed Sync Messages


#1

cc @Sean_Duane

Continuing on from this post, but wanted to create a new one since the issue is slightly different.

I'm still seeing delays in sync message processing. I pushed this sync message a little over a half hour ago to set the product property in_stock: true.

[
  {
    "integratorObjectId": "108",
    "action": "UPSERT",
    "changeOccurredTimestamp": 1531328487008,
    "propertyNameToValues": {
      "in_stock": "true"
    }
  }
]

Here is what the API is returning when I fetch the product property. Note that it has not changed to the new value.

{
    "objectType": "PRODUCT",
    "portalId": 2252779,
    "objectId": 3919485,
    "properties": {
        "in_stock": {
            "versions": [
                {
                    "name": "in_stock",
                    "value": "false",
                    "timestamp": 1531328487008,
                    "source": "INTEGRATIONS_SYNC",
                    "sourceVid": []
                }
            ],
            "value": "false",
            "timestamp": 1531328487008,
            "source": "INTEGRATIONS_SYNC",
            "sourceId": null
        }
    },
    "version": 3,
    "isDeleted": false
}

Let me know if there's anything I can do on my end.


#2

@Walter_Anderson Thanks for making a new post. I'll take a look next chance I get this week


#3

Thanks @Sean_Duane.

A quick update, the product I mention above still has not received the sync message changes. When I fetch product info using /crm-objects/v1/objects/products, it is still returning "false" for the "in_stock" value.

Just so you know, this is an important step in our integration and having this API work consistently and as expected is a very high priority.

Thanks a bunch!


#4

@Walter_Anderson Thanks for the update.

When you send sync messages for this product, are you making sure to supply a later (closest to present) timestamp? (Since the system is very dependent on those timestamps for what to actually update)

Poking around in our end, I can see 3 sync messages that have the timestamp of 1531838826101 (July 17, 2018, 10:47 am UTC-04:00)

Each specifies an "in_stock" property, however 2 messages have it set to "false" and 1 has it set to "true"

When sending Sync messages, we have to make sure that changeOccurredTimestamp is set to a later time. When the sync process processes changes, it checks the timestamp on incoming sync messages, and the set hubspot properties, and chooses the one set later.

Thoughts?


#5

Aha! Yes I believe I'm guilty of this :expressionless:

After discovering the sync messages were not sending as expected, I saved off the payloads so I could execute them manually without going through the application layer (as a verification/confirmation step). Obviously I wasn't updating the timestamp property, which fits in with what you are seeing. Apologies about that.

I can confirm sync messages are being processing successfully (and in a timely manner) now.


it checks the timestamp on incoming sync messages, and the set hubspot properties, and chooses the one set later.

Quick clarification question about this statement quoted above, just to make sure I understand what it's doing. If I send two sync messages that update the same entity, it will look at both the changeOccurredTimestamp to determine which message was sent most recently, but also the properties within the message?

So if I update property foo in my first message and property bar in my second message, both properties get updated. But if I send property foo in BOTH messages, it will use the value from the latter message?


#6

Great, glad to hear they are working properly :slight_smile:
And no problem, i've done the same while manually sending sync messages.

To your question: A sync message has a set of Properties on it.
Each property gets the given timestamp attached to them,
When we sync the message, the timestamp on each message decides if it will write over what is there (assuming something is there, otherwise it just gets written)
If the timestamp is later, or closer to the present, then it "wins"

So in your example, assuming the last message had a higher timestamp, it will use the value from the latter message.