Right now we have an existing application (non-appian), it has two tables: an ap

guozhangy over 10 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...

Discussion posts and replies are publicly visible

0 guozhangy over 10 years ago

...asier to develop and when we make changes to the Process Modal or CDT, we don't need to regenerate the process instance for the existing pending records. But are there any merit for option 2 and 3, which keeps the Pending records in Appian memory (process instance)?

Thanks.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ashish.deshmukh
A Score Level 1
over 10 years ago

I think keeping data in database will be a good option as:
1. Keeping the data in database will help to short live the processes(The processes defined as related actions to edit/delete/modify data).
2. It also depends on the number of records. If number of records are large, the instances which are live will be large, which increases the number of active instances in system which should be avoided.

Also, if possible you can orchestrate the data from two tables and keep only one tables where the Pending and Approved records in table can be differentiated by maintaining status for each record.(That depends upon your database design.)

Hope this is helpful.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 ashish.deshmukh
A Score Level 1
over 10 years ago

Refer below link for more details
forum.appian.com/.../Record_Level_Security_for_Entity_Backed_Records_Best_Practice.html
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Andrew P Gramann
Certified Lead Developer
over 10 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
0 ashish.deshmukh
A Score Level 1
over 10 years ago

You can take a look at Memory Efficient best practices:
forum.appian.com/.../Creating_Memory_Efficient_Models_Best_Practices.html
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 PhilB
A Score Level 1
over 10 years ago

It's worth noting that it's also possible to implement a record locking mechanism by way of a flag in the table.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 guozhangy over 10 years ago

Thanks for all the replies. It seems the only advantage of using Process Instance is the race condition, which I have heard of but I never implemented purposefully in my Process Modal/Quick Tasks.

I also checked the Memory Efficient best pratices, my process modal is very complicated and clumsy because of all those ad hoc Quick Tasks.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel