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, don’t 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 it’s 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

Request

Response

Controller user

inpu

data outpu

View

Model

Presentation Layer (BSP)

Business Layer (BOL & GenIL)

Tables

Business Engine

CRM WebClient

set

get

Data flow Control flow

(APIs)

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 that’s 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

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.

Request

Response

user input

data output

Controller

View Model

Presentation Layer (BSP)

Business Layer

Business Engine (e.g. my SAP CRM)

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

API API API

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

Controller Model

Presentation Layer

Business Layer

Business Engine

BOL

GenIL

View

BSP

Display BOL Model Transaction: BSP_WD_WORKBENCH or GENIL_MODEL_BROWSER

GenIL IMG: Generic Interaction Layer/Object Layer Basic Settings

test data retrieval from database to BOL through the GENIL Transaction: GENIL_BOL_BROWSER

API

API

API

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. Read-Only 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 you’re 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:

The Controller gets implemented within a single ABAP class which follows the naming convention always to end on suffix _IMPL. It’s 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 SAP’s 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 user’s browser for display. Another pictorial representation

View: Layout

Controller:

Model: Context & Context Nodes

Controller: Event Handling & Navigation

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

Request

Response

Controller user

input

data output

View

Model

* .DO

*. HTM

Context

Context Nodes

Method

*_ CTXT

*_CN01

GET_FIELD

Methods: Before Output

DO_INIT_CONTEXT PREPARE_OUTPUT

After Input DO_HANDLE_DATA DO_HANDLE_EVENT

Layout: ABAP/HTMLB-code describing the view layout

e.g. Bus. Partner

e.g. Address

e.g. Street

DB Tables

BOL

Class _IMPL

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.

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.

ViewSet

ViewArea View

ViewArea

ViewSet View

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

The figure displayed above is a Main Component.

Main Component M

IP

IP

OP

OP

NavBar (Profile)

Logical Link

Technical ID =

(Target-ID)

Sub component Search

ViewSet

View

Window

IP

Search

Display

OP

Window

ViewSet

View

IP

Sub component Header

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

Runtime repository of a Component

Contains all Views, which should be displayed.

Element for Cross-View data transfer

Main programming and UI Configuration objects

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. It’s 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

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.

Presentation Layer (BSP)

Controller

View 1

Model Context Node

Model Context Node

Controller

View 2

Custom Controller

Model Context Node

Lifespan

Business Layer (BOL, GenIL)

Database

Lifespan Lifespan

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:

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.

View View

View View

Component I

View View

View View

Component H

View View

View View

Component S

Component M

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_BUTTONS.

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:

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 we’ve 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.

Navigation Request

Event Handling of Request

Calling of OutboundPlug

Starting Navigation

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.