How to control BW processes with parameter tables
The parameter-table pattern: a narrow table the business owns, configured so it cannot be filled wrongly, read at runtime by your own BW logic.
📝 Availability: NextTables for SAP BW, Professional and Enterprise editions. The NextTables half needs configuration only. The ABAP that reads the table is your own development, and where it is a BAdI it needs the Enterprise edition.
You will learn
How to let a business department control BW processes by maintaining a small parameter table, instead of raising a ticket every time a period closes or a planning cycle changes. Closed periods, the active planning cycle, the active version and customer-specific data slices are all the same pattern: a table the business owns, read by logic IT owns.
This article is for whoever designs the process, together with an ABAP developer for the reading half.
📝 What this article does and does not give you. The NextTables half is complete: the table, its configuration, and who may change what. The half that reads the parameter, for example an exit data slice class or a process chain step, is your own development against SAP's own interfaces, and it belongs to your system rather than to NextTables. This article says exactly what that code has to do, and does not pretend to ship it.
The pattern
A parameter that steers a BW process is usually owned by the business and maintained by IT, because it lives in a table nobody outside IT can reach. The result is a ticket for every period close.
Splitting it takes three pieces:
- A small table holding the parameter, typically an ADSO or a custom Z table.
- A NextTables configuration on it, so the department maintains it in a browser, with validation and authorizations.
- Your existing BW logic, changed to read the value from that table rather than from a constant, a variable or a transport.
Nothing about the third piece is NextTables-specific. The change is that the value is now maintained by the people who know it.
What it is used for
| Parameter | Who owns it | What reads it |
|---|---|---|
| Closed periods | Accounting or Controlling | A data slice, or a check in a planning function or BAdI. |
| The active planning cycle | Controlling | Planning functions, queries, transformations. |
| The active version | Controlling | Queries and transformations that filter on version. |
| Data load parameters | The department that owns the source | Process chain steps and transformations. |
| Customer-specific data slices | The business unit being locked | An exit data slice implemented as an ABAP class, against an ADSO. |
Prerequisites
- An ADSO or DDIC table to hold the parameters, or the willingness to create one.
- Config admin rights in NextTables. How object authorizations work in NextTables for SAP BW.
- An ABAP developer for the reading half.
Step-by-Step Instructions
1. Model the parameter table
Keep it narrow and keyed by what the parameter varies over: company code, version, fiscal period, whatever the rule actually depends on. One row per combination, one column per parameter.
Use an ADSO with a change log where the parameter has consequences, which for closed periods and locks it always does. You then have a record of who closed what and when, without building anything. See Which objects NextTables for SAP BW can read and write.
2. Configure it in NextTables
Add the table configuration and a menu entry. Three settings do most of the work here:
- Lock the key fields so the department changes the value, not which row it applies to. Adding a new company code to the list is a different permission from closing a period for one.
- Give the flag column a real value help. A checkbox or a dropdown of allowed values stops a free-text field ever holding
Y,yesandXat the same time. See How to give editors the right values in NextTables for SAP BW. - Turn inserting and deleting off if the set of rows is fixed. The department sets values; it does not invent parameters.
Full settings reference: Table and column configuration in NextTables for SAP BW.
3. Decide who may change which rows
A parameter table is exactly where row-level control earns its keep, because one table usually serves several departments that must not touch each other's rows.
- If the split follows BW authorizations, use analysis authorizations. No code.
- If several departments need different views of the same table, give each one a table alias in its own application.
4. Record who changed it
For a parameter that closes a period or locks data, the question "who set this, and when" will be asked. Configure Changed by and Changed on as locked, derived fields rather than relying on the change log alone: How to track changes in NextTables for SAP BW.
5. Read the parameter from your BW logic
This is your development. Whatever reads it, the contract is the same:
- Read the current value from the parameter table at runtime, not at activation time. A value cached at activation defeats the point.
- Decide what an absent row means, and make it the safe answer. For a closed-period flag, a missing row should mean open or closed by deliberate choice, not by accident.
- Fail loudly. If the parameter table cannot be read, stop rather than continuing on a default nobody chose.
For a customer-specific data slice, the reading half is an exit data slice implemented as an ABAP class against the ADSO, using SAP's planning interfaces. NextTables' part ends at the maintained value: the class reads the row for a company code and reports whether the data is locked.
6. Give the department a way to trigger what follows
Where changing a parameter should also start something, a custom button on the same table does it without a second tool: How to start a BW process chain from a NextTables button.
Troubleshooting / FAQs
1. The department changed the flag but the process still ran the old way.
The reading logic is caching the value, or reading it at activation rather than at runtime. Check where the read happens before suspecting the table.
2. The flag column holds three different spellings of yes.
It is a free-text field. Convert it to a checkbox, or attach a value help with the allowed values and set strict.
3. One department can close another's periods.
Restrict by row, not by asking people to be careful. Analysis authorizations if the split follows BW authorizations, table aliases in separate applications otherwise.
4. Somebody added a row that steers nothing.
Inserting is still allowed. If the set of parameters is fixed, switch inserting and deleting off in the table settings.
5. Do I need the Enterprise edition for this?
Not for the NextTables half, which is configuration. The reading half is your own ABAP; where you implement it as a NextTables BAdI, that part is Enterprise.
6. Is there a ready-made data slice class in NextTables?
No. The data slice belongs to SAP's planning framework and to your model. NextTables maintains the values it reads.