1. SETUP ARCHIVING/PURGING OF IS CORE AUDIT AND PROCESS
AUDIT DATA
The IS Core Audit schema contains the service, error and document level auditing details of the services
currently running on the Integration Server. The Process Audit schema has tables which contain
information about process runtime data.
The Archiving schema contains the stored procedures and the necessary tables required for performing
archiving/purging on the tables in IS Core Audit and Process Audit. Below is a summary of how the
archiving is performed for the Audit data.
Tables in Archiving Schema:
1. Operation_parameter: This table contains all the parameters needed for performing the
archiving/purging on the tables. It has information to decide if you want to purge or archive
respective tables, the number of days of retaining the data and also the status for which the
data needs to be purged/archived.
2. Operation_control: This is the primary table for starting the archival process. The individual
stored procedures refer this table to check if previous process has completed successfully for
archival/has failed and makes a decision. If the previous process is still running, the current
process does not start, but simply makes an entry in log stating that the previous process is still
running.
3. Operation_log: This table contains a log entry for all the steps being run as part of the archival. It
will contain the start and completion steps for every archival cycle (e.g. for Server archival,
Service archival, process archival, etc.) and also contains the number of records being purged
from every table.
Steps for performing Archiving/Purging:
1. In the operation_parameter table, verify that the operation_status field for operation_name as
MONITOR_ARCHIVE is set to COMPLETE/ERROR. If anything else, the archival process will not
start. By default initially the status would be set to COMPLETE.
2. In the operation_parameter table, set the entries for the field properly. Every field in this table
has a description provided. For field like SERVICE_ARCHIVE_ACTION, set the value to DELETE if
you want to have the data deleted from audit tables, else set to ARCHIVE if the data needs to be
moved into the archive tables and referred later.

2. For fields like SERVICE_STATUS_CRITERIA, there are a predefined set of values which are already
provided by Software AG. However there is a possibility that data in the audit tables might
contain data with some other status as well other than the values specified in this field. In such a
case, the data in those audit tables is not deleted. In order to have that data deleted, the status
value would need to be updated in the operation_parameter table beside the specific field. One
way to get all different status is to query the audit tables and find different statuses for which
data exists in the tables.
e.g.: select distinct status from ISCoreAuditSchema.wmerror;
3. Once the configuration parameters have been set, it is necessary to certain grant privileges. The
reason for doing so is because the archival process runs from the Archiving schema whereas the
audit tables are actually present in the ISCoreAudit and ProcessAudit schema’s. If the grant
privileges are not provided, the archival process will not be able to move/delete the data from
the audit tables.
In order to provide grants, you need to go to the ISCoreAudit and Process Audit schema’s and
provide select and delete grants on the tables to Archiving schema
e.g.: grant select,delete on ISCoreAudit.wmerror to Archiving;
The above step needs to be done for all the tables for which archiving/purging happens. You can
find the tables from the Stored procedures.
4. Now you need to run the Stored procedures in a specific order to make sure that the data is
purged. Below are the Stored procedures which need to be run
a. DOCUMENT_ARCHIVE.START_DOCUMENTARCHIVE
b. SERVER_ARCHIVE.START_SERVERARCHIVE
c. SERVICE_ARCHIVE.START_SERVICEARCHIVE
d. PROCESS_ARCHIVE.START_PROCESSARCHIVE
5. Each of these stored procedures take specific inputs. If the inputs are specified while running
these stored procedures, it will override the values specified in the operation_parameter table.
However, if you want the configuration values to be picked up from the operation_parameter
table, run the above stored procedures by passing the inputs as NULL.
6. These Stored procedures need to be executed one after the other. Once all the stored
procedures have been executed, the status is updated in the operation_control table. You can
also monitor the run of every instance by checking the operation_log table.

3. e.g.: select * from operation_log order by log_id desc
7. There are multiple ways to schedule these stored procedures to run. One way would be to have
the DBA team schedule these as jobs or schedule them via OEM so that the jobs run directly at
DB level only. Another way possible would also be also to have them run on Integration Server
using Adapters and connecting to Archiving schema.
8. It is also possible to have all of these run in parallel as well and to check if another instance of a
stored procedure is running already. This would require multiple entries to be created in the
operation_control table like DOCUMENT_ARCHIVE, SERVER_ARCHIVE, SERVICE_ARCHIVE, etc.
and have the individual stored procedures refer to their entries rather than referring the
common entry MONITOR_ARCHIVE as provided by default. You can also have the stored
procedures check the v$session (or gv$session for RAC DBs) to verify if another instance if
running already and make decisions accordingly.