Articles
Resources
Solutions
Contact

STVARV Transaction for Flexibility

When we take a step back and look at features in the BW DataModel that involve ‘hardcoded limitations’, it becomes clear that Transformations and Process Chains do not always have the same absolutely fixed forever requirement. It needs a little flexibility every now and then. A time arrives when the hardcoded limitation was too permanent and the original decision to hardcode the value was the quickest and easiest to implement but it is not the best long term choice for supporting the DataModel.

The ability to tweak that hardcoded value to be a different value for a one-off activity would have made all the difference to be able to repair the DataSet within an InfoProvider. This usually gets highlighted only when a business reporting user has found an issue and needed it fixed, yesterday.

“the TVARVC table exists to
hold configuration values”

For Example: Hardcoding todays date (SYST-DATUM), list of Material Groups (0MATL_GROUP), list of HR Positions (0HRPOSITION), etc.

For Example: Using those lists in InfoPackage and DTP selection filters, Transformation Start and End Routines, Variables for Reporting (BEx Variables), Process Chain Variants, Virtual InfoProviders, etc.

The ability to retrieve values from a configuration table like the TVARVC table will bring the BW Functionality to life; enabling one-off support fixes to be executed and then return to the normal mode of execution (as scheduled).

A BW Administrator can use the STVARV transaction to manually maintain these values. It is generally a bad idea to give the business reporting user community access to maintain TVARVC records; please ensure this capability is limited to BW Administrators who understand the implications on the DataSets within the BW DataModel.

Access to STVARV Transaction

To begin the STVARV journey, log into each BW system in the landscape and understand the current security in place for the STVARV transaction in your landscape. Below is a standard access-matrix highlighting who should usually have access in which system.

SandpitDevelopmentTestingAcceptanceProductionFailover
BW DeveloperCheckedCheckedCheckedCheckedIncompleteIncomplete
BW SupportCheckedCheckedCheckedCheckedCheckedChecked
Reporting Admin.UserIncompleteIncompleteIncompleteCheckedCheckedChecked
Reporting Power UserIncompleteIncompleteIncompleteQuestionQuestionQuestion
Reporting UserIncompleteIncompleteIncompleteIncompleteIncompleteIncomplete

As you work through the business requirements and solidify who needs to be able to update a TVARVC configuration value, it becomes clear that access should be strictly controlled. The ability to use the STVARV transaction with access to all TVARVC records becomes less desirable.

What would be really nice is a way to grant access to a limited number of the TVARVC records. This can be achieved in at least two ways:

  1. The standard table authorisation-object approach will require:
    • A Security Developer to create the standard table authorisations;
    • A Security Developer to put those authorisation-objects into user roles;
    • The user will execute STVARV Transaction to update TVARVC values;
  2. [Recommended] The custom ABAP program approach will require:
    • An ABAP Developer for the program;
    • A Security Developer to put that program into user roles;
    • The user could execute ZSTVARV_BUDGET_PERIOD Transaction to update TVARVC values.

When a custom ABAP program is used, it can be assigned to it’s own transaction code that will be meaningful to the business process it belongs too. That program is easily enhanced to include useful information like links to process documents and reminders about bad data entry values.

Get to know the TVARVC table by spending a little time using the STVARV Transaction to modify Parameters and Selection Options. Use the SE16 Transaction to review those changes directly in the TVARVC table.