Archieving and Deleting Process.

RE: Archieving and Deleting Process.

davel001150 — Wed, 15 Jun 2022 19:09:39 GMT

Or you could always search Splunk for a given error message to see when it first started spiking, then find the coinciding release date one or two days before that to determine when Dev injected that bug.

Wound up being how I usually solved the mystery.

RE: Archieving and Deleting Process.

Chris — Wed, 15 Jun 2022 19:06:05 GMT

Agree, would be nice if we could control a combo of archive/deletion.

Maybe (hoping out loud), archiving would some day be replaced with something such as full, automatic (and adjustable) logging of Process History to an area in the Primary Data Source with built-in reporting capability.. Something you could manage with a much lower footprint of storage use, with full auditing capability.. Stick with me...then have the ability to generate a Monitor instance from the data source, without needing the "process instance" unarchived into memory.....

Are we getting warm yet?!

RE: Archieving and Deleting Process.

Mike Schmitt — Wed, 15 Jun 2022 18:45:46 GMT

[quote userid="2401" url="~/discussions/f/process/24863/archieving-and-deleting-process/96356#96356"]We've archived millions of processes in the past (early theory), while never having to unarchive 1. They just eat server resources,[/quote]

I'm annoyed that it's a strictly one-or-the-other configuration decision still. We should be able to archive after 3 days, and delete after 30, for example. It would help if the "new" feature announced last year where we will allegedly be able to view archived processes right in the process monitor, would ever actually roll out. While expressing my annoyance about this at AW, someone hinted that archival in general might be "going away" soon, though I have no idea what this would really look like at the end of the day.

RE: Archieving and Deleting Process.

Chris — Wed, 15 Jun 2022 18:33:45 GMT

Those are always "fun"! If I recall, I learned about it the easy way a while back (from Eduardo during his tenure with Appian). We hadn't run many subs as asynchronous in the legacy Portal/Apps environment, but we do so more now with Tempo and shorter lived processes - and if they are set to delete, do so after 1 day. No one needs more issues 🙂

RE: Archieving and Deleting Process.

davel001150 — Wed, 15 Jun 2022 18:25:44 GMT

That race condition is a fun one. I bet that was fun to figure out (assuming you know about it the hard way).

RE: Archieving and Deleting Process.

Chris — Wed, 15 Jun 2022 17:48:12 GMT

My $.02, doing both Dev and O&M long term on all of my projects, I default to deleting process instances after 30 days. System processes, and more mature processes, I will delete after 7. This generally gives enough time for debugging, and to resolve our most common "Help, we accidentally denied/ended the process and do not want to bother the prior approvers again" (request to restart at a given step). If any high-priority bug occurs, we certainly will know about it within a month's time, and you can edit the instance to add/activate a dummy rule node (or something of the sort) to keep it from archiving if you need more time to debug.

We've archived millions of processes in the past (early theory), while never having to unarchive 1. They just eat server resources, and processes should be designed to save as much audit type information (history, etc) to the DB for reporting. Archiving was more of a potential decision in the original "Portal" days.

If I were doing O&M and received issues on processes that had been deleted after 0 or 1 day, I would certainly start heating up fish!! 😂

The only other note on deletion settings, which I haven't confirmed is still an issue, is it used to be the best practice for asynchronous sub processes to delete at 1 day instead of 0 to prevent a system race condition.

RE: Archieving and Deleting Process.

davel001150 — Mon, 13 Jun 2022 15:35:33 GMT

Cost benefit analysis required:

Archive: Cost, you have to store on disk. You can eventually fill up disk completely. Benefit: You can unarchive and if needed you can use to debug issues or correct problems.

Delete: Cost: You can't debug. You can't figure out what happened beyond what you recorded in audit logs. Benefit: You don't take up any space or resources at all.

Keep Running: Cost: Keeps your engines busy and takes up RAM on your servers. Benefit: Really easy to debug and correct on the fly when you need to.

My advice: If it's a process that does a basic thing, and especially if it processes a mountain of data, go ahead and quickly delete it. Or quickly archive if you can afford the space it takes up. If it's complex, or error prone, or there's lots of ways that it could go wonky, and especially if you have a lot of tickets, keep those longer before you archive or delete to help your O&M team. If each instance is huge, think about delete. If each is small, don't worry and just archive. Think about how long you keep your archives before you offload or delete them too.

Find a balance between being able to fix issues, and improving performance, and saving resources.

RE: Archieving and Deleting Process.

Mike Schmitt — Fri, 10 Jun 2022 15:44:26 GMT

Me too - but the joke is that, apparently, microwaving fish (in almost any style or capacity) unleashes a nigh-permanent and unbearable smell in the entire vicinity - hence how countless office microwaves have signs specifying, "no fish!".

RE: Archieving and Deleting Process.

Stefan Helzle — Fri, 10 Jun 2022 15:38:49 GMT

LOL. I like fish!

RE: Archieving and Deleting Process.

Mike Schmitt — Fri, 10 Jun 2022 15:04:43 GMT

[quote userid="59361" url="~/discussions/f/process/24863/archieving-and-deleting-process/96203#96203"]My default is delete after 0 or 1 day[/quote]

if I were one of the O&M devs in this system you'd regularly get fish heated up in your office microwave...

RE: Archieving and Deleting Process.

vikashk739 — Fri, 10 Jun 2022 09:42:52 GMT

Hi, deleting a process is more preferred way. If I say in other words then generally we keep Parent most process to be deleted at 1 day and the subprocess are kept at 0 day in Data Management.

RE: Archieving and Deleting Process.

Prakash — Fri, 10 Jun 2022 06:38:09 GMT

Thank you

RE: Archieving and Deleting Process.

Prakash — Fri, 10 Jun 2022 06:38:03 GMT

Thank you

RE: Archieving and Deleting Process.

Stefan Helzle — Fri, 10 Jun 2022 06:16:54 GMT

Archiving and Deleting, both means to remove the process instance from active memory. When archiving, it is stored to disk.

My default is delete after 0 or 1 day, except there is a dedicated requirement. Waiting 1 day can help in debugging. Processes which are executed very frequently should be deleted immediately to save system resources.

Any audit relevant information should be persisted to the DB. Do not rely on any process instances.

RE: Archieving and Deleting Process.

GopalK — Fri, 10 Jun 2022 05:41:31 GMT

Hi,

If your process does not have UITs and you dont need process data for any kind of reporting then you can consider deleting them. If your process contains UITs or any specific data that is being used in any reporting then you can consider archiving it and there too you will have to decide the number of days.