RE: Unable to stop the Race conditions in a process model

davel001150 — Tue, 02 Feb 2021 15:11:39 GMT

If you need an entire process to run in the background, one thing you might want to consider is actually making the button a submit button. Submit the form, move on in the process, call a synchronous sub-process (so it has to finish before you can move on) and activity chain the whole thing in a massive loop back to the same form you were in. If you can configure it well enough, you might be able to dump the user right back into the same form in such a way they won't even notice that they left and came back. (It really, really helps if the form is so short that there's no scrolling.)

Another thing you could do is simply add a Task Form to your subprocess as a confirmation screen. You load that form in a branch near the beginning. Use an AND gate at the beginning and at the end, so the DB processing AND the form both have to be done before it terminates. The user has to reach over and click the "OK" button to close the form, which does nothing but hide the main form from the user while you complete the write.

If you don't need to do that much processing with other script tasks and such, it is best to avoid the subprocess and just process in a rule you call that calls the a!writeToDataStoreEntity() as suggested below. If it's simple enough, that is the best approach if you include the toggle to make sure the button can't be pressed multiple times. Without that, it will seem just like the race condition.

RE: Unable to stop the Race conditions in a process model

Chris — Sat, 30 Jan 2021 15:46:32 GMT

To start us off here, why is a process model required to write data to the DB on a button click while the interface is still active? If this is a requirement, note utilizing a!writeToDataStoreEntity() on the button click instead is much lighter and much easier to control.

Additionally, if you set a flag on the button click, users should only be able to click once - potentially reset the flag to false if any data is modified that might need to be persisted to the DB? Otherwise if you can post more details about your configuration and use case, that would assist here.

a!localVariables(
  local!buttonClicked: false,
  
  {
    a!buttonArrayLayout(
      buttons: {
        a!buttonWidget(
          label: "Write Data",
          value: true,
          disabled: local!buttonClicked,
          saveInto: {
            local!buttonClicked,
            a!writeToDataStoreEntity(
              dataStoreEntity: cons!COE_DS_TESTING,
              valueToStore: 'type!{urn:com:gdit:types}COE_TESTING'(data: "test")
            )
          }
        )
      }
    )
  }
)