These days I have seen developers moving to using database tasks rather than a traditional User Input Task approach.
What are the possible advantages of using DB tasks in terms of reducing memory footprint, creating short lived processes, performance, concurrency and auditing?
Any way whether a process task report or using DB task, we'll be creating tasks to save task IDs, then how it is different and advantageous in comparison to process task report approach?
Discussion posts and replies are publicly visible
I strongly suggest to stay with Appian OOTB as much as possible. Use processes and UITs. This is what Appian is made for. And this is not a "traditional" vs "somethingElse". IMHO, this is more about people trying to force Appian into a use case it is not made for.
And yes, there are use cases which cannot be implemented in the "traditional" way. But they are very rare.
I don't recommend this approach as well. OOTB features are meant to save you time. If you end up reimplementing those features, I think you would need a pretty good reason.
I also recommend to use OOTB features, just consider the next thing as I have already seen some performance issues using the OOTB:
That's a mistake. I was supposed to post a community discussion thread link related to the question here but in hurry ended up posting the teams link by mistake. My apologies.
Originally the comment was to understand the point made by Konduru Chaitanya in the below discussion. Can someone please clarify?
community.appian.com/.../how-to-store-task-report-data-into-db
edit: redacted mistake - thanks for explaining
Was this supposed to be something meaningful to anyone?
Mike Schmitt
That's a hurried mistake. I have edited my comment. My apologies for any kind of misleads.
I believe what Konduru is saying is, in that setup you will maintain a list of work to do in the database, with no Appian process or task active. Then you have a report showing this list of work to the "assignee" listed in the DB, from this report they can choose to initiate a task on that item at any time, which will then create a short lived Appian instance. So, the "task" (and associated process) is only activated ad-hoc instead of always.
This would be different than assigning an Appian Task for each item when it is created, which utilizes Appian memory until completed and the process ends.
Basically, Konduru is saying you will maintain a list of tasks in the database without any Appian processes running. There is a report which shows this list of work to the "assignee" that is listed in the database. From this report, they can initiate a task on that item at any time, and that will lead to the creation of a short lived Appian instance. Therefore, the "task" (and the associated process) is only activated on an ad-hoc basis rather than being activated all the time.
When items are created, they are assigned Appian Tasks, which utilize Appian memory until completed and the entire process is complete and closed, making this different than assigning Appian Tasks when items are created.