During the last few days, I discussed several features of maintenance dialogs and extended table maintenance. The extended maintenance functionality, however, has its limits at the point where multiple, hierarchical tables come into play. This is where we can use view clusters to build a clean and usable maintenance interface. Find out how in today’s post.
View clusters are the perfect tool to maintain data that is distributed over several tables, with hierarchical dependencies between the single tables. For this demonstration, I’ve come up with a very simple data model that consists of three tables.
I will not go over the necessary steps to define these tables, you should have your data ready by now. Be sure to have the foreign key relationships defined correctly, as this will greatly simplify the generation of the view cluster, although it’s not a must. The first important step that needs to be done is the generation of maintenance dialogs for each of the individual tables (or maintenance views). That needs to be done before a view cluster can be defined, so do that if you haven’t done so yet. I explained how to do it in one of the last posts.
Once you’ve generated maintenance dialogs for all of your tables or maintenance views, open the SAP transaction SE54 to start the generation of the actual view cluster. Click on Edit View Cluster in the application menu bar to open the correct screen. You can now enter a name and click Create/Change to proceed.
Once again, you can safely ignore the popup telling you that you’re working with SAP data. You’ll start by maintaining some header data. Enter a short text and change to the Object structure in the navigation tree on the left side. This is where you add the actual tables that make up your view cluster. Click New Entries to begin, The following fields are required:
- View/Table contains, quite obviously, the name of the view or table you want to add.
- The Short Text will be shown in the navigation pane of the view cluster.
- Predecessor defines the hierarchy relationships between the individual objects.
- The dependency type defines whether entries can be made for one or multiple dependent fields.
- You can change the position of the table in the tree using this field.
- Start defines the table to be displayed once the view cluster is opened.
You’re not done yet! We’ve now defined which tables to show, but we still haven’t defined how they are dependent upon each other.