Configuration of view is very important task. It provides multiple options like changing labels,field’s properties like display, input field and removing unwanted fields from display section…etc.
For every standard component SAP provides default configuration. If we don’t want that configuration, we should make our new configurations. We should not do any change in the standard configuration. We can always copy the existing configuration and do the changes or can create whole new configuration.
Go to the any view configuration and click on choose configuration button. It will bring all available configuration list of particular view.
Here it is showing two configurations. There are two columns named STD Con. And Cus Conf. the value X tells you which configuration it is. If X is there under STD conf, then it is only standard configuration else it is configuration done by customer.
In above example, both are customer configurations (This is not a sap standard component. ). If you see both X marks under both columns, it means that customer has changed sap standard configuration. However, we should not do that.
Whenever, we try to create a new configuration, framework will throw one Dialog box.
Role configuration key:
Every business role has one unique role configuration key. So we can make configuration of a view dependable on any business role with the help of the role configuration key. So while making a configuration, we can specify a role configuration key . A user who uses the business role with role
configuration key will be presented the same configuration that we made above.
ex: A user U1 has business role B1 with role configuration key RK1. we created a new configuration CG1 for any view using role configuration key RK1. Then CG1 will be loaded for that view automatically by the framework.
OBJECT TYPE: SAP has introduced this UI object type to make UI changes independent of BOL. It sits between UI and BOL in the design layer. We already discussed it.
OBJECT SUB TYPE: This is sub object and in order to create it we use call back classes.
For example: we can create three sub objects INDIVIDUAL, ORGANIZATION and GROUP as sub objects to the business partner(account ) object to make three different configurations.
So we will make three different configurations using above three sub objects. If user wants to create INDIVIDUAL account, then we use the configuration created with sub object INDIVIDUAL. If he wants to create ORGANIZATION, then we will present the configuration with sub object ORGANIZATION to the user. here configuration created with Individual sub object may have fields like first name last name ..etc and the configuration created with the sub object ORGANIZATION may have fields like organization name...etc.
COMPONENT USAGE:
It is very known fact that we re use one view in different components. When we do so, we create component usages in the parent components(the component in which we are using view of different component).
For ex:
Let us say a view V2 has been reused in the two components C2 and C3 with corresponding usages CU1 and CU2. If we want, field F1 of this view V2 should be not visible when view V2 reused in C2 and same field F1 should be visible when reused in C3.
Assumption is that field is already there on the view V2. So we need not to do anything regarding component C3.
So we create one new configuration with CU1 as component usage by removing the field from view V2. So when reused view V2 in C2, based on the component usage name, framework will load correct configuration by not showing the field F1.
For every standard component SAP provides default configuration. If we don’t want that configuration, we should make our new configurations. We should not do any change in the standard configuration. We can always copy the existing configuration and do the changes or can create whole new configuration.
Go to the any view configuration and click on choose configuration button. It will bring all available configuration list of particular view.
Here it is showing two configurations. There are two columns named STD Con. And Cus Conf. the value X tells you which configuration it is. If X is there under STD conf, then it is only standard configuration else it is configuration done by customer.
In above example, both are customer configurations (This is not a sap standard component. ). If you see both X marks under both columns, it means that customer has changed sap standard configuration. However, we should not do that.
Whenever, we try to create a new configuration, framework will throw one Dialog box.
Role configuration key:
Every business role has one unique role configuration key. So we can make configuration of a view dependable on any business role with the help of the role configuration key. So while making a configuration, we can specify a role configuration key . A user who uses the business role with role
configuration key will be presented the same configuration that we made above.
ex: A user U1 has business role B1 with role configuration key RK1. we created a new configuration CG1 for any view using role configuration key RK1. Then CG1 will be loaded for that view automatically by the framework.
OBJECT TYPE: SAP has introduced this UI object type to make UI changes independent of BOL. It sits between UI and BOL in the design layer. We already discussed it.
OBJECT SUB TYPE: This is sub object and in order to create it we use call back classes.
For example: we can create three sub objects INDIVIDUAL, ORGANIZATION and GROUP as sub objects to the business partner(account ) object to make three different configurations.
So we will make three different configurations using above three sub objects. If user wants to create INDIVIDUAL account, then we use the configuration created with sub object INDIVIDUAL. If he wants to create ORGANIZATION, then we will present the configuration with sub object ORGANIZATION to the user. here configuration created with Individual sub object may have fields like first name last name ..etc and the configuration created with the sub object ORGANIZATION may have fields like organization name...etc.
COMPONENT USAGE:
It is very known fact that we re use one view in different components. When we do so, we create component usages in the parent components(the component in which we are using view of different component).
For ex:
Let us say a view V2 has been reused in the two components C2 and C3 with corresponding usages CU1 and CU2. If we want, field F1 of this view V2 should be not visible when view V2 reused in C2 and same field F1 should be visible when reused in C3.
Assumption is that field is already there on the view V2. So we need not to do anything regarding component C3.
So we create one new configuration with CU1 as component usage by removing the field from view V2. So when reused view V2 in C2, based on the component usage name, framework will load correct configuration by not showing the field F1.