Archieving and Deleting Process.

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.

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.

Thank you

Thank you

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. 

Unknown said:

My default is delete after 0 or 1 day

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

LOL. I like fish!

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!".

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.

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.