Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
7 replies
Subscribers
4 subscribers
Views
2293 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
Process
Right now we have an existing application (non-appian), it has two tables: an ap
guozhangy
over 9 years ago
Right now we have an existing application (non-appian), it has two tables: an approved table and a pending table. When a record is in pending stage, it was stored in pending table and it will move to the approved table after the approval.
My question is what is the best pratice to handle the Pending records when we move to Appian? Should we keep the Pending records in the table or should we move the Pending records into the Appian Process instance? We can have three options:
1. Keep the pending records in pending table only, all the related actions (EDIT/DELETE/APPROVE) will be in a new Process Modal.
2. Keep the pending records in Appian process instances, all the related actions (EDIT/DELETE/APPROVE) will be in quick tasks.
3. Keep the pending records in both Pending tables and Appian process instances, all the related actions (EDIT/DELETE/APPROVE) will be in quick tasks.
From my experience, I feel more comfortable to use option 1, it's much e...
OriginalPostID-143477
OriginalPostID-143477
Discussion posts and replies are publicly visible
Parents
0
Andrew P Gramann
Certified Lead Developer
over 9 years ago
Approach 1 is much better aligned with best practices for the reasons you've already mentioned. It also generally uses less memory on the process execution engines.
Sometimes it's a little bit easier to control race conditions gracefully if you use quick tasks instead of process model backed related actions. For instance, if multiple people want to update the pending record at the same, it's easy to come up with a process variable based locking mechanism if you use quick tasks. The locking becomes a bit more complicated (though still possible) if you use standalone process instances for these actions.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
Andrew P Gramann
Certified Lead Developer
over 9 years ago
Approach 1 is much better aligned with best practices for the reasons you've already mentioned. It also generally uses less memory on the process execution engines.
Sometimes it's a little bit easier to control race conditions gracefully if you use quick tasks instead of process model backed related actions. For instance, if multiple people want to update the pending record at the same, it's easy to come up with a process variable based locking mechanism if you use quick tasks. The locking becomes a bit more complicated (though still possible) if you use standalone process instances for these actions.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data