Force lock object / semaphores

[#1]

Sales Order -> Event BeforeSave.

For every item in the order I read an product-related object, check if it's ok,
- if not ok: throw error and cancel save
- if ok: update it with a new value, making the object unavailable for a second user.

If a second user, in a second sales order, with the same products, saves his/her order at the same time, they will both succeed even though one of the two should fail.

You can write a lot of code to safeguard against this problem, but it's a basic semaphore/locking issue. If I can lock all (relevant) objects BEFORE the check and clear the lock AFTER the update I can avoid this whole business. Is that possible?

[Former Member · Accepted solution]

Hello Vincent,

There is no such functionality via ABSL Scripting to the extent of my knowledge,

I believe the easiest way to achieve this for a Standard BO would be to use a dummy Element and the AfterModify event to trigger a flag that will raise a message in case the same instance is currently being edited by the same user.

In a Custom BO you could achieve this via modifying some of the properties in the UI Designer, however from Standard perspective I cannot think of any way of directly locking the object.

Thanks,

Piotr.

[VVancalbergh · Accepted solution]

Hi Piotr. Semaphores and locks are an ancient problem (going back to early computer hardware design). See https://en.wikipedia.org/wiki/Semaphore_(programming). Thanks for the suggestion, but sadly this only moves the problem to your locking element. You will always do at least two steps: a check for availability followed by marking something as unavailable. If the two steps are not synchronized (they can be run concurrently/in parallel by multiple threads) another user can perform his/her check RIGHT after yours and conclude the object is available as well. These are "race conditions" and are "A Very Bad Thing"(tm).

[Former Member · Accepted solution]

Hi Vincent,

I am very well aware of what Semaphores are and how they work, however as explained previously there is no explicit functions available that would support the creation of Locks/Semaphores via ABSL coding therefore the only option I can think of is to create la simple Flag and whilst race conditions could potentially lead to further issues as the outcome is unexpected, please note that when you enter Edit mode the instance is locked by the system thus eliminating this issue.

Similarly a Before-Save event is only executed when the instance is saved thus potentially multiple users could have already applied changes to that particular instance while the After-Modify script will be triggered on the opening of the instance thus minimizing the chance of multiple users simultaneously opening the same instance and modifying content.

Piotr.

[VVancalbergh · Accepted solution]

Hi Piotr, sorry if that was a bit condescending. I explained it in further detail because, since you suggested something that didn't seem like a good solution, it seemed as if you were not familiar with the subject (and conversely if you ARE familiar with it, why did you suggest it?).

Of course the object you are editing is locked by the UI and thus "protected". But the other user isn't editing the same Sales Order. They are each editing their own Sales Order. In my scenario, because they are both adding the same item, each of their Sales Orders references the same custom BO instance -> They will both attempt to make the same thing unavailable. The UI doesn't lock that object.

So while your answer may be correct that there is no such functionality in ByD (for us SDK-programmers anyway), I cannot accept your suggestion on how to proceed (maybe you can split your answer in "there's no such thing" and "maybe do it this way"? 😄 ).

[VVancalbergh · Accepted solution]

In short: I know how to minimize the risk. I wanted to eliminate it. Thank you for clarifying this.

I am a bit saddened that an SDK Programmer for SAP ByDesign has such poor tools for programming concepts that have been commonplace for decades when ByDesign was conceptualized: atomization, transactions, exception handling, source control. I could go on for a while here.

Off to the Influence forum to post another suggestion! Fingers crossed.

[Former Member · Accepted solution]

I agree Vincent that from the SDK perspective the options are quite limited this is mainly due to how the framework itself is designed to handle PDI coding and how it is executed in the stack.

>Regarding your current scenario, in short there is no easy way to get around this issue 😞

>>Suggestion: Depending on how many Sales Orders are accessing the same Custom BO instance, you could create buffer instances of the Custom BO instance for each of the Sales Orders and have some mechanism in place to push back the data to the single instance (for example by executing a MDR), this is unfortunately not a great solution to the problem however it would ensure that the same instance is not edited simultaneously of course this might not suit your business case.

Piotr.