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.
Handling Repositories In SRM-MDM During System Refresh, Archive Repository
As we know SRM-MDM provides catalog content management functions and a procurement catalog
SRM-MDM Archiving and Unarchiving
As we know SRM-MDM provides catalog content management functions and a procurement catalog enabling users to search, compare, and procure products and services from suppliers.
SRM-MDM Catalog includes a preconfigured data repository for your catalog data. This standard repository consists of the main table Catalog Items and a number of additional sub-tables, for example, for value lookups or classification.
If we need a system copy from Production to non-Production, rather doing complete system refresh (backup/restore), we followed archiving/un-archiving method for the selected Repositories. The brief steps are below.
Steps for Archiving;
1) Connect to the source system (Production), ensure that SRM-MDM console is connected, once connected it will show the existing/available Repositories select the Repository name to be archived.
2) Select the desired Repository to be archived, Right Click->Archive Repository
3) If you want to Verify before archiving you can say ‘Yes’ in the pop-up, otherwise click ‘No’, and provide a new name for the archiving file.
4) Select OK to continue, this would take few minutes depending upon the Repository size.
5) The Archived file will be available under \SRM MDM 5.5\Server\Archives directory.
Steps for Unarchiving;
1) Connect to the target system, connect SRM-MDM Console, and select the Repository which needs to be refreshed from Production.
2) Right click ->Delete Repository. Make sure to take a copy of the old Repository in the same way mentioned above (Archiving steps).
3) Move the Archived production file to target system.
4) Now select the server, Right Click ->Unarchive Repository, it will prompt you for user name and password to connect the DB server.
5) Then provide appropriate Repository name, select the production archived file from the location.
6) Upon completion, the newly created Repository will display in the console, you may load and proceed with further activities.
SLAVE Repository CREATION And SLAVE SYNCHRONIZATIOn
You would like to know what are the steps to create a Slave repository once you have a Master Repository
Once you have the M
You would like to know what are the steps to create a Slave repository once you have a Master Repository
Once you have the Master Repository, you would like to know how to create a SLAVE repository and also on how to keep it in SYNCH with the Master repository.
The steps are detailed below
Once you are connected to the master repositoy, right click on the master repository and go till the option of create slave.You will be asked if the repository has to be verified before the slave is created. Choose No and conitnue
Select the DBMS Server and give the user credentials for that DBMS server ( Normally it would be user "sa"' and its password credentials.
Here you can select a new repository name , ex. if you have the master as TST_MASTER, you can give the name as TST_SLAVE
Note: Please choose the approriate name as if you select from the pull down menu, you could overwrite an existing repository.
4. Now click on finish.When you click on finish, you can see in the MDM console that the Master would be duplicating meaning that it is creating the SLAVE
5. Once the SLAVE creation is completed, you can see the change of icon in the Master repository ( pink couloring on the icon ) and you will get the message that the respository was successfully duplicated.Once the SLAVE has been created, it will still not be displayed in the MDM console until it is mounted.
6. Righ click on the server and click on mount respositoy.Connect to the DB with the "sa" credentials and give the repository name ( example TST_SLAVE) and give the port number on which it has to be mounted.
Make sure you give a port which is not used already else you will not be able to mount the repository.
Double click the SLAVE repository and conenct to it with the required credentials.Right click on the repository and do a load repository ->Immediate. Wait until it is fully loaded, and you can the respository will come to status Loaded Running.
Now your SLAVE repository has been created and loaded.
Once you have the MASTER and SLAVE, you need to have a Synch script to keep the Master and Slave in synch once or twice a day.
When ever you need to do a snchronization of the SLAVE manually,you can right click on the Master repository and click on Synchronize SLAVE.
To automate this, get this to be done by a script and put it in a scheduler ( for Windows ) or in crontab ( Unix)
p.s - We got the script from SAP which we changed according to our environment and have put it in the scheduler to run twice a day.