With this post, we are starting a blog post series focused on SAP Data Management.
At Inquaero we could analyze dozens of SAP Systems and we realized that there is always a limited set of tables that represent a recurrent challenge for an effective Data Management program.
This situation normally occurs when planning a S/4HANA migration or in any other SAP system landscape optimization scenario implementation.
So, we’ve decided to take the top tables of this set, and to write a series of posts that describe how to identify the root cause of their growing size and the possible options available to reduce the size or to limit the database growth.
Whit this blog, we start with tables SOFFCONT1 and SOC3, as their growing sizes are usually recognized as trending pattern in an SAP system where Business Workplace (former SAPoffice), SAP Workflow or Generic Object Services (GOS) are used.
SOFFCONT1 and SOC3 contain SAPoffice documents that are generated in following ways:
- By creating or sending documents with SAP Business Workplace
- By creating attachments with GOS
- By sending ABAP lists or Spool lists
- By sending emails or fax documents from an application
- By sending documents using the Post Processing Framework and the message control
- By sending documents from Smart Forms or SAPscript
- We will see later in which case a document is stored in SOC3 table and in which is stored in SOFFCONT1.
Before continuing, let’s spend some words about SAP GOS (Generic Object Service) and SAP PPF (Post Processing Framework).
GOS is a cross application service available e.g. for purchase documents (as Purchase Orders or Requisitions) or Sales documents that gives to the user the option to link the SAP documents to different kinds of attachments as:
- Binary documents like PDF or Excel files
- Notes
- Links to external document (URL Links)
Its functionalities can be accessed using the small button you can see on the top left of the SAP Gui (its visibility is subjected to some user master parameters like SD_SWU_ACTIVE):
Or via menu option System –>Services for Object
SAP PPF, instead, is a framework that allows the definition of actions that should be automatically processed when a business objects reaches a specific condition.
E.g. let’s assume that you want to have a remainder for the sales employee responsible when a Sales Contract is going to expire, with the SAP PPF you can implement the action (like an automatic email or a Workflow) that should be triggered when the condition becomes true.
SAP PPF is the successor of the message control that it is limited to generate and manage output from an application and control their timing and medium of exchange.
The main transaction for SAP PPF is SPPFCADM, while for message control configuration transactions is NACE.
We have seen which technical and business processes are generating data that is stored into SOC3 and SOFFCONT1 table. Now we must understand when table SOC3 is populated and when it is SOFFCONT1.
Both SOC3 and SOFFCONT1 are transparent tables where most of the size is consumed by a column of type LRAW. This data type is used for generic chain of bytes, which are stored into the database using a compression algorithm.
So basically, we are talking of tables used to store unstructured data (data that cannot be reduced to a predefined relational schema).
But when SAP uses table SOC3 and when it uses table SOFFCONT1?
This is described in OSS Note 904711:
- The document is not stored using the Knowledge Provider (KPRO).
The document is a text document and is not stored using the KPRO. The contents of the document are displayed directly in Table SOC3. The indicator that shows whether a document has been stored using KPRO is found in table SOOD-EXTCT.
- The document is stored using the knowledge provider.
Binary documents are stored using the KPRO. The contents of the document are managed by the KPRO. For this purpose, it recognizes a Logical Object ID (LOIO) and a Physical Object ID (PHIO). The SAPoffice component accesses this using the LOIO, which is stored in table SOC3.
This note introduces the concept of KPro (Knowledge Provider) interface. KPro was adopted with SAP R/3 4.5B as extended interface model for the SAP ArchiveLink.
SAP ArchiveLink is the communication interface between SAP and an external storage system (Content Server), it makes available to the SAP system an external Content Server that is better suitable for storing unstructured data than a relational database.
SAP ArchiveLink and KPro differ mainly on the application interface and management layers. The content server interface is the same in both components.
So basically, when a document is a binary document and it is managed using the KPro interface, it gets stored into table SOFFCONT1, if an external Content Repository is not defined for content category SOFFDB.
This can be checked in transaction OACT, this transaction assigns the content repository to the content category:
The content repository is customized in transaction OAC0, where we can set the database tables used for storing the documents when an external content serve is not used:
So, in case of binary documents managed using KPro, table SOFFCONT1 is used for storing the document content. For normal text document, SOC3 table is used. But, also for KPro binary document SOC3 table plays an important role, as it stores the Logical Object Id (LOIO) of the document.
Indeed, in table SOC3 the key is the compressed key of table SOOD (the header table of an SAPoffice document), instead the key of SOFFCONT1 is a unique Id, that we can retrieve using the SOC3 table.
Here an example, in table SOOD we can find the header information of a document:
In table SOC3 the document key is compressed:
We can use function module SO_OBJECT_GET_CONTENT for retrieving the LOIO of the document:
Then, we can read table SOFFPHIO with the LOIO_ID and getting the Physical Object ID (PHIO_ID) of the document:
And with the PHIO we can read SOFFCONT1 table:
In case of SAPOffice documents generated by GOS (Generic Object Services), it can be useful also to analyze table SRGBTBREL that contains the link between the SAPOffice document and the business object to which the document is attached (in fields INSTID_A and TYPEID_A):
We have seen which main functions populate tables SOFFCONT1 and SOC3 and with which logic.
Now the question is: How can we reduce the size of those table or limit their growth?
The main strategy to use is, of course, to use an external Content Server.
The steps for using an external Content Server are described in OSS Note 530792. In few words, you have to assign a new document category to SOFFPHIO document class using transaction SKPR08. This new document category must be assigned to a Content Repository that links an external Content Server.
For older documents, created before the adoption of the external Content Server, it is possible to execute report RSIRPIRL as described in note 389366 for relocating them into the new external Content Server.
It is also possible to reduce the size of tables SOC3 and SOFFCONT1 using report RSBCS_REORG.
Indeed, if a user deletes documents or attachment from a folder, only the reference between the folder and the document is deleted, but not the document itself that remains on the database.
SAP recommends that you schedule this program regularly as a background job. Please refer to note 966854 for additional info.