cr590 bdt - business data toolset cr590 - busine… · sap ag 2002 cr590 bdt - business data...

SAP AG 2002

CR590 BDT - Business Data Toolset

CR590CR590BDT - BusinessData ToolsetBDT - BusinessData Toolset SAP AG 2002

2002/Q3

SAP BBPCRM / 300

Material number 5005 5126

SAP AG 2002

Copyright 2002 SAP AG. All rights reserved.

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

All rights reserved.

Copyright

Trademarks:

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®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

ORACLE® is a registered trademark of ORACLE Corporation.

INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.

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

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, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

SAP AG 2001

mySAP CRM 1 Col22

CR205

Mobile Sales &Mobile Service

3 Days

CR010

CRM Overview

2 Days

CR900

Analytical CRM

3 Days

CR400

Interaction Center inCRM

3 Days

CR600

Marketing Planning& CampaignManagement

3 Days

CR800

Internet Sales(ex ECO220)

5 Days

CR100

CRM Basics

3 Days

CR700

CRM Service

3 Days

SAP AG 2001

mySAP CRM 2 Col22

CR225

SAP IPCAdmin/Technology

2 Days

CR235

SAP IPC Pricing

2 Days

CR245

SAP IPC ProductConfiguration

2 Days

CR100

CRM Basics

3 Days

CR010

CRM Overview

2 Days

SAP AG 2001

mySAP CRM 3 Col22

CR540

CRM Middlewarefor Mobile Scenarios

2 DaysCR310

SAP MobileApplication StudioBasic Concepts

3 Days

22

CR590

BDT – Business DataToolset

2 Days

CR550

Enhancing the CRMMiddleware

3 Days

CR500

CRM MiddlewareOverview

2 Days

CR320

SAP MobileApplication StudioAdvanced Features

2 Days

CR010

CRM Overview

2 Days

SAP AG 2002

Course Prerequisites

Essential:good knowledge of ABAP programming

Recommended:experience with dialog programming

SAP AG 2002

Target Audience

ParticipantsTechnical consultants and developers who work with the BDT and

develop new functions and extensions within SAP or for development partners

Customers who extend existing BDT applications

Duration:2 days

User notes

The training materials are not teach-yourself programs. They complement the explanations provided by your course instructor. Space is provided on each page for you to note down additional information.

There may not be time during the course itself for you to complete all the exercises. The exercises provide additional examples that are covered during the course. You can also work through these examples - if you have time - to increase your understanding of the topics.

© SAP AG CR590 1-1

SAP AG 2002

Course Goals

Course Objectives

Course Content

Course Overview Diagram

Main Business Scenario

Contents:

Course Overview CR590

© SAP AG CR590 1-2

SAP AG 2002

This course will prepare you to:

Execute enhancements to the data model in the ABAP Dictionary online and for service programs, using the BDT. The course provides a solid base of dialog, program logic, and service program logic, and service program functions in the BDT.

Course Goals CR590

© SAP AG CR590 1-3

SAP AG 2002

At the conclusion of this course, you will be able to:

Describe the goals of the BDT.

Name differences to conventional dialog programming

Process extensions of a standard object using the

example of SAP Business Partner using the BDT

Describe functionality of BDT service programs

Course Objectives CR590

© SAP AG CR590 1-4

SAP AG 2002

Preface

Course Content CR590

Unit 1 Course Overview

Unit 2 Introduction to DTB

Unit 3 BDT Basics

Unit 4 Dialog

Unit 5 Program Logic

Unit 6 Extensions with Table-Participating Applications

Unit 7 Extensions with Table- Owning Applications

Unit 8 Service Programs and Functionality

Exercises

Solutions

Appendices

© SAP AG CR590 1-5

SAP AG 2002

Course Overview Diagram CR590

Extensions with Table-Participating Applications

Extensions with Table-Owning Applications

Service Programs and Functionality

Program Logic

Introduction to BDT

BDT Basics

Dialog

Course Overview

© SAP AG CR590 1-6

SAP AG 2002

Main Business Scenario CR590

The IT department in the IDES company is required to extend the standard object SAP Business Partner – developed with BDT – with specific attributes and functionality to provide an ideal business process for employees. This can entail: the configuration of screen layout and screen sequences, the development of program logic for the application, extension by way of additional fields, ...

© SAP AG CR590 2-1

SAP AG 2002

Contents:

Why the BDT?

Targets

Functionality

Introduction to the BDT

© SAP AG CR590 2-2

SAP AG 2002

At the conclusion of this unit, you will be able to:

Define the BDT and describe its history.

List design targets of the BDT.

Describe the functionality of the BDT.

Introduction: Unit Objectives

© SAP AG CR590 2-3

SAP AG 2002

Introduction: Overview Diagram




Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 2-4

SAP AG 2002

Your IT team has been requested to extend objects that have been developed in the BDT. They must become familiar with the BDT and its functions in order to be able to carry out the extensions.

Introduction: Business Scenario

© SAP AG CR590 2-5

SAP AG 2002

Definition:

Toolset for master data and simple transaction data

Business Data Toolset (BDT):

The BDT (Business Data Toolset) is a central control tool for maintaining master data and simple transaction data. In addition to dialog maintenance, the BDT also supports maintenance with direct input and/or function modules.

The BDT also provides generic object services for consistently recurring requirements such as the change to document lists, field groupings and the deletion program. The BDT controls these objects as well as generic parts thereof and calls the applications using predefined interfaces (control tables and events). The applications introduce application-specific enhancements, such as writing and reading database application tables. Note: The BDT is used at SAP for maintaining several application objects. Development partners and customers can also extend these application objects via the BDT interfaces, without having to make modifications. However, application objects belonging entirely to development partners and customers are not supported by the BDT technology since this does not concern a development tool of the ABAP Workbench.

The BDT resulted from the project 'Central Business Partner.' Besides many demands made by the business world of the data entry technology, those demands listed in the following slides had a high priority. Initially the necessary technology was developed in a common program with the application data for the Business Partner. It quickly became clear that not only the second part of this project - the BP relationship - made the same technical demands of the data maintenance, but that other application objects did as well. For this reason the project group Business Partner decided to separate the technical part of the application data and to make this technology available to other application objects as well. This technical part, which was for a long time called BP Control or Master Data Control, is now called the Business Data Toolset, or BDT for short.

© SAP AG CR590 2-6

SAP AG 2002

Design Targets

Extensibility

Configurability

Divisibility

Alternative user interfaces

Usability

Quicker development

Generic object services

Extensibility: modification-free extension of various dialog parts, for example screen layout, screen sequence, program logic, menu, field grouping, etc. via several layers.

Configurability: application developers (maintenance of the control tables of the BDT) or customers (Visual Configuration Tool) can adapt screen layout and screen sequence.

Divisibility: the maintenance of larger object parts can be split into smaller sections.

Alternative user interfaces: the interface and the program logic are separate in the BDT. The program logic of the application can be found entirely in the function modules. These are called at defined events. In this way the SAP GUI interface can be replaced by another interface.

Usability: besides the SAP Business Partner, other application objects can also take advantage of the BDT. Various application objects have the same design targets.

Quicker development: the dialog control is carried out via the BDT. The business functions are realized by the applications. In addition the BDT provides several services in which the applications can include themselves.

Generic object services: direct input, transfer mode, field control, etc.

© SAP AG CR590 2-7

SAP AG 2002

TablesAppend / Include Structures

Own Tables

Screen Layout and Screen Sequence

Program LogicEvent Techniques

Field Checks

Data Retention

Extensibility

The project group Business Partner defined the central attributes of a business partner (for example, name components, addresses and bank details). In addition to that, other applications have application-specific attributes. Development partners and customers needed to incorporate their own attributes into the maintenance. In the area of customer and vendor master data, you have to make a modification to do this. Because you can not collect and implement all these different attributes in one project group, maintenance for downstream enhancements has to be extensible without the need for modifications.

© SAP AG CR590 2-8

SAP AG 2002

CentralData

FI SD

MM

TR-TM

IS-IS

IS-BIS-U

DevtPartner1

DevtPartner2

Customer

Without modifications

Distributed development in various systems

Extensibility: Development Cycle

Several development groups are working with the same object. Based on the development of the central data in the SAP Basis (for example, Business Partner) there is standard and industry application development, as well as the additional development layers of the development partners and customers.

The BDT can support all the development cycles listed above, with regard to the extension of a BDT standard object.

© SAP AG CR590 2-9

SAP AG 2002

Configurability: Screen Layout

Street/numberPostcode/CityBAS

SD Delivery districtTransport zone

SAP BPPartnerForm of addr.

First nameLast name

Change Business Partner: Address

Partner TESTER

Name

Form of addr. 01

First name

Last name

John

Tester

Address

Street/number

Postcode/City

Ridge Road 11

99999

Delivery district

1122Transport zone

123456

Smithtown

Mid-sized customers in particular tend to suppress most of the standard SAP data fields. However, dialog maintenance becomes tedious when you go through screen after screen on which only one or two fields are relevant. Switching screens often slows down data entry considerably. As a result, SAP decided to make screens configurable so customers could tailor data entry screens to their individual needs and keep the number of screens to a minimum.

Note: BAS - Business Address Services (previously CAM - Central Address Management). All addresses are contained in the tables of the Business Address Services. In order to be able to access addresses later, the application saves only the key of an address in its application table.

© SAP AG CR590 2-10

SAP AG 2002

Configurability: Customizing Screen Layout /Sequence

Configuration via Drag&Drop (Visual Basic)

Screen layout and screen sequence

TechnologySubscreens

Generation of subscreen containers

The Visual Configuration Tool (VCT) allows configuration of the dialog.

This tool allows changes to screen layout to be carried out without modification and by Drag&Drop.

© SAP AG CR590 2-11

SAP AG 2002

Divisibility

Depending on business criteria, objects can be split into parts. These parts can be maintained individually.

ChoicesEach object can be maintained in one or several object parts. A business partner can assume different BP roles. A range of attributes is assigned to each BP role.

Each object can be created in just one object part.Each object is always created as one whole part, no divisibility is required.Example, a contract account is always maintained with all attributes.

If you were to count up all the attributes in the SAP System that are relevant for a business partner, you would have several hundred fields. Since it is impossible to include all these attributes in each type of maintenance, the maintenance itself must be divisible into parts where only those attributes are visible that are relevant in the current business context. These parts are called roles in the SAP Business Partner.

Object parts, like roles, narrow the view of the whole object.

© SAP AG CR590 2-12

SAP AG 2002

Example of Divisibility: BP Role

Borrower

Premium Payer

Policyholder

Contract

The example above shows that a business partner can have several BP roles (account holder, contract partner, borrower), depending on the business process in which he is involved.

The BP role determines which fields are displayed and which fields are changeable.

© SAP AG CR590 2-13

SAP AG 2001

SAP BP ApplObject

BUPA

BDTBDT

Others ...ApplObject

????

SAP BP- Relationships

ApplObject BUPR

Bank Account ApplObject

BKK

IS-REContract ApplObject

RECN

ContractAccount ApplObject

FICA

ClaimsCapture

ApplObject ICL

Usability with Any Object

These are some examples of objects that were developed using BDT. Central Business Partner

• Partner maintenance • Relationship maintenance Contract Accounts Receivable and Payable

• Contract account IBU Banking

• Bank account • Standing order • Financial product • Financial conditions • Risk object • Variable transactions IBU Insurance

• Insurance: Claims • Insurance: Loss event • Commissions: Remuneration agreements Real Estate

• Real estate contract • Cost efficiency analysis

© SAP AG CR590 2-14

SAP AG 2002

Development Without the BDT

ServiceService

ProcessingTransactions

FieldGrouping

ChangeDocument Evalutions

DataTransfer

NotesAuthori-zations

In a development project and also in an implementation project, you always need the same functionality. SAP Basis provides service functions, but most of the functions still have to be developed.

Examples are field grouping, change document evaluation and screen checking from the ABAP Dictionary.

© SAP AG CR590 2-15

SAP AG 2002

Quicker Development With the BDT

ServiceService

Processing TA Data Transfer

NotesAuthorizations

Fiel

d G

roup

ing

Change D

oc. Eval.

Central service Less development work Central service Less development work

Because the BDT takes control of dialog processes, the applications limit themselves to realizing business functions. The BDT also provides services in which the applications can be included. These factors provide significant reductions in the time needed to develop applications.

The applications loose a small part in individuality, but gain the advantage of less object maintenance, equality of dialogs, generic services and quicker development.

© SAP AG CR590 2-16

SAP AG 2002

Dialog MaintenanceConfiguration of Screen and Screen Sequence

Extension of Program Logic

Definition and Configuration of the Menu

Field Groups and Extensible Field Group Criteria

Search Help

Transfer Mode

External Interfaces

Authorization Checks

Notes

Change Documents (Planned)

Data Maintenance Functionality

Functions supported through dialog maintenance include:

• Field grouping: it is possible to extend existing field grouping criteria (like activity) by customer defined criteria.

• Search help: can be extended by customer-defined search fields

© SAP AG CR590 2-17

SAP AG 2002

Maintenance without a DialogDirect Input

Maintenance Using Function Modules

Change Documents

Archiving

Where-Used List

Screen Configuration using Drag&Drop (VCT)

Functionality

Additional functions:

• Different interfaces exist for data maintenance without a dialog. These interfaces are integrated and always use the same coding for the business logic.

• Archiving is connected to the BDT and is supported by it.

• Where-used list: this tool shows all other objects with their identification, in which the actual object is used. By a simple select, you can call up the relevant programs.

• Visual Configuration Tool (VCT): this tool makes a configuration possible by means of Drag&Drop. This tool, which is based on Visual Basic, simplifies the configuration process for the customer.

© SAP AG CR590 2-18

SAP AG 2002

You are now able to:

Define the BDT and describe its history.

List design targets of the BDT.

Describe the functionality of the BDT.

Introduction to the BDT: Unit Summary

© SAP AG CR590 3-1

SAP AG 2002

Contents:

System Architecture and Example Program with Selection Screen

BDT Programming

Positioning

Application Objects and Applications

Basis and the BDT

BDT Basics

© SAP AG CR590 3-2

SAP AG 2002


Describe in principle the architecture of the SAP System and the process of a simple dialog program via the ABAP runtime system

Differentiate between the BDT and conventional programming with user exits.

Position the BDT with regard to the SAP Basis and application objects

Define application objects and applications

Discuss the relationship between Basis and the BDT.

BDT Basics: Unit Objectives

© SAP AG CR590 3-3

SAP AG 2002

BDT Basics: Overview Diagram




Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 3-4

SAP AG 2002

Describe in principle the architecture of the SAP System and the process of a simple dialog program via the ABAP runtime system


Architecture and Dialog Program: Unit Objectives

© SAP AG CR590 3-5

SAP AG 2001

PresentationServerLayer

ApplicationServerLayer

database

Dispatcher

WorkProcess

SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI

WorkProcess

WorkProcess

WorkProcess

Dispatcher

WorkProcess

WorkProcess

WorkProcess

WorkProcess

Client / Server Architecture

The R/3 System has a modular software architecture that follows software-oriented client / server principles.

The R/3 System allocates presentation, applications, and data storage to different computers. This serves as the basis for the scalability of the R/3 system.

The lowest level is the database level. Here data is managed with the help of a relational database management system (RDBMS). In addition to master data and transaction data, programs and the metadata that describe the R/3 System are stored and managed here.

ABAP programs run at the application level, which includes both the applications provided by SAP and the ones you develop yourself. ABAP programs work with data called up from the database level. New data stores there as well.

The third level is the presentation level (SAPGUI). This level contains the user interface where an end user can access an application, enter new data, and receive the results of a work process.

The technical distribution of software is independent of its physical location on the hardware. Vertically, all levels can be installed on top of each other on one computer or each level on a separate computer. Horizontally, application and presentation level components can be divided among any number of computers. The horizontal distribution of database components, however, depends on the type of database installed.

© SAP AG CR590 3-6

SAP AG 2002

PresentationServerLayer

ApplicationServerLayer

Database

Work Process

ABAP Program

User-Oriented View

This graphic can be simplified for most topics discussed during this course. The interaction between ABAP programs and their users will be of primary interest to you during this course. The exact processes involved in user dispatching on an application server are secondary to understanding how to write an ABAP program. Therefore, you will work with a simplified graphic that does not explicitly show the dispatcher and the work process. Certain slides will, however, be enhanced to include these details whenever they are relevant to ABAP programming.

ABAP programs are processed on the application server. The design of the user dialogs and the database dialogs is therefore of particular importance when writing application programs.

© SAP AG CR590 3-7

SAP AG 2001

Selection ScreenSelection Screen

ListList

Bla

ck B

ox

ScreenScreen

Time

Program Flow: What the User Sees

The user is primarily interested in how his or her business transaction flows and in how data can be input into and displayed from the transaction. Technical details, such as whether a single program is running or multiple programs are called implicitly, or the technical differences between the kind of screens being displayed, are usually less important to the user. The user does not need to know the precise flow of the ABAP program on the application server. Users see the R/3 System with application servers and database as a black box.

There are, however, three technically distinct screen types (screens, selection screens, and lists) that offer the user different services. The developer's job is to determine which type of user dialog is most suitable to the user's needs.

© SAP AG CR590 3-8

SAP AG 2001

ProgramStart

ABAP Runtime System

ABAP Program

ABAPProcessingBlock

ABAPProcessingBlock

DatabaseTable

Time

Interaction Between Server Layers

When the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over from the presentation server to the application server and certain parts of the ABAP program are processed. If further user dialog is triggered within the ABAP program, the system sends a screen to the presentation server and control is once again handed over to the presentation server.

© SAP AG CR590 3-9

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System

ABAP ProgramProgramStart Repository

Screen

Time

Sample Program: Program Start

When the user starts the program, the program context is loaded first. This time, however, our sample program contains three processing blocks, a selection screen, a screen, and a variable and two structures as its data objects.

© SAP AG CR590 3-10

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System

ABAP ProgramProgramStart

Screen

Time

ABAP Runtime System Sends Screen

Since the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the beginning of program processing.

© SAP AG CR590 3-11

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System


Screen

Time

User Leaves Selection Screen

As soon as the user has finished entering data on the selection screen, he or she can trigger further processing by choosing Execute. All data input on the selection screen is then automatically placed in its corresponding data object in the program and the ABAP runtime system resumes control of processing. The runtime system then triggers sequential processing of the ABAP processing block that comes after the selection screen.

© SAP AG CR590 3-12

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System


Screen

Time

Program Requests Data Record from Database

The ABAP processing block contains a read access to the database that has been programmed into it. The program also passes the database information about which database table to access and which line in the table to read.

© SAP AG CR590 3-13

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System


Screen

Time

Database Returns Data Record

The database returns the requested data record to the program and the runtime system ensures that this data is stored in the appropriate data objects. Normally a structure is the target field when you access a single record. The structure contains variables for all fields requested from the database.

© SAP AG CR590 3-14

SAP AG 2001

Screen

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System

ABAP Program

ProcessBeforeOutput

ProgramStart

Time

Program Calls Screen

The ABAP processing block now triggers screen processing. This is often expressed simply by saying the program calls the screen. However, in reality, each screen possesses its own processing block that is sequentially processed before the runtime system sends the screen to the presentation server (Process Before Output). This allows screens to be used in a very flexible manner.

PBO contains coding that is fixed to the screen. Other interfaces have to call a screen in the background to get coding or development has to replicate the code.

© SAP AG CR590 3-15

SAP AG 2001

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System


Screen

Time

ProcessBeforeOutput

ABAP Runtime System Sends Selection Screen

After processing the screen's processing block, the ABAP runtime system sends the screen to the presentation server. During this process, data is transported into the screen's fields from a structure that serves as an interface for the screen.

© SAP AG CR590 3-16

SAP AG 2001

Screen

ProcessBeforeOutput

DatabaseTable

Data objects

ABAPProcessingBlock

ABAP Runtime System


Time

ProcessAfterInput

User Executes User Action

Once the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over to the runtime system on the application server again. The screen fields are transported into the structure that serves as the screen's interface and a special processing block belonging to the screen is triggered. This processing block is always processed immediately following a user action (Process After Input).

PAI contains coding that is fixed to the screen. Other interfaces have to call a screen in the background to get coding or development has to replicate the code. This is mainly important for checking logic.

© SAP AG CR590 3-17

SAP AG 2001

Screen

ProcessBeforeOutput

Data objects

ABAPProcessingBlock

ABAP Runtime System

ABAP Program

ProcessAfterInput

DatabaseTable

ProgramStart

Time

Processing of the ABAP Processing BlockResumes

After processing the Processing After Input block, the program continues at the the next ABAP statement after the screen was called.

© SAP AG CR590 3-18

SAP AG 2002

ABAP Program Flow ABAP Program Flow

Screen1000

Screen1000

Screen2000

Screen2000

Screen3000

Screen3000

PBOPBO PAIPAI PBOPBO PAIPAI PBOPBO PAIPAI

Customer ProgramsCustomer Programs

Start

ABAP Program Flow and User Exits

User ExitUser Exit

The program flow in conventional ABAP programs is mostly fixed without the possibility of changing the screen sequence. Only user exits support customer changes or enhancements.

© SAP AG CR590 3-19

SAP AG 2002

Function Module Exit: Flow Diagram

Application Program

Exit Function ModuleEXIT_<prog_name>_001

X Function Group

Include inInclude inCustomerCustomer

NamespaceNamespace

CALL CUSTOMER FUNCTION

This diagram represents the flow of a program that provides an extension in the form of a function module exit

The exit function module is called at a point in the source text that has been defined by an SAP application developer. Within the function module, the user can add functionality with the help of an include in the customer namespace.

© SAP AG CR590 3-20

SAP AG 2002

Function Module Exits

SAP Application Program

ABAPABAP

CALL CUSTOMER FUNCTION '001‘EXPORTING i_vars = gl_field.

***Global Data***DATA: gl_field...

X Function Group

ABAPABAP ScreensScreens

90009000

ENDFUNCTION.

FUNCTION exit_prg_001.*IMPORTING i_vars

INCLUDE ZXaaaU01INCLUDE ZXaaaU01..

*INCLUDE ZXaaaU01*INCLUDE ZXaaaU01

CALL SCREEN 9000.CALL SCREEN 9000.

<additional<additional processing logic>processing logic>

TextText element element

GUI interfaceGUI interface

91009100

You can extend an SAP application at pre-determined points through additional processing logic.

In the context of such an extension, you can also include your own screens with the relevant processing logic and GUI interface, and create customer text elements.

© SAP AG CR590 3-21

SAP AG 2002

Differentiate between the BDT and conventional programming.

At the conclusion of this topic, you will be able to:

BDT Programming: Topic Objectives

© SAP AG CR590 3-22

SAP AG 2002

FB

Overview of BDT Programming

SAP BPApplObj BUPASAP BPSAP BPApplObjApplObj BUPA BUPA

FM

FunctionGroup

FunctionGroup

Sub-screen

Sub-screen

CustomerApplicationCustomerCustomer

ApplicationApplication

"Jump" from a customer application into customer and application program logic from BDT-defined events

Application Program

Exit Function ModuleEXIT_<prog_name>_001

X Function Group

Include inInclude inCustomerCustomer

NamespaceNamespace

CALL CUSTOMER FUNCTION

The term 'application' is central to the BDT. Applications are, for example, central data of the Business Partner or central data of the Business Partner Relationships. An application can own one or more tables and also participate in the tables of other applications.

Each application is based technically on a function group in which its screens (including PBO and PAI), function modules and data structures are found.

The application's behavior is controlled by the BDT by means of events. The application can therefore offer function modules for various events. These function modules are called up by the BDT in dependence on the control tables.

© SAP AG CR590 3-23

SAP AG 2001

BDT

Fixed Program Logic

Control TablesEvents

ScreensStatus ...

SAP Basis

Visible Application

Initial screen

After Input

ISSTABeforeCall

Data screen

Before Output

After Input

ISDAT

ISDSTAUTH1

BeforeCall

Save Back Exit Cancel

XCHNG

Change ?

Yes

DSAVB

AUTH1

DCHCK

DTAKE

DSAVC

DSAVE

No

XCHNG

Change ? No

Save ?No

Yes

DSAVB

AUTH1

DCHCK

DTAKE

DSAVCDSAVE

Yes

A

Abbr.

A

XCHNG

Change ? No

Save ?No

Yes

DSAVB

AUTH1

DCHCK

DTAKE

DSAVCDSAVE

Yes

A

Abbr.

XCHNG

Change ? No

Cancel ?

No

Yes

Yes

A

DLVE1DLVE2

Start

End

DTITL

DCUAD DCUAC

FCODE

DTITL

DCUAD DCUAC

Screen 1: Events with Dialog, Save Mode

Call SubscreenCall Subscreen


Before Output

FCODE

Overview of BDT Program Logic

The program logic of the BDT us static (fixed). Events call dynamically customized Function Modules and Screens.

© SAP AG CR590 3-24

SAP AG 2002

Position the BDT with regard to the SAP Basis and application objects


Positioning: Topic Objectives

© SAP AG CR590 3-25

SAP AG 2001

Application Programs(programmed with BDT)

Application Programs(programmed with BDT)

BDTBDT

SAP Basis (DDIC,...)SAP Basis (DDIC,...)

Positioning

BDT, which is developed in ABAP, is a layer between the applications and the SAP Basis.

© SAP AG CR590 3-26

SAP AG 2001

DB_UPDATE Function Module

CheckFunction Module

WEBSAPGUI

DataRetention

Direct Input

Visual BasicJava

....

CHECK

Alternative User Interfaces

BDT is internal divided into several layers. One part is for data retention, one for checking purposes.

External interfaces are designed solely in external maintenance transactions (abbreviation: external maintenance). You define how data fields are distributed on the screens of this maintenance transaction. The only restriction is that fields belonging to one view always have to be put together on a data screen since there is a common function module for each view that is used to check data (event After input).

The function modules defined for the BDT events are used to read data from the database as well as to check the data and save it. External maintenance determines the current data prior to output using the function modules that read the data (see section 3.2.4).

External maintenance and BDT maintenance can be fully integrated. You can call BDT maintenance in transfer mode from external maintenance. Data can be changed in both types of maintenance. Changes are also visible in each type of maintenance. When making the transition from one kind of maintenance to the other, the data is flagged in the global memory of the application function groups.

The BDT provides varying function modules that are called in external maintenance (procedure described in detail in the next section). These modules in turn process one or more BDT events, which calls event modules in the applications.

Multiple BDT application objects can be maintained simultaneously in external maintenance.

Note: In order to work with external interfaces, you must adhere to the specifications given by the developer for the required actions in events. Correct reading and correct supply of the current and global memory in events ISDAT, DTAKE, DSAVC and DSAVE are particularly important.

© SAP AG CR590 3-27

SAP AG 2002

Define application objects and applications


Application Objects and Applications: TopicObjectives

© SAP AG CR590 3-28

SAP AG 2002

Each master or transaction data object that can be maintained with the BDT is an application object.

ExamplesBUPA SAP Business Partner

BKKA Bank Account

FICA Contract Accounts

Application Object

The values for application objects and differentiation types must be established centrally. This is the only way of avoiding objects with the same ID being created in the case of distributed development. This could potentially lead to entries overwriting each other.

© SAP AG CR590 3-29

SAP AG 2002

BDTBDTBDT

SAP Basis (DDIC, Development Environment, ABAP...)SAP Basis (DDIC, Development Environment, ABAP...)

Bank AccountBank Account((BKKABKKA))

SAP-SAP-BP BP RelationsRelations((BUPRBUPR))

SAP BPSAP BP((BUPABUPA))

Contract Contract AccountAccount((FICAFICA))

AdditionalAdditional............

Application Objects

Positioning of the Business Data Toolset (BDT)

The BDT (Business Data Toolset) is a central control tool for maintaining master data and simple transaction data.

The BDT is based on the ABAP Workbench, the Data Dictionary, etc.

The BDT was developed with ABAP and constitutes a layer between the SAP Basis and the applications. Since R/3 Release 4.0, the BDT is shipped in all core R/3 installations.

© SAP AG CR590 3-30

SAP AG 2002

Each application within an application object adds own elements such as tables, table fields or object parts.An application can be

SAP components (such as FI, SD, TR, IBU, NDA)

Development partners

Customers

Separate function group for each applicationDecouplingCommunication between the applications is conducted via GET or COLLECT function modules

Applications

Applications are always assigned to an application object.

User-specific function groups can be developed that are decoupled (independent) of applications.

Existing function groups cannot be modified.

© SAP AG CR590 3-31

SAP AG 2002

SAP BP ApplObj BUPASAP BP SAP BP ApplObjApplObj BUPA BUPA

Application Objects

Application

SAP-Application I

SAP-SAP-ApplicationApplication I I

CustomerApplicationCustomerCustomer


Sub-screenFBFuMo Sub-

screen

FunctionGroup

FunctionGroup

Sub-screenFBFuMo Sub-

screen

SAP BASIS

BDT

Application Objects and SAP Basis

FunctionGroup

FunctionGroup

An application object (for example, SAP BP object BUPA) is extensible for SAP applications, development partners, SAP Industry Business Solutions and customers.

All applications are assigned to exactly one application object.

Each application always has one or several own function groups. By using separate function groups in each application, the memory areas are encapsulated.

The function groups in the BDT are not customized. Only the content of the BDT, like screens and function modules, is maintained in the BDT control tables.

A function group includes all program objects of an application:

• Event function modules

- (Service) function modules (GET / COLLECT)

- Module (PBO / PAI)

- Subscreens

- Update task

- Digression: Function modules

- Functions are like subroutines (forms). They encapsulate code and data. Accessing data is allowed only via the function module interface.

- Function modules are executed via their name, which is unique in the SAP System.

- Function modules have a defined interface, which can be extended.

© SAP AG CR590 3-32

SAP AG 2002

Discuss the relationship between Basis and the BDT


Basis and the BDT: Topic Objectives

© SAP AG CR590 3-33

SAP AG 2002

Overview of Development with the BDT

ApplicationsApplications

SAPApplication I

SAPSAPApplication IApplication I

SAP Application II

SAPSAP Application IIApplication II

CustomerApplication 7

CustomerCustomerApplication 7Application 7

SAP BPSAP BP(BUPA)(BUPA)

DevelopmentDevelopment

DDIC Development Workbench BDT Control Tables

In table-participating applications, you have development areas Data Dictionary (DDIC), Development Workbench and the BDT control tables. The same development areas are also needed for developing the table-owning applications.

© SAP AG CR590 3-34

SAP AG 2002

BDT Development and the DevelopmentWorkbench

• 0010 First Contact

Screens PBO Module

PAI Module

• ...• PAI

• ...• PBO

Function Modules

Program Logic

Events for EachApplication

Events forTables

Events for EachView

FunctionGroups

FunctionGroups

......

..._..._PAIPAI_.._..

..._..._PBOPBO_.._..

..._..._PBCPBC_.._..

......

CollectCollect

GETGET

......

ISDSTISDST

ISDATISDAT

ISSTAISSTA

Each application develops in their own function group.

Screens (type subscreen), PBO and PAI modules and function modules for events (for each application, table and view) are created in the function group.

The PBO module calls only the service function module BUS_PBO for executing the field status.

The PAI module calls only the service function module BUS_PAI for getting the cursor position.

Program logic:

• Events for each application (read data, check data, save data)

• Events for tables (communication between applications / function groups)

• Events per view a. PBC Event for preparing tables (sorting, etc) b. PBO Event prior to data entry Reading of texts from Customizing tables, formatting of the date etc. c. PAI Event following data entry. Checking of the entry values. Conversion of the date

Note: The same coding is carried out in the maintenance mode without dialog (e.g. direct input). There is no redundant coding.

© SAP AG CR590 3-35

SAP AG 2002

BDT Development: DWB - Events for EachApplication

InitializationISSTAISSTA

ISDATISDAT

ISDSTISDST

FCODEFCODE

XCHNGXCHNG

DCHCKDCHCK

DSAVBDSAVB

DSAVCDSAVC

DSAVEDSAVE

DLVE1DLVE1

DLVE2DLVE2

DTAKEDTAKE

Read data from DB

Distribute data to participating application

Process own function code

Check whether data changed

Check data

Collect data from owning app.

Note data in global memory

Complete data (internal number)

Save data on DB

Initialize current memory

Initialize global memory

The BDT uses fixed events within the dialog flow. All applications are able to extend the object by their own program logic.

The BDT calls application-specific function modules dynamically.

The most important events are displayed in the above slide.

© SAP AG CR590 3-36

SAP AG 2002

BDT Development: DWB - Events for Each View

Change Business Partner

Partner TESTER

NameForm of addr. 01

First name John

Last name Tester

AddressStreet/number

Postcode/City 69121 Smithtown

ZZ_...Date of first contact

Rating of first contact

Create Subscreen with Screen Painter

Screen type: activate subscreen

Create layout

Flow logic

PBO module -> Call

PAI module -> Call

Events – Create function modules for each view

Create FM "before screen call"

Create FM "before output"

Create FB "after input"

BUS_PAIBUS_PAI

BUS_PBOBUS_PBO

Within a view all attributes are grouped together that are displayed and checked together. You can not separate fields by means of the Customizing. The fields are fixed on one screen. A view

is assigned to only one application. Other applications are not allowed to extend an existing standard view. An application has to use

own screens and BDT views. Create a View

• Create a screen in the DWB with screen type subscreen. • Create a PBO module in the flow logic that calls the function module BUS_PBO. • Create a PAI module in the flow logic that calls function module BUS_PAI. • Don't program any field checks. Field checks take place separately in function modules.

Otherwise checks are linked to the calling of a screen. For direct input, you have to create the same coding twice.

Create Events for each View (All events are optional, screens are called without any coding in the events of the view). • Create function module "before call"

This event is triggered by the BDT for all views of a screen when moving from one screen to another. Normally views with step-loop / table controls need a function module for sorting entries.

• Create function module "before output" This event is triggered before the subscreen is called by the BDT. Used for displaying and reading of explanatory text.

• Create function module "after input" This event is triggered after all the relevant subscreens are called in the PAI. Used for field checking for the view.

• Event DCHCK provides the possibility for checking several views.

© SAP AG CR590 3-37

SAP AG 2002

Existing tables can be extended byIncludes

Append structures

New tables can be created and integrated in the maintenance

For every table there is an owning application

there are several participating applications

Tables

Includes constitute a modification; only allowed for SAP applications.

There is a limit of 255 fields for each table. Due to this, it is recommended that table append structures used as extensions be kept to a maximum of 10 fields.

© SAP AG CR590 3-38

SAP AG 2002

BDT Development: Data Dictionary

Table ZZ_......

Table BUT000:

...

...

...

Append structureZZ_...ZZ_...

Development in the DDIC

...

...

...

...

...

ApplicationsApplicationsSAP

Application ISAPSAP

Application IApplication ISAP

Application IISAPSAP

Application IIApplication IICustomer

ApplicationCustomerCustomer


All applications of an application object can add own fields or tables.

• Existing tables can be extended by way of new table fields with the help of append structures. (Exception: SAP applications generally create their own tables).

• Completely new tables can be created and integrated in the dialog.

© SAP AG CR590 3-39

SAP AG 2002

BDT Basics: Unit Summary


Describe in principle the architecture of the SAP System and the process of a simple dialog program via the ABAP runtime systemDifferentiate between BDT programming and programming with user exits.Position the BDT with regard to the SAP Basis and application objectsDefine application objects and applicationsDiscuss the relationship between Basis and the BDT.

© SAP AG CR590 4-1

SAP AG 2002

Contents:

Views

Field Groups

Sections

Screens

Screen Sequences

BDT Screen Processing

GUI Menu

Dialog

© SAP AG CR590 4-2

SAP AG 2002


Differentiate between a view and ascreen.

List all attributes belonging to a view.

Explain the functions of field groups.

Explain the functions of screen sequences.

Describe the internal BDT processing for carrying out dialog screens.

Dialog: Unit Objectives

© SAP AG CR590 4-3

SAP AG 2002

Dialog: Overview Diagram




Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 4-4

SAP AG 2002

An employee requires a certain screen sequence and a certain screen layout for a business partner in the role "prospect".

Dialog: Business Scenario

© SAP AG CR590 4-5

SAP AG 2002

Extensions and changes to screens are possibleAdd other fields

in new frames

in existing frames

Assign fields differently, even between screens

Merge screens

No changes to development environment objectsof the BDT

of other applications

Targets for Screen Layout

Screen layout and sequence should be extended and configured using control tables (without the need for modification). Customers should adapt standard SAP screens to their needs with Drag&Drop in the Customizing. Using the Visual Configuration Tool (VCT), customers can change

• screen layout - or group several screens together

• screen sequence

• screen titles

• frame titles

© SAP AG CR590 4-6

SAP AG 2002

Screen->Section->View

Screen Sequence

AddressAddress Relationships Additional Partner Data

View 1

View 2Section 1

View 3

View 4 Section 2

View 5

View 6

View 7 Section 3

View 8

A screen contains one or more sections

A section contains one or more viewsA view is presented by a subscreen

The Dialog has a hierarchical structure.

Screen sequence (contains one or more screens)

Screens (contain one or more sections)

Sections (contain one or more views)

Views (contain one or more field groups)

Field groups (contains one or more screen fields)

All views correspond to one screen (type subscreen) in the DWB.

© SAP AG CR590 4-7

SAP AG 2002

A screen sequence contains one or more screens

Screen Layout: Screen Sequence ZF00

© SAP AG CR590 4-8

SAP AG 2002

A screen sequence contains one or more screensA screen contains one or more sections

Screen Layout: Screen(s)

© SAP AG CR590 4-9

SAP AG 2002


A view contains one or more field groups

Screen Layout: View(s)

© SAP AG CR590 4-10

SAP AG 2002



Screen Layout: Field Group(s)

© SAP AG CR590 4-11

SAP AG 2002

A screen sequence contains one or more screens

A screen contains one or more sections


Field groups contain one or more screen fields

Screen Layout: Table Field(s)

© SAP AG CR590 4-12

SAP AG 2002

View Definition

Properties are summarized in a view if theybelong together in terms of content

are tested together

The fields of a view are placed together in a subscreen (each view is assigned to a subscreen)A view belongs to an application

Assignment view --> field groups (field grouping)

Multiple use of views in object parts is possible (Example: BP roles)

During the use of object parts, the BDT offers the possibility of making different settings for screen layout and sequence for each object part.

A business process-specific dialog provides employees with the best support for their business processes.

© SAP AG CR590 4-13

SAP AG 2002

Event function modulesBefore output (PBO): Display explanatory texts, ...

After entry (PAI): Field checks, ...

Before screen call (PBC): Sort table, begin display with first entry

Only display view ifthe application of the view is active

the view is assigned to the object part/s to be maintained

Flow logic of the subscreenCall function module BUS_PBO in PBO (field grouping, messages)

Call function module BUS_PAI in PAI (determine cursor position)

View Attributes

Screen-specific coding is encapsulated in function modules. This coding can now be carried out without calling the screen.

In the actual subscreen logic, only service function modules of the BDT (BUS_PBO, BUS_PAI) are called.

All subscreen checks have to be switched off.

© SAP AG CR590 4-14

SAP AG 2002

Owning application of the viewCarries out checks in a function module

Defines the name of the function module in the attributes for the view

All other applicationsCarry out checks in a function module

Add the name of the function module under 'further checks'

Important note:All error messages are issued via the message handler (function module BUS_MESSAGE_STORE)

Additional View Checks

Existing views can not be changed in event PAI. All changes in the Customizing of the SAP System are modifications.

Other applications are able to define input checks by creating "additional checks" and customizing the view.

You have to issue all messages via the message handler. The message handler is used for all modes, as well as for direct input.

© SAP AG CR590 4-15

SAP AG 2002

Assignment section --> views

Sequence of views by way of position numbers

Frame around a section (exception: header data)

Frame title for each section

Section

Position numbers are for SAP, SAP IBS, development partners and customers. You can find namespace descriptions in the BDT manual.

© SAP AG CR590 4-16

SAP AG 2002

Assignment Screen --> Sections

Sequence of sections by means of item numbers

Representation asnormal screen (full screen)

modal dialog box (pop-up)

Screen title for each screen

External screens (not created with the BDT)

Screen

So-called subscreen containers are generated automatically

In a new system, you may have to generate all screens. Tools -> generate subscreen containers.

© SAP AG CR590 4-17

SAP AG 2001

Empty screen container for screen B1Change Business Partner:

Procedure - Step 1

© SAP AG CR590 4-18

SAP AG 2001

Change Business Partner: AddressEmpty screen container for screen B1

Include screen title in screencontainer title

Procedure - Step 2

© SAP AG CR590 4-19

SAP AG 2001

Partner TESTEREmpty screen container for screen B1


Fill 1st view for 1st section


Procedure - Step 3

© SAP AG CR590 4-20

SAP AG 2001

Name

Empty screen container for screen B1



Present title of 2nd section

Partner TESTER


Procedure - Step 4

© SAP AG CR590 4-21

SAP AG 2001

Form of addr. 01





Fill 1st view for 2nd section

Partner TESTER


Name

Procedure - Step 5

© SAP AG CR590 4-22

SAP AG 2001

Form of addr. 01

First nameLast name

OttoTester






Fill 2nd view for 2nd section

Partner TESTER


Name

Procedure - Step 6

© SAP AG CR590 4-23

SAP AG 2001

Address

Form of addr. 01

First nameLast name

JohnTester







Present title of 3rd section

Partner TESTER


Name

Procedure - Step 7

© SAP AG CR590 4-24

SAP AG 2001

Address

Form of addr. 01

First nameLast name

JohnTester

Street/numberPostcode/City

Ridge Rd 11299999 Smithtown








Fill 1st view for 3rd section

Partner TESTER


Name

Procedure - Step 8

© SAP AG CR590 4-25

SAP AG 2001

Form of addr. 01First nameLast name

JohnTester

Street/number Ridge Road 1120

Name

Address

Postcode/City 99999 Smithtown








Fill 1st view for 3rd section

Compress screen


Partner TESTER

Procedure - Step 9

BDT automatically compresses the screen. Dialog surface without fields is suppressed.

© SAP AG CR590 4-26

SAP AG 2002

Screen sequences at any level

Individual additional screens

Extend screen sequences to include new screens

Integrate screens not created with the BDT

Change sequence of screens within a screen sequence

Navigation between screen sequences / screens with the BDT

Tabstrips

Divisibility: best possible screen sequence for each object part

Targets for Screen Sequences

© SAP AG CR590 4-27

SAP AG 2002

Overview

Initial ScreenInitial Screen AddressAddressENTER

NextScreen

PreviousScreen

DeletionFlags

DeletionFlags

OtherData

Back

Main Screen Seq.

LockLockNextScreen

PreviousScreen

Additional Screen Sequence Address Overview

ControlControlNextScreen

PreviousScreen

......

The starting point is always the main screen sequence category (customized as SPACE).

One or more screen sequences are assigned to a screen sequence category. You then assign the specific screen sequence to an object part.

From the main screen sequence, you can move via the dialog to each screen sequence category supported by the dialog.

© SAP AG CR590 4-28

SAP AG 2002

Screen sequence categoryLevels at which a screen sequence is required

Assignment screen sequence category --> screen sequences

Screen SequenceSequence of screens through item numbers

Main screen sequence: assignment object part --> screen sequence

Standard screen sequence

Any screens possible

BDT screens

External screens (by calling a function module)

Definition

Business Partner and Relationships is an example of BDT screens that appear within another application object.

The Business Document Navigator (BDN) in the application object Business Partner is an example of an integrated, external screen.

© SAP AG CR590 4-29

SAP AG 2002

Jump from a screen of another screen sequence

Implementation: alternativesDefine the screen sequence category when defining the GUI function

Call function module BUS_SCREEN_CALL in event FCODE

Navigation optionsMenu (edit, extras, environment)

Freely positionable pushbuttons

Other Screen Sequences

Screen sequences are flexible and can be called by the function module BUS_SCREEN_CALL.

© SAP AG CR590 4-30

SAP AG 2002

Own menu with standard functions for each application object

Add additional functions

Activate / deactivate functionsper activity

per view

per screen sequence category

on the basis of additional program logic

Link menu function <--> freely positionable pushbutton

Extensions to the GUI menu without changes to development environment objects

of the BDT


Targets for the GUI Menu

© SAP AG CR590 4-31

SAP AG 2002

Standard Functions

Contained in the standard menu

Activate / deactivate in system tablesper activity

per activity / view

per activity / view / screen sequence category

Lowest priority

Highest priority

The BDT separates standard functions and additional functions.

Standard functions are contained in the standard menu. The system tables activate and deactivate visible functions in the GUI menu.

The visible GUI menu functions are controlled by the dialog activity, the activity, and the view or activity actually displayed, as well as the actual screen sequence category.

© SAP AG CR590 4-32

SAP AG 2002

Can be included in the standard menu via the option "additional functions" Displayed in an additional popup

Activate / deactivate in system tablesper activity

per activity / view

per activity / view / screen sequence category

Additional Functions

Lowest priority

Highest priority

Additional functions represented in an additional dialog box.

© SAP AG CR590 4-33

SAP AG 2002

Example - "Save" Function

Display Partner: Address

Screen 1

Change Partner: Address Create Partner: Address

Screen 1 Save

View

View

View

Section

Screen 1 Save

Display Mode-

Save Buttonnot active

Create Mode-

Save Buttonactive

Change Mode-

Save Buttonactive

View

View

View

Section

View

View

View

Section

Save

Examples of the Customizing of different functions in the menu.

• The function "save" is only active in create and change mode.

• The activity mode is the only criterion.

© SAP AG CR590 4-34

SAP AG 2002

Example: "Delete Bank Details" Function

Display Partner: Address

View

View

View

Section

Screen 1

Display Partner: Payment Create Partner: Payment

Screen 1 Screen 1

Display mode-

Delete button not active

Create/change mode andbank details visible

-Delete button active

Display mode andbank details visible

-Delete button not active

Section

Delete

Section

Delete

View bank detailsView bank details


• The function "delete bank details" is only active if you are in create / change mode and the view "bank details" is displayed.

© SAP AG CR590 4-35

SAP AG 2002

Example: “Address Overview” Function

Display Partner: Payment Change Partner: Control Create Partner: Address

Section

Screen 1

View

View

View

Section

Screen 1

Display Address

View

View

Section

Screen 1Address overviewAddress overview

Section

Display bank details

Address overview

Create/change/display mode

Address 0verview buttonnot visible

Create/change/display modeAddress overview visible and

Main screen seq.

Address overview buttonactive

Create/change/display mode

Main screen seq.

Address overview buttonnot visible

Main screen seq. Main screen seq.Main screen seq.


• The function "address overview" is only visible in create / change / display mode, the view "address data" is visible and you are in the main screen sequence.

© SAP AG CR590 4-36

SAP AG 2002

DCUAD (Determine GUI status)The standard menu with GUI status is in the application function group of the application that owns the application objectThe application can set the required GUI status

DCUAC (Change GUI status)Programmed activation / deactivation of GUI functions

The function "delete bank" is inactive if field group "bank details" is hidden or is only displayedScroll functions are only active with a large number of entries

Events

The menu is determined in events DCUAD and DCUAC. Menu options can also be set to active or inactive here if the rule that applies to this function cannot be represented using the settings in the Customizing table.

Event DCUAD (Customizing of the menu) Description:The application determines the GUI status and sends it to the BDT. The BDT also receives the name of the function module that sets the GUI status (command SET PFSTATUS...). This function module must be included in the function group of the application that owns the application object. The naming convention for this function module is <Application>_<Application object>_PFSTATUS_SET. Application area: Application that owns the application object. Naming convention: <Application>_<Application object>_EVENT_DCUAD (Customer: Function module name also has the prefix Y_ or Z_). Example: BUP_BUPA_EVENT_DCUAD Action required:

• Determine GUI status for the screen and send it to the BDT.

• Send the name of the function module for setting the GUI status to the BDT.

Event DCUAC (changing the menu) Description:Menu options may be set to active or inactive at runtime. This is done here for the menu options whose active / inactive rule cannot be fully represented in the Customizing tables. Application area: All applications. Naming convention: <Application>_<Application object>_EVENT_DCUAD (Customer: Function module name also has the prefix Y_ or Z_). Example: BUP_BUPA_EVENT_DCUAC Action required:

• Determine current GUI status with the function module BUS_CUA_STATUS_GET

• Include inactive standard functions or active additional functions in the relevant tables

• Return current GUI status to the Customizing with the function module BUS_CUA_STATUS_SET

© SAP AG CR590 4-37

SAP AG 2002

Dialog: Unit Summary


Differentiate between a view and a screenList all attributes belonging to a viewExplain the functions of field groupsIdentify the differences between BDT screens and DWB screensExplain the functions of screen sequencesDescribe the internal BDT processing for carrying out dialogsExplain the functions and different Customizing possibilities of GUI menus

© SAP AG CR590 4-38

Exercises

Unit: Dialog Topic: Dialog Maintenance

At the conclusion of this exercise, you will be able to:

• Change screen sequence and the order of sections and views for an application object in the BDT.

The processor maintains credit card data and bank details for prospects. To improve the business process, the application consultant has to integrate the views of credit card details and bank details and to provide both with a frame.

Navigate to the Easy Access Menu:

/n → Enter → /nbupt – Use the area menu and not the Easy Access Tree.

Replace all ## with your group number.

For example: Group number 11

ZF## = ZF11

1-1 Preparatory steps to avoid changes to the SAP Standard Customizing.

BP control → Screen Sequence

1-1-1 Copy the screen sequence BUP001 to ZF##. In mySAP CRM, you would use the screen sequence „BUP001“ and in SAP R/3 the screen sequence „BUP1“ by default as the template. Replace the last two positions 00 of the position number with 10. You are now in the customer namespace.

1-1-2 Assign the main screen sequence category BUP001 to the screen sequence ZF##.

In SAP R/3:Assign the main screen sequence <SPACE> to the screen sequence ZF##. Do not set the radio button to „Standard“.

© SAP AG CR590 4-39

1-1-3 Create a new object part.

An object part is a restricted view of the whole object. The name for an object part in the SAP Business Partner is role. The development of an application object decides whether divisibility, and therefore object parts, is used or not.

BP Control → Divisibility → BP Roles.

Copy from Prospect role.

Parameter Value

Copy ZCXX10

Role ZC##10

Description ZC##: Prospect

Title ZC##: Prospect

Screen Sequence ZF##

Differentiation type 0

Screen selection not specified

Valid Business Partner categories Organization

Person

Group

1-1-4 Check that the screen sequence in role ZC##10 has been changed.

© SAP AG CR590 4-40

1-2 Changes to the screen layout for bank details and credit cards.

1-2-1 Create a new section.

A section groups a number of views. The sequence is established through position numbers and a line is drawn around these.

BP Control → Screen Layout → Sections

Section ZA##00

Description Bank and Credit Cards ##

Title Bank and Credit Cards ##

1-2-2 Assign the views to the section.

Position number 1000010

View BUP600


View BUP500

1-2-3 Create a screen and assign the view to the section.

A screen includes one or more sections and represents one tab page in the dialog. The position numbers in the screen sequence control the sequence of screens.

BP Control → Screen Layout → Screens

Screen ZB##00

Description Bank and Credit Cards ##

Title Bank and Credit Cards ##

Data screen X

BDT X

Screen type normal

1-2-4 Assign screen to sections.


Section BUP009


Section ZA##00

© SAP AG CR590 4-41

1-2-5 Assign the screen to the screen sequence.

BP Control → Screen Sequence → Define Sequence



Screen ZB##00

1-2-6 Delete screen BUP500 from screen sequence ZF##.

1-2-7 Check the result in your object part (BP role) ZC##10.

mySAP CRM:GoTo Menu → (BP) SAP Menu → Master Data → Business Partner → Maintain Business Partner

SAP R/3:Application → Business Partner → Create

© SAP AG CR590 5-1

SAP AG 2002

Contents:

Program Flow

Events

Table-Participating Applications

Table-Owning Applications

Current and Global Memory

Program Logic

© SAP AG CR590 5-2

SAP AG 2002


Trace the processing flow of the BDT program flow

Name events and their function in the BDT

Describe the processing of table-participating applications

Describe the processing of table-owning applications and the differences with regard to table-participating applications

Differentiate between the current and global memory and their tasks

Program Logic: Unit Objectives

© SAP AG CR590 5-3

SAP AG 2002

Program Logic: Overview Diagram




Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 5-4

SAP AG 2002

Use program logic forDialog maintenance via the standard user interface

Dialog maintenance via an external user interface (in R/3 or a non-R/3 system)

Maintenance without dialog (direct input or function modules)

Decouple program logic from the user interfaceForeign key checks not at the user interface

Data category checks not at the user interface

Extensions without changes to development environment objects

of the BDT


Targets

© SAP AG CR590 5-5

SAP AG 2002

CommunicationBetween the BDT and applications

Between applications

Defined EventsWithin the maintenance dialog

With different object services

Assignment Event --> Event Function ModulesDefine name in control tables

Dynamic call via BDT

Sequence of event function modules by way of position numbers

Event Techniques

Within the dialog flow, events defined by the BDT are used, for which the applications can develop a separate program logic in the form of function modules. The function modules can be defined for each event; then the BDT automatically calls up these modules.

Position numbers have separate namespaces for SAP, SAP-IBS, development partner and customers.

© SAP AG CR590 5-6

SAP AG 2002

Program EventsTable

Check

BDT processing

Views

Event Table

Field Status

Field Grouping Criteria

Event Areas

The BDT can be divided into different areas with regard to the events.

The events for tables serve the purposes of direct input, the communication between applications, and the evaluation of change documents.

Views have events for PBC (Process Before Call), PAI and PBO.

Program events

• Table events are for read- and save-processing (for example, ISDAT, DSAVE)

• The check is for business check and data integration checks (for example, DCHCK).

• The BDT processing contains events for the BDT program flow (for example, XCHNG, DTAKE).

The event field status changes the status of the field group during BDT processing.

The event field grouping criteria allows you to adapt different field grouping statuses for each criterion.

© SAP AG CR590 5-7

SAP AG 2002

ISSTA Initialization

ISDAT Read data from DB

ISDST Distribute data to participating applications

FCODE Process own function code

XCHNG Check to see if data has been changed

DCHCK Check before saving

DSAVB Collect data at owning application

DTAKE Note data in global memory

DSAVC Complete data (get internal number)

DSAVE Save data in DB

Event Table

© SAP AG CR590 5-8

SAP AG 2002

Before Call (PBC)Begin with the first data record (table control)

Sort data records (table control)

Before Output (PBO)Read tables for explanatory texts

After Entry (PAI)Field checks

Views

Views encapsulate their coding in function modules. These function modules are called both in the dialog and in the direct input mode.

© SAP AG CR590 5-9

SAP AG 2002

Initial Screen

After entry

ISSTABeforeCall

Data Screen

Before output

After entry

ISDATISDST

AUTH1BeforeCall

Save Back Exit Cancel

XCHNG

Change ?

Yes

DSAVBAUTH1DCHCKDTAKEDSAVCDSAVE

No

XCHNG

Change ? No

Save ? No

Yes

DSAVB

AUTH1DCHCKDTAKEDSAVCDSAVE

Yes

A

Cancel.

A

XCHNG

Change ? No

Save ? No

Yes

DSAVB

AUTH1DCHCKDTAKEDSAVCDSAVE

Yes

A

Cancel.

XCHNG

Change ? No

Cancel ?

No

Yes

Yes

A

DLVE1DLVE2

Start

End

DTITL

DCUAD DCUAC

FCODE

DTITLDCUAD DCUAC

Events at the dialog: save mode



Before output

FCODE

Events, Flow

A normal transaction code is the starting point. The transaction code always carries out the same program (in BP BUSSTART). The BDT reads all the necessary information in the control tables together with the name of transaction code.

The program flow has a fixed definition. All function modules belonging to the object part that has been carried out are called dynamically in the relevant events.

© SAP AG CR590 5-10

SAP AG 2002

Communication Between the Applications

Distribute Data (Event ISDAT or ISDST)Data from an owning application to a participating application

Creator: owning application

Table BUT000: BUP_BUPA_BUT000_GET

Collect Data (Event DSAVB)Data from a participating application to an owning application

Creator: owning application

Table BUT000: BUP_BUPA_BUT000_GET

Tables (Service Function Modules)

Each table-owning application can provide data to its current tables, which is encapsulated in its function module. This data can also be provided via communication interfaces to other applications.

Without this interface, a table-participating application is not able to receive the data that it has to process.

© SAP AG CR590 5-11

SAP AG 2002

Example A (Initial Situation)

Applications: SAP BPFinancial Service BP Customer

Tables: Table BUT000:Owner: SAP BP

Key fields

INCLUDE for SAP BP

APPEND for FS BP

APPEND for CustomerZZCNT_FIRST

ZZCNT_FIRST

Table-participatingapplications

Example – initial situation:

Three applications: SAP BP, Financial Service, Customer

• SAP BP: Table-owning application (BUT000)

• Financial Service BP: Table-participating application (append BUT000)

• Customer: Table-participating application (append BUT000)

© SAP AG CR590 5-12

SAP AG 2002

Example A - Read Data 01

SAP BPFinancial Service BP Customer

Applications:

Event ISDAT(Read data)Event ISDAT(Read data)

The BDT carries out all necessary function modules in event ISDAT.

© SAP AG CR590 5-13

SAP AG 2002



Event ISDAT(Read data)

Read BUT000Read BUT000

The function module of application SAP BP reads BUT000.

© SAP AG CR590 5-14

SAP AG 2002


BUT000



Read BUT000

Data is stored in the internal structure BUT000.

© SAP AG CR590 5-15

SAP AG 2002




Event ISDST(Distribute data)Event ISDST(Distribute data)

Read BUT000 BUT000

Event ISDST carries out all function modules for distributing data from table-owning to table-participating applications.

© SAP AG CR590 5-16

SAP AG 2002


Event ISDST(Distribute data)



Read BUT000

Get BUT000Get BUT000

BUT000

BUT000

The function module of the application Financial Service BP is called.

© SAP AG CR590 5-17

SAP AG 2002





ServiceFunction Modules

Read BUT000

Get BUT000

BUT000

BUT000

The application Financial Service BP calls the data from BUT000 via the call of the service function module.

© SAP AG CR590 5-18

SAP AG 2002





Read BUT000


Get BUT000 BUT000BUT000

BUT000

BUT000

The data from BUT000 including the append data is stored in the function module of the Financial Service BP application.

© SAP AG CR590 5-19

SAP AG 2002







Read BUT000

Get BUT000

BUT000

BUT000

BUT000

The function module of the customer application is called.

© SAP AG CR590 5-20

SAP AG 2002




Read BUT000

Get BUT000



Get BUT000 BUT000

BUT000BUT000

BUT000

BUT000

The customer application calls the data from BUT000 via the call of the service function module.

© SAP AG CR590 5-21

SAP AG 2002


Get BUT000


Read BUT000


BUT000


Get BUT000


BUT000

BUT000

BUT000

The data from BUT000 including the append data is stored in the function group of the customer application.

© SAP AG CR590 5-22

SAP AG 2002

Example A - Save Data 01


Event DSAVB(Collect data)Event DSAVB(Collect data)

Starting point for saving data.

The BDT dynamically calls function modules of the event DSAVB.

The event serves the purpose of collecting data from table-participating to table-owning applications in order to store data in the database.

© SAP AG CR590 5-23

SAP AG 2002




Event DSAVB (Collect data)

Transfer BUT000

BUT000

BUT000

BUT000

The application Financial Service BP transfers data from the append structure to the application SAP BP.

The application Financial Service BP calls service function module Collect from BUT000.

© SAP AG CR590 5-24

SAP AG 2002




Transfer BUT000

BUT000

BUT000

BUT000


Only data of the Financial Service BP table append is transferred to the BUT000 structure in the application SAP BP.

© SAP AG CR590 5-25

SAP AG 2002


BUT000



Transfer BUT000

BUT000

BUT000

Transfer BUT000


The customer application calls the service function module Collect from BUT000.

© SAP AG CR590 5-26

SAP AG 2002





BUT000

Transfer BUT000

BUT000

BUT000

Transfer BUT000

Only data of the table append of the customer application is transferred to the BUT000 structure in the application SAP BP.

© SAP AG CR590 5-27

SAP AG 2002





BUT000

Transfer BUT000

BUT000

BUT000

Transfer BUT000

Event DTAKE(Transfer data)Event DTAKE(Transfer data)

The BDT carries out all necessary function modules for the event DTAKE.

DTAKE moves all data from current memory to the global memory.

© SAP AG CR590 5-28

SAP AG 2002





BUT000

Transfer BUT000

BUT000

BUT000

Transfer BUT000

BUT000 in Global MemoryBUT000 in Global MemoryEvent DTAKE(Transfer data)

The event DTAKE is available only for table-owning applications.

The application SAP BP moves the current memory to the global memory. This process also includes data from the append structures for the table in BUT000.

© SAP AG CR590 5-29

SAP AG 2002





BUT000

Transfer BUT000

BUT000

BUT000

Transfer BUT000

BUT000 in Global MemoryEvent DTAKE(Transfer data)

FIBUB1

Event DSAVE(Save data)Event DSAVE(Save data)

All the necessary function modules in event DSAVE are carried out.

The event DSAVE is available only to table-owning applications.

© SAP AG CR590 5-30

SAP AG 2002





BUT000

Transfer BUT000

BUT000

BUT000

Transfer BUT000

BUT000 in Global MemoryEvent DTAKE(Transfer data)

BUT000 in DBBUT000 in DBEvent DSAVE(Save data)

The application SAP BP saves the structure BUT000 in the database, including the table append data.

© SAP AG CR590 5-31

SAP AG 2002

Table FSBUB1Owner: FS BP

Key Fields

INCLUDE for FS BP

Applications: SAP BPFinancial Service BP

Tables: Table BUT000:Owner: SAP BP

Key Fields

INCLUDE for SAP BP

Example B (Initial Situation)

Example – initial situation:

Three applications: SAP BP, Financial Service BP, Customer

• SAP BP: Table-owning application (BUT000)

• Financial Service BP : Table-owning application (FSBUB1)

© SAP AG CR590 5-32

SAP AG 2002

Event ISDAT(Read data)Event ISDAT(Read data)

SAP BPFinancial Service BP

Applications:

Example B - Read Data 01

The BDT carries out all necessary function modules in event ISDAT.

© SAP AG CR590 5-33

SAP AG 2002

Read BUT000Read BUT000




The function module of application SAP BP reads BUT000.

© SAP AG CR590 5-34

SAP AG 2002

BUT000



Read BUT000


Data is stored in the internal structure BUT000.

© SAP AG CR590 5-35

SAP AG 2002




Read BUT000 BUT000


The application Financial Service BP needs the data from BUT000 for reading its own table. (The partner number is the search parameter.)

© SAP AG CR590 5-36

SAP AG 2002

GET / ServiceFunction Modules



Read BUT000 BUT000


Get BUT000

For the purpose of reading data, Financial Service BP calls the GET function module of table BUT000.

© SAP AG CR590 5-37

SAP AG 2002




Read BUT000 BUT000


Get BUT000 BUT000BUT000

FS BP saves data in an own structure.

© SAP AG CR590 5-38

SAP AG 2002



Read BUT000 BUT000



Get BUT000Read FSBUB1Read FSBUB1 BUT000

The application FS BP reads its own table FSBUB1 with the partner number of the structure BUT000.

© SAP AG CR590 5-39

SAP AG 2002



Read BUT000 BUT000



Get BUT000Read FSBUB1 FSBUB1FSBUB1BUT000

Data is saved in the internal structure FSBUB1.

© SAP AG CR590 5-40

SAP AG 2002

Event ISDST(Distribute data)Event ISDST(Distribute data)

Get BUT000Read FSBUB1



Read BUT000 BUT000

FSBUB1BUT000



The event ISDST carries out all function modules for distributing data from table-owning to table-participating applications.

© SAP AG CR590 5-41

SAP AG 2002

BUT000


Get BUT000Read FSBUB1

Read BUT000 BUT000


FSBUB1BUT000

FSBUB1BUT000




Data from FSBUB1 is stored in the internal table.

Once the read process is complete, all applications display and check their own datasets.

Complete external publication of the application tables takes place on the basis of the table structure. Data can be changed only in the append structure of the customized table.

© SAP AG CR590 5-42

SAP AG 2002


Example B - Save Data 01

Event DSAVB (Collect data)Event DSAVB (Collect data)

Starting point for saving data.

The BDT dynamically calls function modules of the event DSAVB.

The event is for collecting data from table-participating to table-owning applications in order to store data in the database.

© SAP AG CR590 5-43

SAP AG 2002





BUT000

BUT000 FSBUB1Transfer BUT000

© SAP AG CR590 5-44

SAP AG 2002





BUT000


Event DTAKE(Transfer data)Event DTAKE(Transfer data)

The BDT carries out all necessary function modules for the event DTAKE.

DTAKE moves all data from the current memory to the global memory.

© SAP AG CR590 5-45

SAP AG 2002





Event DTAKE(Transfer data)

BUT000


BUT000 in Global MemoryBUT000 in Global Memory

The event DTAKE is available only for table-owning application.

The application SAP BP moves the current memory to the global memory. This process also includes data from the append structures for the table in BUT000.

© SAP AG CR590 5-46

SAP AG 2002





BUT000


BUT000 in Global MemoryEvent DTAKE(Transfer data) FSBUB1 in Global MemoryFSBUB1 in Global Memory

The application FS BP moves the current memory from FSBUB1 to the global memory.

© SAP AG CR590 5-47

SAP AG 2002





Event DSAVE(Save data)Event DSAVE(Save data)

BUT000



BUT000 in Global Memory

FSBUB1 in Global Memory

All the necessary function modules in event DSAVE are carried out.

The event DSAVE is available only to table-owning applications.

© SAP AG CR590 5-48

SAP AG 2002





BUT000





Event DSAVE(Save data)

BUT000 in DBBUT000 in DB

The application SAP BP saves the structure BUT000 in the database.

© SAP AG CR590 5-49

SAP AG 2002





Event DSAVE(Save data)


BUT000




BUT000 in DB

FSBUB1 in DBFSBUB1 in DB

The application FS BP saves the structure FSBUB1.

© SAP AG CR590 5-50

SAP AG 2002

Program Logic: Unit Summary


Trace the processing flow of the BDT program flow.Name events and their tasks in the BDTDescribe the processing of table-participating applicationsDescribe the processing of table-owning applications and the differences with regard to table-participating applicationsDifferentiate between the current and global memory and their tasks

© SAP AG CR590 6-1

SAP AG 2002

Contents:

Create Table Append

Create Screen

Create Events for Screen

Create Events for Program Logic

Add Additional Checks

Special Case: Data Fields


© SAP AG CR590 6-2

SAP AG 2002


Extensions with Table-Participating Applications:Unit Objectives

Explain the extension of the SAP BP by means of table appendsDescribe the aim of encapsulating screen events in function modulesDescribe the aim of the program logic and its function

Explain the adding of additional checks in the BDT

Describe the special features of date fields in the BDT

© SAP AG CR590 6-3

SAP AG 2002

Extensions with Table-Participating Applications:Overview Diagram




Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 6-4

SAP AG 2002

You are required to extend the SAP BP by way of two additional fields: date and rating of the first contact.

You are required to add additional checks to a standard BP view. The last name has to be checked for vowels.

Extensions with Table-Participating Applications:Business Scenario

© SAP AG CR590 6-5

SAP AG 2002



SAPApplication I


SAP Application II




SAP BPSAP BP(BUPA)(BUPA)


DDIC Development Workbench BDT Control Tables

In table-participating applications, you have development areas Data Dictionary (DDIC), Development Workbench and the BDT control tables. The same development areas are also needed for developing the table-owning applications.

© SAP AG CR590 6-6

SAP AG 2002

Step 1: Data Dictionary

Table ZZ_......

Table BUT000

...

...

...




Application ISAPSAP






...

...

...

...

...

In the first step, an existing table is extended with the help of an append structure in the DDIC. In the following exercise the SAP Business Partner standard table, BUT000, is extended.

© SAP AG CR590 6-7

SAP AG 2002

Step 2: Create Screen


Screen

......

..._POV_....._POV_..

..._PAI_....._PAI_..

..._PBO_....._PBO_..

......

ISDSTISDST

ISDATISDAT

ISSTAISSTAEvents for eachapplication

Events for eachview

Function ModulesFunctionGroup

FunctionGroup

Program Logic

PAI Module

POV-Modul

• ...• POV

• ...• PAI

PBO Module

• ...• PBO

In the second step, a screen with Process Before Output (PBO) and Process After Input (PAI) modules is created. In these modules the BDT service function modules are called up. In order to be able to provide a suitable input help (F4 help) for entering the date in our scenario, an additional Process On Value Request (POV) module is created.

© SAP AG CR590 6-8

SAP AG 2002

Step 3: Create Function Modules

Program Logic......

..._POV_....._POV_..

..._PAI_....._PAI_..

..._PBO_....._PBO_..

......

DSAVEDSAVE

ISDATISDAT


Events for eachview

Function Modules

Screen


FunctionGroup

FunctionGroup

PAI Module

POV Module

• ...• POV

• ...• PAI

PBO Module

• ...• PBO

In the third step, the function modules are created for the events per application and view.

© SAP AG CR590 6-9

SAP AG 2002

Mandatory Events

DLVE1DLVE1 Initialize current memory

ISSTAISSTA Initialization

ISDSTISDST Distribute data to participating application

FCODEFCODE Carry out own function code

XCHNGXCHNG Check whether data has been changed

DCHCKDCHCK Cross-screen check of data

DSAVBDSAVB Return of data to table-owning application

The BDT defines several events for an application object. In these events, assigned function modules are available for the functions of reading, checking and saving. Assigned function modules are called dynamically by the BDT.

The events represented by the darker blocks are absolutely necessary for table-participating applications.

© SAP AG CR590 6-10

SAP AG 2002

BDT Development: DWB - Events for Each Table

Communication:

via GET and COLLECT modules

Table-ParticipatingApplications




Table-OwningApplicationsTable-OwningApplications

..._GET..._GET

..._COLLECT..._COLLECT

Call

Data Flow

Data FlowCall

Tables may have

• one owning application and

• several participating applications.

Tables are assigned to development classes. In a development class, there is one responsible (table-owning) application for each table. Only this application reads the table from and updates the table at the database. The application that adds table fields by means of append structures is defined as the participating application.

Communication between the possessing and participating application takes place via so-called GET and COLLECT function modules.

If a table-owning application allows a table-participating application an append structure, the table-owning application must have these two function modules for communication with other applications. In this way the table-participating application is able to exchange the current table content with the owning application.

Read data (GET-FB): with this function module, the participating applications can determine the current content of the table.

Collect data (COLLECT-FB): this function module allows a table-participating application to transfer to the table-owning application, the values of fields it has attached.

© SAP AG CR590 6-11

SAP AG 2002

Data Administration: Participating Application

Function Group Table-Owning Appl.

Function GroupFunction GroupTable-Participating Table-Participating ApplAppl..

DB

GlobalMemory oldnew

DSAVBDSAVB

ISDSTISDST

(GET FM)

(COLLECT FM)

CurrentMemory

CurrentMemory

new old new old

ISDATISDAT

DTAKEDTAKE

DSAVEDSAVE

Table-participating and table-owning applications have in each case their own function groups with decoupled memory areas. For this reason, the table-participating application gets, in event ISDST, the current memory of the table-owning application by calling the GET function module. Old and new data is saved.

In event DSAVB, data is transferred by the table-participating application to the table-owning application by calling the COLLECT function module. Only new data from the current memory and the table append is transferred.

The table-owning application is responsible for writing the data to the database in event DSAVE.

© SAP AG CR590 6-12

SAP AG 2002

Additional Checks

ScreenScreen

View 1View 1

View 2View 2

View 3View 3

View 4View 4

View 5View 5

View 6View 6

View 7View 7

Sicht 8Sicht 8

Section 1

Section 2

Section 3

View 1View 1

PBCPBC PBOPBO PAIPAI

Application / ScreenApplication / Screen

Additional ChecksAdditional ChecksApplAppl. 1. 1 FuMoFuMo A (PAI) A (PAI)

ApplAppl. 2. 2 FuMoFuMo A (PAI) A (PAI)

...... ......

In addition to the Process Before Call (PBC), Process Before Output (PBO) and Process After Input (PAI) function modules of the views, any number of additional function modules can be attached to each view.

The function modules included under "additional checks" are called up in the Process After Input (PAI) event of the view.

This allows a modification-free check of the data from "external" views.

© SAP AG CR590 6-13

SAP AG 2002

Standard Date Fields

Automatic functions linked to the screen

Other interfaces cannot use these functions

ABAP Processing Block Screen

01.07.2001Date

Automatic functions in the screen- Date formatting- Check- F4 Help

CHAR1020010701

DATS

Date fields are a special case. Internally, a date is represented in the format "YYYYMMDD" (field type DATS).

This format is suitable not only for representation on the screen. For this reason, screens contain service functions that carry out the automatic conversion of date fields in the required format for representation.

The check functions can only be used for the dialog interfaces.

© SAP AG CR590 6-14

SAP AG 2002

Date Fields in the BDT

ABAP Screen

01/07/2001Date

01/07/2001

20010701

_PBO_PBO_POV (F4)_POV (F4)

No conversion

DATS

CHAR10 CHAR10

_PAI_PAI

Conversion and check encapsulated in function modules

Other interfaces can use the same coding

In order to make the program code usable for different interfaces, the code must be encapsulated in function modules.

The BDT events Process Before Output (PBO) and Process After Input (PAI) are used to convert the internal format "DATS" into "CHAR10".

No data conversion takes place between screen processes and ABAP processes.

To provide an input help (F4 help), you have to call a BDT service function module, Process On Value Request (POV), within the screen.

© SAP AG CR590 6-15

SAP AG 2002

Extensions with Table-Participating Applications:Unit Summary


Explain the extension of the SAP BP by means of table appends

Describe the aim of encapsulating screen events in function modules

Describe the aim of the program logic and its function

Describe the adding of additional checks in the BDT

Explain the special features of date fields in the BDT

© SAP AG CR590 6-16

Exercises

Unit: Extensions with Table-participating Applications Topic: Extension of a BDT object via a table


• Extend BDT objects without modifications using a table append.

You need to extend the application object BUPA (Business Partner) by way of attributes and functions.

During the first contact between a processor and a customer, the processor has to enter the date and his rating of the first contact. He should be able to save the first contact date and the rating.

1-1 Look at the prepared DDIC extensions.

Additional attributes have to be maintained in the SAP Basis (DDIC). These could be table appends or tables.

(SE11) SAP Menu → Tools → ABAP Workbench→ Development → Data Dictionary

1-1-1 Write down the name of the append of the customer table BUT000.

_______________________________

1-1-2 Write down the name of the check table for the field rating.

_______________________________

© SAP AG CR590 6-17

1-2 Create the first contact screen. You have to create new screens for the dialog, as there were previously no screens with the new attributes.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator

1-2-1 Create the function group ZBUPA## in the development class ZBUPA.

1-2-2 To save time, copy the top include of function group ZBUPAXX into the top include of your function group.

1-2-3 Create the screen.

Screen number 0010

Description First contact

Screen type Subscreen

Text field BUT000-ZZCNT_FIRST

In-/Output field ZBUSFLDS-CNT_FIRST

Text field BUT000-ZZCNTID

In-/Output field BUT000-ZZCNTID

Output only ZTB001T-TEXT

1-2-4 Create the flow logic in the screen.

1-2-5 Look at your screen in test mode.

1-3 Creation of the screen event function modules Specific SAP Basis functions unfortunately do not work in the dialog and batch / direct input mode. . Because of this, you have to format and date fields for example for the dialog. The event PBO converts the format DATS into CHAR 10. Event PAI carries out a reconversion and check. That is also the reason for using a help structure for the data field and not the database field.

1-3-1 Create event function module Z_ZC##_BUPA_PBO_ZC##10 for event “Process Before Output” in your function group. Use the Coding Appendix as a template.

1-3-2 Create event function module Z_ZC##_BUPA_PAI_ZC##10 for event Process After Input in your function group. Use the Coding Appendix as a template.

© SAP AG CR590 6-18

1-4 Add the screen in the Customizing in the BDT.

You have created your screen in the Development Workbench. It is not yet known to the BDT. The Customizing for this still has to be carried out.

1-4-1 Navigate to the Easy Access Menu:


BP Control→ Screen Layout

1-4-2 Create the field group for the view.

Field group 620 + ## group

(for example 620+11=field group 631)

Description Rating of first contact

Table BUT000

Field name ZZCNTID

Input field X

Field group 640 + ## group number

(for example 640+11=Field group 651)

Description Date of first contact

Table ZBUSFLDS

Field name CNT_FIRST

Input field X

1-4-3 Create and activate the application ZC##.

An application is only a Customizing entry, which groups elements of the SAP Basis (e.g. screens, function modules).

BP Control → Application

1-4-4 Create dataset ZD##10.

Datasets serve the purpose of grouping views. Later views are assigned within the divisibility to the object part. (e.g. in the case of BP, this is the role.) You determine which attributes are displayed in the dialog.

BP Control → Divisibility → Datasets

© SAP AG CR590 6-19

1-4-5 Create the view ZS##10 for your screen 0010.

This view groups the relevant screen and event function modules together for the screen and makes these elements known to the BDT.

BP Control → Screen Layout → Views


Application ZC##

Diff.Type 0

Dataset ZD##10

Entry View X

Dialog View X

Subscreen SAPLZBUPA##

0010

Data screen X

1-4-6 Enter the event function modules PAI and PBO in your view.

Process Before Output Z_ZC##_BUPA_PBO_ZC##10

Process After Input Z_ZC##_BUPA_PAI_ZC##10

1-4-7 Assign the field groups to your view ZS##10.

Fields groups are for controlling field status (display, required entry, optional entry, hide) via the BDT.


Assign field groups 620 + Group ##

640 + Group ##

1-5 Create a new section.

A section groups a number of views together in the dialog, and draws a frame with a title around the views.



Section ZA##10

Description Additional partner data ##

Title Additional partner data ##

1-5-2 Assign the section to your view.


View ZS##10

© SAP AG CR590 6-20

1-6 Create a screen.

A screen includes one or more sections and represents one tab page in the dialog. The position numbers in the screen sequence control the sequence of screens.


1-6-1 Create a new Screen.

Screen ZB##10


Data screen X

BDT X

Screen type normal

1-6-2 Assign the section to the screen.


Section BUP009


Section ZA##10


BP control → Screen Sequence



Screen ZB##10

© SAP AG CR590 6-21

1-6-4 Check the assigned datasets and calling applications in the object part ZC##10.

The call of an object part (role) triggers the execution of the views (screens) and function modules, which are assigned to the datasets and applications.

BP Control → Divisibility → Roles

Datasets BUA010

BUB010

BUP010

BUP020

BUP030

ZD##10

Calling Applications BUA

BUB

BUP

BUS

ZC##

1-6-5 Look at the result under:

Application → Business Partner → Create → Role ZC##10

1-7 Create the following event function modules for the tables append. You will find example coding in the Coding Appendix.

The function modules are created for the different events in function group. These objects from the Development Workbench Objects are made known by the Customizing to the BDT.


Event Function Module

ISSTA – Initialize Z_ZC##_BUPA_EVENT_ISSTA

ISDAT – Distribute/read data Z_ZC##_BUPA_EVENT_ISDAT

XCHNG – Data changed? Z_ZC##_BUPA_EVENT_XCHNG

DSAVB – Collect Data Z_ZC##_BUPA_EVENT_DSAVB

DLVE1 – Initialize current memory. Z_ZC##_BUPA_EVENT_DLVE1

© SAP AG CR590 6-22

1-8 Add the function modules to the Customizing in the BDT.

BUPT Menu → BP Control → Events

ISSTA

Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_ISSTA

Call X

Application ZC##

ISDAT

Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_ISDAT

Call X

Application ZC##

XCHNG

Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_XCHNG

Call X

Application ZC##

DSAVB

Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_DSAVB

Call X

Application ZC##

DLVE1

Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_DLVE1

Call X

Application ZC##

© SAP AG CR590 6-23

Exercises

Unit: Extensions with Table-participating Applications Topic: Extended Check


• Add additional checks for fields, without having to make modifications

Entries made by processors should be verified to ensure that at least one vowel is in the name.

2-1 Create a function module for the additional check of view BUP300.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Function Group ZC##

2-2 Define the additional check in the Customizing.

Menu BUPT → BP control → Screen Layout → Views → Additional Checks

2-3 Check the result in the dialog. Process a word without vowels and try to switch the screen. An error message will be displayed.

BUPT Menu → Application → Business Partner → Create → Role ZC##10

© SAP AG CR590 6-24

Solutions

Unit: Extensions with Table-participating Applications Topic: Extension of a BDT object via a table append



1-1-1 The name of the table append for the customer table BUT000 is ZBUT000.

1-1-2 The name of the check table for the field Rating is ZTB001.

1-2 Create the first contact screen.


1-2-1 Create the function group ZBUPA## in the development class ZBUPA. Select the development class and the type ZBUPA. The structure of the development class ZBUPA is visible. Choose with the right button on the mouse ZBUPA, function group and create.

1-2-2 Copy the top include of function group ZBUPAXX into the top include of your function group. Select function group ZBUPAXX and mark all data definitions in Includes⇒Top include LZBUPAXXTOP. Copy all definitions including the message-ID into your function group LZBUPA##TOP.

1-2-3 Create the screen.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Choose with right mouse button ZBUPA## → Create Screen

Screen number 0010



Text field BUT000-ZZCNT_FIRST

In-/Output field ZBUSFLDS-CNT_FIRST

Text field BUT000-ZZCNTID

In-/Output field BUT000-ZZCNTID

Output only ZTB001T-TEXT

© SAP AG CR590 6-25

1-2-4 The screen flow logic is created. The service function modules BUS_PAI and BUS_PBO are called in PAI and PBO. To support the F4-help, you have to create a process-on-value request as described in the Coding Appendix. After exercise 2-4-2, you have to change the field group in the coding to the field group of the date field.

1-2-5 Look at your screen in test mode.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Screens → Choose Screen Number with right mouse button → Test

1-3 Event function modules are created for the screen.

1-3-1 Create event function module Z_ZC##_BUPA_PBO_ZC##10 for event “Process Before Output” in your function group. Use the Coding Appendix as a template.

1-3-2 Create event function module Z_ZC##_BUPA_PAI_ZC##10 for event Process After Input in your function group. Use the Coding Appendix as a template.

1-4 Add the screen to the Customizing in the BDT.

Navigate to the Easy Access Menu:


BP Control→ Screen Layout

1-4-1 Create the field group for the view.

Field group 620 + ## group

(for example 620+11=field group 631)

Description Rating of first contact

Table BUT000

Field name ZZCNTID

Input field X


(for example 640+11=Field group 651)

Description Date of first contact

Table ZBUSFLDS

Field name CNT_FIRST

Input field X

© SAP AG CR590 6-26

1-4-2 Create and activate the application ZC##.

BP Control → Application

1-4-3 Create dataset ZD##10 with description dataset ##.

BP Control → Divisibility → Datasets

1-4-4 Create the view ZS##10 for your screen 0010.



Application ZC##

Diff.Type 0

Dataset ZD##10

Entry View X

Dialog View X


0010

Data screen X

1-4-5 Enter the event function modules PAI and PBO in your view.

Process Before Output Z_ZC##_BUPA_PBO_ZC##10

Process After Input Z_ZC##_BUPA_PAI_ZC##10

1-4-6 Assign the field groups to your view ZS##10.

BP Control → Screen Layout → Views → Assign View to Field Groups

Assign field groups 620 + Group ##

640 + Group ##

1-5 Create a new section.



Section ZA##10




BP Control → Screen Layout → Sections → Assign Sections to Views


View ZS##10

© SAP AG CR590 6-27

1-6 Create a screen.


1-6-1 Create a new Screen.

Screen ZB##10


Data screen X

BDT X

Screen type normal


BP Control → Screen Layout → Screens → Assign Screen to Sections


Section BUP009


Section ZA##10


BP Control → Screen Sequences → Assign Screen Sequence to Screens



Screen ZB##10

1-6-4 Check the assigned datasets and calling applications in role ZC##10

BP Control → Divisibility → Roles

Datasets BUA010

BUB010

BUP010

BUP020

BUP030

ZD##10

Calling Applications BUA

BUB

BUP

BUS

ZC##

1-6-5 Look at the result under:

→ Application → Business Partner → Create → Role ZC##10

© SAP AG CR590 6-28

1-7 Create the following event function modules for the tables append. You will find example coding in the Coding Appendix.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Choose Function Group with right Mouse Button → Function Module → Create


ISSTA – Initialize Z_ZC##_BUPA_EVENT_ISSTA

ISDAT – Distribute/read data Z_ZC##_BUPA_EVENT_ISDAT

XCHNG – Data changed? Z_ZC##_BUPA_EVENT_XCHNG

DSAVB – Collect Data Z_ZC##_BUPA_EVENT_DSAVB

DLVE1 – Initialize current memory. Z_ZC##_BUPA_EVENT_DLVE1

© SAP AG CR590 6-29

1-8 Add the function modules to the Customizing in the BDT. BUPT Menu → BP Control → Events → Select Event → Assign Events to Function Modules

ISSTA Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_ISSTA

Call X

Application ZC##

ISDAT Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_ISDAT

Call X

Application ZC##

XCHNG Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_XCHNG

Call X

Application ZC##

DSAVB Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_DSAVB

Call X

Application ZC##

DLVE1 Position 7000## +10 Function module Z_ZC##_BUPA_EVENT_DLVE1

Call X

Application ZC##

© SAP AG CR590 6-30

Solutions

Unit: Extensions with Table-participating Applications Topic: Extended Check

2-1 Create a function module for the additional check of view BUP300.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Function Group ZC## → Choose Function Modules with Right Mouse Button → Create

Use Z_ZC##_BUPA_PAI_BUP300 in the Coding Appendix as a template.

2-2 Define the additional check in the Customizing.

Menu BUPT → BP control → Screen Layout → Views → Additional Checks

2-3 If you try to save a business partner in your role without vowels the in name field, an error message will be displayed.


© SAP AG CR590 7-1

SAP AG 2002

Contents:

Create Table

Create Screen

Create Events for the Screen

Create Events for the Program Logic

GUI Menu

Extensions with Table-Owning Applications:

© SAP AG CR590 7-2

SAP AG 2002


Explain the extension of the SAP BP by means of own tablesDescribe the BDT Customizing for tables


Explain the possibilities for extending the GUI menu

Extensions with Table-Participating Applications:Unit Objectives

© SAP AG CR590 7-3

SAP AG 2002

Extensions with Table-Owning Applications:Overview Diagram


Extensions with Table-OwningApplications


Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 7-4

SAP AG 2002

You need to extend the SAP BP by way of a table control. The table control should include business partner hobbies.

Extensions with Table-Owning Applications:Business Scenario

© SAP AG CR590 7-5

SAP AG 2002

SAP BP(BUPA)


DDIC BDT-Control Tables


Development Workbench


SAPApplication I


SAP Application II




For table-participating applications, you have the same development areas as you have for table-owning applications -Data Dictionary (DDIC), Development Workbench and BDT control tables.

© SAP AG CR590 7-6

SAP AG 2002

Step 1: Data Dictionary

Table ZZ_......

Table BUT000

...

...

...



...

...

...

...

...


Application ISAPSAP






In the first step an own table is created in the data dictionary (DDIC).

© SAP AG CR590 7-7

SAP AG 2002

Step 2: Create Screen

......

..._PAI_....._PAI_..

..._PBO_....._PBO_..

..._PBC_....._PBC_..

......

COLLECTCOLLECT

GETGET

• 0020 Hobby

ScreenPBO Module

PAI Module

• ...• PAI

• ...• PBO

......

ISDSTISDST

ISDATISDAT


Events for eachview


FunctionGroup

Program Logic

Events for eachtable

PBC Module

• ...• PBC

In the second step, a screen with Process Before Output (PBO) and Process After Input (PAI) modules is created. In these modules the BDT service function modules are called up.

A Process Before Call (PBC) module is still needed for sorting the data for the table control.

© SAP AG CR590 7-8

SAP AG 2002

Step 3: Create Function Modules

......

..._PAI_....._PAI_..

..._PBO_....._PBO_..

..._PBC_....._PBC_..

......

COLLECTCOLLECT

GETGET

• 0020 Hobby

ScreenPBO Module

PAI Module

• ...• PAI

• ...• PBO

......

ISDSTISDST

ISDATISDAT


Events for eachview


FunctionGroup

Program Logic

Events for eachtable

PBC Module

• ...• PBC

In the third step, the function modules are created for the events for each application and view.

If the table-owning application allows a table-participating application an append structure, the table-owning application must make available a so-called GET and COLLECT function module (events per table) for communication with other applications. In this way the table-participating application is able to exchange the current table content with the owning application.

Read data (GET FunMod):

• With this function module, the table-participating applications are able to determine the current content of the table.

Collect data (COLLECT FunMod):

• With this function module, a table-participating application is able to export to the table-owning application, the data of fields that it has attached.

© SAP AG CR590 7-9

SAP AG 2002

Mandatory Events

ISSTAISSTA

ISDATISDAT

FCODEFCODE

XCHNGXCHNG

DCHCKDCHCK

DSAVCDSAVC

DSAVEDSAVE

DLVE1DLVE1

DLVE2DLVE2

DTAKEDTAKE

Initialization

Read data from DB

Carry out own function code

Check whether data has been changed

Check data before saving

Note data in global memory

Complete data (internal number)

Save data on DB

Initialize current memory

Initialize global memory

All the events represented by the dark blocks are necessary events.

© SAP AG CR590 7-10

SAP AG 2002

Current MemoryTable-owning applications

All table-participating applications

Global MemoryOnly table-owning applications

Global Memory versus Current Memory

Service functions like direct input or the transfer mode make it necessary to differentiate between the current and global memory.

The current memory works with the structure or internal table of the current object. Table-owning and participating applications also have a current memory.

The global memory works with the internal table of one or more objects. Only table-owning applications have a global memory.

© SAP AG CR590 7-11

SAP AG 2002


Func

tion

Gro

up

DB

DSAVEDSAVE

CurrentMemory

new old

GlobalMemory

oldnewISDATISDAT

DTAKEDTAKE

The current memory contains the data of the instance (for example, Business Partner) that is currently being processed. Old and new data statuses are separated. The old status is taken from the data that is read at event ISDAT (table-owning application). At this point new and old data are identical. During maintenance, the new current memory is updated after each entry.

The global memory contains the data for all instances that you have processed but not yet saved in the database. For each table, there is only one global memory. Data of table-participating applications is also included. Also in the case of the global memory, a differentiation is made between the old and new status, and they are stored separately. The old data represents the current database status. For this reason the current database status is created for an instance only when data is maintained for the first time. This is done in the event DTAKE. If the same instance is maintained again without saving, the old status may no longer be changed. The new data is transferred from the new status of the current memory into the new status of the global memory.

Events

• In event ISDAT, you look for data in the global memory. If no data for the current instance has been stored in the global memory, the data is read from the database.

• In event DTAKE, the table-owning application writes the data from the old and new current memory to the global memory.

• In event DSAVE, you check if there are differences between the new and old global memory. If this is the case, changes have taken place and the database must be updated.

© SAP AG CR590 7-12

SAP AG 2002


Function Group Table-Owning Application

Function GroupFunction GroupTable-Participating Table-Participating


DB

GlobalMemory oldnew

DSAVBDSAVB

ISDSTISDST

(GET FM)

(COLLECT FM)

CurrentMemory

CurrentMemory

new old new old

ISDATISDAT

DTAKEDTAKE

DSAVEDSAVE

Table-participating and table-owning applications have in each case their own function groups with decoupled memory areas. For this reason, the table-participating application gets, at event ISDST, the current memory of the table-owning application by calling the GET function module. Old and new data is saved.

In event DSAVB, data is transferred by the table-participating application to the table-owning application by calling the COLLECT function module. Only new data from the current memory and the table append is transferred.

The table-owning application is responsible for writing the data to the database in event DSAVE.

© SAP AG CR590 7-13

SAP AG 2002

Add own menu

Add additional functions

Activate / deactivate functions

Create link menu function <-> pushbutton

Extension of the GUI Menu

DCUADDCUAD

DCUACDCUAC

Set menu

Change menu

BDT Events

The BDT provides the events DCUAD (set menu) and DCUAC (change menu) for adding GUI menus and functions.

By means of these events it is possible to

• add own menus and functions to the standard menus and functions

• activate / deactivate functions

• create links between pushbuttons and menu functions

© SAP AG CR590 7-14

SAP AG 2002

Extensions with Table-Owning Applications: UnitSummary


Explain the extension of the SAP BP by means of own tables

Describe the BDT Customizing for tables


Explain the possibilities for extending the GUI menu

© SAP AG CR590 7-15

Exercises

Unit: Extension with Table-owning Application Topic: Extension of a BDT object via a table


• Extend existing BDT objects with the help of tables.

The processor should be able to save hobbies of a business partner. The standard SAP Business Partner should be extended without modification for this purpose.



1-1-1 Write down the fields of table ZBUTHOBBY.

_______________________________

1-1-2 Are there any peculiarities in structure ZBUSHOBBY?

_______________________________

1-1-3 How does BDT know about the table?

_______________________________

© SAP AG CR590 7-16

1-2 Create the screen Hobby.

You have to create a screen to display the extended attributes of table ZBUTHOBBY. The additional attributes of table ZBUTHOBBY should be displayed at table control. It should be possible to delete individual lines via a function.


1-2-1 Create a Screen in your function group ZC##.

Properties

Screen number 0020

Description Hobby ##


© SAP AG CR590 7-17

Screen Elements:

Table Control TCTRL_ZBUTHOBBY

Table type Entry

with Column heading

Configurable

Separators vertical

horizontal

Line selection Multiple

Column selection None

with selection column GT_ZBUTHOBBY-XMARK

Text field/Title in Table Control (out of DDIC)

ZBUTHOBBY-HOBBY

In-/Output field in Table Control GT_ZBUTHOBBY-HOBBY

Pushbutton PUSH_ZC##_HOBBY_DELE ICON-Name ICON_DELETE_ROW

Function code ZC##_HOBBY_DELE

In-/Output field ZBUSFLDS-POSTXT_ZBUTHOBBY

Output only

1-2-2 Create the event function module Z_ZC##_BUPA_PBC_ZC##20 according to the template in the coding appendix.


© SAP AG CR590 7-18

1-3 Make the necessary entries in the BDT.

1-3-1 Create a field group.

BUPT Menu → BP Control → Screen Layout → Field Groups



Table Control X

Table GT_ZBUTHOBBY

Field name HOBBY

Input field X

Table ZBUTHOBBY

Field name HOBBY

Input field O

1-3-2 Create a view.

BUPT Menu → BP Control → Screen Layout → Views

View ZS##20


Application ZC##

Diff-Typ 0

Dataset ZD##10

Entry View X

Dialog View X


0020

Process Before Call Z_ZC##_BUPA_PBC_ZC##20

Data screen X

1-3-3 Assign the field group to a view.

© SAP AG CR590 7-19

1-3-4 Create section ZA##20 and assign the view.

BUPT Menu → BP Control → Screen Layout → Sections




View ZS##20

1-3-5 Assign screen to section.

Screen ZB##10


Section BUP009


Section ZA##10


Section ZA##20

© SAP AG CR590 7-20

1-4 Create the necessary event function modules.


Event Function module

ISSTA – Initialize already done in exercise 1

Z_ZC##_BUPA_EVENT_ISSTA

ISDAT – Distribute/read data extend from exercise 1 Z_ZC##_BUPA_EVENT_ISDAT

XCHNG – Data changed? Extend from exercise 1 Z_ZC##_BUPA_EVENT_XCHNG

FCODE – Own function code Z_ZC##_BUPA_EVENT_FCODE

DTAKE – From current into global memory

Z_ZC##_BUPA_EVENT_DTAKE

DSAVC – Complete data Z_ZC##_BUPA_EVENT_DSAVC

DSAVE – Save data Z_ZC##_BUPA_EVENT_DSAVE

Update module:

Z_ZC##_BUPA_UPDATE

DLVE1 – Initialize current memory. extend from exercise 1

Z_ZC##_BUPA_EVENT_DLVE1

DLVE2 – Initialize global memory Z_ZC##_BUPA_EVENT_DLVE2

1-5 Make the necessary entries in the BDT. The position numbers are (7000## + 10) and application ZC##.


© SAP AG CR590 7-21

1-6 Store the function code in the BDT.

BUPT Menu → BP Control → GUI-functions → Additional functions

The pushbutton on your screen triggers the function code. The function is recognized by the BDT. The BDT reads the Customizing and executes the function module of your application ZC## in event FCODE.


Function text Delete hobby

Application ZC##

Menu 2

Save Mode

Create

X

Save Mode

Change

X

Transfer Mode

Create

X

Transfer Mode

Change

X

1-7 Check the result in the Business Partner dialog.


© SAP AG CR590 7-22

Exercises

Unit: Extension with Table-owning Application Topic: Change GUI menu


• Change the standard GUI menu by using a BDT event

The processor should be able to call up the function “delete hobby” via the GUI menu.

2-1 Explain the function of the function module. Z_ZCXX_BUPA_EVENT_DCUAC.


2-2 Create function module Z_ZC##_BUPA_EVENT_DCUAC for event DCUAC for changing the GUI-Menu.


2-3 Performe the Customizing in the BDT.


2-4 Check the result in the dialog.


© SAP AG CR590 7-23

Solutions

Unit: Extension with Table-owning Application Topic: Extension of a BDT object via a table



1-1-1 Client, partner and hobby are the fields in table ZBUTHOBBY.

1-1-2 The peculiarity in the structure ZBUSHOBBY is a character field KZ to store the activity (update, delete, insert) for each record. Depending on the activity, the records in direct input are updated, deleted and inserted in the corresponding table by the BDT.

1-1-3 The table ZBUTHOBBY and other attributes are customized as follows:

Menu BUPT → BP control → Tables

© SAP AG CR590 7-24

1-2 Create the screen hobby.


1-2-1 Create the screen in your function group ZC##.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Choose screen with right mouse button → Create

Properties

Screen number 0020



© SAP AG CR590 7-25

Screen Elements:

Table Control TCTRL_ZBUTHOBBY

Table type Entry

with Column heading

Configurable

Separators vertical

horizontal

Line selection Multiple

Column selection None

with selection column GT_ZBUTHOBBY-XMARK

Text field/Title in Table Control (out of DDIC)

ZBUTHOBBY-HOBBY

In-/Output field in Table Control GT_ZBUTHOBBY-HOBBY

Pushbutton PUSH_ZC##_HOBBY_DELE

ICON name ICON_DELETE_ROW


In-/Output field ZBUSFLDS-POSTXT_ZBUTHOBBY

Output only

1-2-2 Create the event function module Z_ZC##_BUPA_PBC_ZC##20 according to the template in the coding appendix.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Choose function modules with right mouse button → Create

© SAP AG CR590 7-26

1-3 Make the necessary entries in the BDT.

1-3-1 Create a field group.

BUPT Menu → BP Control → Screen Layout → Field Groups → Field Groups → Assignment Field Group -> Fields



Table Control X

Table GT_ZBUTHOBBY

Field name HOBBY

Input field X

Table ZBUTHOBBY

Field name HOBBY

Input field O

1-3-2 Create a view.


View ZS##20


Application ZC##

Diff-Typ 0

Dataset ZD##10

Entry View X

Dialog View X


0020

Process Before Call Z_ZC##_BUPA_PBC_ZC##20

Data screen X

1-3-3 Assign the field group to a view.

BUPT Menu → BP Control → Screen Layout → Views → Assign View to Field Group

© SAP AG CR590 7-27

1-3-4 Create section ZA##20 and assign the view.





View ZS##20

BUPT Menu → BP Control → Screen Layout → Sections → Assign section to View

1-3-5 Assign screen to section.

BUPT Menu → BP Control → Screen Layout → Screens → Assign Screen to sectionse

Screen ZB##10


Section BUP009


Section ZA##10


Section ZA##20

© SAP AG CR590 7-28

1-4 Create the necessary event function modules.



ISSTA – Initialize already done in Exercise 1

Z_ZC##_BUPA_EVENT_ISSTA

ISDAT – Distribute/read data extend from exercise 1 Z_ZC##_BUPA_EVENT_ISDAT

XCHNG – Data changed? Extend from exercise 1 Z_ZC##_BUPA_EVENT_XCHNG

FCODE – Own function code Z_ZC##_BUPA_EVENT_FCODE

DTAKE – From current into global memory

Z_ZC##_BUPA_EVENT_DTAKE

DSAVC – Complete data Z_ZC##_BUPA_EVENT_DSAVC

DSAVE – Save Data Z_ZC##_BUPA_EVENT_DSAVE

Update module:

Z_ZC##_BUPA_UPDATE

DLVE1 – Initialize current memory. extend from exercise 1

Z_ZC##_BUPA_EVENT_DLVE1

DLVE2 – Initialize global memory Z_ZC##_BUPA_EVENT_DLVE2

1-5 Make the necessary entries in the BDT. The position numbers are (7000## + 10) and application ZC##. Select events and assign function modules to them. You only have to assign the same function module once.

BUPT Menu → BP Control → Events → Select Event → Assign Events to Function Modules

© SAP AG CR590 7-29

1-6 Store the function code in the BDT.

BUPT Menu → BP Control → GUI Functions → Additional Functions


Function text Delete hobby

Application ZC##

Menu 2

Save Mode

Create

X

Save Mode

Change

X

Transfer Mode

Create

X

Transfer Mode

Change

X

1-7 Check the result in the Business Partner dialog.


© SAP AG CR590 7-30

Solutions

Unit: Extension with Table-Owning Application Topic: Change GUI menu

2-1 The Function Module Z_ZCXX_BUPA_EVENT_DCUAC is for reading the current status of all function modules and for setting the status of the deletion of a hobby depending on coding rules.

(SE37) SAP Menu → Tools → ABAP Workbench → Development → Function Builder

2-2 Create function module Z_ZC##_BUPA_EVENT_DCUAC for event DCUAC for changing the GUI menu.


Be sure, that the global constant for the pushbutton in the top include GC_FCODE_HOBBY_DELE are changed into your Pushbutton name PUSH_ZC##_HOBBY_DELE, and that the parameter for calling 'BUS_FMOD_STATUS_GET' is the function group of the table control.

2-3 Perform the Customizing in the BDT and assign the event DCUAC to the function module.

Menu BUPT → BP control → Events → Assign Event DCUAC to Z_ZC##_BUPA_EVENT_DCUAC

2-4 Check the result in the dialog.


© SAP AG CR590 8-1

SAP AG 2002

Contents:

Processing Modes

Interfaces

Field Groupings

Search Help

Change Documents

Archiving

Visual Configuration Tool

Where-Used Lists


© SAP AG CR590 8-2

SAP AG 2002


Explain the different processing modes of the BDTExplain the steps for extending the field groupingsExplain the steps for extending an existing search helpDescribe change documents in the BDTDescribe the concept of archiving in the BDTWork with the Visual Configuration Tool Work with and customize where-used lists

Service Programs and Functionality: UnitObjectives

© SAP AG CR590 8-3

SAP AG 2002

Service Programs and Functionality: OverviewDiagram



Service Programs andFunctionality

Program Logic


BDT Basics

Dialog

Course Overview

© SAP AG CR590 8-5

SAP AG 2002

Save ModeChanges to a BP are either saved or discarded before leaving the maintenance

Transfer ModeMaintenance via dialog, save is triggered by external application

Example:

Contract calls BP maintenance

BP data is noted

The BP data is not saved until the contract is saved

Direct InputMass insert / update!!

Targets of the Processing Modes

There are several prerequisites for data maintenance:

1. Direct and online maintenance via dialog. (SAVE mode)

2. Maintenance via dialog with external trigger for saving. (Transfer mode)

3. Maintenance via direct input without dialog. (Direct Input)

Direct input enables mass insert/updates. Databases create an index anew after each DB commit. A DB commit is carried out after a few hundred instances for better performance.

© SAP AG CR590 8-6

SAP AG 2002

Processing Modes: Save Mode

Event DSAVBCollect data

Event DTAKENote data

Event DSAVCComplete data

‘Save’ Function

Event DSAVESave data

CurrentMemory

CurrentMemory

CurrentMemory

Owning Application

Participating Participating ApplicationApplication

DSAVBDSAVB

CurrentMemory

DTAKEDTAKE

DSAVEDSAVE

DB

DSAVCDSAVC

Program logic events in the save mode when performing save.

© SAP AG CR590 8-7

SAP AG 2002

Processing Modes: Transfer Mode

ContractContract No.

Contract type

Policyholder

Beneficiary

Change

SAP-SAP-GPGP

Change

Event DSAVBCollect data

Event DTAKENote data

Event DSAVCComplete data

‘Transfer’ Function

Event DSAVESave data

Save

The transfer mode allows you to jump to a BDT object, into creation / maintenance, without saving the data directly on the database. The trigger for saving or discarding comes from the leading application. In case of saving, the events DSAVC and DSAVE are performed.

© SAP AG CR590 8-8

SAP AG 2002

Processing Modes: Direct Input (Flow)

Initial screen: Entries

Initial Screen: PAI

Event ISDAT (Read data)

Event ISDST (Distribute data)

Data screen: Entries

Data screen PAI


Event DTAKE (Transfer data)

Event DSAVE (Save data)

Initial screen: Data from file

Initial Screen: PAI

Event ISDAT (Read data)

Event ISDST (Distribute data)

Data screen: Data from file

Data screen PAI


Event DTAKE (Transfer data)

Event DSAVE (Save data)Important: Mass insert / update!!

Dialog Direct Input

Note: Direct input is not used in CRM. Instead, mass data is processed via the Middleware.

The two diagrams compare events of the dialog and of direct input with each other.

The direct input mode calls the same events, however without running through screens.

Event DSAVE will only be performed in direct input after a few hundred objects (for example, BP), while this takes place in the dialog mode after each maintained object (for example, BP).

© SAP AG CR590 8-9

SAP AG 2002


Explain what is involved in working with direct inputName additional interfaces

Interfaces: Topic Objectives

© SAP AG CR590 8-10

SAP AG 2002

Direct Input (Events)

DINP1 Get header data

DINP2 Get and note data records

Note: Direct input is not used in CRM. Instead, mass data is processed via the Middleware.

To enhance the batch input procedure, the system offers the direct input technique, especially for transferring large amounts of data. In contrast to batch input, this technique does not create sessions, but stores the data directly. No screens are processed. To directly enter the data into the corresponding database tables, the system calls a number of function modules that carry out any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must only be executed in the background.

The BDT uses the event technique to work with direct input.

DINP1 gets the header data of an application object in a file-structure. This technique no longer needs to be programmed for extensions. DINP2 reads data records and checks / saves data in corresponding applications. To extend direct

input by an own table, you only have to create DINP2 for table-owning application. Table-participating applications do not have to extend DINP2, because save processes are carried out the by table-owning application.

© SAP AG CR590 8-11

SAP AG 2002

Direct Input: Flow without the BDT

Frontend

Data selec

-tion program

Frontend

Data selec

-tion program

Read datarecord

Read datarecord

Log: incorrectrecords

Data pool:incorrectrecords

INDX:currentstatus

UNIX file:incorrectrecords

SenderstructureSender

structureReceiverstructureReceiverstructure

UnixorExcelfile

Customer SAP

Restart

2

n

1

2

n

1

Conversion partand currencyconversion

Sender Structure

Receiver Structure

Function part

Prelim. run

SF1 SF2 SF3 SF4

EF1 EF2 EF3 EF4

Check

Save

Commit

Subs. run

This diagram represents direct input flow without the BDT. The customer creates a file for import into the SAP System. The sender structure in the file is identical to the sender structure for reading in the SAP System. The sender structure will be mapped to the receiver structure (BUS_DI). In the DI function part, the data will be checked by five events and loaded into the system. Several log files are written and incorrect records are stored in a separate file.

© SAP AG CR590 8-12

SAP AG 2002

Direct Input: Flow with the BDT I

Send

er S

truc

ture

Rec

eive

r Str

uctu

re

File BDTDI

Prelim. runPrelim. run

SaveSave

CommitCommit

Subs. runSubs. run

CheckCheck

ISSTAISSTA

DSAVEDSAVE

DINP2DINP2

ISDATISDAT

DINP1DINP1

...

Aut

omat

ic I

nteg

ratio

nMap

ping

The BDT uses the functions of DI while using all event function modules. For direct input there are the additional events DINP1 (header data) and DINP2 (detailed data of applications).

© SAP AG CR590 8-13

SAP AG 2002

Direct Input: Flow with the BDT II

Diagram 3: Events for maintenance without dialog

A

After entry(data views)

DSAVB

AUTH1

XCHNG

ISSTA

DINP1

Change?no

ja

DCHCK

Error?

no

yes

DTAKE

DLVE1

Block endor last data

record?

no

yes

B

DSAVE

DLVE2

Last data record?

no

yes

B

End

ISDAT

ISDST

DINP2

After entry (header views)

StartB

A

In the events, direct input uses the same coding as in the dialog mode. DINP1 and DINP2 are additional events for working with direct input.

© SAP AG CR590 8-14

SAP AG 2002

Direct Input (Data Transfer)

SAP BP Data2 BUT000 SPACE 0030001234567...2 BUT0BK SPACE 0030001234567...

SAP BP Addresses2 BUT020 SPACE 0030001234567...2 BUT021 SPACE 0031122334455...

Entry File

Application 1 Application 2

Rec. type

2222

Table

BUT000BUT020BUT021BUT0BK

0030001234567...0030001234567...0031122334455...0030001234567...

DataDel. Flag

SPACESPACESPACESPACE

BDTDistribute data records to applications

The complete file structure is separated into DI structures for each application. Each application carries out a DINP2 function module to check / save the data.

© SAP AG CR590 8-15

SAP AG 2002

Create a structure with field type CHAR

Append structure to main structure (in BP BUS_DI)

Customize append name (not structure name) in the BDT(control->tables)

Create the function module DINP2

Customize the BDT

Steps for Extending the Direct Input

© SAP AG CR590 8-16

SAP AG 2002

Other Interfaces

All kinds of interfaces allowed

Other interfaces call the BDT and use data

Use of BDT function modules beginning with BUS_FOREIGN_... )

The external interface is used in IBU Utilities for incoming documents

External interfaces are designed solely in external maintenance transactions (abbreviation: external maintenance). There are no restricting factors for the distribution of data fields on the screens of this maintenance transaction.

External maintenance and BDT maintenance can be fully integrated. You can call the BDT maintenance in transfer mode from the external maintenance. Data can be changed in both types of maintenance. Changes are also visible in each type of maintenance.

Each external interface is allowed to call the BDT via the "BUS_FOREIGN_..." function modules.

© SAP AG CR590 8-17

SAP AG 2002

Explain the steps for extending field groupings by own criteria


Field Grouping: Topic Objectives

© SAP AG CR590 8-18

SAP AG 2002

Field StatusHide

Display

Required entry

Optional entry

Determine field status of related fields together

Different field grouping criteria

Field grouping criteria can be added by the applications

(Examples from BP: Co.Code by FI: Sales Org. by SD)

Programmed field grouping

Targets of Field Grouping

Field groupings can be made using criteria of your choosing. The BDT supports the application when creating a maintenance transaction for one criterion and links the settings for various criteria during the runtime using predefined rules.

© SAP AG CR590 8-19

SAP AG 2002

Field Grouping: Field Groups

Group fields into field groups if theybelong together logically

are displayed / hidden together

Field grouping per field group

Function module for programmed field grouping

Assignment view --> field groups

Assignment field group --> screen fields

SORT 1SORT 1

SORT 2SORT 2

Field Groups FieldsNAME_ORG1NAME_ORG1

Search terms

Name 1Name 1

© SAP AG CR590 8-20

SAP AG 2002

Field Grouping: Field Status Bar

Field status bar 1 (200 characters)

+ * . - * 1 3Field group: 2

Field status bar 2 Field status bar 3

......... .........

Field Status+ Required entry

. Optional entry

* Display

- Hide

SPACE Not specified

Position in status bar corresponds to field group number (at present:maximum of 1750 field groups)

Each instance of the field grouping criterion is stored in the database for one record. Each position in the record represents one field group number. There are five values allowed (+, ., *,- and SPACE).

Radio buttons facilitate the Customizing in the maintenance view.

© SAP AG CR590 8-21

SAP AG 2002


Explain the steps for extending an existing search help

Search Help: Topic Objectives

© SAP AG CR590 8-22

SAP AG 2002

Each application can add elementary search helps

Activate / deactivate elementary search helps

Direct selection possible via '= ...'

Extensions without changes to objectsof the BDT


Targets for Search Help

© SAP AG CR590 8-23

SAP AG 2002

The search help of a different application can be extended via the Data Dictionary without changing the original search help

Append the additional search help to the main search help of the application

The elementary search help supports the extension of the collective search help

Search Help

© SAP AG CR590 8-24

SAP AG 2002

Steps for Extending the Search Help

Create elementary search help

Append elementary search help to main search help (for example, BP -> BUPA)

Transaction SE11

Function Goto --> APPEND search helps

The elementary search help of customers or development partners extends the existing collective search help (BP – BUPA).

© SAP AG CR590 8-26

SAP AG 2002

Targets of Change Document Evaluation

Central object service of the BDTEvaluation variants

In the dialogChanges per object instance (such as partner changes)Changes per object instance and field (field changes)

As a reportChange history (over several instances)

DivisibilityAdd new tablesAdd additional fields to existing tables

No changes to objectsof the BDTof other applications

© SAP AG CR590 8-27

SAP AG 2002

Change Document Evaluation: Realization

Write Change DocumentsChange document object per application (if own table exists!)Write change documents in event DSAVE

Evaluate Change DocumentsEvents

Event CHGD1 Transfer selection valuesEvent CHGD2 Collect change doc. objects with IDsEvent CHGD3 Change doc. header relevant?Event CHGD4 Change doc. item relevant?

CallChanges per object instance GUI function BUSAChanges per obj.instance & field GUI function BUSIChange history Report BUSCHDOC

Change documents are a generic service within the BDT.

Change documents are written to the database in event DSAVE.

Evaluation processing takes place in event CHGD1-4.

© SAP AG CR590 8-28

SAP AG 2002


Describe the concept of archiving in the context of the BDTUnderstand the events for archiving.

Archiving: Topic Objectives

© SAP AG CR590 8-29

SAP AG 2002

Standard SAP ArchivingArchiving object

Use of the ADK function modules (Archive Development Kit)

Archive administration with transaction SARA

Service Programs in the BDTProgram logic in reports

Processing of application data by event function modules

Archiving in the Context of the BDT

SAP standard archiving procedure. Advantages:

• Infrastructure of the Archive Development Kit (ADK)

• Log files of all archiving runs

• Table checking and Customizing are easily integrated

Service programs in the BDT. Advantages:

• The applications can be easily connected

• Can be extended without the need for modifications

© SAP AG CR590 8-30

SAP AG 2002

Archiving: Program Flow in the BDT

Data InputData Input

Check DataCheck Data

Sort DataSort Data

Create ArchiveCreate Archive


Close ArchiveClose Archive

LogLog

Data InputData Input

ARCH1ARCH1

Sort DataSort Data


ARCH2/3ARCH2/3

Close ArchiveClose Archive

LogLog

Check DataCheck Data

Write ArchiveWrite Archive

with the BDT Applicationswithout the BDT

Archiving without the BDT is extensive because various functions have to be developed.

Archiving with the BDT provides all generic functions for archiving processing. Only application-related function modules have to be programmed.

© SAP AG CR590 8-31

SAP AG 2002

Archiving: Event Function Modules

ARCH1Application-specific

ARCH2..*------ Write Data in Archive ---------- call function 'ARCHIVE_PUT_RECORD‘ exporting archive_handle = p_archive_handle record = lt_but000 record_flags = et_chart-del_flag record_structure = 'BUT000'.

Endfunction.

Unique Call of ADK FMs

© SAP AG CR590 8-32

SAP AG 2002

Archiving: Reports

BUSOBARCH for archiving dataARCH1 Check if data can be archived

ARCH2/3 Archive header data and dependent data

BUSOBARCH_DELETE for consistent deletion from the completed archive

ARCH4 interpret and delete archive data on database

BUSOBARCH_RELOAD for reloading from archivesARCH5 interpret archive data and check that it can be reloaded

ARCH6 interpret transferred data and write to the DB

Start the archiving processes with reports.

During the program flow of the report, several event function modules are carried out.

© SAP AG CR590 8-33

SAP AG 2002


Display the Customizing with the Visual Configuration Tool (VCT)Discuss the use of the VCT.

Visual Configuration Tool: Topic Objectives

© SAP AG CR590 8-34

SAP AG 2002

Visual Configuration Tool

Configuration via

Drag&Drop

(Visual Basic)

Screen layout and

screen sequence

TechniquesSubscreens

Generation of subscreen containers

An administrator is able to customize the screen layout and screen sequence via Drag&Drop.

The BDT standard Customizing table may be reactivated via the "SAP Standard" in the VCT.

© SAP AG CR590 8-35

SAP AG 2002


Discuss the functions of where-used lists

List examples for the use of where-used lists

Where-Used List: Topic Objectives

© SAP AG CR590 8-36

SAP AG 2002

Where-Used List for BP

Where-used List Process Goto System Help

Where-Used List

Valid All Future Past

UsageRIPERS01 Rheinhold MächterRelationships

Is contact person for0000000061 John Weaden/Cheltenham

Is identical toUVR1 Volker Jonas/40024 Düsseldorf

Policyholder1995/12345DE (PRIVATE LIABILITY) VL 555/143/141144 (WEALTH-FORMING LIFE INSURANCE)

Premium Payer1995/12345DE (PRIVATE LIABILITY)

Insured Person Account Holder Correspondence Recipient.

1996/12459fr (Wealth-forming)Claimant Payee Witness

KH 1996/13/3134555 (MOTOR LIABILITY CLAIM)

Valid from Valid to

19.08.1999

12.12.2002 13.12.1994

31.12.1999

31.12.9999

Where-used lists give an overview of where other components are using the object currently displayed . In this example you can see where the business partner is used.

Nodes can be extended. You are able to move into the corresponding application via double-click.

The overview consists of different screens that are time-dependent. These screens show the actual, future and past status of all the items in the where-used list.

© SAP AG CR590 8-37

SAP AG 2002

Can be extended by own object nodes

Customizing of view variants

Integration of own data function modules for data reading

Standard table (BUT030) for reading data of external systems

Function modules for events of the tree control

Link to other components via executing tree elements

Where-Used List Functions

© SAP AG CR590 8-38

SAP AG 2002

Define tree nodes

Customize a view variant for the tree

Assign the view variant to a context (for example, in the BP role)

Customize the screen in the BDT

Steps for Customizing the Where-Used List

© SAP AG CR590 8-39

SAP AG 2002

BDT Internal

Object Part(e.g. Role)

Object PartObject Part(e.g. Role)(e.g. Role)

ApplicationApplicationApplication

Event FMsEventEvent FMs FMs

ScreenScreenScreen PAIPAIPAIPBOPBOPBO

Screen SequenceScreen

Section

Section

View

View

Field group

Field group

View

DataSetsDataDataSetsSets

FM PAI/PBO/PBCFM PAI/PBO/PBCFM PAI/PBO/PBC

Function PartDI + Dialog

Dialog PartDialog

SAP BASIS

n m

1

n

nm

n

1

3

1n

1

1

1

This is an overview of the BDT Customizing. It can also provide support and be used as a check during the Customizing. However, this is not a final list.

BDT Customizing is divided into a dialog part and a function part.

The starting point for carrying out the BDT is always the application object or object part.

© SAP AG CR590 8-40

SAP AG 2002

Service Programs and Functionality: Unit Summary


Explain the different processing modes of the BDT and their effects

Explain the steps for extending the field grouping

Explain the steps for extending an existing search help

Describe change documents in the BDT

Describe the concept of archiving in the context of the BDT

Work with the Visual Configuration Tool

Adapt the where-used list

© SAP AG CR590 8-41

Exercises

Unit: Service Programs and Functionality Topic: Direct Input


• Make the extensions that have been carried out, direct input-enabled.

The technical consultants have to enable your extensions for Direct Input.

1-1 Control structure extensions for direct input.

1-1-1 What is the name of the prepared append structure to the structure BUS_DI?


_________________________________________________

1-1-2 Are there any new fields in the structure compared with table ZBUTHOBBY?

__________________________________________________

1-1-3 Why do you need this field?

__________________________________________________

1-1-4 Check the Customizing for BDT tables, whether the name of append (not the structure name) is defined.

Menu BUPT → BP Control → Tables

1-2 Create the program logic for event DINP2 and carry out the Customizing.


1-3 Customize the BDT control tables.


© SAP AG CR590 8-42

Exercises

Unit: Service Programs and Functionality Topic: Visual Configuration Tool (VCT)


• Customize screen sequences and screens using the VCT.

A business process has changed at short notice To improve support by the dialog, the administrator/application consultant was charged with changing existing screen sequences and screens.

2-1 Change the screen sequence and screen layout of your BP role ZC##10.

BUPT Menu → Customizing → Basic Settings → Screen Configuration → Main Screen Sequence

2-1-1 Change sequence of the tables Hobby and Date/Rating

2-1-2 Change screen sequence.

(Address, Central Data, Additional Data, Bank and Credit Cards, Relationships)

2-1-3 Check the result in the Business Partner dialog.


2-1-4 Reset the VCT settings.

BUPT Menu → Customizing → Basic Settings → Screen Configuration → Main Screen Sequence

Reset by “SAP Standard” and “Save”

All visible control tables in the screen layout are switched off if someone has saved the VCT changes.

© SAP AG CR590 8-43

Exercises

Unit: Service Programs and Functionality Topic: Where-Used List


• Extend the object part (BP role) by way of the where-used list in the dialog.

The IT department is charged with displaying in the BP, all applications where the BP is used.

3-1 Customize the application object BUPA for the tree of the where-used list.

Transaction SM30

3-1-1 Create your own node in the tree.

Customizing View V_TBZ5

Current node ZC##

Node text Object Group ##

3-1-2 Define a view variant for the objects of the where-used list.

Customizing View V_TBZ5E

View variant ZC##

Variant text Variant Group ##

You must double-click on the variant to reach the tree selection.

3-1-3 Assign your view variant to your object part.

Customizing View V_TBZ5A

View variant ZC##

Context (Role) ZC##10

© SAP AG CR590 8-44

3-2 Make the where-used list known to the BDT through the Customizing.

Menu BUPT → BP Control→ Screen layout

3-2-1 Create a field group for the where-used list.

Field group 730 + ##

Description Where-used list ##

3-2-2 Create the view for the where-used list and assign your field group.

View ZS##30


Application ZC##


Dataset ZD##10

Entry View X

Program name SAPLBUD0

Screen number 1800

Data screen X

Assigned Field Group 730 + ##

3-2-3 Create a section and assign it to the view.

Section ZA##30

Description Where-used list Group ##

Title Where-used list ##

Assigned View ZS##30


3-2-4 Assign the screen to the section.

Screen ZB##10

Position 400001

Section ZA##30

© SAP AG CR590 8-45

Solutions

Unit: Service Programs and Functionality Topic: Direct Input

1-1 Control structure extensions for direct input.

1-1-1 The name of the appended structure of BUS_DI is ZHOBBY_DI.


1-1-2 There is a field CHIND for setting the change indicators Insert, Update, Modify or Delete.

1-1-3 These change indicators are for the flow control during the coding of the application. Depending on the indicator in event DINP2, you can insert, update, modify or delete a record in the global memory.

1-1-4 The Append structure of direct input structure is customized in table ZBUTHOBBY for BDT processing.

Menu BUPT → BP Control → Tables

1-2 Create a function module in the object navigator. Z_ZC##_BUPA_EVENT_DINP2 for event DINP2 by using the Coding Appendix.

(SE80) SAP Menu → Tools → ABAP Workbench → Overview → Object Navigator → Choose Function Module with right Mouse Button → Create

1-3 Customize the BDT control tables.

Menu BUPT → BP control → Events → Events → Assign Event to Function Modules

© SAP AG CR590 8-46

Solutions

Unit: Service Programs and Functionality Topic: Visual Configuration Tool (VCT)

2-1 Change the screen sequence and screen layout of your BP role ZC##10.

BUPT Menu → Customizing → Basic Settings → Screen Configuration → General Data

If you are using the old dialog or you are not working in a CRM-System, use the path Screen Configuration→Main Screen Sequence.

2-1-1 Change sequence of the tables Hobby and Date/Rating. Call up the screen in the lower part of the VCT. Select the entry Date / Rating in the section and move it via Drag&Drop into the section Hobby.

2-1-2 Change the screen sequence via Drag&Drop of the screens.

→ Goto → Screen Sequence

2-1-3 Check the result in the Business Partner dialog. Transfer the data from the VCT to the SAP System and save.

→ Screen Configuration → Transfer


2-1-4 Reset the VCT settings.

BUPT Menu → Customizing → Basic Settings → Screen Configuration → General Data

Reset via → Edit → SAP Standard and Transfer

All visible control tables in the screen layout are switched off if someone has saved the VCT changes.

© SAP AG CR590 8-47

Solutions

Unit: Service Programs and Functionality Topic: Where-Used List

3-1 Customize the application object BUPA for the tree of the where-used list.

Transaction SM30

3-1-1 Create your own node in the tree. Select V_TBZ5 for the Customizing and press the button ‘maintain’. Select the application object BUPA. Click the pushbutton ‘new entry’ and create the node ZC##.

Customizing View V_TBZ5

Current node ZC##

Node text Object Group ##

3-1-2 Select V_TBZ5E for the Customizing and click the pushbutton ‘maintain’. Select the application object BUPA. Choose New Entry and create the view variant ZC##. Select the view variant and compose your screen.

Customizing View V_TBZ5E

View variant ZC##

Variant text Variant Group ##

You must double-click on the variant to reach the tree selection.

3-1-3 Select V_TBZ5A for the Customizing and click the pushbutton ‘maintain’. Select the application object BUPA. Select New Entry and create the Assignment for the object part (role) or in field context or transaction.

Customizing View V_TBZ5A

View variant ZC##

Transaction/Context ZC##10

© SAP AG CR590 8-48

3-2 Make the where-used list known to the BDT through the Customizing.

Menu BUPT → BP Control→ Screen layout

3-2-1 Create a field group for the where-used list.

BUPT Menu → BP Control → Screen Layout → Field Groups

Field group 730 + ##


3-2-2 Create the view for the where-used list and assign your field group.


View ZS##30


Application ZC##


Dataset ZD##10

Entry View X

Program name SAPLBUD0

Screen number 1800

Data screen X

Assigned Field Group 730 + ##

Menu BUPT → BP Control → Screen layout → Views → Assign View to Field Group

3-2-3 Create a section and assign it to the view.


Section ZA##30

Description Where-used list Group ##

Title Where-used list ##

Assigned View ZS##30


Menu BUPT → BP Control → Screen layout → Sections → Assign Section to Views

© SAP AG CR590 8-49

3-2-4 Assign the screen to the section.

Menu BUPT → BP Control → Screen layout → Screen → Assign Screen to Sections

Screen ZB##10

Position 400001

Section ZA##30

© SAP AG CR590 A-2

Coding Appendix

Exercise 2: Function Pool

FUNCTION POOL ZBUPA MESSAGE-ID R1.

************************************************************************ * Tables * ************************************************************************ TABLES: BUT000,

ZBUSFLDS, ZBUTHOBBY, ZTB001, ZTB001T.

************************************************************************ * Constants * ************************************************************************ CONSTANTS:

GC_ACTVT_DELETE LIKE BUS000FLDS-CHAR1 VALUE 'D', GC_ACTVT_INSERT LIKE BUS000FLDS-CHAR1 VALUE 'I', GC_ACTVT_UPDATE LIKE BUS000FLDS-CHAR1 VALUE 'U', GC_AKTYP_CHANGE LIKE TBZ0K-AKTYP VALUE '02', GC_AKTYP_DISPLAY LIKE TBZ0K-AKTYP VALUE '03', GC_FCODE_HOBBY_DELE LIKE TBZ4-FCODE VALUE 'ZC##_HOBBY_DELE', GC_FSTAT_OPTIONAL LIKE BUS000FLDS-FLDSTAT VALUE '.', GC_FSTAT_REQUIRED LIKE BUS000FLDS-FLDSTAT VALUE '+', GC_FSTAT_DISPLAY LIKE BUS000FLDS-FLDSTAT VALUE '*', GC_FSTAT_NONSPECIF LIKE BUS000FLDS-FLDSTAT VALUE ' ', GC_FSTAT_SUPPRESSED LIKE BUS000FLDS-FLDSTAT VALUE '-', GC_MESSG_ARBGB LIKE MESG-ARBGB VALUE 'ZBUPA', GC_MESSG_CANCEL LIKE MESG-MSGTY VALUE 'A', GC_MESSG_ERROR LIKE MESG-MSGTY VALUE 'E', GC_OBJAP_PARTNER LIKE TBZ1-OBJAP VALUE 'BUPA', GC_STATUS_DISPLAY LIKE TBZ0K-AKTYP VALUE '*', GC_X LIKE BOOLE-BOOLE VALUE 'X'.

************************************************************************ * Variables * ************************************************************************ DATA:

GV_AKTYP LIKE TBZ0K-AKTYP, GV_ZBUTHOBBY_LINACT LIKE SY-INDEX, GV_CNT_FIRST_OLD LIKE ZBUSFLDS-CNT_FIRST, GV_XSAVE LIKE BOOLE-BOOLE, GV_XUPDTASK LIKE BOOLE-BOOLE.

************************************************************************ * Structure * ************************************************************************ DATA:

GL_BUT000_OLD LIKE BUT000.

© SAP AG CR590 A-3

************************************************************************ * Internal Tables * ************************************************************************ Current memory, new status --------------------------------------------- DATA:

BEGIN OF GT_ZBUTHOBBY OCCURS 0. INCLUDE STRUCTURE ZBUTHOBBY.

DATA: XMARK LIKE BOOLE-BOOLE,LIKE BOOLE-BOOLE, END OF GT_ZBUTHOBBY,

Current memory, old status ---------------------------------------------

GT_ZBUTHOBBY_OLD LIKE ZBUTHOBBY OCCURS 0 WITH HEADER LINE, *------ Role categories ------------------------------------------------

GT_RLTYP LIKE BUS0RLTYP OCCURS 0 WITH HEADER LINE, *------ ZBUTHOBBY: Global memory, new status ---------------------------

MEM_ZBUTHOBBY LIKE ZBUSHOBBY OCCURS 0 WITH HEADER LINE, *------ ZBUTHOBBY: Global memory, old status ---------------------------

MEM_ZBUTHOBBY_OLD LIKE MEM_ZBUTHOBBY OCCURS 0 WITH HEADER LINE *------ Processed Partner ----------------------------------------------

BEGIN OF MEM_PARTNER OCCURS 0, PARTNER LIKE BUT000-PARTNER,

END OF MEM_PARTNER. ************************************************************************ * Controls: * ************************************************************************ CONTROLS: TCTRL_ZBUTHOBBY TYPE TABLEVIEW USING SCREEN '0020'.

© SAP AG CR590 A-4

Exercise 2: Screen 0010

Name Type Line Clmn Def.Length Vis.Length Inbound Outbound

BUT000-ZZCNT_FIRST Text 1 1 20 20

ZBUSFLDS-CNT_FIRST I/O 1 22 10 10 X X

BUT000-ZZCNTID Text 2 1 20 20

BUT000-ZZCNTID I/O 2 22 4 4 X X

ZTB001T-CNTTX I/O 2 29 40 40 X

Flow

PROCESS BEFORE OUTPUT.

MODULE PBO.

*

PROCESS AFTER INPUT.

MODULE PAI.

*

PROCESS ON VALUE-REQUEST.

FIELD ZBUSFLDS-CNT_FIRST MODULE F4_CNT_FIRST.

Flow

*--------------------------------------------------------------------------*

* Module PBO OUTPUT *

*--------------------------------------------------------------------------*

* *

*--------------------------------------------------------------------------*

MODULE PBO OUTPUT.

CALL FUNCTION 'BUS_PBO'.

ENDMODULE.

*--------------------------------------------------------------------------*

* Module PAI *

*--------------------------------------------------------------------------*

* *

*--------------------------------------------------------------------------*

MODULE PAI.

CALL FUNCTION 'BUS_PAI'.

ENDMODULE.

*--------------------------------------------------------------------------*

* Module F4_CNT_FIRST *

*--------------------------------------------------------------------------*

* F4 for the field„Date of the first contact“ *

*--------------------------------------------------------------------------*

MODULE F4_CNT_FIRST.

PERFORM F4_CNT_FIRST. ENDMODULE.

© SAP AG CR590 A-5

*-------------------------------------------------------------------------*

* Form F4_CNT_FIRST *

*-------------------------------------------------------------------------*

* F4 for the field „First contact“ *

*------------------------------------------------------------------------ *

FORM F4_CNT_FIRST.

*------ Local data declarations ------------------------------------------

CONSTANTS: LC_DYNAME LIKE D020S-PROG VALUE 'SAPLZBUPA',

LC_DYNAME LIKE D020S-PROG VALUE '0010',

LC_FLDNM LIKE FELD-NAME VALUE 'ZBUSFLDS-CNT_FIRST'.

DATA: LV_AKTYP LIKE TBZ0K-AKTYP,

LV_STATUS LIKE BUS000FLDS-CHAR1.

*------ Determine field status -------------------------------------------

CALL FUNCTION 'BUS_FMOD_STATUS_GET'

EXPORTING

I_FLDGR = '700' * ATTENTION FIELD GROUP NUMBER: note

IMPORTING

E_STATUS = LV_STATUS

*------ Determine activity for input help ------------------------------

IF LV_STATUS = GC_STATUS_DISPLAY.

LV_AKTYP = GC_AKTYP_DISPLAY.

ELSE.

LV_AKTYP = GC_AKTYP_CHANGE.

ENDIF.

*------ F4 for the date of birth ---------------------------------------

CALL FUNCTION 'BUS_DATEFIELD_POV'

EXPORTING

I_ACTIVITY = lv_aktyp

I_DYNAME = LC_DYNAME

I_DYNUMB = LC_DYNUMB

I_FLDNM = LC_FLDNM

CHANGING

C_FLDVAL = ZBUSFLDS-CNT_FIRST.

ENDFORM.

© SAP AG CR590 A-6

Exercise 2: Event Function Module

FUNCTION Z_ZC##_BUPA_PBO_ZC##10.

*--------------------------------------------------------------------------*

*"*"Local interface:

*--------------------------------------------------------------------------*

*------ Date of the first contact ------------------------------------------

PERFORM ZZCNT_FIRST_PBO.

*------ Rating of the first contact ----------------------------------------

PERFORM ZZCNTID_PBO.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZZCNT_FIRST_PBO *

*--------------------------------------------------------------------------*

* Represent date of the first contact

*--------------------------------------------------------------------------*

FORM ZZCNT_FIRST_PBO.

CALL FUNCTION 'BUS_DATEFIELD_PBO'

EXPORTING

I_VALUE_DB = BUT000-ZZCNT_FIRST

CHANGING

C_VALUE_DYNP = ZBUSFLDS-CNT_FIRST

C_VALUE_DYNP_OLD = GV_CNT_FIRST_OLD.

ENDFORM.

© SAP AG CR590 A-7

*--------------------------------------------------------------------------*

* Form ZZCNTID_PBO *

*--------------------------------------------------------------------------*

* Determine text for rating *

*--------------------------------------------------------------------------*

FORM ZZCNTID_PBO.

*------ Local data declarations --------------------------------------------

DATA: LV_STATUS LIKE BUS000FLDS-CHAR1.

*------ Do not read text if field hidden------------------------------------


EXPORTING

I_FLDGR = '701' *ATTENTION FIELD GROUP NUMBER: note

IMPORTING


CHECK LV_STATUS <> GC_FSTAT_SUPPRESSED.

*------ Rating not filled: Text initial ------------------------------------

IF BUT000-ZZCNTID IS INITIAL.

CLEAR ZTB001T-CNTTX.

*------ Rating filled: determine text---------------------------------------

ELSE.

IF ZTB001T-SPRAS <> SY-LANGU

OR ZTB001T-CNTID <> BUT000-ZZCNTID.

SELECT SINGLE * FROM ZTB001T WHERE SPRAS = SY-LANGU

AND CNTID = BUT000-ZZCNTID.

IF SY-SUBRC <> 0.

CLEAR ZTB001T-CNTTX.

ENDIF.

ENDIF.

ENDIF.

ENDFORM.

© SAP AG CR590 A-8

FUNCTION Z_ZC##_BUPA_PAI_ZC##10.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Check date of first contact-----------------------------------------

PERFORM ZZCNT_FIRST_PAI.

*------ Check rating of first contact---------------------------------------

PERFORM ZZCNTID_PAI.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZZCNT_FIRST_PAI *

*--------------------------------------------------------------------------*

* Check date of first contact *

*--------------------------------------------------------------------------*

FORM ZZCNT_FIRST_PAI.

*------ Check date of first contact-----------------------------------------

*------ ... Call up BDT FM for checking ------------------------------------

CALL FUNCTION 'BUS_DATEFIELD_PAI'

EXPORTING

I_PAST_ALLOWED = GC_X

I_FUTURE_ALLOWED = SPACE

IMPORTING

E_VALUE_DB = BUT000-ZZCNT_FIRST

CHANGING

C_VALUE_DYNP = ZBUSFLDS-CNT_FIRST

EXCEPTIONS

OTHERS = 1.

*------ ... Incorrect entry: issue error message----------------------------

IF SY-SUBRC <> 0.

PERFORM EXCEPTION_MESSAGE_SEND USING SY-MSGTY

'ZBUSFLDS-CNT_FIRST'.

ENDIF.

ENDFORM.

© SAP AG CR590 A-9

*&-------------------------------------------------------------------------*

*& Form EXCEPTION_MESSAGE_SEND *

*&-------------------------------------------------------------------------*

* Issue exception message via message handler *

*--------------------------------------------------------------------------*

* --> I_MSGTY Message type *

* --> I_TBFLD_STRG Cursor field or highlighted fields *

*--------------------------------------------------------------------------*

FORM EXCEPTION_MESSAGE_SEND USING I_MSGTY

I_TBFLD_STRG.

CALL FUNCTION 'BUS_MESSAGE_STORE'

EXPORTING

ARBGB = SY-MSGID

MSGTY = I_MSGTY

TXTNR = SY-MSGNO

MSGV1 = SY-MSGV1

MSGV2 = SY-MSGV2

MSGV3 = SY-MSGV3

MSGV4 = SY-MSGV4

TBFLD_STRG = I_TBFLD_STRG.

ENDFORM.

© SAP AG CR590 A-10

*--------------------------------------------------------------------------*

* Form ZZCNTID_PAI *

*--------------------------------------------------------------------------*

* Check rating of first contact *

*--------------------------------------------------------------------------*

FORM ZZCNTID_PAI.

*------ Local data declarations---------------------------------------------

DATA: LV_STATUS LIKE BUS000FLDS-CHAR1.

*------ Do not carry out check----------------------------------------------

*------ ... if field not included


EXPORTING

I_FLDGR = '701' * *ATTENTION FIELD GROUP NUMBER: note

IMPORTING

E_STATUS = LV_STATUS.

CHECK LV_STATUS <> GC_FSTAT_SUPPRESSED

AND LV_STATUS <> GC_FSTAT_DISPLAY.

*------ ... If field is not filled------------------------------------------

CHECK NOT BUT000-ZZCNTID IS INITIAL.

*------ Check rating--------------------------------------------------------

IF ZTB001-CNTID <> BUT000-ZZCNTID.

SELECT SINGLE * FROM ZTB001 WHERE CNTID = BUT000-ZZCNTID.

IF SY-SUBRC <> 0.

IF 1 = 2. MESSAGE E002. ENDIF.


EXPORTING

ARBGB = GC_MESSG_ARBGB

MSGTY = GC_MESSG_ERROR

TXTNR = '002'

MSGV1 = BUT000-ZZCNTID

TBFLD_STRG = 'BUT000-ZZCNTID'.

ENDIF.

ENDIF.

ENDFORM.


Exercise 2 – Event Function Modules

FUNCTION Z_ZC##_BUPA_EVENT_ISSTA.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Get start parameter ------------------------------------------------

CALL FUNCTION 'BUS_PARAMETERS_ISSTA_GET'

IMPORTING

E_AKTYP = gv_aktyp

E_XSAVE = GV_XSAVE

E_XUPDTASK = GV_XUPDTASK

TABLES

T_RLTYP = GT_RLTYP.

ENDFUNCTION.

FUNCTION Z_ZC##_BUPA_EVENT_ISDAT.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table BUT000 -------------------------------------------------------

PERFORM BUT000_ISDAT.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form BUT000_ISDAT *

*--------------------------------------------------------------------------*

* Table BUT000: Event ISDAT *

*--------------------------------------------------------------------------*

FORM BUT000_ISDAT.

*------ Get data from owning application------------------------------------

CALL FUNCTION 'BUP_BUPA_BUT000_GET'

IMPORTING

E_BUT000 = BUT000.

*------ Note status in current memory--------------------------------------

GL_BUT000_OLD = BUT000.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_XCHNG.

*--------------------------------------------------------------------------*

*"*"Local interface: *" EXPORTING *" VALUE(E_XCHNG) LIKE BUS000FLDS-XCHNG

*--------------------------------------------------------------------------*

*------ Initialize return parameters ---------------------------------------

CLEAR E_XCHNG.

*------Check BUT000 --------------------------------------------------------

PERFORM BUT000_XCHNG CHANGING E_XCHNG.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form BUT000_XCHNG *

*--------------------------------------------------------------------------*

* Table BUT000: Changes? *

*--------------------------------------------------------------------------*

* <-- E_XCHNG Set indicator: ‚Changes exist‘ *

*--------------------------------------------------------------------------*

FORM BUT000_XCHNG CHANGING E_XCHNG LIKE BUS000FLDS-XCHNG.

*------ Initialize return parameters----------------------------------------

CLEAR E_XCHNG.

*------ Set indicator: ‚Changes exist‘ -------------------------------------

IF BUT000 <> GL_BUT000_OLD.

E_XCHNG = GC_X.

ENDIF.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_DSAVEB.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table BUT000 -------------------------------------------------------

PERFORM BUT000_DSAVB.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form BUT000_DSAVB *

*--------------------------------------------------------------------------*

* Table BUT000: EventDSAVB *

*--------------------------------------------------------------------------*

FORM BUT000_DSAVB.

*------ Local data declarations -------------------------------------------

CONSTANTS: LC_SUBNAME LIKE DD02D-TABNAME VALUE 'ZBUT000'.

*------ Return data to existing application--------------------------------

CALL FUNCTION 'BUP_BUPA_BUT000_COLLECT‘

EXPORTING

I_SUBNAME = LC_SUBNAME

I_BUT000 = BUT000.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_DLVE1.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table BUT000 -------------------------------------------------------

PERFORM BUT000_DLVE 1.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form BUT000_DLVE1 *

*--------------------------------------------------------------------------*

* Table BUT000: Event DLVE1 *

*--------------------------------------------------------------------------*

FORM BUT000_DLVE1.

CLEAR BUT000.

CLEAR GL_BUT000_OLD.

ENDFORM.


Exercise 3 – Extended Check

FUNCTION Z_ZC##_BUPA_PAI_BUP300.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Last name ----------------------------------------------------------

PERFORM NAME_LAST_PAI.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form NAME_LAST_PAI *

*--------------------------------------------------------------------------*

* Check Last name *

*--------------------------------------------------------------------------*

FORM NAME_LAST_PAI.

*------ Local data declarations --------------------------------------------

DATA: LL_BUT000 LIKE BUT000,

LV_LENGTH TYPE I,

LV_NAME(40) TYPE C,

LV_STATUS LIKE BUS000FLDS-CHAR1.

*------ Do not carry out test ----------------------------------------------

*------ ... if field not ready for input


EXPORTING

I_FLDGR = '025'

IMPORTING

E_STATUS = LV_STATUS.

CHECK LV_STATUS <> GC_FSTAT_SUPPRESSED

AND LV_STATUS <> GC_FSTAT_DISPLAY.

*------ ... if field is not filled -----------------------------------------

CALL FUNCTION 'BUP_BUPA_BUT000_GET'

IMPORTING

E_BUT000 = LL_BUT000.

CHECK NOT LL_BUT000-NAME_LAST IS INITIAL.


*------ Check if at least one vowel is present in last name-----------------

IF LL_BUT000-NAME_LAST NA 'AEIOUÄÖÜaeiouäöü'.

IF 1 = 2. MESSAGE E001. ENDIF.


EXPORTING

ARBGB = GC_MESSG_ARBGB

MSGTY = GC_MESSG_ERROR

TXTNR = '001'

MSGV1 = LL_BUT000-NAME_LAST

TBFLD_STRG = 'BUT000-NAME_LAST'.

ENDIF.

ENDFORM.


Exercise 4 - Screen Screen 0020 Flow logic PROCESS BEFORE OUTPUT.

MODULE PBO_0020. LOOP AT GT_ZBUTHOBBY WITH CONTROL TCTRL_ZBUTHOBBY

CURSOR GV_ZBUTHOBBY_LINACT. MODULE GT_ZBUTHOBBY_INIT.

ENDLOOP. * PROCESS AFTER INPUT.

MODULE PAI. LOOP AT GT_ZBUTHOBBY.

MODULE GT_ZBUTHOBBY_MODIFY. ENDLOOP. MODULE GT_ZBUTHOBBY_LINACT_DETERMINE.

Program flow *--------------------------------------------------------------------------*

* Module PBO_0020 OUTPUT *

*--------------------------------------------------------------------------*

* Carry out control actions on the subscreen for PBO *

*--------------------------------------------------------------------------*

MODULE PBO_0020 OUTPUT.

CALL FUNCTION 'BUS_PBO'.

CHANGING

C_TC1 = TCTRL_ZBUTHOBBY.

ENDMODULE.


*--------------------------------------------------------------------------*

* Module GT_ZBUTHOBBY_INIT OUTPUT *

*--------------------------------------------------------------------------*

* Note number of lines *

*--------------------------------------------------------------------------*

MODULE GT_ZBUTHOBBY_INIT OUTPUT.

PERFORM GT_ZBUTHOBBY_INIT.

ENDMODULE.

*--------------------------------------------------------------------------*

* Form GT_ZBUTHOBBY_INIT *

*---------------------------------------------------------------------------

* Detemine number of lines *

*---------------------------------------------------------------------------

FORM GT_ZBUTHOBBY_INIT.

------ Local data declarations---------------------------------------------

DATA: LV_NUMBER(3) TYPE C,

LV_LINES LIKE SY-TFILL,

LV_LINES_MAX LIKE SY-TFILL,

LV_TEXT(30) TYPE C.

*------ Determine number of lines in work table---------------------------

DESCRIBE TABLE GT_ZBUTHOBBY LINES LV_LINES.

IF LV_LINES = 0.

LV_LINES_MAX = LV_LINES + SY-LOOPC.

ELSE.

LV_LINES_MAX = LV_LINES + SY-LOOPC - 1.

ENDIF.

*------ All visible lines of the step loop must be ready for input--------

*------ are visible if necessary under blanklines-------------------------

IF SY-STEPL = 1.

TCTRL_ZBUTHOBBY-LINES = GV_ZBUTHOBBY_LINACT + SY-LOOPC - 1.

IF TCTRL_ZBUTHOBBY-LINES > LV_LINES_MAX.

TCTRL_ZBUTHOBBY-LINES = LV_LINES_MAX.

ENDIF.

*------ Issue status text 'entry X of Y' -------------------------------

LV_TEXT = TEXT-XX1.

LV_NUMBER = GV_ZBUTHOBBY_LINACT.

REPLACE '&1' WITH LV_NUMBER INTO LV_TEXT.

LV_NUMBER = LV_LINES.

REPLACE '&2' WITH LV_NUMBER INTO LV_TEXT.

WRITE LV_TEXT TO ZBUSFLDS-POSTXT_ZBUTHOBBY RIGHT-JUSTIFIED.

ENDIF.

ENDFORM.


*--------------------------------------------------------------------------*

* MODULE GT_ZBUTHOBBY_MODIFY. *

*--------------------------------------------------------------------------*

* Save changes

*--------------------------------------------------------------------------*

MODULE GT_ZBUTHOBBY_MODIFY.

PERFORM GT_ZBUTHOBBY_MODIFY.

ENDMODULE.

*--------------------------------------------------------------------------*

* Form GT_ZBUTHOBBY_MODIFY

*--------------------------------------------------------------------------*

* Save changes

*--------------------------------------------------------------------------*

FORM GT_ZBUTHOBBY_MODIFY.

MODIFY GT_ZBUTHOBBY INDEX GV_ZBUTHOBBY_LINACT.

IF SY-SUBRC <> 0

AND NOT GT_ZBUTHOBBY IS INITIAL.

GT_ZBUTHOBBY-CLIENT = SY-MANDT.

GT_ZBUTHOBBY-PARTNER = BUT000-PARTNER.

INSERT GT_ZBUTHOBBY INDEX GV_ZBUTHOBBY_LINACT.

ENDIF.

ENDFORM.

*--------------------------------------------------------------------------*

* MODULE GT_ZBUTHOBBY_LINACT_DETERMINE. *

*--------------------------------------------------------------------------*

* Note new index

*--------------------------------------------------------------------------*

MODULE GT_ZBUTHOBBY_LINACT_DETERMINE.

PERFORM GT_ZBUTHOBBY_LINACT_DETERMINE.

ENDMODULE.

*--------------------------------------------------------------------------*

* Form GT_ZBUTHOBBY_LINACT_DETERMINE *

*--------------------------------------------------------------------------*

* Hobbys: note new index

*--------------------------------------------------------------------------*

FORM GT_ZBUTHOBBY_LINACT_DETERMINE.

GV_ZBUTHOBBY_LINACT = TCTRL_ZBUTHOBBY-TOP_LINE.

ENDFORM.



FUNCTION Z_ZC##_BUPA_PBO_ZC##20.

*"----------------------------------------------------------------------


*" IMPORTING

*" VALUE(I_ACTION) LIKE BUS000FLDS-CHAR1 OPTIONAL

*"----------------------------------------------------------------------

*------ Do not carry out actions during return from additional screen---

CHECK I_ACTION = '1'

OR I_ACTION = '2'.

*------ Sort entries according to hobby---------------------------------

SORT GT_ZBUTHOBBY BY PARTNER HOBBY.

*------ Output begins with the first entry------------------------------

GV_ZBUTHOBBY_LINACT = 1.

ENDFUNCTION.



FUNCTION Z_ZC##_BUPA_EVENT_ISDAT.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table BUT000 -------------------------------------------------------

PERFORM BUT000_ISDAT.

*------ Table ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_ISDAT.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_ISDAT *

*--------------------------------------------------------------------------*

* Table ZBUTHOBBY: Event ISDAT *

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_ISDAT.

*------ Partner was already being processed: read local memory-

READ TABLE MEM_PARTNER WITH KEY but000 partner.

IF SY-SUBRC = 0.

REFRESH GT_ZBUTHOBBY.

LOOP AT MEM_ZBUTHOBBY WHERE PARTNER = BUT000-PARTNER.

CLEAR GT_ZBUTHOBBY.

MOVE-CORRESPONDING MEM_ZBUTHOBBY TO GT_ZBUTHOBBY.

APPEND GT_ZBUTHOBBY.

ENDLOOP.

*------ Partner was not being processed: read database---------------------

ELSE.

SELECT * FROM ZBUTHOBBY

INTO TABLE GT_ZBUTHOBBY

WHERE PARTNER = BUT000-PARTNER.

ENDIF.

*------ Note old status of the current processing---------------------------

GT_ZBUTHOBBY_OLD[] = GT_ZBUTHOBBY[].

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_XCHNG.

*--------------------------------------------------------------------------*


*" EXPORTING

*" VALUE(E_XCHNG) LIKE BUS000FLDS-XCHNG

*--------------------------------------------------------------------------*

*------ Initialize return parameter-----------------------------------------

CLEAR E_XCHNG.

*------Check BUT000 -------------------------------------------------------

PERFORM BUT000_XCHNG CHANGING E_XCHNG.

CHECK E_XCHNG IS INITIAL.

*------ Check ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_XCHNG CHANGING E_XCHNG.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_XCHNG

*--------------------------------------------------------------------------*

* Table ZBUTHOBBY: Changes? *

*--------------------------------------------------------------------------*

* <-- E_XCHNG Indicator: ‚Changes exist‘ ‘ *

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_XCHNG CHANGING E_XCHNG LIKE BUS000FLDS-XCHNG.


DATA: LT_ZBUTHOBBY LIKE ZBUTHOBBY OCCURS 0 WITH HEADER LINE.

*------ Intialize return parameters-----------------------------------------

CLEAR E_XCHNG.

*------ Note new status in LT_ZBUTHOBBY ------------------------------------


LOOP AT GT_ZBUTHOBBY.

CLEAR LT_ZBUTHOBBY.

MOVE-CORRESPONDING GT_ZBUTHOBBY TO LT_ZBUTHOBBY.

APPEND LT_ZBUTHOBBY.

ENDLOOP.

*------ Set indicator: ‚Changes exist‘ ------------------------------------

IF LT_ZBUTHOBBY[] <> GT_ZBUTHOBBY_OLD[].

E_XCHNG = GC_X.

ENDIF.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_FCODE.

*--------------------------------------------------------------------------*


*" IMPORTING

*" VALUE(I_FCODE) LIKE TBZ4-FCODE OPTIONAL

*" EXPORTING

*" VALUE(E_XHANDLE) LIKE BOOLE-BOOLE

*--------------------------------------------------------------------------*

*------ E_XHANDLE Set to ‚X‘ by default-------------------------------------

E_XHANDLE = 'X'.

*------ Process own functions-----------------------------------------------

*------ ... Delete hobby ---------------------------------------------------

CASE I_FCODE.

WHEN GC_FCODE_HOBBY_DELE.

PERFORM GT_ZBUTHOBBY_DELETE.

*------ ... Other function codes: do not handle-----------------------------

WHEN OTHERS.

CLEAR E_XHANDLE.

ENDCASE.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form GT_ZBUTHOBBY_DELETE *

*--------------------------------------------------------------------------*

* Function ‚Delete hobbys’ *

*--------------------------------------------------------------------------*

FORM GT_ZBUTHOBBY_DELETE.

DELETE GT_ZBUTHOBBY WHERE XMARK = GC_X.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_DTAKE.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_DTAKE.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_DTAKE

*--------------------------------------------------------------------------*

* ZBUTHOBBY in local memory

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_DTAKE.

*------ Transfer new status-------------------------------------------------

DELETE MEM_ZBUTHOBBY WHERE PARTNER = BUT000-PARTNER.

LOOP AT GT_ZBUTHOBBY.

CLEAR MEM_ZBUTHOBBY.

MOVE-CORRESPONDING GT_ZBUTHOBBY TO MEM_ZBUTHOBBY.

APPEND MEM_ZBUTHOBBY.

ENDLOOP.

*------ Transfer old status-------------------------------------------------

READ TABLE MEM_PARTNER WITH KEY PARTNER = BUT000-PARTNER.

IF SY-SUBRC <> 0.

LOOP AT GT_ZBUTHOBBY_OLD.

CLEAR MEM_ZBUTHOBBY_OLD.

MOVE-CORRESPONDING GT_ZBUTHOBBY_OLD TO MEM_ZBUTHOBBY_OLD.

APPEND MEM_ZBUTHOBBY_OLD.

ENDLOOP.

*------ Note partner number in the directory of the processed partners -----

DELETE MEM_PARTNER-Partner where partner = BUT000-Partner

MEM_PARTNER-PARTNER = BUT000-PARTNER.

APPEND MEM_PARTNER.

ENDIF.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_DSAVC.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*


DATA: LT_PARTNER LIKE BUS_PARTNR OCCURS 0 WITH HEADER LINE.

*------ Get assignments 'temporary number->final number' -------------------

CALL FUNCTION 'BUP_BUPA_NUMBERS_READ'

TABLES

T_PARTNER = LT_PARTNER.

*------ Table ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_DSAVC TABLES LT_PARTNER.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_DSAVC *

*--------------------------------------------------------------------------*

* Complete data for table ZBUTHOBBY *

*--------------------------------------------------------------------------*

* --> T_PARTNER Assignment of temp.no. -> final no. for partner *

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_DSAVC TABLES T_PARTNER STRUCTURE BUS_PARTNR.


CONSTANTS: LC_TABLE_HOBBIES LIKE CDPOS-TABNAME VALUE 'ZBUTHOBBY'.

DATA: LV_INDEX LIKE SY-TABIX.

*------ Note final number--------

LOOP AT MEM_ZBUTHOBBY.

READ TABLE T_PARTNER WITH KEY PARTNR_TMP = MEM_ZBUTHOBBY-PARTNER.

IF SY-SUBRC = 0.

MEM_ZBUTHOBBY-PARTNER = T_PARTNER-PARTNER.

MODIFY MEM_ZBUTHOBBY.

ENDIF.

ENDLOOP.


*------ Detemine type of change per data record-----------------------------

SORT MEM_ZBUTHOBBY BY PARTNER HOBBY.

SORT MEM_ZBUTHOBBY_OLD BY PARTNER HOBBY.

CALL FUNCTION 'CHANGEDOCUMENT_PREPARE_TABLES'

EXPORTING

TABLENAME = LC_TABLE_HOBBIES

TABLES

TABLE_NEW = MEM_ZBUTHOBBY

TABLE_OLD = MEM_ZBUTHOBBY_OLD

EXCEPTIONS

NAMETAB_ERROR = 1

OTHERS = 2.

IF SY-SUBRC <> 0.

PERFORM EXCEPTION_MESSAGE_SEND USING GC_MESSG_CANCEL

SPACE.

ENDIF.

ENDFORM.


FUNCTION Z_ZC##_BUPA_EVENT_DSAVE.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Save data on database-----------------------------------------------

*------ ... Asynchronous (with update) -------------------------------------

IF GV_XUPDTASK = GC_X.

CALL FUNCTION 'Z_ZC##_BUPA_UPDATE' IN UPDATE TASK

TABLES T_ZBUTHOBBY = MEM_ZBUTHOBBY T_ZBUTHOBBY_OLD = MEM_ZBUTHOBBY_OLD.

*------ ... Synchronous (without update) ---------------------------------

ELSE.

CALL FUNCTION 'Z_ZC##_BUPA_UPDATE'

TABLES

T_ZBUTHOBBY = MEM_ZBUTHOBBY

T_ZBUTHOBBY_OLD = MEM_ZBUTHOBBY_OLD.

ENDIF.

ENDFUNCTION.


FUNCTION Z_ZC##_BUPA_UPDATE.

*--------------------------------------------------------------------------*

*"*"Update module:

*" * ATTENTION: Propertiess Update module


*" TABLES

*" T_ZBUTHOBBY STRUCTURE ZBUSHOBBY

*" T_ZBUTHOBBY_OLD STRUCTURE ZBUSHOBBY

*--------------------------------------------------------------------------*

*------ Update table ZBUTHOBBY ---------------------------------------------

PERFORM ZBUTHOBBY_UPDATE TABLES T_ZBUTHOBBY

T_ZBUTHOBBY_OLD.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_UPDATE *

*--------------------------------------------------------------------------*

* Update table ZBUTHOBBY *

*--------------------------------------------------------------------------*

* --> T_ZBUTHOBBY New status *

* --> T_ZBUTHOBBY_OLD Old status *

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_UPDATE TABLES T_ZBUTHOBBY STRUCTURE ZBUSHOBBY

T_ZBUTHOBBY_OLD STRUCTURE ZBUSHOBBY.


DATA: LT_ZBUTHOBBY LIKE ZBUSHOBBY OCCURS 0 WITH HEADER LINE.

*------ Add new data records------------------------------------------------


LOOP AT T_ZBUTHOBBY WHERE KZ = GC_ACTVT_INSERT.

LT_ZBUTHOBBY = T_ZBUTHOBBY.


ENDLOOP.

INSERT ZBUTHOBBY FROM TABLE LT_ZBUTHOBBY ACCEPTING DUPLICATE KEYS.

IF SY-SUBRC <> 0.

UPDATE ZBUTHOBBY FROM TABLE LT_ZBUTHOBBY.

ENDIF.


*------ Change existing data records----------------------------------------


LOOP AT T_ZBUTHOBBY WHERE KZ = GC_ACTVT_UPDATE.

LT_ZBUTHOBBY = T_ZBUTHOBBY.


ENDLOOP.

UPDATE ZBUTHOBBY FROM TABLE LT_ZBUTHOBBY.

IF SY-SUBRC <> 0.

INSERT ZBUTHOBBY FROM TABLE LT_ZBUTHOBBY ACCEPTING DUPLICATE KEYS.

ENDIF.

*------ Delete existing data records----------------------------------------


LOOP AT T_ZBUTHOBBY_OLD WHERE KZ = GC_ACTVT_DELETE.

LT_ZBUTHOBBY = T_ZBUTHOBBY_OLD.


ENDLOOP.

DELETE ZBUTHOBBY FROM TABLE LT_ZBUTHOBBY.

ENDFORM.


*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table BUT000 -------------------------------------------------------

PERFORM BUT000_DLVE 1.

*------ Table ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_DLVE1.

ENDFUNCTION.

*--------------------------------------------------------------------------*

* Form ZBUTHOBBY_DLVE1

*--------------------------------------------------------------------------*

* Table ZBUTHOBBY: Event DLVE1 *

*--------------------------------------------------------------------------*

FORM ZBUTHOBBY_DLVE1.

CLEAR GT_ZBUTHOBBY REFRESH GT_ZBUTHOBBY.

CLEAR GT_ZBUTHOBBY_OLD. REFRESH GT_ZBUTHOBBY_OLD.

ENDFORM.



*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*

*------ Table ZBUTHOBBY ----------------------------------------------------

PERFORM ZBUTHOBBY_DLVE2.

ENDFUNCTION.

*--------------------------------------------------------------------------* * Form ZBUTHOBBY_DLVE2 * *--------------------------------------------------------------------------* * Table ZBUTHOBBY: event DLVE2 * *--------------------------------------------------------------------------* FORM ZBUTHOBBY_DLVE2. CLEAR MEM_ZBUTHOBBY. REFRESH MEM_ZBUTHOBBY. CLEAR MEM_ZBUTHOBBY_OLD. REFRESH MEM_ZBUTHOBBY_OLD.

CLEAR MEM_PARTNER. REFRESH MEM_PARTNER.

ENDFORM.


Exercise 5 – Menu Function Module

FUNCTION Z_ZC##_BUPA_EVENT_DCUAC.

*--------------------------------------------------------------------------*


*--------------------------------------------------------------------------*


DATA: LT_CUA_EXC LIKE BUS000CUAF "Standard functions to be hidden

OCCURS 10 WITH HEADER LINE,

LT_CUA_EXC LIKE BUS000CUAF "Standard functions to be displayed

OCCURS 10 WITH HEADER LINE,

LV_STATUS(1) TYPE C.

*------ Read GUI functions for current screen------------------------------

CALL FUNCTION 'BUS_CUA_FUNCTIONS_GET'

TABLES

T_STND_EXCL = LT_CUA_EXC

T_FRTH_INCL = LT_CUA_INC.

*------ Function 'Delete hobby':

*------ Inactive, if hobbies not ready for input------------------------

*------ ... *------ Read field status ------------------------------------

READ TABLE LT_CUA_INC WITH KEY FCODE = GC_FCODE_HOBBY_DELE.

IF SY-SUBRC = 0.


EXPORTING

I_FLDGR = '702'

* ATTENTION Field group

IMPORTING


*------ ... Field group hidden: deactivate functions----------------------

IF LV_STATUS = GC_FSTAT_SUPPRESSED

ODER LV_STATUS = GC_FSTAT_DISPLAY.

DELETE LT_CUA_INC WHERE FCODE = GC_FCODE_HOBBY_DELE.

ENDIF.

ENDIF.

*------ Set GUI functions for current screen-----------------------------

CALL FUNCTION 'BUS_CUA_FUNCTIONS_SET'

TABLES

T_STND_EXCL = LT_CUA_EXC

T_FRTH_INCL = LT_CUA_INC.

ENDFUNCTION.