Archieving and Deleting Process.

Certified Associate Developer

Which one is preffered Archieving or Deleting a process model in Data management .

Any use case for the both ? 

  Discussion posts and replies are publicly visible

Parents
  • 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!! Joy

    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.

  • 0
    Certified Lead Developer
    in reply to Chris
    We've archived millions of processes in the past (early theory), while never having to unarchive 1.  They just eat server resources,

    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.

  • 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?!

  • 0
    Certified Lead Developer
    in reply to Mike Schmitt

    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.

Reply Children
No Data