Sorry I don’t believe this is possible. What is likely to happen is that if the webhook updates a record you are actively editing, when you go to save in the UI it will error that the record was modified by someone else and not save your changes.

Hi Shawn-

Yes, that is basically what happens. However, because the webhook code is programmed to “Press Save”, what actually happens is the user changes will be discarded (this is behavior that I want, because presumably you have added items externally to the order, and are just reviewing them in Acumatica).

Acumatica should allow developers to tap into user sessions, and to push updates up to the UI for Sales Order/PO Creation. When you use the native “Add Items” functionality, this is a Smart Panel that overlays the Sales Order, and injects an array of items into the underlying screen. It seems like there is no reason this functionality couldn’t be extended to requests done using a webhook. We just need the ability to target specific user sessions…

Thanks,

Jonathan

This issue is caching and sessioning. The webhook is in a separate session, so there is no way (that I know of) to have it link into your user session and update the cache.

Secondarily, without custom code that allowed having a constant refresh, the only way for your UI to be updated is during postback. So until you did something like update a line or hit an action or saving, there is nothing to trigger the UI to update and pull those changes in.

The problem as I see it is that it would be difficult to have to system stay sync’d and not allow Users to clobber each other in maint screens. E.g. you and someone else are editing the same sales order and both adding the same line detail, if you weren’t careful you could both “succeed" and then be doubling the change.

Lastly, as good as I am, I am the end all guru here, hopefully one of the Acumatica Engineers can chime in and confirm I am not crazy :)

@Shawn Burt I don’t agree that there is no way to link into the user session and update the cache. Acumatica is already baking the necessary tools into the product. For example, Acumatica is using SignalR in its push notification feature. SignalR wraps SSE, which is a protocol that allows for real time updates of client browser sessions from a server: https://en.wikipedia.org/wiki/Server-sent_events

So the protocols and technology are there. I would argue that the current state of affairs is not tenable long term. For example, when my webhook updates the Sales Order of the user (this is live now), then if the user has in the meantime clicked into the Sales Order line area and generated a new line (even if it’s empty), this has the effect of popping a warning that the order has been modified and changes will be lost, once the user tries to save the order. The webhook (so far) has always seemed to win this tug of war between user and webhook, which is our desired outcome. But what if we wanted the user to win this war? Shouldn’t there be a way to tell the system who wins in terms of a conflict, and to generally avoid the situation where users are receiving bizarre warning messages due to no fault of their own?

So the concurrent update problem is already implicated by being able to push updates through the backend with webhooks. The question is how should it be dealt with? I would argue the proper way to deal with it is to push the new sales order line to the user’s session and show the change, then allow the user to accept the merge by hitting save. No more bizarre warning messages, no more confusion on the part of the user.

Thanks,

Jonathan

Just to add to the general discussion here, after giving this a little more thought…

@Yuriy Zaletskyy already has an article about consuming push notifications with SignalR:

https://www.acumatica.com/blog/using-signalr-with-acumatica-push-notifications/

The interesting thing about all of this is that Acumatica has created a way to push notifications to third party systems to alert the user of changes. And they have created a way to consume updates from external systems (webhooks). But there seems to be a gap in the product at the moment, which is allowing Acumatica to display/act on webhooks by pushing updates to its own user browser sessions. Basically, we need a way to target a push at the user’s current Acumatica session.

Currently Acumatica uses “Optimistic Concurrency Control” and they do provide ways to bypass it attributes(PXAccumulatorAttribute for example). You aren’t wrong in that it is completely possible to support a more flexible concurrent model given current web technology.

But it is a huge undertaking and the platform is already playing a bit of catch up to current tech by moving to .Net Core and Aurelia(UI). Apart from the need to implement real-time client-server communication, there are numerous design challenges about how to handle conflicting commits and ensure data consistency. 

I do agree that long term a more collaborative model is necessary, we are seeing that trend across almost all technology.

In regards to your question on who “wins out” it is literally whoever commits their changes first. When committing changes Acumatica compares the graph timestamp(recorded when initially selecting data) with the the timestamp of the database record and throws an error if it has changed(another process committed changes). Acumatica does provide some limited tools to allow you to customize this though. This article(https://asiablog.acumatica.com/2019/02/concurrent-update.html) goes into more detail on that if you are interested. 

@markusray17 I think the PXAccumulator type approach is certainly a decent way to handle the issue in certain contexts. Passing some sort of anonymous function into the commit might be another way to do it, with the function overriding the default save logic.

Interestingly, my issue isn’t really a concurrency problem (or at least it’s a false alarm). Most of the issue has to do with the system thinking there is a change, because of an accidental click into the sales order items (this creates a new blank line….but that line isn’t one we actually want to create). This is enough to trigger the change management warnings.

I think regardless of whether concurrency is implicated or not, it is desirable to update the UI when changes get saved through webhooks and APIs. I am working on some code to push to the frontend with SignalR when there is a backend change.