Hi Guys
Is it possible to run mulitple instances of Write Records smart service as a single transaction, i.e. if one of the instances fails, all updates made by previous instances are rolled back?
According to docs, Records can only be updated for one record type at a time (https://docs.appian.com/suite/help/23.1/Write_Records_Smart_Service.html)
So say I have a record type representing a bank account. And I have a process model to transfer money from one account to another.
The high-level steps are:
1) Update balance of account 1 (deduct the amount)
2) Update balance of account 2 (add the amount)
If step 2 fails, account 1 will be charged, but nothing will be added to account 2.
If there is no option to run the 2 actions as a transaction, what is the best practice for handling such cases?
Discussion posts and replies are publicly visible
In Appian I consider the process model to define the transaction. The drawback is, that there is no roll-back. But something like a roll-back only exists inside a database. As soon as you have multiple systems involved, there is almost no way to implement a roll-back.
So, for such a specific requirement as account transactions, I suggest to go with a stored procedure. When using synced records, append a Sync Record node.
Thank you, Stefan.
I'm quite new to Appian, so I've only been exposed to the academy practice apps, where all the app logic seems to be kept inside the app, and the cloud database is used only as a data store.
Your answer, on the contrary, suggests it's a common practice in real-life Appian apps to split the logic between the application and the database. Is this the case?
And expanding on this thought, stored procedures seem to be a reliable solution even to the most trivial cases like setting timestamps on create/update - is this a common practice as well?
I try to keep logic in Appian as much as possible. If you do not need a real roll-back, but are OK with the way Appian processes work, stay with this approach.
Appian is about making software development easy. But it is our decision whether we make use of it. I consider a stored procedure to not be low-code.