Archiving Metastorm Tables

[Jeff Garcia]

Is there a facility to archive Metastorm system tables to a different tables for archiving purposes and improving performance.

For example, we want to move all records that have reached the arcchived stage to a separate table.

[S Cutura]

Hi Jeff,

What do you need to do with the folder data after the folder has been archived. You probably should ask yourself which data you like to keep for auditing purposes. The reason things move into the archive stages is that the folder has been completed and work with that folder is not required anymore and you might need just a small subset of data beyond that stage.

What we have done very often is the following:

Build an archiving data table with the relevant data structure and then insert the data of all folders you like to archive and remove as folder data from the system. You can also remove eEvent Data and efolder data related to this folder. What we generally do is to store the processdata and the eEvent data into an additional text file for further proof. This will be uploaded into the DMS archive. If someone wants to search for information you can offer admin forms to show current folder and history folder data. The history data review form could the  link to the document stored in the DMS (e.g. Sharepoint) , too.

I hope that helps.

Best regards

Sascha

[Jeff Garcia]

Sorry. I am not familiar with the DMS archive so it will be helpful if you can give some background information here.

Basically, we used Metastorm to build a case management system and we would like old cases that were closed in six months or one year to be moved into separate tables so we will only have few records in the transaction table. We think that this will improve performance as we also store attachments in the eattachments table.

We were thinking of archiving the following tables if possible:

eFolder

eEvent

eLog

eAttachment

Basically we were thinking of having the same table structure with the source and just adding a new column DateArchived so we would know the date that the actual data has been moved. So given this information, we were thinking of creating a new set of tables:

eFolderArchive

eEventArchive

eLogArchive

eAttachmentArchive

We were thinking of creating a SQL Job to move the data from source tables to the archive tables.

Your comments please. Thank you.

[Jerome҉]

In our experience, unless you are dealing with millions of records, a good set if indexes far outweighs any benefit from keeping the process table small. It also involves a great deal less risk, maintenance, and development time.

[Jeff Garcia]

I dont  think indeces will be enough as the database is growing siginificantly. The database is growing 500 MB every week and expecting to peek once more people uses it. Our concurrent users is more than 100 users.

Any ideas?

[Paul]

I tend to agree with Jerome. It's really important to size your database platform correctly and make sure that you've thrown enough resources at it. With an appropriately sized platform you should get good performance.

The only caveat I would add is that if you are making extensive use of attachments you may wish to store this information on another platform such as a good document management system and integrate this with your BPM solutions.