Status and Tracking System (STS) implementations can suffer from increased and unnecessary maintenance effort, which grows proportionally to the number of users involved. As the number of users in your system grows, you must update the relevant URLs, dates, and email addresses for all hierarchy nodes (e.g., cost centers or customers) frequently. Not only is this time consuming, but typically this also requires an IT support person to create these changes.

I provide step-by-step instructions on how to apply logic to assign user IDs, URLs, and email addresses regardless of the InfoObject used in an STS hierarchy. The technique eliminates the need to revisit each hierarchy node and maintain the user IDs, email addresses, and Web addresses assigned to it.

Instead, you can perform all STS maintenance and updates with a single program run, rather than revising each hierarchy node — after you implement this method, you can update all changes to the STS hierarchy nodes with one click of a button. Users then maintain this information in a flat file that the system loads into a DataStore object (DSO) and updates in STS automatically.

I used SAP NetWeaver BI 7.0 for this article. Even though the method includes creating a Business Add-In (BAdI) implementation, no specific experience in BAdIs or ABAP objects is required.

Business Scenario

Let’s say that the characteristic on which you base your STS hierarchy is cost center (0COSTCENTER). For simplicity, I assume that the business logic that returns a user ID based on a cost center is encapsulated in function module Z_USERID_DERIVE. The function module imports a cost center and exports a user ID. This function module, in turn, can read the data from a master data table or a DSO. Of course it could be more complicated than that. For example, the function module could read the 0COSTCENTER attribute 0RESP_PERS first and then find an assignment of responsible persons to user IDs from a custom master data table.

I also assume that email addresses are maintained against each user ID. If that is not the case, you can download an ABAP program in step 4 to help create this data.

The Process

Step 1. Create a BAdI implementation. In transaction SE19, enter UPS_NAME_RESOLVE for the Classic BAdI and click on the Create Impl. button (Figure 1). SAP provides this BAdI to resolve the user IDs for hierarchy nodes. In the pop-up screen that follows, assign a technical name for your implementation, such as ZCUSTOM_NAME_RESOLVE. Click on the enter icon to accept.

Figure 1

Create a new BAdI based on UPS_NAME_RESOLVE

Step 2. Create a filter. After you name your implementation, the Change Implementation screen appears (Figure 2). Enter the Implementation Short Text and create a filter by clicking on the add icon.

Figure 2

Enter the short text and create a filter

In the Defined filters section, assign a four-digit number for your implementation in the NameResolv column. SAP uses 0001 and 0002, so I chose 5000, which is far from SAP's numbers. Enter a short text for your filter and activate the implementation by clicking on the activate icon.

Step 3. Define the RESOLVE method. Initially, all methods in new implementations are empty and require some coding to make them work. In the screen shown in Figure 2, click on the Interface tab, then double-click on the method name RESOLVE. This brings you to the ABAP editor screen. In the code block, insert the ABAP code shown in Figure 3.

METHOD if_ex_ups_name_resolve~resolve.
*-------------------------------------------------------------------------
* Instead of /bi0/oicostcenter you can use any type relevant
* to the characteristic upon which your hierarchy is based.
*-------------------------------------------------------------------------
  DATA: l_hier_char TYPE /bi0/oicostcenter.
  DATA: is_hierarchy TYPE upc_ys_hie_str,
        is_resolve   TYPE ups_ys_resolve.
* Check which filter is currently used
  IF flt_val = ‘5000’.
    LOOP AT it_hierarchy INTO is_hierarchy.
      is_resolve-nodeid = is_hierarchy-nodeid.
      l_hier_char = is_hierarchy-nodename.
*-------------------------------------------------------------------------
* Z_USERID_DERIVE contains your business logic to derive a user ID from
* a hierarchy node
*-------------------------------------------------------------------------
      CALL FUNCTION ‘Z_USERID_DERIVE’
        EXPORTING
          i_char = l_hier_char
        IMPORTING
          e_user = is_resolve-name.
      INSERT is_resolve INTO TABLE et_resolve.
    ENDLOOP.
  ENDIF.
ENDMETHOD.

This code is an example of how you can implement the assignments of user IDs to hierarchy nodes in your STS solution. After defining the necessary variables, check if the filter that is currently used is the one you just defined. Then you loop through all the nodes in the STS hierarchy and find the user ID assigned to it. The resulting line containing the user ID association to a hierarchy node is put into internal table ET_RESOLVE, which is an output parameter of the method.

Save and activate your ABAP code and implementation by clicking on the activate icon. Next, go to transaction SE37 to create the function module Z_USERID_DERIVE referenced in Figure 3. Use code such as the one shown in Figure 4 to define the function module.

FUNCTION Z_USERID_DERIVE.
*”----------------------------------------------------------------------
*”*”Local Interface:
*”  IMPORTING
*”     REFERENCE(I_CHAR) TYPE  /BI0/OICOSTCENTER
*”  EXPORTING
*”     REFERENCE(E_USER) TYPE  UNAME
*”----------------------------------------------------------------------

The code contains the logic to determine a user ID from a characteristic value. If this logic is simple enough, for example a single read from a master data table or DSO table, you do not need to use the function module and can put it into the RESOLVE method directly.

When you are finished, make sure that both the RESOLVE method and the whole implementation are active before moving to the next step.

Step 4. Determine the hierarchy for the subplan in STS Customizing. In the STS Customizing screen (transaction BPS_TC), choose Determine Hierarchy for Subplan and click on the execute icon. This takes you to the screen shown in Figure 5.

Figure 5

Select the Name Resolve method when importing the STS hierarchy

Enter the data relevant for your STS subplan implementation. Click on the Name Resolve field and press F4 to display the pop-up screen shown in Figure 6. Choose the Custom method and click on the execute icon (or press the F8 key). This creates assignments that you can then edit in STS Customizing, such as determine date, person responsible, and layouts.

Figure 6

New method 5000 is available

Email Addresses

After you complete the previous steps, the system automatically assigns the following information to the hierarchy nodes:

• User ID
  
  
• User first and last name (if available for the user ID in transaction SU01)
  
  
• User email (if available for the user ID in transaction SU01)

In reality, email addresses are often not maintained properly for user IDs. For example, many companies simply omit this information when the business side asks the Basis team to create a new user in the system.

However, in most organizations it is quite easy to derive the email address from the first and last name of a person. The typical email address looks like this: firstname.lastname@domain.com.

The ABAP program available for download via this link allows you to create user email addresses, provided that first and last names are already maintained in the system. This program does not update any STS Customizing, it only updates the user records in transaction SU01 with email addresses. To update these changes in STS you need to run Determine Hierarchy for Subplan (step 4) again.

URLs and Dates

In some implementations the planning or reporting URLs are different for each user. For example, the users might plan on different company codes and the planning application for one company code can be different from another company code. The possible scenarios here are very diverse.

I’ll describe two tables that can help automate any derivation rule between user IDs and URLs. It requires some ABAP skills to put your derivation rule in place, but once you know the table names it should be not too difficult. In this section I will just explain the tables you need to use and the relationships between them. You may need the assistance of your ABAP team to proceed with the exact scenario required by your business.

Table UPS_LINKS is the only table you need to update in your ABAP program. Updating this table (namely fields PLANLINK and APPROLINK) results in the assignment of URLs to hierarchy nodes. Planners open these URLs directly from STS emails and go to the planning (URL contained in PLANLINK) or reporting (APPROLINK) screens. Table 1 shows the fields that control assignment of URLs to hierarchy nodes.

Other fields in the UPS_LINKS table include Start Date, Due Date, and Time. These can also be useful in setting up different dates for different users, or to have one common logic for the entire subplan, such as the last working day of the month.

Do not be upset by zero length of the STRING types. In fact you can assign a text of any reasonable length to it. The first three fields constitute the table key. TEILPLAN and VERSION are quite straightforward. However, to identify a hierarchy node corresponding to the third key field, ORGVL, you need another table, UPS_HASH (Table 2). You do not need to update table UPS_HASH, but it contains information for linking a hierarchy node to a 32- character identifier used in UPS_LINKS.

Note that the contents of HKEY are not straightforward. The following value is for the compounding characteristic 0COSTCENTER in which cost center is 9530 and controlling area is 2000:

0COSTCENTER_0000009530_ 0CO_AREA_2000_

Generate and use similar values for HKEY based on the data in your system. Use your subplan name in TEILPLAN. Search table UPS_HASH by HKEY and TEILPLAN and you get a value in the HASH field, which is the one you should use in ORGVL field when updating UPS_LINKS table.

STS and SAP NetWeaver BI Integrated Planning

In SAP NetWeaver BI Integrated Planning, you must complete a couple of prerequisites on top of standard activities to use STS.

Activate STS locking. You can find the details about this at https://help.sap.com/saphelp_nw70/helpdata/en/43/548bafbc0f­357ee10000000a11466f/frameset.htm.

Create an SAP BW Business Planning and Simulation (BW-BPS) planning area. Even if you only use Integrated Planning, to use STS SAP still requires you to create a BPS planning area. In transaction BPS0, go to Planning>Planning Area>Create, then enter a name and description for your planning area (Figure 7). Use the basic InfoCube on which you are planning, in the example ZIC_CCA.

Figure 7

Create the BPS planning area

You need this planning area name when you assign a hierarchy to a subplan in STS customizing. You can see an example of this in Figure 5 in which I used the ZIPCCA planning area.

Andrey Bondarev

Andrey Bondarev is a senior BI consultant for Bluefin Solutions, a UK-based SAP partner. Andrey has more than five years of experience in many areas of SAP BW, specializing in data modeling and performance optimization.

You may contact the author at andrey.bondarev@bluefinsolutions.com.

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