15 Purging Data

This chapter describes how to use the Oracle B2B interface to purge design metadata and instance data.

This chapter includes the following sections:

See the following for alternate methods of purging:

Caution:

Archiving is required before purging data. Purging is an irreversible operation. Ensure that you first archive any important data.

15.1 Purging Design Metadata and Instance Data

Use the Oracle B2B interface to purge design metadata and instance data. Design metadata contains partner profile data, identifiers, document definitions, channels, and agreements.

When you purge this data, predefined data that is part of the installation (the host trading partner name, protocols, and identification types, for example) is not purged. Instance data is created during runtime when messages are processed. Instance, or runtime, data contains the business messages and message-related data.

Specific instance data can be purged from the Business Message tab of the Reports link. See Purging Messages, for more information.

Purging does not remove artifacts that B2B creates in the Credential Store, such as passwords. See Developing with the Credential Store Framework in Securing Applications with Oracle Platform Security Services for more information about the Credential Store.

With an instance message purge, you can optionally purge control number information. Control numbers are used in EDI (X12 and EDIFACT) and HL7 message standards. B2B keeps track of control numbers for inbound and outbound messages. For outbound messages, B2B generates the control numbers in a sequence from an internal control number table. Because purging instance data and control numbers resets the sequence (the control number table is reset), an outbound message after a purge may have the same control number as a message before the purge. If this is undesirable, do not purge control numbers.

Purging is useful for:

  • Managing disk space and improving performance

  • Removing repositories on a test system

To purge design metadata or instance data:

  1. Click the Administration tab, and then the Purge tab.
  2. (Optional if purging instance data.) Select Purge Control Number to reset the sequence.
  3. Click Purge Design Metadata or Purge Instance Data, as shown in Figure 15-1.

    Figure 15-1 Purging Design Metadata or Instance Data

    Description of Figure 15-1 follows
    Description of "Figure 15-1 Purging Design Metadata or Instance Data"

    If you select Purge Design Metadata, then the message Do you want to delete all the design metadata from the repository permanently? appears.

    If you select Purge Instance Data, then the message Do you want to delete all the runtime data from the repository permanently? appears.

  4. Click Yes.

15.2 Purging Data Based on Database Partitions

Oracle B2B allows you to purge data from the B2B tables, based on the conditions provided by using the PURGE_INSTANCE_MSGS_AUDIT procedure. Typically, Oracle B2B uses the B2B_BUSINESS_MESSAGE table for performing database partition based purge.

The conditions that control the partition-based purge are:

  • p_startDate - the start date for the records to be purged.

  • p_endDate - The end Date for the records to be purged.

  • p_msgState - The state of the Business Message.

  • p_tpName - The Trading Partner name (if specified, direction needs to be specified as well.)

  • p_direction - Indicates the direction of the method. Valid values:

    • INBOUND

    • OUTBOUND

  • p_msgType - Indicates the request type. Valid values:

    • REQ

    • RESP

  • p_tpaName - The Trading Partner Agreement (TPA) name.

  • p_idType - The sender ID_TYPE, or identifier type, which uniquely identifies a trading partner and defines how to exchange documents.

  • p_idVal - The sender ID_VALUE. The value associated with the identifier type.

  • p_shouldArchive - Indicates whether the messages to be purged are be archived. Valid values:

    • true

    • false

  • p_force_del - Indicates whether data will be forcefully deleted.

    <Reviewers:> Please check for technical accuracy.

  • p_archiveFileName - The file name of the archive.

  • p_tpaId - The TPA ID.

  • p_action - The EBMS action to be performed.

  • p_service - The EBMS service to be invoked.

  • p_docType - The document type.

  • p_commitFrequency - The commit frequency for batching up deletes; default value is 5000 rec/batch.

  • p_auditId - The Audit ID to track messages deleted against an auditId.

  • p_partitionMode - Indicates how partitions should be handled. Valid values:

    • DROP

    • TRUNCATE

    • STATEMENT

  • p_logMode - Indicates the Log level and whether the logging is console or file based. Valid values:

    • DEBUG

    • INFO

    • ERROR

    • CONSOLE_DEBUG

    • CONSOLE_INFO

    • CONSOLE_ERROR

  • p_rowLimit - Indicates the maximum number of Business Message records that can be deleted.

  • p_stop_time - Indicates the time by which the purge operation should be completed. The procedure continues to delete records in batch until the time is elapsed.

  • p_refreshMW - Indicates whether the b2b_system materialized view should be completely refreshed after the purge. By default, the purge refreshes the view only when a partition pruning is done. Valid values:

    • true

    • false

    • null

  • p_numOfRecordsPurged - Indicates the number of records that are purged in the run.

Oracle B2B provides a command-line utility called b2bpurge that allows partition-based purge of data. See Purging Data to know more about the utility.