SAP Solution Manager is widely used for keeping documentation of business processes, configurations, developments, training materials, and test cases in projects and solutions. As many users are not used to completely deleting documents from SAP Solution Manager, but only deleting their links to project and solution business processes structure, all those obsolete and unused documents remain in SAP Solution Manager unnecessarily, consuming storage and affecting performance.

One solution for this situation, explained in detail in my quick tip “An Easy Way to Delete Unused SAP Solution Manager Documents,” is to periodically run a standard SAP program called SOLMAN_UNUSED_DOCUMENTS, which reads all unused documents from the SAP Solution Manager Knowledge Warehouse and deletes the selected ones.

The standard SAP program SOLMAN_UNUSED_DOCUMENTS has a very simple selection screen in which the user can only select the creator of the document as a filter and the maximum number of entries to be considered when searching for the documents. My experience using this program with companies showed me that this option is sometimes not enough, as users often want more filters so that they can display unused documents by the date of last changes or author of last changes, and then decide whether to delete them or not.

Sometimes a document was created by one person who has since left the company, or who is not responsible for the document changes. Therefore, another user has changed the document, so it may be important to look for documents based on the last changes. It may also be relevant to search for unused documents by document type, especially if obsolete document types were excluded from SAP Solution Manager projects and the user wants to clean the unused documents of those types.

In this article, I show you how to copy the standard SAP program SOLMAN_UNUSED_DOCUMENTS and include three new filters in the selection screen to allow users to search for unused documents using different fields as filters. This step makes the deletion process easier and more flexible for the users. I show you how to include the Last Changed By, Last Changed At, and Document Type fields. Once you have an understanding of these steps, you can make your own changes.

Copy the Program

Go to ABAP Editor in transaction SE38 and copy program SOLMAN_UNUSED_DOCUMENTS to a Z program following your naming conventions. In this example I just included a Z as the first letter of the program name (Figure 1). If you use customer namespaces, do not forget to include /<namespace>/ when naming the program.

Figure 1

Copy the standard SAP program to a customer program

Select a customer package for your copied program and save it in a transport request (Figure 2). If you have only one SAP Solution Manager system (production) and do not have any transport route configured, you can save it as a local object or in a local transport request. The choice depends on the SAP Solution Manager landscape and the development procedures defined. Naming conventions and rules for creating and using packages and transports are beyond the scope of this article.

Figure 2

Save the program in a custom package

Adjust the Source Code

After copying and saving your new ABAP program, open the source code in edit mode. You see the standard source code. In the declaration part, in which you see statement TABLES, include a new table TNOTEEPR (Figure 3). This table keeps the documents types used in SAP Solution Manager and is needed when you create a new select-option for document type.

Figure 3

Include a new table in the TABLES declaration

Now search in the document for the following context (Figure 4).

Figure 4

First context: declaration of selection fields

In this section of code the declaration of parameters and select-options begin. As you can see in the standard code, the only two fields available for the user are Creator and Number of Entries. I include a selection screen block with three new fields for selection declared as select-options:

• Changeby: to select the last person who changed the document; this field corresponds to Last Changed By. This field is type TRESEPR-PROJ_RES, the same type as the existing selection field Creator (corresponding to Created By).
• Lastchan: to select the date of the last change; this field corresponds to Last Changed At. This field can be type SY-DATUM.
• Docutype: to select the document type. This field is type TNOTEEPR-NOTETYPE, which was the table you declared in the TABLES statement.

Figure 5 shows an example of the declaration of the new selection field in my source code.

Figure 5

The declaration of the new selection field. A downloadable version of this code is at the bottom of this article.

None of these fields is mandatory, so the user can still search for documents using only the author as he or she used to do before when running the standard program. If you prefer you can declare one of more fields as parameters, set them as obligatory, and make the changes in a way that suits your needs. You can see my declaration in red in Figure 6. Avoid declaring all the parameters and select-options as optional because in doing so, you might end up with a large number of entries and cause a time out.

Figure 6

Declaration of selection-screen block with three new fields

You have to check standard table SDOKPROP to find the names of the document attributes that you can use as filters in your selection screen. In the example of this article I use the attributes shown in Table 1.

Table 1

Example attributes

The existing Created by field corresponds to field IWB_PHIO_FIRST_CREATED_BY in table SDOKPROP. Now you have to read the information entered in the selection-screen fields that you have created and transfer them to the program logic so that this information is considered during the document search.

In the source code look for the context shown in Figure 7.

Figure 7

Context in which the new lines must be included

In this part of the code the select query is prepared. In other words, it’s where the user selection is read and inserted in internal table LT_QUERY, which is used to filter the unused documents that need to be retrieved.

Below the context, include the lines related to your select-options and move the information to the internal table LT_QUERY, as shown in my example in Figure 8.

Figure 8

Filling internal table LT_QUERY. A downloadable version of this code is at the bottom of this article.

Figure 9 shows a part of this source code in the ABAP editor inserted just below the context.

Figure 9

Source code with the new lines related to new selection fields

Your new selection-screen fields need a search help to allow the users to search for some existing values. In my example, the new selection fields don’t have a predefined search help, so I created one form to search for existing values of Document Type and copied an existing form used for the standard selection field Created By to search for existing user IDs for the Last Changed By field.

In the source code, look for the context shown in Figure 10.

Figure 10

Part of the code where the value-request forms should be included

Just below this code, include the lines shown in Figure 11.

Figure 11

Source code for value-request routines. A downloadable version of this code is at the bottom of this article.

You can see my example in Figure 12.

Figure 12

The source code of search help definitions in the ABAP editor

Now you have defined a search help for your new selection fields. The Last Changed At field does not need a value-request routine because data type SY-DATUM provides its own search help.

After finishing the changes, check the syntax and activate your program. Figure 13 shows the new selection screen with a new block and three new fields.

Figure 13

The new selection screen for program ZSOLMAN_UNUSED_DOCUMENTS

When I run the copied program ZSOLMAN_UNUSED_DOCUMENTS with the selection screen as in Figure 13, I receive a list with only the unused documents of type BB (Business Blueprint) created by USER12 and last changed by USER12 between February 1, 2012, and February 20, 2012.

Raquel Cunha

Raquel Cunha is an independent consultant who has worked with SAP solutions in Latin America and Europe since 1998. She started as an ABAP developer and has also worked as an ABAP team leader and HR application consultant. Raquel has a bachelor’s degree in computer science and is certified on ABAP and ITIL V2 and V3. She changed her focus to SAP Solution Manager, with particular emphasis on Service Desk and ChaRM, and has been implementing Solution Manager in four different countries since 2005. Raquel is currently an SAP Mentor.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.