pcui_book_50

Release CRM 5 .0

Implementing People-Centric User Interfaces with Business Server Pages and SAP Enterprise Portal The Framework for Pattern-based User Interfaces

The People-Centric User Interface of mySAP CRM

Copyright

© Copyright 2003 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Despite the care that has gone into creating the text, figures, and programs, neither the authors nor the editors assume any legal liability or responsibility for any possible errors and their consequences, especially as the product is still being developed.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,

AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are tr ademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA® is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP NetWeaver, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One. All other product and service names mentioned are the trademarks of their respective owners.


Table of Contents

1 INTRODUCTION TO THE PEOPLE-CENTRIC USER INTERFACE OF SAP............11

2 USER INTERFACE DESIGN PATTERNS...................................................................12 2.1 Graphical Design ........................................................................................................12 2.2 Pattern-Based Interaction Design.............................................................................12 2.2.1 Building Patterns for Generic Tasks .............................................................................13 2.2.2 User Interface Patterns and User Interface Components.............................................14 2.2.3 The User Interface Patterns in Detail............................................................................14 2.3 Conclusion ..................................................................................................................18

3 TECHNICAL FOUNDATIONS FOR PEOPLE-CENTRIC USER INTERFACE DEVELOPMENT...........................................................................................................19

3.1 Introduction .................................................................................................................19 3.2 The Model-View-Controller Design Methodology....................................................19 3.3 MVC Programming in People-Centric UI Framework..............................................21 3.4 Business Server Pages ..............................................................................................22 3.4.1 BSP Extensions ............................................................................................................23 3.4.2 Data Dictionary Services for BSP.................................................................................25 3.4.3 Caching BSPs...............................................................................................................25 3.5 References To HTML and BSP Training and Documentation ................................25 3.5.1 HTML ............................................................................................................................25 3.5.2 Business Server Pages ................................................................................................25 3.6 How Does the People-Centric User Interface Fit in with the Web Dynpro

Concept? .....................................................................................................................26 3.6.1 Web Dynpro ..................................................................................................................26 3.6.2 BSP and Web Dynpro...................................................................................................26 3.6.3 Moving the People-Centric UI to the Next Level of Web Dynpro .................................27 3.6.4 The Web Dynpro Integrated Development Environment..............................................27 3.6.5 Target Server Platforms for Web Dynpro .....................................................................27 3.7 Conclusion ..................................................................................................................27

4 PEOPLE-CENTRIC USER INTERFACE DEVELOPMENT.........................................28 4.1 Introduction .................................................................................................................28 4.2 The SAP People-Centric User Interface Programming Model ...............................28 4.2.1 Model-View-Controller ..................................................................................................28 4.2.2 The User Interface Framework .....................................................................................30 4.2.3 Navigation Concept.......................................................................................................34 4.2.4 Session Management and Locking...............................................................................38 4.3 How to Develop Blueprint Applications ...................................................................39 4.3.1 Development Environment of the User Interface Framework.......................................40 4.3.2 Maintaining Blueprint Tables ........................................................................................41 4.3.3 Model Access Class Development ...............................................................................60 4.3.4 Portal Integration of Blueprint Applications...................................................................84 4.3.5 Generic Containers .......................................................................................................90 4.3.6 Accessibility ..................................................................................................................93 4.4 Logical Flow of Control within the People-Centric UI Framework ........................94 4.4.1 Performance Optimization ............................................................................................95 4.4.2 Testing an Application ..................................................................................................99 4.4.3 Debugging.................................................................................................................. 102 4.4.4 Steps for Blueprint Table Maintenance...................................................................... 102 4.4.5 Naming Conventions for Blueprint Tables ................................................................. 103 4.4.6 Requesting Additional Patterns ................................................................................. 107 4.5 User Interface (Re-)Engineering Process.............................................................. 107


4.6 Conclusion ............................................................................................................... 109

5 APPLICATION DEVELOPMENT – DETAILED VIEW.............................................. 110 5.1 Generic User Interface Services............................................................................. 110 5.1.1 Message Handling ..................................................................................................... 110 5.1.2 Context-Sensitive Help .............................................................................................. 114 5.1.3 F4 Help ...................................................................................................................... 116 5.1.4 Selection of Multiple Objects ..................................................................................... 123 5.1.5 Object Links ............................................................................................................... 123 5.1.6 Favorites .................................................................................................................... 123 5.1.7 Status Management................................................................................................... 124 5.1.8 Generic export of search result lists .......................................................................... 129 5.1.9 Standalone OIC and ODC ......................................................................................... 131 5.1.10 Generic Grouping DropDown Buttons ....................................................................... 132 5.1.11 Enhanced UI Pattern in CRM 5.0: new Floorplan...................................................... 132 5.1.12 Time-Control .............................................................................................................. 142 5.2 Special User Interface Components for Building Views...................................... 145 5.2.1 The MultiEdit Controller ............................................................................................. 145 5.2.2 Hierarchical List View (Tree)...................................................................................... 148 5.2.3 Viewset Selection Pattern (VSP) ............................................................................... 151 5.2.4 Guided Data Entry Pattern (GDP) ............................................................................. 156 5.2.5 Popin for Additional Data Display and Selection ....................................................... 165 5.2.6 Popups....................................................................................................................... 166 5.2.7 HTML Viewer ............................................................................................................. 167 5.2.8 The Text Management Tool....................................................................................... 167 5.2.9 CRM Content Management ....................................................................................... 169 5.2.10 Send Screen for E-Mail or Fax .................................................................................. 171 5.2.11 The Survey Tool......................................................................................................... 174 5.2.12 Document Preview..................................................................................................... 175 5.2.13 OIP as Separate iView............................................................................................... 176 5.3 User Interface Integration of Generic Application Services................................ 177 5.3.1 Creating New Objects................................................................................................ 177 5.3.2 Actions ....................................................................................................................... 179 5.3.3 Document Flow.......................................................................................................... 183 5.3.4 Date Management ..................................................................................................... 184 5.3.5 Business Partners...................................................................................................... 186 5.3.6 Business Address Services ....................................................................................... 187 5.4 Conclusion ............................................................................................................... 198

6 HOW TO EXTEND, CUSTOMIZE, AND PERSONALIZE THE PEOPLE-CENTRIC USER INTERFACE .................................................................................. 200

6.1 Extensions................................................................................................................ 200 6.1.1 Restrictions ................................................................................................................ 201 6.1.2 Creating an Extension ............................................................................................... 201 6.1.3 Extensible Applications.............................................................................................. 203 6.1.4 Easy Enhancement Workbench ................................................................................ 204 6.2 Customizing ............................................................................................................. 206 6.2.1 Customizing at Portal Level ....................................................................................... 206 6.2.2 Customizing at Application Level............................................................................... 209 6.3 Personalization ........................................................................................................ 216 6.3.1 Personalization at Portal Level .................................................................................. 216 6.3.2 Personalization at CRM Level ................................................................................... 217 6.3.3 Personalization at Application Level .......................................................................... 217 6.4 Conclusion ............................................................................................................... 218


APPENDIX 220

Example Application .................................................................................................................... 221 Example 1: Simple Screen with Object Identification Pattern (view)...................................... 221 Example 2: Simple Screen with Model Access (Model) ........................................................... 225 Example 3: Search Area with Search Group (View).................................................................. 228 Example 4: Standard Screen with OIP and ODP1 (View) ......................................................... 230 Example 5: User Interaction Within Standard Screen (Model) ................................................ 231 Example 6: Search Result with Toolbar (View) ......................................................................... 235 Example 7: Result List with Simple Toolbar Interaction (Model) ............................................ 236 Example 8: Search Result with Toolbar Interaction (Model) ................................................... 237 Example 9: Result List with Tree (M/V) ...................................................................................... 239 Example 10: ODP with Multiple Tabs (View).............................................................................. 248 Example 11: ODP 1 with Multiple Tabs (Model) ........................................................................ 251 Example 12: ODP 1 with Toolbar (View) .................................................................................... 259 Example 13: ODP 1 with Toolbar (Model) .................................................................................. 260 Example 14: Screen with ODP 1 and ODP 2 (View) .................................................................. 261 Example 15: Screen with ODP 1 and ODP 2 (Model) ................................................................ 262 Example 16: ODP with Tree (Model / View)................................................................................ 264 Example 17: Dialogs via Popin and Popup (View / Model) ...................................................... 265 Example 18: Screen Variants Within ODP ................................................................................. 267 Example 19: Advanced F4 Help .................................................................................................. 272 Example 20: Favorites ................................................................................................................. 276 Example 21: Documentation ....................................................................................................... 278 Example 22: Event Groups.......................................................................................................... 279 Example 23: Viewswitch Groups ................................................................................................ 280

INDEX 281


Table of Figures Figure 2.1: Abstract Solution Template for Generic Tasks....................................................... 13 Figure 2.2: Structure of the Object Identification Pattern.......................................................... 15 Figure 2.3: Structure of the Object Data Pattern ...................................................................... 18 Figure 3.1: Structure of the SAP Web Application Server ........................................................ 19 Figure 3.2: How the MVC Design Methodology Works ............................................................ 20 Figure 3.3: Simple Example of a Two-Stage MVC Programming Model.................................. 21 Figure 3.4: UI Framework Architecture..................................................................................... 22 Figure 3.5: BSP Displaying a Table with Book Data................................................................. 23 Figure 3.6: Extension Directive for the HTMLB Element “Table View”..................................... 24 Figure 4.1: The Business Transaction Layer Model from the Generic CRM Order.................. 30 Figure 4.2: UI framework .......................................................................................................... 31 Figure 4.3: Page Outline Provided by the UI Framework ......................................................... 33 Figure 4.4: UI Framework Controllers in ABAP Workbench..................................................... 34 Figure 4.5: Explorative Object Link ........................................................................................... 36 Figure 4.6: Portal Menu Navigation .......................................................................................... 36 Figure 4.7: Navigation with the Back and Forward Buttons in the Browser.............................. 37 Figure 4.8: Class Builder in ABAP Workbench......................................................................... 40 Figure 4.9: Transaction CRMC_BLUEPRINT for the Maintenance of Blueprint Tables........... 41 Figure 4.10: The Main Blueprint Table........................................................................................ 42 Figure 4.11: Excerpt from Blueprint Table (Table CRMC_BLUEPRINT) ................................... 43 Figure 4.12: Excerpt from the Main Blueprint Table (Table CRMC_BLUEPRINT) .................... 44 Figure 4.13: Excerpt from the Field Group Entity Table (Table CRMC_FIELDGRE)................. 44 Figure 4.14: Excerpt from the Field Group Table (Table CRMC_FIELDGRP)........................... 45 Figure 4.15: Example of the Reuse of Screen Structures .......................................................... 46 Figure 4.16: Field Properties in the Field Group Table............................................................... 47 Figure 4.17: Example of Referencing Field Groups.................................................................... 51 Figure 4.18: Example for Search Group (Table CRMC_BL_SEARCH) ..................................... 52 Figure 4.19: Example of Tabstrip Records (Table CRMC_REGTABGRP) ................................ 53 Figure 4.20: Example of Viewswitch (Table CRMC_REGTABGRP).......................................... 54 Figure 4.21: Example of Toolbar Records (Table CRMC_TOOLBARGR)................................. 54 Figure 4.22: Example of Events (Table CRMC_BSP_EVENT) .................................................. 55 Figure 4.23: Multigroup in Main Blueprint Table (Table CRMC_BLUEPRINT) .......................... 57 Figure 4.24: Multigroup in Tab Group Table (Table CRMC_REGTABGRP).............................. 57 Figure 4.25: Example of Multigroup (Table CRMC_MULTIGRP)............................................... 57 Figure 4.26: Structure of an Application Set ............................................................................... 58 Figure 4.27: Example of Screen Structures (Table CRMC_ACCESS)....................................... 59 Figure 4.28: Accessing Business Logic Within the UI Framework ............................................. 61 Figure 4.29: Structure of the Model Access Classes for Complex Models................................. 61 Figure 4.30: Interface for the Model Access Class ..................................................................... 63 Figure 4.31: Coding Example for Using Context in Function Group CRM_INTLAY_DATA

Function Module CRM_INTLAY_SINGLE_GET_DATA (Lines 178-185) .............. 64 Figure 4.32: Interface of QUERY Method................................................................................... 65 Figure 4.33: Interface of READ Method...................................................................................... 66 Figure 4.34: Interface of READ_FOCUS_OBJECT Method....................................................... 66 Figure 4.35: Interface of MODIFY Method.................................................................................. 67 Figure 4.36: Interface for Transactional Methods ....................................................................... 68


Figure 4.37: Interface for Initialize Method ................................................................................. 68 Figure 4.38: Interface of CHECK_BEFORE_SAVE Method....................................................... 68 Figure 4.39: Interface of SAVE Method ...................................................................................... 69 Figure 4.40: Interface of AFTER_SAVE Method ........................................................................ 69 Figure 4.41: Interface of AFTER_ROLLBACK Method............................................................... 69 Figure 4.42: Interface of GET_PRIORITY Method ..................................................................... 70 Figure 4.43: Interface of INITIALIZE Method.............................................................................. 70 Figure 4.44: Interface of CHECK_BEFORE_DELETE Method .................................................. 71 Figure 4.45: Interface of DELETE Method.................................................................................. 71 Figure 4.46: Interface of AFTER_ROLLBACK_DELETE Method .............................................. 71 Figure 4.47: Interface of PROCESS_EVENT Method................................................................ 72 Figure 4.48: Interface of FILL_EVENTGROUP Method ............................................................. 73 Figure 4.49: Interface of GET_MESSAGES Method.................................................................. 73 Figure 4.50: Interface of GET_VARIANT Method....................................................................... 74 Figure 4.51: Interface of GET_FIELDGROUP_VARIANT Method ............................................. 74 Figure 4.52: Interface of GET_ACTIVE_TOOLBAR Method...................................................... 75 Figure 4.53: Interface of CHECK_ACTIVE_TABSTRIP Method ................................................ 75 Figure 4.54: Interface of FILL_DROPDOWN_LISTBOX Method ............................................... 76 Figure 4.55: Interface of CHECK_ACTIVE_MULTIGROUP....................................................... 77 Figure 4.56: Interface of CHECK_ACTIVE_STEPS ................................................................... 77 Figure 4.57: Interface of CHECK_ACTIVE_VIEWSETGROUP ................................................. 77 Figure 4.58: Interface of method CHANGE_FOCUS.................................................................. 77 Figure 4.59: Interface of CONVERT_TO_BOR Method ............................................................. 78 Figure 4.60: Interface of CONVERT_FROM_BOR Method........................................................ 78 Figure 4.61: Interface of GET_MY_FAVORITES Method .......................................................... 78 Figure 4.62: Interface of SET_URL_PARAMETER Method....................................................... 79 Figure 4.63: Interface of IS_OBJECT_IN_CREATE_MODE Method......................................... 79 Figure 4.64: Interface of GET_ALLOWED_DDLB_VALUES...................................................... 79 Figure 4.65: Interface of SET_SELECTED_STEP_ID................................................................ 80 Figure 4.66: Interface of SET_SELECTED_PROCESS_ID ....................................................... 80 Figure 4.67: Interface of CHECK_ACTIVE_SHUFFLER............................................................ 80 Figure 4.68: Interface of GET_PARENT_OBJECT_KEY method .............................................. 81 Figure 4.69: Interface for the Model Access Class ..................................................................... 81 Figure 4.70: Interface of QUERY_BY_STRING Method ............................................................ 82 Figure 4.71: Interface of QUERY_BY_EXTINDEX Method........................................................ 83 Figure 4.72: Interface of READ_BE_EXTINDEX Method........................................................... 83 Figure 4.73: Examples of Authority Transaction Codes ............................................................. 85 Figure 4.74: Example of CRM Object Types (Table CRMC_PRT_OTYPE) .............................. 87 Figure 4.75: Example of Object Link Assignment (Table CRMC_PRT_ROLE_MO) ................. 87 Figure 4.76: Integration of a Blueprint Application as an External Portal Service ...................... 90 Figure 4.77: Logical Flow of Control ........................................................................................... 95 Figure 4.78: Testing an Application Without Using the Portal .................................................. 101 Figure 5.1: Table CRMC_BSP_MSGS ................................................................................... 112 Figure 5.2: Table CRMC_BSP_MSG_GRP............................................................................ 112 Figure 5.3: Example of Table CRMC_F4MAPREC ................................................................ 118 Figure 5.4: Example of Table CRMC_F4MAPSND ................................................................ 119 Figure 5.5: Example of Table CRMC_F4_MULTIDEF............................................................ 120


Figure 5.6: Example of Status Management in the Result List............................................... 125 Figure 5.7: Example of Status Management in the ODP........................................................ 125 Figure 5.8: Example of Status Management in a Tab ............................................................ 126 Figure 5.9: Example of Status “Blocked” ................................................................................ 126 Figure 5.10: Example of Status in ODP 2................................................................................. 127 Figure 5.11: OIP List ................................................................................................................. 133 Figure 5.12: Separated ODP with Header ................................................................................ 133 Figure 5.13: Internal Link: switch to Details .............................................................................. 134 Figure 5.14: Goto Button Navigation possibilities within the new floorplan .............................. 135 Figure 5.15: Fields in Structure CRMT_BSP_TREE_INCL ...................................................... 148 Figure 5.16: Viewset Selection Pattern (VSP) .......................................................................... 152 Figure 5.17: Fields in Viewset Group Table CRMC_VSETGRE .............................................. 152 Figure 5.18: Fields in Viewset Group Table CRMC_VSETGRP .............................................. 153 Figure 5.19: Example of Viewset Group Table CRMC_VSETGRP.......................................... 153 Figure 5.20: Example of Table CRMC_BLUEPRINT with VSP................................................ 154 Figure 5.21: Interface of CHECK_ACTIVE_VIEWSETGROUP Method .................................. 154 Figure 5.22: Fields in Structure CRMT_BSP_VSETGRP_M.................................................... 155 Figure 5.23: Fields in table CRMC_BSP_PROC...................................................................... 156 Figure 5.24: Interface of SET_SELECTED_PROCESS_ID method ........................................ 156 Figure 5.25: Guided Data Entry Pattern (GDP) ........................................................................ 156 Figure 5.26: Stepbar in GDP..................................................................................................... 157 Figure 5.27: Example of Step Group Table CRMC_STEPGRP ............................................... 158 Figure 5.28: Fields in Step Group Table CRMC_STEPGRP.................................................... 158 Figure 5.29: Example of Table CRMC_BLUEPRINT with GDP ............................................... 159 Figure 5.30: Interface of CHECK_ACTIVE_STEPS Method .................................................... 160 Figure 5.31: Fields in Structure CRMT_BSP_STEPGRP_M.................................................... 160 Figure 5.32: Interface of SET_SELECTED_PROCESS_ID Method ........................................ 161 Figure 5.33: Interface of SET_SELECTED_ STEP_ID............................................................. 162 Figure 5.34: Screenshot with OIP and GDP ............................................................................. 163 Figure 5.35: Screenshot of OIP, VSP, and GDP ...................................................................... 163 Figure 5.36: Blueprint Table Maintenance for Popin ................................................................ 166 Figure 5.37: Screenshot of Content Management.................................................................... 169 Figure 5.38: Screenshot of Send-Screen Popin ....................................................................... 172 Figure 5.39: Example Coding of Reading the Customizing Parameters .................................. 173 Figure 5.40: Preview in a New Window .................................................................................... 175 Figure 5.41: Example of Actions in a Separate Tab ................................................................. 180 Figure 5.42: Entries in CRMC_ACCESS for Actions ................................................................ 181 Figure 5.43: Entries for Actions in the Main Blueprint Table .................................................... 182 Figure 5.44: Example of a Screen Structure for Date Management......................................... 185 Figure 5.45: Example Business Partners in Opportunity Management.................................... 186 Figure 5.46: Business Partner in the ODP................................................................................ 186 Figure 5.47: Business Partners on the Partners Tab................................................................ 187 Figure 5.48: Business Partners on the Address Selection Popin ............................................. 187 Figure 5.49: Business Partners on the Partners Selection Popin............................................. 187 Figure 5.50: Model Access Class for Business Address Services ........................................... 189 Figure 5.51: Interface of GET_ADDRESS_KEY Method.......................................................... 190 Figure 5.52: Interface of ADRESS_IS_CREATED Method ...................................................... 191


Figure 5.53: Interface of GET_GLOBAL_PARAMETERS Method........................................... 191 Figure 5.54: Interface of GET_ADDRESS_NUMBER Method ................................................. 191 Figure 5.55: Interface of GET_PERSON_NUMBER Method ................................................... 192 Figure 5.56: Interface of DELETE_ADDRESS Method ............................................................ 192 Figure 5.57: Interface of INITIALIZE_ADDRESS Method ........................................................ 193 Figure 5.58: Interface of SET_DIALOG_MODE Method .......................................................... 193 Figure 5.59: Interface of SET_OPTIONAL_ADDRESS Method............................................... 194 Figure 5.60: Interface of ENABLE_DUPLICATE_CHECK Method .......................................... 194 Figure 5.61: Interface of SET_FIELD_SELECTION Method.................................................... 194 Figure 5.62: Interface of SET_ DISABLE_ADDRESS_VERSIONS Method ............................ 195 Figure 6.1: Extension Concept with Customizing Includes..................................................... 201 Figure 6.2: Creation of a Customizing Include........................................................................ 202 Figure 6.3: Additional Field on the UI Using a Customizing Include....................................... 202 Figure 6.4: Portal Role and Blueprint View............................................................................. 207 Figure 6.5: Personalizing the Page Layout............................................................................. 216 Figure 6.6: List Customizing in Blueprint Applications............................................................ 217


Abbreviations Abbreviation Explanation ABAP Advanced Business Application Programming API Application Programming Interface BAB Blueprint Application Builder BAPI Business Application Programming BAdI Business Add-In BAS Business Address Services BSP Business Server Pages CI Customizing Include EEW Easy Enhancement Workbench EP Enterprise Portal GDP Guided Data Entry Pattern GOS Generic Object Services GUI Graphical User Interface HTML HyperText Markup Language HTMLB HTML Business for BSP HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol with SSL (Secure Sockets Layer) ICM Internet Communication Manager IDE Integrated Development Environment IMG Implementation Guide ITS Internet Transaction Server JSP Java Server Pages LDAP Lightweight Directory Access Protocol LOIO Logical Info Object LUW Logical Unit of Work MIME Multi-Purpose Internet Mail Extension MVC Model-View-Controller mySAP CRM mySAP Customer Relationship Management SAP EP SAP Enterprise Portal ODP Object Data Pattern OIP Object Identification Pattern OTF Output Text Format OTR Online Text Repository PDA Personal Digital Assistant PDV Portal Data Viewer PPF Post Processing Framework RFC Remote Function Call SAP Web AS SAP Web Application Server SP Support Package UI User Interface URL Uniform Resource Locator VSP Viewset Selection Pattern WML Wireless Markup Language XML eXtensible Markup Language


1 INTRODUCTION TO THE PEOPLE-CENTRIC USER INTERFACE OF SAP

This book provides information on the:

• Technical foundations for People Centric User Interface (PCUI) development

• Development process of the PCUI framework

• Application development by using the PCUI Framework

• Customizing and extending the PCUI framework

For an introduction on the goals and need for PCUI of SAP, User Interface Design Patterns, Portals, and How to Build People Centric Portal Content, see the previous version of the book and refer to chapters 1, 2, 3, and 7 respectively.

We also recommend you to read the Getting Started with mySAP CRM section for 5.0 in the help portal under mySAP Customer Relationship Management.


2 USER INTERFACE DESIGN PATTERNS User interfaces (UIs) for software applications must appeal graphically to users and meet their interaction requirements.

To achieve these goals, two aspects need to be taken into consideration when designing a UI:

• Graphical design

• Interaction design

To a certain extent, these two aspects can be viewed as separate entities as described below, whereby this document focuses mainly on interaction design.

2.1 Graphical Design

The graphical design refers to the shapes, colors, and fonts used on a UI and is defined by the selected style sheet. Various style sheets have been designed in collaboration with Frog Design and are available as part of SAP EP, which also provides a style sheet editor for designing customer-specific style sheets. For additional information on graphical design, refer to the appropriate documents from SAP EP (see help.sap.com → Cross Industry Solutions → SAP Enterprise Portal)

2.2 Pattern-Based Interaction Design

The interaction design is concerned with how the user interacts with the system, which data is displayed when, which UI elements are used to enter and modify data, and how the navigation works.

In the following sections, we will show that the use of a small set of generic UI building blocks (called UI components), which are constructed according to predefined user interface patterns, leads to more simple, easy-to-use, and consistent UIs.

In general, a pattern is a canonical design solution on a specific level of abstraction. The pattern-based approach, that is, constructing solutions based on predefined, abstract specifications, or solution templates, has been in use for a long time – for instance in the field of architecture: When designing a building, an architect first determines the purpose of the building and its basic functions. For example, a house should provide rooms in which to sleep, cook, live in, eat, and wash. Therefore, the architect begins by drawing up a plan that describes the following:

• The structure of the building

• The purpose of each room (bedroom, living room, and so on)

• The functions of each room, indicated by standard symbols (bed, stove, sofa, and so on)

• The connections between the rooms (doors and windows)

Details such as the electrical and sanitary installations are left out at this stage of the design. Best practice solutions are often available for specific design problems, for example, for the efficient spatial order of kitchens, living rooms, and dining rooms.

In a similar fashion, SAP uses a pattern-based approach to design the interaction screens for its software applications. Based on SAP’s extensive experience in software development and on numerous user studies, an abstract specification for user interaction with software was developed at SAP.

The pattern-based approach offers important advantages for development:


• Patterns are defined on an abstract or semantical level. They can easily be used with different screen specifications (various resolutions, Personal Digital Assistants (PDAs)).

• Pattern-based user interfaces are comprised of hierarchically structured, reusable user interface components. It is easy to regroup, reuse, or redesign individual components.

2.2.1 Building Patterns for Generic Tasks

Seen abstractly, every software user carries out various generic tasks when processing a business transaction, for example:

• Selection of the business object type

• Orientation

• Search for the object to be maintained

• Selection of the object to be maintained

• View and maintenance of the selected object at header level

• View and maintenance of the selected object at detail level

Since these generic tasks are carried out when processing every single business transaction, it is advantageous to have them displayed on the screen in a uniform and logical manner. The determination of the geographical distribution of the tasks on the screen led to the first pattern (or solution template), which is the “ground plan” of the UI (see figure 2.1).

Solution templates have been developed by the SAP Usability Engineering Center for these generic tasks. Each generic task comprises various elementary tasks. These elementary tasks correspond to certain interface elements (controls), for example, choosing an item from a selection list or editing a field.

With the specification of the ground plan and the solution templates for individual basic tasks, a solid interaction design is available that serves as a basic ground plan for all mySAP CRM applications (such as Marketing, Sales, and Service).

To achieve this goal, the abstract generic tasks that make up a business transaction were determined.

Through close collaboration between usability experts and users, work processes were analyzed, subtasks of business transactions were identified, and corresponding abstract specifications – the patterns – were drawn up.

Orientation: Object type

Object identificationObject search and selection

Editing details of main attributes

Editing main attributes

Figure 2.1: Abstract Solution Template for Generic Tasks


2.2.2 User Interface Patterns and User Interface Components

The People-Centric UI is built from a set of elementary UI components that can be combined to form higher levels of hierarchically structured components. On each level of the UI component hierarchy, only predefined combinations and arrangements of components are allowed on the screen. Allowed combinations and arrangements of components are described within the UI patterns approved by the SAP Usability Engineering Center. Patterns are available for each level of the component hierarchy.

The top-level pattern of the People-Centric UI page is called a business object pattern, which is a combination of more specialized patterns (see figures 2.2 and 2.3):

• The Object Identification Pattern (OIP) which contains the search area and result list. It is used for object search and identification.

• The Object Data Pattern (ODP) for object data presentation

These specialized patterns visualize object structures and offer related services, such as personalization and help functions.

2.2.3 The User Interface Patterns in Detail

Semantically related tasks are grouped together in special patterns to visualize them on screen. Each pattern serves a specific task. Up to five patterns – in a fixed order – form the basic structure of a page (business object pattern) of the People-Centric UI:

• Search area pattern (upper part of OIP), for orientation and object search

• Result list pattern (lower part of OIP), for object identification and maintaining objects at header level

• Object Data Pattern 1 (ODP1), for viewing and maintaining objects at detail level

• Object Data Pattern 2 (ODP2, optional), for viewing and maintaining objects at detail level

• Object Data Pattern 3 (ODP3, optional), for viewing and maintaining further objects

2.2.3.1 Object Identification Pattern (OIP)

The following generic tasks are carried out in the Object Identification Pattern:

• Orientation

• Object search

• Object identification

There is one standard search solution that enables users to work on their tasks (see figure 2.2).


Account

Search Bar AreaAdvanced Search Area

Content Area

Container content (list, form, graphic and so on)

Advanced Search (Shuffler)

Toolbar Area

Search Bar

Toolbar

Figure 2.2: Structure of the Object Identification Pattern

In order to provide each user with an individual work environment, mySAP CRM and mySAP HR use technology from SAP EP. The portal provides the user with the various mySAP CRM / mySAP HR applications available and the necessary navigation tools. To aid user orientation, the name of the current application is displayed on the screen. On the same level, the following functions for working within the pattern are provided:

• Minimized view – displays only one line of the result list

• Normal view – displays five lines

• Maximized view – displays 25 lines on the screen

2.2.3.1.1 Object Search

Object search allows users to search for an object either by using a predefined search or by using the fast-entry search. If users want to limit their search from the start, they can open the Advanced Search area in the search area and enter additional search criteria.

In addition to the search functions provided, users can also define their own searches, save them, and later retrieve them from the dropdown list box.

2.2.3.1.2 Toolbar

The search result is displayed in a table in the content area. Above this is a toolbar component that provides functions for the objects displayed and for viewing the table. These are:

• Toggle button (to switch between list view and form view)


• In the form view, the identifying basic data of the selected objects is displayed in a form (the fields and the toolbar adapt to the changed view)

• Expandable button toolbar with the standard functions Create, Save, or Delete and other buttons, depending on the specific application

• Help information regarding the current application

2.2.3.1.3 Sorting, Filtering, and Navigating in the Result List

The result list can be personalized by changing the settings of the list.

Under the column headers of the list an additional line can be activated for filtering by pressing the button Filter On in the right corner above the column headers. After pressing this button its description changes to Filter and if you press it you will get a menu with three entries. Dependant on the particular data column the belonging filter column can support the data choice. There are dropdown list boxes with the current possible data values, input fields with F4 help, input fields with special value help for dates and in case of checkboxes you will get a dropdown list box with the entries Show selected, Show unselected and an empty entry (for showing all). Here the user can enter filter criteria for the current list. Filtering is performed by pressing the button Filter (see above) and choosing the menu entry Execute Filter or by selecting the filter-icon in the column furthest to the left of the filter line, or by choosing Enter. If a dropdown list box or another value help will be used in the filter line filtering is performed too. The filter string can consist of any character. If the button Filter will be pressed and the menu entry Reset Filter Values will be chosen the filter line will be cleared and the initial list content will be shown. If the menu entry Filter Off will be chosen the filter line will be removed, the filter button description changes to Filter On and the initial list content will be shown. The user also has the possibility to personalize that the filter line will be displayed at start up of a particular list. In the personalization dialog of a list (accessible by pressing the link Personalize in the right corner above the list header) you can set the checkbox for Display Filter Line During First Call. With this adjustment the list filter line will be shown at start up. Be aware that this setting only affects the filter line by the first call of the list. If you close the filter line and change to another application and later return to the prior application with the list, the filter line is closed – as adjusted before.

If the user selects the fields of the header line in the result list the result list is sorted alphabetically or numerically, according to the selected column.

The user can navigate through the list by using a navigation element that enables the user to scroll up and down to see more objects. The user can also jump directly to the beginning or end of the list or to a special page. The page number display also aids orientation.

2.2.3.1.4 Selecting an Object

Selecting an object highlights the line and switches the previously “read-only” cells of that line to “edit” mode. The highlighted object now has the status “selected”. Functions like Delete can be chosen for the selected line. The selected line calls the business object and updates the subsequent containers. The next editable field can be reached using the tab button on the keyboard.

Input help (also called “F4 help”) is offered for several field types:

• Calendar help (to enter a date)

• Value help (to enter currency values, or country codes, for example)

• Complete Object Identification Pattern (enabling users to search for objects they want to enter into the system, such as a customer address)


The selected column remains fixed if the table is scrolled horizontally.

It is possible to add or remove selected objects from My Favorites by choosing the relevant buttons.

2.2.3.2 Object Data Pattern (ODP)

The following generic tasks are carried out in the Object Data Pattern (ODP):

• Viewing the selected object

• Maintaining the different views and attributes of the selected object

There are several UI components available for the ODP, with the most commonly used being:

• List view

• Form view

ODPs can also be filled with content other than lists or forms. For this purpose, special UI components are available as tabs in the ODP, for example, for content management, text management, or for interactive questionnaires (the Survey Tool).

The following list shows examples of additional UI components available as visualization variants in the ODP:

• Hierarchy display (also available in OIP)

• Text management

• Content management

• Survey Tool

• HTML viewer (for example, for product configuration)

• Address detail

Usually a maximum of three ODPs follow a single OIP on one screen. The number and dependencies of the ODPs are influenced by the structure and the focus areas of the object:

• The first ODP displays important attributes of the object, often in a form

• The second ODP displays hierarchically dependent objects or details

• The third ODP displays additional details

In general the ODP consists of a row of tabs that offer different views of the object selected in the result list. The selected tab is brought forwards in front of the other tabs. Any number of tabs can be offered to the user. The user can scroll through the tabs by using the navigation elements. A popup menu also allows the user to jump directly into a tab.


Content Area

Toolbar Area

Toolbar

Container content (list, form, graphic and so on)

Toolbar Area

Figure 2.3: Structure of the Object Data Pattern

The ODP toolbar has the same properties as the result list toolbar, except that the ODP toolbar of the list component can contain a dropdown list box, which offers the user different views on a single object in a particular tab. The functions that are subsequently made available refer to the selected tab.

The content area has the same functions as those of OIP. The data is displayed in a list or in the detailed display and the user can edit data in both views.

2.3 Conclusion

By analyzing and standardizing the various tasks of a CRM or HR user’s typical working day, the SAP Usability Engineering Center has worked out the generic tasks of a CRM or HR user for the People-Centric UI. In the next step, these generic tasks were transferred to a hierarchical set of UI patterns, which are abstract specifications of the interaction screens. These patterns are used for the implementation of the UI of the various CRM applications. The result is a consistent, easy-to-use, and easy-to-learn UI for mySAP CRM and mySAP HR.


3 TECHNICAL FOUNDATIONS FOR PEOPLE-CENTRIC USER INTERFACE DEVELOPMENT

3.1 Introduction

The People-Centric UI is based on a combination of portal technology, the Model-View-Controller (MVC) programming model, and the Business Server Page (BSP) technology of SAP Web Application Server (SAP Web AS) – the platform system for mySAP Business Suite. SAP Web AS is the result of further development to the SAP Application Server, with particular consideration given to the Internet. All prerequisites for the efficient development and operation of Web applications are provided by SAP Web AS. Based on SAP’s new Internet Communication Manager (ICM), HTTP requests from the Internet (from a browser, for example) can be processed directly in SAP Web AS and HTTP client requests can be sent directly to the Internet.

SAP Web Application Server

Dispatcher

Internet Communication

Manager

Work ProcessWork Process



Work Process

Database

DIAG

HTTP(s)Browser

SAP GUI

Figure 3.1: Structure of the SAP Web Application Server

3.2 The Model-View-Controller Design Methodology

The MVC design methodology is an object-oriented methodology that efficiently relates UIs to the underlying data models. For quite some time now, MVC has been the dominant methodology in the development of graphical user interfaces (GUIs) in client-server environments, and with the C/C++ and Smalltalk programming languages. MVC is now becoming more widely adopted and is the predominant methodology for the development of Web-based UIs through programming practices or through platform-specific derivatives of MVC (for example, JavaServer Pages Model 2 methodology). Today MVC is held in high regard by the software development community as a pattern for reducing the overall time required for the development of software with UIs and for greater reuse of object code.

The basic interactions in an application based on MVC are illustrated in the figure below:


Figure 3.2: How the MVC Design Methodology Works

The MVC design approach is based on a clear separation between processing control, data model, and data display in the UI. The formal separation of these three areas is realized by means of the three components model, view, and controller. With the help of these components, complex Web applications can be divided up into simpler, logical units.

• View

The view is the visualization layer, which is responsible for the rendering of the graphical and textual outputs. Inbound and outbound data is displayed in the relevant interface elements (such as push buttons, menus, and dialog boxes). The view receives instructions from the user and passes these on to the controller.

• Controller

The controller monitors and interprets the user’s mouse and keyboard input and causes the model or view layer to react accordingly. Data entries are sent on to the model for processing. Furthermore, the controller informs the views about status changes to the model. In this way, the controller determines the reactions to the user entries and status changes of the model.

• Model

The model delivers or receives data from the controller and ensures that the data is processed by the corresponding business logic. The model deals only with internal processing, with no reference to the UI. There are various views for a model. For example an account can be displayed in a list or in a form in different applications. As the model knows neither the views nor the controller, the internal business logic is decoupled from the UI. This opens up the possibility of displaying the same data in a different manner and with different devices.

Using the MVC design methodology has the following advantages:

• Simplification of the structure of applications, since the view is totally separated from the model and the controller. This facilitates not only the changeability of applications, but also greatly improves their maintainability.

• Dynamic structuring of pages from several views, resulting in a componentization of the layout.

• It need not be decided which page comes next until input processing has been completed. The controller can branch to different views as appropriate.

• Even complex visualization logic can be implemented with the MVC approach.

• MVC supports a strict separation of concerns. Thus the layout and the visualization logic can be maintained by different people.


3.3 MVC Programming in People-Centric UI Framework

In the simplest case, a controller works with one model that delivers data, and with one view that visualizes this data. However, complex interaction mechanisms require a more thorough componentization. In this way, a controller can control several views, or can call subcontrollers that then generate the views.

The People-Centric UI is built on a two-level controller model. There is the central main controller, which accesses various subcontrollers, each of which is assigned to one or several views. The main controller communicates, amongst others, with the following subcontrollers:

• Search request controller

• Search result controller

• Detail controller

• Multi controller

Controller

ControllerController

Model

ControllerView

View

ViewViewView

Figure 3.3: Simple Example of a Two-Stage MVC Programming Model

The search request controller builds the search area view, and the search result controller builds the result list view (see section 2.2.3.1.3). Similarly, the detail controller creates the view for the ODP (see section 2.2.3.2). The multi controller unifies the views of several different subcontrollers (see section 4.3.2.7).

HTTP requests sent from the browser are received by the main controller. This then calls in sequence the appropriate subcontrollers (search request, search result, detail). These subcontrollers access the model for data retrieval (for details on model access, see section 4.3.3). The model makes defined access methods available, such as:

• Query

• Read

• Modify


The subcontroller transfers the data received from the model to the view, which it builds dynamically using HTML Business for BSP (HTMLB) extensions (see section 3.4.1). The completed views are passed on to the main controller, which then sends the response to the browser. As the controllers and views comprise a generic framework for the UI, the main controller requires additional information about the application-specific setup of the page (for example, which fields are to be filled with which data types, and which methods should be used to access the application). This information is stored in the blueprint tables, which the main controller accesses during runtime.

Controller ModelView

User InputD

isplay

Search Area View

Result ListView

Detail Area View

QUERY(data)

Blueprint Tables



READ(data)

MODIFY(data)

Figure 3.4: UI Framework Architecture

3.4 Business Server Pages

Within the SAP UI programming model, BSP coding is a task only performed by a limited number of specialized controller developers. Application developers do not work with the BSP coding itself − they customize BSP controllers via blueprint tables. This section describes what BSPs are and how they can be used.

SAP Web AS with its BSPs, a page-based programming model supporting server-side scripting, is SAP’s platform for the development of Web applications with dynamic screen layout. The BSP programming model is very similar to other server page models, such as Java Server Pages (JSP) and Active Server Pages (ASP).

BSP applications consist of the interface definition and program logic, which are pulled together to form a logical unit – the BSP application. The UI is developed using HTML and embedded tags from BSP extensions (see section 3.4.1). Communication between the UI and the program logic occurs at given points in time and is controlled by the BSP runtime environment by calling the Advanced Business Application Programming (ABAP) programs belonging to the relevant application (using BAPIs, function modules, or class libraries). Within the UI framework, controllers are implemented as BSP applications.

The interaction between the BSP application and the user is not based on the SAP GUI but on the HTTP or HTTPS protocol using a Web browser or a mobile device browser (such as a WAP phone). By using the standard Internet protocols, firewalls and proxy servers can also be easily integrated into the system landscape.

The UI of a BSP application consists of the following:

• Web pages (BSP pages)

The BSP pages are displayed in the browser. They can contain static HTML code and dynamic scripting code (ABAP or JavaScript). This scripting code is evaluated on the server.

• Multi-Purpose Internet Mail Extension (MIME) objects

In the SAP system, all MIME objects, such as graphics, style sheets (with which the formatting properties of individual HTML tags can be defined), audio and video files, and so on, are managed in a central location: the MIME repository. With every newly created BSP application, a directory of the same name is created in the MIME repository and can be used as an archive for all application-specific MIMEs.

Web pages and MIME objects are integrated into the SAP correction and transport system as part of the BSP application, and as such are treated as a logical unit. In this way, all objects in a system landscape that affect a BSP application can be easily transported between SAP systems in a complete and consistent fashion. <%@page language="abap"%>  <html> <body> <table border=1>  <tr> <th>ISBN</th> <th>Title</th> <th>Publisher</th> </tr> <% data: wa like line of bsbook.  loop at bsbook into wa. %> <tr>  <td> <%= wa-ISBN %> </td> <td> <%= wa-title %> </td> <td> <%= wa-publisher %> </td> </tr> <% endloop. %> </table> </body> </html>

Figure 3.5: BSP Displaying a Table with Book Data

To ensure the strict separation of layout, interaction, and application logic, the BSP programming model supports the MVC design model. This means that alternative front-end technologies can easily be integrated.

3.4.1 BSP Extensions

The BSP programming model allows the development of easy-to-use, yet complex HTML pages. However, creating complex HTML code over and again is a tedious task during which many errors can occur. Complex elements in particular, such as table views or toolbars, are often reused but are hard to implement. In this instance, abstraction technology helps, which can easily express the syntax as well as the semantics of a particular line of HTML code. This abstraction technology is known as BSP extensions, which are basically specific tag libraries.

In principle, a tag library is a reusable extension of a predefined design language (such as HTML or WML). Developers can create their own tags (also known as custom tags) and use them in the page. In most cases, these tags are written to encapsulate rendering code. This has the advantage

that such a tag contains rendering code that presents a UI element, such as a button, in a company-wide design. So, page developers need not rethink design aspects over and again because they can use a custom tag. For example, developers of text tags determine the way the text tags are rendered once and for all. When properly written, text tags ideally provide rendering that it is browser-independent, thus guaranteeing their use regardless of the specific client they are later used on (such as Netscape, Internet Explorer, mobile devices). The set of parameters of a custom tag determines the interface between the developer of the tag and its users. A tag is represented internally by an object, either in Java or in ABAP objects.

The BSP extensions mechanism is structured in such a way that it can not only be used for HTML-based pages, but also for other pages (based on XML or WML, for example).

<%@page language="abap"%> <%@extension name="htmlb" prefix="htmlb"%> <htmlb:tableView id = "tvX"  headerText = "Books"  headerVisible = "true" design = "alternating" visibleRowCount = "8" fillUpEmptyRows = "true" table = "<%=bsbook%>" />

Figure 3.6: Extension Directive for the HTMLB Element “Table View”

A BSP extension groups together a number of BSP elements (tags). In the BSP context, each element is assigned to an ABAP class that contains the BSP element functions, including the generation of the HTML code. SAP delivers a number of predefined extensions, such as HTML Business for BSP (HTMLB), which can be implemented and are accessible in every SAP Web AS system. It is also possible for customers to define their own extensions for their own special requirements. These can be created in the BSP environment by using an editor integrated into the development environment (transaction SE80).

A BSP extension is included in a BSP page by using an extension directive (see figure 4.6). This extension is the interface of the custom tag which has to be maintained by the application developer.

The views of the People-Centric UI are implemented as BSP elements. Thus there are special BSP elements that either form the toolbar of the views, or display a list of objects, or form the tabstrip. Each view is made up of several BSP elements. The BSP element interfaces are filled by the controllers.

Using BSP extensions has the following advantages:

• Less complex BSP pages. The encapsuling of functions in BSP elements can greatly help reduce scripting in BSP pages.

• A BSP element can be used by any BSP page (that is, there is a single BSP element and it can be reused elsewhere). The standard XML syntax used can be parsed and checked during the BSP compile time.

• The HTML code generated contains correct references to the style sheets available.

• The element class can contain additional logic, in order to generate browser-dependent HTML code. In this way, the same layout is guaranteed with different


browser versions (Internet Explorer, Netscape Navigator, and so on). However the People-Centric UI only supports the Microsoft Internet Explorer.

• Clear role division: Developers define BSP extensions and implement the relevant element handler classes; designers use the BSP elements in the page layout of BSP applications.

• Tool support within ABAP workbench through the BSP extension editor.

3.4.2 Data Dictionary Services for BSP

The top priority for Data Dictionary (DDIC) Services is to make already existing meta information and definitions available for Web applications as well. Services are mainly Dictionary Services, which are based on the type properties of a data object. In a data-binding step, the DDIC information on data types, value ranges, or field length is taken over to the view. Furthermore, additional functions in general demand, such as the treatment of currencies and units of measure, are also provided.

More information is available in the documention SAP Web Application Server, Release 6.20 to be found under service.sap.com/technology → SAP Web Application Server.

3.4.3 Caching BSPs

Using the Internet server cache (also known as the ICM server cache) considerably increases performance and scalability. The ICM server cache offers dynamic and active content caching technology. The server resources necessary to produce BSP pages are reduced in this way. The repeated calling of frequently demanded BSPs is similarly avoided. This can lead to significant performance improvements.

3.5 References To HTML and BSP Training and Documentation

3.5.1 HTML

The layout section of a BSP consists of HTML elements and ABAP scripting. If you want to know how to build Web pages with HTML, try one of the following introductions:

• For a good introduction and an excellent reference for HTML, CSS, and so on, in German, see selfhtml.teamone.de.

• For a very good step-by-step HTML introduction in English, see www.w3schools.com/html/default.asp.

3.5.2 Business Server Pages

The Web Application Builder has been added to the SAP development environment (SE80) for building BSPs.

• The SAP Web AS 6.20 documentation in German or English provides an introduction to BSP technology and also includes an introduction to MVC in German or English, including a short tutorial (see help.sap.com).

• Additional information is available at the Roadrunner homepage: (see service.sap.com/roadrunner).

• There are also Virtual Classroom Sessions available as Business Server Pages Part 1-4, BSP extensions or MVC.


• Developers should start with the tutorials provided at the roadrunner homepage.

• For discussing all topics on SAP Web AS and BSP the newsgroup sap.technology.roadrunner [news://news.sap-ag.de /sap.technology.roadrunner] can be used.

• Classroom training (NET200) is also available from SAP University.

3.6 How Does the People-Centric User Interface Fit in with the Web Dynpro Concept?

3.6.1 Web Dynpro

The People-Centric UI implements a first version of SAP’s new UI technology called Web Dynpro. This is a highly declarative, tool-based programming model. It minimizes platform-dependent "plumbing" code for building UIs and maximizes declarative metadata describing huge portions of a typical application in a platform-independent way. The People-Centric UI uses blueprint tables to describe this metadata, but in the next version of Web Dynpro, which will be available with SAP Web AS 6.40 XML will be used. This implementation-independent description of the UI is the foundation for supporting several runtime environments and requires minimal effort on the part of the application developer.

The programming model Web Dynpro does not make strict assumptions about the client technology used. The current focus is on Web-based clients (Microsoft Internet Explorer and Netscape Communicator) as well as on small devices like Personal Digital Assistants (PDAs) (such as the Pocket PC or WAP mobile phones).

Special care has been taken to guarantee desktop-style interactivity for Web Dynpro applications, even though Web browsers like Microsoft Internet Explorer are used as client technology. This is achieved without requiring the application to do any client-side (for example JavaScript) programming. Instead, all dynamics are available through data binding (also a platform-independent and declarative method). With the next Web Dynpro version, a so-called Client-Side Framework (CSF) can be used on the client PC. It does not leave a footprint there, but it can use the client’s intelligence to save server roundtrips, do screen updates without a page reload, speed up the rendering, and so on.

3.6.2 BSP and Web Dynpro

Most of the BSP concepts and features fit neatly into the Web Dynpro programming model, even though BSP historically has followed a "bottom-up", programming-driven approach to Web development. Web Dynpro follows a "top-down" approach in order to consistently support multiple runtime platforms. There are several things that Web Dynpro and BSP have in common:

• Both models embrace the Model-View-Controller paradigm.

• The control set available with BSP Extensions is currently identical to the control set for Web Dynpro.

• Applications written according to either of the two models are equipped to run in the Enterprise Portal.

Unlike pure BSP or JSP programming, the People-Centric UI and Web Dynpro do not confront the application developer with the mark-up language actually used. Instead of taking HTML pages as a basis and trying to insert the UI logic into them, Web Dynpro focuses on the logic itself: The developer designs an abstract model of the user interface and then the Web Dynpro tools will generate the application from this model – tailored to the specific platform and mark-up. The


developer can augment the generated application with custom coding, which ensures that Web Dynpro is universally applicable for UI programming even in more exotic scenarios.

3.6.3 Moving the People-Centric UI to the Next Level of Web Dynpro

Thanks to the layered architecture of the People-Centric UI, the move to the next level of Web Dynpro is not difficult. We have already seen that:

• BSP is used only at the component level of the People-Centric UI, that is, the search request, search result, and detail views and their corresponding controllers were implemented in BSP, and so was the main controller that ties the others together.

• BSP is not visible at application development level, that is, the SAP application developer never comes into contact with BSP at all – all the application developer does is to supply the data and to fill out the blueprint tables.

The task of moving the People-Centric UI to the next level of Web Dynpro is therefore reduced to migrating a limited number of views and controllers. And just like there were only a small number of developers at work when it came to building the BSP parts of the UI, a similarly small number of developers will be involved in reimplementing this layer in Web Dynpro technology.

3.6.4 The Web Dynpro Integrated Development Environment

The Web Dynpro Integrated Development Environment (IDE) will offer built-in support for guaranteeing highly usable, consistent, and pattern-based UIs. Application developers will be able to choose from a library of typical interaction patterns (such as object selection, master, detail, or wizard), pre-built components (such as search area, result list, ODP)), or basic UI elements. All of these reusable patterns will be available within the IDE for application development and they will all be consistently supported by the Web Dynpro across all platforms.

3.6.5 Target Server Platforms for Web Dynpro

The target server platforms for Web Dynpro are Java 2 Platform, Enterprise Edition (J2EE), Microsoft .NET, and ABAP/BSP. The BSPs are a genuine Web Dynpro platform and form part of the Web Dynpro programming model within SAP Web AS.

For additional up-to-date information on the Web Dynpro, see the Web Dynpro homepage at webdynpro.wdf.sap-ag.de:1080.

3.7 Conclusion

Using the MVC design methodology and BSP extensions has many advantages for UI development. MVC helps to simplify the structure of the applications, allows dynamic structuring of pages from several views, and the implementation of complex visualization logic. It supports a strict separation of concerns so that the layout, the visualization logic, and the business logic can be maintained by different people. BSP extensions help to make the BSP pages less complex and it means that BSP elements can be reused by any BSP page. The use of this technology also brings a clear role division with developers defining BSP extensions and implementing the relevant classes to handle the elements and designers using the BSP elements in the page layout of BSP applications.


4 PEOPLE-CENTRIC USER INTERFACE DEVELOPMENT

4.1 Introduction

This chapter discusses in detail the development process for the People-Centric UI and is aimed specifically at application developers and technical consultants.

The UI framework simplifies Web implementation details for UI development and configuration. Thus ABAP application developers can concentrate on functionality rather than BSP or HTMLB.

Another benefit to SAP Development is the clear separation of tasks or development roles:

Application Developers

• Determine data fields and screen functions

• Determine field layout and search variants

• Maintain the Customizing tables (called blueprint tables)

• Develop the APIs by implementing interfaces for model access (building on ABAP)

UI Framework Developers

• Support blueprint table definitions

• Provide basic controllers and views

• Build on BSP, HTMLB, JavaScript, portal, and other Web technologies

Additional Controller Developers

• Develop additional controllers for the ODP

• Build on BSP, HTMLB, and JavaScript

Technical Consultants

• Customize screens via Customizing Tool (see section 6.2.2.1)

• Change existing implementations or build new ones within SAP IMG and ABAP Workbench

4.2 The SAP People-Centric User Interface Programming Model

4.2.1 Model-View-Controller

Due to the increased reliance of software products on Web browsers instead of proprietary clients, the Model-View-Controller (MVC) development approach and methodologies associated with it are undergoing a resurgence of interest within the developer community and software companies. A number of software companies have adopted MVC as a standard methodology for UI development. For example, Sun Microsystems is advocating use of its Model 2 software architecture, which is based on MVC for Java 2 developers, IBM supports several MVC Web frameworks through its cooperation with the Open Source community, and SAP's BSP framework is also MVC-based.

The following is an explanation of how the MVC pattern is used to break down programs into MVC object classes:


• The model is the representation of the logical structure of data in an application and the high-level class(es) associated with it. The model itself does not contain any information about the user interface.

• The view is made up of all classes that represent the elements of the user interface. All of the things that the user can see and respond to on the screen (buttons, display boxes, text, graphics, and so on) are part of the view in MVC.

• The controller consists of all the classes used to connect the model and the view. The controller is used for communications between classes in the model and the view.

Still, there are more concrete reasons for SAP to commit to the MVC development approach than just to follow industry trends. Historically – with the problems and restrictions associated with thin clients – Web browsers have proven to be tough target platforms for application developers. Programmers have been forced to work around the limitations of the browser as a client platform and the result is often lacking in functionality compared to the classical client-server applications. However, Web applications are almost always simpler, cleaner, and consequently easier to use by an untrained or occasional user. The simplicity and limitations of Web browsers and the stateless nature of HTTP protocol have essentially forced designers and programmers to pay much more attention to the usability of the UI. Also, a functionality gap between Web browsers and thick clients had to be bridged – in the past this was often achieved by breaking down complex functions into a series of simpler functions suitable for Web browsers. Therefore, the limitations of Web browsers are at least partly one of the reasons why Web applications are simple to use and why Web interfaces have smaller but more consistent sets of UI elements.

It is also true of Web applications that hundreds and sometimes thousands of different "views" are required to produce applications comparable in functionality to classical client-server applications. MVC has become the predominant pattern used in Web development. This is due to its ability to speed up development through greater reuse of existing elements, and because it places some constraints on developers (through a set of predefined view elements and controller classes that connect views to the model). This in turn ensures consistency in the resulting UI. The UI architecture and resulting framework have been created with these principles in mind.

Additionally, we seek to address the specific concerns of CRM development:

• Typical CRM users generally have less time to get accustomed to and learn new applications (or new application versions)

• Typical CRM users often have less experience and expertise than users of applications in other fields

For example, it is reasonable to expect that users of document processing tools will, with time, acquire expertise in their tools of choice and that this will allow them to develop their own ways of using the tool, its macros, and advanced features. For this type of user, simplicity may become an obstacle once they are sufficiently advanced as users. However, the needs of CRM application users are different: They are more likely to go through all the steps of even the most repetitive tasks as they refer to different customers (data). The need for a consistent UI is also exaggerated by the fact that most CRM users (be they interaction center personnel, sales consultants, and so on) will either have limited training time (due to mobility, high staffing turnovers) or will simply be expected to fulfill their role at very short notice (especially in the US where CRM employees in sales support and interaction centers are very likely to be temps).

The solution to the issues specific to CRM development at SAP are fully addressed by SAP's pattern-oriented UI framework. Limited numbers of controllers and a set of reusable view components (that facilitate SAP BSPs and the associated HTMLB technology) require every CRM application or module to be refactored or redesigned with the goal of a simple, consistent UI in mind.


4.2.2 The User Interface Framework

From its inception, SAP CRM has been designed and engineered in a multi-layer model, allowing for a clear separation of tasks. The BSP-based UI framework extends this model and only user-interface and interaction-layer components had to be added to support the additional Web UI. This can be demonstrated by comparing the layered business transaction model already known from the generic CRM order with the new MVC-based UI framework: The view corresponds to the UI layer of the business transaction layer model. The controller and the model correspond roughly to the interaction layer and the API in the object layer of business transaction model.

User InterfaceDynpro

Interaction LayerFlow logic and field selection control

Object LayerApplication logic

API (defined methods)

PUT_DATA API GET_DATA_APIGET_DATA API

GET MethodPUT Method

Figure 4.1: The Business Transaction Layer Model from the Generic CRM Order

The interaction layer controls the flow of any business transaction. Based on the user inputs (field modifications, function keys, and so on), it controls which methods of an object are performed (Fcode control), which objects are to be displayed or modified, or which elements of the corresponding UI are to be activated (dynpro or field control).

The purpose of the interaction layers is to enable any screen, that is, the graphical user interface (GUI), to communicate with the interaction layer through defined interfaces, without having to bother about data acquisition or even the processing of this data each time, but concentrating instead on the visualization alone.

The UI framework is built on the MVC programming model and implemented in two layers of controllers. One main controller (C0) controls several subcontrollers (C1, C2 and so on – these controllers are "nested" within the main controller). These controllers communicate over the generic interface of the interaction layer with the model. The business objects also provide a generic interface to the interaction layer. These generic interfaces are the model access layer.

The main controller is responsible for all the communications that occur between subcontrollers and subcontrollers and the main controller itself. The main controller instantiates all subcontrollers depending on the configuration stored in the configuration tables (blueprint tables) and it controls them throughout their life cycle. Subcontrollers are responsible only for the generation of the view that corresponds to their configuration (also stored in the blueprint tables) and for supplying data to the views from the model and vice versa.


Controller ModelView

User InputD

isplay

ControllerC1

ControllerC2

ControllerC3

Main Controller C0

Blueprint Tables

Interaction Layer

Pattern-Based

Search Area View

Result ListView

Detail Area View

QUERY

READ...

Model A

ccess Layer

ProductMaster

Account

Customer Order

Figure 4.2: UI framework

The main controller receives all the requests from the user. User requests are made from the Web browser via the portal and contain two or more additional parameters within the requesting URL:

• APPL, which defines the application

• BLVIEW, which defines the selected blueprint view on the transaction

• Specific parameters (optional), like OBJECTID

The main controller reads the URL and its attributes from incoming requests. With this information the main controller can obtain relevant customization data from the blueprint tables. The blueprint tables contain information that defines the setup of the view and the methods for the access of the business data. With the view setup information available, the main controller invokes the subcontrollers, for example, C1, C2, and C3. All controllers communicate with the model over the interaction layer (API) to get the necessary business data and objects for building up their respective views. With the data from the model, the subcontrollers can generate the views by using BSP elements.

• C1 is the search request controller and it builds the search area view.

• C2 is the search result controller and it builds the result list view.

• C3 is the detail controller and it builds the ODP view.

The complete page is assembled by the main controller from all the views generated by the subcontrollers and is then sent back to the browser as a response.

In order to address customer-specific UI requirements, an additional customizing layer is available for blueprint tables. This is described in section 4.3.2.12.

Definitions

• The UI framework connects the business logic to the UI with the configuration information from blueprint tables.

• Blueprint applications are applications built by Customizing the blueprint tables of the new UI framework.

• Blueprint tables are tables that contain all the configuration information required by the new UI framework to specify the application UI (Web-based).


• The interaction layer provides controllers with one single interface across all business objects.

• Model access classes give standard interfaces to business objects which, in conjunction with the configuration information contained in blueprint tables, connect the UI to the business logic.

4.2.2.1 Patterns and Controllers

Main interaction patterns in CRM have been explored and discovered through usability and UI studies (relative to the desired CRM application functions) at SAP. A limited set of patterns has been identified as sufficient templates for most CRM applications. On the top level, these interaction patterns (see also chapter 2) are built out of three types of areas:

• Search area

• Result list

• ODP

Each of these areas is implemented by:

• One or more controllers

• BSP elements (HTMLB extensions and extensions developed by CRM) that comprise the views

The search area contains the search and the advanced search functionality. The corresponding search result is displayed in the result list. These two areas are used for searching, identifying, and selecting data (such as records) from the application. The search area is implemented by the search request controller and the result list by the search result controller

The ODP contains the details of the selected object (focus) in the result list or the parent ODP (one record). The ODP can be implemented by the detail controller, for example, and as such it consists of a tabstrip, a toolbar, and the data (in a list as a hierarchical tree or as a form view).

Consequently, the following controllers have been developed for the new UI framework:

• Search request (including advanced search)

• Search result

• Detail

The model in this solution is represented by an interface that the developer creates to encapsulate ABAP business logic in a specific, homogenized API layer.


C1: Search Request ControllerV1: Search Area View

C2: Search Result ControllerV2: Result List View

Text

C3: Detail Controller

V3: Detail Area View

Field1Field2

Search

C0 Main Controller

Search Area

Result List

Detail Area

Advanced Search

Toolbar

ToolbarTabstrip

Figure 4.3: Page Outline Provided by the UI Framework

The detailed UI framework implementation depicted in the figure above is supported by the SAP Usability Engineering Center guidelines governing the layout of all pages in the applications. Put simply, this MVC-based framework is a consequence of the pattern-based design and limits the possibilities of screen layout. All transactions have three page-outline elements in common:

• Search request

• Search result

• Detail

User interface components (such as the toolbar, tabstrip, or field groups) are customized within separate blueprint tables. Thus every aspect of page layout can be defined by configuration of controllers through blueprint tables.

Available Controllers

The following is a list of the controllers available in the UI framework:

• Main controller

• Search request controller

• Search result controller

• Detail controller

• Application log

• F4 help

• Multi controller

• Content management

• Hierarchy/tree


• Survey tool

• Text processing

• HTML viewer

• Address

• Document preview

To ensure a consistent layout, further controllers may not be added without special permission from the person responsible for the UI design. All of the controllers mentioned above can be found in ABAP Workbench.

Figure 4.4: UI Framework Controllers in ABAP Workbench

4.2.3 Navigation Concept

The People-Centric UI is completely portal-based. This means that SAP EP is the single point of access to all capabilities of the SAP solution as well as to external sources of information or to other applications. When the user starts the application, first a general overview page is displayed from the portal. From there the user can access the different capabilities of the SAP application via the first-level navigation bar of the portal. The second-level navigation bar then offers access to the different applications or transactions. For example, the CRM key capability Sales has the applications Quotations, Orders, Contracts, and so on. These applications run as iViews inside the portal. The number and type of applications shown to a user depends on the portal role of that particular user.


Lower-level navigation is supported by the blueprint application itself. The user can scroll lists, switch between different tabs, and toggle between different views. Additionally, object link navigation is offered, allowing the user to jump directly via a hyperlink from one object in an application to the application that actually handles that particular object. For example, in the Sales Orders application, if the user selects Ship-To Party, the Account Management application is started with the detailed data of the Ship-To Party.

Basically navigation and session management is based on a multi-window scenario. This means that every time the user has not saved data that has been changed and navigates to another application a new window is opened. In this new window, a second session with the selected application is displayed. However if there are multiple windows open on the client the locks of the objects are not dequeued. If an object is locked from one application and an additional application inside an additional window is launched, the object is still locked.

4.2.3.1 Atomic Navigation Scenarios

Several atomic navigation scenarios are important for understanding the user's perspective of session management. The main question covered here is:

If the user navigates anywhere from the current application and thus leaves the current context or page what happens to the user's current data if he or she changed it and leaves the page without saving that data?

To give a clear impression of the various scenarios, the following subheaders are used in the ensuing scenario descriptions:

Description

This paragraph contains a short description of the scenario.

Scenario

This paragraph describes a concrete scenario.

Behavior

What happens if data was changed, and what happens if no data was changed?

4.2.3.1.1 Explorative Object Link Navigation

Description

An explorative object link is a link to a more detailed view of an existing object (object creation is handled separately), for example, from the list of customers to the detailed view of one customer. An object link could be published inside a blueprint application or somewhere else, like in Java iViews.

Scenario

The user selects a hyperlink that points to a task.

Behavior

If the user selects an object link on an overview page (Java iView), the new object is launched in the same window.

If the user is on a blueprint application, changes some data without saving and uses object-link navigation, this always leads to a new window. Without enhanced session management everytime the uses navigates via object link navigation a new window is opened. Both cases allow the user to navigate back to an earlier screen.


Figure 4.5: Explorative Object Link

4.2.3.1.2 Portal Menu Navigation

Description

The user tries to leave the current transaction via the portal menu navigation, represented by the top-level menu bar.

Scenario

The user navigates via the portal navigation bar from Activity Management to Contact Persons.

Behavior

If the current data has been changed, the new object is launched in a new window. Otherwise the new object replaces the current object in the same window.

Figure 4.6: Portal Menu Navigation

4.2.3.1.3 Back Navigation

Description

Navigation by using the Back and Forward buttons. This works only in the same browser window.

Scenario

The user presses the back button of the browser and navigates to the previous pages in the same window.

Behavior

While navigating through the portal, the user sometimes decides to go back to a previous screen. From the perspective of the browser, all these screens are ordered into a history that can be traversed by using the Back and Forward buttons in the navigation bar of the browser. Without


enhanced session management, the UI framework does not provide an application history. This leads to the following scenarios:

• Internal navigations, like changing a tabstrip, are eliminated from the browser's history by JavaScript. Thus, back navigation to this status is not possible.

• If the user navigates to another screen by object link a new browser window is opened. Therefore, back navigation with the browser button is not possible.

Figure 4.7: Navigation with the Back and Forward Buttons in the Browser

In the Microsoft Internet Explorer, navigation by history works in every open browser window, that is, the history is up-to-date in every window.

In the UI framework without enhanced session management, the application history is implemented by using a multi-window scenario. This means every object link opens a new browser window that displays the requested content. If the user wants to go back, he or she just has to switch to the original window.

With the enhanced session management application back within the same browser window is supported. The user gets back to earlier sessions with the selected application, view, tab etc.

4.2.3.1.4 URL Navigation

Description

The user types a new URL string into the address bar of the browser.

Scenario

The user is editing an activity when he or she decides to type a URL, Google for example, in the address bar.

Behavior

The current session in the browser window is closed as the user leaves the current application.

4.2.3.1.5 Close Browser

Description

The user closes the browser.

Scenario

The user closes the browser while editing an activity.

Behavior

The current session in the browser window is closed as the user leaves the current application.


4.2.3.1.6 Object Deletion

Object deletion occurs inside the blueprint application and is not relevant for session management and navigation.

4.2.3.1.7 Creating a New Object

There are different kinds of object creation. The scenario depends on the relationship of the object to be created with other (parent) objects.

• Creating a new object of the current type occurs inside the blueprint application and is not relevant for session management and navigation (see section 5.3.1).

• Creating a new object in a list of child objects occurs inside the blueprint application and is not relevant for session management and navigation. For example, creation of a new order item in the list of items within the sales order form.

• Creating a new reference object of a master object in a list. This object is related to a list of other master objects. If such an object has to be added, navigation to its main blueprint application is necessary to fill in the required initial data. For example, creating and adding a new partner or a new opportunity to a business partner. The user chooses the Create button that leads (navigates) to another blueprint application (hosted on another portal page) dealing with the new object type. If the current object is in an unsaved state, a new browser window will be opened.

4.2.4 Session Management and Locking

Traditionally, because of the stateless nature of HTTP, locking has been a complicated issue when implemented over the Web. A typical HTTP communication works as follows:

• A client makes a request to the Web server application. The server replies with a response.

• The same client makes a new request. Without additional state persistency services, the server does not know what request was made previously by the same client or what state the client was left in.

The stateless nature of HTTP makes locking challenging. However, the UI framework runs statefully and this is handled by SAP Web Application Server (SAP Web AS). The session is held and the data is buffered on the server. The browser participates in the session by receiving and sending a session ID as a URL parameter.

The UI framework has abstracted the implementation details for locking, which makes it easy for application developers. In the following list READ, MODIFY, and so on, are model access class methods, which are described in detail in following sections.

General Rules for Locking:

• Locking is performed at READ and not at MODIFY (pessimistic locking), otherwise it could be that two users edit the same object and the changes made by one of them are lost.

• Locking is based on the selected object (focus object).

• Dependent objects of a root object are completely locked if the root object is in focus, for example items of a sales order. This is the default locking mechanism: in the result list only the focus object is locked and in the ODP all dependent objects are locked.


• If associated objects are displayed in a ODP, for example Activities in the Opportunity application, only the focus object is locked. This locking mechanism has to be maintained in blueprint table CRMC_ACCESS.

• The QUERY method does not lock anything.

• No locking is performed when the READ method is called to populate the search result list. If the user selects one object, this object is locked.

• When an object is selected, the READ method is called again with the selected key and an indicator that this object should be locked.

• If an object cannot be locked, this needs to be considered when the application fills the field attribute table (return parameter of the READ method). All fields of the screen structure have to be marked as protected (other attributes, like "hidden", may also be used of course).

• The unlock of an object is triggered from the AFTER_SAVE method via the INITIALIZATION method. The framework sets SET UPDATE TASK LOCAL to prepare change mode for the same object after SAVE.

The best practice for locking is to keep the amount of data locked as discrete as possible and for the shortest time possible, in order to avoid contention. Therefore, locks are set only when needed and only when an object is selected.

When the user changes the selection, the formerly selected object needs to be unlocked. This is handled by the data-loss method of the framework:

• When selected object data has been manipulated by the user, objects are registered for saving.

• Subsequently, if the user chooses a different object before saving, the data-loss dialog will appear to warn the user of the potential loss of the changes:

- If the user chooses Save, then the SAVE and the AFTER_SAVE methods will be called. The initialization of the AFTER_SAVE method calls the internal unlock method.

- If the user chooses Do Not Save, then initialization is performed via the AFTER_SAVE method.

• The next call of the READ method uses a newly selected key for locking.

If the user navigates from a locked object to the referring application, the source object has to be unlocked because the target application needs to lock the object.

4.3 How to Develop Blueprint Applications

The People-Centric UI is built on a generic framework. Thus, there are only two steps to be performed to develop an application with this UI:

• The views of the applications have to be customized via the blueprint tables.

• A class with special methods has to be implemented inside the model in order to access the business data


4.3.1 Development Environment of the User Interface Framework

SAP developers are already familiar with the SAP development environment and ABAP Workbench. The new UI framework is based on BSP, which is new to at least some of the ABAP developers. However, the BSP framework has been integrated into ABAP Workbench since SAP Web AS 6.10 so that developers can take the full advantage of the SAP integrated development environment both for ABAP- and BSP-related work. ABAP Workbench (SE80) is used by the framework developers to implement the UI framework. Application developers and technical consultants use the Class Builder (SE24) which is integrated in ABAP Workbench for developing model access classes.

Figure 4.8: Class Builder in ABAP Workbench

The maintenance of the blueprint tables is done within separate maintenance transactions. These are CRMC_BLUEPRINT for SAP product development and CRMC_BLUEPRINT_C for customer developments. Tasks that are required for the completion of a blueprint application are listed sequentially from top to bottom. The transactions offer a consistency check for the blueprint table entries. Incorrect entries are detected and can be easily corrected.

Transaction CRMC_BLUEPRINT_C works on the Customizing layer of the blueprint tables because the standard UI delivered by SAP must not be modified.

The transactions are intended to develop new UIs. The Customizing Tool is provided for modifying existing UIs (see section 6.2.2.1).

Both transactions can be accessed in SAP Customizing (also in SAP IMG → Customer Relationship Management → Layout of User Interface (People-Centric UI)).


Figure 4.9: Transaction CRMC_BLUEPRINT for the Maintenance of Blueprint Tables

4.3.2 Maintaining Blueprint Tables

The blueprint tables denote the schema to configure the UI. They contain the descriptive data that automates and controls the UI. Information about every screen is kept in these tables and the application uses the data from them to construct and build Web pages. Developers and customers alike are able to customize the metadata to control various aspects of the application. It is important to understand how to maintain these tables because this is the first of the two development steps.

This section describes how developers maintain blueprint tables.

4.3.2.1 The Main Blueprint Table

The main blueprint table (CRMC_BLUEPRINT)drives the whole UI – when the application is requested by the browser, the main controller first looks into the main blueprint table, which is where the basic parameters of the application have been set. The entries in the main blueprint


table also determine which blueprint subtables are relevant for the setup of the current screen. Thus the main blueprint table is the basic blueprint for the design of an application.

Field Comment

APPLICATION (Key) Transaction

BLVIEW (Key) Role-dependent view, Blueprint View

EVENT (Key) Event

POSITION (Key) Screen positions

SCREEN VARIANT (Key) Display variant

ELEMENT Type of view

FIELD GROUP Using field groups

TOOLBAR GROUP Adding toolbars

TAB GROUP Adding tabstrips

SEARCH GROUP Search tables

DOCUCLASS Class for documentation

ID FOR DOCUMENTS AND RELATIONS Object ID of documentation

STRUCTURE NAME Linking screen structures

Figure 4.10: The Main Blueprint Table

The blueprint table key consists of five columns:

• Application is used to identify the transaction.

• BLView defines the blueprint view on an application (optional). With this, a different layout of a screen can be assigned to different roles.

• Event identifies the action of the application and is similar to the function codes (Fcodes).

• Screen Positions identifies the positions that make up the whole screen.

• Screen Variant is an optional feature that provides techniques to handle special conditions.

View and Screen Variant are advanced topics that will be discussed later on (sections 4.3.2.10 and 4.3.2.11).

The application and event are passed to the main controller as URL parameters and are used to retrieve blueprint records and ultimately to create or change the view. An example of an application is Sales Contract (SLS_CONTRACT). The INIT event is used to define the screen on startup and is necessary to paint the view. Other events are triggered by the buttons on the toolbar, or tabs in the tabstrip. The events that change the view content and the layout of the screen are handled by the application framework. This is ultimately performed by additional blueprint records that we will see later on. There are also other events that require custom actions and these events can be handled by implementing a method within the model access class.

Besides INIT there is another generic event. If the screen should be newly built up after the focus is changed from one object to another in the search result list, the event CHANGE_FOCUS_SRES


has to be maintained in the blueprint tables. This is useful, for example, to change the toolbar in a mixed list of objects, depending on the selected object.

Screen positions are predefined areas of the view. There are up to five positions on the screen and they all have designated content according to the following positions and content rules:

• Search request is mandatory in position 1.

• Search result (in list or tree display) is mandatory in position 2.

• Detail (in form or list view) is allowed only in positions 3, 4, and 5.

• The navigation events popin, popup, and new window, are also handled as specific screen positions.

The screen type defines the subcontroller, which provides the view. The main controller calls a set of subcontrollers to build the view.

An example of the value range of the screen type:

• FIND – search request

• RESULTS LIST – search result list or RESULTS LIST AS HIERARCHY – search result tree

• LIST or FORM – detail view, where the data is displayed in a list toggle functionality to form view, or data is displayed only in a form without toggle

• Additional: content management (CMAN), survey tool (SURV), text management (TEXT), HTML viewer (HTML), address (ADDR), segment builder (SEGA), form preview (PREV), hierarchy (TREE). Additional work may be necessary if the data has to be displayed in one of these views.

The next data fields maintain several relationships (defined by foreign keys) to other blueprint tables. Finally, the columns Document Class and Object ID define the location of the documentation for the application (for details see section 5.1.2).

To create initial blueprint records, it is necessary to define the application in the main blueprint table, for example SLS_CONTRACT. After that, the records for the INIT event have to be created for this application. Values have to be entered for at least three screen positions. The initial blueprint table should end up with something like this:

Application … Event Position Screen Variant

Element …

SLS_CONTRACT INIT 1 Search Request

SLS_CONTRACT INIT 2 Search Result

SLS_CONTRACT INIT 3 List

Figure 4.11: Excerpt from Blueprint Table (Table CRMC_BLUEPRINT)

Now the general setup of the screen is defined. However, concrete content (such as fields and labels) and the way this looks on the screen is still missing. This is included in the next steps:

1. Linking screen structures

2. Using field groups

3. Defining search groups

4. Adding toolbars


5. Adding tabstrips

6. Maintaining application sets

4.3.2.2 Linking Screen Structures

Screen structures are the data dictionary (DDIC) structures used to exchange data between the business application and the user interface. A DDIC structure containing the fields to be displayed or maintained on the screen must be created. This structure is used for communication between the controllers and the model (see model access class methods, section 4.3.3.2). The structure may be filled from one or multiple database tables or objects in the interface. The structure name of the screen structure has to be added to the field group entity table, where it is linked to a field group. The field group and the screen structure are linked to the application in the main blueprint table.

The screen structure is simply a flat DDIC structure including several fields. The definition as to how these DDIC fields are displayed on the screen is maintained in the field groups. More than one field group can be maintained for one screen structure.

With the new entries the blueprint tables look like this:

Application Event Position Element Field Group

COMM_BP INIT 1 SREQ BP_SEARCH

COMM_BP INIT 2 SRES BP_LIST

COMM_BP INIT 3 LIST BP_DETAIL

Figure 4.12: Excerpt from the Main Blueprint Table (Table CRMC_BLUEPRINT)

Field Group Description Structure Name

BP_SEARCH Search account DDIC_SEARCH

BP_LIST Result list account DDIC_LIST

BP_DETAIL Address details DDIC_DETAIL

Figure 4.13: Excerpt from the Field Group Entity Table (Table CRMC_FIELDGRE)

4.3.2.3 Using Field Groups

Field groups affect the way the data is presented in the view. The table CRMC_FIELDGRP defines how the fields of the screen structure are displayed. The following elements can be defined, for example:

• Sequences of the fields on the screen

• Display attributes (like hidden, dropdown list box, and so on)

• Grouping of fields

• Frames


A field group has to be set up and linked to a screen structure in the field group entity table (CRMC_FIELDGRE). In the field group table it has to be defined how the fields of the screen structure (DDIC structure) are displayed on the view.

Field Group View Screen Position

... Field Name Field Type

Not List

... Not changeable

BP_DETAIL 1 Field1 of DDIC_detail TXTF X

BP_DETAIL 2 Field2 of DDIC_detail TXTF

BP_DETAIL 3 Field3 of DDIC_detail INPF X

Figure 4.14: Excerpt from the Field Group Table (Table CRMC_FIELDGRP)

The key consists of FIELD GROUP, VIEW, and SCREEN POSITION. Only the sequence can be defined, not the specific location of the fields. That is done by the layout generator based on an algorithm from the SAP Usability Engineering Center to ensure the consistency of the layout. This generated layout can be adopted to customer-specific needs using Customizing Tool (see section 6.2.2.1).There are several attributes for the fields in the field group table (CRMC_FIELDGRP) like FIELD TYPE, MANDATORY, NOT CHANGEABLE, NOT LIST, NOT DETAIL and so on (see Figure 4.14). NOT LIST defines whether a field is hidden in the list view, NOT DETAIL in the form view. The text field is “read only” every time. However the FIELD TYPE input field can be set to “read only” by setting an X at NOT CHANGEABLE. The customer can activate fields that have been deactivated via standard Customizing. The application can also override the field attributes at runtime. There should be at least one record in the field group table for each DDIC field. Otherwise the field will not be displayed (this would be the same as if the field was defined as "hidden"). Note: Entering a field type is mandatory.

The attributes of the fields can be defined role-dependently in group tables, like the field group table with the parameter view. Whenever the field group is maintained view-specifically, the whole group is read only with this view, as usually the view differs from the standard.

The field name has to be filled according to the screen structure (DDIC).

FIELD TYPE defines what kind of field it is: text field (TXTF), input field (INPF), checkbox item (CBIT), image (IMAG), dropdown list box (DDLB) ), Time-Combobox(TIME), Combobox(COBX), and radio button group (RBGR). Currently there is no difference between field type Combobox and Time-Combobox.

It is possible to reuse screen structures. This means that the same screen structure can have several field groups. With this technique it is possible to use one screen structure for several tabs or views. Each tab or view has its own field group and the display of the fields is regulated by the hidden attribute.


Field Group Field Name Not List Field Group Field Name Not List

CON_DTL1 FIELD1 X CON_DTL2 FIELD1

CON_DTL1 FIELD2 CON_DTL2 FIELD2 X

CON_DTL1 FIELD3

CON_DTL2 FIELD3 X

The blueprint table:

Application Event Position Screen Variant

Element Field Group Structure Name

COMM_BP TAB1 3 FORM CON_DTL1 DDIC_01

COMM_BP TAB2 3 FORM CON_DTL2 DDIC_01

Figure 4.15: Example of the Reuse of Screen Structures

In this example, there are two field groups, CON_DTL1 and CON_DTL2, for one screen structure DDIC_01. The first field group will display FIELD1 of the screen structure, while the second field group will display both FIELD2 and FIELD3.

The use of one screen structure for more than one tab is recommended when the data is similar and a customer would probably like to see it on one tab and other tabs can be switched off. Developers should be aware of the fact that the size of a structure could affect performance because the structure will be filled completely by the application.

There are many customizable attributes that can be assigned to each field (see Figure 4.16):

Display Attributes Descriptions

FIELDGROUP (KEY) Name of the field group

VIEW (KEY) Role-dependent blueprint view for UI display

SCREEN POSITION (KEY) Numeric key field that identifies the sequential position

Field Group Variant (KEY) Variant of field group

REFERENCE GROUP A recursive foreign key used to nest subfield groups

GROUP TYPE The style of the reference group: screen group (SCGR), checkbox group (CBGR), field-melting (FMLT), logical group (LOGG), and include group (INCL)

FIELD NAME The field name has to be filled in according to the screen structure (DDIC)

FIELD TYPE Type of field: text field (TXTF), input field (INPF), checkbox item (CBIT), image (IMAG) or dropdown list box (DDLB), Combobox (COBX), Time-Combobox (TIME) and radio button group (RBGR)

NOT LIST If checked "X", field is hidden in the list view, the customer can activate fields that are deactivated in the standard Customizing table

NOT DETAIL If checked "X", field is hidden in the form view

NOT CHANGEABLE If checked "X", then the input field is “read only”

MANDATORY FIELD If checked "X", it is mandatory to maintain the field upon creation of new objects

F4 APPLICATION Application that will be displayed in a separate OIP as F4 help (see


section 5.1.3)

NO LABELS If checked "X", no label will be displayed

DEFAULT VALUE The initial value of the field

DOMAIN VALUES If checked "X", and field type DDLB or COBX or TIME domain values are displayed for selection

FIELDNAME → CRM OBJECT TYPE

Contains field name for field containing CRM object type

FLD NAME CONTAINS BOR TYPE

If checked "X", object type is BOR (and not special CRM object type)

CRM OBJECT TYPE CRM object type for navigation

CRM METHODS CRM application for navigation target

FIELD → CRM OBJECT ID Contains field name for field containing CRM OBJECTID

UNLOCK OBJECT Unlocks focus object (and displays data-loss popup) at navigation event

SORTED If checked "X", list is initially sorted by this column

NEW LINE If checked "X", this field is displayed in a new line

REQUEST (server call) (4.0) Initiation of server roundtrip at DDLB, COBX, TIME and fields with F4 help and input fields which belonging screen structure field is of data type date, when data is changed (4.0)

FIELDNAME → BOR OBJECT

Field name, which contains BOR object type to define appropriate application for F4 help dynamically at runtime (see section 5.1.3)

HEIGHT_DETAIL Used to set row span in detail screen for text field and image

LENGTH_DETAIL Used to set column span for text field and image

URL_KIND Defines the type of hyperlink used for the text field

OWN_NAV_FIELD Navigation field

TOOLTIPFIELDNAME Field name for the tool tops, see accessibility (5.3.5)

MASS_UPDATABLE (5.0) If checked “X”, this field can be mass updated

MASS_UPDFIELDGRP (5.0) If the field can be mass updated, it may be desired that several dependent fields should be updated together. They should be defined in a field group and refer its name here.

LENGTH_LIST Tailoring the width of the field in a list

EVENT Rendering a link for raising an event if pressed

Figure 4.16: Field Properties in the Field Group Table

The attributes for form view and list view are collected in one table. However there are attributes that influence only the list view, and others that influence only the form view. Just the key fields Field Name, View, and Screen Position are parameters for both display variants. The field name has to be filled in according to the screen structure (defined in DDIC). The screen position is a numeric field and has an impact on the sequence of the fields. However it does not define the final position of the field on the screen because this is performed by an algorithm provided by the SAP Usability Engineering Center. The lower numbers are displayed first.

4.3.2.3.1 Parameters for List and Form View

The following field group parameters influence list and form view:


• Field type is mandatory. Image and radio button group is not possible in list view! The text field is “read only” every time. However the field type input field can be set “read only” by setting an X. The content of the field types radio button group, dropdown list box, and combobox (COBX respectively TIME) is taken from the fixed domain values of the DDIC field. The title of the group is the label from the DDIC field, for example, gender with the domain values female and male. Radio buttons are recommended when there are only a few entries to be selected – otherwise the dropdown list box is to be used.

• Mandatory fields are rendered with a small red star on the browser but there is no check from the framework if the field is filled out or not. The complete logic to check if all required fields are filled out has to be done by the application. Fields which are marked as mandatory will be checked by the browser. If the user has not filled all mandatory fields, a popup appears, that forces the user to fill out all mandatory fields before processing further actions. Although it is possible to set a field as mandatory during runtime via the READ method the check on the browser is only executed for the customized fields. Any further check coding has to be provided by the application.

• Domain values are only relevant for dropdown list box, combobox (COBX respectively TIME), and radio button group – content will be filled with the fixed values of the domain.

• Default values that should appear when creating a new object are defined in this field.

• F4 APPLICATION has to be filled with the name of an application of the main blueprint table if the OIP of this application is to be presented as advanced F4 help (for details see section 5.1.3)

• If the user navigates via the object link from an object to the maintenance application of the same object, he or she may lock the object in the source application and thus cannot modify it in the target application. To unlock the object at object link navigation, choose Data-loss popup and unlock in the column UNLOCK OBJECT. To unlock the object the event DISPLAY is given to the model in the PROCESS_EVENT method. The application has to ensure that at the next call of the READ method the object is displayed as “read-only”.

• It is possible to write a URL as a link in a text field or to add a hyperlink to a text field. If the URL, for example http://www.sap.com, should be displayed directly in a text field, only the type of the URL has to be specified (URL_KIND). It is possible to display http, https or mailto links. If the link doesn`t start with “http”, “https” or “mailto” the framework automatically adds “http” or “mailto” corresponding to the URL type. However it is also possible to fill the text field with a description which points to the URL. Then the field of the screen structure, which contains the URL, has to be specified at FIELD → CRM OBJECT ID. The framework doesn´t check, if the URL is correctly working!

• REQUEST has only to be set, if the application uses dropdown list boxes or comboboxes (COBX respectively TIME) or F4 help or input fields which belonging screen structure field is of data type date. Then it is necessary to initiate a server roundtrip, if the application wants to react to the event of selection in a dropdown list box or a selection respectively a value change in a combobox or a call of F4 help or a selction from the value help respectively a value change in an input field which belonging screen structure field is of data type date. For example if the application wants to define the F4 help at runtime or if different fields should be changeable in dependence of the selected item in the dropdown list box. If the change in the combobox or in the input field of “data type” date takes place manually (without the use of the corresponding value help) the roundtrip will be triggered after the particular field loses the focus.


• EVENT (Event) - here you can maintain a value from the “event table” (CRMC_BSP_EVENT). If there is an entry and the field is of type input field or text field the content will be rendered as a link. The link has a tool tip which corresponds to the particular event description. If this link will be clicked an event will be fired that can be handled by the PROCESS_EVENT method of the target application (see section 4.3.3.2). If such a link will be clicked no focus change takes place. If you use this approach for triggering an event you can do without introducing an additional button to fire the event.

The object link navigation uses the fields Field name → CRM Object Type (URL_FIELDNAMEOT), Fld Name contains BOR Type (URL_FNOTISBOR), CRM Object Type (URL_OBJECTTYPE), CRM Methods (URL_METHOD)and Field → CRM Object ID (URL_FIELDNAMEID). These fields have to be maintained if the user is to be able to navigate via hyperlink from the current field to another application with the object as parameter. For a detailed description of object link navigation see section 4.3.4.

4.3.2.3.2 Parameters Only for List Display

The following field group parameters influence list view:

• NOT LIST and NOT DETAIL define whether a field is hidden in the list view or in the form view. It is recommended to display a maximum of ten columns in one list, because the list has to fit in a full-screen window.

• If the list to be displayed has to be sorted by one or more columns, SORTED has to be set in the corresponding fields.

• The fields displayed in the list view in the search area are also used for the dropdown list box at the Get search.

• LENGTH_LIST (Column Width) can influence the column width. For describing this parameter first we have to talk about list rendering behaviour in general. In the personalization dialog of a list (accessible by pressing the link Personalize in the right corner above the list header) you can change the list rendering to Adjust Column Width to Text Length. With this adjustment a list column will be rendered dependant on the current content – the width is determined by the length of the column header text respectively by the data length. If the content contains some special characters (space, ...) it also can be shown in multiple lines. Dependant on the amount of columns and the column content it may happen that horizontal scrolling will be necessary. But in default mode (the above mentioned personalization is not active) all columns will be relatively scaled to the current browser width. There will be no horizontal scrolling! (If you minimize the browser at a certain degree you will get scrollbars – but not in the normal mode.) Also there will be no rendering in multi line – all cell content (if it contains special characters or not) will be put in one line. Dependant on the DDIC length respectively on the column header length – but just up to a maximum value of 20 - of all visible columns and the current browser width the particular column width will be determined. E.g. a table with three columns, columnX-length = min(20,max(DDIC/header)) = 5, columnY-length = min(20,max(DDIC/header)) = 15, columnZ-length = min(20,max(DDIC/header)) = 20

columnX spans 12,5%, columnY spans 37,5% and columnZ spans 50% of the current browser width. If the content (either header or data) is longer than the column itself the content will be shown at the cell end with omission marks (…). The omission marks only will be shown in view mode – not in edit mode! Be aware that if there are too much columns visible or some column length is very


large (i.e. customized – see next section) it may happen that all columns or some of them are rendered so small that no content is visible. Now we come to the meaning of the field LENGTH_LIST (Column Width): If the default rendering mode is active and if this field contains an entry not equal to 0 this value will be used instead of min(20/max(DDIC/header)) (see above). Be aware that the “real” width will also be scaled relatively dependant on all other visible columns and the current browser width – as described above.

4.3.2.3.3 Parameters Only for Form Display

The following field group parameters influence form view:

• REFERENCE GROUP and GROUP TYPE are explained in detail on the following pages.

• Language-dependent titles for SCREEN GROUP and CHECKBOX GROUP are maintained in a special text table: CRMC_FIELDGRP_T. The key is the language and the field group.

• NO LABELS hides the label of a field. The field is displayed without a label. This is recommended at field-melting.

• NEW LINE guarantees that a new line starts with that field. A line feedback is done before displaying the field.

• HEIGHT DETAIL and LENGTH DETAIL define the size of the field in the form view. It is only for the field types image or text field. Normally it should not be filled! The parameter LENGTH DETAIL is used for the fields, melted within a field melting group. The parameter defines the ratio of the field within the length of the field melting.

4.3.2.3.4 Reference Groups

In addition to the direct definition of the field group, a generic field group definition (reference group) can also be referenced. This simplifies, for example, the definition of the homogeneous display of address structures or the combination of specific fields like currency and value.

To reference a group, a field group that contains the fields to be combined can be defined. This is the reference group. After that, the name of this field group is entered into the reference group field (of the field group defined in the main blueprint table). In the field group type it has to be defined how the reference group should be displayed. This could be screen group (SCGR), logical group (LOGG), field-melting (FMLT) or checkbox group (CBGR). A screen group generates a frame around several fields with a title.

• A “logical group” defines fields which logically belong together, so that they should be displayed next to each other (for example, contract start and end date).

• A “field-melting” group melts fields together in one column (for example, value and currency).

• A “checkbox group” consists of a title and some fields with checkboxes.

• An “include group” just combines fields without any additional layout effect.

Note:

The fields of the reference group have to be fields of the screen structure as well.


SCGR

FMLT

Grouptype

City

Name2

Name1

Currency

Value

SoldTo

Number

Field Name

03Address

02Address

01Address

02Ord_Value

01Ord_Value

Address04Order

Ord_Value03Order

02Order

01Order

Referencegroup

Screen Position

Field Group

SCGR

FMLT

Grouptype

City

Name2

Name1

Currency

Value

SoldTo

Number

Field Name

03Address

02Address

01Address

02Ord_Value

01Ord_Value

Address04Order

Ord_Value03Order

02Order

01Order

Referencegroup

Screen Position

Field Group

Number 4711

Sold-ToBach

Value1000 Eur

Name1 Name2 CityNorbert Nackendick Heidelberg

Group Ord_Value with Grouptype Melting Group

Group Address with Grouptype Screengroup

Figure 4.17: Example of Referencing Field Groups

For usability reasons, it is not permitted to use screen groups within another group. Exception: other groups can be used in the logical group.

Radio buttons are not a group type! A radio button group can be declared in the field type attribute of the field group table. The label is taken from the corresponding DDIC field, values come from domain fixed values.

Entity tables, containing the objects with a description, are available for all entities of the blueprint tables. In the field group entity table (CRMC_FIELDGRE) some additional information is stored. The structure name of the main blueprint table is linked to the referring field group.

If fields are hidden at runtime there is usually an empty space in their place. If the empty space has to be eliminated and the field layout needs to be compressed, this has to be switched on at COMPRESSION YES/NO. If COMPRESSION YES is selected, CRM Designer cannot be used to modify the layout of this field group.

4.3.2.3.5 Layout Generation and Layout Table for Form Display

The arrangement of the fields on the screen is determined automatically by a layout generator based on the information of the field group table. This arrangement is stored in the layout table. For SAP Developers a documentation of the layout algorithm is available at http://bis.wdf.sap-ag.de:1080/usability/data/Pattern/Library/S_LayoutgenerationSpec.doc.

Some hints for maintaining the field group to get a smart layout are:

• Use layout control mechanisms sparingly (e.g. the New_Line attribute) since they may create additional work during the final layouting.Use Screen Groups (Grouptype: SCGR) whenever you have more than 4 fields to display. When you group elements using screen group boxes, we can distribute your controls more harmonically on the screen. The group box visual design makes it easier for users to scan and interpret formsTry to form screen groups of about the same size. Group boxes with about an equal number of elements can be arranged side by side. This makes the screen look more harmonious and easier to interpret.Use the Length_Detail attribute to shorten the


field‘s visible length if the usual content is not too long.If the user‘s standard sequence of actions allows this, arrange long elements at the beginning or end of the form. Long elements (long fields, logical groups) often disrupt the standard column layout, so we place only one of them per row. It just looks best if they appear at the beginning or end of the screen group.

• Use Field Melting Groups (Grouptype: FMLT, e.g. for currency fields) for better clarity and screen space usage. Trying to change the layout algorithm is time consuming. In customer projects, the layout table can be changed both manually and with the Customizing Tool (see section 6.2.2.1).

4.3.2.4 Defining Search Groups

Search groups are used to provide users in the advanced search with multiple queries. For example it is possible to search for All accounts by address and by contact person. The fields offered by the queries are different. The search group defines the content of the shuffler boxes (combined selection, Search/by) in the advanced search area. The "fast-entry" query (Get) displays all the fields of the screen structure of the search request for selection.

The search group does not influence the fields for the fast search (Get queries). The fields for the dropdown list box, displayed in the fast search, are taken from the screen structure of the search area at event INIT. The fields that are not hidden in the field group are ordered alphabetically and displayed automatically at the Get search.

Search groups are defined in CRMC_BL_SEARCH and are only allowed for screen type search request (SREQ). It is mandatory to maintain a search group with at least one Show/By combination! Although the shuffler box should not be displayed, the search group still has to be maintained. With one combination of Show/By the shuffler is not displayed. Use INIT as the event in this case.

ACC_001

Search Group

DDIC_2

DDIC_1

Structure Name

SRES

SREQ

Screen Type

FieldGroup

...

2INITCOMM_ACC

1 INITCOMM_ACC

Screen Variant

Event PositionApplica-tion

ACC_001

Search Group

DDIC_2

DDIC_1

Structure Name

SRES

SREQ

Screen Type

FieldGroup

...

2INITCOMM_ACC

1 INITCOMM_ACC

Screen Variant

Event PositionApplica-tion

Data Source

ACC_All

ACC_All

Show

ACC_Contact

ACC_Address

Event

CON_ContactACC_01

CON_AddressACC_01

By Search Group Data Source

ACC_All

ACC_All

Show

ACC_Contact

ACC_Address

Event

CON_ContactACC_01

CON_AddressACC_01

By Search Group

All Accounts

Description

ACC_All

Show

All Accounts

Description

ACC_All

Show

AdressACC_Address

Contact Person

Description

ACC_Contact

By

AdressACC_Address

Contact Person

Description

ACC_Contact

By

Figure 4.18: Example for Search Group (Table CRMC_BL_SEARCH)

In the main blueprint table a search group has to be entered at screen position 1. The field has to be initial for all other screen positions of the main blueprint table. For usability reasons it is recommended that only one search group is used. The table CRMC_BL_SEARCH defines the search group. The keys are SEARCH GROUP, SHOW, and BY. SHOW and BY represent the fields that could be chosen by the user for the query. Their descriptions/titles are maintained in the tables


CRMC_BL_SHOW and CRMC_BL_BY. There are additional text tables CRMC_BL_SHOW_T and CRMC_BL_BY_T for the purpose of translation into other languages.

The events used within the search group also have to be declared in the main blueprint table CRMC_BLUEPRINT and in the events entity table CRMC_BSP_EVENT. Do not use the event INIT for the show/by combinations, because then the complete page is set the the initial state, especially selection of tabs in ODP are reset.

Applications can maintain another attribute: data source. Data source tells the application, from which source the data for the query has to be taken, for example from the CRM database or from an archive. Data source is a key, defined in table CRMC_BL_SOURCE, that is passed from the framework to the model. The application interprets the key and takes the appropriate data source.

4.3.2.5 Adding Tabstrips

Tabstrips can only be added to the detail view. They are always positioned above the toolbar. The table for tabstrips is CRMC_REGTABGRP, which defines the sequence of tabs and the events that the tabs will raise. The tabstrip must first be defined within this table and then linked to the main blueprint table.

The tab group table:

Tab Group Sequence Event Selection Group

OPP_ODC1 01 INIT

OPP_ODC1 02 OPP_TAB1

OPP_ODC1 03 OPP_TAB2



Screen Type

Tab Group Structure Name

COMM_BP INIT 1 SREQ DDIC_search

COMM_BP INIT 2 SRES DDIC_list

COMM_BP INIT 3 LIST OPP_ODC1 DDIC_ detail

COMM_BP OPP_TAB1 3 FORM OPP_ODC1 DDIC_detail_01

COMM_BP OPP_TAB2 3 LIST OPP_ODC1 DDIC_detail_02

Figure 4.19: Example of Tabstrip Records (Table CRMC_REGTABGRP)

Each click on a tab raises an event. Therefore, two additional blueprint records have to be created that are used to handle the new events OPP_TAB1 and OPP_TAB2. If the OPP_TAB1 or OPP_TAB2 event is triggered, then the ODP in position 3 will change and will use the data structure DDIC_DETAIL_01 or DDIC_DETAIL_02, respectively. The register tab group table also has a text table (CRMC_REGTABGRP_T) for the maintenance of language-dependent tab titles. INIT must not be used as an event in TOOLBARGROUP or REGTABGROUP, because the whole screen is then built up again. An event must be unique in one application.


To minimize the number of tabstrips, a so-called viewswitch is offered. This means that within one tab, multiple views are available and can be selected from a dropdown list in the toolbar. This viewswitch works in the same way as the tabs on a lower level. A viewswitch should be used for similar content, for example: Instead of using the three tabs Competitor Address, Competitor Products and Competitor Strategy, they can be combined to one viewswitch OPP_Competitor with the fields address, products, and strategy in the dropdown list box in the toolbar. The dropdown list box only appears if the viewswitch tab is active. To build a viewswitch, several tabs have to be combined to a viewswitch group.

Tab Group Sequence Event Selection Group

… … …

OPP_ODC1 04 Comp_Address OPP_Competitor

OPP_ODC1 05 Comp_Products OPP_Competitor

OPP_ODC1 06 Comp_Strategy OPP_Competitor

Figure 4.20: Example of Viewswitch (Table CRMC_REGTABGRP)

4.3.2.6 Adding Toolbars

The appearance of the toolbar in the result list view and the ODP is defined by a toolbar group.

The table for toolbar groups is CRMC_TOOLBARGR, which defines the sequence of buttons and the events that the buttons will raise. The toolbar must first be defined within this table and then linked to the main blueprint table.

The toolbar group table:

Toolbar Group Sequence Event Text (from text table)

Enhanced Display

Event Group (4.0)

Parent Event (5.0)

PRD_ODC1 01 PRD_COND Create

PRD_ODC1 02 PRD_CONTR Check X

PRD_ODC1 03 PRINT_LIST Print



Screen Type

Toolbar Group

Structure Name

CRMM_PRODUCT_SALES INIT 1 SREQ DDIC_search

CRMM_PRODUCT_SALES INIT 2 SRES DDIC_ist

CRMM_PRODUCT_SALES INIT 3 LIST PRD_ODC1 DDIC_ detail

CRMM_PRODUCT_SALES PRD_COND 3 FORM PRD_ODC1 DDIC_detail_01

CRMM_PRODUCT_SALES PRD_CONTR 3 LIST PRD_ODC1 DDIC_detail_02

Figure 4.21: Example of Toolbar Records (Table CRMC_TOOLBARGR)


Now two additional blueprint records have to be created, which are used to handle the new events PRD_COND and PRD_TEXT. In this case, if the PRD_COND or PRD_CONTR event is triggered, then the ODP in position 3 will change and will use the data structure DDIC_DETAIL_01 or DDIC_DETAIL_02, respectively. The toolbar group table has to be maintained for all events supported by the application. The toolbar group table has also a text table (CRMC_TOOLBARGR_T) for language-dependent maintenance of the names of the events (buttons). The text is displayed in the text column of the entity table CRMC_BSP_EVENT, where every event has to be listed.

Some events like PRINT, CREATE, or SAVE are handled directly by the framework. For example for a button to print a list only, one button with the event PRINT_LIST has to be maintained in table CRMC_TOOLBARGR. No entries in the entity table or text table are necessary. If the user selects the Print button, a document preview window appears for printing (see section 5.2.12). It works in a similar manner for the other generic events.

In 5.0, the framework also provides support for mass change of list or tree component (for tree component, it only works in list view). If application want to use this feature, the event MASS_UPDATE need to be maintained in toolbar event customizing table. And the mass updatable fields need to be customized in field group customizing table (see section 4.3.2.3.2).

Event Usage F4 Application

… Navigation Event Unlock Object

Text

ACC_EBPP Functionally relevant

… ACCEBPP No Data-loss popup

Biller direct

ACC_TAB1 Layout relevant No Data-loss popup

Partners

FUP_OPP Functionally relevant

… CREATE_FOLLOWUP Data-loss popup and unlock

Generate Opportunity

Figure 4.22: Example of Events (Table CRMC_BSP_EVENT)

Toolbar events can be handled by the model access class method PROCESS_EVENT (see section 4.3.3) or can link to another blueprint application. The link to other blueprint applications is used to create follow up objects, for example. The link to another blueprint application is a standard object link and has to be defined by the parameters Field name → CRM Object Type (URL_FIELDNAMEOT), Fld Name contains BOR Type (URL_FNOTISBOR), CRM Object Type (URL_OBJECTTYPE), CRM Methods (URL_METHOD)and Field → CRM Object ID (URL_FIELDNAMEID). In addition it has to be declared, how the session management works. There are three possibilities for the parameter Unlock Object:

• No data-loss popup

• Data-loss popup and unlock

• Data-loss popup and no unlock

For further details on session management see section 4.2.4.

The framework enables an event to be raised after navigation to the target application. This is a navigation event. Then the PROCESS_EVENT method of the target application is called and can provide additional functionality.

The toolbar is expandable. This means that, initially, only a few buttons are displayed. The others appear if the user expands the toolbar. It can be defined whether a toolbar event is part of the expandable toolbar or not via the Enhanced Display flag.

To reduce the number of different buttons, the event group (CRMC_EVENTGRE) is being introduced. Several toolbar events can be summarized into one event group. In the toolbar, the event group is displayed as one button, where the label (description) is maintained language-dependently in the


text table CRMC_EVENTGRE_T. If the user selects this event group button, a popup appears and offers the toolbar event of the event group. It is also possible to decide at runtime which toolbar events should be displayed in the event group. Then the Dynamic Events checkbox has to checked with X. If the user selects the event group button, the method FILL_EVENTGROUP from the model is called to fill the selection of toolbar events dynamically (see section 4.3.3).

In 5.0, we can use popup menu to group several toolbar events into one toolbar popup-trigger button. It has more flexibility to group events into multi-hierarchy menus, and can be used side by side with old way of using popup window for backward compatibility.

For static case (the contents of popup menu can be decided at design time), we can use the newly introduced Parent Event attribute.

Toolbar Group

Sequence Event Text (from text table)

Enhanced Display

Event Group (4.0)

Parent Event (5.0)

PRD_ODC1 … …

PRD_ODC1 11 PRD_DL Download

PRD_ODC1 12 PRD_DL_CSV As CSV PRD_DL

PRD_ODC1 13 PRD_DL_XML As XML PRD_DL

For the configurations as above example, on toolbar, there will be one popup-trigger button (which may looks different than normal button) corresponding the PRD_DL event. Clicking it will show a popup menu with menu items corresponding to PRD_DL_CSV and PRD_DL_XML events. If required, we can use Parent Event recursively to implement multi-level menus.

For dynamic case, we still need to use the Event Group field as before. But in event group customizing table (CRMC_EVENTGRE), we introduce a new field Popup Trigger (POPUP). If this checkbox is checked with X, the corresponding button will be rendered as popup-trigger button (either it is a Dynamic event group or not); thus when user click it, a popup menu will be shown instead of a popup window. It can be used together with Parent Event field, so in popup menu, some menu items can be dynamic (returned by method FILL_EVENTGROUP from the model), some can be static (defined in toolbar event customizing table). It can also be used in submenus.

4.3.2.7 Multigroup – List and Form Within one View

Sometimes it is required that separate fields and one or more tables must be shown together within one ODP. Examples are:

• In Sales and Service, the table with pricing conditions and some header attributes (for example, the net value)

• In Sales and Service, dates as a table (together with other fields)

• In Opportunity, activity plan and sales assistant

• In Service Contracts, billing data as form fields (together with billing plan as a table)

Therefore using the special multi-controller multiple instances of the ODP views can be placed within one ODP. This means that it is possible to mix form and list views. To unify several views in one ODP a multigroup has to be maintained in table CRMC_MULTIGRP. Because the different views are displayed one below the other, SEQUENCE defines the position of the view. EVENT refers to the main blueprint table, where the configuration of the views is defined.

The multigroup is called when in the main blueprint table the screen type multigroup (MULT) is assigned to an event. The corresponding multigroup is found via the Tab Group.


Application Event Screen

Position Screen type Field Group Tabstrip

COMM_BP MultiEvent 3 Mult Tabgrp01

COMM_BP Accont 3 Form ACC_DET

COMM_BP Opport 3 List OPP_DET

Figure 4.23: Multigroup in Main Blueprint Table (Table CRMC_BLUEPRINT)

Tab Group Sequence Event Multigroup

Tabgrp01 1 MultiEvent M_Address

Tabgrp01 2 Tab2

Tabgrp01 3 Tab3

Figure 4.24: Multigroup in Tab Group Table (Table CRMC_REGTABGRP)

Multigroup View Sequence

Position Event Table Width

M_Address 1 Accont 1/1

M_Address 2 Opport ½

Figure 4.25: Example of Multigroup (Table CRMC_MULTIGRP)

In the multigroup view the component list has its own toolbar. In case of toolbar events, the method PROCESS_EVENT from the application will be called, but only after all data from all controllers has been transported to the application via the MODIFY method (see section 4.3.3).

In 5.0, it is possible to display two views side-by-side. For two consecutive entry (their Sequence value can be same, but not required) in multigroup customizing table, the first one can have Position field value 1st Position, the second one can have Position field value 2nd Position, then these two views will be displayed side by side.

Either it is taken the whole row or displayed with another views side-by-side, for example form and list, the width of the component can be specified. The allowed values are 1/3, 1/2, 2/3, 1. If a list does not use the full width of the screen, there will be no toggle button to get the form view of the table.

The different instances of the subcontrollers are independent of each other and there will be no communication between these instances via the framework. If anything is needed here, this has to be done by the application in the model access class.

4.3.2.8 Working with Application Sets

In general, an application as described in this section is a UI-oriented concept that can be compared, for example, to a SAP R/3 transaction. To ease reuse of various screen elements (such as fields, toolbars, search scenarios, and so on) across various applications, the concept of “application sets” has been introduced. The application set also provides access to the model. The application set is the interface between several UIs and the business logic of one major business object.


Application 3

Application SetToolbars

Tabstrips

Events

Searchgrp

Model

Application 2

Application 1

Figure 4.26: Structure of an Application Set

An application set refers to one major business object (for example product or opportunity) and contains all building blocks necessary for the construction of applications dealing with this object.. From each of these application sets, various applications can be build.

It is obvious that applications like Quotations and Orders use very similar screen structures, toolbar groups, and so on. If each application were to maintain its own screen elements, the whole system could become quite complex. Therefore it makes sense to collect reusable screen elements within so-called application sets.

For this reason UI components have to be assigned to an application set. These are:

• Toolbar (in table CRMC_TLBARAPP)

• Tabstrip (in table CRMC_RGTABAPP)

• Search scenario (in table CRMC_SEARCAPP)

• Screen structure (in table CRMC_ACCESS)

To create a new application, the new application is assigned to an application set in table CRMC_BL_APPL and is then combined out of several elements of the chosen application set. This allows especially the reuse of screen structures and their coupling to the appropriate model access class, which is done in table CRMC_ACCESS. The table for screen structures is CRMC_ACCESS that defines the connection between the UI and the business logic for each screen structure. This connection works via a model access class. This is a concrete class that contains several standardized methods for data access. These methods provide data for one or more screen structures (see section 4.3.2). In principle it is possible to have a separate model access class for each combination of application set and screen structure, but it is recommended that only one model access class is used for each application set.

4.3.2.9 Object Dependencies Across Screen Structures

Often the data displayed via multiple screen structures is dependent from each other. For example sales orders are displayed in the result list and the depending positions of the orders are displayed in the ODP. These relationships affect the locking mechanism.


Application Set

Structure Name Access Class Structure Type Reference Name

Parent Structure Name

ACCOUNT BP_search CL_CRM_MAC_ACC Search Structure

ACCOUNT BP_result CL_CRM_MAC_ACC Root BP_root

ACCOUNT BP_detail CL_CRM_MAC_ACC Dependent BP_root

ACCOUNT BP_activity CL_CRM_MAC_ACC Main Act BP_root

ACCOUNT BP_trans_detail CL_CRM_MAC_ACC Dependent Act

Figure 4.27: Example of Screen Structures (Table CRMC_ACCESS)

In addition to the model access, some attributes of the screen structure have to be maintained in CRMC_ACCESS. Especially for locking (see section 4.2.4) the framework needs to know about the relations between the screen structures and how they interact with each other.

• Each structure is classified as root, main, dependent or search structure. As a consequence no structure can be used as root and main within the same application set.

• Each structure has an ”alias” name (reference name). The reason is that it is possible to have several root structures, that is, they will be used to display different data in the search result. The reference name has been introduced to have a unique parent structure.

• Each root and primary structure must have the reference name as an attribute.

• Each structure (except the root and search structure) has a parent structure and this is the reference name of the real parent structure.

The screen structure of the search area is always a search structure. The screen structure of the result list is always a root structure, as it is the starting point, which other screen structures are related to. The screen structures of the ODPs can be dependent from the screen structure above them. Or they are the starting point of further relations. Then they are a main structure. This means they refer to the root structure and they can have dependent structures. Main structures are not dependent on root structures. For the consequences of these attributes on the locking mechanisms, see section 4.2.4.

In the example (Figure 4.27) business partners are displayed in the result list. ODP 1 presents additional detail data to each business partner, for example different addresses. The data is dependent on the referring business partner. In ODP 2, activities independent objects concerning the business partner are listed. Details depending on the selected activity are displayed in ODP 3.

4.3.2.10 Blueprint View

The field BLVIEW of the main blueprint table defines special views of the application screen and is used to maintain the role-dependency of the applications. One view can be used for several roles (see section 6.2.1). So the blueprint tables can be maintained in a role-specific manner, for example with SLS_MANAGR for a sales manager (see naming conventions, section 4.4.5). The parameter will be set from the portal, when the application is called via URL. As the nodes in the portal menu are always related to one role, the parameter will be set as unique, even when the user has multiple roles. In this case, it can happen that a user has multiple menu entries for one object – one for each role.

4.3.2.11 Screen Variant

Screen variant is a key field of the main blueprint table. It makes it possible to have different screen designs for the same event (that is, application equal, event equal, and screen position equal, but different variant). It is used in special cases. For example, in the ODP a customer address should


be displayed with different fields, depending on whether the customer is a company or a private person. Therefore two screen variants are used.

To define a different layout of the fields, the field group variant can be used.

The application can define the current variant, which should be displayed, at runtime. The methods GET_VARIANT and GET_FIELDGROUP_VARIANT are called from the framework to obtain the necessary information (see section 4.3.3).

4.3.2.12 Tailoring Blueprint Tables to Customer-Specific Needs

The blueprint tables CRMC_BLUEPRINT, CRMC_FIELDGRP, CRMC_REGTABGRP, CRMC_TOOLBARGR have development class S (System). These tables contain the UI delivered by SAP. For customer modifications, there is an additional Customizing layer of blueprint tables that is client-specific and has development class C (Customizing).

There are additional tables for BLVIEWS, with classes S and C. The model access table CRMC_ACCESS is not view-dependent and has class E. Class E means that extensions and modifications are only allowed in the customer name space.

If one entry group exists in the C table of the toolbar group and tabstrip group, the S-table is not used for this group. So deactivation of tabs or events is possible in Customizing.

In the C-table of the field group table entries for single fields of a field group are possible. The other field(s) in the group will be read from the S-table.

Customers maintain the blueprint tables via the Customizing Tool (see section 6.2.2.1).

4.3.3 Model Access Class Development

The UI framework uses standardized interfaces to access the business model. The business logic should already exist and must be separate from the UI. The interfaces define abstract methods to access existing business objects in a homogeneous manner. Application developers are required to develop model access classes by implementing the interface IF_CRM_BSP_MODEL_ACCESS_IL. The model access class is a concrete class and will not provide any business functionality but rather the data mapping routines and general access to business functionality. In other words, the model access class serves as a wrapper around all existing business objects. Via an interaction layer the controllers invoke methods of the model access class to communicate with the business logic. Note that this communication is one-way, that is, the UI controllers will initiate method calls and not the model.

In general the controllers call the interaction layer of the UI framework, which gets the application data from the model access classes. The interaction layer (CL_CRM_BSP_IL) is one single service interface to all CRM business objects. It provides generic methods like QUERY, READ or MODIFY to access the business logic. The interfaces of the model access class methods are very similar. The interaction layer dispatches the calls from the controllers to the relevant model access class. The general QUERY and READ methods (and so on) of the interaction layer call the corresponding special methods of the model access classes. The information about which model access class has to be called for which screen structure is stored in the blueprint table CRMC_ACCESS.

The framework also provides a generic data context class for data management. The data context class buffers the application data and is responsible for data binding between the UI and the back end. Thus the tags which build the view get the data from the data context class and write them back there. Type checks are also performed in the data context class.


Controller

Data Context

Class

Interaction Layer

(CL_CRM_BSP_IL)Model Access

ClassREAD

MODIFY

...

Model Access Class

READ

MODIFY

...

Model Access Class

READ

MODIFY

...

Model Access Class

READ

MODIFY

...

Model Access Class

READ

MODIFY

...

Model Access Class

READ

MODIFY

...

READ

MODIFY

SAVE

QUERY

...

DispatcherData Management Access to Business Objects

Transactional Methods, like SAVE, INITIALIZE

Data Access Methods, like READ, MODIFY

One single Service Interface to all Business Objects

Figure 4.28: Accessing Business Logic Within the UI Framework

Usually one application has one model access class for all screen structures entered in the blueprint table. If an application consists of several different object types, the different object types could have their own model access classes. However it is recommended to create one master model access class that delegates to the other model access classes. For example, the application Account Management displays the object Business Partner, but also Activities, Conditions, and Addresses.

Account Management

Business Partner

Conditions

Activities

Addresses

Business Partner 3

Business Partner 1

Business Partner 2

Model Access Class

Model Access Classes forComponents of theModel

Figure 4.29: Structure of the Model Access Classes for Complex Models

The master model access class is responsible for:


• Collecting the messages from all screen parts.

• Locking all screen parts consistently. If the result list could not be locked, all the screen parts should be set as "read only".

• Delegating to other access classes in the right sequence, taking care of dependencies, saving sequence, and so on.This method also eases the reuse of other object types by just integrating the corresponding model access class.

Basically the model access class implements the interface IF_CRM_BSP_MODEL_ACCESS_IL:

IF_CRM_BSP_MODEL_ACCESS_IL

Method Description

QUERY Start search

READ Read data

READ_FOCUS_OBJECT Read data of focus object for ODP

MODIFY Change data

CHECK_BEFORE_DELETE Check whether delete is possible

DELETE Delete object

AFTER_ROLLBACK_DELETE Reset changes in internal buffers after unsuccessful delete

PROCESS_EVENT Event execution

GET_MESSAGES Read error messages

GET_VARIANT Read screen variants

GET_FIELDGROUP_VARIANT Read field group variants

CHECK_ACTIVE_TOOLBAR Read active push buttons

CHECK_ACTIVE_TABSTRIP Read active tab pages

CHECK_ACTIVE_MULTIGROUP (4.0) Read active subcontroller

CHECK_ACTIVE_STEPS Read active steps for guided data entry

CHECK_ACTIVE_VIEWSETGROUP Read active viewsets

CHANGE_FOCUS Changes focus

FILL_DROPDOWN_LISTBOX Read dropdown list box values

CONVERT_TO_BOR Determine BOR parameter from OBJECTID

CONVERT_FROM_BOR Determine OBJECTID from BOR parameter

GET_MY_FAVORITES Determine favorites

FILL_EVENTGROUP (4.0) Read dynamic events

SET_URL_PARAMETER Set URL parameters for events

IS_OBJECT_IN_CREATE_MODE Checks, if root object is created

GET_ALLOWED_DDLB_VALUES Fills dropdown list box in dependence of object key

SET_SELECTED_STEP_ID Sets id of selected step for guided data entry

SET_SELECTED_PROCESS_ID Sets id of selected process for guided data entry


CHECK_ACTIVE_SHUFFLER Check active shuffler entry

GET_PARENT_OBJECT_KEY Determine Higher-Level Object Key

Figure 4.30: Interface for the Model Access Class

The methods of the model access class have different tasks. On the one hand there are methods for data access and data modification like QUERY, READ, MODIFY, CHECK_BEFORE_DELETE, DELETE, AFTER_ROLLBACK_DELETE, GET_MESSAGES and PROCESS_EVENT. On the other hand there are methods for the dynamic modification of the screen like GET_VARIANT, CHECK_ACTIVE_TOOLBAR, CHECK_ACTIVE_TABSTRIP, and FILL_DROPDOWN_LISTBOX. CONVERT_TO_BOR and CONVERT_FROM_BOR are conversion methods that are needed for the management of the displayed favorites.

To set up a screen, the main controller calls the subcontrollers twice. In the first run the business data is collected; in the second run the layout of the views is generated. In each run, the corresponding methods of the model access class are called by the UI framework:

First Run: Data Supply – the Main Controller Calls Subcontrollers in the Following Sequence:

1. Search request controller, the GET_MY_FAVORITES method of the model access class is called. Afterwards the QUERY method is called.

2. Search result controller, first the READ method is called without locking to get the search result list. The READ method is called again for the focus object with locking.

3. Application log controller, which calls the GET_MESSAGES method to access the messages.

4. Detail controller, which calls the READ method. If detail view is a form, the READ method is called with locking. If detail view is a list, the READ method is first called without locking and then the READ_FOCUS_OBJECT method is called for the focus object.

Second Run: Layout Generation – the Main Controller Calls Subcontrollers Which Build Their Views in the Following Sequence:

1. Application log controller

2. Search request controller

3. Search result controller, CHECK_ACTIVE_TOOLBAR, and GET_FIELDGROUP_VARIANT are called

4. Main controller calls GET_VARIANT for detail view

5. Detail controller, which calls CHECK_ACTIVE_TABSTRIP, CHECK_ACTIVE_TOOLBAR and GET_FIELDGROUP_VARIANT

The following parameters have almost all of the methods of the interface in common:

• Screen structure In the UI framework, data from the business logic is communicated in the form of DDIC structures. The names of the DDIC structures are referenced in the blueprint table. These DDIC structures are called screen structures, because they define the fields that are displayed on the screen. It is the responsibility of the model access class to map data into the fields of the screen structure. The methods of the model access class normally need the name of the screen structure for creating objects of that data type at runtime. In addition, values are given to the methods via the screen


structure itself. In the interfaces, this field is type "any" because the data type of the screen structure is known by the controller only at runtime.

• Object key Each structure must have an object key to identify the unique instance. Furthermore, it must be the first field in the structure and the field name is CRMT_BSP_OBJECTKEY. The object key is a 100-character field that can contain a globally unique identifier (GUID) or any other unique identifier, like a concatenated logical key. The conversion of the application key to object key must be done by the application in a central routine. If the object is a BOR object and the structure is used for the search area, the key should be according to the definition in BOR. The explanation below shows how each method (QUERY, READ, and MODIFY) interacts with the object key.

- QUERY Returns a list of object keys identified in the search request

- READ The object keys are passed to the READ method and subsequently used to retrieve business data in DDIC structures (screen structures)

- MODIFY Will return object keys where the module failed

4.3.3.1 Mapping

The fields of the application's business objects have to be mapped inside the model access class to the screen structure displayed on the view. At the end of mapping, a BADI has to be provided for extensions for each model access class (more than one implementation should be possible). Also use move-corresponding whenever possible.

In general, the ABAP context (SE33) buffers every database access for about 2 to 3 hours. Using a buffer increases performance, especially if data that is often read from the database is buffered. Therefore it is recommended to use the context CRMCT_REPORT_COL2TXT for buffering language-dependent descriptions for technical keys.

DATA: lv_context_text TYPE context_crmct_report_col2txt. ... SUPPLY value = lv_value langu = lv_langu structname = lv_objwrkname component = ls_map_itf-obj_field TO CONTEXT lv_context_text. DEMAND text_found = <itf_value> FROM CONTEXT lv_context_text.

Figure 4.31: Coding Example for Using Context in Function Group CRM_INTLAY_DATA Function Module CRM_INTLAY_SINGLE_GET_DATA (Lines 178-185)

It is recommended to collect all mapping functionality for an object within one method. The technical keys and the description must also be filled into the screen structure. Type conversion and conversion exits will be triggered from the underlying BSP framework.


4.3.3.2 Model Access Class IF_CRM_BSP_MODEL_ACCESS_IL Methods

The methods QUERY, READ, MODIFY, and GET_MESSAGES are mandatory for implementation. The implementation of the other methods depends on the requirements of the application.

QUERY

Parameter Type Description

IV_SCREEN_STRUCTURE_NAME Importing Name of the DDIC structure

IS_SCREEN_STRUCTURE Importing DDIC structure used for advanced searches

IV_SEARCH_ID Importing Concatenation of Search and by for the predefined searches

ET_OBJECT_KEY Exporting List of keys of the results returned to C1 controller (search request)

Figure 4.32: Interface of QUERY Method

The QUERY method is called by the search request controller. It passes the search criteria to the model and gets the object IDs of the results. At simple Search (fast entry search) the corresponding field of the screen structure is filled with the search attribute. At Advanced Search with the Search/by shuffler the Search and the By values are concatenated and transferred via the IV_SEARCH_ID. The screen structure contains the search criteria. The QUERY method returns a list of object keys of the selected objects. The query result, which is presented to the user is limited to 100 hits. If the search result exceeds this number a message appears (CRM_BSP_FRAME 010). If the user does not enter any search criteria in search fields, every object should be selected. It is not necessary to enter * in the search field (neither in the simple nor in the advanced search).

To provide additional functionality (personalization/customizing of the query result) there is the method IF_CRM_BSP_MODEL_ACCESS_IL_2~QUERY (pay attention to the _2 at the end of the interface name). In contrast to IF_CRM_BSP_MODEL_ACCESS_IL~QUERY there is an additional parameter:


IV_SEARCH_MAXHITS Importing Limit Value for the query result

The maximum value of hits which should be returned by the application and presented to the user is provided in the parameter IV_SEARCH_MAXHITS.

This value will be determined either by user personalization or by customizing on application level or by a default value. The personalization is available in the settings dialog (accessible by pressing the link Settings in the search area of the application). There you can provide an appropriate value in the input field with the label Specify Maximum Number of Search Results. The customizing (in table CRMC_BL_APPL) is available by transaction CRMC_BLUEPRINT Application/Layout and double clicking the concerning application. There you can maintain a value for Search Limit Value. If neither a personalization nor a customizing is available a default value of 100 will be used.

If the search result exceeds the current number a message (CRM_BSP_FRAME 017) exists, that can be used by the application. This message accepts one parameter for the current valid threshold value.


READ


IV_LOCK Importing The lock indicator, Boolean type

IT_OBJECT_KEY Importing List of keys needed to map data into the screen structure

IV_SCREEN_STRUCTURE_NAME Importing Name of the DDIC structure needed to be filled

ET_SCREEN_STRUCTURE Exporting Table of objects referring to the imported keys

ET_FIELD_ATTRIBUTE Exporting Parameter to control display attributes at runtime fields that will override blueprint settings

ET_CLASS_NAME Exporting Name of the class with implementation of the INITIALIZE method

Figure 4.33: Interface of READ Method

The READ method reads the data from the model. It also provides locking. The READ method is called with a list of keys. It returns a filled table of the screen structure, according to the keys. After the QUERY method has passed the object keys of the search result to the UI framework, the READ method is called to pass the attributes of the objects to the controller. The result list now could be displayed, but one object has to be in focus first. The READ method is then called again with the object key of the object, which is focused. Then the lock indicator is set. The object in focus will be locked.

Optionally, the READ method can return table ET_FIELD_ATTRIBUTE with display attributes for the fields. These attributes override the entries of the field group table. So the application can decide if fields of an object are changeable and visible at runtime. If the field names of one object are not maintained in ET_FIELD_ATTRIBUTE and the field property set to "read-only", all fields of that object will be displayed as "read-only".

The READ method returns the name of the class with the implementation of the INITIALIZE method, which initializes the buffers. Details are given below.

READ_FOCUS_OBJECT


IV_LOCK Importing The lock indicator, Boolean type






Figure 4.34: Interface of READ_FOCUS_OBJECT Method


The interface of the READ_FOCUS_OBJECT method is very similar to the one of the READ method as they both have almost the same purpose: Both read the complete data of business objects for displaying them in the views. However READ_FOCUS_OBJECT is only called in detail view. Then first the READ method is called without locking to get the data of all the objects and afterwards the READ_FOCUS_OBJECT method is called with the focus object as the importing parameter and with locking. The difference between READ and READ_FOCUS_OBJECT called by the detail controller is that READ is called with the object key of the parent object (of the container above) and READ_FOCUS_OBJECT is called with the object key of the child object in the detail view.

MODIFY



IT_SCREEN_STRUCTURE Importing Table of the DDIC structure data

IT_CHANGED_FIELD Importing Transfers the changed fields and the referring object keys

IV_PARENT_OBJECT_KEY Importing Contains the object key of the parent object from result list (or ODP 1)

ET_FAILED_OBJECT_KEY Exporting Returns a table of object keys that have failed to update

ET_CLASS_NAME Exporting List of classes implementing interface IF_CRM_BSP_PROCESS_IL for processing update

ET_NEW_OBJECT_KEY Exporting Returns the new object key after creation

CT_OBJECTS_TO_REPLACE Changing List of Object Keys that must be replaced (multiedit see section 5.2.1)

Figure 4.35: Interface of MODIFY Method

The MODIFY method is intended for data manipulation (both for object creation and update). The MODIFY method is called with the table of screen structures and information about which fields in the table have changed. This increases performance, as the application has only to check and update the changed data. It performs all checks and updates the buffer of the business object. The MODIFY method is only called if fields on the screen have been changed.

The MODIFY method can return the keys where the modify failed. This means that the buffer could not be updated. If the application log is used, this will usually not happen because the buffer is successfully updated when an error is written in the application log. Nothing needs to be exported into ET_FAILED_OBJECT_KEY if the APIs buffer the incorrect input data. Should the APIs not be able to buffer the incorrectly input data, the framework will do this.

When the MODIFY method is called with “create”, the screen structure contains the data fields. For the newly created object the application has already generated an object key and communicated it to the framework. Therefore the object key is passed back by the MODIFY method.

The MODIFY method has to tell the UI framework the class with the transactional methods for processing the data (ET_CLASSNAME). This class implements the interface IF_CRM_BSP_PROCESS_IL with EV_RETURNCODE and ET_MESSAGES as return parameter and also the interface IF_CRM_BSP_INIT_IL, which contains only the INITIALIZE method.


IF_CRM_BSP_PROCESS_IL

Method Description

CHECK_BEFORE_SAVE Performs final checks and final internal processing before save

SAVE Saves the relevant objects, no commit!

AFTER_SAVE Can refresh buffer

AFTER_ROLLBACK Refreshes buffer after rollback

GET_PRIORITY Returns priority for saving to framework

Figure 4.36: Interface for Transactional Methods

IF_CRM_BSP_INIT_IL

Method Description

INITIALIZE Initializes data, unlocks the object

Figure 4.37: Interface for Initialize Method

The intent of these interfaces is to decouple transactional responsibilities from IF_CRM_BSP_MODEL_ACCESS_IL. Also, the classes with these interfaces can easily be reused. It is recommended to implement the two interfaces in the same class. The concrete class or classes that implement IF_CRM_BSP_PROCESS_IL and IF_CRM_BSP_INIT_IL are the export parameters of the MODIFY method.

The UI framework will receive the classes that implement these interfaces when MODIFY is called. The framework calls CHECK_BEFORE_SAVE and SAVE. The commit will be called centrally so it is not allowed to perform a commit within the APIs for SAVE. When saved, the objects can be initialized with the AFTER_SAVE method. If the save fails and a rollback has to be done, after the rollback the AFTER_ROLLBACK method will be called for initialization. The INITIALIZE method is called after the commit and the AFTER_SAVE call or after the AFTER_ROLLBACK call.

The methods CHECK_BEFORE_SAVE and SAVE need relevant object keys from the MODIFY method.

CHECK_BEFORE_SAVE


EV_RETURN_CODE Exporting Return code

Figure 4.38: Interface of CHECK_BEFORE_SAVE Method

This CHECK_BEFORE_SAVE method is called after selecting the Save button to perform final checks and final internal processing. The application needs to know relevant keys internally from the MODIFY method. It may return that saving is not allowed.


SAVE


IV_FOCUS_CHANGE Importing Boolean value

EV_RETURN_CODE Exporting Return code

Figure 4.39: Interface of SAVE Method

The SAVE method saves the relevant objects. The application needs to know relevant keys internally from the MODIFY method. No COMMIT WORK is allowed because this is done centrally by the framework.

At event SAVE only the complete content of the transaction is saved (saving in individual views is not supported):

• At event SAVE, first of all the BEFORE_SAVE method of all registered objects will be called. The classes have been returned to the framework by the MODIFY methods. If an error is returned from any of these methods, no SAVE method will be called.

• If no problem occurs, all registered SAVE methods will be called.

• If any save event returns an error, a rollback will be executed by the central framework and the methods AFTER_ROLLBACK will be called.

• If no problem occurs on save, the methods AFTER_SAVE and INITIALIZE will be processed for each object.

• The data-loss dialog is provided centrally.

AFTER_SAVE

No parameters

Figure 4.40: Interface of AFTER_SAVE Method

The AFTER_SAVE method can refresh the buffer or reset the change pointers related to the MODIFY and PROCESS_EVENT methods.

AFTER_ROLLBACK

No parameters

Figure 4.41: Interface of AFTER_ROLLBACK Method

With the AFTER_ROLLBACK method the buffer can be refreshed after unexpected problems during the save event.


GET_PRIORITY


RV_PRIORITY Returning Priority: values from 1 to 9, default 5, high 1, low 9

Figure 4.42: Interface of GET_PRIORITY Method

In some cases, dependent objects have to be saved, for example Account and Addresses. There, the order of calling the SAVE methods is crucial. Therefore the GET_PRIORITY method returns a priority value, which defines the importance and thus the sequence of the saving. Values from 1 to 9 can have priority (1 means high priority, processed in the beginning; 9 means low priority, processed at the end). The default value for objects is 5. The implementation of this method is optional. If the method does not return a value, the object that has to be saved receives the default priority.

INITIALIZE


IV_FOCUS_CHANGE Importing Boolean value

Figure 4.43: Interface of INITIALIZE Method

The INITIALIZE method is implemented via the interface IF_BSP_CRM_INIT_IL. The INITIALIZE method has been separated into an extra interface because initialization has to take place not only at saving. For example, the buffer has to be initialized when the focus is changed in the result list. The INITIALIZE method clears all buffers that are filled from the READ method. Therefore the class with the implementation of the INITIALIZE method is returned by the READ method as well as by the MODIFY method.

The INITIALIZE method resets the buffer. This means it either clears the buffer or resets change pointers. Also it dequeues locks (because the lock is also related to the READ method).

The INITIALIZE method is always called

• When the focus changes

• After commit (after the AFTER_SAVE method)

The INITIALIZE and the SAVE methods have an additional optional parameter IV_FOCUS_CHANGE, so the application can decide whether unlock is necessary.

So the INITIALIZE method initializes data that came into the buffer via the READ method, whereas the AFTER_SAVE method initializes data that came into the buffer via the MODIFY method.


CHECK_BEFORE_DELETE


IV_OBJECT_KEY Importing Key of the object to be deleted

IV_SCREEN_STRUCTURE_NAME Importing Name of the screen structure

IT_OBJECT_KEY Importing Table of object keys (multiedit see 5.2.1)

RV_REJECT Returning If delete is rejected

Figure 4.44: Interface of CHECK_BEFORE_DELETE Method

If the user selects the Delete button in the result list toolbar, the CHECK_BEFORE_DELETE method is called with the object keyError! Bookmark not defined. of the object in focus and the referring name of the screen structure. The method CHECK_BEFORE_DELETE performs authorization checks to check whether the deletion of this object is possible. The method can return that the deletion is rejected. Then no further deletion processing is performed.

DELETE





RV_DELETION_FAILED Returning If deletion failed

Figure 4.45: Interface of DELETE Method

If the deletion is allowed then the DELETE method is called after the CHECK_BEFORE_DELETE method with the same parameters. In case the object has been changed before deletion, the registrations for save are cleared. After the deletion has been correctly completed, the framework performs the commit. Then it calls the INITIALIZE method of the classes received from the READ method to clear the buffers. If the deletion fails, a rollback is executed and the AFTER_ROLLBACK method is called.

AFTER_ROLLBACK_DELETE





Figure 4.46: Interface of AFTER_ROLLBACK_DELETE Method

The AFTER_ROLLBACK_DELETE method enables the application to remove data from the buffer after an unsuccessful delete.

The CHECK_BEFORE_DELETE and DELETE methods are intended to delete complete objects, which are generally displayed in the result list. If the delete functionality is required on the detail screen it has to be done with the PROCESS_EVENT method.


The implementation of this method is optional.

PROCESS_EVENT


IV_EVENT Importing The event name or Fcode (references CRMC_BSP_EVENT)

IV_SCREEN_STRUCTURE_NAME Importing Name of the structure to be displayed

IV_FOCUS_OBJECT_KEY Importing Object key with screen focus

IV_EVENT_INDEX (4.0) Importing Internal tables, current line index

IT_SELECTED_OBJECT_KEY Importing Table of object keys selected (future use)

IT_ALL_OBJECT_KEY Importing Table of object keys

ET_CLASS_NAME Exporting List of classes implementing interface IF_CRM_BSP_PROCESS_IL for processing update

EV_OBJECT_KEY Exporting Object key

ET_CHANGED_OBJECTS Exporting Table of object keys (multiedit see 5.2.1)

ET_INSERTED_OBJECTS Exporting Table of object keys (multiedit see 5.2.1)

ET_DELETED_OBJECTS Exporting Table of object keys (multiedit see 5.2.1)

Figure 4.47: Interface of PROCESS_EVENT Method

The application developers register events in the blueprint tables and can implement PROCESS_EVENT method within the model access class to handle custom toolbar events. Toolbar events that are not handled by the QUERY, READ, and MODIFY methods are processed by the PROCESS_EVENT method of the model access class. This method also has to be used for the delete functionality in the ODP. The method calls a function of the application. The application gets the object key of the object in focus and the object keys of all objects displayed in that view. The parameter IT_SELECTED_OBJECT_KEY will be used in future when it is possible to select more than one object in a list.

If the event has been raised by clicking a link which has been rendered due to existing customizing in the field group table field Event (see section 4.3.2.3) the method parameter IV_EVENT contains that customized entry. And the parameter (table) IT_SELECTED_OBJECT_KEY contains one entry that represents the belonging object key of the current clicked entry.

When a button is pressed on the toolbar, the main controller dispatches the event to the appropriate subcontroller's method DO_HANDLE_EVENT, but not to all the subcontrollers. Thus, events triggered in the search area affect only the search request and search result controllers. The subcontroller checks whether the event is a local event for a tag. In this case, no application method is called. Otherwise, the PROCESS_EVENT method is called.

The parameter IV_EVENT_INDEX is used if the event group is filled dynamically at runtime. Then the user selects a button and is presented with some events for selection. If the user selects the second event, the application gets IV_EVENT_INDEX = 2 and can react accordingly.

The parameter ET_CLASS_NAME must only be returned with the class if data has changed in the PRCOESS_EVENT method. It is the duty of the application to fill the parameter properly. This class implements the interface IF_CRM_BSP_PROCESS_IL and also the interface IF_CRM_BSP_INIT_IL to ensure the transactional behaviour of the data.


FILL_EVENTGROUP


IV_OBJECT_KEY Importing Object key

IT_SELECTED_OBJECT_KEY Importing Table of object keys (multiedit see 5.2.1)

IV_SCREEN_STRUCTURE_NAME Importing Structure name for display field

IV_EVENTGROUP Importing Event group

CT_Event Changing Table type for event texts

Figure 4.48: Interface of FILL_EVENTGROUP Method

If the application uses the event group to offer the user multiple events dynamically at runtime for selection in a popup, the method FILL_EVENTGROUP is called after the user selects the referring toolbar button. The application gets information about the current focus object (object key and screen structure) and about the event group that is assigned to the raised toolbar event. The application returns the events and event texts for the popup to the framework.

GET_MESSAGES



IV_FOCUS_OBJECT_KEY Importing Object key of focus object


RT_APPLOG Returning Entries of application log

Figure 4.49: Interface of GET_MESSAGES Method

The GET_MESSAGES method collects all messages of the application and passes them to the application log controller. The messages are displayed on top of the OIP (for details see section 2.2.3.1). The UI framework will call upon this method to retrieve any processing messages. The main controller calls the application log controller with the focus key of the search result list and screen structure name of this focus. So the application log controller has all the information it needs to determine the model access class and to call the GET_MESSAGES method. The method returns a table with the necessary information about the errors in the form of:

• Message type

• Message ID

• Message number

• Message context (optional): message context for free use as reference for table CRMC_BSP_MSGS

- Object key is the key for content in the data container to be displayed. The key is in the same format as in the screen structure (100 bytes). The messages have to be provided in the following way:

- If the API uses the application log, the messages of the application log are returned when the GET_MESSAGES method is called. The messages in the application log are not to be deleted at this moment.


- If the API does not use the application log, a message buffer is required in the model access class. For example, the application log can be used or the last message can be collected. This buffer must be cleared before the API is called. When a message occurs, the message is collected in the buffer. If it is an message type “E”, the invalid data must not be copied to the data buffer. The key is returned in the parameter IT_FAILED_OBJECTS. If this is not done, the entered data will disappear.

- If the GET_MESSAGES method is called, the messages are returned from the message buffer. Afterwards this message buffer is cleared.The CRMC_BSP_MESSAGE table has to be maintained to automatically set the cursor if the user selects the message.

• PROCESS_ID

• STEP_ID

For message navigation in an Guided Data Entry Pattern (GDP), PROCESS_ID and STEP_ID must be determined. For further information on message navigation see section 5.1.1.

GET_VARIANT


IV_OBJECT_KEY Importing Key of the focus object to be displayed in the variant

IV_SCREEN_STRUCTURE_NAME Importing Name of the structure of the focus object

EV_SCREEN_VARIANT Exporting Optional field used to customize content for application and event

Figure 4.50: Interface of GET_VARIANT Method

The GET_VARIANT method is called from the first detail controller. In dependence of the object in focus in the result list, the application can set the screen variant for the ODP. The child data of the focus object of the result list is then displayed in that screen variant in the ODP. This also works with ODP 1 and ODP 2. Basically the variant only changes the display of the ODP.

The screen variant has to be defined in the blueprint tables.

GET_FIELDGROUP_VARIANT


IV_OBJECT_KEY Importing Key of the focus object to be displayed in the variant

IV_SCREEN_STRUCTURE_NAME Importing Name of the structure of the focus object

EV_SCREEN_VARIANT Exporting Field group variant

Figure 4.51: Interface of GET_FIELDGROUP_VARIANT Method

The GET_FIELDGROUP_VARIANT method is called with the key of the focus object. If the focus object is to be displayed in a field group variant, the application has to return the variant.


CHECK_ACTIVE_TOOLBAR


IV_OBJECT_KEY Importing Focus key of parent

IV_SCREEN_STRUCTURE_NAME Importing Name of the structure that will be displayed


CT_TOOLBAR Changing Table of structures used to maintain the active toolbar group

Figure 4.52: Interface of GET_ACTIVE_TOOLBAR Method

The main controller checks whether all toolbar events derived from the blueprint table are active by calling the CHECK_ACTIVE_TOOLBAR method. This method gets the table of toolbar events as its changing parameter. The object key of the focused parent object and the name of the parent screen structure give the application the context of the toolbar. Toolbar events can be deactivated based on application logic. These buttons are displayed as inactive.

CHECK_ACTIVE_TABSTRIP


IV_OBJECT_KEY Importing Key of the focus object

IV_SCREEN_STRUCTURE_NAME Importing Name of the structure to be displayed

CT_TABSTRIP Changing Table of structures used to maintain tab groups

Figure 4.53: Interface of CHECK_ACTIVE_TABSTRIP Method

The main controller checks whether all tabs derived from the blueprint table are active. Tabs can be hidden using application logic. The CHECK_ACTIVE_TABS method overrides the tabstrip of the tabstrip blueprint table. The method gets the object key of the parent focus object and the screen structure of the parent object as the importing parameter.

Process of deactivating tabs:

• To get the deactivated tabs of the ODP 1 (or ODP 2), the detail controller for ODP 1 (or ODP 2) is called with the focus key and calls the CHECK_ACTIVE_TABS method of the referring model access class.

• Since the parameter CT_TABSTRIP is a changing parameter, the results can be used in ODP 1 (or ODP 2) to deactivate the tabs on the view. These tabs are not displayed.


FILL_DROPDOWN_LISTBOX




IV_ALL_VALUES Importing If set to "X", all possible values must be returned

IT_SCREEN_STRUCTURE Importing Optional, only used with F4 help

ET_FIELD_CATALOG Exporting Table with list of the fields, that should be displayed

CT_DROPDOWNLB_DATA Changing The table is used to transport extended data to CRM tags. The data is used to populate the dropdown list box with keys and values

Figure 4.54: Interface of FILL_DROPDOWN_LISTBOX Method

This FILL_DROPDOWN_LISTBOX method is used for two different purposes. The first one is to fill a dropdown list box, Time-Combobox, or ComboBox, which is defined in the field group table, with values. The second one is to populate a popup for data selection (simple F4 help) with data other than domain values. If a field is defined as a dropdown list, Time-Combobox, or ComboBox box in the field group table, this method fills the entries to be displayed for selection. It is necessary to use this method if there is a value table for the field. However it is not necessary if the values can be determined by domain values ( "Domain_Values" has to be flagged in the field group table). If the user does not have to select an entry from the dropdown list box, the first(!) key field in RT_DROPDOWNLB_DATA has to be initial. In some blueprint applications the additional characters like ä,ö,ü,...(Sonderzeichen) in DDLB are displayed at the end of the dropdown list box. To avoid this, please integrate the additional characters into the common alphabetical order (a,ä,b,c,....o,ö, p,q,r,...u,ü,v...z) by selecting "sort as text" for the relevant dropdown list box. The method is called twice from the subcontroller. The first time, the IV_OBJECT_KEY is filled with the key of the focus object and IV_ALL_VALUES is initial. Now the values for the dropdown list box of the focus object should be returned. However there may be more selection values for the other objects as for the focus object. Therefore the method is called again with IV_ALL_VALUES = X. Now the values for all objects have to be returned. This is especially important if objects of different types are in one list.

If the method should be used for F4-help, the input field hast to be assigned with the F4-help flag in the field group table. Then the parameter ET_FIELD_CATALOG can be used to define, which fields of the value help table should be displayed. To display more than two columns in the userdefined value table you have to fill that table with the field names of the columns to be displayed. The order of the columns corresponds to the order of the entries in that table. Furthermore you can overwrite the column header which is automatically taken from DDIC. Please notice that you have to fill the parameter KEYCOLUMNNAME of changing parameter CT_DROPDOWNLB_DATA in any way. The key must be unique. If only two columns should be displayed, the parameter needn´t be used.


CHECK_ACTIVE_MULTIGROUP


IV_PARENT_OBJECTKEY Importing Object key

IV_SCREEN_STRUCTURE_NAME Importing Name of the screen structure.

CT_MULTIGROUP Changing Table of Multigroup Entries

Figure 4.55: Interface of CHECK_ACTIVE_MULTIGROUP

CHECK_ACTIVE_STEPS


IV_OBJECTKEY Importing Object key

CT_STEPGROUP Changing Table of steps (Guided data entry)

Figure 4.56: Interface of CHECK_ACTIVE_STEPS

For details see section 5.2.4.

CHECK_ACTIVE_VIEWSETGROUP


IV_OBJECTKEY Importing Object key


CT_VIEWSETGROUP Changing Table with Viewset group

Figure 4.57: Interface of CHECK_ACTIVE_VIEWSETGROUP


CHANGE_FOCUS



CV_FOCUS_KEY Changing Object key

Figure 4.58: Interface of method CHANGE_FOCUS

The method CHANGE_FOCUS is called in Result List and in ODP directly after the READ method. At this point of time the application can change the focus by returning a different object key. For example this method can be used with a popup-scenario: the user creates a new business partner, which already exists in the system. As the user saves the new one, the system tells him within a popup, that there exists already a business partner with the same name. Now the user can select the existing one and delete the new one. When the popup disappears the user expects that the focus is set on the existing business partner. This can be implemented with the CHANGE_FOCUS method.


CONVERT_TO_BOR




EV_OBJTYPE Exporting BOR object type

EV_OBJKEY Exporting BOR object ID

EV_LOGSYS Exporting Logical system

Figure 4.59: Interface of CONVERT_TO_BOR Method

CONVERT_FROM_BOR



IV_OBJTYPE Importing BOR object type

IV_OBJKEY Importing BOR object ID

IV_LOGSYS Importing Logical system

EV_OBJECT_KEY Exporting Object key

Figure 4.60: Interface of CONVERT_FROM_BOR Method

The CONVERT_TO_BOR and CONVERT_FROM_BOR methods are needed to handle the user's favorites via Generic Object Services (GOS) for favorites. These GOS need the BOR OBJECTID for the management of the favorites. However, the UI framework only knows the 100-character OBJECTID of each object. Therefore the application has to implement the two conversion methods. The handling of the favorites (like add to favorites, display, or delete favorites) is provided by the framework (for more information about favorites, see section 5.1.6).

GET_MY_FAVORITES


IT_OBJECT_TYPE Importing List of object types

IV_SCREEN_STRUCTURE_NAME Importing Structure name for display field

ET_FAVORITE_KEY Exporting Transfer table for My Objects

Figure 4.61: Interface of GET_MY_FAVORITES Method

The method GET_MY_FAVORITES offers applications that do not use GOS favorites an alternative method of providing users with favorites. The object type or types referring to the application are taken from the blueprint table CRMC_APPL_OBJT. These object types in combination with the name of the screen structure are the importing parameters. The application has to return the object keys of the favorites to be displayed in the result list.


SET_URL_PARAMETER


IV_EVENT Importing Event



ET_URL_PARAMETER_TAB Exporting Table with URL parameters

Figure 4.62: Interface of SET_URL_PARAMETER Method

In case of navigation events that are raised from a toolbar button, it can be useful to extend the target URL with additional parameters. Standard parameters are object ID and object type. Additional parameters can be set using the method SET_URL_PARAMETER. In dependence of the event, the object key of the focus and the current screen structure the application can define URL parameters that are added to the target URL.

IS_OBJECT_IN_CREATE_MODE




RV_IN_CREATE_MODE Returning Boolean

Figure 4.63: Interface of IS_OBJECT_IN_CREATE_MODE Method

The method IS_OBJECT_IN_CREATE_MODE is rarely used. It tells the framework whether the object defined by object type and screen structure name is in creation mode. The method has only to be implemented when the application creates objects in the background without using the CREATE event.

For example, in Opportunity Management the action "call the customer" can be activated. Then an activity is created in background. If the user then looks at the activity tab in Opportunity Management and selects the object link of the created activity, the framework calls the IS_OBJECT_IN_CREATE_MODE method. If the object is in create mode, the data-loss popup has to be displayed.

GET_ALLOWED_DDLB_VALUES


IT_OBJECT_KEY Importing Table of object keys

IT_DEFAULT_DDLB_VALUES Importing Table with values for dropdown list box


ET_CHANGED_DDLB_VALUES Returning Table with entries of dropdown listbox in dependence of object key

Figure 4.64: Interface of GET_ALLOWED_DDLB_VALUES

The method GET_ALLOWED_DDLB_VALUES is only used with the MultiEdit Controller (see section 5.2.1)


SET_SELECTED_STEP_ID



IV_STEP_ID Importing Id of step

ET_CLASS_NAME Exporting Class name

Figure 4.65: Interface of SET_SELECTED_STEP_ID


SET_SELECTED_PROCESS_ID



IV_PROCESS_ID Importing Id of process

Figure 4.66: Interface of SET_SELECTED_PROCESS_ID

For details see section 5.2.3 and 5.2.4.

CHECK_ACTIVE_SHUFFLER


EV_SHOWKEY Exporting Key for Search-Show Values

EV_BYKEY Exporting Key for Search-By Values

EV_SRCKEY Exporting Data Source for Search Queries

CT_SHUFFLER Changing Table Type for Shuffler Content

Figure 4.67: Interface of CHECK_ACTIVE_SHUFFLER

The method CHECK_ACTIVE_SHUFFLER gives application the possibility to change the shuffler table of the Search Area. The changing parameter is of type CRMT_SHUFFLER_TAB. Application gets only SEARCHGROUP, SHOWKEY, BYKEY, SOURCEKEY fields in ct_shuffler as defined in the blueprint tables. This is done to restrict the application from changing of other values which should only be read from the customizing. The method is called only once per session. The application can delete rows from the table or change the sequence of the rows.

Please Note: The show-by-source combination of the first row of the CT_SHUFFLER table will be visible as selected in the advanced search area.

Example for usage: If application wants to show only two out of four customized shufflers, the extra rows can be deleted from the shuffler at run time. As of now there is no concept of sequence for the shuffler. If application wants to show some show-by-source combination as selected, they can change the sequence of the rows to achieve the desired result.


GET_PARENT_OBJECT_KEY



IV_SCREEN_STRUCTURE_NAME Importing Structure name of display field

RV_PARENT_OBJECT_KEY Returning Object key

Figure 4.68: Interface of GET_PARENT_OBJECT_KEY method

The method GET_PARENT_OBJECT_KEY is used for determining the object key of the respective next higher level. The method returns the object key of the object from the level above. GET_PARENT_OBJECT_KEY is used especially for message navigation as described in chapter 6.1.1.

4.3.3.3 IF_CRM_BSP_MODEL_SRCH_EXTIN_IL methods

Model access classes can instantiate methods of the IF_CRM_BSP_MODEL_SRCH_EXTIN_IL interface for implanting Fast Search functionalities:

IF_CRM_BSP_MODEL_SRCH_EXTIN_IL

Method Description

QUERY_BY_STRING Start Fast (TRex) Search over all attributes

QUERY_BY_EXTINDEX Start Fast Search over a specified attribute

READ_BY_EXTINDEX Read Fast Search display data (specified object keys)

Figure 4.69: Interface for the Model Access Class

Those methods are optional.

The Fast Search concept allows for applications to interface with an external database for conducting their queries. Fast Search queries are of two types:

• There are the queries over a specified attribute.

• There are the queries over all attributes (TRex).

The integration of Fast Search into OIP is as transparent to the user as possible – the results are displayed in exactly the same way as it is done for the standard search. However, the search over-all-attributes, as well as the search by-attribute, are triggered from within the Google Like Search iView of PCUI, which is positioned below the branding area in the portal. Via URL parameters, this iView sends the following parameters to the OIP:

• QueryType The parameter QueryType defines the fast search query algorithm used: Over all attributes or over a specified attribute.

• QueryAttribute This defines the object attribute over which the search is to be performed for query based (ByAttribute) search. The parameter is only required for query based (ByAttribute) search.


• QueryString, The parameter QueryString represents the searched-for term. It is required for Fast Search (ByString) and for query based (ByAttribute) search.

Depending on the QueryType, on “old-fashioned” query-by-attribute or a query-over-all-attributes (TREX) search is executed.

“Old-fashioned” ByAttribute Fast Search applications need to implement the methods QUERY_BY_EXTINDEX() and READ_BY_EXTINDEX() of interface ‘IF_CRM_BSP_MODEL_SRCH_EXTIN_IL'. If FastSearch is not activated, then 'IF_CRM_BSP_MODEL_ACCESS_IL_2~QUERY' will be invoked. If this is also not implemented then the old 4.0 query method will be invoked for backward compatibility Note that the Attribute list for the ddlb of ‘google like iview’ are taken from the customized fieldgroup for screen position 1 and event ‘INIT’ (Old Blueprint Customizing). In order for PCUI to know if this FastSearch ByAttribute can be offered or not via ddlb, ByAttribute applications have to identify themselves via tables CRMC_APPL_VIEWC (the customer table) or CRMC_APPL_VIEW (the standard table), through the FASTSEARCH parameter. ByString Fast (TRex) Search applications need to implement the method QUERY_BY_STRING() of interface ‘IF_CRM_BSP_MODEL_SRCH_EXTIN_IL' for the FastSearch over-all-attributes integration. If FastSearch is not activated, then 'IF_CRM_BSP_MODEL_ACCESS_IL_2~QUERY' is invoked. If this is also not implemented then the old 4.0 query method will be invoked for backward compatibility. Enabling of all FastSearch (ByAttribute & ByString) operations on an application server: Fastsearch operations need to be controlled server-wide, since an external/TRex server may or may not be available to take the FastSearch requests. This is done via table CRMC_PRT_CUSTOM through the CRM_BSP_FAST_SEARCH_ENABLED parameter. A value like ‘YES’ or ‘X’ will do just fine. On the other hand, the FastSearch functionality can afterward be deactivated by removing the previous entry, or by setting it to ‘’, ‘NO’ or ‘FALSE’

QUERY_BY_STRING



IS_SEARCH_STRING Importing Holds search term used for Fast Search

IV_SEARCH_MAXHITS Importing Limit Value for Search

IT_SORT_FIELDS Importing Sorting information (for future considerations)


Figure 4.70: Interface of QUERY_BY_STRING Method

The QUERY_BY_STRING method is called by the search request controller for FastSearch over all attributes. It passes the search criteria to the model and gets the object IDs of the results. The screen structure contains the search criteria. The search string focuses on the searched string. The QUERYBY_STRING method returns a list of object keys of the selected objects. The query result, which is presented to the user is limited to 100 hits. If the search result exceeds this number a message appears (CRM_BSP_FRAME 010).


If the user does not enter any search criteria in search fields, every object should be selected. It is not necessary to enter * in the search field .

QUERY_BY_EXTINDEX



IS_SCREEN_STRUCTURE Importing Table of objects referring to the imported keys

IV_SEARCH_ID Importing Concatenation of Search and by for the predefined searches

IT_MULTIVALUES Importing Table Type for CRMT_BSP_SEARCH_MULTI_VAL

IV_SELECTED_GET_FIELD Importing Name of a Field

IV_SEARCH_MAXHITS Importing Limit Value for Search



EV_TOTAL_HITS Exporting Total number of records found (for future considerations)

Figure 4.71: Interface of QUERY_BY_EXTINDEX Method

The QUERY_BY_EXTINDEX method is called by the search request controller for FastSearch over a specified attribute. The parameters are the same as of the standard QUERY() defined within IF_CRM_BSP_MODEL_ACCESS_IL_2, excepted for IT_SORT_FIELDS[] and IV_TOTAL_HITS that are for future considerations.

READ_BY_EXTINDEX








Figure 4.72: Interface of READ_BE_EXTINDEX Method

The READ_BY_EXTINDEX method is called by the search result controller for FastSearch over a specified attribute. The parameters are the same as of the standard READ() defined within IF_CRM_BSP_MODEL_ACCESS_IL, excepted for IT_SORT_FIELDS[] that is for future


considerations, and for the lack of the IV_LOCK parameter, since no database locking can be performed using this method.

4.3.4 Portal Integration of Blueprint Applications

The People-Centric UI as a whole is seamlessly integrated into SAP EP. The portal is the single point of entry for every user and offers access to the Web-based SAP applications as well as to different content from document management tools or Web-enabled applications. Special features of the portal, like Single Sign-On (SSO), personalization, and Drag&Relate, make it the appropriate workplace for any user. The layout and the content of the portal as well as the layout and the functionality of the application depends on the user's roles. The role corresponds with the job function the user has, for example Sales Representative, Lead Qualifier, or Service Manager.

The following tasks have to be fulfilled to include a blueprint application into the portal:

• Definition and maintenance of roles

• Definition and maintenance of authorizations

• Creation of object links

• Insertion of the blueprint application into the portal

In the portal context, the blueprint applications are included as BSP applications.

For detailed documentation on the tasks to be performed on the portal side, see SAP Service Marketplace under www.service.com/epinstall. In the present document, we are focusing on the tasks to be done on the UI framework side.

4.3.4.1 Roles

SAP EP can be treated as an infrastructure to combine different kinds of content into one user interface depending on the user's role.

Roles and the referring worksets, services, and pages are maintained in the portal (see chapter Fehler! Verweisquelle konnte nicht gefunden werden.). The definition of the roles takes place in the portal, as does the assignment of the users to their roles. To connect the user-access rights of the blueprint application to the portal role, an equivalent role to each portal has to be maintained in Web Application Server (transaction PFCG). For each portal role there is a corresponding single role in SAP Web AS, for example the portal role com.sap.pct.crm.CampaignManager corresponds to the role SAP_PCC_CAMPAIGN_MANAGER in CRM Server. The relationship of the roles has to be maintained in table CRMC_PRT_ROLE_RL. For each single Server role, the corresponding portal role and SAP BW role have to be assigned.

However, there is no technical connection between the portal role and the server role. The linking is performed by the user, to whom roles are assigned in SAP Enterprise Portal and in SAP CRM. A unique CRM user is assigned to each portal user. The CRM Server role defines the access rights of the user. The connection between the portal user and the CRM user works through the SSO mechanism. With SSO, the user has access to various systems and applications within the portal, without having to log on again for each system.

For a role-dependent view of the blueprint applications, the parameter blueprint view (BLVIEW) is transferred to CRM Server at runtime. There this parameter in the blueprint tables is responsible for the role-dependent setup of the screens (see section 4.3.2.10). A blueprint view can be part of several portal roles. The parameter blueprint view defines a special view on a transaction, which can be used within roles.


4.3.4.2 Authorizations

Each role in the portal has a corresponding role on the server. For example the lead manager role in the portal com.sap.pct.crm.LeadManager refers to SAP_PCC_LEAD_MANAGER on the CRM server. Authorizations for each role are defined by a transaction code for each blueprint application. This transaction code collects all authority objects for the specific blueprint application.

To add authorizations to a role the following steps are necessary: • Define an authority transaction code or use an existing one

• Add authorizations to authority transaction

• Add authority transaction code to blueprint application

4.3.4.2.1 Definition of Authority Transaction Code

If no authority transaction code exists for a blueprint application, one has to be created within transaction SE93. The naming convention for authority transaction codes for blueprint applications is the following: BSP_<name of blueprint application (or abbreviation)>.

Figure 4.73: Examples of Authority Transaction Codes

4.3.4.2.2 Maintain authorizations

If the authority transaction code for a blueprint application is created, the authorizations can be maintained via transaction SU22. The transaction code has to contain at least the authorization object BSP_APPL, because this permits the general access to the UI framework. Application developers have to add all authority objects, which are necessary for using his or her blueprint application, to the authority transaction. Then the authority objects have to be classified and their field values have also to be maintained in the way as they should be shipped to the customer. The maintenance has to be view independent.

To ease the maintenance of authorizations it is also possible to refer to an existing transaction and add only specific authorizations for the blueprint application. For example the authority transaction code BSP_CRMD_BUS2000108 uses the transaction CRMD_ORDER_PA as parameter transaction (have a look in SE93).

Then blueprint application specific authorization objects for accessing the UI framework or the F4-help are added (SU22). In SU22 the status of the authority transaction code has to be set to “auto”. Notice, that it is not possible to use a parameter transaction as parameter transaction. The reference works only once.

If a role administrator adds the transaction BSP_CRMD_BUS2000108 to one role, the role get all authority objects from both transactions!

4.3.4.2.3 Reference authority transaction code

Each blueprint application needs one authority transaction code. The authority transaction code has to maintained in table CRMC_APPL. The table can be found in transaction CRMC_BLUEPRINT at Application -> Layout Definition

Authority TCode BSP-Application

BSP_CRMD_BUS2000108 CRMD_BUS2000108

BSP_CRMDBUS2K116QUO CRMD_BUS2000116_QUOT


Portal administrators use this information to add the authority transactions to the corresponding portal roles (transaction PFCG, tab menu). The values of the authorization objects can be maintained there, too. Customers customize their authorizations via transaction pcfg, tab authorizations.

For testing the authorizations a user has to be created (SU01) and then added to the role (PFCG, tab user: add user and then execute “user comparison”)

4.3.4.2.4 Tracing Authority Objects of Blueprint Applications

For tracing authority objects the following steps have to be executed: • Start program VIEW_USOB (Transaktion SE38)

• Search for objects with SSER_TYP="PC-UI"

• Look directly for you authorization objects or search for your blueprint application

• Copy the hash value (first column of the list) which identifies your blueprint application and use it to find the authority objects in table USOBX (SE16).

4.3.4.3 Object Links

Object links are hyperlinks displayed on the fields of an object or attached to a toolbar button. If the user selects them, the maintenance application of this object is called with the object as parameter. Thus the user can for example select the Ship-To Party field in the Sales Order application and jump directly into the account management of this ship-to party. Another example is the Create Follow-Up button, which launches the sales order application directly from the opportunity application.

The only units that can be meaningfully addressed by URLs in SAP EP are pages and external services. Therefore a URL is generated that references the portal service which hosts the iView hosting the destination blueprint application. These links are generated automatically using the following information:

• Object ID The unique key of the object with the hyperlink

• Object type The object type matching the object ID

• Method The blueprint application that works with this kind of object

Object links have to be maintained in the field group table.

To get the OBJECTID of the object that owns the hyperlink, the framework needs to know the field of the screen structure that contains the OBJECTID. Therefore the name of this field has to be maintained in the column Field → CRM Object ID (URL_FIELDNAMEID) in the field group table.

The field CRM Object Type (URL_OBJECTTYPE) of the field group table contains a special kind of object type. Usually business objects are related to BOR types, which are defined in the Business Object Repository (BOR). The use of the BOR type has limitations, because several applications refer to subtypes of the BOR type. For example Product and Service Product can not be differentiated by the BOR type. Therefore a special CRM object type has been introduced as subtypes of the BOR object types.

CRM object types have to be created in table CRMC_PRT_OTYPE. If an application uses only one BOR type, only one CRM object type has to be maintained. For the usage of several CRM object types for one BOR type, multiple records have to be defined. It is possible to mark one of the CRM


object types as the BOR object type. This CRM object type is used for object links using the BOR type.

CRM Object Type Object Type Description BOR Object Type Internal Key

Accountcrm BUS1006 Account X

Competitorcrm BUS1006 Competitor

Figure 4.694: Example of CRM Object Types (Table CRMC_PRT_OTYPE)

The internal key field is for future use within unification tasks.

There are different applications that work with the same type of object, but in different ways. For example, apart from the default maintenance application, a product can have an application to handle cash flow. CRM Method defines the application that has to be used. CRM methods are maintained in table CRMC_PRT_MTD and then assigned to CRM object types in table CRMC_PRT_MO. “Default” is the standard entry. The default method is the standard maintenance application of that object type. However if a link has to be made to a particular page of that application (not the usual start page), then a special method has to be defined.

One object type can be assigned to several methods in table CRMC_PRT_MO. To facilitate customizing, every method should have one entry without object type.

The definition of the target application takes place in table CRMC_PRT_ROLE_MO. For every combination of role, object type, and method of the target application, the appropriate view and the page ID from the Portal Content Directory have to be maintained.

The concrete target of an object link is defined in the table below:

Role CRM Object Type

CRM Methods

Priority Implementation Type

Applica-tion

View

Page ID / Service

SAP_PCC_KEY_ACCOUNT_MANAGER

ACCOUNT_CRM

Default 23 BSP External Service

ACC /roles/com.sap.pct.isu.KAM/Accounts/nf/nf

Figure 4.705: Example of Object Link Assignment (Table CRMC_PRT_ROLE_MO)

The implementation type defines how the portal interprets the transferred parameters and has to be selected according to the type of target application:

• For blueprint applications BSP External Service is used

• For iViews on portal pages Portal Page or BSP Portal Page is used

• For SAP R/3 transactions with SAP GUI for HTML T has to be selected

• For further content External Service is used

If one user has assigned two different views on the same application (via different roles), the parameter priority is used to decide which target application is displayed.

For the object links, the portal role and the server role have to be related. This is maintained in table CRMC_PRT_ROLE_RL.

The relation between object links and the corresponding target application is tightly coupled in the Blueprint tables and the object links are specified at design time. But applications sometimes need a more flexible concept to specify the object links. Especially in the case of mixed lists the object


type can differ from row to row and has therefore to be specified at runtime. It is possible to use an indirection by declaring a fieldname of the screen structure that contains the CRM Object Type or the CRM Method per row. With this concept the applications can declare the navigation targets during runtime. The customizing of this behavior is explained in the section “Creating links in mixed lists”.

4.3.4.3.1 Creating Object Links

The preparations for URL generation have to be completed before object link navigation can be provided.

• Creating object type for navigation (table CRMC_PRT_OTYPE):

- Create one object type for the BOR type of your application and mark it as BOR object type in the checkbox.

- Add further object types as sub types of your BOR type, if necessary.

• Maintain method for navigation (table CRMC_PRT_METHOD):

- Check if method default exists. If not create it.

- If you need further methods, create them also.

• Assign method to object type (table CRMC_PRT_MO):

- Declare each combination of object type and method you want to use. Create one record with an empty object type for each method.

• Define the target for the object links (table CRMC_PRT_ROLE_MO):

- For every combination of role, object type, and method you want to use in the target application you have to define the implementation type, application, view and page ID / service. Application and view are the same as in the main blueprint table. The information for Page ID / service and implementation type are taken from the Portal Content Directory (PCD).

- Define Priority to define the launched view, if the role of the user allows two different views on your application.

• Assign a single role to the portal and SAP BW role (table CRMC_PRT_ROLE_RL)

To create the concrete object links, maintain the entries in field group table CRMC_FIELDGRP or in the event table CRMC_BSP_EVENT and follow the steps below:

• Creating standard object links:

- Choose object type in field CRM Object Type (URL_OBJECTTYPE).

- Choose the default method (or leave field empty) in the field CRM Methods (URL_METHOD).

- Enter the name of the field containing the object ID into field Field → CRM Object ID (URL_FIELDNAMEID).

• Create link to special method of static object type:

- Choose object type in field CRM Object Type (URL_OBJECTTYPE).

- Choose appropriate method in field CRM Methods (URL_METHOD).


- Enter the name of the field containing the object ID into field Field → CRM Object ID (URL_FIELDNAMEID).

• Create links in mixed lists: o dynamic object type

Leave CRM Object Type empty (field URL_OBJECTTYPE). Enter the name of column containing the object type in field Field Name →

CRM Object Type (URL_FIELDNAMEOT). If you want to provide BOR types instead of CRM object types, set the flag Fld Name contains BOR Type (URL_FNOTISBORFLG).

Choose the DEFAULT method or another suitable method in field CRM Methods (URL_METHOD).

Enter the name of field containing the object ID into field Field → CRM Object ID (URL_FIELDNAMEID).

o Dynamic navigation method Set up CRM Object Type or the dynamic object type (see above) Leave CRM Navigation empty (URL_METHOD) Enter the name of column containing the object type in field Field Name.

CRM Object Type (URL_FIELDNAMEMTD).

4.3.4.4 Session Management

Blueprint applications can be seen as a special type of BSP applications. The portal infrastructure has an iView that was especially designed to host BSP applications. This iView is used to integrate, for example, the CRM applications as external services into the portal. This iView provides a simple session management that ensures the termination of the hosted BSP session when the surrounding context changes. Every time the frame that hosts the BSP disappears, a termination URL is sent to the BSP application to ensure proper session termination. Details can be found in the portal documentation.

BSP standard session management assumes that sessions are shared inside the same BSP application. CRM uses an approach where only one BSP application exists (CRM_BSP_FRAME). All the various applications like Account Management, Opportunity Management and so on, are managed internally by a URL parameter called APPL. This leads to the following problem: If the user switches from one portal service that hosts a blueprint application to another portal service that hosts another blueprint application, in both cases it is the same BSP application CRM_BSP_FRAME. Therefore, the portal is unable to obtain the correct order of both the session close request of the portal service that was left and of the session request for the new blueprint application.

BSP applications are able to provide session information like a session ID via a cookie or a URL. In the CRM environment it has been decided to use URL rewriting with the advantage that more than one blueprint application can be used on one portal page and the creation of new sessions can be controlled explicitly. The selection between the two methods of session management is controlled by a URL parameter value “sap-syscmd=nocookie”. This means that session management is handled through a URL. Details can be found in the documentation of SAP Web AS 6.20, SP05.

With the administration of a blueprint application as an external service in the portal, the additional query string contains the blueprint table application parameter APPL and the system command parameter with the value “nocookie”.


Figure 4.716: Integration of a Blueprint Application as an External Portal Service

4.3.5 Generic Containers

Applications that wish to send complex data to each other can use the generic container classes provided by the PCUI Framework. Generic containers are represented by instances of the IF_CRM_BSP_CONTAINER interface. Each container can have any number of attributes (which are name-value string pairs) and can also have any number of children containers. Containers are stored in the database under a globally unique identifier (GUID) that can be passed from one application to another as a URL parameter (see the Object Link Generator documentation for more information on adding parameters to a URL). Containers can be instantiated through the CL_CRM_BSP_CONTAINER_FACTORY class.

A typical scenario for an application would include the following steps:

1. Create a new, empty container by calling the factory class.

2. Set the container’s attributes.

3. Create other containers, set their attributes and add them as children of the first container.

4. Save the root container to the database by calling its SAVE method. All the children are saved automatically.

5. Get the root container’s GUID and add it to a URL that points to another application.

6. When the user clicks that link, the other application receives the container GUID in its URL.

7. It calls the container factory to load the container with that GUID, as well as all its children, from the database.

8. The application then reads the information contained in those containers.

The IF_CRM_BSP_CONTAINER interface wraps a container object. It features a number of methods that can be called by model access classes.

IF_CRM_BSP_CONTAINER

Method Description

RELEASE Performs any required cleanup operations before the


Method Description container is removed from memory. This method recursively calls itself on all children containers prior to performing any cleanup operations.

SAVE imports IV_BACKGROUND optional

Saves this container to the database. If the IV_BACKGROUND flag is set to ‘X’, the save is performed as a background task. This method calls itself recursively on all children containers.

DELETE imports IV_BACKGROUND optional

Deletes this container from the database. If the IV_BACKGROUND flag is set to ‘X’, the deletion is performed as a background task. This method calls itself recursively on all children containers.

SET_ATTRIBUTE imports IV_NAME IV_VALUE

Sets the value of the specified attribute. Automatically sets each attribute’s creation date, change date, creator and changing user, as well as the whole container’s change date and changing user (if the new value is different from the previous one).

SET_ATTRIBUTES imports IT_ATTRIBUTES

Sets the specified attributes according to the received table. Each entry contains the corresponding attribute’s creation date, change date, creator and changing user. Also sets the whole container’s change date and changing user.

GET_ATTRIBUTE imports IV_NAME returns RV_VALUE

Returns the value of the specified attribute. Raises a CX_CRM_BSP_INVALID_PARAMETER exception if no attribute exists with the specified name. This method is not case-sensitive.

GET_ATTRIBUTE_CS imports IV_NAME returns RV_VALUE

Returns the value of the specified attribute. Raises a CX_CRM_BSP_INVALID_PARAMETER exception if no attribute exists with the specified name. This method is case-sensitive.

GET_ATTRIBUTES exports ET_ATTRIBUTES

Returns all attributes as a table of name-value pairs. Each entry also contains the corresponding attribute’s creation date, change date, creator and changing user.

REMOVE_ATTRIBUTE imports IV_NAME

Removes the specified attribute. Also updates this container’s change date and changing user.

REMOVE_ATTRIBUTES Removes all the attributes of this container. Also updates this container’s change date and changing user.

ADD_CHILD imports IR_CHILD

Adds the specified child to the container and updates the child’s parent reference. Raises a CX_CRM_BSP_INVALID_PARAMETER exception if a child with the same name already exists, if the child’s parent reference is not empty, if the specified child is one of the container’s ancestors in the hierarchy, or if adding the child is impossible for some other reason. This method also sets this container’s change date and user.

GET_CHILD imports IV_NAME returns RR_CHILD

Returns a reference to the child container with the specified name. Raises a CX_CRM_BSP_INVALID_PARAMETER exception if no child with that name exists.

GET_CHILDREN Returns a table of children container names and references.


Method Description exports ET_CHILDREN

The order of the children is unspecified.

REMOVE_CHILD imports IV_NAME

Removes the child with the specified name. Raises a CX_CRM_BSP_INVALID_PARAMETER exception if no child exists with the specified name. This method also sets this container’s change date and user.

GET_PARENT returns RR_PARENT

Returns a reference to this container’s parent. If the container’s parent GUID is not empty and the reference is null, loads the parent object from the database by calling the Container Factory. If the parent GUID is empty, returns an initial reference.

GET_PARENT_GUID returns RV_PARENT_GUID

Returns the GUID of this container’s parent. If the container has no parent, returns an initial value.

GET_GUID returns RV_GUID

Returns this container’s GUID.

SET_NAME imports IV_NAME

Sets this container’s name, updating the change date and changing user (if the name is different from the previous one).

GET_NAME returns RV_NAME

Returns this container’s name.

SET_FORMAT imports IV_FORMAT

Sets the format name of this container. The format name can be defined by applications wishing to use containers to transfer information from one another. It is optional.

GET_FORMAT returns RV_FORMAT

Returns the format name of this container. The format name can be defined by applications wishing to use containers to transfer information from one another. It is optional.

GET_CREATED_ON returns RV_CREATED_ON

Returns this containers’ creation date.

GET_CREATED_BY returns RV_CREATED_BY

Returns this container’s creator.

GET_CHANGED_ON returns RV_CHANGED_ON

Returns this container’s last change date.

GET_CHANGED_BY returns RV_CHANGED_BY

Returns this container’s last changing user.

Containers cannot be instantiated directly. The CL_CRM_BSP_CONTAINER_FACTORY class must be used to either create a brand-new container or load one from the database. This class features a specific method for each purpose.

CL_CRM_BSP_CONTAINER_FACTORY

Method Description

LOAD_CONTAINER Instantiates a container instance by loading it from the


Method Description imports IV_GUID returns RR_CONTAINER

database. Returns the container instance. A CX_CRM_BSP_INVALID_PARAMETER is raised if a container with the specified GUID cannot be found.

CREATE_CONTAINER returns RR_CONTAINER

Instantiates a container instance and returns it to the caller.

4.3.6 Accessibility The SAP Accessibility Standard is part of the SAP product standards. User interfaces have to fulfill this standard to ensure that people with disabilities can access SAP products with the help of special equipment (for example screen readers). The SAP Accessibility Standard guarantees also that the product is in compliance with the US laws (Section 508 of the workforce investment act). Section 508 of the Rehabilitation Act Amendments, as amended by the Workforce Investment Act of 1998, requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, they shall ensure that the electronic and information technology allows Federal employees with disabilities to have access to and use of information and data like non-disabled persons.Therefore it is a requirement to be compliant with that regulations to sell software in the US public sector. The European Community is currently also preparing some similar regulations.

The People-Centric User Interface is compliant with the SAP Accessibility Standard. It supports the usage for people with

• Sensory disabilities (color blindness, low vision, blindness, etc.)

• Mobility disabilities (for ex. inability to use the mouse, etc.)

For the second target group the People-Centric UI is keyboard enabled. For sensory disabilities a special accessibility mode can be switched on. Then additional tooltips etc. are part of the UI.

Accessibility Mode

Technically the accessibility mode can be switched on with the parameter SAP-Accessibility=X within the URL.

In ABAP a developer can check if the user has switched on the accessibility mode by the following method call:

data accessibility type string.

accessibility = runtime->WITH_ACCESSIBILITY( ).

Creation of Tooltips

Icons or pictures need to be explained by a tooltip. This tooltop is for example read loudly by screenreaders. If an application uses icons or pictures, it has to create a tooltip which explains the icon or picture.

To display the tooltip only two steps are necessary: • Add a field to your screen structure with the text of the tooltip.

• Enter the name of the field in the field TOOLTIPFIELDNAME of fieldgroup table


4.4 Logical Flow of Control within the People-Centric UI Framework

The application flow is initiated by a browser request – an HTTP request containing parameterized URL in its body, for example server.wdf.sap -ag.de:port/sap/bc/bsp/sap/crm_bsp_frame/entrypoint.do?sap -client=200&appl=CRMD_BUS2000111. In this example, the parameters after the question mark define the client (200) and the application (CRMD_BUS2000111).

From this point on, the framework has enough information to initialize the application's main controller (parameters in the URL define the application name and event).

The following contains a summary of the flow logic that takes place:

• A parameterized URL (application and BLVIEW) is taken to start with

• The subcontrollers are called twice to set up a screen,:

- The first run is for data retrieval

- The second run is for layout generation

Process Before Output

1) The main controller (C0) is determined using the parameters supplied in the URL.

First Run

2) Determine screen setup using the blueprint table for the given main controller.

3a) C0 requests the focus from parent controller by calling a method in application passing focus and screen structure, receiving a variant for the access of the blueprint table.

3b) C0 instantiates the subcontrollers (if not already done) using blueprint parameters.

4a) The subcontroller requests keys (communicated by the main controller) from its parent controller (controller with previous item number in blueprint table).

4b) The subcontroller retrieves data for the screen structure using the parameter SCREENSTRUCTURENAME.

5) Repeat steps 3-4 for all positions defined in the blueprint table.

Second Run

6) The subcontroller determines the view (internal knowledge of the subcontroller) and sets the view.

7) The tag retrieves information (labels) from DDIC and sets up the screen. Tags should never retrieve application data.

8) Repeat steps 6-7 for all positions defined in the blueprint table. Display the complete screen.

Now the user enters some values and selects a button (for example Search or Save). Again a request is sent to the server and now processing after input starts:

Process After Input

9) The dispatcher (Basis function) passes the entered values to the appropriate subcontroller.

10) The subcontroller calls the appropriate method of the application (QUERY, MODIFY). The controller knows whether it needs to call modify or query.

11) The result list is buffered in the memory of the data context of the subcontroller. There is a data context for each screen structure (see also section 4.3.3)


Process Before Output

12) Starts with step 2.

At 4b) the list-controller calls CRM_READ with keys and screen structure as parameters

C1: Search RequestV1: View

C1: Search RequestV1: View

C2: Search ResultV2: View

C4: DetailV4: View



C4: DetailV4: View

C4: DetailV4: View

Sold-to Party BACH

C3: DetailV3: ViewField1Field2Field2

Search

ListList

Focus

KeysKeys

C0 Main Controller

CRM Model

GenericOrder

Product Master

Business Partner

Que

ryR e

adM

odify

Basis

7)

7)

7)

7)

4b)

4a)

4a)

4b)

10)

10)

1) 2)

Figure 4.727: Logical Flow of Control

4.4.1 Performance Optimization

A few basic rules must be adhered to during development to achieve optimal scalability. The basis for good scalability is the CPU of the database and linear dependency at the application layer.

4.4.1.1 General Tips for Performance-Optimized Coding

The Database

Choosing the Right Index Design

There is an example from real life that may help you to follow the guideline:

A telephone book lists the names in alphabetical order. So if you are looking for the surname of the person who has the telephone number 654321, you have to look through every single entry of the telephone book. A telephone book only has one index, but a database table can have numerous indexes. The following guidelines should be followed to achieve good index design:

• All frequently executed database accesses (selects, updates, and deletes) must be supported by indexes. A highly modified table should not have too many indexes. The more columns an index has, the higher the chance that an update will affect one of the indexed columns. frequently specified with "=" should be at the beginning of the index.


• The most selective columns should be at the front. The index BUKRS is not selective. • The indexes BELNR, MATNR, KUNNR, OBJNR are highly selective and bring the

optimizer to the right index as quickly as possible. MANDT – as an exception – should still be part of every index at the first position.Avoiding Identical Select Statements

Here too there is a example from everyday life: If you have a favorite restaurant where you need to book ahead, you certainly don't want to be bothered with looking up the number every time and would probably have the number on your inboard. The same concept applies to database programming:

Using Read Modules as Buffers in Application Programs

Read modules are special function groups that store information read from the database in global internal tables.

The visibility of the data is restricted to one SAP Logical Unit of Work (LUW).

Read modules should be used:

• When buffering the information using the technical settings of the table is not feasible

• To prevent unnecessary database calls when the same data record is used in different program units of the transaction

• To ensure consistent data within one transaction

Making Use of SAP Buffers

Take good housekeeping, for example. To optimize food storage, it makes sense to store the tinned food or foodstuffs that you don't need too often in the cellar or in a cool, dry place, whereas you would keep perishable foodstuffs in the kitchen. This concept also applies to tables buffers.

In a production system, the following tables rarely change:

• Small tables

• Tables that are mainly accessed for reading

• Control tables, Customizing tables, or "small" master data tables

Therefore, check whether buffering is allowed:

• No, if data must always be up-to-date (possible inconsistency within the synchronization period)

• No, if overhead due to displacement and synchronization is too high (> 1% changes)

For effective use of the buffer, the right buffering type has to be chosen and not all statements can make use of the buffer. Also, displacement or synchronization must be avoided.

Ensuring Complete Where-Clauses

Here an example from the supermarket may help: Often when you buy toothpaste, it comes in two packages. The carton is not really needed to keep the toothpaste itself and you also have to dispose of it. Within the framework of SAP NetWeaver this means that it must be ensured that only data is read from a table that is actually needed for further processing. If the where-clauses are complete, the number of transferred data records is reduced, thus alleviating the database.

SAP Web Application Server

Ensuring Linear Dependency


Take thirst, for example. If you buy 10 bottles of fruit juice, you expect 100 bottles to weigh 10 times as much. The same expectation applies to SAP NetWeaver. Linear dependency is the most prominent feature of scalable programs. The most important tip here is to use the right table type:

• Use the standard table for multiple access types, use BINARY SEARCH for mass accesses and try to SORT only once

• Use the sorted table, if generic key access is main access type

• Use hashed tables if single line access with fully specified key is the only access type

• Then you must ensure that the table is filled efficiently by:

- Using array operations and APPEND or INSERT

- Using TRANSPORTING field list /NO FIELDS if useful

- Using ASSIGNING especially in nested tables

• Try to keep internal tables small

Determining an Adequate Sizing Procedure

When a motor company brings out a new car, one of the best sales arguments is how much fuel it needs. Our customers expect the same from us. Therefore, before and during development, the following questions should be answered:

• Will the scenario have to handle high throughput?

• Will the scenario have to handle high user concurrency?

Allocate sufficient time to do measurements when the product and the system are stable and be aware of possible sizing algorithms:

• Disk space consumption

• CPU consumption

• Memory consumption

4.4.1.2 Tips for Performance-Optimized UI Development

With respect to the UI framework, good performance of the GUI can be assured by adhering to a few guidelines with respect to the design of screen structures and the corresponding APIs (model access classes):

1. Creating screen structures with reasonable sizes: Large screen structures may have the advantage of flexibly moving fields from one tabstrip to the other but you should bear in mind that the corresponding model access class must always fill the full structure. Therefore, when you create screen structures, avoid reading all possible information before the user actually requests it. So if you already have some structures of your model (components), make efficient use of them.

2. Making efficient use of buffers: Because the framework always reads all the data from the model it is important that this read access is highly performance-optimized. This means that it is of paramount importance to make sure the model access classes know where the buffers are and they should use them directly.

3. Dynamic layout generation: Wherever possible, use the dynamic layout generation for the field groups.


4. Handling queries effectively: For all queries you deliver, the corresponding requests to the database must be supported by appropriate indexes.

It is very important that you do not instantiate every requested object, but that you only determine the data requested by the screen structure. This means that the corresponding APIs are different from the ones you normally use for the ODP (see also Step 1 above).

4.4.1.3 SAP Monitoring and Performance Tools

SAP Web AS offers multiple possibilities for monitoring processes and performance analysis:

4.4.1.3.1 Code Inspector (Transaction SCI)

The code inspector helps to check static coding and DDIC objects (generally: TADIR objects). It is available with SAP Web AS 6.10 and 6.20. The checks include performance, security, reliability, and statistical information. The code inspector can be called for a single object (program, function module, or class) from the menu of the ABAP editor (SE38), function builder (SE37), or class builder (SE24) with Object → Check → Code Inspector (where object is "program", "function module" or "class"). The respective single objects are then checked with a default check variant of the code inspector.

Alternatively, with transaction SCI it is possible to create object sets, and check variants and inspections. An object set can contain, for example, all objects of a package, and a check variant is a collection of different checks. An inspection runs a chosen check variant for all objects of an object set.

For more information about the code inspector, see the Code Inspector User Manual in SAPNet, alias Performance → Media Center → Literature.

4.4.1.3.2 Performance Trace (Transaction ST05)

The performance trace (transaction ST05) allows the developer

• To monitor the interaction of the program with the database (SQL trace)

• To see the remote function calls (RFCs) (RFC trace)

• To see the enqueues (Enqueue trace) and how long an enqueue is held

• To see the buffer accesses (Buffer trace)

If the performance trace is not available on a special platform (for example, Java), the database trace of the respective vendor can be used. For example, Oracle "tkprof" or Microsoft SQL Server "Profiler".

It is possible to trace SQL statements from HTTP requests. This tracing function can be switched on as usual for a single user or all users.

For more information about the performance trace, refer to SAPNet alias Performance → Media Center → Presentations: Performance Tools: Performance Trace & Code Inspector.

4.4.1.3.3 Global Performance Analysis (Transaction ST30)

Transaction ST30 is used to perform a global performance analysis. Trace data (SQL and RFC traces) and statistical data (the same data as that obtained from ST03 and STAD) are determined across system boundaries. This data is user-specific and can be generated for specific intervals. All of the data generated in ST30 can be saved to the database for later analysis.


ST30 can also be used to perform an automatic performance analysis. The system runs predesigned test cases that simulate user activity and saves the trace and statistical data to the database.

The following transactions are related to transaction ST30:

• ST33: Displays and analyzes the performance data saved by ST30.

• ST34 and ST35: Maintains Customizing settings for the automatic performance analysis.

• ST36: Deletes performance data that is no longer needed from the database.

4.4.1.3.4 Workload and Performance Statistics (Transaction ST03N)

Transaction ST03N (ST03) is used to analyze the system load at various levels. This includes a look at system load for the entire system, for individual servers, down to an analysis per user or transaction. This is statistical data that includes response, database, and CPU times, and the amount of data processed and main memory use.

For a simplified view of single statistical records, such as for one user, the transactions STAT (= old version from earlier releases) and STAD (= new version of STAT) can be used:

• Per default switched off for HTTP requests. To switch it on the profile parameter: RDISP/NO_STATISTIC = "PLUGIN" has to be changed to: RDISP/NO_STATISTIC = " ".

• After switching on, HTTP requests are available with tasktype "H" and the usual information (except transaction code, instead the HTTP path is shown in detail view).

4.4.1.3.5 Runtime Analysis (Transaction SE30)

The “ABAP trace” monitors the time spent in different ABAP modules, which modules are called, and how often they are called.

ABAP runtime analysis (SE30) can be switched on using transaction SICF for a specific service (URL) and for a defined time frame. For activation (SICF), select the service and select in menu: Edit → Runtime Analysis → Activate.

Result: one performance file per request. The performance files can be evaluated using SE30: choose button "Other file" to set the user that ran the HTTP request. (If it cannot be found, try user SAPSYS, because the recording of the first request of a user starts before user validation, and is therefore treated as SAPSYS).

4.4.1.3.6 ICM Monitor (Transaction SMICM)

The ICM monitor (transaction SMICM) monitors general statistics (requests, processing time) of the Internet Communication Manager (ICM).

Developer's traces (dev_files) are as usual available via SM50, SM04 for the work processes, and are also available for the ICMAN process.

4.4.2 Testing an Application

If a new application has been created by Customizing the blueprint tables and implementing a model access class, it can be tested without the portal environment by using a simple BSP page,


which displays hyperlinks to all applications of the UI framework. This overview page is called SELECT.HTM and is available at SE80, package CRM_BSP_FRAME_GENERIC (see Figure 4.64).

To test an application, choose SELECT.htm. The application must be selected from the list and it will be displayed in the same browser window. The recommended screen solution is 1024x768.

Caching of MIME Objects

The MIME objects – for example icons, pictures, JavaScript files - have an explicit expiration date (7 days after the request) from the browser's point of view and stay in the browsers cache until the expiration date has been reached. This happens also, when there is a newer version of the MIME object on the server. The client won't check for newer versions! (This is true for default (and recommended) settings of the browser cache.)

In a more complex scenario, where a proxy server is involved (e.g. decentral development locations), the proxy server behaves in the same way as described for the browser before. It won't check for newer versions until the expiration date is reached.

To get the latest version of a MIME object you need to clear the browser's cache and in the case a proxy server is involved you need to refresh the page.

If you change a MIME object you should clear the HTTP-Server Cache (transaction smicm) in addition to the above mentioned actions to enable yourself (and others) to receive the latest version of the mime object.

Caching of URL

For performance reasons, the URL generation for object links, object references, navigation or other links uses a buffer. Entries in this buffer remain active for one hour before they are replaced with data which was calculated again.

If you change the configuration of the URL generation, it is probable that the new data is not taken into account immediately. After one hour, the buffered data becomes invalidand the new configuration data is taken into account.

For development, test or configuration purposes, this buffering can be deactivated for individual users. If the buffering is deactivated, the buffer is deleted and the generation is always based on the current data. The buffering can be deactivated as follows:

• Call up the 'User maintenance' transaciton (SU01)

• Call up the change mode for the desired user

• Go to the 'Parameters' tab

• Create parameter CRM_URL_BUFFER_OFF if this does not exist

• Enter parameter value 'X' for parameter CRM_URL_BUFFER_OFF

• Save

After SPA/GPA CRM_URL_BUFFER_OFF has been set, the buffering is deactivated. Changes of the navigation data come into effect immediately now.


Figure 4.738: Testing an Application Without Using the Portal

MS Internet Explorer Settings

To display the error messages of SAP Web AS in the browser deselect "Show friendly HTTP error messages" in MS Internet Explorer → Internet Options → Advanced.

Generally the most restrictive security setting of the Microsoft Internet Explorer is medium. Especially the following have to be relaxed from their most restrictive setting:

• Allow per-session cookies (not stored)

• File download

• Launching programs and files in an IFRAME

• Navigate subframes across different domains

• Active Scripting


Neither Logon setting for user authentication has to be relaxed from its most restrictive setting nor Java VM is required.

4.4.3 Debugging

Problems whilst displaying or executing BSP applications can have different reasons. If a problem occurs, the application debugs itself to find the solution. A special HTTP Debugger is available for the program code of BSP applications.

The HTTP Debugger is user-specific, that is, breakpoints are set specifically for each user. Authentication must not be suppressed if authentication is set for the HTTP request.

Procedure to Follow Before Debugging:

• Make sure that the Internet Communication Manager (ICM) is active. To do this, navigate to the transaction SMICM. The status of the ICM should be on Running and the green traffic light should be displayed.

• Make sure that the ICM is running with the correct parameters. The correct domain and DNS configuration is already entered for the BSP application.

The HTTP Debugger for BSPs can be activated and set up in different ways:

• By setting the breakpoints in the BSP application

• In the HTTP service tree maintenance (transaction SICF) under Maintain → Debugger → Activate Debugger.

• In the Development Workbench (transaction SE80) under Utilities → Settings. In the following dialog box for user-specific settings, the embedded tab HTTP Debugger on the tab ABAP Editor should be chosen. Here you can activate the HTTP Debugger globally for each user.

In the Web Application Builder of the Development Workbench it is also possible to activate or deactivate the HTTP Debugger under Utilities → Breakpoints → (De)activate for HTTP User.

It is important to note that deleting all breakpoints does not automatically deactivate the HTTP Debugger.

4.4.4 Steps for Blueprint Table Maintenance

The transaction CRMC_BLUEPRINT offers a convenient way of maintaining all blueprint tables and subtables. Just go through the transaction step-by-step and add the required fields. Make sure you use the naming conventions (section 4.4.5).

An example application is provided in the Appendix to this document, which explains step-by-step how to build the first simple blueprint application. This example is further enhanced with additional UI functionality, blueprint table entries, and coding of model access class methods.

Step-By-Step Blueprint Table Maintenance

• Define the application set

• Define the screen setup in the main blueprint table

• If you have role-dependent views, define them here

• Define events

• Define the layout of toolbars, tabstrips, and search groups

• Create screen structure


• Define field groups

• Create model access class and complete application set

• Maintain application log

• Define object link navigation (see section 4.3.4.2, and particularly 4.3.4.3.1)

• Complete F4 help, if necessary

• Test the consistency of entries

• Generate the layout

Details of how to complete these steps are explained in sections 4.3.2 and 4.3.3.

4.4.5 Naming Conventions for Blueprint Tables

The following naming conventions are mandatory for blueprint maintenance. The framework checks whether the blueprint entries comply with the naming conventions.

4.4.5.1 Abbreviations

The naming conventions are described by using the following abbreviations:

Abbreviation Full Version

For XXX ACC Account

ACI Actions

ACT Activity

CFM Confirmation

CON Contact

CPT Competitor

CPL Complaints

EMP Employee

IBA Installed Base

LEA Lead

MKT Marketing Plan

OPP Opportunity

PCF People-Centric Framework Development

PRD Product

SDB Solution Database

SLC Sales Contract

SLO Sales Order

SLQ Sales Quotation

SRC Service Contract

SRV Service

Take further abbreviations from CSN components like BTX for business transaction. Do not use CI_. This prefix is reserved for automatically generated entries for Customizing includes.



For YY HD Header

IT Item

For VVV ADDRESS Address Information

CM Content Management

COND Conditions

CONFIG Configuration

DETAIL Detail Information (instead of General or Overview)

PARTNER Partner Information

PRODUCT Product Information

TAX Tax Information

TEXT Text

TGROUPS Target Groups

…

For QQQQ PART Partner

OLIS Object List

COND Conditions

TEXT Text Management

CM Content Management

ITEM

LIST

OIP Search Area/Result List

ODP1 Object Data Pattern 1

ODP2 Object Data Pattern 2

(length not fix) …

For ZZ…Z Any field from 0 to Z or _

(…) optional


4.4.5.2 Blueprint Table Entries


APPLICATION: Naming conventions are the same as for transactions in CRM: <component><prefix>_ZZZZZ…ZZ

Component: COM For general objects

BBP

CRM

CDB

…

Prefix: C Customizing

D Transaction Data M Master Data

Examples: CRMM_ACCOUNT Account Management

COMM_PRODUCT Product (old: COMMPR01)

CRMM_PRODUCT_SALES Product (Sales)

CRMM_PRODUCT_SERVICE Product (Service)

CRMM_PRODCUT_MARKETING Product (Marketing)

COMM_IBASE IBASE (old IB51,IB52,IB53) See also CRM Guidelines at \\dwdf034\CRMOrder\ProgrammierModell\ProgGuidelines_english.doc

APPLICATION SET:

Naming conventions the same as for application

MESSAGE GROUP:

Like Message Classes in the CRM programming guidelines, for example CRM_MKPL_COND_MSG_GR

EVENT: Generic events and events specific to a particular object have to be distinguished:

Generic events are predefined events in the UI framework, you should use: INIT, DELETE, CREATE, ADD_LINE, SAVE, REMOVE_LINE, PRINT, COPY, CHANGE, FOCUS_CHANGE_SRES, FOCUS_CHANGE_DETAIL

If you want to make the event “object specific” use: XXX_<generic event> (for example ACC_INIT, IBA_INIT…)

Do not use: INSERT, CLEAR, CHANGE, REFRESH, MODIFY, SEARCH

Event specific for an object: XXX(_YY)_VVV

Examples: OPP_HD_DETAIL

OPP_IT_COND

SRV_PARTNER

IBA_PARTNER

PRD_CONFIG



PRD_TAX

FIELD GROUP: XXX(_VVV) Screen position information must not be used (reason: cannot be changed, if the field group changes to another "place”)

Examples: OPP_DETAIL

OPP_PARTNER

SRV_CONFIG

BA_PRODUCT

SCREEN SCTRUCTURE:

<component>T_BSP_XXX_Z(..Z), for example CRMT_BSP_SLO_SEARCH. Do not use any special character except _ , because special characters can cause conflicts with JavaScript and HTML

TOOLBAR GROUP:

XXX_QQQQ(_Z)

Examples: OPP_OIC_1

SRV_ITEM

ACT_LIST_1

MKT_OIC

MKT_ODC

REGISTERTAB GROUP:

Same naming conventions as for toolbar group

EVENTGROUP: Same naming conventions as for toolbar group

SEARCH GROUP: XXX(_ZZZZZZ)

BYKEY: XXX(_ZZZZZZ) (Table CRMC_BL_BY)

SHOWKEY: XXX(_ZZZZZZ) (Table CRMC_BL_SHOW)

MULTIGROUP: XXX_VVV

BLUEPRINT VIEW (BLView)

XXX_YYYYYY (abbreviations see below)

For XXX SLS Sales

SRV Service

MKT Marketing

For YYYYYY MANAGR Manager

ASSIST Assistant

REPRES Representative

LEAD_Q Lead Qualifier

Examples: SLS_MANAGR Role: Sales Manager

MKT_ASSIST Role: Marketing Assistant

SRV_REPRES Role: Service Representative


4.4.6 Requesting Additional Patterns

UI-framework development is based on identifying, understanding, and utilizing UI patterns in common with the various CRM applications and tasks. The use of a limited number of controllers and views ensures a consistent layout of the screens across all transactions. It is important to keep the number small. A number of patterns have already been defined and implemented as controllers and views. There is some evidence that the currently available or planned patterns will not satisfy every single application scenario. It is important to note at this time that the requests for new patterns (controllers, views) should be always directed to the UI Framework Group alone. It is essential that this task is handled centrally to ensure that new controller development and controller maintenance is orchestrated and managed in such a way that usability standards are consistently applied and to avoid duplication of effort in the various application groups.

Before making a request for a new pattern, developers should ensure that all possibilities of reusing existing patterns and redesigning the application have been exhausted. Only if this does not lead to an acceptable solution should the developer approach the UI Framework Group with the new controller requirements.

4.5 User Interface (Re-)Engineering Process

To create a UI according to the People-Centric design approach requires intensive effort before implementation. It has to be focused on the user and the user's tasks, and it must be analyzed how the user can best cope with these tasks. These processes have to be completed if a new blueprint application is built as well as if an existing UI is re-designed.

There are ten steps that lead to the basic design of a pattern-based UI for an application that meets the guidelines and principles of the People-Centric UI.

Step 1 Analyze the users' tasks (build “Use Case”) and identify the business objects the user works with

Step 2 Analyze existing applications for their component tasks and task sequences (using the user object hierarchy of the Business Partner)

Step 3 Build the application model (business process pattern = ground plan) for every business process

Step 4 Describe each specific component of every application model with "focus areas" (specific component tasks with attributes (objects, functions, and so on)

Step 5 Consolidate the application models to the minimum of those necessary (standardization)

Step 6 Look for similar or equal component tasks (reusable "modules")

Step 7 Construct a paper prototype for each business process

Step 8 Test the paper prototype with real users

Step 9 Repeat steps 7 and 8 until the paper prototype has been fully optimized

Step 10 Build the user interface of the application


The following questions should be answered during the (re)-engineering process of the UI. This information should lead to the compilation of a specification or design document, which should be discussed in a review.

• Feature list: Provide a list of the features of the SAP GUI application. Mark each feature which is not contained in the new design. Try to make the new design as simple as possible. Thus it is OK to lose some of the less important features of the old design!

• View structure: Describe which views are used and how they are placed on the screen.

• Description of the OIP:

- Which standard queries are offered under Show? Describe for each of the standard queries the data shown in the result list.

- Which possibilities to search for objects are offered under Advanced Search?

- Which functions are offered in the toolbar?

- Which fields are shown in the list view? Are those fields editable in the list?

- Which fields are shown in the form view? Are those fields editable?

- Is it necessary to have views other than the form and list views (for example tree, content management, and so on)?

• Description of the ODPs: Which tabs are shown on the ODP? Describe for each tab:

- Which functions are offered in the toolbar?

- Is the information on the tab shown as an input form or a table or in a different form?

- For input forms: Describe the fields on the form.

- For tables: Describe the columns and if a form view is offered for the table the fields on the form view.

- For non-standard views (calendar, graphic, and so on): Give a short description about what is shown on the screen. If possible add some graphical examples.

- Is another ODP displayed or hidden in dependency of the action on the tab?

- How is navigation to other objects possible (with hyperlinks or buttons)?

• Use cases: Describe some (at least one) typical use cases. Show for this use case how the user interacts with the interface.

- Also describe the interaction with other application components. The use cases should cover realistic business processes in which several application components are used.

• Open points: Add open points in the general specification of the new interface paradigm or problems you found in mapping your application to the new paradigm as a list to the document.


4.6 Conclusion

Within the UI framework, responsibility for the design of the UI is in the hands of usability specialists. The screens are built from reusable, pattern-based UI components and can be customized by the application developer by maintaining blueprint tables. A generic application interface implemented in the model connects the UI to the business logic. This generic interface also serves as a basis for upcoming Web services.

The clear separation of concerns of the programming model enables software development to focus on special tasks, such as UI development, framework development, and application development. This makes software development more efficient, increases product quality, simplifies customizing and personalization, and reduces costs.


5 APPLICATION DEVELOPMENT – DETAILED VIEW

5.1 Generic User Interface Services

On each screen various generic UI services like input help, error message handling and so on have to be provided. The following sections introduce the services of the UI framework.

5.1.1 Message Handling

Messages are displayed above the search area in a separate view. The application log controller generates this view. The screen position of this view is fixed and does not need to be maintained in the blueprint tables. Messages may either be raised by the framework itself or by the application. If there are multiple messages at the same time, only the latest message with the highest priority is shown. However the user has the possibility to expand the message area to see a list of all messages, sorted by priority and time of occurrence. Initially only the short text of a message is shown. If a long text is available, as well a link “Details” will be shown. Clicking on it will show the text in a separate window.

Usually messages inform about erroneous data entered on a screen. To support the user in correcting this data, the concept of message navigation was introduced. The user clicks on a message and, as a result, the relevant screen is shown with the erroneous field having the focus. However, to establish this message navigation, some configuration effort is necessary.

At runtime, the application has to provide the messages via exporting parameter RT_APPLOG of method GET_MESSAGES (see section 4.3.3.2). Note that the framework only calls GET_MESSAGES for the class being assigned to the screen structure of the result list. If the application consists of several model access classes, it is the responsibility of the application to collect and provide the messages issued by the different classes.

To support message navigation, blueprint table CRMC_BSP_MSGS has to be maintained. This establishes the link between messages raised by the application (specified by ID, number and context) and navigation information (screen position, event and fieldname) necessary to navigate to the correct screen.

For each message provided by the application the framework tries to find a corresponding entry in table CRMC_BSP_MSGS. If no entry exists, navigation is not supported.

The following fields of table CRMC_BSP_MSGS contain the navigation information: • Screen Position

Screen Position specifies the position of the screen (according to SCREENPOSITION in table CRMC_BLUEPRINT).

• Event

Event specifies the event the screen is configured for in the blueprint table. As a result, the framework has to trigger event Event for position Screen Position to navigate to the correct screen. However, if Screen Position specifies a screen below ODP1 (position 4 or position 5) all other screens located on the ‘path’ to this screen (position 3 & 4), might have to be adjusted as well. The framework at runtime evaluates this. The framework analyses all screens being configured in the blueprint table and lying on a path to the relevant screen by using a bottom up algorithm. However the relevant screen might be reached by different paths showing different screens in between. In this case, the path that best matches the path of currently displayed screens from top to bottom is taken. As a result, as little as possible of the current screen layout changes.


Each screen (= controller) on the path to the relevant screen might handle several objects. E.g. a list controller handles a list of entries/objects, each represented by a different OBJECT_KEY. If a list controller lies on the path to the relevant screen, the correct object of the list needs to receive the focus. As the framework does not know the OBJECT_KEY, it asks the application to specify it. Therefore method GET_PARENT_OBJECT_KEY is called (see section 4.3.3.2).

• Fieldname

Fieldname specifies the technical name of the field (in the screen structure) that should receive the focus. This technical fieldname might as well be provided by the application at runtime. When returning a message in parameter RT_APPLOG of method GET_MESSAGES the application might optionally specify the fieldname (component FIELD_NAME). In this case the framework considers the fieldname to be more relevant than a fieldname specified in table CRMC_BSP_MSGS.

• Action Event

Action Event is only relevant for popups and popins (see section 5.2.5 and 5.2.6).

5.1.1.1 How to configure table CRMC_BSP_MSGS to enable message navigation

Table CRMC_BSP_MSGS has the following keys that are relevant for message specification:

• Message ID

• Message Number

• Message Group

• Context

A message raised by the application at runtime must always specify a Message ID and a Message Number. It may optionally specify a Context. This runtime message information has to be mapped to the message specification in table CRMC_BSP_MSGS to get the relevant navigation information.

The following three configuration methods are supported (the framework evaluates these configuration methods in the given order):

Explicit message specification

The entry in CRMC_BSP_MSGS is specified by Message ID, Message Number and Context. Message Group must be initial. The runtime message information must exactly match the message specification. If the runtime message information does not contain a context, the context in table CRMC_BSP_MSGS must be initial as well.

Lines 1 to 3 of figure 6.1 are examples of this kind of message specification.

Message specification using message groups

The entry in CRMC_BSP_MSGS is specified by Message Group and Context. Message ID and Message Number must be initial.

Several messages with the same navigation target can be grouped into a Message Group. Therefore table CRMC_BSP_MSG_GRP has to be maintained assigning messages (by ID and Number) to message groups:

• Message ID

• Message Number

• Message Group


This reduces configuration effort in table CRMC_BSP_MSGS. Only one entry for the message group has to be maintained to support navigation for all messages of this group.

Figure 6.2 and Lines 4 to 5 of figure 6.1 are examples of this kind of message specification.

Message specification independent of ID and Number

The entry in CRMC_BSP_MSGS is specified by Context only. Message Number and Message Group must be initial. Message ID must have the value ‘*’. This means, that navigation bases exclusively on the Context. As an application developer would normally associate the context with a specific screen, it is appropriate to use the name of the screen structure for the context as well.

Lines 6 to 7 of figure 6.1 are examples of this kind of message specification.

Application Set

Message ID

Message Number

Context Message Group

Field Name

Event Screen Position

COMM_BP CRM_OPP 12 DATE OPP _OVERVIEW

3

COMM_BP CRM_OPP 15 SOURCE OPP_SOURCE 4

COMM_BP CRM_OPP 15 TARGET OPP_TARGET 4

COMM_BP ADDRESS OPP_ADDRESS 3

COMM_BP DETAIL ADDRESS OPP_ADDRESS_D

3

COMM_BP * OPP_GENERAL OPP_GENERAL 3

COMM_BP * OPP_DETAIL OPP_DETAIL 4

Figure 5.1: Table CRMC_BSP_MSGS

Message Group

Message ID Message Number

ADDRESS CRM_OPP 18

ADDRESS CRM_OPP 19

Figure 5.2: Table CRMC_BSP_MSG_GRP

5.1.1.2 Parameterized Application Start

When starting an application, different URL parameters can be specified to start the application with a preselected object, to process an action in the backend or to navigate to a predefined screen at startup.

Preselect an object in OIP

If an object should be preselected, the key of this object has to be passed via parameter crm_object_id. The framework calls MAC method READ to get the relevant data for this object. This object is solely displayed in OIP holding the focus.


Perform an action in the application

To make the application perform a backend action at startup, parameters crm_appl_event and crm_appl_object_id can be used. If the parameter crm_appl_event is specified, the following steps are performed:

• The model access class (MAC) that is configured for the search request controller for event INIT is used for backend communication.

• Method PROCESS_EVENT of the MAC is called with the following parameters:

- IV_EVENT: the value specified in parameter crm_appl_event.

- IV_SCREEN_STRUCTURE_NAME: name of the screen structure configured for the search request controller for event INIT.

- IV_FOCUS_OBJECT_KEY: the value specified in parameter crm_appl_object_id. If crm_appl_object_id is not specified, the parameter will be initial.

• Method GET_MESSAGES of the relevant MAC is called with the following parameters:

- IV_SCREEN_STRUCTURE_NAME: name of the screen structure configured for the search request controller for event INIT.

- IV_FOCUS_OBJECT_KEY: the value specified in parameter crm_appl_object_id. If crm_appl_object_id is not specified, the parameter will be initial.

- The backend must return at least one message in exporting parameter RT_APPLOG. This message should inform about the action being performed in the backend. If no such message is provided, a dump is triggered. The backend might specify an object key in component OBJECT_KEY_OIC (of parameter RT_APPLOG). This tells the framework to display the corresponding object in the OIP. The further behaviour is the same as if this object key would have been specified in parameter crm_object_id at startup (see above).

Note: The parameters crm_appl_event and crm_object_id cannot be used at the same time. Parameter crm_appl_object_id cannot be used without parameter crm_appl_event.

Navigate to a predefined screen

Normally the application starts up with the screen that was configured to be the default screen (event INIT) in the blueprint tables. However in some cases it may be useful to start with a different screen. This could be achieved by parameters crm_appl_event and crm_appl_object_id as well. The parameters have to be specified the same way as explained above for performing an action in the backend. However, the application is of course not necessarily forced to perform an action, but could simply return a message. The framework picks up the (first) message returned by the application and treats it the same way as if the user had manually clicked on this message in the application log. Thereby the framework tries to initiate a message navigation as explained in section 5.1.1.1.

By configuring the blueprint tables CRMC_BSP_MSGS and CRM_BSP_MSG_GRP for message navigation and providing a suitable message, the application has the ability to control the first screen to be displayed at startup. As a precondition for navigating to ODP screens, an object has to be selected in OIP. Therefore the backend needs to specify the OIP object’s key in component OBJECT_KEY_OIC of the message.


5.1.2 Context-Sensitive Help

Application developers can add context-sensitive documentation to their application screens. If documentation is available, a help link appears on the screen area. Otherwise, the link is not available. Choosing this help link opens a new browser window and displays the requested document with the help information. If the help window is already open on request, it will be reused. Also if the main window closes, the help window closes automatically too.

As usual, the SAP Knowledge Warehouse (KW) hosts the SAP online documentation. KW is set up for dynamic help. For each controller, container, or tab, the class of the online help and the ID of the logical information object (LOIO) have to be maintained in the main blueprint table.

5.1.2.1 Requesting Documentation

The implementation of the context-sensitive help is based on client-side JavaScript and a special controller, the help processor. JavaScript is needed for opening the help window and cleanup (“onUnload”). Upon view generation, the main controller reads the class and the ID of the LOIO from the blueprint table and makes it available as an argument for the JavaScript function “showHelp (documentGuid)”.

If documentation is requested, the process is the following:

• Users trigger a help request by choosing Help on the screen or screen area where they need further information.

• The LOIO ID of the requested help documentation is passed to the JavaScript function, which opens (reuses) a new browser window and passes the URL to the Help Processor.

• The Help Processor calls KW, determines the user context and resolves the document URL for KW.

• The document URL is returned from KW to the Help Processor and then forwarded to the browser window.

• The browser window requests the document with the document URL from KW and displays it in the browser window.

5.1.2.2 Documentation and Translation

In the People-Centric UI, customers have access to context-sensitive documentation as and when they need it. The following types of documentation are provided on the People-Centric UI:

• Data elements

• Messages

• Knowledge Warehouse (KW) topics

5.1.2.2.1 Data Elements

• Short texts ABAP Dictionary provides short texts. You can display, maintain, and translate short texts in transactions SE11, SE61, and SE63. For more information about individual transactions, see training material from SAP courses ZDI030 and ZDI 220.

• Long texts If the short text of the data element is not descriptive enough, you can maintain longer


data element descriptions as field help long texts in transaction SE61. You may also maintain additional glossary definitions in SAPterm that define the concepts behind the short texts. You can link to glossary entries from your Knowledge Warehouse topics. If you write a definition, keep it as general as possible because the concept as a whole may apply to more than just one data element.

5.1.2.2.2 Messages

• Message short texts The system provides the messages that appear on the People-Centric UI. You can display, maintain, and translate short texts in transactions SE91, SE61 and SE63.

• Message long texts If a long text is available for a particular message, the short text appears as a hyperlink. The long text appears in a separate Web browser window.

5.1.2.2.3 Knowledge Warehouse Topics

When users choose Help context-sensitive documentation appears. Only use the following information classes for the KW documentation for BSP-based interfaces:

• Component

• Function

Help links are provided in each area. In the ODP, each tab page has its own Help link to a KW topic. When you choose Help, a Web browser window displays the KW topic as the Help text.

Knowledge Warehouse topics are handled in the following way for the People-Centric UI:

• Topics are displayed without a structure.

• Topics can contain glossary links.

• Topics can contain hyperlinks to other topics.

• For the technical name of these topics, the following naming conventions apply: CRM_UI_<Key Capability>_...; Example: CRM_UI_SALES_QUOTATION_001

• Topics are included in a dummy structure. This dummy structure is a substructure. This substructure must not be included in another structure nor should another structure link to that substructure or any of its topics.

• As long as SAP supports the People-Centric UI and the SAP GUI for Windows, we recommend using existing documentation if possible.

Linking a Knowledge Warehouse Topic to People-Centric UI

Prerequisites:

You know the application number and the logical information object (LOIO).

Finding the Application Number:

There are various ways to find the application number:

• Call the BSP-based interface that you wish to describe. In the address field you will find a URL. The application number is part of this URL: appl=CRMD_BUS<Number> The part marked in bold face is the application number

• Ask the responsible developer.


Finding the Logical Information Object:

1. In KW, choose the current context..

2. Display the info object list for the folder that contains the topic.

3. Select the topic and display it in the Web browser. The topic you selected appears in the Web browser.

4. You will find the LOIO in the address field of the browser after the following letters: IWB_EXTHLP~. The LOIO is comprised of 32 numbers and letters.

5. Copy the LOIO to the clipboard.

Checking the Logical Information Object (Optional):

To check whether the LOIO is correct, proceed as follows:

1. In system AIO, go to the KW Change documentation screen.

2. Choose Utilities → Find → Find LOIO.

3. Choose area IWBHELP.

4. Choose object class IWB_EXTHLP.

5. Enter the LOIO that you copied previously in field Log. document and choose Enter. The dialog box List of Existing Contexts appears.

6. Select the original language of the topic and choose Copy Info Object (Ctrl + Shift + F9). The topic that belongs to the LOIO added by you is displayed.

Linking a Knowledge Warehouse Topic with the People-Centric User Interface:

1. Log on to your SAP system.

2. Call transaction CRMC_BLUEPRINT. Screen Display IMG appears.

3. Choose Implementation Guide (IMG) activity Application/Layout and confirm the message relating to the client. The screen Change View ″Application Scenario″: Overview appears.

4. Select the application number of the People-Centric UI you want to link with your KW topic. In the navigation area, double click Complete Use of Layout. The screen ″Complete Use of Layout″: Overview appears. All data elements that appear on the People-Centric UI are displayed. The names of the tab pages appear in the Event column.

5. Select the corresponding row of the tab page you want your topic to be linked to.

6. In the DocuClass field, enter IWB_EXTHLP.

7. In the ID for documents and relations field, enter the LOIO of the KW topic to be called using the Help link.

8. Save your entries. The dialog box Prompt for Workbench request appears.

9. Choose Create Request. The dialog box Create Request appears.

10. In the field Short description enter: "Link to UI documentation" and save your entry.

11. Save the request with Continue.

5.1.3 F4 Help

The F4 help (well-known from SAP GUI for Windows) offers input help for the user at different levels:


• Simple value help, which displays several predefined values for selection. The sources for these values are the domain fixed values or the value table of the domain of the DDIC field

• Value help, which displays special values defined by the application at runtime

• Advanced search help

F4 help is available on all three levels in the new UI framework. However, it is not quite the same as in the SAP GUI for Windows. The (complex) search help from SAP R/3 will not be supported.

5.1.3.1 Value Help

A simple F4help will be displayed for a certain field, if there exists:

a) domain fixed values or

b) check tables or

c) simple search help ( with or without exit)

In case b) and c) text tables can not be evaluated – only key values can be returned. If the text columns are directly located in the check table or in the table related to the query method the text will be returned. Please take care that existing exits do not bring up messages and do not process call screens. This will cause problems in the framework context. No further action is required.

If the values are to be displayed in a dropdown list box or in a combobox (COBX respectively TIME) in the field group table, the field needs the attribute DDLB (dropdown list box) or COBX respectively TIME and the field DOMAIN_VALUES has to be set. Now if a simple value help is assigned to the DDIC field, the dropdown list box respectively the combobox (COBX respectively TIME) will be filled automatically via data binding.

If you want the application to specify the values for selection (within popup or dropdown list box or combobox (COBX respectively TIME)) at runtime instead of using predefined domain values, data must be provided by the application via the method FILL_DROPDOWN_LISTBOX. That scenario works if the field type is "Input Field" and the F4 application is set to "VALUE_TABLE". With these customizing settings, the method FILL_DROPDOWN_LISTBOX of the interaction layer is called at runtime and the actual field values will be passed to the application via importing parameter IT_SCREEN_STRUCTURE. Thus the application can provide context-sensitive help values within a popup or a dropdown list box respectively combobox (COBX respectively TIME). Within the popup more than one column of values can be displayed.

Dropdown list boxes should not be used if the number of entries exceeds a value of 10. A check report might otherwise change the field type settings in the blueprint customizing.

Note: Simple F4help window is always opened with fixed height and width.

5.1.3.2 Advanced Search Help

The advanced search help is displayed in a separate browser window with search area and result list (OIP). Client-side JavaScript opens this window when users choose F4. Scripting creates this window with a URL, which is directed to the special F4 help controller (CL_CRM_BSP_F4_HELP_MAIN). This F4 help controller provides the F4 help data. Data transfer from window to main screen is also performed by client-side JavaScript.

If advanced search help needs to be performed, the corresponding application of the main blueprint table is assigned to the input field in the field group table in the field F4_APPLICATION. For example "ACC" has to be entered if Accounts is to be searched in the F4 input help. If the F4 application should be dynamically defined at runtime, the value DYNAMIC_F4_HELP has to be entered as the F4 application. The identification of the application, that should be called as the F4


application, works like object links. One field with the corresponding BOR object type has to be provided and according to that, the field Field name → BOR or CRM object has to be maintained in the field group table. From CRM5.0 DYNAMIC_F4_HELP by default will use 'CRM Objects'. To use the 'BOR Objects' additionally, Fieldgroup customizations for the Field must be performed.

Follow the instructions in the OSS Note 828350, for carrying out the changes.

The correct application is identified via the navigation tables CRMC_PRT_OTYPE and CRMC_PRT_MO. In CRM5.0 field Field Name -> CRM or BOR Method has to be maintained in the Fieldgroup for the search of the application. Search is performed with first value in the field Field Name -> CRM or BOR Method if application find fails then methods VALUEHELP and DEFAULT will be used successively.

“Field name → BOR or CRM object” represents F4_FIELDNAME_BOR ,

“Field Name Containse BOR Object” represents F4_FIELDISBOR

Field Name -> CRM or BOR Method” represents F4_FIELDNAMEMTD In Fieldgroup tables

The advanced search help is processed in its own ABAP session. Within the portal the advanced search help is displayed in an iView. There is a standard iView for the F4 help which can be overwritten according to OSS note 658796.

5.1.3.3 Transfer of values between F4 Help and Application

Transport of the selected value from the F4 help popup back to the application screen is done by using the same field names. However, in many cases, the field names of the screen structure of the screen that calls the advanced F4 help and the field names of the screen structure of the search result list of the F4 help do not match. In such cases, mapping rules can be defined in blueprint customizing in table CRMC_F4MAPREC.

The key of the mapping table is similar to the key of the field group table: FIELDGROUP, BLVIEW and FIELDNAME.

For each field FIELDNAME where an F4 application is assigned, it is possible to define any number of mapping pairs. Several fields of the result list screen structure of the F4 application can be mapped to the screen structure of the source application. For example, let us consider the field group OPP_EMPL where the F4 application ACCOUNT is assigned to the field LASTNAME:

Field Group BLView Field Name Result Field F4 Application Field in Hitlist

OPP_EMPL Lastname Firstname BP_name1

OPP_EMPL Lastname Lastname BP_name2

Figure 5.3: Example of Table CRMC_F4MAPREC

With the customizing measures described above, the advanced F4 help is called from the field LASTNAME. The search area of Account Management is displayed in a separate window and the user selects the account "Carl Miller". The first name "Carl" is the value of the field BP_NAME1 and the last name "Miller" is the value of the field BP_NAME2. Back to the source application, the mapping rules transfer "Carl" to the field FIRSTNAME and "Miller" to the field LASTNAME of the field group.

The key of the table CRMC_F4MAPREC is Fieldgroup, BLView, Fieldname, Result field and F4-Application. The values for the keys have to be taken from the field from which the F4 help is triggered. The field FIELDNAME_SND defines the source for the default value whereas the field SEARCH_FIELDNAME contains the target field of the screen structure of the called search area.


Thus if F4 help is called from field FIELDNAME, the value of FIELDNAME_SND is taken as default value for SEARCH_FIELDNAME.

It is possible to define similar mapping rules for the transfer of default values to the F4 help popup. That means that field values of the focus object of the application can be set as default values in the advanced search area of the F4 help popup. The maintenance of mapping table CRMC_F4MAPSND is similar to that of CRMC_F4MAPREC.

Field Group BLView Field Name Source Field for default values

F4 Application Target Field for default values

OPP_EMPL Lastname Firstname BP_name1

OPP_EMPL Lastname Lastname BP_name2

Figure 5.4: Example of Table CRMC_F4MAPSND

The key of the table CRMC_F4MAPSND is Fieldgroup, BLView, Fieldname, Source Field and F4-Application. The value for the field ‘Field name’ has to be taken from the field from which the F4 help is triggered.

The field F4 Application must remain empty in standard cases. Its relevant only for the dynamic F4 help. In case of dynamic F4 help there could be a separate set of mapping rules for each possible F4-Application. In order to distinguish and maintain these sets of rules key field F4-Application was added.

5.1.3.4 Hidden Fields

In some cases, selected data set is identified by a key, for example, a 32-character Global Unique Identifier (GUID). Such a key should not appear on the screen for usability reasons. Nevertheless, such keys will simplify application coding if available.

It is possible to transfer these keys as hidden fields from the F4 popup to the main screen. The key field can be hidden on the main screen and the key field can be hidden in the hit list as well. Two prerequisites must be fulfilled:

• The hidden fields must belong to the corresponding field groups

• The hidden fields must be mapped in the mapping table

5.1.3.5 Field assignment for pre-selecting fields to be filled by default

In the multiple selection value help, you can select multiple rows from the search results in the value help application. All mapped fields are transferred from the value help application to the calling application. In addition, you can pre-select fields in the calling application that will be filled in by default. The values are filled in by copying the value from the focus row ( which means the row from which value help application was launched). In such cases, mapping rules can be defined in blueprint customizing in table CRMC_F4_MULTIDEF.

The key of the mapping table is similar to the key of the field group table: FIELDGROUP, BLVIEW and FIELDNAME. However, F4_APPLICATION, which is the name of the value help application, is also an additional key.

For each field FIELDNAME where an F4 application is assigned, it is possible to define any number of dependent fields to be copied by default. For example, let us consider the field group OPP_EMPL where the F4 application COMM_BUPA_SEAR is assigned to the field PARTNERID:


Field Group BLView Field Name F4 Application Field Name

OPP_EMPL PartnerID COMM_BUPA_SEAR Partner_FCT

OPP_EMPL PartnerID COMM_BUPA_SEAR Partner_Role

Figure 5.5: Example of Table CRMC_F4_MULTIDEF

5.1.3.6 Changes to MAC required

Where the screentype in ODP is LIST or TREE, there are changes required in the MAC for the Multiple Selection functionality to work properly. When N lines are selected from the Value Help application, this means that (N-1) new rows of data will get added to the ODP. For each of the (N-1) new rows of data, FW generates a GUID to provide a dummy object key. The focus row, i.e. row in the ODC from which Value Help was launched, is also updated with new data.

When the MODIFY method of the IL is called, the following information is provided by the FW:

IT_SCREEN_STRUCTURE contains the updated focus row, as well as (N-1) new rows added with data.

IT_CHANGED_FIELD contains the list of columns modified for every new row of data in IT_SCREEN_STRUCTURE, with dummy object keys in the first column. It would also have an entry for the focus row, which has a real object key provided by the MAC.

CT_OBJECTS_TO_REPLACE contains the dummy object keys created by the FW.

In order to handle several new rows of data, the MODIFY method of the MAC must compare object keys in IT_SCREEN_STRUCTURE with entries in CT_OBJECT_TO_REPLACE. If the entry exists, then this is a new row of data generated by FW in the current server roundtrip.

The application should generate a genuine object key to replace the dummy object key, and append it to the ET_NEW_OBJECT_KEY structure. Thereby, the real object keys are passed back to the FW in the MODIFY method.

5.1.3.7 Context sensitive value help

The current complex value help is not fully context sensitive. It does not consider the information the user has already entered on the screen, If it is present in different screen position or in different line of a list than the field on which F4 is pressed. Thus, the value help often displays result set which are not related in the current context. To make value help context sensitive following points must be improved.

• The complex value help must consider the entries of relevant fields on the calling applications screen as search criteria.

• The value help application should be enabled to set the value in the Search-Shuffler depending on the current context.

• The application should be enabled to dynamically disable the availability of the value help icon for a field.

To implement this feature for any field in the field group following steps to be performed:


1. New field group customizing flag is added the by checking this enables context sensitive

search for a input field. Field group customizing is called “Roundtrip CS Search”.

<Include the figure>

2. Determine the fields to be transferred to the value help application from calling application and create ABAP structure from this fields.This structure is called “Context sensitive screenstructure” (CS structure). Assign this CS structure to the complex value help application which is associated with the input field. This is done in:

Transaction crmc_blueprint

Open the node “Application/Layout node “

Edit the value help application

Enter the name of the structure in the filed “Struct. For Context-Sensitive srch. Help ” (F4_CS_STRUCTURE)

3. PC-UI FW takes the CS structure data from the calling application and defaults them in the value help applications advance search screen structure. Include this CS structure to the advanced screen structure of value help application to have the same fields of CS structure and add the corresponding fields for the CS structure to field group of advance search.

4. Implement IF_CRM_BSP_MODEL_ACCESS_IL_2~FILL_F4_STRUCTURE in the calling applications Model Access Class. In this method you fill the value in CS structure which will be passed to the value help application.

IF_CRM_BSP_MODEL_ACCESS_IL_2~FILL_F4_STRUCTURE Importing

IV_F4_INPUTFIELD Type STRING

IV_SCREEN_STRUCTURE_NAME Type CRMT_BSP_SCRSTRUCNAME

IS_SCREEN_STRUCTURE_DATA Type ANY

IV_PARENT_OBJECT_KEY Type CRMT_BSP_OBJECTKEY

IV_F4_SCREEN_STRUCTURE_NAME Type CRMT_BSP_SCRSTRUCNAME

Exporting

ES_F4_SCREEN_STRUCTURE_DATA Type ANY

IV_F4_INPUTFIELD Name of input field on which F4 is pressed

IV_SCREEN_STRUCTURE_NAME Structure Name in which field F4_INPUTFIELD is present. This is the SS assigned to the current Field group.

IS_SCREEN_STRUCTURE_DATA Data of above screen structure.

IV_PARENT_OBJECT_KEY Object Key of the focus object.

IV_F4_SCREEN_STRUCTURE_NAME Context sensitive screen structure name which is customized for value help application associated with the F4_INPUTFIELD.

ES_F4_SCREEN_STRUCTURE_DATA This is export parameter. Fill the data which is to be passed to the value help application.


5. Implement / or enhance if already implemented IF_CRM_BSP_MODEL_ACCESS_IL_2~CHECK_ACTIVE_SHUFFLER in value help applications MAC. This step is optional, With this you will be able to select the correct shuffler based on the context sensitive data passed with new import parameters values to this method.

IF_CRM_BSP_MODEL_ACCESS_IL_2~ CHECK_ACTIVE_SHUFFLER

Importing IS_F4_SCREEN_STRUCTURE_DATA Type ANY

IS_SCREEN_STRUCTURE_DATA Type ANY

IV_F4_SCREEN_STRUCTURE_NAME Type CRMT_BSP_SCRSTRUCNAME IV_SCREEN_STRUCTURE_NAME Type CRMT_BSP_SCRSTRUCNAME

Exporting

EV_SHOWKEY Type CRMT_BSP_SEARCHSHOWKEY

EV_BYKEY Type CRMT_BSP_SEARCHBYKEY

EV_SRCKEY Type CRMT_BSP_SOURCEKEY

ET_SS_CHANGEDVALUES Type TIHTTPNVP

Changing

CT_SHUFFLER Type CRMT_SHUFFLER_TAB

Description of new parameters: IS_F4_SCREEN_STRUCTURE_DATA Context sensitive data which is filled in

FILL_F4_STRUCTURE method. This data is supplied in this method to better assist the application to select the correct shuffler based on the context sensitive data.

IS_SCREEN_STRUCTURE_DATA Data present in the screen position 1 of the value help application. This data is used to select the correct shuffler in the value help application.

IV_F4_SCREEN_STRUCTURE_NAME Name of the cs-screen structure

IV_SCREEN_STRUCTURE_NAME Name of the screen structure present in the adv search of value help application.

ET_SS_CHANGEDVALUES Application are allowed to modify the data in the adv search screen structure based on the cs-data passed to the application to refine their search criteria. In this field they can return the name and value pair table. FW will update SS with this values.

6. CS screen structure should have field called "ERROR_FLAG" with component type CRMT_BSP_F4_CSERROR. When a wrong value is entered in input field and context sensitive value help is called, Applications can use this flag to inform FW that wrong data is present in the field and FW will add an error message to the application log of value help to tell the user that there is wrong data.


5.1.3.8 Remove Value Help Icon at Runtime

If a field is customized in blue print tables to show value help and data is not present for this field,application can instruct the FW not to show the value help icon for this field.

Applications can change some display attributes of the field group fields at run time by passing constant values in the read methods ET_FIELD_ATTRUBUTE parameter. A new value is added to the fixed value range of domain ET_FIELD_ATTRUBUTE which should be passed in the READ method for a field.

New value in the fixed range:

Value Description

D No Value Help

5.1.4 Selection of Multiple Objects

Multi selection is an additional screen type for the result list. Using this screen type it is possible to create applications, where the user can select multiple objects in the result list and invoke an action on them. For example if a list of orders is displayed, there can be a button to bill multiple orders simultaneously. As the available HTMLB Table View control doesn’t allow the concept of multi-selection and focus of one object at the same time, there is no focus object in multi selection result lists. For this reason no ODP can be displayed below a multi selection result list. The following functions are possible for multiple objects:

• Update objects

• Delete objects

• Insert objects

Additional functions on the list like Show selected / Show all or Select All / Select none are provided by the framework automatically. The objects cannot be edited or modified! Editing of multiple objects in a list at the same time is planned for further releases.

The following steps describe how to implement an application with multi selection: • Maintain screen type multi selection for the result list of your application

• Create toolbar events for the actions, which you want to provide for the selected objects

• Implement the corresponding event handling in the model access class method PROCESS_EVENT.

Field group variants will not be supported, as there is no focus key available.

5.1.5 Object Links

For details see section 4.3.4.2.

5.1.6 Favorites

The framework uses Generic Object Services (GOS) provided by SAP NetWeaver for managing favorites. In addition, it is possible to maintain a separate favorite management and transfer the favorites via the method GET_MY_FAVORITES to the result list (see section 4.3.3).


Each time the user navigates to the application, the predefined query called My Favorites is executed. The favorites (objects the user often works with) are displayed in the results list. It is possible to replace this query, My Favorites, which is automatically executed at start-up, by another when the user starts an application. In this case, you must enter the replacement query in field Predefined Query in table CRMC_BL_APPL . If this field is empty, My favorites is executed per default at the beginning.

The UI framework uses the folder concept of the GOS favorites to assign the favorites to an application. In blueprint table CRMC_BL_APPL, each application has attribute Favorites_Folder, where the corresponding folder of the GOS favorites has to be added. A further attribute is the BOR type. At least one BOR type has to be assigned for each application within blueprint table CRMC_APPL_OBJT. This table can be accessed at the topic Object Type Assignment in the blueprint maintenance transaction. If the framework calls the GOS for the favorites, it exports the favorites folder and the maintained BOR type or types. One favorites folder containing favorites with several BOR types can be used for multiple applications, because the BOR types work as filter criteria.

If users add an object to favorites, the framework saves the favorites to the correct folder. To get the correct BOR object type of the object, the method CONVERT_TO_BOR of the model access class is called. If the application has its own favorites management via method GET_MY_FAVORITES, it has to react on the events ADD_TO_FAVORITES and DELETE_FAVORITE separately on its own. These events are passed to the PROCESS_EVENT method. The framework handles the GOS favorites management.

To display the favorites, the framework reads all favorites according to the definition for the folder.. The application has assigned object types. Additionally, the framework reads all favorites of the assigned object types that are not related to a folder. Method CONVERT_FROM_BOR is called for the conversion of the BOR key to the internal object ID.

5.1.7 Status Management

mySAP CRM differentiates between system status and user status. A system status is assigned to a business transaction internally and automatically by the system. It gives information on whether particular business processes are completed, for example if a new document has been created or if a document has errors. A user status, however, is assigned to a document manually by the user and it offers certain additional information such as to be released, released, rejected or delivered.

The status management function of the People-Centric UI supports two status types:

• Only a status field (with a dropdown list box) can be maintained (in the result list or ODP)

• All active user statuses are displayed in the ODP. To set a new status, a line in the ODP is opened for input where only those statuses can be set (in a dropdown list box) depending on allowed business transactions and statuses that were already set.

To set a user status scheme, the application has to provide an input field (if the status scheme has not been set in customizing). Status management will not provide such an input field.

Status history will be integrated in the common history overview.

5.1.7.1 Including Status Management into the Application

For all objects in the result list:

• In the result list, the only status shown for CRM business transaction objects will be the user status. If there is no user status or a status profile has not been maintained, this field will be left blank.


• To implement this, include structure CRMT_BSP_SINGLE_STATUS_OJ in your result list screen structure. In the field group for the result list, mention the field STATUS_KEY as a dropdown field. This has been implemented in the Business Activity application as shown below:

Figure 5.6: Example of Status Management in the Result List

In the ODP:

• For objects to display the status in a dropdown list box (only the user statuses will be shown, as is also the case in the result list), you should include structure CRMT_BSP_SINGLE_STATUS_OJ in the screen structure. For example, if you want to show the statuses as a dropdown list box in the ODP, then include this structure in the screen structure and define field STATUS_KEY as a dropdown list box in the field group.

Figure 5.7: Example of Status Management in the ODP

• For objects to show all the statuses under the status tab, create your own structure that includes the following two structures:

- CRMT_BSP_OBJECTKEY

- CRMT_BSP_MULTIPLE_STATUS_OJ

Assign this screen structure to the tabstrip in the blueprint table. This will allow you to see all the statuses that are currently active for this business object. Further status details also appear (see Figure 5.6).


Figure 5.8: Example of Status Management in a Tab

For the scenario mentioned above, you will have to include toolbar group STATUS_ODC in the blueprint tables for this tab. This toolbar group provides two buttons that allow users to set or delete a status. When the user chooses New Row, a new line appears and all possible statuses for maintenance appear in the first column.

Users can only add and delete lines in status management; they cannot change an existing status.

If there are objects in which the user should be allowed to maintain statuses such as “Blocked for Billing” or “Blocked for Delivery”, the toolbar group STATUS_BLK has to be added to the toolbar. Additional buttons such as Reject, Billing Block, Delivery Block and Credit Release then appear in the toolbar. The screen structure remains the same as defined previously, but two additional fields have to be maintained in the field group. These fields show the reason for the status (see Figure 5.6).

For examples of status integration, please refer to CRM applications Business Activity (CRMD_BUS200126) and Quotations (CRMD_SALQ).

Figure 5.9: Example of Status “Blocked”

In case the business object should display the SAP R/3 status and the item total status at the header level, it can appear in ODP 2 (see Figure 5.7).


Figure 5.10: Example of Status in ODP 2

To achieve this, users must define an entry in the blueprint table for ODP 2 for the application as follows:

• If you are dealing with a business transaction object, assign model access class CL_CRM_BSP_AM_HEADOM_1O to structure CRMT_BSP_HEADER_ODC2_STATUS . Otherwise, assign your own class to it.

• Create a new entry for your application in the main blueprint with the following details:

- Event STATUS_DETAIL

- Position ODP 2

- Screen Element Type FORM

- Field Group STATUS_HEADER_R3_TOTAL_ITEM

- Tab Group STATS_ODC2

For business transaction objects only the above-mentioned table entries have to be maintained. For other objects, you need to fully understand the classes that are implemented for the status management and call the appropriate methods within your model access class.

5.1.7.2 The Generic Parts of Status Management

The generic status management for the People-Centric UI is implemented with the following classes, methods, and functions:

Model Access Class CL_CRM_BSP_INTLAY_STATUS with the following methods:

• Fill_dropdown_listbox: Depending on the request (that is, whether the interface name is “USER” or “SYSTEM”) this method responds with the relevant statuses that are currently maintained in the system. Depending on the call, it may also respond with a status that now can be maintained. For example, in the ODP, the user chooses New Line.

• GET_DATA: Lists the currently active statuses with the details as to who activated them and when.


• PROCESS_EVENT: Called when there is a line deleted or when a special status that can be maintained using the buttons in the toolbar is called.

• APPL_REQUEST_DETERMINE: Private method that determines which kind of statuses that the user has requested. There can be two values: “SYSTEM” or “USER”

• PUT_DATA: Gets all the data from the UI and stores it in the global tables.

• READ_STUS_TEXT_CUSTOMIZING: Private method that reads the text that the user has maintained in the system for the special statuses that are maintained using the buttons.

Functions: The methods call the functions internally from the function group CRM_BSP_STATUS_IL:

• CRM_BSP_GET_BILLING_STATUS: Gets the billing status data if it is set for the current object. Also this is used to get all possible values for reasons that can be set for the billing status.

• CRM_BSP_GET_CREDIT_STATUS: Reads the current active credit status if it is maintained.

• CRM_BSP_GET_DELIVERY_STATUS: Gets the delivery status data if this is set for the current object. Also gets all possible values for reasons that can be set for the delivery status.

• CRM_BSP_GET_REJECT_STATUS: Gets the reject status data if this is set for the current object. Also gets all possible values for reasons that can be set for reject status.

• CRM_BSP_STATUS_GET_TOOLBAR_BTS: Gets all the active toolbar buttons.

• CRM_BSP_STATUS_GET_UI_DATA: Gets all the data that was set using the PUT_DATA method.

• CRM_BSP_STATUS_MAINTAIN_DLVBLK: Called when you choose Delivery Block in the toolbar. Gets the data from the UI for the delivery block and passes it to the interaction layer.

• CRM_BSP_STATUS_MAINTAIN_REJECT: Called when you choose Reject Block in the toolbar. Gets the data from the UI for the reject block and pass it to the IL layer.

• CRM_BSP_MTN_BILLING_BLK: Called when you choose Billing Block in the toolbar. Gets the data from the UI for the billing block and passes it to the IL layer.

• CRM_BSP_MTN_CREDIT_BLK: Called when you choose Credit Block in the toolbar. Gets the data from the UI for the credit block and passes it to the IL layer.

• CRM_BSP_STATUS_PUT_UI_DATA: Takes data from the UI and passes it to the IL. The data is entered in the global tables, which in turn is accessed by function CRM_BSP_STATUS_GET_UI_DATA.

• CRM_BSP_STATUS_REASON_DD_GET: Gets all the reason dropdowns for all the statuses.

• CRM_BSP_STATUS_SET_TOOLBAR_BTS: Sets which buttons are to be active and which are to be inactive in the toolbar.


5.1.8 Generic export of search result lists

The PC UI offers since version 5.0 the export of search result list primarily of OIC content to the local disk of the user. In case the CRM Service framework is available in the backend system, this can be done in “Formatted Lists” consisting of XML which fully integrates into Microsoft Excel (and only there). This feature can be triggered from the PC UI but it is available only when the XML providing componets are present. The PC UI would offer in such a case to choose a certain template/formatting, open the list in the local user’s Excel application, work on it and even save the changes back to the server. The formatting of a list for the XML format can actually become quite rich according to the formats the administrator provides for his users. For details about this format, please refer to the documentation about the CRM Service framework.

The default-download format, which is always available also without the XML providing components, is the CSV format. This is a flat-file format, which contains the mere data from the search result list and no formatting or other additional MIMES. This format is a pure text file (ASCII, if not specified differently) which can easily be imported e.g. in Microsoft Excel and Access, as well as numerous other applications on various platforms, not only Windows. Since it does not contain other data than characters, we also call it the “Unformatted list”.

The framework provides three framework specific events, which can be added to the applications toolbar to execute the creation of the download file:

PCF_DL_CSV triggers only and directly the download of a CSV file (“Unformatted list”). PCF_DL_XML triggers only and directly the download of an XML file (“Formatted list”). PCF_DL_EXPORT triggers the default format for download, which is the XML format. Only in case XML is not available or when the user has customized to always use CSV, not the formatted list will be provided but CSV.

5.1.8.1 Customize your application to use download of lists

In the Blueprint Customizing, go to “Application Element” “Toolbar” and choose the toolbar of your application. Assign here one of the above mentioned events (PCF_DL_CSV, PCF_DL_XML or PCF_DL_EXPORT) in the way you have learned it in the blueprint customizing documentation about toolbars.

You can have further influence on the default download behaviour of the resulting CSV files when you continue the blueprint customizing like this:

1. Go to “Characteristics of Versions” and choose your work area, which is usually your web application.

2. Do your view, version and floorplan customizing here

3. Go to “Characteristics of view” in the root menu of the blueprint customizing.

4. Choose here again as workarea the application+view you defined in the step before.

5. In the upcoming list please find the following columns which are of interest for the CSV customizing:

a. Code Page: Choose the code page in which the resulting CSV files are to be written. This ought to be different in the US or in China, for instance. Choose the codepage your users are most likely to use.

b. Max Lines: For security reasons the number of downloadable lines can be restricted to the amount that was entered here. When nothing is entered, there are no restrictions to the number of lines that can be downloaded.

c. Column Separator: By default this is the char “;”. If, for any reason you should need to use this character within the data of your coluns, this char cannot be used


any more as an indicator for columns. So you can use here any other printeable character. You maybe should make sure that your users are aware of this.

d. ZIP Compression: Activate here a feature you might need when you allow your users to download a huge number of entries. In order to save on bandwidth and increase portability, the resulting CSV file will be g-zipped and offered as a binary file to the user. This file can then only be opened with an uncompression utility as they are freely available in the internet. The g-zip algorithm should work very effective especially on text files as CSV is one and offer a very good compression ratio. Please note that some prerequisites are to be fulfilled before the compression feature actually is available:

i. The application server, on which the web application is running, must support compression. Please consult your application server user guide about how to ensure this.

ii. The clients Request-Header '~server_protocol' must contain 'HTTP/1.1'

iii. The clients Request Header 'accept-encoding' must contain 'gzip'.

iv. When the client is using Internet Explorer as a browser, the length of the URL must not exceed 256 characters. This is a known limitation of the Microsoft Internet Explorer and addressed in SAP note number 796354.

e. Comment: You can write here a special comment, maybe of legal content, that is appended to each file that is downloaded. A certain hint like “Downloaded from your company XY. Do not spread.” could make sense here for you.

5.1.8.2 How each user can influence the download format

Each user is enabled to choose the download format he prefers. This is done using the “Settings” link next to the “Advanced Search” button in the Search Request controller. A dialog is brought up with this link which offers to check the “Always use unformatted list format (CSV) for download” feature. If checked, always the CSV format will be downloaded when the triggered event is PCF_DL_EXPORT.

5.1.8.3 Issues to be aware of when using the list download feature

There are a few things that have to be obeyed in order to use the download feature without problems:

1. Since the download must be triggered in a JavaScript created popup-window, users must not use popup blockers in there browser when they want to use the download feature.

2. There are some prerequisites to fulfill when using the compression functionality. For details please refer to page 130, cond. d above.

3. Basically it is better or “more save” for users to first save the downloaded file to their disk prior to loading them into their local application. Especially when using CSV format, importing the files offers more flexibility in handling this file format: Users should go, for instance in Microsoft Excel, to Data Import External Data Import Data and choose the CSV file they just created. In the wizard screens that come up after that they can set the appropriate file encoding, the column separator to use, and where to insert the data into the current sheet.


5.1.9 Standalone OIC and ODC

The Standalone OIC and ODC, later renamed to OIP and ODP (Object Identifcation Pattern and Object Detail Pattern), is also known as “New Floorplan”.

The New Floorplan consists of several changes that have some impact on the whole appearance of the PC UI. The biggest change you can see at once in the New Floorplan is the fact that no ODP is displayed any more below the OIP once a certain object was selected. Because there is more place now for the search result list, the default number of entries was raised to 20. However, this default can also be changed in the blueprint customizing: Go to Application Element Field Group. In your field group scroll to the very right and you will see the columns “No. of Lines” which sets the default number of enries in the Multiedit ODP and “No. Lines SRES”, which sets the default number of entries for the Search Result Controller. Users can also determine themselves what number of entries they wish to have per page. (See 5.1.9.4 [page 131] below). Since the length of the page can vary now, the “Maximize” and “Minimize” buttons on the right top coner of the applications became obsolete and are removed for the New Floorplan.

Another minor change is the fact that the form/list toggle button is removed in the New Floorplan. For technical reasons it remaind only available for the tree views.

Please find a description of more changes in the below sub-sections.

5.1.9.1 Searching

In the New Floorplan, the simple or “Get” Search is no longer available because this was replaced by the “Google Like” Search which resides in another web application that is available in the portal. An explicit search within the PC UI is now triggered only via the Advanced Search, which is still a part of the Search Request Controller.

5.1.9.2 Default selection of objects

After a new search was triggered, an object is automatically selected only when it was the only result of the search. When more than one object is listed in the search result list, none of them will appear selected. This change is also performed for the Old Floorplan.

5.1.9.3 Navigation

For more information, see section 5.1.11.

5.1.9.4 User Settings

Just like in the versions before, there is a Settings link to the right of the Advanced Search button which offers since 5.0 development some more settings:

Choose the default entry in the Show dropdown: Is an old option from former releases in which you can set the default search which is executed when the search result list is empty. To be able to choose between searches, the user has to save an advanced search he triggered before under a certain name.

Always use unformatted list format (CSV) for download: As already described in section 5.1.8 above, this option make sure that upon availability of the Download Button for exporting a search result list always the CSV format will be used rather than the XML format.

Maximum Number of search results: Specify here the total number of possible search results per search. Setting this to 0 means to reset the last set value. This setting appears enabled only when the MAC has implemented the corresponding interface.


Number of entries per page of search result list: Set here the number of entries you want to have displayed per page in the search result list. Setting this to 0 means to reset this value to its default. This value will only be taken into account when the New Floorplan is used.

5.1.9.5 Hitcounter

The “hitcounter” or “item counter” is a new display feature next to the left of the paging mechanism in the views of the following sub controllers:

1. Search Result List (searchres.htm)

2. Multiselect controller (multiselect.htm)

3. Multiedit controller (me_detail.htm)

In those sub controllers that allow multiple selection of objects, the hitcounter reads as “x items (y selected)” while in flat result lists like the search result list you only get the number of hits that was created by the search.

5.1.9.6 ListManager and StateManager implementation

This is a new major development for the PC UI which is explained in a separate chapter of this book.

5.1.10 Generic Grouping DropDown Buttons

This is a new floorplan independent development available since PC UI 5.0. Its aim is to group all the single events that render as separate buttons in the toolbar, cluttering it up. Now single events, when grouped in EvenGroups in the blueprint customizing can show up as menu entries in a popup. The popup is triggered by this new button wich replaces the “New …” or “Create …” event. The popup can even consist of sub-menus which again group Event Groups having single events of similar kind. For details about this please refer to the last paragraph of the “Adding Toolbars” section Fehler! Verweisquelle konnte nicht gefunden werden..

5.1.11 Enhanced UI Pattern in CRM 5.0: new Floorplan

The new Floorplan is designed for mySAP CRM 5.0. It is a general interaction and navigation concept for PCUI. The main reason for designing a new Floor plan is the intention to improve the User Experience of mySAP CRM 5.0.

The wording OIC – Object Identification Container- has to be changed to OIP where the ‘P’ stands for Pattern. The separation of OIP and ODP is the core change in the new Floor plan.


Figure 5.11: OIP List

The main function of the OIP is to provide a search to find items and after that list them in a result list. The user is able to navigate to details, summary or fact sheet view of the application.

Figure 5.12: Separated ODP with Header

5.1.11.1 General navigation possibilities

CRM 5.0 applications consist of a set of portal pages and views: the BSP application with List and Details view, the Summary page and the Fact Sheet page. Navigation should be possible from all pages and views to all others.

Using buttons in the list view toolbar the user can navigate to Details, Summary or Fact Sheet page of an object. Due to the fact that List and Details will be separated in the new floor plan but displayed on the same portal page, navigation is necessary from List to Details area and vice versa.

Summary and Fact Sheet pages are implemented on separate portal pages. Therefore navigation within the portal has to be executed to reach theses additional pages. The header will be displayed on the top of theses pages and there are the same navigation possibilities included as in the OIP.


5.1.11.2 Internal Link

For every application exactly one field has to be defined as hyperlink field in the OIP search result list that navigates to the ODP or Summary page of this object. This hyperlink field will be displayed like a hyperlink.

Figure 5.13: Internal Link: switch to Details

Unlike the Summary or Fact Sheet page the ODP will not be shown on a separate portal page. It shares the same portal page with the OIP and is able to switch between OIP and ODP. Once it will be shown in the same portal page as the OIP this hyperlink field is not realized as a standard hyperlink within the portal. But the link is triggering a BSP Event that executes the necessary action to switch from the OIP to the ODP. This link will be called “internal Link” and can be customized within the object link information of the field group.

Therefore the object link information of the field group will be extended with an additional flag “internal Link to ODP” which indicates that the link leads to the ODP. If the flag is checked then the link triggers an navigation and the application displays the ODP of the object with the header area. If the flag is not checked then the object link information should be set up in order to navigate to the Summary page.

The link field should always be non editable in the resultlist to avoid that the link field could be changed in the resultlist by the user. Therefore the field has also to be marked as “non editable” in the field group customizing.

Limitation: Once a field is customized as internal link then the link belongs to all applications which are using this field group in the OIP. Otherwise a new BLView has to be created for the application and the field group has also to be duplicated. So the internal Link field can be differentially customized for distinct BL Views.


5.1.11.3 Navigation attached to a button

Other navigation possibility is navigation attached to buttons that are placed in the tool bar of the OIP. It should be the possibility to navigate to the OIP, Summary or the Fact Sheet page of the object.

Figure 5.14: Goto Button Navigation possibilities within the new floorplan

The navigation to Summary and Fact Sheet page is also a navigation within the portal and will be archived by customizing the appropriate button event with the object link information. The navigation to the ODP will be handled like in the hyperlink case: a BSP event is triggered to switch from OIP to ODP.

There are system-events regarding navigation defined in the CRMC_BSP_EVENT table. The following system events are available:

System Event

Description

EDIT_DETAILS

Switch to the ODP (BSP Event) or navigate to the ODP

SHOW_LIST Switch to the OIP (BSP Event) or navigate to the OIP

SHOW_SUMMARY Navigate to the Summary Page of the object SHOW_FACTSHEET Navigate to the Fact Sheet page of the object GOTO Root event for the new generic DropDown List

box

Each application toolbar has to be extended with the system events in order to fulfill a correct navigation to the targets. These events will not be automatically added to the toolbar of the application. Therefore it is the duty of the application customizing to enhance the necessary events to the toolbar.

All buttons in the OIP regarding navigation should be grouped into a Generic Grouping Dropdown Button (formerly known as popup trigger). The GOTO event is the generic root of the DropDown List Box button and should also be used in the toolbar customizing – see customizing documentation of the Generic DropDown Listbox.

The next table shows the system events and the navigation techniques the framework is using to trigger the navigation. The events are shown in bold. Internal Navigation is triggering an event to switch to another view. Portal Navigation happens within the portal to reach another portal page.

Target page

OIP List Details Summary Page Fact Sheet Page


OIP List X

EDIT_DETAILS

Internal Navigation

SHOW_SUMMARY

Portal Navigation

SHOW_FACTSHEET

Portal Navigation

Details SHOW_LIST Internal Navigation

X

SHOW_SUMMARY

Portal Navigation

SHOW_FACTSHEET

Portal Navigation

Summary Page SHOW_LIST Portal Navigation

EDIT_DETAILS

Portal Navigation

X

SHOW_FACTSHEET

Portal Navigation

Fact Sheet Page SHOW_LIST

Portal Navigation

EDIT_DETAILS

Portal Navigation

SHOW_SUMMARY

Portal Navigation

X

As you can see EDIT_DETAILS and SHOW_LIST events are internal navigation in case of switching between List and Details. In all other cases these events have to trigger a portal navigation to reach the List or Details view of the application. Therefore the object link information has to be maintained.

The SHOW_SUMMARY and SHOW_FACTSHEET events are always navigation within the portal and therefore the Object Link Information has also to be maintained to the corresponding portal page.

5.1.11.4 System Event Redefintion

Since each application will use the same system event regarding navigation, these events must be redefined for each Application and BL View. A new table CRMC_BSP_EVENT_R is therefore created to redefine the navigation events with Application and BL View parameter.

This table is a copy of the CRMC_BSP_EVENT table, but the table key is enhanced with Application and BL View attributes. The Application must redefine the above mentioned navigation events with the object link information to the corresponding pages. A customizing view is available in the Blueprint transaction and called Event Redefinition.

5.1.11.5 Object Header Area

The Object Header Area is a design pattern of the new floor plan. The <Details> part of an application consists of an Object Header Area and an ODP. The <Summary> part of an application consists again of an Object Header Area and the <Summary> information blocks.

Goal of the Object Header Area is to show the identified object (unique identifier) and carry out actions for the identified object. In addition this Area has to be consistent for the user while maintaining the data of an object and when looking at the <Summary> data of the object.

5.1.11.5.1 Parts of the Object Header Area

The Object Header Area has a title bar, a header bar and a toolbar.

Object Header Area with definition of the areas:


5.1.11.5.1.1 Title bar

The title bar displays the regarding CRM application.

5.1.11.5.1.2 Header bar

The header bar identifies the selected object (identifier – this doesn’t have to be and often cannot be unique, but it should provide attributes to the object in focus that help identifying the object). In the header bar the key identifying attributes of the object are displayed. The user can check at one glance the appropriate object he is located at. Every application has to define the main attributes.

The maximum number of fields/attributes used for the unique identifier is not limited, but the maximum length must not exceed one line, so no line break may appear in this header bar. In case a user creates a new object the header information displays the text “New <Application Name>”. Please see picture below:

Object Header Area when creating a new object

5.1.11.5.1.3 Tool bar

The toolbar of the Object Header Area contains a certain amount of buttons as well as the record counter.

The buttons will be held consistent in both pages - <Details> and <Summary>. This also means that buttons not needed on one page but on the other should also be visible but grayed out. The reason for a consistent and fixed sequence of buttons is to keep the screen calm. Users expect the buttons on the same place. The probability to hit the expected button with the cursor is higher for the user.

Toolbar Object Header iView in <Summary> Page

Toolbar Object Header iView in <Details>

The following events will be provided from the generic framework:

• Show List: This event is for navigation to <OIP>.

• Show Summary: This event is for navigation the <Summary> page.

• Show Fact Sheet: This event is for navigation to the <Fact Sheet> page.

• Edit Details: This event is for navigation to <Details>.

• New: This event is for creation of a new object in the <Details> area.


• Save: This buttons saves the object.

• Add to Favorites / Remove From Favorites: Adding or removing the object to / from the favorites list.

Application specific buttons can and have to be added to carry out actions for the object marked in the list. Every application has to decide which buttons should be available in the tool bar of their Object Header Area (for <Summary>, <Fact Sheet> as well as <Details> page).

Also for application specific buttons the rule applies that they should be held consistent, same place and order of buttons in both pages. If a button is relevant for one page but not the other it should be still available but grayed out where not needed.

The Record Counter is a counting mechanism for items and is situated at the end of the toolbar. It is held consistent for all pages, <Details>, <Summary> and <Fact Sheet>. If there is a result list of the <OIP> cached in the background, the user can navigate between the Items of the <OIP> List. Via the Record Counter the user only navigates up & down through the <OIP> List.

Record Counter in object header area

5.1.11.5.2 Customizing

5.1.11.5.2.1 Application / Layout

The definition of an OHP requires one additional entry in the Application / Layout section (transaction crmc_blueprint):

Property Value

Application <your application name>

View <your blview>

Event INIT

Position Header Area (‘H’)

Screen Variant <your screen variant>

Screen Element Type The same screen element type as in screen position 2 has to be used.

Field Group The filed groups specified here must be based on the same MAC as the filed group used for screen position 2 and screen position 3, event INIT

Toolbar Group <your header toolbar group>

… …

The customizing for screen position 2 and screen position H are very similar. They may not differ in the screen element type and they must both use field groups that are building on top of the same Model Access Class. This is imported to support the use cases CREATE and SAVE.


5.1.11.5.2.2 Field Group

In the Field Group Structure, two new properties are introduced with the new floor plan in CRM 5.0: • Not in Header • Key Field

“Not in Header” has the same meaning as the previously existing properties “Not in List” and “Not in Detail”. Fields having this flag set will not be displayed in the object header area. Fields having this flag cleared will be displayed in the object header area.

“Key Field” identifies this field to contain the key or logical key for the object in focus. The contents of this field will be displayed enclosed by parentheses and at the very end of the identifier text in the header bar.

5.1.11.5.2.3 Toolbar Group

A new property is introduced in the Toolbar Group with the new floor plan in CRM 5.0: • Event Not Used in ‘Detail’ View

Toolbar group entries having this flag set will not be displayed in the object header area. Toolbar group entries having this flag cleared will be displayed in the object header area.

5.1.11.5.2.4 Event Definition / Event Redefinition

The Object Header Area offers navigation to a variety of targets. As with previous versions of the PCUI Framework, this navigation can be triggered by a server side event (Framework event), which is offered to the user in the form of a button. The button’s navigational behavior is configured via the event customizing in transaction crmc_blueprint (table CRMC_BSP_EVENT).

For some events that are considered standard, the OHP may be source and target of the navigation. E.g., when navigating from the Details page to the Summary page, the OHP is part of both pages should only offer the navigation possibilities that actually make sense. When the Summary is shown, the SHOW_SUMMARY event should not be offered to the user. When the Details page is shown, the event EDIT_DETAILS should not be shown, when on the Fact Sheet page, the event SHOW_FACTSHEET should not be available to the user. Therefore, all events where the OHP can be source and target of the navigation need to be system events that are known to the PCUI Framework. In combinations with the view mode, OHP can offer or hide/disable senseless options.

However, each application needs to specify its own navigational properties for an event. This conflict, the event needs to be a system / predefined framework event and an application defined event, is solved with the introduction of event redefinition. The main part of this new concept is the new table CRMC_BSP_EVENT_R with the following fields:

• EVENT

• APPLICATION

• BLVIEW

• All fields of structure CRMT_BSP_EVENT_DAT, including definition of navigation

With this new table it is possible to redefine an existing event from CRMC_BSP_EVENT per APPLICATION – BLVIEW tuple. The predefined system events for navigation from OHP are:

• SHOW_LIST

• SHOW_SUMMARY

• SHOW_FACTSHEET

• EDIT_DETAILS


If one of these events is to be included in OHP’s toolbar, there has to be an entry in CRMC_BSP_EVENT_R that redefines the navigation behavior for this application and view.

Other events should be entirely defined in table CRMC_BSP_EVENT. For these events, there is no need for redefinition.

5.1.11.6 New design of the advanced search involves the removal of ‘By’ shuffler.

Understanding the functionality of the Advanced Search is difficult for users. This was found in several usability tests and is also frequently reported as feedback from customer projects.

One of the main problems is that users fail to understand the functionality behind the first two available Shufflers. The values in these Shufflers determine which fields are available to formulate the search restrictions.

The main problem with the current solution is that the user has to search in the By-Shuffler to find the right field combination to formulate his search request. There are also scenarios in which natural search requests can not be formulated properly because the necessary fields do not occur together on one of the available search screens.

Search-Shuffler By-Shuffler

The displayed search fields depend on the entries in the two dropdowns. Thus, the displayed fields are changed when the user changes the entries in Search- or By-Shuffler.

Some applications use a third shuffler (Source-Shuffler) which determines if the search is performed on the DB or in archived content. The Source-Shuffler does not influence the displayed search fields.

To solve this problem only the Search-Shuffler should be remaining if the user can search in one OIC for different types of objects (like in Accounts where it is possible to search for persons, organizations or groups). All fields from the 'By'-Shuffler should be combined into one search screen. The Search-Shuffler should be used exclusively when in one OIC a search for several object types is supported. If this is not the case for an application also the Search-Shuffler should be dropped.

In addition there should be a possibility to group different search fields inside the Advanced Search to offer the user a quick orientation.

Remark: If this solution is implemented it will also solve an additional annoying problem with the current search functionality. Assume that a user has entered several values in the advanced search, then recognizes that one field is missing and thus changes the shuffler. The new form for entering the search restrictions is now totally empty, i.e. even if the same fields for which he has


entered values before are again on the screen he has to enter the values again. Users very often complain about that.

The framework has to allow the applications a possibility to decide if:

• Only the Search shuffler is displayed

• Only the Source shuffler is displayed

• Only the Search shuffler and the Source shuffler are displayed

• None of the shufflers are displayed Only the Search shuffler is displayed:

Search Key By Key Source Key

search1 - -

search2 - -

search3 - -

search4 - -

This will display only Search ddlb with four entries (namely: search1, search2, search3, search4).

Only the Source shuffler is displayed:


search1 - src1

search1 - src2

search1 - src3

search1 - src4

This will display only Source ddlb with four entries (namely: src1, src2, src3, src4).

Only the Search shuffler and the Source shuffler are displayed:


search1 - src1

search1 - src2

search1 - src3

search2 - src1

search2 - src4

This will display Search ddlb with 2 entries and Source ddlb with 3 or 2 entries depending on the selection in Search ddlb.

None of the shufflers are displayed:


search1 - -

No shuffler ddlb will be visible.

PCUI provides a feature to save the search criteria under a name. This can be reused later by selecting in Search-ddlb. User-defined search criteria is termed as Variants. These variants can be made available to all users by running a report (available via customizing). This is termed as


Query. Query and variant table stores the saved search values as an xstring and the shuffler state is saved as SEARCHID. SEARCHID is created as showkey?bykey?srckey.

It is quite possible that the customer has some self defined shuffler definition. These will have the customizing entries for By-ddlb. To make sure that this still works fine, the complete rendering of by-ddlb will not be deleted from the code but it will be made independent of Search-ddlb. An information message will be displayed on the UI, if ‘By’ is still available in customizing tables.

Any old sap delivered query will get corrupted by changing the advanced search structures. Applications have to delete old predefined query and create new ones.

If customer has maintained any query with (old) sap delivered shuffler definition, then this will be corrupted with the migration to 5.0 from 3.1 and 4.0.

If customer has maintained any query with the self customized shuffler definition, then this will be safe. But an information message will be displayed on the UI, if ‘By’ is still available in customizing tables because the query still has the old design.

5.1.12 Time-Control

In CRM 5.0 there is a new fieldtype called time-Combobox which is similar to a dropdownListBox(DDLB) with the added feature of being editable.

It is based on the htmlb:comboBox and is typically used to show a list of time for the user to choose from.Unlike the DDLB the user can also type into this field.

(The fieldtype comboBox is also new and has same features as Time-Combobox).

When the user wants to show a time control then she can choose a new field type ‘TIME’ to show time as can be seen below.


5.1.12.1 Sending list of values from application to framework

As in a dropdownListBox the framework uses the method fill_dropdown_listbox to get the list of values from application in a tabular form based on the structure CRMT_DROPDOWNLISTBOX_DATA.

Let us suppose that the application wants to show all the hours of a day in a field called Starttime i.e. the contents of the drop down list is 01:00,02:00……………………….24.00

Then the application will provide the data in the form of structure CRMT_DROPDOWNLISTBOX_DATA with the value as follows :

FIELDNAME = StartTime

KEYCOLUMNNAME = ST_key

VALUECOLUMNNAME = ST_Value

VALUE2COLUMNNAME =

DATA = The following internal table


DATA

ST_Key ST_Value

01:00 01:00

02:00 02:00

. .

. .

. .

24:00 24:00

Let us suppose that as in MS-Outlook there is a Endtime field which shows time along with an interval e.g., 11:30( 30 minutes ), 12:00 ( 1 Hour) , 12:30 ( 1.5 Hours ) etc.

Then the values will be :

FIELDNAME = EndTime

KEYCOLUMNNAME = ET_key

VALUECOLUMNNAME = ET_Value

VALUE2COLUMNNAME = ET_Value2

DATA = The following internal table

DATA

ET_key ET_Value ET_Value2

11:30 11:30 ( 30 minutes)

12:00 12:00 ( 1 Hour )

12:30 12:30 ( 1.5 Hours )

24:00 24:00 ….

5.1.12.2 Editing the Time-Combobox

Let us suppose that the fieldgroup FG1 has a field STARTTIME whose fieldtype is TIME.The structure on which this field-group is based is ST1.

Then this structure ST1 should also have a field in it called STARTTIMEVALUE.(This field only needs to be in the structure and need not be in the field-group).

This field needs to be there to capture any value that the user may type into the TIME field.

Example :

STARTTIME has a list of values as follows – 11:00,11:30,12:00,12:30,13:00 etc.

Then when the user selects a value from the list (e.g., 11:30) then the behaviour is exactly the same as for a dropdownlistbox (DDLB) .i.e., in the modify method ,for screen-structure ST1 the field STARTTIME = 11:30 .


If the user now types in a value , 12:22 then in the modify method ,for screen-structure ST1 the field STARTTIME will be blank while STARTTIMEVALUE = 12:22 .Thus the field STARTTIMEVALUE is used to pass the value from framework to application .

Application can then set the STARTTIME based on this .If application wants that this value 12:22 should also appear in the drop-down list then it can add it to the list and pass it to framework using the method fill_dropdown_listbox.

5.2 Special User Interface Components for Building Views

Several UI components can be used in addition to the simple list and form presentations inside the views of the OIP. The integration of these components is described below.

5.2.1 The MultiEdit Controller

With the MultiEdit controller the framework provides the functionality of selecting and editing multiple entries of a list in Result List or ODP simultaneasly.

The concept of a focus key is only used to determine the parent key for the controller below the current controller (and maybe to display the messages details for this object, but this is still open).

In order to use the multiedit controller with the new functionality, the applications have to do the following:

• Selected keys: The following methods contain the table IT_SELECTED_OBJECT_KEY. In the multiedit controller this table contains all selected entries. The focus object will typically also be filled in the interface in the corresponding field, if it existed before in the interface. The application can now use the information of the selected keys to perform a function triggered by an event Attention: The focus key does not necessarily have to be selected.

PROCESS_EVENT

FILL_EVENT_GROUP

• Changed objects In the method PROCESS_EVENT the application has to tell the framework for Result List, which objects were changed. Therefore the parameter et_changed_objects has to be filled with the corresponding keys. Only these objects will be read again.

• Inserted and deleted objects In method PROCESS_EVENT there are two new export parameters ET_INSERTED_OBJECTS and ET_DELETED_OBJECTS. With these you can tell the framework about new object keys that have to be inserted or object keys that should be deleted. For the inserted objects the framework will append these to the current objects and read the data with the next read call. For the deleted objects the framework will just delete these entries from the data context without informing or asking the application again.

• Replaced objects In case the framework created new objects because the user hit the button ‘Add


page’, the object keys are generated by the framework. In order that the application knows in the method MODIFY, that these are new objects, these keys will be imported via table ct_objects_to_replace. The application then has to create their own object keys and change the table accordingly. This way the framework is able to replace the object keys in the data context.

• READ Method There is a major change in the locking mechanism that has to be used: If optimistic locking is available: In Multiedit controller always optimistic locking must be used. This is a rather new basis feature in locking. The fundamental concept of optimistic locking is, that an object is not really locked. Any other session can lock this object exclusively. But then the optimistic lock is lost. This way an application always knows, if the buffer is still correct or if in the meantime someone else potentially changed the object on database. That means, all objects that are read have to be locked optimistically. If any change is performed on an object (via modify- or process_event-method) an exclusive lock has to be set on this object. Now there are different possibilities:

- Exclusive lock can be set Proceed with the changes

- Object is already exclusively locked by another session Discard changes, set fields to not ready for input, put a message to applog

- Optmistic lock was lost in the meantime Discard changes, keep fields open for input, put a message to applog, read

object again from database to buffer

If optimistic locking is not available: For Result List the READ-method will be called with the flag IV_LOCK set for all objects, that are visible, for all objects that are selected and the object in focus. The object in focus must be part of this list as in ODP below the fields might be ready for input for this object. The application can then lock these objects.

If no change occurred for an object and this object is not part of the list within the next round trip, the application can unlock this object again. The Read-method with the parameter IV_LOCK will always be called, no matter if optimistic locking is available or not.

• CHANGE-Event If the event ‘CHANGE’ is given in method PROCESS_EVENT, all selected objects have to be locked exclusively. Objects that cannot be locked exclusively, have to be set to not ready for input and a message has to be put to the application log.

• Deletion If deletion is requested by the user, then first the CHECK_BEFORE_DELETE method is called for all selected entries. If at least one object cannot be deleted, then the


deletion process will be stopped.

• Fill Dropdown Listbox content The method GET_ALLOWED_DDLB_VALUES which has to be used in the model access class for filling the dropdown listbox values. The reason for this is that from now on all dropdown listboxes in a list are really rendered and therefore all dropdown listbox tables must be sent to the client. With this method the framework can handle significant performance measures to be able to really send only those data to the client which are necessary. This method has as parameter the followoing: - IT_OBJECT_KEY: The object keys for which dropdown list box values are needed - IT_DEFAULT_DDLB_VALUES: Default values from domain - IV_SCREEN_STRUCTURE_NAME: name of screen structure - ET_CHANGED_DDLB_VALUES: Table with changed dropdown list box values. The key for this table is the object key. Fill this table only with object keys, for which you want to have different value tables in the dropdown listbox.

• Choose the right screentype in the main blueprint table SRME for Result List MEDL for ODP

• Field attributes in ODP lists: If you want to set field attributes for all entries in lists in ODP, you can fill the field attribute table with an initial object key and the corresponding field attributes. In case there is no special entry with the object key of an entry, the line with initial object key will be used.

• Check_Active_Toolbar In method CHECK_ACTIVE_TOOLBAR there is a import parameter IT_OBJECT_KEY which contains the selected object keys. This way the application can determine if buttons should be active or not depending on the current selection of objects. If the user selects other objects, only after a new roundtrip the buttons are activated/deactivated.

• Get_Messages In method GET_MESSAGES there is a new import parameter IT_OBJECT_KEY which contains the object keys, for which messages should be displayed. The application must collect all messages for all these object keys.

• Applications as F4 help Attention: F4 help does not support multiple line selections and therefore the multiedit controller is not suitable for F4 help!

If your application is used as an F4 help application by any other applications and you want to introduce the multiedit controller in the search result list, then you have to provide another application with the single line edit mode in the search result as an F4 help application. The depending applications have to use this new one for their F4 help.

• Defaulting of Empty Lines

It is possible to customize the field-group being used for the Multi-edit so that when the LIST is shown in ODP it will always have a number of empty lines where the user can directly enter data without having to click on the “Add Entry” button.

The customizing is done in the blueprint table CRMC_FIELDGRE by setting a value for NumberOfLines which decides the page size and also the number of empty rows available by default .

Example :


Let is suppose that for a fieldgroup G1 the numberofLines is set to 10.When the ODP with this fieldgroup is shown then 3 rows of data are returned from application.Then (10-3=7) 7 blank rows will appear below these 3 rows which can be used to enter more data.

If the numberOfLines is not maintained in CRMC_FIELDGRE then the empty lines will not appear by default.i.e. in the above scenario if the application returns 3 rows then only those 3 rows will be shown.To add another row the “Add Entry” button would have to be used.

5.2.2 Hierarchical List View (Tree)

In order to display data in a hierarchical table (a table view with expandable rows, similar to a tree), a special screen structure has to be created, the blueprint tables have to be maintained, and an additional interface has to be implemented in the model access class.

5.2.2.1 Setting Up the Screen Structure

Structure CRMT_BSP_TREE_INCL has to be included in the screen structure. The READ method of the model access class must provide the data for the following fields:

Field Description

PARENT_KEY Object key of the parent element, initial for top level nodes

ICON Optional icon (SAP icon code like “@AB@” for node in collapsed state

ICON_EXPANDED Optional icon for node in expanded state

IS_EXPANDED Indicator that node is expanded. The framework will call the READ_CHILD_NODES method if flag is set

IS_LEAF Indicator that node has no child nodes. No expand/collapse icon will be drawn

IS_HOTSPOT Indicator that node icon and description become a hotspot and that a click on them triggers event ONNODECLICK for application

DESCRIPTION Explanation

Figure 5.15: Fields in Structure CRMT_BSP_TREE_INCL

5.2.2.2 Maintaining the Blueprint Tables

Generally, the setup of the blueprint tables is similar to the setup of a table with lists. Only the differences will be mentioned here.

Currently, it is not possible to toggle from a hierarchical list to a different view in the ODP. In the result list, a list appears first which is in multi-selection mode. You can select a couple of objects here and use the toggle button to move the selected objects to the hierarchical list, where you can work with them. In the selection list, you currently only have access to the favorites function.

You must set the screen type field of the main blueprint table to “TREE” (for the ODP) or “SRET” (for the result list) and you must assign a field group. For the result list there is a second screen type ‘SREU’ which adds a flat list for preselection to the set of viewmodes available.


5.2.2.2.1 Field Group

The field that will be used as a node description can be specified simply by making it the first field visible on the screen – this field is the field with the lowest value for Screen Position and Hidden List not flagged. For the node description field, only input fields and dropdown list boxes are allowed as field types.

5.2.2.3 Adjusting the Model Access Class for the Result List

The READ and MODIFY methods must handle the fields of the screen structure, including CRMT_BSP_TREE_INCL.

The hierarchical list in the result list has a specialized data context class now that takes care of some of the things that the application had to look for until now. It basically works like this:

The application is free to choose what kind of objects it searches for and hands over to the controllers (top level nodes only, complete trees or single nodes from anywhere in the hierarchy).

Every time a complete list of results is read (IV_READ_ALL = True), the hierarchy that is uploaded will be sorted hierarchically and there is a check for primitive loops in the hierarchy (objects with reference to themselves as parent object or object keys which are initial). These loops are resolved (initializing the parent key in the first case and deleting the complete node in the second case). These measures are taken to prevent endless loops due to bad data from the application when operating on the hierarchy. However, closed loops in the hierarchy that include more than one object are not yet detected.

Initially, the READ method may either return the whole tree or only top-level nodes. If some nodes need to be displayed in expanded state initially, the table is to be filled with the child nodes and set IS_EXPANDED to X for the expanded node. This will then be taken over to the internal representation of the navigational state of the tree in the context class. The framework will handle the expanding and collapsing of nodes. If a node is expanded and the framework does not yet know its child nodes, the method READ_CHILDREN will be called.

If it is already known that a node has no child nodes, IS_LEAF has to be set to X. IS_EXPANDED should be SPACE if IS_LEAF is set to X.

There are now two events for the creation of new objects: ‘CREATE_CHILD’ and ‘CREATE_SIBLING’. The first one is used to create an object underneath the current node and the second one is used to create another node on the same level. The application gets the object key of the current focus and is responsible for placing this object key either in the parent key of the new object in the buffer, or using it to determine the parent key of the current focus object and place it in the parent key of the new object in the buffer. To create a new top-level node, the first node named "root" is selected (by default). The object key of the "root" node will be “//root”.

For CRM 5.0 additional creation events have been defined which are due to the fact that you may want to trigger the creation of new nodes changing to a different view mode at the same time. 'CREATE_CHILD_DET' and 'CREATE_SIBLING_DET'. They can be customized for the toolbar of the hierarchical search result list by the application.

For the navigation within the new floorplan viewmodes added in CRM 5.0 the events 'EDIT_DETAILS', 'SHOW_FACTSHEET', 'SHOW_LIST', 'SHOW_SUMMARY' and 'SHOW_HIERARCHY' can be customized in the blueprint tables.

Also added in CRM 5.0 was the event ‘READ_PARENT’ which will display the current nodes parent node in the hierarchy on top of the OHP viewmodes. It is sufficient to just add this event to the corresponding toolbars since it makes use of the normal ‘READ’-Method in the interfaces.

In addition, additional creation from Flat List (Screen Type ‘SREU’ ) in New Floorplan is added.


This allows to create complete new hierarchies from flat list. To enable the creation ‘CREATE_CHILD_DET’ event should be used.

To do the Multiple Seletion in flat list(screentype SREU) use ‘Ctrl + Click’. This will mark the rows as selected.

PCUI Framework Limitation: ‘Ctrl + Click’ will not trigger a server roundtrip.

Work Around: Because of no server roundtrip in case of ‘Ctrl + Click’ search result controller (searchret.do) will not be able register the rows selected. To register the rows selected in case of External Navigation (e.g: Show summary/Factsheet/External Link Navigation) make sure you trigger a server roundtrip by a row selection or internal navigation ( show hierarchy / show details/select a row ).

Another feature is the option to Cut/Copy and Paste. The methods Cut and Copy both contain the screen structure’s name (to identify the access class to be used) and the focus object key in their interfaces. The implementations of these methods should be used to memorize the base node of the sub-tree to be cut or copied and prepare for the upcoming paste operation. When you choose Cut, the controller will have switched off all toolbar buttons except for Paste when the application is rendered after the server roundtrip. This does not apply when you choose Copy. You can then mark the node where you want to paste and drop the sub-tree there. The paste method has an object key for the node where the sub-tree is to be pasted in its interface , and of course the screen structure name to identify the access class. It has to return a table of screen structure types that contains the data for the sub-tree to be pasted (which is used to insert the pasted sub-tree in the data context class’s representation of the data table.). Additionally, you should return a list of the object keys of all the objects in the sub-tree that is being pasted. The objects referenced in this list by their object keys should all be in your buffer. The object key list is used to enable switching between different objects in the sub-tree without having to save. The sub-tree can only be saved completely. This allows for editing all objects in the sub-tree to remove messages that are sent by the application. It is the application’s responsibility to prevent the paste event in case an error would be created by pasting that cannot be removed by just editing the sub-tree objects. In such a case there is a parameter ‘iv_failed’. Setting it to ‘ABAP_TRUE’ will reverse the operation in case of a cut preceding the paste event, and during Copy, the framework will do nothing. It is the application’s responsibility to post an appropriate message in the application log in such a case.

The complete list of methods of the interface IF_CRM_BSP_TREETABLE_IL to be implemented in the model access class follows:

• IF_CRM_BSP_TREETABLE_IL → CUT

• IF_CRM_BSP_TREETABLE_IL → COPY

• IF_CRM_BSP_TREETABLE_IL → PASTE

• IF_CRM_BSP_TREETABLE_IL → READ_CHILDREN

• IF_CRM_BSP_TREETABLE_IL → READ_ROOT_DESCR

• IF_CRM_BSP_TREETABLE_IL → REFRESH

• IF_CRM_BSP_TREETABLE_IL → GET_FIELD_ATTRIBUTES

5.2.2.4 Adjusting the Model Access Class for the ODP

The READ and MODIFY methods must handle the fields of the screen structure, including CRMT_BSP_TREE_INCL.

Initially, the READ method may either return the whole tree or only top-level nodes. If some nodes need to be displayed in expanded state initially, the table is to be filled with the child nodes and you must set IS_EXPANDED to X for the expanded node. The framework will handle the expanding and


collapsing of nodes. If a node is expanded and the framework does not yet know its child nodes, the method READ_CHILDREN will be called.

Methods READ and READ_CHILDREN are only called when necessary, thus only when new nodes need to be retrieved. For example, if a branch is collapsed and then re-expanded, neither method is called. This however means that the application doesn’t get a chance to change the tree structure with every server roundtrip, as would be the case in the result list and for the list view. In order to change the tree structure, the application has to set the refresh flag in method REFRESH, which is called for every round trip. If this flag is set, the framework deletes the old tree and calls the READ method for a new tree.

If it is already apparent that a node has no child nodes, IS_LEAF must be set to X. IS_EXPANDED should be SPACE if IS_LEAF is set to X.

The CREATE method will put the object key of the currently selected node into the field PARENT_KEY of the new node. This means that a new node is always inserted below the currently selected one as its child node. To create a new top-level node, the first node named "root" is selected (by default). The object key of the "root" node will be “//root”.

Additionally, the methods of interface IF_CRM_BSP_TREETABLE_IL are to be implemented in the model access class.

• IF_CRM_BSP_TREETABLE_IL → READ_CHILDREN: The parameters are the same as for the READ method, except for the fact that data will not be read for the key contained in IT_OBJECT_KEY, but for their child nodes (successors on next level).

• IF_CRM_BSP_TREETABLE_IL → READ_ROOT_DESCR: The tree will always contain a root node. New top-level nodes can only be created as children of this root node. The description of the root node can be set by implementing this method. The object key will always be “//root”.

• IF_CRM_BSP_TREETABLE_IL → REFRESH: Implementation of this method tells the framework to re-load the complete tree.

• IF_CRM_BSP_TREETABLE_IL → CUT, COPY, PASTE: Currently these methods cannot be used for a tree in the ODP

• IF_CRM_BSP_TREETABLE_IL → GET_FIELD_ATTRIBUTES: Using this method, the application can return the field attributes to modify some display attributes. These field attributes are usually passed using the READ method. For further information about field attributes, see section 4.3.2.3. Since this method is not called with every round trip for the tree, a new method was necessary.

5.2.3 Viewset Selection Pattern (VSP)

You can use the Viewset Selection Pattern (VSP) to represent different groupings, actions, or processes in your application on the screen (as an icon). The user starts one of these processes by selecting the relevant symbol.


Figure 5.16: Viewset Selection Pattern (VSP)

A viewset is a collection of information, for example, for a process that is made up of several steps. You can use a viewset to go to a Guided Data Entry Pattern (GDP) or to group individual ODPs.

Viewsets

The Viewset Selection Pattern (VSP) consists of a number of viewsets that are represented by icons or text links. Each icon or text link represents a certain action, procedure, or business transaction (for example, an organizational change). Each icon exists in an active and inactive version. The VSP is situated directly below the results list in the third level of the screen (in the blueprint table CRMC_BLUEPRINT: SCREENPOSITION = 3).

If a viewset is represented by an icon, a descriptive text, which is taken from the events text table (CRMC_BSP_EVENT_T), is situated below the icon. This text is the heading of each event.

When a user selects a viewset, either an Object Data Entry Pattern (ODP) or a Guided Data Entry Pattern (GDP) is displayed in the level below.

Viewset Groups

The VSP can have several tab pages. On these tab pages, different viewsets can be collected in viewset groups, for example, according to content. In this way, each tab page represents one viewset group. The user can select individual viewset groups using these tab pages.

5.2.3.1 Integration of the VSP in the Blueprint Application

In the Viewset Selection Pattern (VSP), icons or text links represent a certain process. With a unique identification number, the process ID can be used to set up a link to the Guided Data Entry Pattern: when the user selects a specific icon or text link, a GDP is displayed in the screen level below the VSP as an additional pattern. An Object Data Entry Pattern (ODP) can also be called from the VSP. In this case, the process ID is certainly not required.

5.2.3.1.1 Viewset Group Table (CRMC_VSETGRP)

A viewset group is defined in the table CRMC_VSETGRE.

Field Description

VIEWSETGROUP Viewset group

DISPLAY_MODES Permitted display modes

Figure 5.17: Fields in Viewset Group Table CRMC_VSETGRE

The display options of the individual viewsets are determined in a VSP with the attribute DISPLAY_MODES: “Icon with link, link and minimized” is preset as standard. This means that the user can display a viewset in all display modes (as an icon, text link and in the minimized display). When the user selects the value “Link and minimized” for DISPLAY_MODES, the viewsets cannot be displayed as icons, but only as a text link and in the minimized display.

The individual viewsets are defined in the viewset group table CRMC_VSETGRP and are also assigned to the appropriate viewset groups here. You can make the following entries in this table:


Field Description


SEQUENCE Position of the viewset in the VSP. By entering the position, you define the order in which the viewsets will be displayed on the screen in the specified viewset group.

EVENT Event that is triggered when the user selects the viewset..

PROCESS_ID Unique identification number when a process is assigned. If an ODP is assigned to the viewset, then the process ID is initial. If a GDP is assigned, the process ID specifies the ID of the back-end process that is performed in the GDP. In this way, the VSP and GDP are linked technically with each other.

The process ID is characterized more accurately in the table CRMC_BSPPROC (comp. Section 5.2.3.1.3.1)

ICONPATH Path details for the file that contains the icons displayed in the VPS for each active viewset.

DISABLEDICONPATH Path details for the file that contains the icons displayed in the VPS for each disabled viewset.

Figure 5.18: Fields in Viewset Group Table CRMC_VSETGRP

The graphic files can also be stored with the icons, e.g. on a central server, and also in the MIME repository. The standard icons, e.g. which SAP supplies within the framework of the HCM, are in the name range of MIME repository under Public -> HCM -> PA. Here there is a separate customer name space for customers, which must be used. An Internet service must be set up for each folder using Transaction SICF if you are to be able to access the icons stored here.

We advise depicting the corresponding application hierarchy as a folder structure at least at the upper levels for SAP development in the MIME repository. Thus, with changes to icons, it is easier to determine which applications use a particular icon.

Example for viewset group table: the entries in the viewset group table can look as follows for a viewset group:

Viewset group Sequence Event Process_ID Icon path

VSETGRP1 1 VSET1 ICON1

VSETGRP1 2 VSET2 PROCESS1 ICON2

Figure 5.19: Example of Viewset Group Table CRMC_VSETGRP

In this example, the viewset group VSETGRP1 consists of the viewsets VSET1 and VSET2, which are represented by ICON1 and ICON2. The process PROCESS1 is assigned to VSET2.


5.2.3.1.2 Extensions to the Blueprint Customizing

The controller type VSET is provided for VSP. In the blueprint table CRMC_BLUEPRINT, this controller type is entered in the field SCREENTYPE. You can use field VIEWSETGROUP to determine which viewset group should be displayed each time.

Example: the entry in the blueprint table can look as follows for the VSP:

Event Screen-position

Screen-type

Field-group

Tabgroup Toolbargroup Viewset-group

Stepgroup

INIT 1 SREQ FG1

INIT 2 SRES FG2

INIT 3 VSET VSETFG VSETTABGRP VSETGRP1

VSET1 4 LIST FG3 TABGRP1 TLBARGRP1

VSET2 4 GDPF FG4 TLBARGRP2 STEPGRP1

Figure 5.20: Example of Table CRMC_BLUEPRINT with VSP

In this example, a VSP is displayed (screen type = VSET) in the third level (screen position = 3). What is activated by selecting the viewset in the third level, is displayed in the fourth level. In this case, there is a list and a GDP with the step group STEPGRP1.

5.2.3.1.3 Link to model access class (MAC)

Although a field group is not actually required for the layout of the VSP, a field group must be specified in the table CRMC_BLUEPRINT. This field group is used to derive the model access class, which is called for communication purposes with the back-end.

As explained in section 4.3.2.3 (Using Field Groups), a screen structure is assigned to the field group, which is in turn assigned to a model access class.

5.2.3.1.3.1 Method CHECK_ACTIVE_VIEWSETGROUP ()

Interface: IF_CRM_BSP_MODEL_ACCESS_IL

The method CHECK_ACTIVE_VIEWSETGROUP (Check Active Viewsets) is used for the communication between the front end and back end, and is called when the status of all viewsets must be transferred to the front end.

The application might implement the method to deactivate specific viewsets or to change their properties.

CHECK_ACTIVE_VIEWSETGROUP



IV_SCREEN_STRUCTURE_NAME Importing Structure name

CT_VIEWSETGROUP Changing Viewset group

Figure 5.21: Interface of CHECK_ACTIVE_VIEWSETGROUP Method

The list of viewsets is passed via changing parameter CT_VIEWSETGROUP.


The structure CRMT_BSP_VSETGRP_M contains the following fields:

Field Description


SEQUENCE Position of the viewset

EVENT Event

PROCESS_ID Identification number of the process

ICONPATH Path details for icon

DISABLEDICONPATH Path details for inactive icon

CONSISTENT_DATA Indicator to show that consistent data is required

START_IMMED Indicator to show that the step should immediately be initiated

DISABLED Indicator to show that an viewset should be displayed as disabled

Figure 5.22: Fields in Structure CRMT_BSP_VSETGRP_M

The application may perform the following actions:

• Delete an entry so that a viewset is no longer displayed on the screen.

• Set the DISABLED flag so that the inactive version of the icon is displayed.

• Set or delete indicator START_IMMED for a viewset. This indicator is only provided for viewsets, which represent a process (GDP).

If the indicator is not set, a process is not automatically initiated. This means that the user must explicitly select the viewset, which represents the appropriate process in order to call up the GDP:

If the indicator is set, the process can be initiated without explicit action by the user. This happens for example, when the user selects a different tab page in the VSP. In this case, the relevant viewset group is displayed. If the indicator START_IMMED is set for the first active viewset in this viewset group, this viewset is selected. The relevant process is automatically initiated and displayed in the underlying level.

• Set or delete indicator CONSISTENT_DATA for a viewset.

This indicator is only provided for viewsets, which represent a process (GDP). If a user selects a viewset or a viewset exists for which the indicator CONSISTENT_DATA is set, the framework checks whether data must be saved.

If unsaved data is available, the user receives a dialogue box. He/she can either save or discard the data here.

The Customizing for a viewset group is defined in the table CRMC_VSETGRP. The process ID is also maintained here.

The attributes for the process ID, and the indicators START_IMMED and CONSISTENT_DATA are maintained in the table CRMC_BSP_PROC. This means that both indicators can only be changed for a process ID that is entered in the table CRMC_BSP_PROC. This table contains the following fields:


Field Description

PROCESS_ID Identification number of the process

CONSISTENT_DATA Indicator to show that consistent data is required

START_IMMED Indicator to show that the step can immediately be initiated

Figure 5.23: Fields in table CRMC_BSP_PROC

5.2.3.1.3.2 Method SET_SELECTED_PROCESS_ID ()

Interface: IF_CRM_BSP_MODEL_ACCESS_IL.

The method SET_SELECTED_PROCESS_ID is called when the user selects a viewset in the VSP. In this case, it does not matter whether the viewset represents a GDP process or a ODP tabstrip group. The process ID is transmitted to the back end. If it is a tabstrip group, the process ID is initial.




IV_PROCESS_ID Importing Process ID

Figure 5.24: Interface of SET_SELECTED_PROCESS_ID method

5.2.4 Guided Data Entry Pattern (GDP)

You can use the Guided Data Entry Pattern (GDP) to map and edit processes that consist of several steps. The user is guided through the process step by step. It is, however, also possible to go directly to specific steps, if required.

Figure 5.25: Guided Data Entry Pattern (GDP)

The GDP is situated either directly below the results list in the third level of the screen (SCREENPOSITION = 3) or, if it is called from a VSP, it is situated in the fourth screen level (SCREENPOSITION = 4).


The GDP consists of a sequence of numbered steps. The stepbar is created from the individual step headings and is displayed on the screen. The following is an example of a stepbar:

Figure 5.26: Stepbar in GDP

The stepbar consists of several numbered step headings, which, in the GDP, replace the tab pages used in the ODP. The arrow-style representation of the individual step headings denotes the process flow. The GDP can include different controller types (lists, forms) in the individual steps.

Before the first process step, there is a heading in the stepbar that tells you which process you have selected. The text for this heading is taken from the text from the DESCRIPTION field in the step group table CRMC_STEPGRP. To ensure the connection as regards content between the GDP and the VSP, this text should be the same text as the corresponding viewsets.

5.2.4.1 Navigation

Within the individual process steps, the user has various navigation options:

• The user can work through the individual steps of the process in the specified order by using the buttons Previous Step or Next Step.

• The user also has the option to go directly to each (active) step of the process by clicking on the respective process heading.

5.2.4.2 Personalization Options

Within the framework of the GDP, the user cannot personalize the stepbar. He or she cannot choose to show or hide any of the individual process steps.

However, the user has the option of personalizing the individual fields of a list. If a list is displayed within the GDP, the user can show or hide individual fields, as is the case within the ODP.

5.2.4.3 Integration of the GDP in the Blueprint Application

For the GDP, there is a strict separation between the front end and the back end. Each back end process is identified by a process ID (field PROCESS_ID). Each individual step of the process is selected by a step ID (field STEP_ID). These back end IDs are stored in the (front end) Blueprint Configuration, in order to create the connection between front end processes and back end processes. When the event occurs, the step ID is stored in the back end. The event, also created for the individual step (field EVENT), supplies information for the front end.

Within the process, the back end can activate, deactivate, or hide individual steps. The back end can mark specific steps as mandatory.

5.2.4.3.1 Back-End and Front-End Processes

There are technical differences between the back end and front end processes:

• Back-end processes: All processes for guided data entry are assumed to be modeled in the back end. The back end defines the process (represented by a process_id) and the steps that belong to this process (represented by a step_id). For each back end step the back end might store further information, such as an operation that should be performed, when the step is executed. Furthermore, the back end handles the dependencies between different steps and invalidates steps that are not relevant or cannot yet be processed.


• Front-end processes: A front end process is linked to a back-end process during the configuration via the process ID. However, this is only necessary if the GDP is called from a VSP. The process ID and icons are stored together in the configuration table of the viewset (CRMC_VSETGRP). The table is described under Viewset Selection Pattern -> Integration of the VSP in the Blueprint Application.

5.2.4.3.2 Step Group Table (CRMC_STEPGRP)

The complete process within a GDP is defined with its individual steps as a step group in the table CRMC_STEPGRP. The table defines the step groups to which each step belongs and which position the individual step should have. The individual step groups are defined in table CRMC_STEPGRE, which is made up of field STEPGROUP. In table CRMC_STEPGRP, a step group can be defined, for example, as follows:

Step Group Sequence Event Step ID Multigroup

STEPGRP1 1 STEP1 STEP_A

STEPGRP1 2 STEP2 STEP_B

STEPGRP1 3 STEP3 STEP_C

Figure 5.27: Example of Step Group Table CRMC_STEPGRP

In this table, you can make the following entries in the individual fields:

Field Description

STEPGROUP Name of step group

SEQUENCE Position of each step within the step group. By entering the position, you define the order in which the steps will be displayed on the screen.

EVENT Event that is started when the relevant step is selected. (Information for the front end).

STEP_ID Unique identification number of the back end step. The step ID can contain up to 20 characters.

MULTIGROUP The multigroup corresponds to the multigroup for the ODP. Several lists and forms can be displayed for one step.

Figure 5.28: Fields in Step Group Table CRMC_STEPGRP

The descriptions of the individual steps are taken directly from the text table of the event (CRMC_BSP_EVENT_T).

5.2.4.3.3 Extensions to the Blueprint Customizing

The following controller types are available for the GDP:

• GDPL (Guided Data Entry – List): the data is displayed in a table.

• GDPF (Guided Data Entry – Form): the data is displayed as a form.


• GDPM (Guided Data Entry – Multi-GDP): combination of forms and lists. . In a GDPM, the following types can be specified as an entry: HTML (HTML viewer), Tree (hierarchy display), Multi-Edit, Upload (data upload).

These controller types correspond to the standard controller types for tab strips, as described in the section User Interface Pattern in Detail (Section 2.2.3).

In the central blueprint table CRMC_BLUEPRINT, this controller type is entered in the field SCREENTYPE. This determines which controller is displayed and where it is displayed on the screen.

Example: the entry in the blueprint table can look as follows for the GDP:

Event Screen Screen type Field group Tab group

Viewset group

Step group

INIT 1 SREQ FG1

INIT 2 SRES FG2

INIT 3 GDPF FG3 STEPGRP1

STEP1 3 GDPF FG3 STEPGRP1

STEP2 3 GDPF FG4 STEPGRP1

STEP3 3 GDPL FG5 STEPGRP1

Figure 5.29: Example of Table CRMC_BLUEPRINT with GDP

In this example, a GDP is displayed in the third screen level with the step group STEPGRP1. This step group consists of three steps: the first two steps STEP1 and STEP2 include a form, the third step includes a list.

5.2.4.3.4 Navigation

The navigation options within a process, which has several steps, are controlled from the back end. It determines which step the user can access from the step they are currently in. The back end can for example also ensure that a specified sequence is followed during processing, by only activating the subsequent step and deactivating all the others. To do this, the back end implements the method CHECK_ACTIVE_STEPS.

The buttons Previous Step and Next Step are controlled directly from the framework and cannot be changed or adjusted by the application. These two buttons cannot be deactivated using the method CHECK_ACTIVE_TOOLBAR(). The framework deactivates the button Previous Step when the first step is selected. Likewise, the framework deactivates the button Next Step when the last step is selected. Otherwise, both buttons are active. When one of these buttons is selected, the method CHECK_ACTIVE_STEPS is called. Then the next or previous step that is not deactivated is selected.

5.2.4.3.5 Error messages

When an error message appears, the user can go directly to the respective screen by clicking on the message. In the case of a GDP; it must be known within which process and in which step the error has occurred. For this purpose, the fields PROCESS_ID and STEP_ID must also be filled in, so that the corresponding screen can directly be displayed.

In addition, the desired event must be determined for navigation in the table CRMC_BSP_MSGS. See Message Handling 5.1.1 for further information.


5.2.4.4 Methods

5.2.4.4.1 CHECK_ACTIVE_STEPS()


The method is used for the communication between the front end and back end, and is called when the status of all steps must be transferred to the front end.

CHECK_ACTIVE_STEPS



IV_SCREEN_STRUCTURE_NAME Importing Structure name of display field

CT_STEPGROUP Changing Step group

Figure 5.30: Interface of CHECK_ACTIVE_STEPS Method

When method CHECK_ACTIVE_STEPS is accessed, table CT_STEPGROUP, which has the structure CRMT_BSP_STEPGRP_M, is transferred. This table contains all the steps of the relevant process, which are defined in the back end and are used for the configuration of the UI. The back end modifies this table for each step, depending on the current status of the individual steps.

The number of entries in this table does not have to match the number of visible steps because a back end step can be divided into two UI steps.

The structure CRMT_BSP_STEPGRP_M contains the following fields:

Field Description

STEP_ID Unique identification number of the step

MANDATORY Indicator to show the step is mandatory

DISABLED Indicator to show the step is deactivated

STATUS Description of the processing step within the process

Figure 5.31: Fields in Structure CRMT_BSP_STEPGRP_M

The table CT_STEPGROUP is updated each time before the method CHECK_ACTIVE_STEPS is called. The back end must therefore always return the complete status of all steps.

The application can perform the following operations and modifications to the table CT_STEP GROUP in the method:

• Set indicator DISABLED to‘X’: If the back end has filled this field with ‘X’, the step is deactivated. The step is then grayed out on the screen. Thus, the user cannot click on the step. When the user selects one of the buttons Previous/Next Step, the system skips the deactivated step and displays the previous/next step that is active.

• Set indicator MANDATORY to ‘X’: If the back end has filled this field with ‘X’, the step is mandatory. Mandatory steps are indicated by a red asterisk (*) in the step number. This indicator solely acts as a sign on the surface and does not affect functionality. This means that this indicator has for example no effect at all on navigation using the Previous Step / Next Step buttons or on selecting options and save.


The model access class in this regard has to prevent the user from saving a GDP, if he or she has not performed the mandatory steps.

• Set the status of the step: The status of the steps describes the user’s progress within the process. A step can have one of the following status. They are defined as constants in the interface IF_CRM_BSP_CONTANTS:

o GC_STEP_IS_UNPROCESSED:

The step has not yet been processed.

o GC_STEP_IS_OK:

The step has the status OK.

o GC_STEP_HAS_WARNINGS:

A warning has been issued for the step.

o GC_STEP_HAS_ERRORS:

The step contains an error. You cannot add other statuses.

The status tells the user on screen whether a step has been performed and with what result. In each case, a particular symbol is displayed on the step heading in order to represent the status. If the step has not yet been performed or if the status was set to initial for other reasons, no symbol is displayed.

When the back end sets the status to warning or error, a suitable message of the same category should be issued to explain the error. The field STATUS has no effect on the functionality. It is simply a way to visualize the information.

• Delete a step from the table: If the step should not be displayed on the screen, the entry must be deleted from the table.

Each time the method CHECK_ACTIVE_STEPS is called, the same steps must be deleted as is the case the first time the method is called. Thus, the numbering of the steps remains unchanged when the method is called again. Therefore individual steps throughout the course of the process should not be hidden or shown, but activated or deactivated.

No other operations are allowed and are ignored by the framework.

5.2.4.4.2 SET_SELECTED_PROCESS_ID


The method SET_SELECTED_PROCESS_ID is called when a user selects one of the viewsets in the VSP. The method is used to transfer the process ID for the relevant viewset to the back end. The method is always called from the VSP, irrespective of whether the viewset represents a GDP or a tabstrip group.




IV_PROCESS_ID Importing Process ID

Figure 5.32: Interface of SET_SELECTED_PROCESS_ID Method


5.2.4.4.3 SET_SELECTED_STEP_ID

The method SET_SELECTED STEP_ID is called when a step is displayed in the GDP. The method is used to transmit the STEP_ID of the displayed step to the back end. The user accesses each step either by selecting it directly or using the Previous Step / Next Step buttons.

The back end can at this point supply the parameter ET_CLASS_NAME. Thus, the back end signals that data exists, which has not yet been saved. It also indicates the name of the class, which should be called for saving to be carried out. (see also Save under 4.3.3.2 Model access class methods).

SET_SELECTED_ STEP_ID



IV_STEP_ID Importing Process step ID

ET_CLASS_NAME Exporting Class name

Figure 5.33: Interface of SET_SELECTED_ STEP_ID

5.2.4.5 Save and Close

It is possible to distinguish between the following options for saving: • “Save”: A particular condition is stored.

• “Save and Close”: A particular condition is stored and subsequently the whole process is closed.

If the application wants to differentiate between these two types, an individual push button is required to “Save und Close.” For this purpose, there is the event PCF_SAVE_AND_FINISH.

The application includes the push button “Save and Close” in the tool bar of the Object Identification Pattern. When the user selects “Save and Close”, the method PROCESS_EVENT is initially called. Then the regular security process is performed. There are the methods CHECK_BEFORE_SAVE and SAVE for this, which are described in Section 4.3.3.2 Model Class Methods).

5.2.4.6 Connection between VSP and GDP

A GDP is located in either the third or fourth screen level. This depends on whether the GDP is called from a VSP or directly from the OIP. In the first case, VSP and GDP are available on the screen at the same time.

5.2.4.6.1 Calling a GDP Without VSP

In this case, the GDP is directly below the OIP and is called from here.


Figure 5.34: Screenshot with OIP and GDP

In this case, a VSP is not included. If the user selects an entry in OIP, the GDP is displayed directly in the level below. A process ID is not required for this. The first step of the process is selected and displayed. The method SET_SELECTED_PROCESS_ID is also not called.

5.2.4.6.2 Calling GDP from VSP

One or more GDPs can be called from a VSP.

Figure 5.35: Screenshot of OIP, VSP, and GDP

In this example, the VSP is displayed in the third level of the screen, the GDP in the fourth. The GDP is called here when the user selects one of the existing viewsets in the VSP.

On the screen, there is a visible connection between the two patterns as the same text is used for the process in both patterns. In the VSP, each viewset has its own text, which is displayed below the icon. This text is the label of each event. In the GDP, there is a heading with a process


description in the stepbar. This text is the description of the step group. These two texts should match so that the user can recognize in the GDP which process was called from the VSP.

5.2.4.6.2.1 Process ID

The connection between VSP and GDP is created using the process ID. When the user selects a particular viewset, the process ID tells the back end which new process should be initiated when icons or textlinks are selected. The GDP is displayed in the level below.

The process ID is transmitted to the back end using the method SET_SELECTED_PROCESS_ID when a GDP is called from the VSP. If an ODP is called instead of a GDP, the process ID is initial.

During the process, the method SET_SELECTED_STEP_ID tells the back end which step the user is currently in.

5.2.4.7 Example of Communication Between Framework and Model Access Class (MAC)

This example describes the interaction between framework and application for a process that runs within the Guided Data Entry Pattern. The process in the GDP is called from a Viewset Selection Pattern. The process ID of the selected viewset is ORG_CHANGE.

1. User clicks the icon (viewset) in VSP.

2. Framework checks if a process_id was stored for this viewset. Framework finds process_id ORG_CHANGE.

3. Framework calls SET_SELECTED_PROCESS_ID(ORG_CHANGE); if process_id was not specified, framework calls SET_SELECTED_PROCESS_ID(‘’).

4. Back end sets a global variable to indicate that all further MAC calls will relate to this process.

5. Back end sets internally the status of all steps in this process.

6. Framework calls CHECK_ACTIVE_STEPS()

7. Back end returns the status for all steps in CHANGING parameter CT_STEPGROUP.

8. Framework searches for the first step with DISABLED = initial. Let’s call this step STEP_I. Framework calls SET_SELECTED_STEP_ID(STEP_I) to inform the back end about the step currently being processed.

9. Framework calls READ(OBJECT_KEY). Back end returns the data for this step.

10. User changes some data and presses ENTER (-> Roundtrip)

11. Framework calls MODIFY(); back end handles the changed data (same as in ODP)

12. Framework calls READ(OBJECT_KEY). Back end returns the data for this step.

13. User changes some data and presses button NEXT_STEP

14. Framework calls MODIFY(); back end handles the changed data (same as in ODP)

15. Framework calls CHECK_ACTIVE_STEPS(); back end returns status for all steps.

16. Framework searches for the next step (with a sequence number higher than the sequence number of the current STEP_I) with DISABLED = initial. Let’s call this step STEP_J; if there is no such step, stay on the current step (STEP_J = STEP_I). In this case, the back end is not allowed to disable STEP_I.

17. Framework calls SET_SELECTED_STEP_ID(STEP_J); continue with step 9.


5.2.5 Popin for Additional Data Display and Selection

The popin is used to ask users for additional data or filter criteria. Examples include:

• Choosing Ship-To Party

• Choosing organizational data

• Entering additional information for printing

The popin is displayed dynamically between the result list and ODP 1. It is implemented by a data request controller, which creates the view for the popin.

The request for a popin is initiated by a message, which is raised by the application. The field REF_OBJECT within parameter RT_APPLOG of method GET_MESSAGES has to be filled with an object key. The message will be found by the message controller and triggers the message text(for example "Please choose Ship-To Party").

To insert a popin view on the screen, several entries have to be maintained in the blueprint tables:

• The message is related to an entry in table CRMC_BSP_MSGS, where it is related to an additional event, the action-event, besides the usual message event.

• The application makes an additional entry in the main blueprint table with screen position "popin" or "D" and the event according to table CRMC_BSP_MSGS.

• The type of view where the message is raised can be of any allowed screen type.

• The popin view will be inserted on top of ODP 1.

• Based on the message, the main controller knows which result list, ODP, or tab has raised the message. The request controller is inserted on top of ODP 1. In the ODP, the appropriate tab will be opened.

The data will be retrieved and changed as usual by using the READ method and the MODIFY method of the model access class:

• If a popin is used for a selection screen (such as "Please choose Ship-To Party"), the data that can be chosen has to be provided by the READ method of the model access class. This data can be buffered in the API or the model access class, or the list of values can be determined when the READ method is called. This would also work after saving the object and the value could be chosen later on.

• If a detail view is used for the popin, the fields are displayed according to the screen structure in the blueprint table.


Please choose Credit Card: VISAMC

Find

Detail

Result List

Screen Position 1

Screen Position 2

Screen Position 3

Init Tab2 Tab3

T1Str6DetailDEvent1

Str5Detail3Tab3

Str4Detail3Tab2

Str3Detail3Init

Str2Result2Init

Str1Search1init

ToolbarStructureTypePositionEvent

T1Str6DetailDEvent1

Str5Detail3Tab3

Str4Detail3Tab2

Str3Detail3Init

Str2Result2Init

Str1Search1init

ToolbarStructureTypePositionEvent

Blueprint-Table (simplified)

Event1Tab2331Sample

Action Event

EventMessage-Number

Message-Area

Event1Tab2331Sample

Action Event

EventMessage-Number

Message-Area

CRMC_BSP_MSGS (simplified)

Select01T1

EventPositionToolbar

Select01T1

EventPositionToolbar

CRMC_TOOLBAR_GRP

Select Screen Position Popin

Figure 5.36: Blueprint Table Maintenance for Popin

Because popins have some usability disadvantages, it has been decided to support popups in addition to popins in SAP CRM 4.0. From the user’s perspective, this may produce the following disadvantages:

• The user loses the focus of the screen

• The user does not realize that the popin is "inserted" without affecting the content of the rest of the screen.

• Accessibility problems if the popin appears system-driven

5.2.6 Popups

Popups can be used for selection and additional data display. In general popups allow you to avoid the disadvantages of popins. Popups are displayed as new windows. Popups can be moved or minimized to view data on the main window. However, as long as the popup is opened, it is not possible to work on the data of the main window; effectively setting the focus back to the popup.

Technically, the popup works as a second main-controller that communicates with the server and calls the single sub-controller maintained in the blueprint-table. This sub-controller has a toolbar but no tabstrips. Like the popins, popups are initiated by a message in method GET_MESSAGES. The message text is displayed as the heading of the popup. The message which raised the popup must not be deleted before:

• The user closes the popup. This raises event CANCEL_POPUP.

• The user clicks on a button on the toolbar of the popup, which closes the popup. The application has control over that events.

Generally, setting up a popup is very similar to setting up a popin; the only difference being that the screen-position is Popup instead of Dynamic.


5.2.7 HTML Viewer

The HTML viewer displays an HTML page at the screen position of the ODP and is used to display external HTML content. The source for the HTML page can either be a URL or direct HTML code in a table. To use the HTML viewer, screen structures need to be defined that include either a field for the URL or a table consisting of the lines of HTML code.

The HTML viewer works in the following way:

• The DO_REQUEST method of HTML controller is called with the relevant screen structure.

• All screen structures that are used for the HTML controller need to have either a field called URL (type STRING) or a field called HTML_TABLE (type CRMT_BSP_HTML_TAB).

• The corresponding model access class is determined via the screen structure. If possible, the existing model access class of the application shall be used.

• The READ method of the model access class is called and fills either the URL or the HTML code.

• HTML or URL is published to the view via the object of the context class and the view html.htm is called. Within this view, the htmlContainer tag is used.

• When either the tabstrip is changed (so that the HTML controller disappears from the screen) or the save button for the application is pressed and the HTML controller is active on the screen, the DO_HANDLE_DATA method of the controller is called. The corresponding model access class is determined by the given screen structure.

• The MODIFY method of the model access class is called.

• Example: For configuration or restrictions, the MODIFY method would then call the IPC to request the changed data.

If the HTML viewer needs to be integrated in the application, a screen structure has to be created as explained above and the blueprint tables have to be maintained. You must choose HTML as the screen type. A dummy field group (which need not contain any fields) has to be created because the framework requires the existence of a field group. The application can add a field HEIGHT type string to its screenstructure. The number in this field defines the height of the HTML container at runtime. If this field is not filled, is 0, or not even part of the screenstructure, the height will remain at 500 pixels. If the field is filled with -1 the height of the container will be 0 (See also note 638630). The HTML viewer is already used to integrate JSP-based product configurations into Sales applications Quotation (CRMS_SALQ) and Sales Order (SLO_SALES).

5.2.8 The Text Management Tool

The text management tool allows the user to edit text in a text area on a tab in the Details view. The following steps have to be performed to add the text management tool to a screen:

The specific programming objects for text management can be found in package CRM_BSP_MODEL_IL_TM. Basically a DDIC structure that includes structure CRMT_BSP_TM and a model access class (for example CL_BSP_ACCESS_MODEL_TM)have to be created. The methods READ and MODIFY of the model access class have to be implemented:

• The READ method has to be implemented in order to retrieve the text management keys from the object key. For the first version, it is sufficient to fill TM_OBJECT,


TM_PROCEDURE and TM_NAME. In most cases TM_NAME is the GUID of the application data. If the dropdown list box is not required for languages other than the logon language, you can remove it from the screen with the parameter TM_LANGU_OFF = X. Consequently, texts can only be maintained or read in the logon language.

• It is possible to switch the text edit field to disabled mode with the parameter TM_MODE = “C”.

• Optionally it is possible to specify a communication structure to read predefined texts from Customizing (parameter TM_COMSTRUC_FIELDTAB).

• In the READ method, it is necessary to register the process class of the text management tool to initialize the text buffers. Proceed as described in the example below. In the MODIFY method, it is necessary to register the responsible interaction layer process class for text management.

Example:

METHOD if_crm_bsp_model_access_il~modify .

DATA: ls_class_name LIKE LINE OF et_class_name.

*--------------

IF iv_screen_structure_name = “CRMT_BSP_<YOUR_SCREENSTRUCTURE_NAME>“.

ls_class_name = “CL_BSP_PROCESS_MODEL_TM”.

APPEND ls_class_name TO et_class_name.

ENDIF.

ENDMETHOD.

No additional steps are required from the application in order to use the text management tool.

For initialization reasons (framework event = INIT), the READ method of the model access class defined in the blueprint table is called with LS_OBJECT_KEY = space. In this way, it is possible for the application to fill the dropdown list box of the text type with valid values. To achieve this, parameters TM_OBJECT and TM_PROCEDURE have to be specified by the application.

• An entry needs to be made in table CRMC_ACCESS to specify the model access class for the application. The attributes are to be filled in as follows:

- Screen Structure = CRMT_BSP_TM_…..

- Model Access Class = CL_BSP_ACCESS_MODEL_TM

• An entry has to be made in table CRMC_BLUEPRINT. Assign the text management tool to the application. The attributes are to be filled in as follows:

- Screen Type = TEXT

- Screen Structure = CRMT_BSP_TM_*

• If your application does not use the GUID from the result list as text object name (TM_NAME) please use function module COM_TEXT_GENERATE_TDNAME to generate it.

• COPY function: the result list dispatches the copy-event for the applications. The application has to get this event within the PROCESS_EVENT method of its model


access class. To copy the text, it is necessary to call function module COM_TEXT_COPY_API of the API of the text management.

• DELETE function: See copy function (above), but use function module COM_TEXT_DELETE_API.

• It is possible to get the current key settings of the text management controller by using the static method GET_ACTUAL_SETTINGS of class CL_BSP_PROCESS_MODEL_TM.

5.2.9 CRM Content Management

CRM content management is based on Document Management Service (DMS) of SAP Web Application Server (AS). With CRM content management, it is possible to enrich standard data objects like products, product catalogs, or business partners with "unstructured" data such as documents or multi-media objects. You can access content management functions when you maintain the relevant business object. In product maintenance, for example, content is maintained under the tabstrip Documents. The system then displays the content management interface.

Content management offers the following features:

• A user interface (UI) integrated within the CRM applications

• Linkage of content with business objects

• Technical content management functions, like folder management and the storage of content on content servers

• Content storage on one database

• Content versioning

• Separation of layout and content

• Folder templates

• Metadata administration

• Document search

• Archive Link documents

• Where-used list for documents

Figure 5.37: Screenshot of Content Management

5.2.9.1 Integrating Content Management

The following steps describe how to include content management in a blueprint application:


• Do not use your own screen structure. Instead, use CRMT_BSP_CM_OBJ. Fill CRMC_ACCESS-APPLICATION with your application to assign your model access class to global screen structure CRMT_BSP_CM_OBJ.

• Create your own model access class corresponding to this screen structure. This model access class has to forward the method GET_MESSAGES to the model access class of content management. Please use method CL_CRM_BSP_CM_ACCESS → GET_INSTANCE to get it. In general, your access class should forward method GET_MESSAGES to all lower applications, which include all tabstrips of your application. This is independent of the tabstrip that is currently active.

• Implement the READ method in your model access class in order to fill the content management keys from your object key:

<ScreenStructure>-INSTID = Business object (for example, GUID) <ScreenStructure>-TYPEID = Business object type (for example, BUS…) <ScreenStructure>-CATID = Business object

• Include event CM in your tabstrip. Each application using content management can have its own description for the tabstrip, in which content management is displayed. Then you have to create your own tabstrip event and to maintain the text table for the description:

- Account: Attachments/Anlagen

- Sales: Attachments/Anlagen

- Lead: Attachments/Anlagen

- Marketing Planner: Documents/Dokumente

- Product: Documents/Dokumente

- Mobile: Attachments/Anlagen

- Within the tabstrip, the documents are still called documents.

• Make an entry in table CRMC_BLUEPRINT:

- Event = CMT_CM

- Position = ODP 1 = 3

- Screen type = Content Management

- Structure name = CRMT_BSP_CM_OBJ

- Field group = CMT_MAIN

- Toolbar group = CMT_MAIN

• If your application uses folder templates (IMG: CRM → Basic Functions → ContentMgmt. → Define Templates for Folders), these templates are assigned to your objects within Customizing (for example, CRM→MasterData→Product→Settings for ProductType→ Assign ContentMgmt Folder Template to ProductType). To create these folders on the initial call of the document tab, use method CL_CRM_DOCUMENTS→CHECK_IO_EXISTENCE. For an example in the classic Dynpro UI, see function group COM_PRODUCT_DOCUMENT, form save_document_file_folderexist.


• A "display mode" is not available in the UI. But a result list object in the application may be locked and in this case content management has to be set to “read only”. In the READ method ET_FIELD_ATTRIBUTE has to be filled in as follows:

- FIELD_NAME = <SPACE>, this means all fields / the complete controller

- FIELD_PROPERTY = CL_CRM_BSP_FRAME_TOOLS → GC_ATTR_READ_ONLY

• Currently, there are no authorization checks for documents. There is only a check for the business object authorization in CL_CRM_DOCUMENTS → BO_AUTH_CHECK.

• Include a new entry into the blueprint layout table: Event = CMT_WHERE_USED, Position = Pop-up, Screentype = LIST, Fieldgroup = CMT_WHERE_USED, Toolbargroup = CMT_WHUSE, Tabgroup = CMT_02, DocuClass = IWB_EXTHLP, DocuObjectID = 9DFFCA4B6AC78B4FB30F1A64535FCCAB.

• Add a message for Navigation for Application Log for your application set with: messageID = CRM_DOCUMENTS, messageNo. = 105, Position = Pop-up, Action Event = CMT_WHERE_USED. Make sure that your access class calls CL_CRM_BSP_CM_ACCESS → GET_MESSAGES. Otherwise the where-used popin will not appear!

• Assign content management’s toolbars (CMT_MAIN, CMT_WHUSE), tabgroup (CMT_02), and search scenario (CMT_001) to your application set.

• Assign content management’s model access class CL_CRM_BSP_CM_ACCESS for screen structure CRMT_BSP_CM_WHERE_USED to your application set.

5.2.10 Send Screen for E-Mail or Fax

The send screen provides the necessary capabilities for all applications that send e-mail and faxes. When the user chooses the e-mail/fax button in the toolbar, a send screen appears in a popin (see also section 5.2.3).

The popin is divided into three areas:

• Box to edit text for the e-mail or fax

• List of recipients

• Search to find recipients

Also, the functions Upload Document, Find Document, and Delete Document are available for attaching documents.


Figure 5.38: Screenshot of Send-Screen Popin

5.2.10.1 Integrating the Send Screen into a Blueprint Application

The following steps have to be performed:

• Create an E-Mail/Fax button in your application with a corresponding event. In this example, it is called SRV_BF_MAX_OPEN_POP, but this should be an application-specific event. Thus all entries are up to the application developer except for the text, which should be the same in all applications (E-Mail/Fax). Customize the application set in transaction CRMC_BLUEPRINT.

• Add the predefined toolbar group SRV_BFMAX1 to your specific application set.

• Add the predefined screen structures CRMT_BSP_BF_MAX, CRMT_BSP_BF_MAX_A, CRMT_BSP_BF_MAX_R, and CRMT_BSP_BF_MAX_S to your specific application set. The four screen structures are assigned to four different screen areas on the send screen popin:

- The attachment list, rendered via the UI framework

- The recipient list, rendered via the UI framework

- The general attributes, rendered via the UI framework

- The e-mail description and text, hard-coded rendering

• Create an application-specific subclass of class CL_CRM_BSP_BF_MAX_ACCESS and assign the new class as model access class to all screen structures.

• Customize application/layout in transaction CRMC_BLUEPRINT. Add the event created first with screen position popin to your application. For the screen setup use the field group SRV_BF_MAX_BASIC and the toolbar group SRV_BFMAX1. As a final step, add the screen structure CRMT_BSP_BF_MAX.

• Create a message for the popin (see also section 5.2.3). For example, the message 999(B1) (this could be an application-dependent message). Also customize Navigation for Application Log in transaction CRMC_BLUEPRINT (see section 5.1.1). Here you


have to maintain the link between the message and the popin. Reuse the event defined at the first step as the action event.

• Fill out fields APPLICATION, MSGID, MSGNO, OBJECT_NAME, and FIELD_NAME exactly as in the message put into the application log to bring up the popup. The figure below shows how the system reads the corresponding Customizing:

Figure 5.39: Example Coding of Reading the Customizing Parameters

If and only if the search result controller returns this message to the main controller via method SRES2 → GET_MESSAGES, the popin is opened in this server trip. Thus the application (and not the send-screen popin) has to trigger display of the popin. The send-screen controller passes all events to the model access class defined in the second step. The send and cancel event, which closes the popin, stops the message from being passed to the result list and therefore to the main controller. If the message for the popin is triggered, the field REF_OBJECT has to be filled (this is the object key passed to the popin). The message indices must be unique – otherwise the application log controller will delete duplicates.

The toolbar group SRV_BFMAX1 contains all server-side events of the send screen. The events are mapped to the four possible positions on the popin via a naming convention.

5.2.10.2 Tailoring the Send Screen to Special Requirements

As mentioned above, the implementation of the subclass of CL_CRM_BSC_MAX_SC is necessary. If special functions of the send screen are required, such as the transfer of recipient data to the popin, some of the methods have to be modified as follows:

• If you want to provide initial recipients, attachments, or other attributes, when the popin is opened, re-implement method CREATE_DATA4PARENT_OBJECT_KEY of your model access class assigned to the send screen. This method is called if and only if there is no data for your object buffered in the model access class, that is, when the popin is opened.

• If you want to provide initial recipients, you should use method CL_CRM_BSP_MAX_SC=>GET_POSSIBLE_RECIPIENT_TYPES to determine whether the required recipient type is available (maybe the system parameters or the user parameters forbid some recipient types). Otherwise recipients provided by the application will be filtered away for the user.

• You should re-implement the methods EVENT_HANDLER_CANCEL and SEND_SUCCESSFULLY to close the popin (if the user cancels the popin). The default implementation cleans up the data. Thus please call method SUPER → EVENT_HANDLER_CANCEL/SEND_SUCCESSFULLY.

• You might want to re-implement the method SEND_UNSUCCESSFULLY. The default behavior is to create a message in the application log. Thus if you do not re-implement this method, the popin will stay open.


• All messages (send-screen controller and send-screen model access class) will be returned via method GET_MESSAGES of the send screen model access class.

5.2.11 The Survey Tool

The survey tool is a small application for handling questionnaires and ratings by filling out an interactive survey. The survey tool is implemented with a separate controller and view. The survey controller provides the survey representation using BSP elements. The survey controller also takes the survey-specific result stream and calculates the new survey value XML, which will be passed to the application for storing.

5.2.11.1 Including the Survey Tool in an Application

The survey tool is a tab in the ODP. When the user chooses this tab, a global event is passed to the main controller, which then calls the survey controller. The survey controller creates the view, which includes the tabstrip and toolbar, and replaces the Detail view. Therefore, the survey tool can be set only on screen position 3 or 4. The survey-specific programming objects are in package CRM_BSP_MODEL_IL_SURVEY.

In order to add the survey tool to a screen:

• Create a DDIC structure that includes survey-specific structure CRM_SVY_OBJECT or copy CRMT_BSP_SURVEY to your own structure.

• Create a new model access class. You will find some sample coding for accessing surveys in class CL_BSP_ACCESS_MODEL_SURVEY.

• Implement the READ method for the defined screen structure in order to retrieve the survey key from your object key. Fill in the specified interface structure.

• If you process an existing survey, at the very least, you must pass the value guide to the survey controller. Value version is optional.

• If there are no survey values assigned to your business object, you have to provide the survey ID specified in Customizing.

• Implement the MODIFY method in order to store survey data in your application. The survey controller will pass the survey value XML back to the application.

• Make an entry in table CRMC_ACCESS and assign the model access class to your screen structure.

• Make an entry in table CRMC_BLUEPRINT. Assign the survey to your application. Fill the attributes as follows:

- Screen type = SURV

- Screen structure = defined DDIC structure (with include CRM_SVY_OBJECT)

For more information on blueprint table maintenance, see section 4.3.2.

A good example for implementation of the survey tool can be seen in the class CL_CRM_BSP_AM_SURVEY_1O for Opportunities, Leads, and Activities.

As an alternative to using the MODIFY method of the model access class, it is also possible to use the callback interface of the survey tool to save a survey.


5.2.12 Document Preview

With the preview controller, documents generated from blueprint applications can be previewed in the Adobe Acrobat Reader or in the browser before printing. The user can review the documents and print them locally via the browser or the Adobe Acrobat Reader. Previewed documents can be displayed either on a special tabstrip or in a separate window. Display data has to be formatted in an Output Text Format (OTF) table or a table with HTML code, or a URL. The OTF table is converted into PDF and can be read by the Adobe Acrobat Reader.

Figure 5.40: Preview in a New Window

5.2.12.1 Integrating the Preview into a Blueprint Application

The following steps describe how to integrate the preview into a blueprint application:

• Create your own screen structure in your own package and include structure CRMT_BSP_PREVIEW.

• Create your own model access class corresponding to this screen structure.

• Implement the READ method in your model access class in order to fill the preview data from your object key:

- <ScreenStructure>-OBJECT_KEY = Business object (for example, GUID)

- <ScreenStructure>-HTMLDATA = HTML table for the preview

- <ScreenStructure>-OTFDATA = OTF table for the preview

- <ScreenStructure>-URL = URL

- <ScreenStructure>-LANGUDATA = relevant only for e-mail forms preview, table contains language IDs and descriptions for e-mail previews in different languages.

• If you use screen position “W” for the preview controller, it is not necessary to maintain the NEW_WINDOW parameter


• You may include an event for the preview in your tab group. Use the text “Mail Preview” or “Form Preview” (whatever is more suitable in your particular case) for the tabstrip.

• Make an entry in table CRMC_BLUEPRINT:

- Event for your preview function

- Screen position = ODP 1 - 3 or New Window

- Screen type = PREV “Preview”

- Structure name = <your new screen structure> (which includes CRMT_BSP_PREVIEW)

- Enter an adequate event in your toolbar or tabstrip to launch the preview

For an example, please refer to the application CRMD_MKT_IM_ML and its model access class CL_CRM_MKT_ML_ACCESS.

5.2.13 OIP as Separate iView

The People-Centric UI offers the possibility to work on a specific set of data of one application in a full screen mode. This is a very important part of the daily work of people. Another aspect is the quick overview about business data.

For that overview pages with a set of different iViews, which display different data, are used. To ensure, that the user interface of these iViews is the same as in the full-screen blueprint applications, a special mechanism is provided. The OIP of a blueprint application can be used as a separate iView.

The focus of this OIP – iView is not to offer the possibility to maintain data on those overview pages. It is more a preview than a data maintenance container. Of course there is possibility to navigate to the selected object(s) to work on them.

5.2.13.1 How to include the OIP in an iView?

Every existing blueprint application can be used for an iView. To configure an iView within the portal the URL of the source application has to be maintained. To use a blueprint applications OIP as an iView, the URL usually used to point to a blueprint application has to be enhanced with the additional parameter OICONLY. If the UI framework gets this parameter within the URL the OIP of the specified blueprint application is displayed in the iView. However some functions like the toggle button etc. are not included.

It is possible to customize the OIP – iView with the following parameters. They have only to be included in the URL. NO_TITLEBAR: the complete title will not be shown including minimize / maximize buttons

NO_SREQ: the search area will not be shown, only the result list with the results of the predefined query is displayed

NO_MARK: it is not possible to mark an entry because the first column will not be shown

Toolbar

The OIP – iView differs a little bit from the usual OIP. To provide only the service of an overview no toolbar buttons are displayed except two: The ‘TRANFER LIST’ button and the ‘PRINT LIST’ button. The first button will transfer the list to the corresponding blueprint application where the


user could work on the data. The second button gives the user the possibility to print the complete list. The toggle button will also be not visible.

Editing entries

The records in the list are displayed as ‘read only’, because it is only an overview. If a user wants to edit an entry then she/he has to perform just one click on a link to navigate to the corresponding blueprint application. The column(s) which display(s) the link can be defined in the field group table. If IS_NAV_FIELD is marked in the field group table all fields with this property are rendered in the iView as hyperlink, so that a user can navigate to the full application. This works also if the value of the field is empty. The read-only feature reduces the number of locked entries, too.

Interaction with other iViews

If an entry is ‘markable’, the controller would fire an iView event. On this event other iViews could react to adapt their data.

5.3 User Interface Integration of Generic Application Services

Services like object creation, handling of actions and dealing with business partners are used in various applications. This section describes how these generic application services can be integrated into blueprint applications.

5.3.1 Creating New Objects

There are three generic ways to create a new object:

• Standard: Creation of a complete new object in the result list or adding new dependent child objects in the ODP

• For objects with a lot of data to be entered: Creation of a new object in a new browser window

• Creation of follow-up objects: For example, to make an order out of a quotation. This is implemented by creation of new objects in a new window. The data of the source object is passed to the follow-up object.

5.3.1.1 Creating a New Object in the Result List

When the Create button is pressed, an empty line is displayed. Technically the search result controller creates a new empty line in the search result key table on top of the current focus. Now the new focus is this new line. Depending on the blueprint table, an appropriate screen structure and field group can be provided for this event (usually not necessary).

With SAP CRM 4.0 the process of creating new objects has slightly changed although the previous method as used in SAP CRM 3.1 is still supported. Now, after the Create event, the PROCESS_EVENT method is called. The application then creates the object, including any possible default values and returns the object key to the framework. Afterwards the READ method is called to update the list and the new object is displayed as a focus object within an empty line, but already with its object key. This line is treated by the framework in the same way as any other line. Possible user changes are sent via the MODIFY method to the application.

Technically the creation of a new object in the search result works like this:

• The CREATE event is raised by a toolbar button


• The PROCESS_EVENT method is called so that the application can react to this event, especially an object key can be determined and returned (parameter EV_OBJECT_KEY).

• Then the READ method with the new object key returned by the PROCESS_EVENT method (or initial if nothing was returned) is called, so that the application can fill in some dynamic default values. In that case the default values from the field group tables are overridden.

5.3.1.2 Creating a New Object in the ODP

When the user presses the Add Line button in the ODP, an empty line (or form view in the ODP) will be provided. The detail controller creates a new empty line in the detail table. Depending on the blueprint table, an appropriate screen structure and field group can be provided for this event. Usually this is not necessary. The detail controller calls the READ method to fill the additional fields with default values. This new line is the new focus. The data of the ODP below the current one is not ready for input at this moment. After entering data in the new line, the MODIFY method of the model access class is called and the data of the newly-created object is transferred to the application. For child objects of the objects in the result list, the MODIFY method does not return the keys, as the READ method reads all subobjects of the focus. Therefore, it is also not a problem if internal additional child objects are created. Child objects are, for example, the items of an order.

For child objects, creating a new object in a list view in the ODP works like this:

• The event ADD_LINE is raised.

• First the READ method with the parent object key is called. There is no READ method call with an initial object key for the new line itself.

• Next the default values from the blueprint tables are read. These fields are automatically included in the field list for the MODIFY method.

• There is also no PROCESS_EVENT method call for the raised event.

• The MODIFY method is called with initial object key. All fields with default values from the field group table plus all fields changed by the user are in the IT_CHANGED_FIELD → FIELD_NAME_TAB parameter. Therefore some fields are duplicated because they have a default value from the field group table and these fields are changed by the user.

• The MODIFY method returns the object key of the new object.

5.3.1.3 Creating New Objects in a New Window

For complex objects (where a lot of fields have to be maintained during creation), it is possible to open a new browser window within the relevant application. This is very useful for lists of products in the ODP, for example.

Therefore the creation event is related to a URL. In the table CRMC_BSP_EVENT, the same fields for URL definition are provided as in the table CRMC_FIELDGRP for object link definition. When the event is raised the method PROCESS_EVENT of the model access class is called first to set the context for the next window. A new window for the URL is opened by the framework.

When a new object is created in a new window, the application needs to pass data to this object. For example, Account Management should propose the account number when a new opportunity is created in the new window, or quotation data needs to be copied into an order when a follow-up object is created in the new window.


For this data transfer, a generic model context class for data context is provided. This model context class CL_CRM_CONTEXT contains relevant data of the model. Data can be set into the model context class by the READ, MODIFY PROCESS_EVENT methods of the model access class. Data is stored as name reference pairs. This context class is provided by the UI framework (see section 4.3.3).

5.3.2 Actions

The Post Processing Framework (PPF) provides SAP applications with a uniform interface for the condition-dependent generation of actions (for example, printing delivery notes, faxing order confirmations, or triggering approval procedures). Actions are generated if specific conditions occur for an application document. They are then either processed directly or at a later time. Actions are important for maintaining and improving business relationships. Predefined processes can be scheduled and started with the actions component by means of user-definable conditions from transaction documents.

For example, one month before the expiry of a quantity contract, the sales employee responsible receives a reminder in his or her inbox to make a telephone call. The purpose of the telephone call is to discuss a new contract. This reminder has been initiated by an action.

The system processes the actions automatically as customized. However actions can also be scheduled and started manually. The actions component also provides the technique of controlling output. It is used within CRM for printing transaction documents.

In the People-Centric UI actions are included as follows:

• Result list Print button, which launches document preview for printing via Acrobat Reader

• ODP 1 Action list (header level)

• ODP 2 Action detail (header level)

• ODP 2 Action list (item level)

• ODP 3 Action list (item level)


Figure 5.41: Example of Actions in a Separate Tab

Integration takes place by simply maintaining the blueprint tables. In order to be able to change the logic and tab sequence from a central point you should not create your own screen structures, function codes, events, or entries for actions but use the existing ones. Thus the logic is kept uniform and the program control that relies on certain naming conventions, for example, to hide or deactivate fields or buttons, works. Furthermore, there is the same functionality and “look and feel” across all applications.

The implementation of the CRM Quotations application (CRMD_SALQ) is a good example of the necessary changes.

These are the settings of the blueprint tables that you have to maintain for your application:

Screen Structure Model Access Class

Scheduled Actions

CRMT_BSP_ACTION_ACTIV_H CL_CRM_BSP_Error! Bookmark not defined.ACTION_1O

CRMT_BSP_ACTION_ACTIV_I CL_CRM_BSP_Error! Bookmark not defined.ACTION_1O

Actions to be scheduled

CRMT_BSP_ACTION_INACT_H CL_CRM_BSP_ACTION_1O

CRMT_BSP_ACTION_INACT_I CL_CRM_BSP_ACTION_1O

Action Details

CRMT_BSP_ACTION_HTML_LOTXT CL_CRM_BSP_ACTION_1O

CRMT_BSP_ACTION_HTML_SCOND CL_CRM_BSP_ACTION_1O

CRMT_BSP_ACTION_LIST_COPAR CL_CRM_BSP_ACTION_1O

CRMT_BSP_ACTION_LIST_PRLOG CL_CRM_BSP_Error! Bookmark not defined.ACTION_1O

CRMT_BSP_ACTION_LIST_PRPAR CL_CRM_BSP_ACTION_1O

CRMT_BSP_ACTION_OTF_PREVW CL_CRM_BSP_ACTION_1O

Print Button in Result List (for Document Preview)


Screen Structure Model Access Class

CRMT_BSP_ACTION_OTF_PREVW_TB CL_CRM_BSP_ACTION_1O

Figure 5.42: Entries in CRMC_ACCESS for Actions

To display the scheduled actions at header and item level, add events ACI_H and ACI_I to your tab group. For objects that do not have the header/item structure, ACI_H will be sufficient.

Appli-cation


Screen Type

Field Group Toolbar Group

Regtab Group

Scheduled Actions

ACI_H 3 LIST ACI_ACTIV_H ACI_ACTIV Application-specific (SALQ_ODC1)Error! Bookmark not defined.

ACI_H 4 HTML ACI_LONGTEXT ACI_DET_H

ACI_I 4Error! Bookmark not defined.

LIST ACI_ACTIV_I ACI_ACTIV Application-specific (SALQ_ODC2)

ACI_I 5 HTML ACI_LONGTEXT ACI_DET_I

Action Details Header

ACI_CONDPARAM_H 4 LIST ACI_CONDITIONPARAMETER

ACI_DET_H

ACI_LONGTEXT_H 4 HTML ACI_LONGTEXT ACI_DET_H

ACI_PRNTPREV_H 4 PREV ACI_PRINTPREVIEW

ACI_DET_H

ACI_PROCLOG_H 4 LIST ACI_PROCESSINGLOG

ACI_DET_H

ACI_PROCPARAM_H 4 LIST ACI_PROCESSINGPARAMETER

ACI_DET_H

ACI_STARTCOND_H 4 HTML ACI_STARTCONDITION

ACI_DET_H

Action Details Item

ACI_CONDPARAM_I 5Error! Bookmark not defined.

LIST ACI_CONDITIONPARAMETER

ACI_DET_I

ACI_LONGTEXT_I 5Error! Bookmark not defined.

HTML ACI_LONGTEXT ACI_DET_I

ACI_PRNTPREV_I 5Error! Bookmark not defined.

PREV ACI_PRINTPREVIEW

ACI_DET_I

ACI_PROCLOG_I 5Error! Bookmark not defined.

LIST ACI_PROCESSINGLOG

ACI_DET_I


Appli-cation


Screen Type

Field Group Toolbar Group

Regtab Group

ACI_PROCPARAM_I 5 LIST ACI_PROCESSINGPARAMETER

ACI_DET_I

ACI_STARTCOND_I 5Error! Bookmark not defined.

HTMLError! Bookmark not defined.

ACI_STARTCONDITION

ACI_DET_I

Print Button in Result List area (for Document Preview)

PRINT W PREV ACI_PRINTPREVIEW_TB

Figure 5.43: Entries for Actions in the Main Blueprint Table

To enable actions for printing as a button, add event PRINT in the toolbar group of the result list.

To enable actions to be scheduled as a button, follow these steps: • Assign the event ACI_INACT_TOOLBAR to the respective toolbar group.

The toolbar should be displayed within the “extended” functions, therefore mark the corresponding flag. Assign event group ACI_TB to the new entry.

• Find the model access classes for both header and item (item is only necessary for structured applications) and add the coding shown below for methods TOOLBAR_FILL_EVENTGROUP and PROCESS_EVENT. (For the model access classes CL_CRM_BSP_AM_HEADFM_1O and CL_CRM_BSP_AM_ITEMTB_1O the changes are already implemented.)

TOOLBAR_FILL_EVENTGROUP: ... ... INCLUDE crm_bsp_appl_con. INCLUDE crm_object ... * call action determination CALL METHOD cl_crm_bsp_action_list_tb=>toolbar_fill_eventgroup EXPORTING iv_filter_value = gc_bsp_appl-oneorder <-- your application iv_object_key = iv_object_key iv_ref_kind = gc_object_kind-orderadm_h/i <-- fill correctly iv_eventgroup = iv_eventgroup CHANGING ct_event = ct_event. PROCESS_EVENT: ... ... INCLUDE crm_bsp_appl_con. ... ... * execute action EventGroup (Schedule Actions) CALL METHOD cl_crm_bsp_action_list_tb=>toolbar_process_event EXPORTING


iv_event = iv_event iv_filter_value = gc_bsp_appl-oneorder <-- your application iv_focus_object_key = iv_focus_object_key iv_event_index = iv_event_index.

• Maintain the Business Add-In (BAdI) implementation for CRM_BSP_ACTION_BADI for

your filter value. If the filter value is CRMD_ORDER, the implementation already exists.

5.3.3 Document Flow

In general document flow is used to track the flow of related business documents. If document flow is used in an application, ODP 1 always displays document flow in a tree or in a list and ODP 2 shows item relationships.

The following steps are necessary to integrate document flow:

• For ODP 1 create your own screen structure, in your own package with the first field as OBJECT_KEY and include the structure CRMT_BSP_GEN_DOCFLOW_OJ, or alternatively you can use the screen structure CRMT_BSP_GEN_DOCFLOW.

• For ODP 2 create your own screen structure, in your own package with the first field as OBJECT_KEY and include structure CRMT_BSP_ITM_DOCFLOW_OJ, or alternatively you can use the screen structure CRMT_BSP_ITM_DOCFLOW.

• For ODP 1 use the field group DOCFLOW_GENERIC. Please do not make changes to this field group entry. Alternatively create your own field group referring to DOCFLOW_GENERIC.

• For ODP 2 use the field group DOCFLOW_ITM_GENERIC. Please do not make changes to this field group entry. Alternatively create your own field group referring to DOCFLOW_ITM_GENERIC.

• For the blueprint entries, as an example, please refer to the application CRMD_BUS2000111 with events OPPORT_HD_DOCFLOW. If you would like the document flow to be in a tree structure then the SCREEN TYPE should be TREE otherwise it can be a LIST. If it is a LIST then you may want to display the field PARTROLE which holds the role of the document (For example, “Preceding Document” or “Next Document”). This can be enabled through the field group entry. Just uncheck the attribute "Not in List" for the field PARTROLE.

• For ODP 1 use the model access class CL_CRM_BSP_AM_HEADOM_1O. Alternatively create your own model access class corresponding to the screen structure. This model access class should call the method CL_CRM_BSP_INTLAY_DOCFLOW → GET_DATA with the corresponding screen structure name.

• If you are creating your own modelError! Bookmark not defined. access class for ODP 1 then you will have to implement the interface IF_CRM_BSP_TREETABLE_IL. Here the methods READ_CHILDREN, READ_ROOT_DESCR and REFRESH have to be implemented. The code can be reused from the model access class CL_CRM_BSP_AM_HEADOM_1O.

• For ODP 2 use the model access class CL_CRM_BSP_AM_ITEMOM_1O. Alternatively create your own model access class and call the method CL_CRM_BSP_INTLAY_DOCFLOW → GET_DATA with the corresponding screen structure name.


5.3.4 Date Management

5.3.4.1 Introduction

Date management provides a service for all blueprint applications that require time stamps, time intervals, durations, and operations. In addition, dependencies within date management are defined using date rules.

The following options are available for displaying the time stamps, time intervals, and durations:

• Time string In the date management customizing, the display format of the time stamp is defined:

The checked properties determine how the time string is formed:

The limitation is that the BSP environment has no input help with which the date and time components of the time string can be changed. However, this is not serious, as most applications only require the date and weekday. In the BSP and the SAP GUI for Windows interface there is unfortunately no inline navigation (navigation using the tab key within the string).

• Date and time: the time stamp is split into date and time. You can only use the date.

• Duration: string that delivers the duration in whole numbers.

In each area of the UI (result list, ODPs), you can maintain or display the time stamp for each date type using either the time string or the date or time. If the developer offers both formats simultaneously for each date type, the time string has internal priority. In Activity Management, date and time are predominantly used, in other transactions the time string is used.

5.3.4.2 Implementation

The date management display is controlled by the screen structure. The display-formatting in date management is performed by the interaction layer of the UI framework. To do this, the screen area of date management, which is to be displayed as defined in the date management customizing, is required as information. Different screen areas are possible for each transaction. The screen area is determined from the interface structure name, which is formed as follows: CRMT_BSP_XXX_*, where XXX is the application ID. A screen area is assigned to this ID in the APPL_GROUP_DETERMINE method of the CL_CRM_BSP_INTLAY_DATES generic class.

5.3.4.2.1 Implementation of Table View

The structure CRMT_BSP_GEN_DATES is to be included in the screen structure, whereby the components of the structure CRMT_BSP_GEN_DATES correspond to the UI structure in the SAP GUI for Windows. The screen structure used must conform to the naming convention outlined above, for example, CRM_BSP_CFM_OD2_DATES_OJ.


5.3.4.2.2 Implementation of Form View

The content of date management is serialized. The position of a date type is defined by the display position in the date management customizing. You cannot use a semantic definition for this. If the “Start of Contract“ is meant to appear in the result list, then the date type “Start of Contract“ must be maintained in customizing with the lowest display position. The start of contract is then always shown at the front of the structure in each form view, independent of the area (result list, ODP, and so on). If the date type represents a time interval (only in Activity Management) then at least two date fields are needed, one for the start point and one for the end point. The duration is always provided in the field TIME_OUT (time string).

Component Properties Description

APPT_TYPE1 Must field Internal key date type

IS_DURATION1 Must field Internal key duration

APPT_TEXT1 Display Date type text

DATE1 Changeable Date




DATE2 Changeable Date

TIME2 Changeable Time




TIME_OUT3 Changeable Time string




TIME_OUT4 Changeable Duration as time string

TIME_UNIT4 Changeable Time unit

TIME_UNIT_TEXT4 Display Time unit text

Figure 5.44: Example of a Screen Structure for Date Management

The fields APPT_TYPEN, IS_DURATIONN must have the value N ={1,…,M}. If the fields TIME_UNITxxx are contained in the structure and the current date type is a time stamp and not a duration, then these fields are not filled.

In Activity Management, different date types are used, but only one date type is displayed in the people-centric UI. This date type is determined using date management. In a form view, only this date type can be used. For this, the interface structure keeps the space for two points in time (the first space for the start time or start date, and the second for the end time or end date).

A good example is the Activity Management screen structure CRMT_BSP_ACT_DATES_OJ from component APPT_TYPE1.


5.3.5 Business Partners

Often business partners are used in several applications. They can be included in both the result list or ODPs. The following steps describe how to integrate business partners into these containers:

Integration into the Result List

• To implement business partners in the result list, include the structure CRMT_BSP_DTL_PARTNER_OJ in the result list screen structure.

• An example of the business partners in the result list is shown below in Business Opportunities.

Figure 5.45: Example Business Partners in Opportunity Management

Integration into the ODP

• For objects that want to show the business partner in the detail screen, the structure CRMT_BSP_DTL_PARTNER_OJ and CRMT_BSP_OVW_PARTNER_IM have to be included in the screen structureError! Bookmark not defined..

• The screen structure with the above-mentioned structures looks like this:

Figure 5.46: Business Partner in the ODP

Integration into the Tabstrip

• For objects that want to show all the business partners under the tab Partners create a structure which includes the following two structures:

- CRMT_BSP_OBJECTKEY

- CRMT_BSP_DTL_PARTNER_OJ


• Assign this screen structure to the tabstripError! Bookmark not defined. in the blueprint table

• This will allow you to see all the partners that are currently active for this business object

Figure 5.47: Business Partners on the Partners Tab

Integration into the Popin

• For the address selection popin the structures CRMT_BSP_PARTNER_ADDRESS and CRMT_BSP_PARTNER_ADDRSEL_OJ have to be included.

Figure 5.48: Business Partners on the Address Selection Popin

• For the partner selection popin the structures CRMT_BSP_PARTNER_PARTNERSEL and CRMT_BSP_PARTNER_PARTNERSEL_OJ have to be included.

Figure 5.49: Business Partners on the Partners Selection Popin

5.3.6 Business Address Services

Documentation about the general BAS functionality can be found in the SAPNet under http://intranet.sap.com/bas or under the alias BAS in the SAPNet. Information about the BAS can be found in the internal help portal http://helpportal:1080 -->Documentation in Progress --> SAP Web AS 6.30 --> <Language> --> SAP NetWeaver Components--> SAP Web AS --> Basis


Services/Communication Interfaces --> Business Address Services (BC-SRV-ADR) or under the alias “bas” in SAPNet http://intranet.sap.com/bas.

Providing the BAS functionality as reusable objects provides application developers with the same advantages using the Business Address Services means in SAP GUI:

• .Uniform layout of address data in all applications using the BAS

• .Address checks

o Consistency and plausibility

o Tax jurisdiction code

o Duplicates

o Postal validation (this is currently under development)

• .International address versions

• .Communication data

• .Substantial cost reductions due to reuse

The Business Address Services (BAS) provide reusable tools for the user interface that allow blueprint applications to maintain addresses. There are two ways of implementing the address services:

• The application uses the address controller provided by the BAS of Application Basis (ABA). This way all details of an address can be maintained.

• The application only includes some address fields in its own screen structure and uses the BAS model access class to handle the changes. This option is discussed in section 5.3.6.7.

Changes to the content of this chapter can be found in OSS-Note 583404.

5.3.6.1 Integrating Address Services into an Application

In this section we give an overview of the steps that have to be taken by the application developer in order to include the address controller in the UI. To most of the steps detailed information will follow in the next sections. The steps are as follows:

• Create a subclass of the abstract model access class template CL_BSP_ACCESS_MODEL_ADDRESS(for the remainder of this document we will call this subclass CL_BSP_APPLICATION_ADDRESS).

• In the class CL_BSP_APPLICATION_ADDRESS implement the method GET_ADDRESS_KEY. In this method the application provides for each object key the corresponding address ID, consisting of address type, address number or handle, and person number or handle if required.

• In the class CL_BSP_APPLICATION_ADDRESS, implement the method ADDRESS_IS_CREATED. This method will be called to notify the application that a newly created address was written to the BAS memory successfully for the first time. More details can be found in section 5.3.6.4.2.

• In transaction CRMC_BLUEPRINT maintain the application set of your application under “Model Access” in the following entry:


Structure Name Model Access

CRMT_BSP_ADDRESS CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADTEL CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADFAX CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADTLX CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADSMTP CL_BSP_Error! Bookmark not defined.APPLICATION_ADDRESS

CRMT_BSP_ADRML CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADRFC CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADPRT CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADURI CL_BSP_APPLICATION_ADDRESS

CRMT_BSP_ADSSF CL_BSP_Error! Bookmark not defined.APPLICATION_ADDRESS

CRMT_BSP_ADPAG CL_BSP_APPLICATION_ADDRESS

Figure 5.50: Model Access Class for Business Address Services

• In transaction CRMC_BLUEPRINT under IMG activity CRM UI: Blueprint Tables -> Application Elements -> Application Set -> Model Access for your application maintain the following entries:

Structure Name SPACE

Access Class SPACE

Reference Application ADDR_DETAIL • In transaction CRMC_BLUEPRINT at “Application/Layout”, maintain the following entry

for the main blueprint table for your application: View: Your view Event: Navigation event leading to the address controller Position: Position of the address controller in the application Screen Variant: Your screen variant Scrn Elmnt Type: Multi ODC Field Group: ADR_DETAIL Toolbar Group: ADR_DETAIL Tab Group: Your tab group Search Grp: SPACE Docu Class: SPACE Object ID: SPACE

• In transaction CRMC_BLUEPRINT at Application Elements → Message Group maintain the following entry for your application under “Navigation for Application Log”: Message ID: SPACE Message number: SPACE + (Context): The context of the address within your application + (Message Group): ADR_DETAIL Object Name: SPACE Field Name: SPACE Event: The navigation event that leads to the Address Controller


Screen Position: The screen position of the Address Controller Action Event: SPACE The value entered under Context here must be the same as the value that the method GET_ADDRESS_KEY of class CL_BSP_APPLICATION_ADDRESS returns.

• Adapt the coding of your own model access classes.

Note:

Pay special attention to the fact that none of the applications’ process classes may return the value “9” with the method GET_PRIORITY.

5.3.6.2 Objects Involved in Business Address Services

5.3.6.2.1 The CL_BSP_ ACCESS_ MODEL_ADDRESS Class

This class is the abstract superclass for the actual application-specific model access class of the application. Most methods have already been implemented.

However there are some methods that have to be implemented in the application because it requires application-specific logic. These methods are:

GET_ADDRESS_KEY



IV_SCREEN_STRUCTURE_NAME Importing Name of Screen Structure

ES_ADDR_KEY Exporting Return address ID and context

EV_CONTEXT Exporting Application Context

ER_PARAMETERS Exporting Data Container Address

ADDRESS_NOT_EXIST Exception

Figure 5.51: Interface of GET_ADDRESS_KEY Method

The address controller only gets the application-specific object key from the main controller. Now the address controller itself has no way of determining the address ID from this object key. Therefore this method is called. Depending on the object key, the application has to return the address ID in structure ES_ADDR_KEY and the context of the Address controller in EV_CONTEXT. The context is only needed when using more than one address controller in the same application. The screen structure and the context are only needed when using more than one address controller in the same application. Additional information has to be returned with the parameter ER_PARAMETERS. More details about these additional parameters can be found in section 5.3.6.3.1.


ADDRESS_IS_CREATED



IV_ADDR_KEY Importing Address ID and context

Figure 5.52: Interface of ADRESS_IS_CREATED Method

This method is called to notify the application that a newly created address has been successfully inserted into the BAS local memory for the first time. This means the application will have to obtain an address number and/or person number before saving the address. More details on this can be found in section 5.3.6.4.2.

GET_GLOBAL_PARAMETERS


ER_GLOBAL_PARAM Exporting Parameters

Figure 5.53: Interface of GET_GLOBAL_PARAMETERS Method

This method asks the application for parameters that are independent of the individual address. It is necessary for the address controller to know these parameters, even if there is no address selected for display (for example, at the start of a transaction). More details about these additional parameters can be found in section 5.3.6.3.2.

The class has a few additional methods for use by the application. They are:

GET_ADDRESS_NUMBER


IV_ADDRESS_HANDLE Importing Handle for creating addresses/persons (BAS)

IS_ADDRESS_REFERENCE Importing Transfer structure for the use of addresses

IV_PERSONAL_ADDRESS Importing Flag: This is a personal address

IV_NUMBERRANGE_NUMBER Importing Number range number

IV_OWNER Importing Checkbox field

EV_RETURNCODE_NUMBERRANGE Exporting Return code

EV_ADDRESS_NUMBER Exporting Address number

Figure 5.54: Interface of GET_ADDRESS_NUMBER Method

This method is similar to the function module ADDR_NUMBER_GET and should be used to obtain an address number for a newly created address. This method should be called in method CHECK_BEFORE_SAVE of the process class.


GET_PERSON_NUMBER


IV_PERSON_HANDLE Importing Handle for creating addresses/persons (BAS)

IS_PERSON_REFERENCE Importing Transfer structure for the use of persons (BAS)

IV_OWNER Importing Checkbox field

EV_PERSON_NUMBER Exporting Person number

EV_RETURNCODE_NUMBERRANGE Exporting Return code

Figure 5.55: Interface of GET_PERSON_NUMBER Method

This method is similar to the function module ADDR_PERSON_NUMBER_GET and should be used to obtain a person number for a newly created address.

DELETE_ADDRESS


IV_OBJECT_KEY Importing Object Key

IV_SCREEN_STRUCTURE_NAME Importing Name of Screen Structure

IS_ADDRESS_KEY Importing Address key

IS_ADDR_REF Importing Transfer structure for the use of addresses

IS_PERS_REF Importing Transfer Structure for Usage of Persons (Bus. Address Services)

IV_RETAIN_PERSON Importing Indicator: Delete Person Data (Only Type 2)

EV_DELETE_SUCCESSFUL Exporting Indicator: Deletion Was Successful

ET_APPLOG Exporting Error Message Table

ET_CLASS_NAME Exporting Corresponding MAC

ADDRESS_NOT_EXIST Exception Address specified does not exist

Figure 5.56: Interface of DELETE_ADDRESS Method

This method is used to delete an existing address. It should be called within the DELETE method of the applications model access class. Either the object key or the address key have to be provided in order to identify the address. The structures IS_ADDR_REF and IS_PERS_REF have the same meaning as in the DELETE function modules in function group SZA0. The parameter EV_DELETE_SUCCESSFUL will indicate whether or not the delete encountered any problems. In case it does, the table ET_APPLOG contains all the error messages. The Parameter ET_CLASS_NAME contains the name of the corresponding process class. The calling application has to pass this to the interface layer, else the deletion will not be saved.


INITIALIZE_ADDRESS


IV_OBJECT_KEY Importing Object Key

IS_ADDRESS_KEY Importing Address key

ADDRESS_NOT_EXIST Exception Address specified does not exist

Figure 5.57: Interface of INITIALIZE_ADDRESS Method

This method is used to undo all changes to an existing address. It should be called within the applications initialization class. Either the Object Key or the Address Key have to be provided in order to identify the address. If the address was newly created and not yet saved its creation will be undone. The implementation of the methods GET_SYNCHRONIZED_FIELDS and SET_SYNCHRONIZED_FIELDS is optional. They are necessary to synchronize fields with the application (see section 5.3.6.5.2). This method DUPLICATES_FOUND only needs to be implemented if the application wants to use the feature Enabling Duplicate Checks with Third Party Tools.

5.3.6.3 The Class CL_BSP_ADDRESS_PARAMETERS

5.3.6.3.1 The Class CL_BSP_ADDRESS_PARAMETERS

This class is used as a wrapper for several address-dependent parameters. The procedure of a class that has to be filled with SET methods has been used so that a check of the given parameters is possible. The following parameter SET methods are currently implemented:

SET_DIALOG_MODE


IV_DIALOG_MODE Importing Maintenance operation mode, default value “empty”

IV_ADDRESS_GROUP Importing Address group (key) (BAS)

IV_PERSON_GROUP Importing Person group (key) (BAS)

Figure 5.58: Interface of SET_DIALOG_MODE Method

This method has to be called to fill the parameter class each time the method GET_ADRESS_KEY is called.


SET_OPTIONAL_ADDRESS


IV_ADDRESS_IS_OPTIONAL Importing Address is not automatically created

IT_IRREL_FIELDS_FOR_INSERT Importing Field names that do not lead to create

Figure 5.59: Interface of SET_OPTIONAL_ADDRESS Method

As default behavior the address controller will try to insert a new address the first time the MODIFY method is called. By setting the flag IV_ADDRESS_IS_OPTIONAL to “X” this behavior can be changed. Now the address controller will only attempt to insert the new address if the user has made at least one entry in one of the fields.

Fields listed in IT_IRREL_FIELDS_FOR_INSERT will not trigger insertion of the address even if the fields are filled.

ENABLE_DUPLICATE_CHECK


IV_DUPLICATE_CHECK_IS_ACTIVE Importing Duplicate Check Is Active

IT_OBJECT_TYPES_FOR_SEARCH Importing Object types to be searched

IV_SEARCH_IN_ALL_OBJECT_TYPES Importing Flag: Search in all object types

IV_DIALOG_TYPE Importing Duplicate check method call mode

IV_SEARCH_IN_ADDRESS_TYPE_1 Importing Flag: Search in type1 addresses



Figure 5.60: Interface of ENABLE_DUPLICATE_CHECK Method

With this method the application enables the duplicate check for this address. The parameter IV_DUPLICATE_CHECK_IS_ACTIVE determines whether or not a duplicate check for this address will be conducted. The other parameters have the same meaning as in function module ADDR_ENABLE_DUPLICATE_CHECK. More details on the duplicate check process can be found in section #.

5.3.6.3.2 The Class CL_BSP_ADDRESS_GLOBAL_PARAM

This class is used as a container for address-independent parameters. In particular it contains such parameters that the address controller needs even if no address data is available for display on the screen yet. The following parameter SET methods are currently implemented:

SET_FIELD_SELECTION


IT_FISEL_TAB Importing Table for field selection

Figure 5.61: Interface of SET_FIELD_SELECTION Method


In the IT_FISEL_TAB table each application can modify the attributes of each address field on the screen. The field name given in the list has to correspond to the fields in structure CRMT_BSP_ADDRESS.

SET_ DISABLE_ADDRESS_VERSIONS


IV_DISABLE_ADDRESS_VERSIONS Importing Disabling of maintenance of international address versions

Figure 5.62: Interface of SET_ DISABLE_ADDRESS_VERSIONS Method

If the Parameter IV_DISABLE_ADDRESS_VERSIONS is set to 'X' then the display and maintenance of international address versions will be turned off.

5.3.6.4 Operating Procedures for Business Addresses

5.3.6.4.1 Displaying or Maintaining an Existing Address

If the address to be displayed or changed already exists, all the application has to do is to correctly implement the method GET_ADRESS_KEY of class CL_BSP_ ACCESS_ MODEL_ADDRESS in its own subclass CL_BSP_APPLICATION_ADDRESS. The address controller will read the address, apply all the changes and save it upon the event SAVE automatically.

5.3.6.4.2 Creating an Address

If the address to be maintained does not yet exist there is a little more the application has to do. Basically follow the following steps:

1) Before the address controller is called with the address to be created for the first time the application has to create a temporary pointer to the address in the form of an address handle and/or person handle. The application has to provide these handles in the method GET_ADRESS_KEY. Additionally it has to provide DIALOG_MODE = “CREATE” and the address group (and person group) of the new address using the method SET_DIALOG_MODE of the parameter class CL_BSP_ADDRESS_PARAMETERS.

2) Once the address has been inserted into the local BAS memory for the first time the method ADDRESS_IS_CREATED will be called to notify the application. The application should store this information for each handle. From now on the application can provide DIALOG_MODE = “CHANGE” in method SET_DIALOG_MODE.

3) During the method CHECK_BEFORE_SAVE of the applications process class, the application first has to determine the final key for the parent object of the address to be created (if the parent object is newly created as well). Then the application has to obtain an address number and/or person number for each address that has been inserted successfully. The address number or person number are obtained with the methods GET_ADDRESS_NUMBER or GET_PERSON_NUMBER. These numbers have to be stored in the applications database tables. From now on these numbers have to be provided in method GET_ADDRESS_KEY whenever this address is to be referred to. The methods GET_ADDRESS_NUMBER and GET_PERSON_NUMBER may not be called for addresses, for which the method ADDRESS_IS_CREATED has not been called.


5.3.6.4.3 Initializing an Address

In order to undo changes made to an address all the application has to do is to call the method INITIALIZE_ADDRESS. This should be done during the applications INITIALIZE method. It does not matter which instance of class CL_BSP_APPLICATION_ADDRESS is used.

5.3.6.4.4 Deleting an Address

In order to delete an address all the application has to do is to call the method DELETE_ADDRESS. This should be done during the applications DELETE method. It does not matter which instance of the class CL_BSP_APPLICATION_ADDRESS is used.

5.3.6.5 Additional Features

5.3.6.5.1 Message Handling

The model access class CL_BSP_ACCESS_MODEL_ADDRESS will store all address-related messages internally. All the application has to do is to call method IF_CRM_BSP_MODEL_ACCESS_IL → GET_MESSAGES of the application-specific subclass of CL_BSP_ ACCESS_ MODEL_ADDRESS inside the method IF_CRM_BSP_MODEL_ACCESS_IL → GET_MESSAGES of the result list-related model access class and append the resulting messages to the returned application log.

The method IF_CRM_BSP_MODEL_ACCESS_IL~GET_MESSAGES will at all times return the current state of the error table for all addresses, so there is no need for the application to buffer address-specific error messages.

5.3.6.5.2 Synchronizing Fields with the Application

Some applications hold within their own database tables identical copies of some address fields. The reasons for this are many. One example is the business partner, which keeps a copy of the name fields in the business partner tables, since a business partner must have a name even if it has no address.

In such a scenario it is necessary to synchronize the application fields and the address fields during the dialog. To do so, the application has to implement the methods GET_SYNCHRONIZED_FIELDS and SET_SYNCHRONIZED_FIELDS of class CL_BSP_ACCESS_MODEL_ADDRESS.

During the MODIFY method, the class CL_BSP_ACCESS_MODEL_ADDRESS uses the following procedure:

• It obtains the current value of the synchronized fields in the application fields with the method GET_SYNCHRONIZED_FIELDS.

• It compares these values with the old and the new value in the corresponding address fields and determines the new value of the field in the application fields.

• It passes this new value to the application by calling the method SET_SYNCHRONIZED_FIELDS.

The new value of the field in the application table is determined in the following way:

• If the value was not changed on the address controller, then any possible changes have been made in the application fields. Therefore the value obtained from the application fields is applied to the address fields as well and returned to the application unchanged.


• If the value obtained from the application is the same as the old value on the address controller, then the value has not been changed on the application fields. Therefore the new value in the address controller is kept and handed to the application.

• If the value obtained from the application is the same as the new value on the address controller, then any possible changes have been made simultaneously. In this case, no action is necessary, so the value obtained from the application is returned unchanged.

• If the value obtained from the application as well as the old and the new value in the address fields are mutually different, then the field has been changed in the address controller and in the application fields, with different results. In this case it is not possible to determine which was the last change, so the value in the address controller is kept and handed to the application.

5.3.6.6 More Than One Address Controller in the Same Application

It is possible without problems to have more than one address controller in the same application. For example the Business Partner Master Data could have one address controller in the detail controller for the address overview and another one to maintain the address independent communication data. Having more than one address controller is possible without problems. There are only three things the application has to be careful about: ...

1) If the different address controllers are on the same level (i.e. both are ODP1), then the parent object key will not suffice to distinguish between the two, so the application may run into problems when trying to determine the address key in method GET_ADDRESS_KEY. To solve this the screen structure used in the Layout by the second controller must not be CRMT_BSP_ADDRESS but CRMT_BSP_ADDRESS_2. Similarly the field group used in the Layout must be ADR_DETAIL_2 and the toolbar group used must be ADR_DETAIL_2 as well. Since the method GET_ADDRESS_KEY also provides the screen structure this will allow the application to correctly determine the address key for the current controller.

2) For the different address controllers the method GET_ADDRESS_KEY class CL_BSP_APPLICATION_ADDRESS must return different values in the field EV_CONTEXT.

3) For each value of EV_CONTEXT, a different entry must be maintained in the blueprint tables under 'Navigation for Application Log'. Each entry must point to the controller corresponding to the respective value of EV_CONTEXT.

The same method also works with 3 or more controllers in the same application. In this case further dummy structures like CRMT_BSP_ADDRESS_2 have to be created.

5.3.6.7 Using the Address Function Without the Address Controller

It is possible to use the model access class template CL_BSP_ ACCESS_ MODEL_ADDRESS without actually using the address controller. This is especially advisable if address fields are contained in some screen structures, while somewhere else in the application an address controller is used that could potentially maintain the same addresses.

To use the model access class template CL_BSP_ ACCESS_ MODEL_ADDRESS, proceed as follows:

1) Create a subclass of CL_BSP_ ACCESS_ MODEL_ADDRESS (we will call it CL_BSP_APPLICATION_ADDRESS) and implement the methods GET_ADDRESS_KEY, ADDRESS_IS_CREATED and the other ones you may need, as described before.

2) Of course you do not need to maintain any blueprint tables. Instead call the READ, MODIFY and FILL_DROPDOWN_LISTBOX method of class CL_BSP_APLICATION_ADDRESS within the


READ, MODIFY and FILL_DROPDOWN_LISTBOX method of your modelError! Bookmark not defined. access classError! Bookmark not defined..

Except for these points, handling should work just as described in sections 5.3.6.4.1 and 5.3.6.4.2.

5.3.6.8 Enabling Duplicate Checks with Third-Party Tools

Like in the Classic SAP-GUI the address controller will allow the application to implement a duplicate check by a third party tool. In order to do this the application has to do two things: ...

1. Provide the class CL_BSP_ADDRESS_PARAMETERS returned in method GET_ADDRESS_KEY with the necessary data for the duplicate check using method ENABLE_DUPLICATE_CHECK.

2. Implement the method DUPLICATES_FOUND of class CL_BSP_APPLICATION_ADDRESS. Every time an address that has gotten the flag DUPLICATE_CHECK_IS_ACTIVE is inserted or changed a duplicate check will be conducted. Should any duplicates be found then the method DUPLICATES_FOUND will be called to inform the application. The application then has to further process this information.

The interface parameters of method ENABLE_DUPLICATE_CHECK have the same meaning as those of function module ADDR_ENABLE_DUPLICATE_CHECK; the interface parameters of method DUPLICATES_FOUND have the same meaning as the exporting parameters of function module ADDR_DUPLICATE_CHECK_FOR_BAPI.

It is possible that the method DUPLICATES_FOUND will be called multiple times in one server-roundtrip, especially if address data is maintained in several of the controllers in the application. In this case the last call always has the correct data. In particular it is possible that DUPLICATES_FOUND is called with an empty result listError! Bookmark not defined., which means there are no duplicates and any previously recorded duplicates for this address have to be discarded.

5.4 Conclusion

To provide users with highly interactive, functional rich UI several generic services and specialized components were implemented. Well-known and appreciated UI services like F4 help, status managementError! Bookmark not defined. and an advanced message handling are available. Additionally specialized applications as content management, text management or survey tool can easily integrated into the People-Centric UI. Also usual services provided by SAP Basis like actions, addresses or dates can be used.


-


6 HOW TO EXTEND, CUSTOMIZE, AND PERSONALIZE THE PEOPLE-CENTRIC USER INTERFACE

The People-Centric UI is based on applications that use blueprint tables to define the screens of the user interface – these applications are therefore referred to as blueprint applications.

Tailoring blueprint applications to customers’ needs and user-specific requirements is supported by several means:

• Extensions (to extend SAP’s business object definitions)

• Customizing (installation-wide settings, performed by a system administrator)

• Personalization (user-specific settings)

The well-known procedures for modification of SAP sources and dictionary objects are also available. In addition, at portal level a set of generic, Java-based iViews (such as the Alert Inbox, Alert List, List, Related Links, and Search) is available as part of the Business Package for mySAP CRM and these iViews can be used as templates for developments by the customers themselves. For example, the generic Alert iView is used to provide the user with an overview of the available alerts. The alerts are grouped and totaled according to freely definable criteria, which are entered into the property file of the iView. The Related Links iView enables the user to navigate to additional Web addresses or to SAP EP pages. Therefore the iView is assigned to a workset in the portal and obtains its information from there. If an administrator inserts a new page in the workset, the iView will display it. The Related Links iView currently only works with a flat structure. For more information about handling the generic iViews, see the Configuration Guide of the Business Package for mySAP CRM in SAP Service Marketplace.

Blueprint application building, customizing, and extensions are tasks performed by developers, consultants, or administrators. Changes made at this level are valid for the whole system. All measures regarding personalization, however, concern the tailoring of the system to individual needs by the users themselves.

6.1 Extensions

Since SAP CRM 3.1 Support Package 3 (SP03), additional fields can be added to CRM objects using customizing includes (CIs). These CIs can be created either directly in DDIC or by using Easy Enhancement Workbench (EEW). With SAP CRM 4.0, additional features for business partner and business transaction are available as part of EEW (see section 6.1.4).

A CI is a placeholder for a customer-definable data structure attached to a business object in the Data Dictionary (DDIC). The naming convention for customizing starts with CI_*. Customers just create a structure that contains the additional fields and add that structure to the predefined CI (SE11). The field is automatically added to the database structures as well as to the user interface as input fields. CIs allow the extension of objects without modifications or upgrade problems. CI fields appear on the UI with no additional customizing. The anchor of each extension is an application object, not the UI. This approach is also used in the Mobile Application Studio.

The figure below shows the principle for a CRM application using the People-Centric UI. The “anchor” object of extensions is the application object containing a CI (for example, Activity Header). The relevant database table also includes this CI, as well as the API structures and one or more suitable screen structures. The CI is mapped directly between these places. All fields that belong to a CI of a screen structure are displayed automatically in the People-Centric UI with default properties (visible, editable). If a field is not to be visible on a particular screen, it can be switched off using Customizing Tool (see section 6.2.2.1).


API CI 1

CI 1

UI

CI 1 CI 1

Access Class

API CI 1

CI 1

UI

CI 1 CI 1

Access Class

Figure 6.1: Extension Concept with Customizing Includes

6.1.1 Restrictions

There are some restrictions to this very simple and lean approach: • Fields are displayed automatically on the application screens, that handle the

corresponding object. These screens are predefined

• Tables can only be added to the object types Business Partner and Business Transaction, fields can be added to every object

• BDocs in SAP CRM Middleware are only automatically extended for business partner and business transaction)

• Migrating manual extensions to CIs is not supported currently

6.1.2 Creating an Extension

It is recommended to use EEW for extending objects as it provides an automated, wizard-guided process. However to explain the concept in detail, the manual process is described:

• Create the CI providing the additional fields required in your CRM system’s Data Dictionary (transaction SE11). Use your data elements and domains to define the field properties. Make sure that field names are not longer than 16 characters or have a RAW type. Some CIs do not allow extensions with numerical fields and DDIC will report errors in such cases. Ensure that your field names begin with “ZZ”, as this is the DDIC naming convention for customer fields.

• After that, you can start the application – it will contain your fields

• Most CIs will appear on several screens. If you want to remove them from a particular screen, you can use CRM Designer, which can also be used to change properties of the fields.


Example:

You want to maintain a personal risk factor for customers (technically: Business Partners) of an insurance company. For that purpose, create a domain (for example, ZPERSRISK) with predefined risk values (for example, “LOW”, “MEDIUM”, or “HIGH”) and a data element (for example, ZPERSRISK) with a descriptive text (for example, “personal risk factor”). At last add this data element to the predefined CI called CI_EEW_BUT000.

Figure 6.2: Creation of a Customizing Include

Figure 6.3: Additional Field on the UI Using a Customizing Include


6.1.3 Extensible Applications

The following applications are extensible using the CI technique. Message BDocs contain the CI if the BDoc column is checked.

Object Customizing Include BDoc Remarks

Business Partner CI_EEW_BUT000 (X) If EEW is used

4)

Product Master 1)

Business Transaction CI_EEW_ORDERADM_H X

Business Transaction Item CI_EEW_ORDERADM_I X

Activity CI_EEW_ACTIVITY_H X

Opportunity CI_EEW_OPPORT_H X

Transaction Item – Product CI_EEW_PRODUCT_I X

Transaction Item – Financing Product CI_EEW_FINPROD_I X

Business Transaction – Sales Set CI_EEW_SALES X

Business Transaction – Shipping Set CI_EEW_SHIPPING X

Business Transaction – Billing Set CI_EEW_BILLING X

Organizational Unit Set CI_EEW_ORGMAN X

Business Transaction Pricing Parameter Set

CI_EEW_PRICING X

Transaction Item – Price CI_EEW_PRICING_I X

Business Transaction Item – Schedule Line

CI_EEW_SCHEDLIN X

Transaction Item – Service CI_EEW_SERVICE_I X

Transaction – Additional Extension CI_EEW_CUSTOMER_H X 2)

Transaction Item – Additional Extension CI_EEW_CUSTOMER_I X 2)

SDB – Symptom CI_EEW_ISMP

SDB – Solution CI_EEW_ISOL

Marketing Element: Basic Data CI_EEW_MKTPL_BDINC 3)

Marketing Element: Execution CI_EEW_MKTPL_CHINC 3)

Installed Base (Header) CI_EEW_IBIB

Installed Base Component – Addition/ Specialization

CI_EEW_IBSP

Remarks:

1) There has been another concept to extend Product Master since SAP CRM 2.0. With transaction COMM_ATTRSET, new attributes and own set types can be defined for use by the product master. These set types are part of the SAP GUI and of data exchange to SAP BW and SAP R/3. They are displayed in the People-Centric UI but they cannot be changed.


2) This CI is also part of the Order BDoc and appears in the external order interface (IDoc or XML).

3) There has been another concept to extend Campaign Management since SAP CRM 3.0. Using transaction CRMC_MKTPL_SETTYPE, new fields can be defined based on the set type technique. These fields are only visible in the SAP GUI, not in the People-Centric UI. Connection to SAP BW is supported, but not to SAP CRM Middleware. This functionality will also be provided for CIs in future, so CIs should be used for new extensions. Currently there is no migration concept to transfer set type fields to CIs.

4) BDT (Business Data Toolset) is another extension concept for Accounts (similar to set types for Products)

If the application provides BAdIs, customers will also be able to add business logic and coding without modifications to SAP coding. To extend business objects with new tables, the application will provide BAdIs in all methods of the model access class. This concept will be available after SAP CRM 3.1, SP03.

6.1.4 Easy Enhancement Workbench

As an alternative, Easy Enhancement Workbench (EEW) (transaction EEWB) can be used for extending objects.

EEW will simplify the customer's development process and will reduce errors by including the following features

• A guided user concept

• Wizards (enabling extensions to be defined intuitively, without the user having to have detailed knowledge of the CRM data model)

• Project workbench (enabling easy management of CRM extensions)

• Predefined business objects and extension scenarios

• Automatic generation of all SAP-internal objects (screen programs, customer exits, tables) without modification, and ready for transport

• Extensive knowledge of the mySAP CRMError! Bookmark not defined. internal data modelError! Bookmark not defined. is not required

As of SAP CRM 4.0, EEW includes the following functionality:


Object Functionality

Business Partner Adding fields or new tables is possible. The fields are visible in the People-Centric-UI and in SAP GUI. Additional features are available:

• CRM MW Message BDoc is extended

• The Synchronization BDoc (Mobile BDoc) is extended, including Mobile Bridge mapping. (Support Package functionality)

• SAP BW data source is extended

Business Transaction

Business Transaction Item

Activity

Opportunity

Lead

Transaction Item – Product

Transaction Item – Financing Product

Business Transaction – Sales Set

Business Transaction – Shipping Set

Business Transaction – Billing Set

Organizational Unit Set

Business Transaction Pricing Parameter Set

Transaction Item – Price

Business Transaction Item – Schedule Line

Transaction Item – Service

Transaction – Additional Extension

Transaction Item – Additional Extension

Adding fields to the objects listed on the left side. The fields are visible in People-Centric-UI and in SAP GUI. Additional features are available:

• CRM MW Message BDoc is extended

• The Synchronization BDoc (Mobile BDoc) is extended, including Mobile Bridge mapping.

• R/3 Adapter is extended

• For sales transactions the R/3 tables are extended

• SAP BW data source is extended

SDB – Symptom Generating a customizing include

SDB – Solution Generating a customizing include

Marketing Element: Basic Data Generating a customizingError! Bookmark not defined. include

Marketing Element: Execution Generating a customizingError! Bookmark not defined. include

Installed Base (Header) Generating a customizingError! Bookmark not defined. include

Installed Base Component – Addition/Specialization

Generating a customizingError! Bookmark not defined. include

Instructions for using EEW are given in the online help.

Using EEW has the following advantages: • No actions are necessary in the DDIC, a wizard guides you through the extension

process.


• The tool contains information on all existing CIs.

In SAP CRM 3.1, EEW only generates the CI and its data elements and domains.

6.1.4.1 Database Integrity

As described above, every CI is part of a database table that stores the contents of the new fields. Therefore some changes to the CI are critical for the database:

• Deleting fields

• Changing type or length of a field

Some databases do not support these operations directly, but need adjustment of the database structure. This adjustment can be made using the Database Utility of DDIC. For details of this process, see the relevant documentationError! Bookmark not defined.

Both DDIC and EEW provide information if database adjustment is necessary after changing a CI.

Important: Take care that you have the necessary authorization for database adjustments. Your authorization should contain activity “42” of object type “TABL”.

6.2 Customizing

6.2.1 Customizing at Portal Level

The portal administrator has the following customizing options at portal level:

• Setting up new portal pages with a set of iViews or modifying them: The portal administrator can modifyError! Bookmark not defined. the layout of the pages and can also permit or prevent modification of the layout and iViews on a page by users.

• Tailoring roles: The portalError! Bookmark not defined. administrator can define various roles to tailor content, accessible functions, and navigationError! Bookmark not defined. to specific user-group needs. The role definition includes:

- iViews, which are assigned to a portal page or a role

- A set of portal pages (including iViews) or external services (displayed as full pages)

- A hierarchy of worksets to structure the pages and external services

• Setting worksets: The portal administrator can set a workset as an entry point. This means that the users of these role see the workset as a first level navigation point. The underlying worksets correlate to the navigation structure of the role.

• Defining portal themes: The portal administrator can define and release themes that determine how the portal looks (a theme includes style sheets, images, and so on). By selecting one of the released themes, the individual user can tailor the look of his or her portal. It is important to know that the selected theme also affects the look of the CRM application. SAP EP provides an editor for the style sheets

Details on Customizing at portal level and Customizing options (because more and more features are added to SAP Enterprise Portal with every release) can be found in the SAP Enterprise Portal


documentation under help.sap.com → mySAP.com Cross-Industry Solutions → SAP Enterprise Portal →Administration, Developer and End User Documentation.

6.2.1.1 Portal Roles and Blueprint Table Views

A CRM transaction displayed in a portal page consists of several user interface components, such as toolbars, tabstrips, and fields, which are composed according to the basic user interface patterns. The user interface components can be adapted to different blueprint views, which are used to build roles in the portal. One blueprint view can be reused in several roles.

Role a Role b

Transaction 1 Transaction 2

View x View xView y View y

Figure 6.4: Portal Role and Blueprint View

An overview of all existing blueprint views (technical name: BLView) can be found in the F4 help in the report CRM_BSP_BLUEPRINT_XML_SERVICE. The list is also available in table CRMC_BL_VIEW (displayed in CRMC_BLUEPRINT or CRMC_BLUEPRINT_C under the entry point Views).

The following user interface components can be maintained with multiple views:

• Applications

• Field groups

• Tabstrip groups

• Viewswitch groups

• Toolbar groups

• Search groups The parameter BLVIEW is one of the key fields of the blueprint tables for these user interface components. Therefore all attributes of these components can be maintained view-dependently. To find the right blueprint entries in table CRMC_BLUEPRINT at runtime, the framework first selects the blueprint entries with BLVIEW and then without. If there exists an blueprint entry with called BLView, all screen positions below are only read with this value of BLView. For a detailed description of the components and their attributes, see section 4.3.2.


6.2.1.2 State Manager and List Manager

The PCUI Framework features a component called the State Manager which lets applications store the state of their user interface between sessions. The State Manager provides an enhanced sense of continuity as the user switches from one application to another and then comes back to the previous application. It stores such attributes as the visual state of user interface elements, the list of objects displayed in the search result list, and so on. All list-related operations are accomplished by a component called the List Manager, which is also part of the PCUI Framework. Both the State Manager and the List Manager are completely transparent to applications and require no additional coding in the model access classes. They are called directly by the BSP controllers.

The State Manager and the List Manager operate based on specific customizing settings that can be accessed through the CRMV_BSP_SESMGTC maintenance view. This maintenance view is based on the CRMC_BSP_SESMGTC customizing table.

CRMC_BSP_SESMGTC

Field Data Element Data Type Length Short Text

MANDT MANDT CLNT 3 Client. [PK]

OBJECT_ID_IS_KEY FLAG CHAR 1 Internal

WINDOW_ID_IS_KEY FLAG CHAR 1 When ‘X’, uses the current browser window ID as part of the state’s key.

STATE_LIFE_HOURS INT4 INT4 10 State life span hours.

STATE_LIFE_DAYS INT4 INT4 10 State life span days.

LISTS_LIFE_HOURS INT4 INT4 10 List life span hours.

LISTS_LIFE_DAYS INT4 INT4 10 List life span days.

INTERAUDIT_HOURS INT4 INT4 10 Hours between each audit.

INTERAUDIT_DAYS INT4 INT4 10 Days between each audit.

NEXT_AUDIT_START Internal

BACKGROUND_SAVE Internal

The WINDOW_ID_IS_KEY attribute defines whether a different state will be stored for different browser windows.

The STATE_LIFE_HOURS, STATE_LIFE_DAYS, LISTS_LIFE_HOURS and LISTS_LIFE_DAYS attributes define the life span of states and lists in the database. In other words, they tell the PCUI Framework when a state or list is expired and should be rebuilt from scratch. The lifespan is the sum of the number of hours and the number of days. If the lifespan is zero, the states and lists will never be deleted.

The inter-audit hours and days combined show the minimum time between audits. Audits are tasks that scan the database for old states and old lists and delete them. If the inter-audit time is zero, audits are never made.

If for some reason a system administrator needs to delete a particular state or set of states, he or she can use the CRM_BSP_STATE_ERASE transaction. This transaction lets the administrator specify which states will be deleted based on a range of applications, blueprint views, user IDs and browser window IDs.


6.2.1.2.1 Applicative disabling

Applications generating non-Persistent Keys cannot be restored by this Framework. In order for those applications to inform the State Manager about such limitation, applications instantiate the new IF_CRM_BSP_PERSISTENCY_IL~IS_NON_PERSISTENT() interface, and return ABAP_TRUE. The State Manager only processes the ABAP_TRUE returned values.

For those “non-persistent” applications, the State Manager will not save, and therefore not restore, any previous session data.

6.2.1.2.2 Contextual disabling

Persistent applications may also require persistency to be disabled on some limited window launches. (Session restoration only occurs while launching new windows). One correct way for informing the State Manager about this requirement is via the following URL name & value pair:

crm_bsp_restore=false

When the State Manager encounters this negative parameter, it performs no restoration of the previous session’s attributes.

6.2.1.2.3 Attribute specific disabling

Persistency can also be disabled on a parameter basis, for those PCUI parameters that can be specified on the URL. For example, persistency will not override the “view_mode” when specified on the URL.

6.2.2 Customizing at Application Level

On top of the blueprint tables, the UI framework provides two visual tools for blueprint application building and customizing:

6.2.2.1 PCUI Customizing Tool

The new customizing tool presents a new approach to maintaining PC UI applications. It is divided in two main views accessible via buttons in the search and selection area: the application view and the application element view. On its turn, each view is divided in two panels: the left, navigation panel and the right, maintenance panel.

6.2.2.1.1 Application element tab

The application element tab lets the user maintain various PC UI application elements, -events, field groups, tab page groups, etc – no matter what specific application they belong to, if any at all. On this tab, a user can create components that he will later on integrate into application on the Application tab.


6.2.2.1.2 Application tab

The application view presents a view to a specific application and its components. The application view is made up by the search and selection area, the navigation panel and the maintenance panel. The navigation panel gives the user two perspectives on the application: a view on the application static model and a view on the application dynamic model.

Navigation Panel Maintenance Panel


The application view presents a view to a specific application and its components. The application view is made up by the search and selection area, the navigation panel and the maintenance panel. The navigation panel gives the user two perspectives on the application: a view on the application static model and a view on the application dynamic model. A good understanding of the concept and usage of those two models is necessary to efficiently use the tool.

The static model presents the application in a structure corresponding to the screen positions that will appear on the screen: the Search Area, Search Result, Detail Area, etc. Each screen position node can be expanded to reveal the components, field groups, tab page groups and others that will be displayed at runtime. It is important to notice that the static model presents a superset of the application components and not a runtime behavior. This means that, depending on the application logic and customizing, some screen positions or their components will be or not displayed at certain times and not at the others. The static model should be used to maintain application static components and their attributes.

The dynamic model gives a view on what impact each event has on different screen positions. This model is called dynamic since one can customize the desired runtime behavior using this screen. This model can be compared to the node “Application Layout” from the old blueprint customizing transaction. Even though the dynamic model gives a view on the static components that are affected by a given event, it doesn’t let the user modify those components. For this purpose the static model should be used.

6.2.2.1.3 Features of the tool

The new customizing tool offers the possibility to maintain applications and their components either using a context sensitive menu, accessible by right-clicking on nodes in the navigation panel or

Search & selection Area

Static Model

Dynamic Model

Maintenance Area


using the right-hand maintenance panel to change the selected object. Whenever it makes sense, right-clicking on a node gives possibilities such as adding a new element or leaf to the node (e.g. Add a field or a reference group to a field group, add an event to a toolbar, etc.). For leaves in the navigation tree, right-click gives features like removing the object from its container. It is important to keep in mind that deleting an object from its container doesn’t delete it from the pool of reusable objects. For both leaves and nodes, the user can change the text label that appears on the screen at runtime. However, text renaming functionality is possible only in individual application views; it cannot be maintained on application-only level to affect all dependent application views.

The maintenance panel can be used to maintain the content of containers like field groups, toolbar groups, event groups and so in a table like view or to maintain attributes of individual components.

The Search & selection area of the Application tab offers the possibility to create application views via copy. This is a very useful feature since typical users want to build their application views based on existing views.

6.2.2.1.4 Typical usage of the new customizing tool

Because of its limitations (see next chapter), the customizing tool is well suited for modifying existing applications and application components rather than creating new applications from scratch.

The typical scenario can be described as follow: 1. Locate in the Search & Selection area the application you want to maintain. 2. Choose the view you want to edit. 3. If necessary, copy the selected view to a new view 4. Expand the version node that you would like to maintain. 5. If you want to change application components, drill from the static model down to the

application component you want to modify. a. Either right-click or double click on the component you want to maintain and

perform the desired change. b. Repeat step 5 until you have completed all the desired changes

6. If you want to change the runtime behavior of your application, open the “Dynamic Model” node and either double-click on the node “Driving Events” to have in the right-hand panel a table containing all the events and their influence or drill down to the screen variant leaf and double-click to edit.

7. After finishing your changes, save.

6.2.2.1.5 Limitations of the new customizing tool

The new customizing tool does not replace all IMG activities that were used in previous releases or that were added in the current release. Following is a list of maintenance activities that are not covered by the new customizing tool.

Search Group

Define Search Criteria Selection

Define Search Variant Selection

Define Data Source Shuffler

Define Search Scenario

Viewset Group

Viewset Group

Process

Process Attributes


Application Set

Toolbar (Add/Delete/Modify)

Tabstrip (Add/Delete/Modify)

Search Scenario (Add/Delete/Modify)

Model Access (Add/Delete/Modify)

Navigation for Log messages

Message Group (Add/Delete/Modify)

Navigation (Add/Delete/Modify)

Navigation (URL Generation)

Object Type for Navigation

Method for Navigation

Method for Object Type

Assign Object Method to Role

Check Consistency of Object Links

Perform Role Check for Object Links

Use Role Copier for Object Links

Assign Portal Role to Single Role

F4 Help

Field Assignment for Transferring Values

Field Assignment for Search Preassignment

Field Assignment for Copying during MultiSelection

Characteristics of Version

Characteristics of View

Consistency Check

Copy Report Delivery Queries

Application Set

6.2.2.1.6 Free Field Assignment

The PCUI Customizing Tool includes a feature that makes it possible to move a field from one tab to another through customizing. The move will only apply to the context of a single application, version and blueprint view. With this feature an administrator could, for example, merge two tabs together in a single application. This feature is completely transparent to model access classes, so no additional coding is required. However, it should be used sparingly since it may have a slight negative impact on the performance of the affected application.

Note: The free field assignment feature can only be used by users who are authorized to make DDIC changes and customizing changes. Also, cross-client customizing and DDIC changes must be enabled on the affected client.


In order to move a field in the PCUI Customizing Tool, the user simply needs to drag that field from one field group to another in the tree on the left. If the move is not possible, an error will be displayed that explains why the move couldn’t be completed. For instance, an error will be displayed if the user tries to move a field across field groups that do not belong to the same application.

When a field is moved from one field group to another, two things can happen.

1. If the destination field group already contains moved fields, the new field is simply added to the field group.

2. If the destination field group does not already contain moved fields, it is automatically copied into a new field group and the moved field is added to that new field group. All references to the old field group are replaced with references to the new one for the current application, blueprint view and version. This prevents modifying field groups that are used by many applications.

Fields can freely be moved to or from field groups that already contained moved fields. After the move is completed, a message will tell the user which field group the field was added to. The user will then need to regenerate the layout for that field group before the affected application can be used. If the move is unsuccessful, a message will be displayed that tells the user why the move could not be completed.

Note: If the user does not regenerate a field group’s layout after moving fields to that field group, the affected application will not run.

If the user wishes to undo all field assignments for a particular field group, he or she can simply right-click on that field group in the tree on the left and choose the “Unmove all fields” command. The field group will be restored to its original state, without any moved fields.

Error Message Explanation

Some moved fields already exist in the destination screen structure.

The field being moved already exists in the screen structure of the destination field group.

The customizing transport failed because a customizing request could not be obtained.

The customizing request to which customizing entries will be associated could not be created. Verify the user’s permissions and the client settings.

The customizing transport failed because an object could not be added to the request.

Customizing entries could not be added to the specified request. Verify the customizing request and the user’s permissions.

The customizing transport failed because the object check failed.

An object could not be added to the customizing request. Verfiy the user’s permissions and the client settings.

The Data Dictionary transport failed because a package could not be obtained.

The user specified an invalid package for the DDIC changes. Verify that the specified package exists and is valid.

The Data Dictionary transport failed because a workbench request could not be obtained.

The workbench request to which the DDIC changes will be associated could not be created. Verify the user’s permissions and the client settings.

The destination field group was overridden through previous customizing.

The destination field group was replaced with a new one that contains moved fields. Further field assignments should be made to the replacement field group, not to the original one.

The destination reference group is not a screen group.

When fields are moved to a reference group instead of a top-level field group, that reference group must be of the ‘SCGR’ (screen group) type.

The fields cannot be moved because some of the fields are reference groups.

Reference groups cannot be moved to other field groups. Only individual fields can be moved.


Error Message Explanation

The fields cannot be moved because the destination field group contains screen groups.

Field groups that contain screen groups cannot contain individual fields.

The grouped screen structure could not be activated in the Data Dictionary.

The automatically generated screen structure could not be activated. Verify the user’s permissions and the client settings.

The grouped screen structure could not be created in the Data Dictionary.

The automatically generated screen structure could not be created. Verify the user’s permissions and the client settings.

The source and destination field groups must belong to the same application, blueprint view and version.

A field can only be moved within the context of a single application, in order to ensure that the corresponding model access class will always be properly initialized when the field is used.

6.2.2.2 Text Replacement Tool

People Centric CRM is delivered for a wide variety of customers and industries. These specific customers and industries often use terminology that is very particular although an underlying process or functionality may be common across multiple industries. In order to provide a more complete industry scenario, it has been made possible to selectively translate certain labels. This can be achieved without having to create industry specific DDIC elements.

Currently, field label texts within People Centric CRM are defined at data dictionary level. Therefore a combination of the DDIC structure used and the language of the user determine the text displayed on the screen. This is restrictive when industry specific or customer specific terms need to be shown and when the same DDIC structure is used in various situations. For example, while they are based on the same business process and data structure, employee management and contact management applications use different terminology to designate the same concept of business partner: in one case the business partner will be called “employee” and in the other case a business partner is referred to as a “contact”.

Moreover, while the Text Replacement Tool can be used by some customers, others who are doing business in different industries on one single CRM installation can not use this tool, as the replacement affects all the applications that share the data structure. Therefore another method is required to allow for multiple languages and industry specific terms to co-exist within one system.

To remedy to this situation, we can define one central repository of customized, industry-relevant texts that can be reused to redefine text labels. These texts can then to be used via customizing to replace tab names, application titles, button names in the relevant application for given industry views.

Another advantage of using this central text repository is that other portal applications can use it to make their own text elements and labels compliant to industry terminology. The definition of texts to be used for label redefinition can be done in the appropriate customizing view that can be accessed from IMG activity Application Element -> Rename Interface Texts -> Define Interface Texts. Application names can be customized to match industry terminology in IMG activity Application Element -> Rename Interface Texts -> Rename Application. Field labels can be renamed in IMG activity Application Element -> Rename Interface Texts -> Rename Field Label. Tabs, buttons, toolbar groups and screen groups can be renamed in IMG activity Application Element -> Rename Interface Texts -> Rename Other Interface Texts.


6.3 Personalization

In general, personalization permits the individual user to customize the solution according to his or her own specific requirements and authorizations.

Personalization can take place at portal level and at CRM level. For more information on personalization, see the Getting Started with mySAP CRM section in the help portal

6.3.1 Personalization at Portal Level

mySAP CRMError! Bookmark not defined. is a portalbased, people-centric solution. Using the personalization features of SAP EP, each user can define the following settings for his or her individual working environment (as far as permitted for the particular role of the user):

• Type of content and information to be provided on screen

• Format of information

• Page layout

• Style of the portal (for example the company branding with various font sizes)

Portal administrators can prepare personalization by releasing themes and roles within specific portal settings. End users can select a released theme or apply for a released role and thus tailor their individual working environment. The portal administrator is able to lock personalization for an individual role. Therefore, for example, a user cannot change the layout of a page or iView if personalization is locked.

In addition, the portal data viewer (PDV) provides easy-to-use personalization features for the presentation of lists.

For more details on personalization of the portal, see help.sap.com → mySAP.com Cross-Industry Solutions → Administration, Developer and End User Documentation.

Figure 6.5: Personalizing the Page Layout


6.3.2 Personalization at CRM Level

In the first step, UI personalization at CRM level focuses on the presentation of lists. From the functional and user interaction point of view, CRM list personalization follows the same approach as the PDV from SAP EP. The following light-weight functions are available in the first step:

• Hiding and unhiding fields (columns)

• Reordering columns

• Resetting column sequence to a default sequence

Additionally, you have two further options which also belong to the particular list:

• Display Filter Line During Firts Call (see section 2.2.3.1.3)

• Adjust Column Width to Text Length (see section 4.3.2.3.2)

Figure 6.6: List Customizing in Blueprint Applications

6.3.3 Personalization at Application Level

To ease the search for all end users and enhance their user experience, commonly used search scenarios in each application can be predefined and made accessible to all users. These predefined queries can then be accessed and run by all users with a given role, which lets them run common search scenarios without entering every time the search criteria. Examples of predefined queries: “My last week activities”, “My team tasks”, “My contacts”, etc.

To create predefined queries, one has to copy personal queries (a.k.a. variants) that were created for/by a specific user to application wide queries. Individual queries can be created in the application search area and saved in the system either to be used by their owner or to serve as basis for the creation of predefined queries. The copy from personal queries to application predefined queries can be performed via IMG activity Search Queries -> Define Standard Queries. Old, unused queries can be deleted via IMG activity Search Queries -> Delete Search Queries.


6.4 Conclusion

It is a mandatory task of SAP’s people-centric strategy to support options for the adaptation of the UI to the users’ needs. The use of portal roles, role-dependent customized views, extensions, and of course personalization, leads to an individually-suited working environment for each user.


APPENDIX

Table of Contents

Example Application .................................................................................................................... 221 Example 1: Simple Screen with OIP (view)................................................................................ 221 Example 2: Simple Screen with Model Access (Model) ........................................................... 225 Example 3: Search Area with Search Group (View).................................................................. 228 Example 4: Standard Screen with Search Area, Result List, and ODP 1 (View).................... 230 Example 5: User Interaction Within Standard Screen (Model) ................................................ 231 Example 6: Search Result with Toolbar (View) ......................................................................... 235 Example 7: Result List with Simple Toolbar Interaction (Model) ............................................ 236 Example 8: Search Result with Toolbar Interaction (Model) ................................................... 237 Example 9: Result List with Tree (M/V) ...................................................................................... 239 Example 10: ODP with Multiple Tabs (View).............................................................................. 248 Example 11: ODP 1 with Multiple Tabs (Model) ........................................................................ 251 Example 12: ODP 1 with Toolbar (View) .................................................................................... 259 Example 13: ODP 1 with Toolbar (Model) .................................................................................. 260 Example 14: Screen with ODP 1 and ODP 2 (View) .................................................................. 261 Example 15: Screen with ODP 1 and ODP 2 (Model) ................................................................ 262 Example 16: ODP with Tree (Model / View)................................................................................ 264 Example 17: Dialogs via Popin and Popup (View / Model) ...................................................... 265 Example 18: Screen Variants Within ODP ................................................................................. 267 Example 19: Advanced F4 Help .................................................................................................. 272 Example 20: Favorites ................................................................................................................. 276 Example 21: Documentation ....................................................................................................... 278 Example 22: Event Groups.......................................................................................................... 279 Example 23: Viewswitch Groups ................................................................................................ 280


Example Application As it is useful to enhance theoretical concepts by practical exercises, the following sections describe an example application. The example introduces the declarative method of UI development within mySAP CRM. Step by step it is described how to maintain blueprint tables, provide DDIC entries, and implement model access class methods. Screenshots and example coding make it easy to create “my first blueprint application”.

The example application starts with a simple screen, with a search area and a result list. Data of flights as used in travel agencies is displayed on the screen. This example data is stored in tables delivered with mySAP CRM. The simple example from the beginning is then enhanced step-by-step with further UI functionality.

The step-by-step description as well as the example coding has been developed by Horst Schaude, SAP AG. The examples are also delivered within SAP CRM 4.0, but they have a different naming: instead of TMP_* the term PCF_* is used. So, for example, the model access classes begin with CL_PCF_*. Within SAP CRM 4.0 the examples can be found in SE80 in Package CRM_BSP_FRAME_SAMPLE.

Example 1: Simple Screen with Object Identification Pattern (view)

Some fields of the table SFLIGHTS2 are used to create a simple application with OIP. In the first step, no data selection is implemented, it is just a view.

1. Create DDICError! Bookmark not defined. structures: TMP_EXAMPLE_SEARCH and TMP_EXAMPLE_RESULT. Be aware of the fact that the screen structure for the result list must have a field OBJECT_KEY of type CRMT_BSP_OBJECTKEY.


2. Create model access class TCL_MDM_EXAMPLE1 and assign interface IF_CRM_BSP_MODEL_ACCESS_IL. Create the methods QUERY and READ (can be empty), otherwise you will get a dump if you hit the GO button.

3. Create application set TMP_EXAMPLE1 with screen structureError! Bookmark not defined.s TMP_EXAMPLE_SEARCH and TMP_EXAMPLE_RESULT, which are handled by model access class TCL_MDM_EXAMPLE1.

4. Create the following field groups:

- TMP_AIRPORT_FROM, which contains the fields airport, city and country from

where the flight originates. The fields for the airports are not shown in the list display.

- TMP_AIRPORT_FROM_SREQ which contains the same fields but as input fields


- TMP_AIRPORT_TO contains the fields airport, city, and country to which the flight

goes. The fields for the airports are not shown in the list display.

- TMP_AIRPORT_TO_SREQ contains the same fields but as input fields

- TMP_AIRPORT combines the fields above as reference groups: the group TMP_AIRPORT_FROM as an include, the group TMP_AIRPORT_TO as a logical group and similar for the *_SREQ groups

- TMP_AIRPORT_SREQ the same fields but as input fields

- TMP_CARRIER the carrier for this flight as a text field

- TMP_CARRIER_SREQ the same fields but as input fields

- TMP_DATES some times (flight time, departure, arrival time). Only flight time is shown in list display.

- TMP_DIST the distance of the flight. No fields are shown in list display.

- TMP_COST the airfare in the local currency. No fields are shown in list display.

- TMP_COST_MELT combines the TMP_COST fields as a reference group

with field melting: the value and currency are displayed in one column.


- TMP_EXAMPLE1_SREQ includes as screen groups the TMP_CARRIER_SREQ and TMP_AIRPORT_SREQ. The fields from these groups are available as search parameters.

- TMP_EXAMPLE1_SRES includes TMP_CARRIER, TMP_AIRPORT,

TMP_DATES, TMP_DIST and TMP_COST_MELT. Some fields are not shown in list display (see above), but all are displayed in the form view.

5. Assign the application TMP_EXAMPLE1 to the application set TMP_EXAMPLE1. The

application displays for the event INIT the field groups TMP_EXAMPLE1_SREQ and TMP_EXAMPLE1_SRES in the search area and in the result list.


6. Create the layout and test the consistency.

7. You can now call the application TMP_EXAMPLE1: It will show only the search area and the result list. The first one can be expanded to the “Advanced Search” area, the result list can also be displayed in a form view.

Example 2: Simple Screen with Model Access (Model)

Now example 1 is enhanced by the query functionality. The application reads data from the database and displays it in the result list.

Create class TCL_MDM_EXAMPLE2 and assign interface IF_CRM_BSP_MODEL_ACCESS_IL.

1. Copy the field groups TMP_EXAMPLE1_SRES and TMP_EXAMPLE1_SREQ to TMP_EXAMPLE2_*.

2. Copy the application and the application set from the first example to TMP_EXAMPLE2. For the application set change the model access class to TCL_MDM_EXAMPLE2. For the application adjust the field groups.

3. The field group TMP_MISC is added to the field group TMP_EXAMPLE2_SRES. It contains fields for the plane type, the summed up air fare and the seats. The later two fields are only shown in the form view.

4. Create the methods QUERY and READ for reading the data from the database. In the QUERY method the data is read into a global table and the object keys (in this case new generated GUIDs) are the result of this method. Now the READ method is called with the complete list of object keys. The complete data is returned. At last the READ method is called with one object key and the lock flag set. This object should now be enqueued. In this example we assume all flights for the carrier Singapore Airlines (last entry) are already locked and will therefore be only shown in display mode.

method if_crm_bsp_model_access_il~query. data: ls_search type tmp_example_search, ls_data like line of me->gt_data, lt_data like me->gt_data, ls_object_key type crmt_bsp_objectkey, lt_object_key type crmt_bsp_objectkey_tab, lt_carrid type range of s_carr_id, ls_carrid like line of lt_carrid, lt_airpfrom type range of s_fromairp, ls_airpfrom like line of lt_airpfrom, lt_cityfrom type range of s_from_cit, ls_cityfrom like line of lt_cityfrom, lt_countryfr type range of land1, ls_countryfr like line of lt_countryfr, lt_airpto type range of s_toairp, ls_airpto like line of lt_airpto, lt_cityto type range of s_to_city,


ls_cityto like line of lt_cityto, lt_countryto type range of land1, ls_countryto like line of lt_countryfr, lv_guid type guid_32. field-symbols <fs_data> type tmp_example_result. * this query method is only programmed for this screen structure check iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH'. * move from generic structure to own structure move is_screen_structure to ls_search. * refresh class variable refresh me->gt_data. * no selection criteria => gime all! if ls_search is initial. select * from sflights2 into corresponding fields of table me->gt_data. * selection by search criteria else. macro_define_range: ls_carrid lt_carrid ls_search-carrid, ls_airpfrom lt_airpfrom ls_search-airpfrom, ls_cityfrom lt_cityfrom ls_search-cityfrom, ls_countryfr lt_countryfr ls_search-countryfr, ls_airpto lt_airpto ls_search-airpto, ls_cityto lt_cityto ls_search-cityto, ls_countryto lt_countryto ls_search-countryto. select * from sflights2 into corresponding fields of table me->gt_data where carrid in lt_carrid and airpfrom in lt_airpfrom and cityfrom in lt_cityfrom and countryfr in lt_countryfr and airpto in lt_airpto and cityto in lt_cityto and countryto in lt_countryto. endif. * define object keys loop at me->gt_data assigning <fs_data>. * <fs_data>-object_key = sy-tabix. call function 'GUID_CREATE' importing ev_guid_32 = lv_guid. <fs_data>-object_key = lv_guid. endloop. refresh et_object_key. loop at me->gt_data into ls_data. append ls_data-object_key to et_object_key. endloop. * if nothing found => raise message * IF et_object_key[] IS INITIAL. * MESSAGE s001(tmp_example) WITH 0. * CALL METHOD me->set_status_message. * ENDIF. endmethod.

METHOD IF_CRM_BSP_MODEL_ACCESS_IL~READ. * depending on the calling screen structure CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_RESULT'.


CALL METHOD me->read_result EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. ENDCASE. APPEND me->gc_init_class TO et_class_name. ENDMETHOD.

METHOD read_result. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_data INTO me->gs_data WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_data-carrid = 'SQ'. lv_display = 'X'. ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_data-object_key. APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

5. The READ method also returns the class for the IF_CRM_BSP_INIT_IL interface. The method INITIALIZE dequeues the locks and refreshes the variables set by the READ method.

method if_crm_bsp_init_il~initialize. * dequeue any locks and refresh all variables set by the READ method clear me->gs_data. endmethod.


6. Because some data can be changed in the result list, the framework will call the MODIFY method to allow the application the update of the internal data. That means you need to have an possible empty MODIFY method.

Example 3: Search Area with Search Group (View)

This example shows how to use the shuffler to group some fields for a specific search request.

1. Copy class TCL_MDM_EXAMPLE2 to TCL_MDM_EXAMPLE3. Correct the constant GC_INIT_CLASS.

2. Copy the field groups of example 2 to TMP_EXAMPLE3_SRES and TMP_EXAMPLE3_SREQ.

3. Copy the application and the application set from example TMP_EXAMPLE2 to TMP_EXAMPLE3. For the application set change the model access class to TCL_MDM_EXAMPLE3. For the application adjust the field group to TMP_EXAMPLE3_*.

4. Define the events TMP_EXAMPLE_AIRPFR, TMP_EXAMPLE_AIRPTO and TMP_EXAMPLE_CARRIER.

5. Create the Show-Shuffler

MDM_ALL for all search fields TMP_AIRP for the airports TMP_CARR for the carrier

6. Create the By-Shuffler

MDM_ALL for all search field of a show shuffler TMP_FROM for the departing airport TMP_TO for the arriving airport


7. Create the search scenario TMP_EXP and group the show- and by-shuffler to have a useful combination. Assign those combinations the above defined events. Assign this search scenario to the application set.

8. Add this search scenario to the application for event INIT and the field group

TMP_EXAMPLE3_SERQ of the search area.

9. Define in the application which field group is to be displayed when each of the above

events is raised in such a way that the right field is shown in the search area that maps to the chosen shufflers:

To specialize the search, you are now able in the expanded search area to select either

- All fields or

- All fields for the carrier (the carrier itself) or

- The departing airport/city/country or

- The arriving airport/city/country

The user can add such a search with Add to show to the list of her or his predefined queries in the Show DDLB.


Example 4: Standard Screen with OIP and ODP1 (View)

In this step the example is enhanced by a ODP.

1. Create DDIC structures TMP_EXAMPLE_ODC1_MAIN and TMP_EXAMPLE_ODC1_DET.

2. Copy the class TCL_MDM_EXAMPLE3 to TCL_MDM_EXAMPLE4. Correct the constant

GC_INIT_CLASS.

3. Copy the field groups from example 3 to TMP_EXAMPLE4_SRES and TMP_EXAMPLE4_SREQ.

4. Copy the field group TMP_EXAMPLE3_SERS to field group TMP_EXAMPLE4_ODC1_MAIN and remove the entries with position 30 to 60. The structure name for the field group is TMP_EXAMPLE_ODC1_MAIN.

5. Copy the field group TMP_EXAMPLE3_SERS to field group TMP_EXAMPLE4_ODC1_DET and remove the entries with position 10 to 20. The structure name for the field group is TMP_EXAMPLE_ODC1_DET.

6. Define the events TMP_EXAMPLE_MAIN and TMP_EXAMPLE_DETAIL.

7. Create a tab group TMP_EXP4 with the two tab pages for the events TMP_EXAMPLE_MAIN and TMP_EXAMPLE_DETAIL and assign it to the application set.


8. Copy the application and the application set from example TMP_EXAMPLE3 to

TMP_EXAMPLE4. For the application set change the model access class to TCL_MDM_EXAMPLE4 and create a new entry for the structures TMP_EXAMPLE_ODC1_MAIN and TMP_EXAMPLE_ODC1_DET with the model access class TCL_MDM_EXAMPLE4.

9. For the application adjust the field groups to TMP_EXAMPLE4_* and create three new

entries:

10. Now two tabs are shown: one for the main data with all fields read-only and one for the details, which is input-enabled. Remember to have the INIT event assigned for the first call. The event of the tab page is necessary for coming back (for example, hitting the tabstrip itself).

Example 5: User Interaction Within Standard Screen (Model)

We will now enlarge example 4 with some methods to supply the fields with data and react on user input.

1. Copy the class TCL_MDM_EXAMPLE4 to TCL_MDM_EXAMPLE5. Correct the constant GC_INIT_CLASS.

2. Copy the application and the application set from example TMP_EXAMPLE4 to TMP_EXAMPLE5.


For the application set change the model access class to TCL_MDM_EXAMPLE5 but keep the field groups as referencing to example 4.

3. Enlarge the method READ with a WHEN branch for the screen structure TMP_EXAMPLE_ODC1_MAIN.

METHOD IF_CRM_BSP_MODEL_ACCESS_IL~READ. * depending on the calling screen structure CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_RESULT'. CALL METHOD me->read_result *(… as before …) WHEN 'TMP_EXAMPLE_ODC1_MAIN'. CALL METHOD me->read_main EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_ODC1_DET'. CALL METHOD me->read_det EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. ENDCASE. APPEND me->gc_init_class TO et_class_name. ENDMETHOD.

METHOD read_result …as before…)

METHOD read_main. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result TYPE tmp_example_odc1_main. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * it will be always only one entry in the IT_OBJECT_KEY, because * this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING ls_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data has to be maintained ENDIF.


* modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

METHOD read_det. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result TYPE tmp_example_odc1_det. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * it will be always only one entry in the IT_OBJECT_KEY, because * this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING ls_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data has to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

4. Assign the interface IF_CRM_BSP_PROCESS_IL to the class TCL_MDM_EXAMPLE5.

5. Implement the method MODIFY to handle the changes made by the user. method IF_CRM_BSP_MODEL_ACCESS_IL~MODIFY. CASE iv_screen_structure_name. * Changes in the result list WHEN 'TMP_EXAMPLE_RESULT'. CALL METHOD me->modify_result EXPORTING iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field


iv_parent_object_key = iv_parent_object_key IMPORTING et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. * Changes in the detail tab of the ODP 1 (the main tab as only text fields) WHEN 'TMP_EXAMPLE_ODC1_DET'. CALL METHOD me->modify_det EXPORTING iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key IMPORTING et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. ENDCASE. APPEND me->gc_init_class TO et_class_name. endmethod.

method MODIFY_RESULT. TYPES: tt_tmp_example_result TYPE STANDARD TABLE OF tmp_example_result. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_result, <fs_old_data> TYPE tmp_example_result, <fs_new_data> TYPE tmp_example_result, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>. * read actual data set from global internal table READ TABLE gt_data WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. <fs_old> = <fs_new>. ENDLOOP. * update global data set gs_data = <fs_old_data>. endmethod.

METHOD modify_det. TYPES: tt_tmp_example_odc1_det TYPE STANDARD TABLE OF tmp_example_odc1_det. FIELD-SYMBOLS:


<ft_data> TYPE tt_tmp_example_odc1_det, <fs_old_data> TYPE tmp_example_result, <fs_new_data> TYPE tmp_example_odc1_det, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>. * read actual data set from global internal table READ TABLE gt_data WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. IF NOT sy-subrc IS INITIAL. * this field is unknown in the changed structure: * should NEVER occur CONTINUE. ENDIF. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. * this field is unknown in the global internal table: * maybe it is stored somewhere else IF NOT sy-subrc IS INITIAL. CONTINUE. ENDIF. * assign new value <fs_old> = <fs_new>. ENDLOOP. * update global data set gs_data = <fs_old_data>. ENDMETHOD.

After the activation of this changes the data entered either in the result list or in the detail screen are read in by the method MODIFY and stored in the internal table. Consequently the changed data is shown after the next round-trip.

Example 6: Search Result with Toolbar (View)

We take example 5 and add a toolbar to the result list.


2. Create the event TMP_EXAMPLE_INACTIVE.

3. Create toolbar TMP_TB1 with those generic events: CREATE, SAVE, CHANGE, COPY, PRINT, DELETE and the example event TMP_EXAMPLE_INACTIVE.



TMP_EXAMPLE6. For the application set change the model access class to TCL_MDM_EXAMPLE6 but keep the field groups as referencing to example 4.

5. Assign the toolbar TMP_TB1 to the application set TMP_EXAMPLE6.

6. Assign the toolbar TMP_TB1 to the application TMP_EXAMPLE6, event INIT, screen position “Result List”.

The toolbar is mainly display. The generic events SAVE, CHANGE, PRINT, DELETE are inactive. The event CHANGE is hidden.

Example 7: Result List with Simple Toolbar Interaction (Model)

What happens if the button is pressed? This example processes a message for each button press.


2. Copy the application and the application set from example TMP_EXAMPLE6 to TMP_EXAMPLE7. For the application set change the model access class to TCL_MDM_EXAMPLE7 but keep the field groups as referencing to example 4.

3. Implement the methods PROCESS_EVENT, GET_MESSAGES, SET_STATUS_MESSAGE. METHOD if_crm_bsp_model_access_il~process_event. * the events "SAVE" and "DELETE" are handled in the DO_HANDLE_EVENT method of the subcontroller CASE iv_event. WHEN 'CREATE' or 'CHANGE' or 'COPY' or 'PRINT'. MESSAGE s001(00) WITH 'Button >' iv_event '< pressed'. CALL METHOD me->set_status_message.


ENDCASE. ENDMETHOD.

method IF_CRM_BSP_MODEL_ACCESS_IL~GET_MESSAGES. * add always status message DATA ls_msg_show TYPE crmt_bsp_applog. IF NOT gs_msg_show IS INITIAL. INSERT gs_msg_show INTO TABLE rt_applog. CLEAR gs_msg_show. ENDIF. endmethod.

method SET_STATUS_MESSAGE. DATA: ls_msg_show TYPE crmt_bsp_applog. IF is_msg_show IS INITIAL. ls_msg_show-msgty = sy-msgty. ls_msg_show-msgid = sy-msgid. ls_msg_show-msgno = sy-msgno. ls_msg_show-msgv1 = sy-msgv1. ls_msg_show-msgv2 = sy-msgv2. ls_msg_show-msgv3 = sy-msgv3. ls_msg_show-msgv4 = sy-msgv4. * ls_msg_show-object_name = . ELSE. ls_msg_show = is_msg_show. ENDIF. ls_msg_show-show_first = 'X'. gs_msg_show = ls_msg_show. endmethod.

Example 8: Search Result with Toolbar Interaction (Model)

The framework provides the basic functions for the SAVE and DELETE events. But there is a CHECK_BEFORE_SAVE and a CHECK_BEFORE_DELETE method which is implemented in this example. Furthermore the toolbar itself is influenced so that

• One button is always inactive

• A new button is introduced

This new button is not defined in the toolbarError! Bookmark not defined. group.



3. Implement the methods CHECK_BEFORE_SAVE, CHECK_BEFORE_DELETE. Both methods refuse the save and the deletion in this example via a message.

method if_crm_bsp_process_il~check_before_save. ev_return_code = 4. message s001(00) with 'SAVE not supported'. call method me->set_status_message.


endmethod.

method if_crm_bsp_model_access_il~check_before_delete. rv_reject = 'X'. message s001(00) with 'DELETE not supported'. call method me->set_status_message. endmethod.

4. You need also the methods AFTER_SAVE and AFTER_ROLLBACK to initialize the buffers.

5. Implement the method CHECK_ACTIVE_TOOLBAR to influence which button is active and even to introduce buttons dynamically.

METHOD if_crm_bsp_model_access_il~check_active_toolbar. DATA ls_button TYPE crmc_toolbargr. CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_RESULT'. IF gs_data IS INITIAL. DELETE ct_toolbar WHERE event = 'CREATE'. ENDIF. DELETE ct_toolbar WHERE event = 'TMP_EXAMPLE_INACTIVE'. READ TABLE ct_toolbar INTO ls_button WITH KEY event = 'SAVE'. IF sy-subrc IS INITIAL. ls_button-event = 'MDM_REFRESH'. ls_button-sequence = ls_button-sequence + 1. APPEND ls_button TO ct_toolbar. ENDIF. ENDCASE. ENDMETHOD.

6. To react on the event CREATE of the toolbar of the result list you need to adapt the MODIFY method.

method MODIFY_RESULT. TYPES: tt_tmp_example_result TYPE STANDARD TABLE OF tmp_example_result. DATA: ls_new_data TYPE tmp_example_result, lv_guid TYPE guid_32. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_result, <fs_old_data> TYPE tmp_example_result, <fs_new_data> TYPE tmp_example_result, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. *(…as before…) * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. <fs_old> = <fs_new>. ENDLOOP. * new object needs a key IF <fs_new_data>-object_key IS INITIAL. CALL FUNCTION 'GUID_CREATE' IMPORTING


ev_guid_32 = lv_guid. <fs_old_data>-object_key = lv_guid. APPEND <fs_old_data>-object_key TO et_new_object_key. ENDIF. * update global data set gs_data = <fs_old_data>. endmethod.

Example 9: Result List with Tree (M/V)

There is a possibility to show a hierarchical list (tree) in the result list. For this tree you had to include the DDIC structure CRMT_BSP_TREE_INCL into the result structure, implement the interface IF_CRM_BSP_TREETABLE_IL and make some definitions in the blueprints.

1. Create the DDIC structure TMP_EXAMPLE_RESULT_TREE with the obligatory OBJECT_KEY entry and an include for the structure CRMT_BSP_TREE_INCL. Include some fields from the tables SPFLI, SFLIGHT, SBOOK.

2. Create also the DDIC structures TMP_EXAMPLE_SPFLI, TMP_EXAMPLE_FLIGHT and

TMP_EXAMPLE_BOOK with the OBJECT_KEY field.



GC_INIT_CLASS.

4. Re-implement methods QUERY, READ, and MODIFY. method if_crm_bsp_model_access_il~query. data: ls_search type tmp_example_search, ls_hier like line of me->gt_hier, ls_conn like line of me->gt_conn, lt_conn like me->gt_conn, ls_object_key type crmt_bsp_objectkey, lt_object_key type crmt_bsp_objectkey_tab, lt_carrid type range of s_carr_id, ls_carrid like line of lt_carrid, lt_airpfrom type range of s_fromairp, ls_airpfrom like line of lt_airpfrom, lt_cityfrom type range of s_from_cit, ls_cityfrom like line of lt_cityfrom, lt_countryfr type range of land1, ls_countryfr like line of lt_countryfr, lt_airpto type range of s_toairp, ls_airpto like line of lt_airpto, lt_cityto type range of s_to_city, ls_cityto like line of lt_cityto, lt_countryto type range of land1, ls_countryto like line of lt_countryfr, lv_guid type guid_32.


* this query method is only programmed for this screen structure check iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH'. * move from generic structure to own structure move is_screen_structure to ls_search. * refresh class variable * REFRESH me->gt_data. * no selection criteria => get all! if ls_search is initial. select * from spfli into corresponding fields of table me->gt_conn. * selection by search criteria else. macro_define_range: ls_carrid lt_carrid ls_search-carrid, ls_airpfrom lt_airpfrom ls_search-airpfrom, ls_cityfrom lt_cityfrom ls_search-cityfrom, ls_countryfr lt_countryfr ls_search-countryfr, ls_airpto lt_airpto ls_search-airpto, ls_cityto lt_cityto ls_search-cityto, ls_countryto lt_countryto ls_search-countryto. select * from spfli into corresponding fields of table me->gt_conn where carrid in lt_carrid and airpfrom in lt_airpfrom and cityfrom in lt_cityfrom and countryfr in lt_countryfr and airpto in lt_airpto and cityto in lt_cityto and countryto in lt_countryto. endif. * read data and build up hierarchy table call method me->buildup_hierarchy. refresh et_object_key. loop at me->gt_hier into ls_hier where parent_key = space. append ls_hier-object_key to et_object_key. endloop. * if nothing found => raise message if et_object_key[] is initial. message s001(tmp_example) with 0. call method me->set_status_message. endif. endmethod.

method buildup_hierarchy. data: ls_conn like line of gt_conn, ls_flight like line of gt_flight, ls_book like line of gt_book, ls_hier like line of gt_hier, lv_guid type guid_32. field-symbols <fs_hier> like line of me->gt_hier. loop at me->gt_conn into ls_conn. macro_buildup_hierarchy ls_conn gt_conn ls_conn 'S'. * select the connections select * from sflight into corresponding fields of ls_flight where carrid = ls_conn-carrid


and connid = ls_conn-connid. macro_buildup_hierarchy ls_flight gt_flight ls_conn 'F'. * select the bookings select * from sbook into corresponding fields of ls_book where carrid = ls_flight-carrid and connid = ls_flight-connid and fldate = ls_flight-fldate. macro_buildup_hierarchy ls_book gt_book ls_flight 'B'. endselect. endselect. endloop. * define object keys and tree attributes loop at me->gt_hier assigning <fs_hier>. case <fs_hier>-type. when 'S'. <fs_hier>-icon = icon_flight. <fs_hier>-icon_expanded = icon_ws_plane. read table me->gt_flight transporting no fields with key carrid = <fs_hier>-carrid connid = <fs_hier>-connid. if sy-subrc is initial. <fs_hier>-is_leaf = space. else. <fs_hier>-is_leaf = 'X'. endif. concatenate <fs_hier>-carrid '/' <fs_hier>-connid into <fs_hier>-descr. when 'F'. <fs_hier>-icon = icon_date. <fs_hier>-icon_expanded = icon_final_date. read table me->gt_book transporting no fields with key carrid = <fs_hier>-carrid connid = <fs_hier>-connid fldate = <fs_hier>-fldate. if sy-subrc is initial. <fs_hier>-is_leaf = space. else. <fs_hier>-is_leaf = 'X'. endif. concatenate <fs_hier>-fldate ':' <fs_hier>-carrid '/' <fs_hier>-connid into <fs_hier>-descr. when 'B'. <fs_hier>-icon = icon_status_booked. <fs_hier>-icon_expanded = icon_status_booked. <fs_hier>-is_leaf = 'X'. concatenate <fs_hier>-bookid '(' <fs_hier>-fldate ':' <fs_hier>-carrid '/' <fs_hier>-connid ')' into <fs_hier>-descr. endcase. <fs_hier>-is_expanded = space. endloop. endmethod.


method if_crm_bsp_model_access_il~read. * depending on the calling screen structure case iv_screen_structure_name. when 'TMP_EXAMPLE_RESULT_TREE'. call method me->read_result_tree exporting iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name importing et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. when 'TMP_EXAMPLE_RESULT'. call method me->read_result exporting iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name importing et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. endcase. append me->gc_init_class to et_class_name. endmethod.

METHOD read_result_tree. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result_tree, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_hier INTO me->gs_hier WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_hier TO ls_result. APPEND ls_result TO et_screen_structure. ENDIF. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_hier-carrid = 'SQ'. lv_display = 'X'. ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_hier-object_key.


APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

METHOD read_result. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_hier INTO me->gs_hier WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_hier TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock objectError! Bookmark not defined. IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_hier-carrid = 'SQ'. lv_display = 'X'. ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_hier-object_key. APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

method if_crm_bsp_model_access_il~modify. case iv_screen_structure_name. * Changes in the tree result list when 'TMP_EXAMPLE_RESULT_TREE'. call method me->modify_result_tree exporting iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key importing et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. * Changes in the result list when 'TMP_EXAMPLE_RESULT'. call method me->modify_result


exporting iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key importing et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. endcase. append me->gc_init_class to et_class_name. endmethod.

method modify_result_tree. types: tt_tmp_example_result_tree type standard table of tmp_example_result_tree. data: ls_hier type tmp_example_result_tree, lv_guid type guid_32. field-symbols: <ft_data> type tt_tmp_example_result_tree, <fs_old_data> type tmp_example_result_tree, <fs_new_data> type tmp_example_result_tree, <fs_old> type any, <fs_new> type any, <fs_changes> type crmt_bsp_changedfield, <fs_name> type crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN assign it_screen_structure to <ft_data>. * read modified data set read table <ft_data> index 1 assigning <fs_new_data>. * new object? if <fs_new_data>-object_key is initial. append ls_hier to gt_hier. * create the internal identifier, e.g. GUID call function 'GUID_CREATE' importing ev_guid_32 = lv_guid. append lv_guid to et_new_object_key. endif. * read actual data set from global internal table read table gt_hier with key object_key = <fs_new_data>-object_key assigning <fs_old_data>. * read the changed values for this data set read table it_changed_field with key object_key = <fs_new_data>-object_key assigning <fs_changes>. * loop for all changed fields loop at <fs_changes>-field_name_tab assigning <fs_name>. assign component <fs_name> of structure <fs_new_data> to <fs_new>. assign component <fs_name> of structure <fs_old_data> to <fs_old>. <fs_old> = <fs_new>. endloop. * supply new GUID for create if <fs_old_data>-object_key is initial. <fs_old_data>-object_key = lv_guid. <fs_old_data>-parent_key = <fs_new_data>-parent_key. <fs_old_data>-is_leaf = <fs_new_data>-is_leaf.


endif. * actualise global data set gs_hier = <fs_old_data>. endmethod.

METHOD MODIFY_RESULT. TYPES: tt_tmp_example_result_tree TYPE STANDARD TABLE OF tmp_example_result_tree. DATA: ls_hier TYPE tmp_example_result_tree, lv_guid TYPE guid_32. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_result_tree, <fs_old_data> TYPE tmp_example_result_tree, <fs_new_data> TYPE tmp_example_result_tree, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>. * new object? IF <fs_new_data>-object_key IS INITIAL. APPEND ls_hier TO gt_hier. * create the internal identifier, e.g. GUID CALL FUNCTION 'GUID_CREATE' IMPORTING ev_guid_32 = lv_guid. APPEND lv_guid TO et_new_object_key. ENDIF. * read actual data set from global internal table READ TABLE gt_hier WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tabError! Bookmark not defined. ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. <fs_old> = <fs_new>. ENDLOOP. * supply new GUID for create IF <fs_old_data>-object_key IS INITIAL. <fs_old_data>-object_key = lv_guid. <fs_old_data>-parent_key = <fs_new_data>-parent_key. <fs_old_data>-is_leaf = <fs_new_data>-is_leaf. ENDIF. * actualise global data set gs_hier = <fs_old_data>. ENDMETHOD.

5. Implement methods READ_CHILDREN, READ_ROOT_DESCR.


method if_crm_bsp_treetable_il~read_children. data: ls_object_key type crmt_bsp_objectkey, ls_result type tmp_example_result_tree, lt_result type table of tmp_example_result_tree, ls_hier like line of gt_hier. case iv_screen_structure_name. when 'TMP_EXAMPLE_RESULT_TREE'. * only one node is marked read table it_object_key into ls_object_key index 1. loop at gt_hier into ls_hier where parent_key = ls_object_key. move-corresponding ls_hier to ls_result. append ls_result to lt_result. endloop. et_screen_structure = lt_result. endcase. endmethod.

method if_crm_bsp_treetable_il~read_root_descr. case iv_screen_structure_name. when 'TMP_EXAMPLE_RESULT_TREE'. ev_root_description = gv_description. endcase. endmethod.

6. Implement the method FILL_DROPDOWN_LISTBOX with an empty body.

7. Create toolbar TMP_TB2.

8. Create the field group TMP_EXAMPLE9_SRET with TMP_EXAMPLE_RESULT_TREE as

screen structure.


9. Copy the application set from example TMP_EXAMPLE8 to TMP_EXAMPLE9 and change

the modelError! Bookmark not defined. access classto TCL_MDM_EXAMPLE9. Add a new entry for the screen structure TMP_EXAMPLE_RESULT_TREE and model access class TCL_MDM_EXAMPLE9.

10. Copy the application from example TMP_EXAMPLE8 to TMP_EXAMPLE9. Change the entry for event INIT and result list and create the others:

11. Delete the entry for the ODP 1 from the application.

Example 10: ODP with Multiple Tabs (View)

This example introduces multiple tabs on the tabstrip. Each of them contains special fields or a usage of special reference groups.


2. Create new events: TMP_EXAMPLE_FIELDS, TMP_EXAMPLE_GROUPS, TMP_EXAMPLE_CHECKBOX, TMP_EXAMPLE_DDLB, TMP_EXAMPLE_RADIO, TMP_EXAMPLE_TABLE, TMP_EXAMPLE_TABLE2, TMP_EXAMPLE_HTML.

3. Create the tab group TMP_EXP10 with the events above as tab pages .


4. Create new field groups:

TMP_FIELD_TEXT The first field displays ist values as text, the second has a default value,

TMP_FIELD_INPUT_READONLY An input field is shown which is set to “not changeable” in the blueprint table,

TMP_FIELD_INPUT The first field is a simple input field,the second one is a mandatory input field,

TMP_FIELD_IMAGE An image will be shown here

TMP_EXAMPLE10_FIELDS The four field groupsError! Bookmark not defined. from above are included as screen groups,

TMP_GROUP_SIMPLE Two fields typed as input fields,

TMP_GROUP_CHECKBOX_FIELDS One field typed as a checkbox item,

TMP_GROUP_CHECKBOX Includes the group above as a checkbox group, therefore it gets a frame

TMP_GROUP_MELTING_FIELDS Two fields typed as input fields,

TMP_GROUP_MELTING Includes the group above as a melting group,both fields are melted together in one column,

TMP_GROUP_LOGICAL_FIELDS Two fields typed as input fields,

TMP_GROUP_LOGICAL Includes the group above as an logical group, both fields are displayed near to each other, no new line is allowed here,

TMP_GROUP_INCLUDE_A_FIELDS Two fields typed as input fields,

TMP_GROUP_INCLUDE_B_FIELDS Two fields typed as input fields,

TMP_GROUP_INCLUDE Includes the group above as an include group, nothing special happens,

TMP_EXAMPLE10_GROUPS The five field groups from above are included as screen groups,

TMP_RADIO_FIELD One field typed as radio button,

TMP_RADIO_FIELDS Two fields typed as radio button, ‘space’ as initial value is not in value list


TMP_EXAMPLE10_RADIO The two field groups from above are included as screen groups,

TMP_FLAGS_CBGR Two fields as checkbox items,

TMP_EXAMPLE10_CBGR The first line is a simple checkbox item, the second entry defines a checkbox group, therefore it gets a frame,

TMP_EXAMPLE10_DDLB The first is a normal dropdown listbox, the second has an empty entry (not mandatory), the third is set to “not changeable”, the forth gets no domain values, the fifth sends a request, when the value changes,

TMP_FORAMT Two fields typed as input fields,

TMP_EXAMPLE10_LIST Two fields as text fields, two as input fields, the fith is a field melting group

TMP_EXAMPLE10_LIST2 The first is a text field, the second is a input field, the third is a input field set to “not changeable”, the forth is a normal dropdown listbox, the fifth is a dropdown listbox set to “not changeable”,

TMP_EXAMPLE10_HTML The only field is named URL and will contain a valid URL.


6. Create new entries in the application: Event Position Screen

Element Field Group Tab Group

TMP_EXAMPLE_CHECKBOX ODC 1 FORM TMP_EXAMPLE_CBGR TMP_EXP10

TMP_EXAMPLE_DDLB ODC 1 FORM TMP_EXAMPLE_DDLB TMP_EXP10

TMP_EXAMPLE_FIELDS ODC 1 FORM TMP_EXAMPLE_FIELDS TMP_EXP10

TMP_EXAMPLE_GROUPS ODC 1 FORM TMP_EXAMPLE_GROUPS TMP_EXP10

TMP_EXAMPLE_RADIO ODC 1 FORM TMP_EXAMPLE_RADIO TMP_EXP10

TMP_EXAMPLE_TABLE ODC 1 LIST TMP_EXAMPLE_LIST TMP_EXP10

TMP_EXAMPLE_TABLE2 ODC 1 LIST TMP_EXAMPLE_LIST2 TMP_EXP10

TMP_EXAMPLE_HTML ODC 1 HTMLError! Bookmark not defined.

TMP_EXAMPLE_HTML TMP_EXP10

7. Assign the tab group TMP_EXP10 to a other entries in the application for the screen position ODP 1.

8. Create new entries in the application set for model access structures TMP_EXAMPLE_BOOK.

The tab TMP_EXAMPLE10_FIELDS contains different type of fields, in TMP_EXAMPLE10_GROUPS the different grouping features are shown. Radio buttons are in the tab TMP_EXAMPLE10_RADIO, whereas checkboxes are in tab TMP_EXAMPLE10_CBGR. Dropdown listboxes are included in the


tab TMP_EXAMPLE10_DDLB, list views are in TMP_EXAMPLE10_LIST and TMP_EXAMPLE10_LIST2. To include a HTML page look at TMP_EXAMPLE10_HTML. This works either with a direct url in the field URL or a table with HTML code in a field called HTML_TABLE.

Example 11: ODP 1 with Multiple Tabs (Model)

Now we want to populate the new tab pages with data. Therefore we need to implement the READ methods.


2. Copy the application and the application set from example TMP_EXAMPLE10 to TMP_EXAMPLE11. For the application set change the model access class to TCL_MDM_EXAMPLE11.

3. Adjust READ and MODIFY methods so they will handle all screen structures. Both methods are called with the object keyError! Bookmark not defined. of the focus object. For the List display the method READ_FOCUS_OBJECT is called with the object key of the selected line.

METHOD IF_CRM_BSP_MODEL_ACCESS_IL~READError! Bookmark not defined.. * depending on the calling screen structureError! Bookmark not defined. CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_RESULT'. CALL METHOD me->read_result EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_ODC1_MAIN'. CALL METHOD me->read_main EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_ODC1_DET'. CALL METHOD me->read_det EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_BOOK'. CALL METHOD me->read_book EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_HTML'.


CALL METHOD me->read_html EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. ENDCASE. APPEND me->gc_init_class TO et_class_name. ENDMETHOD.

METHOD read_result. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_data INTO me->gs_data WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_data-carrid = 'SQ'. lv_display = 'X'. ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_data-object_key. APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

METHOD read_main. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result TYPE tmp_example_odc1_main. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * it will be always only one entry in the IT_OBJECT_KEY, because


* this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING ls_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data has to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

METHOD read_det. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result TYPE tmp_example_odc1_det. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * it will be always only one entry in the IT_OBJECT_KEY, because * this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING ls_data TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data has to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key.


* * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

METHOD read_book. TYPES: BEGIN OF lt_keys, carrid TYPE s_carr_id, connid TYPE s_conn_id, fldate TYPE s_date, END OF lt_keys. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result LIKE LINE OF me->gt_book, ls_keys TYPE lt_keys, lt_keys TYPE TABLE OF lt_keys, lv_guid TYPE guid_32. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * it will be always only one entry in the IT_OBJECT_KEY, because * this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING ls_data TO ls_keys. ENDIF. APPEND ls_keys TO lt_keys. ENDLOOP. * only if we have entries found CHECK NOT lt_keys[] IS INITIAL. * if not in internal table, read from database LOOP AT lt_keys INTO ls_keys. READ TABLE me->gt_book WITH KEY carrid = ls_keys-carrid connid = ls_keys-connid fldate = ls_keys-fldate TRANSPORTING NO FIELDS. IF NOT sy-subrc IS INITIAL. SELECT * FROM sbook APPENDING CORRESPONDING FIELDS OF TABLE me->gt_book WHERE carrid = ls_keys-carrid AND connid = ls_keys-connid AND fldate = ls_keys-fldate. ENDIF. ENDLOOP. * read result from internal table LOOP AT lt_keys INTO ls_keys. LOOP AT me->gt_book INTO ls_result WHERE carrid = ls_keys-carrid AND connid = ls_keys-connid AND fldate = ls_keys-fldate. * insert missing GUID IF ls_result-object_key IS INITIAL. CALL FUNCTION 'GUID_CREATE' IMPORTING ev_guid_32 = lv_guid. ls_result-object_key = lv_guid. ls_result-type = 'B'. MODIFY me->gt_book FROM ls_result. ENDIF. APPEND ls_result TO et_screen_structure.


ENDLOOP. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data has to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

METHOD read_html. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data TYPE tmp_example_result, ls_result TYPE tmp_example_html. * it will be always only one entry in the IT_OBJECT_KEY, because * this is the ODP 1. * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_data INTO ls_data WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. SELECT SINGLE url INTO ls_result-url FROM scarr WHERE carrid = ls_data-carrid. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. ENDMETHOD.

method IF_CRM_BSP_MODEL_ACCESS_IL~MODIFY. CASE iv_screen_structure_name. * Chnages in the result list WHEN 'TMP_EXAMPLE_RESULT'. CALL METHOD me->modify_result EXPORTING iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key IMPORTING et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. * Changes in the detail tab of the ODPError! Bookmark not defined. 1 (the main tab as only text fields) WHEN 'TMP_EXAMPLE_ODC1_DET'. CALL METHOD me->modify_det EXPORTING


iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key IMPORTING et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. * Changes in the other tabs of the ODP 1 WHEN 'TMP_EXAMPLE_BOOK'. CALL METHOD me->modify_book EXPORTING iv_screen_structure_name = iv_screen_structure_name it_screen_structure = it_screen_structure it_changed_field = it_changed_field iv_parent_object_key = iv_parent_object_key IMPORTING et_failed_object_key = et_failed_object_key et_new_object_key = et_new_object_key. ENDCASE. APPEND me->gc_init_class TO et_class_name. endmethod.

method MODIFY_RESULT. TYPES: tt_tmp_example_result TYPE STANDARD TABLE OF tmp_example_result. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_result, <fs_old_data> TYPE tmp_example_result, <fs_new_data> TYPE tmp_example_result, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>. * read actual data set from global internal table READ TABLE gt_data WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. <fs_old> = <fs_new>. ENDLOOP. * update global data set gs_data = <fs_old_data>. endmethod.

METHOD MODIFY_DET.


TYPES: tt_tmp_example_odc1_det TYPE STANDARD TABLE OF tmp_example_odc1_det. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_odc1_det, <fs_old_data> TYPE tmp_example_result, <fs_new_data> TYPE tmp_example_odc1_det, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>. * read actual data set from global internal table READ TABLE gt_data WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. IF NOT sy-subrc IS INITIAL. * this field is unknown in the changed structure: * should NEVER occur CONTINUE. ENDIF. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. * this field is unknown in the global internal table: * maybe it is stored somewhere else IF NOT sy-subrc IS INITIAL. CONTINUE. ENDIF. * assign new value <fs_old> = <fs_new>. ENDLOOP. * update global data set gs_data = <fs_old_data>. ENDMETHOD.

METHOD MODIFY_BOOK. TYPES: tt_tmp_example_book TYPE STANDARD TABLE OF tmp_example_book. FIELD-SYMBOLS: <ft_data> TYPE tt_tmp_example_book, <fs_old_data> TYPE tmp_example_book, <fs_new_data> TYPE tmp_example_book, <fs_old> TYPE ANY, <fs_new> TYPE ANY, <fs_changes> TYPE crmt_bsp_changedfield, <fs_name> TYPE crmt_bsp_fieldname. * cast from TYPE ANY to TT_ZHS_DATEN ASSIGN it_screen_structure TO <ft_data>. * read modified data set READ TABLE <ft_data> INDEX 1 ASSIGNING <fs_new_data>.


* read actual data set from global internal table READ TABLE gt_book WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_old_data>. * read the changed values for this data set READ TABLE it_changed_field WITH KEY object_key = <fs_new_data>-object_key ASSIGNING <fs_changes>. * loop for all changed fields LOOP AT <fs_changes>-field_name_tab ASSIGNING <fs_name>. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_new_data> TO <fs_new>. IF NOT sy-subrc IS INITIAL. * this field is unknown in the changed structure: * should NEVER occur CONTINUE. ENDIF. ASSIGN COMPONENT <fs_name> OF STRUCTURE <fs_old_data> TO <fs_old>. * this field is unknown in the global internal table: * maybe it is stored somewhere else IF NOT sy-subrc IS INITIAL. CONTINUE. ENDIF. * assign new value <fs_old> = <fs_new>. ENDLOOP. * actualise global data set gs_book = <fs_old_data>. ENDMETHOD.

4. Implement FILL_DROPDOWN_LISTBOX method to influence the values of a dropdown listbox.

METHOD if_crm_bsp_model_access_il~fill_dropdown_listbox. * type for values for dropdown listbox TYPES: BEGIN OF ts_ddlb_data, key_field TYPE char8, text_field TYPE char40, END OF ts_ddlb_data. DATA: lt_ddlb_data TYPE REF TO data, ls_ddlb_data TYPE REF TO data. FIELD-SYMBOLS: <fs_ddlb> TYPE crmt_dropdownlistbox_data, <fs_ddlb_data> TYPE ts_ddlb_data, <ft_ddlb_data> TYPE table. * only if DDLB are on the screen CHECK NOT ct_dropdownlb_data[] IS INITIAL. CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_BOOK'. * loop over all DDLB LOOP AT ct_dropdownlb_data ASSIGNING <fs_ddlb>. * handle DDLB for field INVOICE IF <fs_ddlb>-fieldname = 'COUNTER'. * all possible values * IF iv_all_values = 'X'. * create data objects and assign field symbols


CREATE DATA lt_ddlb_data TYPE TABLE OF ts_ddlb_data. CREATE DATA ls_ddlb_data TYPE ts_ddlb_data. ASSIGN lt_ddlb_data->* TO <ft_ddlb_data>. ASSIGN ls_ddlb_data->* TO <fs_ddlb_data>. * fill table with values CLEAR <fs_ddlb_data>. MOVE '00000001' TO <fs_ddlb_data>-key_field. MOVE text-001 TO <fs_ddlb_data>-text_field. APPEND <fs_ddlb_data> TO <ft_ddlb_data>. CLEAR <fs_ddlb_data>. MOVE '00000002' TO <fs_ddlb_data>-key_field. MOVE text-002 TO <fs_ddlb_data>-text_field. APPEND <fs_ddlb_data> TO <ft_ddlb_data>. CLEAR <fs_ddlb_data>. MOVE '00000003' TO <fs_ddlb_data>-key_field. MOVE text-003 TO <fs_ddlb_data>-text_field. APPEND <fs_ddlb_data> TO <ft_ddlb_data>. CLEAR <fs_ddlb_data>. MOVE '00000000' TO <fs_ddlb_data>-key_field. MOVE text-000 TO <fs_ddlb_data>-text_field. APPEND <fs_ddlb_data> TO <ft_ddlb_data>. * assign table to DDLB <fs_ddlb>-keycolumnname = 'KEY_FIELD'. <fs_ddlb>-valuecolumnname = 'TEXT_FIELD'. MOVE lt_ddlb_data TO <fs_ddlb>-data. * ELSE. * ENDIF. ENDIF. ENDLOOP. ENDCASE. * IF iv_object_key IS INITIAL AND iv_all_values = 'X'. * IF iv_screen_structure_name = 'ZHS_ERGEBNIS'. * ENDIF. * ENDIF. ENDMETHOD.

5. Implement CHECK_ACTIVE_TABSTRIP method to hide the first tab as soon as data is selected.

METHOD if_crm_bsp_model_access_il~check_active_tabstrip. DATA ls_tabstrip TYPE crmc_regtabgrp. * hide the first tab page as soon as data is selected IF iv_screen_structure_name <> 'TMP_EXAMPLE_ODC1_MAIN' AND NOT iv_object_key IS INITIAL. DELETE ct_tabstrip WHERE event = 'TMP_EXAMPLE_MAIN'. ENDIF. ENDMETHOD

Example 12: ODP 1 with Toolbar (View)

In this example we create a new toolbar and assign it to the screen structures which are placed in the ODP 1. Here it is only one toolbar for all screen structures but of course it could be also a different one for each screen structure. After pressing the button a message will appear in the applicaton log area above the search area as with the buttons from the toolbar of the result list of example 7.



2. Create new events: TMP_MESSAGES_1, TMP_MESSAGES_2.

3. Create new toolbar TMP_TB3 and assign the two new events.


TMP_EXAMPLE12. For the application set change the model access class to TCL_MDM_EXAMPLE12 but keep the field groupError! Bookmark not defined.s.

5. Assign the toolbar TMP_TB3 to all entries in the application for screen position ODPError! Bookmark not defined. 1.

Example 13: ODP 1 with Toolbar (Model)

After pressing the button one or more messages will be shown in the application log. With the enhancement of the methode GET_MESSAGE you can now expand this area to look at all messages at the same time. When you click on the link, the long text will be displayed.

With using messages the cursor can be placed on a specific field defined in the blueprint. Click on a line of a message and this will happen.


2. Copy the application and the application set from example TMP_EXAMPLE12 to TMP_EXAMPLE13. For the application set change the model access class to TCL_MDM_EXAMPLE13 but keep the field groups.

3. Create two more messages in the message class TMP_EXAMPLE.

4. Adjust PROCESS_EVENT and GET_MESSAGE methods. Create ADD_MESSAGE method.

5. Create the following three entries in the blueprint table NAVIGATION FOR APPLICATION LOG:


Example 14: Screen with ODP 1 and ODP 2 (View)

With a list in the ODP 1 sometime it is neccessary to show more detail values in a second area, the ODP 2.

1. Create the DDIC structure TMP_EXAMPLE_BOOK_DET as a copy of TMP_EXAMPLE_BOOK.


3. Copy the application and the application set from example TMP_EXAMPLE13 to TMP_EXAMPLE14. For the application set change the model access class to TCL_MDM_EXAMPLE14 but keep the field groups and create a new entry for the DDIC structure TMP_EXAMPLE_BOOK_DET.

4. Create the event TMP_EXAMPLE_ODC2.

5. Create the tab group TMP_EXP14 and assign the event TMP_ EXAMPLE_ODC2.

6. Define the field group TMP_EXAMPLE14_ODC2 for the DDIC structure

TMP_EXAMPLE_BOOK_DET.

7. Create the following two entries in the application:


Example 15: Screen with ODP 1 and ODP 2 (Model)

Here are the methods to fill the ODP 2 screen structure.


2. Copy the application and the application set from example TMP_EXAMPLE14 to TMP_EXAMPLE15. For the application set change the model access class to TCL_MDM_EXAMPLE15 but keep the field groups.

3. Implement the methods READ and READ_FOCUS_OBJECT.

In the READ method from the exercise before replace the READ_HTML method through method READ_BOOK_DET:

METHOD IF_CRM_BSP_MODEL_ACCESS_IL~READ. (…) WHEN 'TMP_EXAMPLE_BOOK_DET'. CALL METHOD me->read_book_det EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. (…) ****************************************************************** METHOD READ_BOOK_DET. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result LIKE LINE OF me->gt_book. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * only one entry because it is the focus object * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_book INTO ls_result WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. APPEND ls_result TO et_screen_structure. * it should find only one entry EXIT. ENDIF. ENDLOOP. * lock object IF iv_lock EQ 'X'.


* calling enqueue function module, if additional data had to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME' * ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

method IF_CRM_BSP_MODEL_ACCESS_IL~READ_FOCUS_OBJECT. * depending on the calling screen structure CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_BOOK'. CALL METHOD me->read_focus_book EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. ENDCASE. APPEND me->gc_init_class TO et_class_name. endmethod.

METHOD read_focus_book. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result LIKE LINE OF me->gt_book. * ls_object_attr TYPE crmt_bsp_fieldattribute, * ls_field_attr TYPE crmt_bsp_obj_fieldattribute. * only one entry because it is the focus object * read data according to object key READ TABLE it_object_key INTO ls_object_key INDEX 1. LOOP AT me->gt_book INTO ls_result WHERE object_key = ls_object_key. IF sy-subrc IS INITIAL. APPEND ls_result TO et_screen_structure. * it should find only one entry EXIT. ENDIF. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module, if additional data had to be maintained ENDIF. * modify screen, * ls_field_attr-field_name = space. " valid for all fields * 'TMP_EXAMPLE_ODC1_MAIN-CARRNAME'


* ls_field_attr-field_property = 'A' " Not Changeable * 'B' " Not Relevant * 'C' " Mandatory Field * APPEND ls_field_attr TO ls_object_attr-field_attribute. * * ls_object_attr-object_key = gs_data-object_key. * * APPEND ls_object_attr TO et_field_attribute. ENDMETHOD.

Remember the system calls first the READ method and expects to get back one or a list of objects. Then it calls the method READ_FOCUS_OBJECT with the lock flag set and the one focus object of the returned list. This is valid in the same way for result list, ODP 1 and ODP 2.

Example 16: ODP with Tree (Model / View)

The tree can also be used in the ODPs.


2. Copy the application and the application set from example TMP_EXAMPLE09 to TMP_EXAMPLE16. For the application set change the model access class to TCL_MDM_EXAMPLE16 but keep the field groupError! Bookmark not defined.s.

3. Create the Toolbar TMP_TB8 with the events ADD_LINE and REMOVE_LINE.

4. In the application

- Change the entry for the result list from screen type SRET to FORM and use field group TMP_EXAMPLE4_SERS.

- Create an new entry for ODP 1with TREE as screen type, field group TMP_EXAMPLE9_SRET and TMP_TB8 as toolbar.

- Adjust the entry for event TMP_EXAMPLE_MAIN to the same values


5. React on the event REMOVE_LINE in the method PROCESS_EVENT. METHOD if_crm_bsp_model_access_il~process_event. * the events "SAVE" and "DELETE" are handled in the DO_HANDLE_EVENT method of the subcontroller CASE iv_event. WHEN 'CREATE' OR 'CHANGE' OR 'COPY' OR 'PRINT'. MESSAGE s001(00) WITH 'Button >' iv_event '< pressed'. CALL METHOD me->set_status_message. WHEN 'REMOVE_LINE'. * remove entry from hierarchy table (don't care about children ) DELETE me->gt_hier WHERE object_key = iv_focus_object_key. * on success, set flag for refresh IF sy-subrc IS INITIAL. gv_refresh = 'X'. ENDIF. ENDCASE. ENDMETHOD.

6. Implement the method REFRESH to refresh the tree after a line was removed. METHOD if_crm_bsp_treetable_il~refresh. * only for the screen structure of the tree CHECK iv_screen_structure_name = 'TMP_EXAMPLE_RESULT_TREE'. * refresh was set by method PROCESS_EVENT ev_refresh = gv_refresh. CLEAR gv_refresh. ENDMETHOD.

The only event the tree controller handles by itself – except from focus changes and exand etc. – is the ADD_LINE event. All other events such as REMOVE_LINE must be handled by the application itself. If necessary the method REFRESH must return a true value to have the tree controller rebuild the tree.

Example 17: Dialogs via Popin and Popup (View / Model)

Popin and popup are special areas to enter more selection criteria or display additional information. This area is displayed as a separate window (popup) or between the result list and the ODP 1 (popinError! Bookmark not defined.). It can contain any field type (text, input, dropdown listbox, checkbox, radio button, …) and it is possible to define the field group not only as a form but also a list. In this example we use a popin, however it is recommended to use popups, but the implementation is quite the same.

1. Create DDIC structure TMP_EXAMPLE_DATA with some fields. Do not forget the field OBJECT_KEY.



GC_INIT_CLASS.

3. Copy the application and the application set from example TMP_EXAMPLE15 to TMP_EXAMPLE17. For the application set change the model access classError! Bookmark not defined. to TCL_MDM_EXAMPLE17 but keep the field groups. Add a new entry for the screen structure TMP_EXAMPLE_DATA and model access class TCL_MDM_EXAMPLE17.

4. Define the message 005 in the message class TMP_EXAMPLE with the text “Pop-In requested”.

5. Create the events TMP_REQUEST_POPIN, TMP_RAISE_POPIN and TMP_EXAMPLE_POPIN.

6. Create the tab group TMP_EXP17 with the event TMP_EXAMPLE_POPIN.

7. Define the field group TMP_EXAMPLE17_POPIN with the DDIC structure

TMP_EXAMPLE_DATA.


8. Create an entry in the application table for the event TMP_RAISE_POPIN in screen position

“PopIn”:

Event Position Screen Element

Field Group Tab Group

TMP_RAISE_POPIN PopIn FORM TMP_EXAMPLE17_POPIN TMP_EXP17

9. Create one entry in the blueprint tableError! Bookmark not defined. NAVIGATION FOR APPLICATION LOG:

Message Id Message No Action Event

TMP_EXAMPLE 005 TMP_RAISE_POPIN

10. Create the toolbar TMP_TB4 with the event TMP_REQUEST_POPIN and assign it to all entries in the application table for screen position result listError! Bookmark not defined. and ODP 1.

Pressing the button “Request Pop-In” will always create an empty area with text field, input field, etc. between the result list and the ODP 1, regardless if the button in the toolbarError! Bookmark not defined. of the result list or in the toolbar of the ODP 1 (or even ODP 2) is choosen.

Example 18: Screen Variants Within ODPError! Bookmark not defined.

If you have different objects to maintain with similiar but not exact the same data, it may be convenient to handle this data on the same tab.

Variants are the choice to do this. You define for the same event different variants which will show the object-specific data depending on the focus object. This works only for the ODPs, not for the result list.


2. Copy the application and the application set from example TMP_EXAMPLE9 to TMP_EXAMPLE18.


For the application set change the model access class to TCL_MDM_EXAMPLE18 but keep the field groups.

3. Add new entries for the screen structures TMP_EXAMPLE_SPFLI, TMP_EXAMPLE_FLIGHT, TMP_EXAMPLE_BOOK and model access class TCL_MDM_EXAMPLE18 to the application set.

4. Define the field groups TMP_EXAMPLE18_SPFLI, TMP_EXAMPLE18_FLIGHT, TMP_EXAMPLE18_BOOK.

5. Adjust the READ method to handle the new DDIC structures. METHOD if_crm_bsp_model_access_il~read. * depending on the calling screen structure CASE iv_screen_structure_name. WHEN 'TMP_EXAMPLE_RESULT_TREE'. CALL METHOD me->read_result_tree EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_RESULT'. CALL METHOD me->read_result EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name


IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_SPFLI'. CALL METHOD me->read_connection EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_FLIGHT'. CALL METHOD me->read_flight EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. WHEN 'TMP_EXAMPLE_BOOK'. CALL METHOD me->read_booking EXPORTING iv_lock = iv_lock it_object_key = it_object_key iv_screen_structure_name = iv_screen_structure_name IMPORTING et_screen_structure = et_screen_structure et_field_attribute = et_field_attribute. ENDCASE. APPEND me->gc_init_class TO et_class_name. ENDMETHOD.

METHOD READ_RESULT_TREE. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result_tree, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_hier INTO me->gs_hier WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_hier TO ls_result. APPEND ls_result TO et_screen_structure. ENDIF. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_hier-carrid = 'SQ'. lv_display = 'X'.


ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_hier-object_key. APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

METHOD READ_RESULT. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_result, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute, lv_display TYPE c. * initialize CLEAR lv_display. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_hier INTO me->gs_hier WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. MOVE-CORRESPONDING me->gs_hier TO ls_result. ENDIF. APPEND ls_result TO et_screen_structure. ENDLOOP. * lock object IF iv_lock EQ 'X'. * calling enqueue function module * sorry, SPLFI has no enqueue object, but * let's say, we allow only display for data of SQ (Singapore Airlines) IF gs_hier-carrid = 'SQ'. lv_display = 'X'. ENDIF. ENDIF. * modify screen, e.g. display mode if object is already locked IF lv_display = 'X'. ls_field_attr-field_name = space. " valid for all fields ls_field_attr-field_property = 'A'. " display mode APPEND ls_field_attr TO ls_object_attr-field_attribute. ls_object_attr-object_key = gs_hier-object_key. APPEND ls_object_attr TO et_field_attribute. ENDIF. ENDMETHOD.

METHOD read_connection. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result LIKE LINE OF me->gt_conn, ls_object_attr TYPE crmt_bsp_fieldattribute. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_conn INTO ls_result WITH KEY object_key = ls_object_key.


IF sy-subrc IS INITIAL. APPEND ls_result TO et_screen_structure. ENDIF. ENDLOOP. ENDMETHOD.

METHOD READ_FLIGHT. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result LIKE LINE OF me->gt_flight, ls_object_attr TYPE crmt_bsp_fieldattribute. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_flight INTO ls_result WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. APPEND ls_result TO et_screen_structure. ENDIF. ENDLOOP. ENDMETHOD.

METHOD READ_BOOKING. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result LIKE LINE OF me->gt_book, ls_object_attr TYPE crmt_bsp_fieldattribute. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_book INTO ls_result WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. APPEND ls_result TO et_screen_structure. ENDIF. ENDLOOP. ENDMETHOD.

6. Implement the GET_VARIANT method to decide on the object type of the focus object which variant to be used. Prerequiste for this is that the READ method returned an screen structure with an not initial object key.

METHOD if_crm_bsp_model_access_il~get_variant. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_data LIKE LINE OF me->gt_hier. * read data according to object key READ TABLE me->gt_hier INTO ls_data WITH KEY object_key = iv_object_key. CASE ls_data-type. WHEN 'S'. ev_screen_variant = 'CONN'. WHEN 'F'. ev_screen_variant = 'FLIGHT'. WHEN 'B'. ev_screen_variant = 'BOOK'. ENDCASE. ENDMETHOD.

7. Insert the following entries in the application with variants as key fields:


Event Position Screen Variant

Screen Element

Field Group Tab Group

INIT ODC 1 BOOK FORM TMP_EXAMPLE18_BOOK TMP_EXP4

INIT ODC 1 CONN FORM TMP_EXAMPLE18_SPLFI TMP_EXP4

INIT ODC 1 FLIGHT FORM TMP_EXAMPLE18_FLIGHT TMP_EXP4

TMP_EXAMPLE_MAIN ODC 1 BOOK FORM TMP_EXAMPLE18_BOOK TMP_EXP4

TMP_EXAMPLE_MAIN ODC 1 CONN FORM TMP_EXAMPLE18_SPLFI TMP_EXP4

TMP_EXAMPLE_MAIN ODC 1 FLIGHT FORM TMP_EXAMPLE18_FLIGHT TMP_EXP4

Now you will see, that depending on the selected object, a connection, a flight or a booking different data is shown in the same tab “Main Data”.

Because in the method GET_VARIANT you have only the object key at your hand, you can not define a variant for specific tabs, but for a specific object for all tabs. As a result you need to define the variant for all of your tabs. Otherwise the framework will not find the proper tab for the field group.

The variant will be valid for all inferior screen positions. This means a variant defined for the screen structure of the result list is taken to determine the entries for the ODP 1. In turn a variant defined for a screen structure of ODP 1 can overwrite this for the inferior ODP 2 of this tab.

Example 19: Advanced F4 Help

Some fields may need a more sophisticated F4 help than domain values or a value table. For this a application can be assigned to fields, which were called when hitting the F4 button. The result of this F4 application is the filled automatically into the calling field.

1. At first create the F4 application: it will search for carriers.

a. Create the DDIC structure TMP_EXAMPLE_SEARCH_APP with the mandatory object key and an include of the table SCARR.

b. Define the field group TMP_EXAMPLE19_SEARCH_APP with the DDIC structure

TMP_EXAMPLE_SEARCH_APP.


c. Define the application TMP_EXAMPLE19_SEARCH with events for the search area

and the result list.

d. Define the application set for the application and the DDIC structure

TMP_EXAMPLE_SEARCH_APP.

e. Implement the class TCL_EXAMPLE_19_SEARCH_APP for the interface

IF_CRM_BSP_MODEL_ACCESS_IL with the methods QUERY and READ. METHOD if_crm_bsp_model_access_il~query. DATA: ls_search TYPE tmp_example_search_app, ls_data LIKE LINE OF me->gt_data, lt_data LIKE me->gt_data, ls_object_key TYPE crmt_bsp_objectkey, lt_object_key TYPE crmt_bsp_objectkey_tab, lt_carrid TYPE RANGE OF s_carr_id, ls_carrid LIKE LINE OF lt_carrid, lt_carrname TYPE RANGE OF s_carrname, ls_carrname LIKE LINE OF lt_carrname, lt_url TYPE RANGE OF s_carrurl, ls_url LIKE LINE OF lt_url, lv_guid TYPE guid_32. FIELD-SYMBOLS <fs_data> TYPE tmp_example_search_app. * this query method is only programmed for this screen structure CHECK iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH_APP'.


* move from generic structure to own structure MOVE is_screen_structure TO ls_search. * refresh class variable REFRESH me->gt_data. * no selection criteria => gime all! IF ls_search IS INITIAL. SELECT * FROM scarr INTO CORRESPONDING FIELDS OF TABLE me->gt_data. * selection by search criteria ELSE. macro_define_range: ls_carrid lt_carrid ls_search-carrid, ls_carrname lt_carrname ls_search-carrname, ls_url lt_url ls_search-url. SELECT * FROM scarr INTO CORRESPONDING FIELDS OF TABLE me->gt_data WHERE carrid IN lt_carrid AND carrname IN lt_carrname AND url IN lt_url. ENDIF. * define object keys LOOP AT me->gt_data ASSIGNING <fs_data>. <fs_data>-object_key = <fs_data>-carrid. ENDLOOP. REFRESH et_object_key. LOOP AT me->gt_data INTO ls_data. APPEND ls_data-object_key TO et_object_key. ENDLOOP. * if nothing found => raise message IF et_object_key[] IS INITIAL. MESSAGE s001(tmp_example) WITH 0. CALL METHOD me->set_status_message. ENDIF. ENDMETHOD.

METHOD if_crm_bsp_model_access_il~read. DATA: ls_object_key TYPE crmt_bsp_objectkey, ls_result TYPE tmp_example_search_app, lt_result TYPE TABLE OF tmp_example_search_app, ls_object_attr TYPE crmt_bsp_fieldattribute, ls_field_attr TYPE crmt_bsp_obj_fieldattribute. CHECK iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH_APP'. * read data according to object key (s) LOOP AT it_object_key INTO ls_object_key. READ TABLE me->gt_data INTO ls_result WITH KEY object_key = ls_object_key. IF sy-subrc IS INITIAL. APPEND ls_result TO lt_result. ENDIF. ENDLOOP. et_screen_structure = lt_result[]. ENDMETHOD.

2. Second copy the application TCL_MDM_EXAMPLE5 and adjust the carrier field for using the F4 application.


a. Copy the class TCL_MDM_EXAMPLE5 to TCL_MDM_EXAMPLE19_APP. Correct the constant GC_INIT_CLASS.

b. Copy the application and the application set from example TMP_EXAMPLE5 to TMP_EXAMPLE19_APP. For the application set change the model access class to TCL_MDM_EXAMPLE19_APP but keep the field groups.

c. Copy the field groups TMP_CARRIER_SERQ to TMP_EXAMPLE19_CARRIER_SERQ and TMP_EXAMPLE4_SERQ to TMP_EXAMPLE19_SERQ.

d. Define for the carrier in the field group TMP_EXAMPLE19_CARRIER_SERQ the application TMP_EXAMPLE19_SEARCH as F4 application.

e. Replace in the field group TMP_EXAMPLE19_SERQ position 10 the reference group

TMP_CARRIER_SERQ with TMP_EXAMPLE19_CARRIER_SERQ.

f. Replace the field group TMP_EXAMPLE4_SERQ with TMP_EXAMPLE19_SERQ in the

application TMP_EXAMPLE19_APP. If you are using the application TMP_EXAMPLE19_APP, goto the advanced search and click the F4help for carrier. A new window will pop up in which you can search for this carrier. The result – the value, you mark in the result list – is transported back.

If you have different field name in your application and in the F4 application, you need to define a name mapping.


Example 20: Favorites

You can assign some objects from the search result list to your favorites “My Favorites”. This search is always and automatically executed at the start for the application.

1. Copy the class TCL_MDM_EXAMPLE19_SEARCH to TCL_MDM_EXAMPLE20. Correct the constant GC_INIT_CLASS.

2. Create toolbar TMP_TB6 with events ADD_TO_FAVORITES and DEL_FROM_FAVORITES.

3. Copy the application and the application set from example TMPM_EXAMPLE19_SER to

TMPM_EXAMPLE20. For the application set change the model access class to TCL_MDM_EXAMPLE20 but keep the field groups.

4. Assign the toolbar TMP_TB6 to the application set.

5. In the Application / Layout maintain the favorites folder TMP_EX21


In the section Screen Structure assign the Toolbar TMP_TB6 to the result list

In the section Object Type Assignment create an entry for the BOR objectError!

Bookmark not defined. SFLIGHT.

6. Implement the methods CONVERT_TO_BOR and CONVERT_FROM_BORError! Bookmark

not defined. to convert the object key of the BOR objects to the object key of the application.

method if_crm_bsp_model_access_il~convert_to_bor. check iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH_APP'. * this should correspond to the entry done with transaction SMY1 ev_objtype = 'SFLIGHT'. * the OBJECT_KEY is CARRID ev_objkey = iv_object_key. call function 'OWN_LOGICAL_SYSTEM_GET' importing own_logical_system = ev_logsys. endmethod.

method if_crm_bsp_model_access_il~convert_from_bor. check iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH_APP'. * Object key is CARRID ev_object_key = iv_objkey. endmethod.

The application can define more entries in this list or modify them by implementation of the method GET_MY_FAVORITES. method if_crm_bsp_model_access_il~get_my_favorites.


data: ls_favorite_key type crmt_bsp_objectkey. check iv_screen_structure_name = 'TMP_EXAMPLE_SEARCH_APP'. * Lauda Air is my favorite (in this example) ls_favorite_key = 'NG'. append ls_favorite_key to et_favorite_key. endmethod.

7. Maintain relationship of favorite folder and BOR objecttype via transaction SMY1.

Now you can add objects to your favorites and remove them.

The framework reads the favorites via the GOS (via “Object Type Assignment” the framework finds the BOR object type, then GOS looks for them using this BOR object type). With CONVERT_TO_BOR the object keyError! Bookmark not defined.s are determined and then method READ is called like normal. => READ must read the objects according the object key. It can not rely on method QUERY is called before.

Example 21: Documentation

Because we are running in a browser window F1 help is not available for the application itself. Instead it is possible to assign for each screen area search area, result list, ODP 1, ODP 2, ODP 3 and for each tab in the ODPs a special link to the online documentation in the Knowledge Warehouse. By this the documentation can describe each field and the available functions on the current screen area.

Take a look at the application table of TMPM_EXAMPLE04:

The column “DocuClass” has to be filled with the value “IWB_EXTHLP” and the next column with the LOIO from the Knowledge Warehouse.


Example 22: Event Groups

If an application has several functions which are of the same type but nethertheless different, it is possible to “collect” them in an event group: A single button is shown, which – when selected – will open a new window with all functions as checkboxes. It looks like an F4 help.

This is realized with an asssignment of some events in the toolbar (like in TMP_TB9) to one or more event groups.

If the eventError! Bookmark not defined. group is marked as “Dynamic Events”, the method FILL_EVENTGROUP is called. Here the application can fill in more events as are already defined. The application has to provide the description of the events too.

METHOD IF_CRM_BSP_MODEL_ACCESS_IL~FILL_EVENTGROUP. DATA lv_event TYPE crmc_bsp_event_t. * only for this screen structure CHECK iv_screen_structure_name = 'TMP_EXAMPLE_ODC1_MAIN'. * in this example, we ignore the IV_OBJECT_KEY * we show always the same events CASE iv_eventgroup. WHEN 'TMP_ADD'. lv_event-event = 'ADD_LINE'. APPEND lv_event TO ct_event. lv_event-event = 'ADD_TO_FAVORITES'. APPEND lv_event TO ct_event. lv_event-event = 'INSERT'. APPEND lv_event TO ct_event. ENDCASE. ENDMETHOD.

For the implementation details, look at the application TMPM_EXAMPLE_EVENT and the class TCL_MDM_EXAMPLE_EVENT.


Example 23: Viewswitch Groups

If an application has several tab pages which are of the same type but nethertheless different, it is possible to “collect” them via viewswitch groups: There will be a DDLB in the toolbar from which the user can select one of the “collected” tab pages.

To get such a DDLB define the viewswitch groups and assign a viewswitch group to those events in the tab group representing the tab pages.

For the implementation details, look at the application TMPM_EXAMPLE_VIEWSW and the class TCL_MDM_EXAMPLE_VIEWSWIT.

This may be a good solution if the application contains several type of texts (for example, long and short texts).


INDEX

ABAP, 6, 15, 16, 17, 18, 20, 21, 25, 27, 33, 87, 92, 93, 108, 112, 138

ABAP context, 58

ABAP Workbench, 18

Accessibility, 87, 154

Actions, 36, 42, 46, 94, 117, 139, 143, 165, 167, 168, 169

Advanced Search, 25, 46, 59, 77, 111, 112, 113, 197, 198

AFTER_ROLLBACK, 7, 57, 62, 63, 65

AFTER_ROLLBACK_DELETE, 7, 56, 57, 65

AFTER_SAVE, 7, 32, 33, 62, 63, 64

Application Set, 38, 51, 52, 53, 96, 97, 159, 160, 176, 198, 214

BAB, 54, 197, 198, 199

Back Navigation, 30

BADI, 58

BEFORE_SAVE, 63

Blueprint Application, 24, 28, 29, 31, 34, 49, 70, 78, 79, 80, 81, 83, 101, 157, 163, 164, 165, 171, 188, 197, 213

Blueprint Table, 15, 19, 20, 21, 23, 24, 25, 26, 32, 33, 34, 35, 36, 37, 38, 40, 42, 44, 45, 46, 47, 48, 50, 53, 54, 55, 57, 66, 69, 78, 82, 83, 88, 96, 104, 107, 108, 111, 118, 119, 120, 121, 136, 142, 147, 153, 155, 156, 165, 166, 168, 177, 185, 188, 195, 197, 198, 199, 213

BLView, 36, 100, 112, 113, 114, 195

Browser, 12, 14, 15, 16, 17, 22, 24, 28, 30, 31, 32, 35, 42, 94, 95, 108, 109, 110, 111, 163, 165, 166

BSP, 6, 7, 8, 12, 15, 16, 17, 18, 19, 20, 21, 23, 24, 25, 33, 47, 54, 56, 58, 59, 61, 66, 67, 75, 76, 78, 79, 81, 82, 83, 104, 105, 106, 107, 109, 119, 121, 122, 136, 137, 138, 139, 143, 148, 153, 155, 157, 158, 159, 160, 162, 166, 170, 184, 185, 195, 213, 218

Business Object, 23, 25, 51, 52, 54, 58, 61, 80, 101, 119, 120, 157, 159, 162, 188

Business Partner, 31, 53, 157, 165, 173, 174, 184, 188, 189

Business Server Pages, 18

CHECK_ACTIVE_MULTIGROUP, 7, 56, 71

CHECK_ACTIVE_STEPS, 7, 8, 56, 71, 147, 148, 149, 152

CHECK_ACTIVE_TABSTRIP, 7, 56, 57, 69

CHECK_ACTIVE_TOOLBAR, 56, 57, 69, 135, 147

CHECK_ACTIVE_VIEWSETGROUP, 7, 8, 56, 71, 142

CHECK_BEFORE_DELETE, 7, 56, 57, 65, 134

CHECK_BEFORE_SAVE, 7, 62, 150, 179, 183

Code inspector, 92

Conditions, 36, 50, 167

Container, 61, 108, 155, 164

Content Management, 37, 102, 157, 158, 159

Context-Sensitive Help, 108, 111

Controller, 13, 14, 15, 20, 22, 23, 24, 25, 26, 35, 36, 37, 50, 57, 58, 59, 60, 66, 68, 69, 76, 77, 88, 89, 101, 104, 105, 107, 108, 111, 133, 134, 135, 138, 142, 145, 147, 153, 154, 155, 157, 161, 162, 163, 165, 166, 177, 184, 185

CONVERT_FROM_BOR, 7, 56, 57, 72, 118

CONVERT_TO_BOR, 7, 56, 57, 72, 118

Creating a new object, 42, 166

CRM Designer, 9, 34, 39, 45, 46, 54, 188, 189, 197, 198, 199, 200, 201, 202, 205

Customizing, 24, 81, 111, 112, 113, 118, 171, 172, 188, 197, 198

Customizing Include, 188

Customizing Layout Tool, 197, 198, 199

Data Binding, 19, 54, 111

Data Elements, 110, 189, 193

Date Management, 171, 172

DDIC, 18, 38, 39, 40, 41, 42, 45, 47, 57, 58, 59, 70, 76, 77, 88, 92, 111, 155, 162, 188, 189, 194, 213


Delete, 65, 66, 71, 72, 120, 133, 143, 161

DELETE, 7, 8, 56, 57, 65, 118, 134, 157, 180

Developer, 17, 19, 20, 21, 87, 101, 106, 160, 172

Development, 12, 15, 16, 17, 18, 19, 20, 21, 22, 33, 34, 35, 54, 89, 91, 94, 141, 197, 213

Document Flow, 170

Document Preview, 49, 167

Documentation, 18, 37, 45, 78, 83, 108, 109, 110, 194

Event, 36, 37, 41, 42, 46, 47, 49, 50, 53, 63, 66, 67, 73, 82, 88, 104, 107, 117, 133, 134, 136, 138, 139, 145, 147, 150, 151, 153, 154, 156, 158, 160, 161, 162, 164, 165, 166

Extension, 16, 17, 18, 188

External Service, 81

F4 Help, 26, 40, 41, 42, 70, 97, 110, 111, 112, 113, 135, 195

Favorites, 57, 72, 117, 118, 136

Field Group, 26, 37, 38, 39, 40, 41, 43, 44, 45, 46, 54, 60, 70, 80, 82, 91, 97, 111, 112, 113, 119, 120, 136, 142, 155, 160, 165, 166, 185, 198

FILL_DROPDOWN_LISTBOX, 7, 56, 57, 70, 111

FILL_EVENTGROUP, 7, 50, 56, 67, 170

Form View, 25, 37, 39, 40, 41, 43, 44, 51, 102, 166, 172

GET_FIELDGROUP_VARIANT, 7, 54, 56, 57, 68

GET_MESSAGES, 7, 56, 57, 59, 67, 68, 104, 105, 107, 135, 153, 154, 158, 159, 161, 162, 184

GET_MY_FAVORITES, 7, 56, 57, 72, 117, 118

GET_PARENT_OBJECT_KEY, 57, 75, 105

GET_PRIORITY, 7, 62, 64, 178

GET_VARIANT, 7, 54, 56, 57, 68

GOS, 72, 117, 118

Guided Data Entry Pattern, 8, 68, 139, 140, 142, 143, 144, 145, 146, 147, 149, 150, 151, 152

Guidelines, 26, 89, 91, 99, 101

Hidden fields, 113

HTML, 15, 16, 17, 18, 37, 155, 163, 242

ICM, 12, 18, 93, 96

Initialize, 88, 156

Internet, 12, 15, 16, 18, 30, 141

IS_OBJECT_IN_CREATE_MODE, 7, 56, 73

iView, 28, 29, 80, 83, 112, 164, 165, 188, 209

JavaScript, 16, 19, 21, 30, 94, 108, 111

Knowledge Warehouse, 108, 109, 110

List View, 14, 24, 37, 39, 40, 41, 42, 43, 48, 50, 102, 138, 199

Locking, 31, 32, 33, 52, 53, 57, 60, 61, 134

Main Blueprint Table, 35, 37, 38, 42, 44, 45, 46, 47, 48, 50, 53, 82, 96, 108, 111, 135, 136, 153, 177, 197, 198

Mapping, 54, 58, 102, 112, 113, 193

Marketing, 193

Message, 59, 67, 68, 75, 76, 104, 105, 106, 107, 109, 110, 134, 138, 147, 149, 153, 154, 159, 160, 161, 229

Message Group, 106

Message Handling, 104

Metadata, 19, 35

MIME, 16, 94, 141, 201, 202

Model, 12, 13, 14, 15, 16, 19, 21, 22, 23, 24, 25, 32, 33, 38, 47, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 67, 69, 75, 76, 91, 97, 101, 104, 107, 117, 118, 121, 135, 136, 138, 142, 153, 155, 156, 158, 159, 160, 161, 162, 166, 167, 213

Model Access Class, 32, 33, 38, 49, 51, 52, 54, 55, 56, 57, 58, 66, 67, 68, 75, 91, 96, 97, 104, 107, 117, 118, 121, 135, 136, 138, 142, 149, 153, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 167, 170, 176, 185, 192, 213

Modification, 57, 188, 194

Modify, 45, 61, 88, 134, 139


MODIFY, 7, 32, 51, 54, 56, 57, 58, 59, 61, 62, 63, 64, 66, 88, 134, 137, 138, 152, 153, 155, 156, 162, 165, 166, 167, 181, 184

MVC, 6, 12, 13, 14, 16, 18, 21, 22, 23, 26

mySAP Business Suite, 9, 12

mySAP CRM, 6, 9, 118, 188, 213

Naming Convention, 53, 79, 96, 97, 109, 161, 168, 172, 188, 189

Navigation, 27, 28, 29, 30, 31, 41, 43, 49, 73, 75, 82, 94, 97, 102, 104, 105, 106, 107, 110, 112, 145, 147, 148, 172, 194

Object, 12, 18, 21, 23, 25, 28, 29, 30, 31, 32, 33, 41, 42, 43, 49, 51, 52, 53, 55, 56, 57, 58, 59, 60, 61, 64, 65, 66, 67, 69, 71, 72, 73, 76, 77, 78, 80, 81, 82, 83, 92, 94, 97, 101, 105, 106, 107, 108, 110, 111, 113, 117, 118, 119, 120, 121, 122, 133, 134, 135, 137, 138, 153, 155, 156, 157, 158, 159, 161, 162, 164, 165, 166, 188, 238

Object Creation, 29, 31, 61, 92, 165

Object ID, 59, 73, 76, 80, 82, 83, 118

Object Key, 58, 59, 60, 61, 62, 66, 67, 69, 71, 73, 75, 76, 107, 133, 134, 135, 137, 138, 139, 153, 155, 158, 161, 162, 165, 166, 217

Object Link, 28, 29, 30, 42, 43, 49, 78, 81, 82, 94, 97, 111, 166

Object Link Navigation, 28, 29, 42, 43, 82, 97

ODC, 120

ODP, 6, 7, 8, 14, 20, 21, 24, 25, 32, 47, 48, 49, 50, 52, 53, 66, 69, 92, 102, 107, 109, 117, 118, 119, 120, 121, 133, 134, 135, 136, 140, 145, 146, 152, 153, 155, 162, 165, 166

OIC, 169

OIP, 6, 8, 40, 42, 106, 107, 111, 133, 150, 151, 164

Pattern, 12, 20, 21, 22, 26, 101, 140, 198

People-Centric UI, 12, 14, 17, 18, 19, 20, 21, 27, 33, 34, 78, 87, 101, 108, 109, 110, 118, 121, 167, 188, 192

Performance, 18, 28, 40, 58, 61, 91, 92, 93, 94, 135

Performance Trace, 92

Personalization, 78, 188, 206, 208, 209

Popin, 37, 153, 154, 159, 160, 161, 175

Popup, 37, 41, 42, 49, 50, 67, 70, 71, 73, 111, 112, 113, 154, 161

Portal, 12, 21, 24, 27, 28, 29, 30, 31, 53, 78, 79, 80, 81, 82, 83, 112, 188, 194, 195, 209

Portal Menu Navigation, 29

Portal Page, 31, 81, 83, 195

PPF, 167

Printing, 49, 153, 163, 167, 169

PROCESS_EVENT, 7, 42, 49, 51, 56, 57, 63, 65, 66, 107, 117, 118, 122, 133, 134, 150, 156, 165, 166, 167, 170

Query, 46, 47, 59, 76, 83, 88, 111, 118, 164, 197

QUERY, 7, 32, 54, 56, 57, 58, 59, 60, 66, 75, 76, 77, 88, 197, 217

Read, 14, 39, 42, 54, 56, 58, 60, 87, 90, 91, 133, 134, 137, 139, 156, 159, 166, 183

READ, 7, 32, 33, 42, 54, 56, 57, 58, 59, 60, 64, 65, 66, 71, 75, 77, 89, 106, 122, 134, 136, 137, 138, 139, 152, 153, 155, 156, 158, 159, 162, 163, 165, 166, 167, 218, 254

READ_FOCUS_OBJECT, 7, 56, 57, 60, 61, 75

Reference Name, 53

Result List, 14, 20, 24, 25, 32, 36, 37, 48, 52, 53, 56, 57, 60, 67, 88, 102, 104, 111, 112, 117, 118, 119, 135, 136, 137, 138, 153, 156, 159, 161, 164, 165, 166, 172, 173, 184, 213

Role, 18, 22, 27, 53, 78, 79, 81, 82, 96, 194, 209

Rollback, 62, 63

ROLLBACK, 57

Runtime Analysis, 93

SAP Enterprise Portal, 9, 78, 194

SAP EP, 6, 27, 78, 80, 188, 194

SAP GUI, 15, 81, 109, 110, 111, 172, 193

SAP IMG, 21, 34

SAP NetWeaver, 90, 91, 117


SAP Web Application Server, 6, 12, 18, 32, 90, 157

SAP Web AS, 12, 15, 17, 18, 19, 20, 32, 33, 78, 83, 92, 95

Save, 63, 65, 110, 138, 143, 148, 155, 158, 229

SAVE, 7, 32, 33, 49, 62, 63, 64, 150

Screen Position, 37, 41, 46, 53, 104, 142, 153, 155, 160, 162, 195

Screen Structure, 32, 37, 38, 39, 40, 41, 44, 46, 52, 53, 54, 55, 57, 58, 59, 60, 61, 67, 69, 73, 80, 87, 88, 89, 91, 92, 96, 104, 105, 106, 107, 112, 119, 120, 135, 136, 137, 138, 142, 153, 155, 158, 159, 160, 162, 163, 164, 165, 168, 172, 188

Screen Variant, 54, 68

Search Area, 14, 20, 24, 25, 43, 46, 53, 58, 66, 104, 111, 112, 113, 164, 213

Search Group, 37, 46, 47, 96, 198

Send-Screen, 161, 162

Session Management, 28, 29, 30, 31, 49, 83

SET_SELECTED_PROCESS_ID, 7, 8, 56, 74, 144, 149, 151, 152

SET_URL_PARAMETER, 7, 56, 73

Shuffler, 46, 59, 74, 220, 221

Status Management, 118, 120, 121

Step Group, 8, 146

Structure Type, 138

Survey Tool, 37, 162

Tab, 30, 39, 40, 47, 48, 94, 102, 108, 109, 110, 119, 120, 143, 145, 147, 153, 155, 162, 169

Tabstrip, 17, 25, 26, 30, 36, 47, 91, 119, 149, 155, 157, 158, 162, 163, 164

Tabstrip Group, 54, 144, 149

Testing, 80

Text Management Tool, 155, 156

Text Replacement Tool, 197, 208

Toolbar, 17, 25, 26, 36, 47, 48, 49, 51, 52, 54, 66, 67, 69, 73, 80, 102, 117, 120, 122, 138, 154, 159, 160, 161, 162, 164, 165, 185

Toolbar Group, 48, 49, 52, 54, 120, 160, 161, 185

Training, 19, 22, 108

Transactional Methods, 61

Translation, 47, 208

UI Framework, 6, 15, 21, 22, 23, 24, 25, 26, 30, 32, 33, 54, 57, 60, 61, 78, 79, 91, 99, 104, 111, 118, 164, 167, 172, 197

URL, 24, 31, 32, 36, 41, 42, 43, 49, 53, 56, 73, 80, 82, 83, 87, 88, 93, 94, 108, 109, 111, 155, 163, 164, 166, 201

Usability, 22, 25, 45, 46, 101, 113, 154

Value Help, 70, 111, 204

View, 13, 14, 15, 16, 17, 18, 20, 21, 22, 23, 24, 25, 28, 29, 30, 33, 36, 37, 38, 39, 40, 41, 43, 44, 47, 48, 50, 51, 53, 54, 57, 63, 66, 78, 81, 82, 88, 93, 94, 96, 102, 104, 108, 133, 136, 138, 139, 140, 141, 142, 143, 145, 146, 151, 152, 153, 154, 155, 162, 166, 195, 197, 198, 199, 201

Viewset Selection Pattern, 8, 139, 140, 146, 152

Web, 12, 13, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 32, 33, 35, 78, 83, 92, 109, 110, 157, 188

Web Dynpro, 19, 20

Workbench, 18

Workset, 188, 194

XML, 17, 19, 162, 195, 199, 200, 202

pcui_book_50

Documents

sap logo

sap products

user interface patterns

sap earlywatch

sap netweaver

sap archivelink

user interface components

user interface design