Dimensiones del modelo educativo Filosófica

5.6.1 BBP_TRANSXSTRING: Temporary Working Storage for Attachments

In SAP Supplier Relationship Management (SAP SRM), files (PDF, XLS, and so on) can be uploaded from a file directory and attached to an SAP SRM document such as a shopping cart or purchase order. These attachments can later be edited and versioned.

During the upload process, the content of the files is temporarily stored in table BBP_TRANSXSTRING before being stored in the final location, for example, a content server. After the data has been successfully stored on an external content server or internal table BBPCONT, it is deleted automatically from temporary table BBP_TRANSXSTRING.

5.6.1.1 Avoidance Cannot be used

5.6.1.2 Summarization Cannot be used

5.6.1.3 Deletion

A programming error by SAP causes the temporary storage that is used during upload of documents from the users’ PCs to not be cleaned up properly. To correct this we recommend the following procedure:

1. Delete obsolete data with report RSBBPFREETRANSX, which deletes all records older than 2 hours, to avoid performance problems after the automatic deletion is working correctly.

2. Implement SAP Note 1489962: Table BBP_TRANSXSTRING is not cleared.

3. Re-run RSBBPFREETRANSX to clean up the amount of data that was posted between the first cleanup and the note implementation.

5.6.1.4 Archiving Cannot be used

5.6.2 BBPCONT: SAP SRM Attachments

Table BBPCONT is used as a default storage location to hold the binary content of attached and uploaded files such as PDF files, Microsoft Excel files, and so on.

The binary content of the attachments to SAP SRM documents is stored using the Knowledge Provider (KPro). The default setup of the content repository for an SAP SRM document (document area BBP) causes the document content to be stored in the database table BBPCONT.

This default setup allows attachments to be used immediately without having to maintain any additional customizing and—most importantly—without having to have any external content server implemented..

However, a negative side effect of this approach is that the table may grow significantly.

5.6.2.1 Avoidance

Users should only attach those documents that are really necessary for the business process.

5.6.2.2 Summarization

In some cases, it may be useful to upload ZIP files instead of the original files if the upload is done manually.

In the case of PDF attachments that are generated by the system automatically, compression is not an option.

5.6.2.3 Deletion

Individual attachments can be logically deleted and then physically removed with report

RS_REMOVE_DEL_ATT_CONTENT. You can determine how many documents are flagged for deletion by running a TAANA analysis on table BBP_PDATT, field DEL_IND.

5.6.2.4 Archiving

There is no option for data archiving. That is, the archiving object for SAP SRM documents like shopping carts and confirmations will only archive the linkage information to the attachment but will leave the content of table BBPCONT untouched.

Future growth of this table can be avoided by changing the storage location of SAP SRM attachments from the database to an external content server.

There are no SAP standard tools for the migration of already existing documents from the database to an external content server. If this migration is required, please contact SAP partner company xft (www.xft.de) to support you with the migration activities.

5.6.3 BBPD_PD_INDEX_I, BBPD_PD_INDEX_H: SAP SRM Index Tables

To allow faster access when working on large lists of documents, the core information of SAP SRM documents is stored redundantly to the original tables in indexing tables BBPD_PD_INDEX_H (header information) and BBPD_PD_INDEX_I (line item information).

Since the data model in SAP SRM is quite complex and the data is distributed across several tables, it is much faster to read one or two tables instead of reading all involved tables that are required to represent the full document.

See SAP Note:

· 721358 (BBPCRM 400): Perfomance improvements for list displays 5.6.3.1 Avoidance

Cannot be used

5.6.3.2 Summarization Cannot be used

5.6.3.3 Deletion

This index can be rebuilt to remove obsolete records with report BBP_GETLIST_INDEX_FILL. Please test the runtime of this report, as it may run for several hours if not days.

5.6.3.4 Archiving

The index records are deleted by the delete jobs of the archiving objects for SAP SRM business documents, like BBP_SC or BBP_PO.

Please note: As the index records do not contain information of their own but only redundant information of the business document itself, the archive write job does not include this data in the archive files.

5.6.4 CRMD_PARTNER, BBP_PDIGP: SAP SRM business documents

These tables represent parts of the SAP SRM documents like shopping carts and purchase orders.

CRMD_PARTNER holds the links to the partners related to business activity. BBP_PDIGP holds the purchasing information on line item level. An SAP SRM business document consists of records in many different tables, but these are those that usually show considerable growth.

5.6.4.1 Avoidance Cannot be used

5.6.4.2 Summarization Cannot be used

5.6.4.3 Deletion Cannot be used 5.6.4.4 Archiving

To archive entries from these tables, the corresponding archiving objects for SAP SRM business documents like BBP_SC (Shopping Carts) or BBP_PO (Purchase Orders) have to be implemented.

Archiving is split into two steps. In the first step, a preprocessing job checks if the business documents are finally processed and fulfill the archiving criteria. If yes, the status value can be archived is set. In the second step, the data archiving process takes place (write and delete job) for all documents with status can be archived.

For a detailed description of the prerequisites, see the SAP Library for SAP Supplier Relationship Management® Functions ® Archiving.

Table analysis

To determine which of the available archiving objects will have the biggest effect, you can run an analysis with transaction TAANA on the header table for SAP SRM documents: table CRMD_ORDERADM_H.

Analysis variant STANDARD will reveal the most relevant archiving objects and the age of the data.