Getting the basics right – Creating the perfect config table (Part 2, View Clusters)

[Former Member]

A view cluster should be created when a config table has a ‘multi-part' key.  It provides a maintenance screen that allows the user to filter each part of the key in turn, simplifying the management of large sets of config data.

From the previous blog we have a config table with three fields; Sending Country, Receiving Plant, Surcharge Flag.  Country and plant is the key.  Let's say the customising is done on a country by country basis, so each configurer is only interested in the settings for their country.  If we create a view cluster when they maintain the table they will first select the country, then maintain a table of plants for just that country.  What we'll get is this;





To achieve this we need to do number of things

• Create another table for the first part of the key (in this case just the country)


• Create a maintenance view for the original table


• Create the View Cluster

To create another table for just the country, do everything as defined in the part 1 of this blog, but set the Data Browser/Table View Maint. to ‘Display/Maintenance Allowed with Restrictions'.



Create a maintenance view for the original config table (ZMM_TRANSFER)



Set the maintenance attribute for field Sending Country to S.  This will allow you to maintain the table by subsets of country.



On the Maint.Status tab set the Data Browser/Table View Maint. to ‘Display/Maintenance Allowed with Restrictions'.  Then create the maintenance dialog as defined in the part 1 of this blog.

Now we can create the View Cluster.  Call transaction SE54 and select the push button ‘Edit View cluster', enter a view cluster name and choose ‘Create/Change'.   You'll get the message SV137 (Do not make any changes (SAP data)), but provided you use a customer name space you can ignore the message (check note 671067 if you don't believe me).



Double-click on the ‘Object structure' folder.



Here we need to enter the two tables that make up our view cluster, ZMM_TRANSFER_CTY is the table that holds just the country and ZMM_V_TRANSFER is our maintenance view.

The Short text holds the titles of the folders that will appear on the navigation tree on the left of the screen.  As the default size for this frame often truncates the full text it is a good idea to put the most meaningful part at the beginning.

The remaining settings specify the sequence the tables are processed.  So as we're selecting Country first it is set with itself as predecessor, with Dependency R (as it's the header table) and with the Start radio button selected.  For the maintenance view we specify the country table as the predecessor, Dependency as S (meaning in this case that the dependent entries can only be maintained for one country).  The position number defines the sequence of the folders down the navigation tree.

Select the second table (the view cluster) and double-click on the ‘Field dependencies' folder.



This defines the link between the country table and the view cluster, specifically the LAND1 field.

These steps can be repeated where a table has more that two parts to the key.

Back on the header entry screen active the view cluster and back on the initial screen we can test it.  The view Cluster can also be accessed from transaction SM34.



When we need to query the config settings in our code we can read either table ZMM_TRANSFER_CTY (to determine if any config is maintained for a country) and ZMM_TRANSFER to determine the country and plant settings.