At the onset of any project, I encourage the project management team to hold a project work management brainstorming session. In this session, I ask them to try to imagine (or remember) all the different ways the business could ask to report on solution documentation. This session may seem like an exercise in encouraging a blank-check mentality, but when it comes to enabling features in SAP Solution Manager, it has an important purpose.

The point of the exercise is to anticipate what kind of metadata or attributes you need to store on the project documents to be able to report and manage the solution documentation content to meet the business needs. Additionally, you can identify better ways to manage work by grouping deliverables. For example, many projects are deployed in waves or releases. You can assign these two common attributes to documents to help manage work and monitor progress. Other commonly used attributes are key milestone planning dates, team or functional groupings, business criticality or business value attributes, and information relating to how a particular document might relate to systems or processes outside of SAP systems.

The use of custom attributes is a feature in SAP Solution Manager that allows you to go beyond simple keywords. By defining your own custom attributes you are actually extending the reporting capability of SAP Solution Manager. Virtually all the SAP Solution Manager reports support the use of custom attributes in selection screens or as filters in output lists. Consequently, you can build execution and layout variants for team members and leaders to build custom work lists for the subset of documents each person needs.

The technique I describe was originally developed in SAP Solution Manager 4.0 on Support Package 12. As I move through the details, I point out the differences between SAP Solution Manager 7.0 Support Package 19 and SAP Solution Manager 7.1 Support Package 2, which are the two systems I used when updating this procedure. As always, it’s important that you understand the key components involved, and I talk about them in the next section.

Knowledge Warehouse

SAP Solution Manager is a complex software stack that includes the Knowledge Warehouse (KW). It is where the documents that you store in your blueprint, configuration, test workbench, service desk, and learning content are actually stored. Those lines you see in the General Documentation or Project Documentation tabs are merely pointers to the actual documents stored in the KW.

When you create a document in the KW, you actually do two things at once. First, you create a Binary Large Object (BLOB), which is the document itself stored in the KW. It contains the binary representation of your document, whether it’s a Microsoft Word document, PDF, spreadsheet, or any other type. The second thing that occurs is that a data record is created that contains the pointer to the BLOB along with a collection of metadata or attributes.

SAP Solution Manager stores many attributes related to the document by default, including Priority, Technical Name, Title, Person Responsible, Keywords, and Folder. This list of attributes is significant, but it rarely meets all the project’s management and reporting needs. You often need to add some additional attributes to meet the full management and reporting needs of your project.

The LOIO and PHIO

The LOgical Information Object (LOIO) is in the KW. You can think of it as a folder in a file cabinet. The LOIO is effectively the label or identifier of the file folder. The Physical Information Object (PHIO) is a unique identifier of each version of a document stored in the KW in SAP Solution Manager.

Each version of the document that you save to the KW through editing creates a new BLOB that is stored in the LOIO. Imagine that every time you saved a document, you printed it out and stored the new copy in the same folder (LOIO) in the file cabinet without throwing away the old ones. Each of the copies is uniquely identified in a file folder by its physical existence as a separate document. In SAP Solution Manager, each version is stored as a new BLOB and is assigned a unique, system-generated identifier called the PHIO.

For example, while I write this article, it is going to go through several edits. I’d like to keep each version for posterity, so I create a folder in Windows to house the different versions. This folder is similar to the LOIO in the KW. Each time I save a version of this article during the editing process, I give it a unique name to track the versions.

However, in SAP Solution Manager, you don’t need to manage the versions with naming conventions or other techniques. SAP Solution Manager does this behind the scenes by assigning each new version a PHIO. The PHIO is a unique identifier of the version of the document that was just saved. All versions (with their assigned PHIOs) are stored in the same LOIO.

It’s this robust, behind-the-scenes version management that gives SAP Solution Manager a lot of its power. You can retrieve any version of a saved document simply by going to the History tab in the document attributes. The Document Attributes pop-up window opens the LOIO, but the rows on the History tab represent individual PHIOs (or document versions) stored within the LOIO (Figure 1).

Figure 1

History of the document in the Maintain Attributes display

Note that some of the rows displayed are in light blue, and some are in white. This is because each attribute that is changed on a document gets a record in this list. The color changes with each version of the document or when a new LOIO is created. You can see that the blue rows show that the document text was changed (i.e., I did some editing), and the attribute for the document priority was changed. It shows the old value and the new value.

Note that Project Priority (in the Change Type column) is a custom attribute that was set up in the demonstration system used. This attribute illustrates the power of the versioning SAP Solution Manager performs. By having the custom attribute assigned to the PHIO class, the history of the custom attribute itself is preserved.

The white rows are from the prior version of the document. They are an example of a typical row list for when you create a document. Upon document creation, many of the attributes go from blank to having a value. You see a row for each of those attributes with the old value being blank and the new value being the value that was in the attribute at the time of save.

Project Requirement

In the example I use in this article, project leadership has requested the ability to group, manage, and report on documents by project milestones called waves and releases. For this particular project, releases occur within waves, so you should create two separate attributes to provide the flexibility the planning team needs to coordinate the releases within the waves.

Before going further, I’d like to point out that there are two flavors to this technique. One requires a developer key and skills with the SAP Data Dictionary to create custom tables and fields. The other does not require a developer key, but includes a little extra research to find data definitions that meet your needs. This is the method I describe in this article.

First you need to create your new attributes, which requires three steps:

1. Create the IO attribute
2. Assign it to the PHIO class
3. Clear the KW buffers

Step 1. Create the IO Attribute

In the IMG, navigate to the document attributes maintenance. This path differs depending on your system. For SAP Solution Manager 7.0, it is SAP Solution Manager > Advanced Configuration > Scenario-Specific Settings > Implementation > Document Management > Document Attributes (Figure 2) and for SAP Solution Manager 7.1, it is SAP Solution Manager > Technical Settings > Document Management > Document Attributes (Figure 3). In either version, you can use transaction DMWB.

Figure 2

Document attributes in SAP Solution Manager 7.0

Figure 3

Document attributes in SAP Solution Manager 7.1

If you look closely, you see that in SAP Solution Manager 7.1 there are several new features to explore in this area, but since 7.1 is not in wide use, I’ll discuss these features at a later date.

By clicking the Create Document Attributes node you bring up the screen in Figure 4. Click the IWBSOLAR section and then open the IO Attributes folder (Figure 5).

Figure 4

Document Modeling Workbench entry screen

Figure 5

Opening the IO Attributes window in the DMWB

Right-click any of the existing attributes and click Create from the context menu (Figure 6).

Figure 6

Create a new IO attribute

The next screen prompts you to name and describe the new attribute (Figure 7).

Figure 7

Create an IO attribute for the wave assignment to documents

Press Enter and you may be prompted to enter a transport request (Figure 8). The prompt for transport is driven by the client settings in your SAP Solution Manager system. For more information, consult the SAP Help document on transaction SCC4. If your SAP Solution Manager client has been set to automatic recording of changes, then you are prompted for a transport. For the purposes of this example, I just made the attribute a local object, but you need to adhere to your project standards regarding transports.

Figure 8

Transport request for the new IO attribute

Click the save icon and the attribute is added to the list of IO attributes. Double-click the new attribute and click the display/change  icon to open it for assignment to a Data Dictionary element (Figure 9).

Figure 9

New IO attribute open for editing

Populate the TABLE_NAME and FIELD_NAME fields. Now the two variations come into play here. If you’ve chosen to create your own custom Data Dictionary structure and fields to control the behavior of the attribute, assign them here. If not, you can use an existing Data Dictionary table and field.

The purpose of the table and field assignment is to describe to the KW the data characteristics of the attribute. It is not where the data is going to be actually stored, so almost any Data Dictionary table and field is fair game.

I like to use fields from the structure SADOCPROPS (in versions 7.0 and 7.1), which is the standard document attributes. I also like SAEVAL_STR (in version 7.0), which is used in many of the standard reports in SAP Solution Manager.

For the wave attribute you could use SADOCPROPS for the table and BUPA_NAME for the field. The BUPA_NAME is a 40-character text field. This size would give you good flexibility for a naming convention. You could also use BUPA, which is 10 characters, if you were looking for something shorter. Once you’ve entered the table and field names, click the activate icon  to activate the IO attribute.

Step 2. Assign the Attribute to a PHIO Class

Next, navigate to the PHIO classes folder in the IWBSOLAR section (Figure 10).

Figure 10

PHIO class assignment of the new IO attribute

Double-click SOLARGNSRC_V. Be sure to double-click it and not open the group and double-click SOLARGNSRC — you’d be lost. On the Entity Properties screen, select the Instance Attributes tab. Make sure you’re in change mode, because you won’t be able to make the necessary entries if you’re not. Click the insert row  icon to assign your new attribute to the PHIO class (Figure 11).

Figure 11

Add the new attribute to the PHIO class

Click the activate icon to activate the PHIO class.

Step 3. Clear the Buffers

Clearing the buffers causes the application server to import the PHIO class definition with your new attribute assignment. If you skip this step, you are going to become frustrated wondering why the new attribute does not appear in the document attributes screen. Use transaction SE33. Enter IWB_CLASS_PROPS into the Context. Follow menu path Edit > Delete Buffer > On all servers.

Congratulations! You’ve just created a new custom attribute.

Repeat the preceding steps for other attributes. If you already know that you need to create multiple attributes, you can create all of them at once in the IO attributes and then assign them all at once to the PHIO class. Then you need to delete the buffer in transaction SE33 only once for all the attributes. Make sure you save and activate as you go.

Now, let’s see how it works. Go to transaction SOLAR01 and select a project (Figure 12).

Figure 12

Project open in transaction SOLAR01. A test document has already been added.

The steps to add a document are outside the scope of this article. In Figure 12, I’ve already selected a test document created previously. Click the attributes  icon. The Maintain Attributes pop-up screen appears (Figure 13). You might notice that there’s a new tab called Other Attributes. Your new attribute is available for maintenance in this tab.

Figure 13

The Maintain Attributes screen with the Other Attributes tab highlighted

Select the Other Attributes tab and you see the new attribute that you just created (Figure 14).

Figure 14

Other Attributes entry screen with the wave field populated

Now let’s look at some of the other features that are available in custom attributes.

Other Features

In this example, you assigned the new attribute to the PHIO class. This step allows you to maintain the attribute on the individual versions of the document so that you can see if the wave assignment changed over time. You use this approach so that you have that history available if needed. However, you can assign the custom attribute to the LOIO class, which does not store the attribute on each version of the document, but rather the LOIO or folder in which the document is housed. This step saves some space in the KW, but sacrifices the history for the attribute. There are many ways you can deploy these attributes. Some of them are shown in Table 1.

Table 1

Options for deploying attributes

Experiment, Experiment, Experiment

I hope you can see that the ability to add custom attributes to your documents opens up new features in SAP Solution Manager. As always, when working with these advanced features, I encourage you to experiment in a development or sandbox SAP Solution Manager system first.

For example, set up several custom attributes and experiment with how the different reports in transaction SOLAR_EVAL change. Experiment with changing some of the options on the attributes after you have used them on documents. How do the changes in the attributes change the behavior of the entry screens in transaction SOLAR01 or SOLAR02? What happens in the reporting when documents are maintained with an attribute before and after the attribute options are changed?

You might need to change the options on custom attributes, especially on large or long-term projects. This is yet another reason why you need to experiment. You don’t want to learn about undesirable affects of changing the behavior (options) of custom attributes when you have thousands of documents to handle.

For the options of required and multiple entry, I strongly encourage you to experiment a lot. These two attribute options have some quirks that can cause some serious headaches if you implement them incorrectly and need to change them later. I’ve had experiences in which we had to develop cleanup programs to scrub data out of the KW because we changed the behavior of multiple entry attributes.

As with any configuration in any SAP system, take the time to thoroughly document how you set up these attributes. Include why you set up the different attributes and the options for the attributes, not just what you set up. Keep in mind that you might have to revisit that configuration six months from now, and you might wonder why you did certain things.

I haven’t covered every way to use attributes, but I’ve provided you with enough information to take your document management to the next level.

D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.

You may contact the author at solmanruss@gmail.com.

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