1.

Business Roles
Definition
The Business role is the central object for controlling the Navigation Bar, the Logical
Links and the authorizations for users
Purpose
The business role determines the different profiles of the UI and
what is visible on the UI
How to define and assign Business Roles
Step1: Go to IMG Path: Customer Relationship Management > Business Roles >
Define Business Roles or to transaction CRMC_UI_PROFILE
Step2: Pick a suitable role which you want to create a copy of and note the PFCG
Role ID

Step3. Go to Transaction PFCG and create a Z copy of the standard PFCG role

Step 4: Once the PFCG Role is created go to IMG Path: Customer Relationship
Management > Business Roles > Define Business Roles and create a new business
role with the above created PFCG Role. (It is convenient to copy the standard role to
Z name space and change the PFCG role ID). Save the changes.
Step 5: IMG Path: Customer Relationship Management > Business Roles > Define
Organizational Assignment or transaction PPOMA_CRM
Users/Business partners are assigned within the Organizational Model to a
Position
User / Business Partners can be assigned to multiple Positions
Each Position can have exactly one Business Role

Double click on the position, menu option Goto>Detail Object>Enhanced Object

Description

Go to Business role and click on create

Maintain the Business role

Save the changes and run UI.

2. Role Config Key

Purpose
Whenever you do your UI Configuration steps, you can choose to save your changes
only for a specific role configuration key. Only users with a Business Role assigned,
which has entered this Role Configuration key will see your changes
How to create and assign Role Config Key
Step 1: Go to IMG Path: Customer relationship management > UI framework > UI
framework Definition > Define role configuration key
Step 2: To assign the role config key to the required business role go to IMG Path:
Customer relationship management > Business roles > Define business roles.

Step 3: You can save your configuration according to different parameters. If different
configurations for one view have been saved you get an overview, if you press
Choose configuration. With Copy Configuration you can copy an existing
configuration. Make the necessary changes to the config and save the same. Run the
UI and notice the made changes.

3. Navigation Bar Customizing

The Navigation bar that is shown on the UI depends on the navigation bar profile
mentioned in the business role.
The path for customizing navigation bar is:
Go to IMG Path: Customer relationship management > UI framework > Technical
Role Definition > Define navigation bar profile

The navigation bar is divided into 2 main categories:

1) Work Centres

2) Direct Link groups

The navigation bar can have a two level menu. Each of the last level entry is known as
a Logical Link.
Logical Links can then be grouped as follows depending on whether you want to
include it as a work centre link or a direct Link
Part of work Centre
Step 1. Create a relevant logical link
Step 2: Group different Logical Links as Work Center Link Groups
Step 3: Group related Work Center Link Groups as work centres
Step 4: Assign the work centre to the navigation bar profile
Part of direct link group
Step 1: Create a relevant logical link
Step 2: Group different logical links as Direct Link groups
Step 3: Assign the direct link group to the navigation bar profile

Once the above steps are done, we need to assign the navigation bar profile to the
business roles:
Go to IMG Path: Customer Relationship Management > Business Roles
Assign your navigation bar profile to the business role.
Note: You also need to go into options adjust work centers, adjust work centre groups
and adjust link groups and activate all the links that you need to see on the UI.

4.Transaction Launcher
Purpose
With Transaction Launcher you can integrate Calls of:
1) External URLs which are defined in URL repository
2) Web Gui Transaction of another SAP System with available ITS
Pre-requisites
1) The transaction Launcher can be used to launch URLs and BSPs / BOR
transactions from other systems.
2) To launch a GUI transaction a BOR object type with a method EXECUTE, that
supports synchronous calls is required.
3) A mapping of the logical systems is required. Transaction:
CRMS_IC_CROSS_SYS
4) To launch an URL the URL has to be defined in the URL repository first.
View: CRMV_IC_LTX_URL
Launch GUI transaction
1) To launch a GUI transaction a BOR object type with a method EXECUTE, that
supports synchronous calls is required.
2) Transaction: SE80 > Workbench > Edit object
3) Copy BOR object type TSTC to ZTSTC

3) In the method Execute set the synchronous flag.

4) Generate the object.

5) Check that the system is maintained in transaction CRMS_IC_CROSS_SYS

6) Go to IMG path: Customer Relationship Management > UI Framework >

> Technical Role Definition > Configure Transaction Launcher or transaction:
CRMC_UI_ACTIONWZ
a) Enter a launch transaction ID

b) Enter a description, class name (Z-class, dont give names of existing classes
else the same gets over-written )
If the STATEFUL flag is set, the launch transaction will always be executed in a
new window and will remain open until the agent manually closes it.
The RAISE VETO flag is used to raise a message to inform the agent that launch
transaction is open on a different window and is useful only when the STATEFUL
flag is set.

c) Choose Transaction Type = BOR Transaction

Choose the BOR Object type you created
Choose EXECUTE

d) Choose Parameter: Object Key

Value: <transaction code>

7) IMG: Customer Relationship Management > UI Framework > Technical Role

Definition > Define Navigation Bar Profile
Create a new Logical Link
Type: C Launch Transaction
Target ID: EXECLTX
Parameter class: CL_CRM_UI_LTX_NAVBAR_PARAM

8) IMG: Customer Relationship Management > UI Framework > Technical Role

Definition > Define Navigation Bar Profile
Create a new Direct Link Group and assign the logical link to it
Assign the Direct Link Group to your Navigation Bar Profile
IMG: Customer Relationship Management > Business Role > Define Business
Role > Set the link to visible

Launch URL
1) Transaction: SM30 View: CRMV_IC_LTX_URL
Maintain the necessary URL details

2) Go to IMG path: Customer Relationship Management > UI Framework >

> Technical Role Definition > Configure Transaction Launcher or transaction:
CRMC_UI_ACTIONWZ
a) Enter a new Transaction Launcher ID

b) Enter a description, class name

c) Select the transaction type as a URL transaction and enter the URL ID

d) Complete and save the transaction launcher

3) IMG: Customer Relationship Management > UI Framework > Technical Role
Definition > Define Navigation Bar Profile
Create an new Logical Link
Type: C Launch Transaction
Target ID: EXECLTX
Parameter class: CL_CRM_UI_LTX_NAVBAR_PARAM

4) ) IMG: Customer Relationship Management > UI Framework > Technical Role

Definition > Define Navigation Bar Profile
Create a new Direct Link Group and assign the logical link to it
Assign the Direct Link Group to your Navigation Bar Profile
IMG: Customer Relationship Management > Business Role > Define Business
Role > Set the link to visible
Note: If you want to have a parameter accepted in the URL maintain the same in
the URL definition. You can fill in the value while configuring the transaction
launcher (if its a constant value).
If the value for the parameter is to be filled dynamically, go to the class mentioned
while configuring the transaction launcher and go to the method
IF_CRM_IC_ACTION_HANDLER~PREPARE_DATA_FLOW.
Make the necessary changes in this method.

5. MVC Concept
Presentation Layer (BSP)
user
inpu

Request

Controller
set Model

CRM WebClient

data
outpu

Response

View

Business Layer

get

(BOL & GenIL)

Data flow
Control flow

Business
Engine

(APIs)
Tables

This is a non-SAP specific programming model. It is a general description of how

to develop software with a clear separation of business logic and data model and
the specific visual presentation of this data.
Within the application there is a strict separation of reading/changing data,
showing data and reacting on user inputs.
(M) Model: The model is a kind of blackbox entity which contains all necessary
methods to get access to business data and functions.. Model interacts with the
BOL and GenIL in order to get the required data.
(V) View: View forms the presentation layer and thats what is visible on the UI
(C) Controller: Controller is responsible for accepting user inputs and interacting
with the model to fetch the required results.

6. BOL & GenIL

Presentation Layer (BSP)
user
input

Request

Model

data
output Response

Business
Layer

Controller
View

BOL: Business Object

Layer
data structures
of the BOL holding business
objects for the UI session

GenIL: Generic Interaction

Layer
GenIL Model and
Implementation
Classes connecting BOL to CRM APIs

Business
Engine

API

API

API

(e.g. my SAP CRM)

BOL (Business Object Layer): The BOL structures hold the data while the UI
session runs. You can treat them as work areas.
GenIL (Generic Interaction Layer): The GenIL layer includes the classes that
connect the BOL with the underlying APIs that fetch the relevant data from the
data base tables.

Note: You can have a look at the underlying GenIL classes as follows:
Go To IMG path: Customer Relationship Management > CRM cross-application
components > Generic interaction layer/object layer > Basic Settings

These GenIL implementation classes connect the BOL to CRM application logic
and database tables APIs
BOL & Genil Tools
Presentation
Controller
Layer

BSP
Model

View

BOL Display BOL Model

Transaction:
BSP_WD_WORKBENCH or
GENIL_MODEL_BROWSER

Business
Layer
GenIL

GenIL
IMG: Generic Interaction
Layer/Object Layer
Basic Settings

test data retrieval

from database to
BOL through the
GENIL
Transaction:
GENIL_BOL_BROWSER

Business
Engine

AP
I

AP
I

AP
I

You can view the entire model of a particular component at

GENIL_MODEL_BROWSER

Types Of Objects
Root objects: Directly accessible via a distinct key (like Header GUID for
BTOrder) and can be independently locked and maintained.
Query Services (Search Objects): Defined object search by given set of
parameters. Return a well defined root or access object type.
Dependent object: Aggregated by a distinct root objects. Locked and maintained
only via its root object.
Query Result objects (Search Result Objects): Aggregated set of fields from
various root, access, or dependent objects for faster display of result lists. ReadOnly by definition.
Access objects: Directly accessible via a distict key but locked and maintained
only via its root object.
View objects: Alias for a hard coded set of objects.

GenIL Model: Relation Types

Aggregations: Binds child objects to a root object. Only Access and Dependent
objects can be aggregated.

Compositions: Like an Aggregation, but composed child objects always exist.

Associations: Link between any kind of objects. Can also be defined across
components with root or access object as target.

You can test the data retrieval from the database to the BOL through GenIL using
GENIL_BOL_BROWSER

Using the pushbutton CHILDREN you can navigate to the relations as you see
them on GENIL_MODEL_BROWSER and view the data.

7. Component Workbench:MVC
To work on UI Components SAP provides so called Component Workbench in
CRM system.
Transaction BSP_WD_CMPWB starts this Tool.
You can also launch UI directly from here.
When youre on initial page you can enter component name CRM_UI_FRAME in
input field Test Application and hit Test button to launch UI

Go to the application and pick up one of the views and note the following:

Controller
:
Model:
Context &
Context
Nodes

Controller:
Event Handling & Navigation

View: Layout

The Controller gets implemented within a single ABAP class which follows the
naming convention always to end on suffix _IMPL. Its also called the
Implementation Class.
The Model is represented by a collection of ABAP classes.
One management class administrates several different model accesses classes.
This management class also follows a certain naming convention to always end on
suffix _CTXT. Therefore this class is also called the Context class. It is
responsible for creating and connecting the context nodes.
The sub elements which are managed by the context are the so called Context
nodes.
Each context node refers to a single business object out of SAPs Business Object
Layer (BOL).
Context Nodes are also implemented as ABAP classes. Each context node
provides methods to get access to specific business data within SAP CRM
databases.
The View is implemented as so called business server page (BSP), which is a .htm
file.
Certain layout specific coding can be found in here. The view takes over the data
coming from model and prepares the final html output which is sent back to users
browser for display.

Another pictorial representation

user
inpu
t

Request

Controller
Class

* .DO
_IMPL

Methods:
Before Output
DO_INIT_CONTEXT
PREPARE_OUTPUT
After Input
DO_HANDLE_DATA
DO_HANDLE_EVENT

View

Model
Context

*. HTM

*_ CTXT e.g. Bus. Partner

Context
Nodes

*_CN01

e.g. Address

Layout:
data
outpu
t

ABAP/HTMLB-code
describing the view layout

Method GET_FIELD e.g. Street

Response
BOL

DB
Tables

8.Controller
In this section, we shall have a look at the basic methods in the controller and the
general architecture.
Each view has a controller which has the naming convention .do. The controller is
implemented through a global class which generally ends with _IMPL.
Attributes
Each implementation class has an attribute called TYPED_CONTEXT which
refers to the type of the Context Class (_CTXT).
Methods
Some of the important methods and for what purpose they are used are listed
below:
a) DO_INIT_CONTEXT
This method is used to initialize the context reference.
b) WD_CREATE_CONTEXT
It instantiates the controller context reference. It calls the method
CREATE_CONTEXT_NODES of the context class.
c) WD_DESTROY_CONTEXT
This method releases the controller context reference.
d) DO_HANDLE_DATA
This is the very first method that the runtime would come to after user has
made inputs on the view or a user action has been triggered. This method has
an importing parameter called FORM_FIELDS. You can check this to see

which fields have been changed on the view.

e) DO_HANDLE_EVENT
This is the event handler of the controller. From here the controller is routed to
the different event handler methods depending on the user action triggered.
f) SET_MODELS
This method is used to map the page attributes of the view with the context
nodes or with the global attributes of the controller itself. If this method is not
implemented then the data would not be visible on the view.
g) DO_PREPARE_OUTPUT
This method is the method called just before the view is rendered to the user
and can be used for any last changes in the display format.
h) Inbound(IP_) / Outbound(_OP) Plugs
The inbound and outbound plugs are used to navigate in and out of a view.
i) IF_BSP_WD_HISTORY_STATE_DESCR~GET_STATE_DESCRIPTION
This method can be used for setting the header texts for the views.

9. Context and Context Nodes

The context class (_CTXT) class acts as a wrapper class which creates and
connects all the context nodes together.
Attributes
The context class has each of the context nodes as its attributes.
There is also another attribute called OWNER which refers to the controller
class reference at runtime.
Methods
a) CREATE_CONTEXT_NODES
This method creates the context nodes by referring to their respective types.
This method also binds the context nodes to the nodes of the custom or
component controller (to be covered later) if desired. ( Refer chapter 15)
b) CONNECT_NODES
This method can be used to link the context nodes.

The context nodes (_CN01) refer to a single business object.

Attributes
The attribute BASE_ENTITY_NAME generally refers to the BOL relation
that the context node refers to.
Methods

The context node class has the methods called getters and setters for each
attribute in that BOL relation.
a) GET_<attr_name>
This method fetches the value of the required attribute from the BOL structure
which is then used to be displayed on the view
b) SET_<attr_name>
This method sets the value entered by the user on the view into the BOL
structure.
c) GET_M_<attr_name>
This method is used to get the metadata of the attribute (basically the data type
that the attribute refers to)
d) GET_I_<attr_name>
This method is used to get the input readiness for the attribute. If this method
returns a FALSE then the attribute is displayed as a read-only field on the
view.
e) GET_V_<attr_name>
This method is used to give any value help to the fields on the view. The
implementation of this method will be taken up later
f) GET_P_<attr_name>
This is used to describe the property of the attribute. For example: you want a
link to appear under one of the attributes then you can use this method.
g) ON_NEW_FOCUS
This method defines how the collection for the context node shall be created.
It is usually called in the method CREATE_CONTEXT_NODES of the
context class to initialize the collection.

10.View Layout
The view is the .HTM file of the view.
Each view has a set of page attributes which are used to display the data on the
view.
Various BSP extensions are available for us to code the view layout.
You can have a look at them in SE80 by selecting the option BSP Extensions.
Each of the BSP extensions provides certain tags.
Some of the extensions commonly used are HTMLB, CHTMLB, XHTMLB etc.

11.Config Tool
CRM 2007 provides a very strong config tool in order to define the configuration
of each view without writing much of html code.

In order to use the config tool you need to use a Role Config key(described in
Chapter 2).
The code to be written at the view level for using this tool is as follows:

<%@page language="abap" %>

<%@extension name="chtmlb" prefix="chtmlb" %>
<%
DATA:
lv_xml
TYPE string.
lv_xml = controller->configuration_descr->get_config_data( ).
%>
<chtmlb:config xml = "<%= lv_xml %>"
mode = "RUNTIME" />

Once this has been done the runtime understands that the view layout as to be
picked up as defined in the configuration and you would be able to see a
configuration tab in your component workbench.

Note: If you are defining a new configuration for a standard view, copy existing
configuration and save the changed configuration against your Role Config key. This
config would be visible when you launch your UI as the role config key is saved
against your Business role. (Process defined in chapter 2)
If you click on the Button Show Available Fields it would list down all the context
nodes with the attributes in them.

You can then select the required attribute and click the + or buttons to add or
remove fields from the view

.
Click on the button Show Field Properties after selecting a field

You will be able to make changes like, changing the row column positions, changing
labels, making the field mandatory or read-only.

Save your config and run UI.

12.Window Concept
Each component must have one or more windows which are hosting
the views.
It defines a root for a hierarchy of viewsets and views in the runtime repository.
Navigation is only possible between views or viewsets which are assigned to the same
single window.
A viewset or view can only be part of exactly one window (still no direct reuse of
views)
The window is not only responsible for managing navigation between own views of
the component but it is also mediating between the embedded and embedding
component during runtime.
It acts as the interface between two single components which are reusing each other.

13. UI Elements: OVP, View Sets, View Areas and View

Within a Window, we generally include an Over View Page (OVP) or View Sets.
Views can also be directly attached to a window.
A viewset consists of several fixed View areas and the views are attached to these
view areas. For Eg. Below we can see a viewset with three different viewareas.
Views put into these areas will be displayed and processed in parallel when running in
UI.

ViewSet
View

ViewArea

ViewArea
View

ViewSet

In case of over view pages the views are attached to the OVP in the runtime
repository. Each of them appears as one Assignment Block (AB) in the
configuration. You need to select the assignment blocks that you want to display.
As for a loading, we have 3 options:
1) Direct Load
The entire view appears as soon as the UI is started
2) Lazy load
The header text of the view appears as a link and you have to click on it to see the
entire view
3) Hidden
Such views are not displayed on the UI.

14. Component Concepts

Components are usually bundled together within a MAIN Component for a
specific field of functionality.
If you notice the naming convention that would tell you if the component is a
Main (M), Search (S), Header (H) or Item (I) component.
SAP naming conventions
For e.g.: One order; BT<object><type>_<speaking string>
Where <type> is S, H, I or M
Note: First seven characters must be unique
M includes S, H, I Components
NavBar (Profile)

Logical Link

Main Component M

Technical
ID =
(Target-ID)
Display

Search

Sub component
Header

IP

OP

Sub component
Search

IP

IP

Window

ViewSet
Window

IP

ViewSet

OP

View

The figure displayed above is a Main Component.

View

OP

OP

Each Main Component consists of all available Sub Components related to one
certain Business Object like One Order etc.
Each Sub Component keeps certain Views. A View represents one UI screen with
a certain collection of fields and data of a Business Object.
Sub Components communicate via Inbound and Outbound Plugs.
These Plugs enable data transfer between components as well as cross component
navigation on UI.
To call such a Main Component from your Navigation Bar a target ID has to be
defined.
This target ID points to a specific so-called work area component together with
a specific inbound plug to use.
Definition of target IDs can be found in Customizing under CRM -> UI
Framework -> Technical Role Definition -> Define Workarea Component
Repository

Important elements of a component

Contains all Views, which
should be displayed.

Element for Cross-View data

transfer
Main programming and UI
Configuration objects

Runtime repository of a Component

Assignment of Views to Windows

Combination of single Views

into one Screen
Navigation Description
Exposition of Component
Elements to the Outside
Definition of Reusage of other
Components

1) In the runtime repository we can find all necessary definitions how runtime
objects work together during processing of UI Component.
To be able to show a view finally to the end user it has to be assigned to a
Window. This assignment will be done in Runtime Repository editor.
2) Different single views can be combined together in a so-called Viewset to
display them together on a single screen.
How and which views form a viewset can be defined in viewset section of runtime
repository editor.
3) Definition of Navigation between views can be found in description of so
called Navigational Links.
A navigational link contains concrete information about on which source view a
navigation starts and on which target view it ends. Its a kind of a dericted route
description for a single navigation step.
4) To enable an UI component to be reusable a so called Component Interface has
to be defined.
In the Component Interface you define which views of the component can be
reused and which data should be available to the outside.
5) A Component Usage defines which parts of an outside component are reused
within the reusing component.
It gives a detailed description of which parts of an outside Component Interface
are getting used and are available then to the reusing component.
Component Usages are handled like inside views, and can be also used as parts of
a viewset or a Navigational Link.
To display parts of reused components, Component Usage also has to be assigned
to a Window.
6) The Models section is used to add the component set of the GenIL structure. It
is the same component set that you enter in the transaction
GENIL_MODEL_BROWSER.

15. Component & Custom Controllers

Component Controller
highest level of all controllers
is loaded at initial load of component
can serve as data container
manages binding of usages
manages data transfer between components
Binding of Context Node from custom controller to component controller

The component controller has a method WD_USAGE_INITIALIZE which is used

to instantiate the context nodes in case of component usages. Based on the usage
name the code is written as follows:

Where iv_name is the name of the controller of the present component

iv_target_node_name is the name of the context node in that controller
iv_node_2_bind is the name of the context node of the used component
Custom Controller
Serves as a data container
enables holding information past the lifetime of a view
is loaded at the time the context of the controller is used the first time
Used to transfer data between views of the same component
Presentation Layer (BSP)
Lifespan
Lifespan
Controller

Controller

Model
Context Node

View 1

Lifespan

Custom
Controller
Model
Context Node

Model
Context Node

View 2

Business Layer (BOL, GenIL)

Database

The binding of the custom controller nodes with the nodes of the view happens in
the method CREATE_CONTEXT_NODES of the context class of the view.

The code is as follows:

Where iv_name is the name of the controller

iv_target_node_name is the name of the context node in that controller
iv_node_2_bind is the name of the context node of the view
As a component the architecture would look something like follows:
Component M

Component I
Component H
Component S

View
View
View
View
View
View
View
View
View
View
View
View

16. Global Data Context(GDC)

Custom controllers can be used to share data between the views of a component and
to extend the lifespan of data so that they survive the lifespan of a single view.
In 2007 this concept is enhanced by the so called global data context. The global data
context is used to transfer data between components and to extend the lifespan of the
data so that they survive the lifespan of a single component.
In the IC Web Client, global data contexts are used a lot as some data need to be
available during the whole session (communication process) like, business partner
confirmed etc.

Technically a global data context is a public custom controller of a component.

To access the Global Data Context the following code might be used:

17. Enhancement Set

For any customer modifications to the standard components, we need an
Enhancement Set.
When doing enhancement for standard component a new BSP application will be
created and standard components runtime repository gets copied in there.
Creation of Enhancement Set
Go to Transaction SM34 and cluster view BSPWDVC_CMP_EXT

Create a new enhancement set. You need to enter only a name and description.

Assignment of Enhancement Set to a client

Go to Transaction SM30 and open maintain BSPWDV_EHSET_ASG

Assign the created enhancement set to the client you require

18. Enhancing Standard Components

In order to enhance a standard component follow the steps:
1) In the component workbench, choose the component you need to enhance and
the enhancement set that you created

2) Click on the button Enhance Component

3) When you do that you get an option to enter a new BSP application name (
This should be a new name)

4) Once you have done that in SM34 view BSPWDVC_CMP_EXT you will be
able to see the enhancement definition

5) Right click on the view that you want to make changes to and say enhance
(All objects in Grey have not been enhanced and the ones in Black have been
enhanced) All the classes would be generated in the Z-namespace, so you can
go ahead and redefine methods or create new methods.

6) All the methods are marked by colored icons

Yellow: Inherited
Green: Redefined
Red: Does not exist

7) Once you have done this you shall be able to see the same in SM34 view
BSPWDVC_CMP_EXT under controller replacements against Enhancement
definitions

19. Creation of a new component with views and

viewsets
Follow the steps listed below:
Go to component workbench and enter the name of the component and say
create. It would ask you to create a MainWindow which is usually the default
window available in any component. Assign a package to the same.

Creation of view sets

Right click on Views and say create viewset

(Give a name to the view set and the number of rows and columns that you require)

(You need to create view areas and enter the column and row positions and the spans)

Creation of Overview pages

Right click on views and say create Overview page. You will need to enter only the
over view page name

Creation of Views
Right click on views and say create

Model nodes are the ones which are picked up from BOL structures. The model nodes
can be created as to be dependent on the higher model nodes as shown in the screen
shot above. The code for creating the collection of the lower end nodes will be
generated by the wizard.

Value nodes are generally used for those data which are not a part of the BOL instead
they could be referring to a DDIC table, etc.

In this step you select the various attributes that you want in your context nodes. The
setters and getters for the same would be generated by the wizard.

Click on the add button and give the DDIC table name and then you can select all the
attributes that you require in your value node.

This step is used link the context nodes of the view with the context nodes of the
custom controller. As covered in chapter 15 the code for binding the context nodes
would be generated.
We shall take up an example of custom controllers later. Let us skip this step for now.

Select the view type that you want to create. You can select an empty view and write
the configuration code or else select the table view in case you want to have the
display in the table format. In case of the table view you shall need to select the
context node which you want to appear in the table format. Form view contains form
for data entry.

All the controller, context and context nodes classes would be generated. Save the
classes.

Next add the configuration code for the view in the .htm as covered in chapter 11 and
create a configuration for the same.

Go to the runtime repository editor of the component and make the following changes

Save the changes

Save the changes

(Finally the repository looks like this)

Test the application.

Similarly you can create other views and attach to the different view areas.
In case you want to attach the same to an OVP instead follow the steps shown below:

After this in configuration select the assignment block and make it available.

20. Creation of Buttons

There are many ways of creating buttons on views. A few ways are listed below:
1) Create an attribute GT_BUTTONS in the implementation class of the view.
This attribute is of the type CRMT_THTMLB_BUTTON_T. This table needs
to be filled in the method DO_PREPARE_OUTPUT of the implementation
class as follows:

At the view.htm level, the following code needs to be maintained for displaying
the buttons:

This view has to be a part of an overview page and the button would be available
besides the view header text.
2) In order to create the buttons in the toolbar, you shall need to implement the
interface IF_BSP_WD_TOOLBAR_CALLBACK. The list of the buttons will
be provided in the method
IF_BSP_WD_TOOLBAR_CALLBACK~GET_BUTTONS

and the number of buttons is defined in the method

IF_BSP_WD_TOOLBAR_CALLBACK~GET_NUMBER_OF_VISIBLE_B
UTTONS.

If the buttons are in a view which is a part of the view set you shall have to
implement the interface in the view set as well.
The buttons in this case would appear in the tool bar.
3) The last method is to directly create the button using the extensions

In this case the buttons would appear depending on their placement in the .htm
page.

21. Event Handling

Once you have created the buttons, links etc. on the view you need event handlers
to handle the user commands. This section describes how it is done in UI.
The implementation class for each view has a method DO_HANDLE_EVENT
which is where the runtime comes to when a user action is triggered. From here it
is routed to various event handlers depending on the event triggered.

This code is generated by the wizard as follows. Go to the controller class of the
view, then in the event handler right click and say Create

Give the event name. Please note that it is very important to have this user
command entered in the right case else the event handler cannot be determined
correctly.

The wizard generates the event handler with a naming convention

EH_ON<event_name> as follows:

You can code what you desire in this method.

22. Navigation Concepts

In order to navigate from one view to another on a user action we need
navigational links, outbound plugs and inbound plugs. These concepts are covered
here.
Inbound Plug / Outbound Plug

IP and OP are methods of regarding view (or windows) controller classes. IP

belongs to navigation source. OP belongs to navigation target and contains coding
to start Navigation.
Creation of IP and OP
Right click on Inbound/Outbound plugs in the implementation class and say
create. The inbound plugs are named IP_<Plug name> and outbound plugs are
named OP_<Plug name>

Navigational Link
Navigational links define the mapping between a specific source with OP and
target with IP. The navigational link name has to be unique.

If navigation target is an independent work area component, navigation is

mediated by mapping tables that are part of Navigation Bar Customizing and the
Work area Component Repository.
Creation of a navigational link
Go to the runtime repository of the view and right click on the Navigational links
and say add navigational link

Create the navigational link with a unique name and provide the IP/OP and the
view details.

Navigation Procedure
The event handler for the event would call the relevant outbound plug.
The outbound plug would then call the Navigational link which would then
navigate to the relevant view.
The steps are illustrated below:

Navigation Request

Event Handling of Request

Calling of OutboundPlug

Starting Navigation

The highlighted name would be the name of the navigational link.

Navigation scenarios
There are two main navigation scenarios in Web client UI
1) Navigation within a Component. This is what is depicted in the picture above.
2) Navigation between a Component and a Work area Component through
Navigation Bar
E.g. Navigation from Sales Ticket View to Product Detail View in Component
ICCMP_BT_SLT

Navigation is not only handled within Component ICCMP_BT_SLT but

responsibility of navigation is dispatched to be handled by the framework on the
outside of the component.
1) The first step within this navigation scenario is similar to what weve seen
before. For the view, where navigation is triggered by clicking a link, the
appropriate event handler and the outbound plugs are called.
However, in the outbound plug method no call of view_manager is done. Instead
of that the outbound plug of a window in the component is called.

2) In the next step window controllers outbound plug method gives responsibility
for navigation to the outside, by so-called firing an outbound plug to the
framework. Name of fired outbound plug and name of outbound plug method
have to be the same.

3) Now Framework gets the information that for Component ICCMP_BT_SLT

outbound plug PRODUCTDETAIL has been called.
With this information Framework gets to Work area Component Repository (IMG
Path: Customer Relationship Management->UI Framework->Technical Role
Definition->Define Work Area Component Repository ) to check resulting object
type and object action combination to find target for this navigation step.

In this case outbound plug PRODUCTDETAIL of Component ICCMP_BT_SLT

is mapped to Object Type: PRD_MATSRV with Action DISPLAY.
4) These object type & object action combination can be mapped to their target
within the Generic OP (Outbound Plug) mapping within navigation bar
customizing. (IMG Path: Customer Relationship Management-> UI Framework->
Technical Role Definition->Define navigation bar profile)

In this customizing table there is defined which so called Target ID should be

Used for an object type & object method combination.
This example maps object type PRD_MATSRV with object action DISPLAY to
target ID TODETAIL.
5) The Target ID itself is also mapped to a specific component & inbound plug
combination in Work area component repository.

Thus the navigation process is completed.

P.S. All navigation scenarios fall into only these 2 categories. If component
usages are defined the navigation happens as if it is an inside component
navigation.