The application tool is a tool that collects messages, exceptions, warnings and errors, logs from different applications are written to the databas
The application tool is a tool that collects messages, exceptions, warnings and errors, logs from different applications are written to the database and contain information on messages/events for further analysis. These logs get accumulated over the period of time but are not automatically deleted. Application events can be logged centrally in the application log.
The log for an object comprises: - The log header (table BALHDR) with a unique log number: This provides information about who triggered a particular event, using which program or transaction. - Multiple numbers of log messages and their urgency status (tables BALDAT).
Application Logs - Expiration Date
Every log written to the database will usually be assigned with an expiration date, which is the date to which the logs must be retained in the database. The same is set by the application logic which updates the BAL* tables, please note that expiration date cannot be set by the end user or administrators, it is a application managed setting. Moreover, expiration date does not mean that the logs will be deleted automatically from the systems. The DEL_BEFORE indicator in the BALHDR table determins whether the log can be deleted before it reaches the expiration date.
Tables involved in the application logs are BALDAT, BALHDR, BAL_INDX and BALM.
Avoidance of updating Application logs
There is no general procedure for activating or deactivating the application log. Some applications provide this option or let you reduce the number of entries created, please refer OSS Notes, 183960, 373688, 393667, 376555 and 460310.
Application Logs: Deletion
From Release 4.6A, transaction SLG2 can be used to delete records according to the selection criteria specified, in addition to that, you can also use SBAL_DELETE program to schedule it as a background job at pre-defined intervals.
Upto Release 4.5B, RSSLG200 report deletes all the logs with expired dates, another report RSSLGK90 deletes all messages with an expiry date too far in the future or no expiry date.
Pre-requisites for deletion: As mentioned in the previous sections, application log entries can be deleted after the esxpiry date is reached. However, if the DEL_BEFORE is set to blank (not ‘x’), then these logs can be deleted even before reaching the expiry date.
Only Important for CRM Systems:
In CRM systems, application logs with subobject type "SINGLE" must not be deleted with deletion report SBAL_DELETE (see SAP Note 595856). Table entries with subtype "SINGLE" are deleted while archiving CRM documents with the related archiving objects. For more information, see the "Archiving" section.
Selection fields for the SBAL_DELETE delete program (transaction SLG2):
- Object - Sub-Object - External ID - Transaction Code - User - Log Number - Problem Class - From Date (BALHDR-ALDATE) - To Date (BALHDR-ALDATE) - Transaction Code
Expiry Date You can delete logs that have reached their expiry date or you can delete logs before the expiry date.
Options - Only calculate the amount => this is a simulation - Generate list => The report identifies the logs that can be deleted and displays a list from which you have to select the logs to delete. - Delete immediately => The report identifies the logs that can be deleted and deletes them without any further input from the user.
Application Logs: Archiving
Application logs can be archived using archiving object BC_SBAL, reloading back to the database is not possible with this archive object.
Prerequisites for Archiving
A log can be archived only if it has expired (expiration date has been reached or has passed) or it can be deleted before the expiration date (DEL_BEFORE flag).
Dependencies to Other Objects
There are no dependencies to other archiving objects.
SAP recommends to archive application logs after 6 months since they probably do not have to be accessed frequently any more
SOC3 : Table SOC3 stores information like application mails, URLs, work item notes,
Content of Tables:
SOC3 : Table SOC3 stores information like application mails, URLs, work item notes, PC documents and contents of documents which are created and sent in SAP Business Workplace (formerly SAPoffice) and documents created using Generic Object Services (GOS). Therefore, the size of SOC3 depends heavily on how frequently such types of documents are sent within a system. The corresponding meta data is stored in table SOOD, folder management data in table SOFM, information of the send process in tables SOOS (send procedure) and send history in SOST.
SOFFCONT1 : As of Release 4.6B, KPro (which is in built) plays a major role in storing the contents of the PC attachments, KPro allows you to make use of a certified external storage system, so that the growth of the production database can be controlled as the attachments will be stored in external storage system. If external storage system is not connected, then by default the attachments are stored in SOFFCONT1 (as of release 4.6B).
How to avoid the updates on SAPOffice/SBWP related tables?
Avoiding Updates to SOFFCONT1:
As mentioned above, make use of an external storage system, that way the PC attachments are not written to SOFFCONT1, instead they are stored in the external storage system, but this approach comes with an additional cost for the external storage system.
From Basis Release > 6.10:
Avoiding Updates to SBCMCONT1
Converted MIME documents that are created during shipping with the SMTP are stored in SBCMCONT1 table. As of Basis Release 6.20 SP 34, this persistent MIME storage is deactivated by default, and as of SP39, it can be activated or deactivated at your convenience, for more information, refer SAP Notes: 845449, 687810 and 706328.
How to delete the contents of SAPOffice/SBWP related tables?
There is no standard program or transaction available for deleting the SAPOffice/SBWP related tables, the deletion is only possible by the end user which means the end users must be given training to perform periodical deletion of their mailbox content. If a user delete mails from a folder with or without an attachment, only the references between the folder and the documents are deleted at first. The content of the document will remain in the database. The orphaned data can be deleted from the database with the help of reports RSBCS_REORG* (Tables SOC3, SOOS, SOOD, SOFM and SOFFCONT1).
How to archive the contents of SAPOffice/Business Workplace Documents?
It is possible to move the document contents from table SOC3 to an optical archive using program RSSOAPUT. However, archiving for table SOFFCONT1 is not possible and can only deleted and reorganized as mentioned above.
Quick Tips :
You can use program RSSOINBO (SOY5) to return a list of users who have many documents or unread documents in their inbox. Similarly RSSOQUTA program gives information on the number and size of documents that user may have in their private folder area.