Sei sulla pagina 1di 302
CR590 BDT - Business Data Toolset CR590CR590 BDT BDT - - Business Business Data Data
CR590 BDT - Business Data Toolset
CR590CR590
BDT BDT - - Business Business
Data Data Toolset Toolset
 
SAP AG 2002
SAP AG 2002

2002/Q3 SAP BBPCRM / 300 Material number 5005 5126

Copyright
Copyright

Copyright 2002 SAP AG. All rights reserved.

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

All rights reserved.

SAP AG 2002

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 Server TM 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.

mySAP CRM 1 Col22
mySAP CRM 1 Col22
CR100 3 Days CRM Basics
CR100
3 Days
CRM Basics
CR100 3 Days CRM Basics CR010 2 Days CRM Overview CR400 3 Days Interaction Center in
CR100 3 Days CRM Basics CR010 2 Days CRM Overview CR400 3 Days Interaction Center in
CR010 2 Days CRM Overview
CR010
2 Days
CRM Overview
CR100 3 Days CRM Basics CR010 2 Days CRM Overview CR400 3 Days Interaction Center in
CR100 3 Days CRM Basics CR010 2 Days CRM Overview CR400 3 Days Interaction Center in
CR400 3 Days Interaction Center in CRM CR600 3 Days Marketing Planning & Campaign Management
CR400
3 Days
Interaction Center in
CRM
CR600
3 Days
Marketing Planning
& Campaign
Management
CR700
3 Days
CRM Service
CR800
5 Days
Internet Sales
(ex ECO220)
CR205
3 Days
Mobile Sales &
Mobile Service
CR900
3 Days
Analytical CRM

SAP AG 2001

mySAP CRM 2 Col22
mySAP CRM 2 Col22
CR100 3 Days CRM Basics CR225 2 Days SAP IPC Admin/Technology CR235 2 Days SAP
CR100 3 Days CRM Basics
CR100
3 Days
CRM Basics
CR100 3 Days CRM Basics CR225 2 Days SAP IPC Admin/Technology CR235 2 Days SAP IPC
CR100 3 Days CRM Basics CR225 2 Days SAP IPC Admin/Technology CR235 2 Days SAP IPC
CR225 2 Days SAP IPC Admin/Technology
CR225
2 Days
SAP IPC
Admin/Technology
CR235 2 Days SAP IPC Pricing CR245 2 Days SAP IPC Product Configuration
CR235
2
Days
SAP IPC Pricing
CR245
2
Days
SAP IPC Product
Configuration
CR010 2 Days CRM Overview
CR010
2 Days
CRM Overview
CR235 2 Days SAP IPC Pricing CR245 2 Days SAP IPC Product Configuration CR010 2 Days

SAP AG 2001

mySAP CRM 3 Col22
mySAP CRM 3 Col22
CR010 2 Days CRM Overview
CR010
2 Days
CRM Overview
CR550 3 Days Enhancing the CRM Middleware CR500 2 Days CRM Middleware Overview CR310 3
CR550
3
Days
Enhancing the CRM
Middleware
CR500
2
Days
CRM Middleware
Overview
CR310
3 Days
CR320
2 Days
CR540
2
Days
SAP Mobile
SAP Mobile
Application Studio
Application Studio
CRM Middleware
for Mobile Scenarios
Basic Concepts
Advanced Features
CR590
2 Days
BDT – Business Data
Toolset

SAP AG 2001

Course Prerequisites
Course Prerequisites
Course Prerequisites Essential: good knowledge of ABAP programming Recommended: experience with dialog programming 

Essential:

Course Prerequisites Essential: good knowledge of ABAP programming Recommended: experience with dialog programming 

good knowledge of ABAP programming

Prerequisites Essential: good knowledge of ABAP programming Recommended: experience with dialog programming  SAP AG

Recommended:

experience with dialog programming

SAP AG 2002

Target Audience
Target Audience
Target Audience Participants Technical consultants and developers who work with the BDT and develop new functions

Participants

Technical 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

SAP AG 2002

Duration:

2 days

2 days
2 days
2 days
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.

Course Overview CR590
Course Overview CR590
Course Goals Course Objectives Course Content Course Overview Diagram Main Business Scenario
Course Goals
Course Objectives
Course Content
Course Overview Diagram
Main Business Scenario

Contents:

SAP AG 2002

Course Goals CR590
Course Goals CR590
Course Goals CR590  SAP AG 2002 This course will prepare you to: Execute enhancements to

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 Objectives CR590
Course Objectives CR590
Course Objectives CR590  SAP AG 2002 At the conclusion of this course, you will be

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 Content CR590
Course Content CR590

Preface

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 2002

Course Overview Diagram CR590
Course Overview Diagram CR590
Course Overview Diagram CR590 Course Overview Program Logic Introduction to BDT Extensions with Table- Participating

Course Overview

Program Logic

Introduction to BDT

Extensions with Table- Participating Applications

BDT Basics

Extensions with Table- Owning Applications

Dialog

Service Programs and Functionality

SAP AG 2002

Main Business Scenario CR590 The IT department in the IDES company is required to extend
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 2002
Introduction to the BDT
Introduction to the BDT
Why the BDT? Targets
Why the BDT?
Targets

Contents:

Functionality

SAP AG 2002

Introduction: Unit Objectives
Introduction: Unit Objectives
Introduction: Unit Objectives  SAP AG 2002 At the conclusion of this unit, you will be

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: Overview Diagram
Introduction: Overview Diagram
Introduction: Overview Diagram Course Overview Program Logic Introduction to the BDT Extensions with Table- Participating

Course Overview

Program Logic

Introduction to the BDT

Extensions with Table- Participating Applications

BDT Basics

Extensions with Table- Owning Applications

Dialog

Service Programs and Functionality

SAP AG 2002

Introduction: Business Scenario Your IT team has been requested to extend objects that have been
Introduction: Business Scenario
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.
 SAP AG 2002
Business Data Toolset (BDT):
Business Data Toolset (BDT):

Definition:

Toolset for master data and simple transaction data

SAP AG 2002

Business Data Toolset (BDT): Definition: Toolset for master data and simple transaction data  SAP AG

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.

Design Targets
Design Targets

Extensibility

Configurability

Divisibility

Alternative user interfaces

Usability

Quicker development

Generic object services

SAP AG 2002

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.

Extensibility
Extensibility

Tables

Append / Include Structures

Own Tables

Screen Layout and Screen Sequence

Program Logic

Event Techniques

Field Checks

Data Retention

SAP AG 2002

Screen Layout and Screen Sequence Program Logic Event Techniques Field Checks Data Retention  SAP AG

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.

Extensibility: Development Cycle
Extensibility: Development Cycle

Distributed development in various systems

DevtPartner1 IS-U MM IS-B Central FI SD Data TR-TM IS-IS DevtPartner2 Customer
DevtPartner1
IS-U
MM IS-B
Central
FI
SD
Data
TR-TM
IS-IS
DevtPartner2
Customer

Without

modifications

SAP AG 2002

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.

Configurability: Screen Layout
Configurability: Screen Layout

Change Business Partner: Address

Partner

TESTER
TESTER

Name

Form of addr. 01 First name John Last name Tester
Form of addr.
01
First name
John
Last name
Tester

Address

Street/number

Ridge Road

 

11

Postcode/City

99999

Smithtown

Delivery district

123456

   

Transport zone

1122

 
123456     Transport zone 1122   SAP BP Form of addr. Partner First name

SAP BP

Form of addr.

Partner

Partner
Partner

First name

Last name

SAP BP Form of addr. Partner First name Last name
SAP BP Form of addr. Partner First name Last name
Form of addr. Partner First name Last name   Street/number BAS Postcode/City  
 

Street/number

BAS

Postcode/City

 

Delivery district

SD

Transport zone

name   Street/number BAS Postcode/City   Delivery district SD Transport zone  SAP AG 2002

SAP AG 2002

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.

Configurability: Customizing Screen Layout / Sequence
Configurability: Customizing Screen Layout /
Sequence
Configurability: Customizing Screen Layout / Sequence  SAP AG 2002 Configuration via Drag&Drop (Visual Basic)

SAP AG 2002

Configuration via Drag&Drop (Visual Basic)

Screen layout and screen sequence

Technology

Subscreens

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.

Divisibility
Divisibility

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

Choices

parts. These parts can be maintained individually. Choices Each object can be maintained in one or

Each object can be maintained in one or several object parts.

A

attributes is assigned to each BP role.

business partner can assume different BP roles. A range of

Each object can be created in just one object part.

Each object is always created as one whole part, no divisibility

is

Example, a contract account is always maintained with all

required.

attributes.

SAP AG 2002

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.

Example of Divisibility: BP Role
Example of Divisibility: BP Role

Policyholder

Premium Payer Borrower
Premium Payer
Borrower
Example of Divisibility: BP Role Policyholder Premium Payer Borrower  SAP AG 2002 Contract
Example of Divisibility: BP Role Policyholder Premium Payer Borrower  SAP AG 2002 Contract
Example of Divisibility: BP Role Policyholder Premium Payer Borrower  SAP AG 2002 Contract

SAP AG 2002

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

Usability with Any Object
Usability with Any Object
Others ApplObject ????
Others
ApplObject
????
Claims Capture ApplObject ICL IS-RE Contract ApplObject RECN
Claims
Capture
ApplObject
ICL
IS-RE
Contract
ApplObject
RECN
SAP BP ApplObject BUPA
SAP BP
ApplObject
BUPA
SAP BP- Relationships ApplObject BUPR Bank Account ApplObject BKK
SAP BP-
Relationships
ApplObject
BUPR
Bank
Account
ApplObject
BKK

SAP AG 2001

BDTBDT

Contract Account ApplObject FICA
Contract
Account
ApplObject
FICA

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

Development Without the BDT
Development Without the BDT
Processing Data Transactions Transfer Field Change Grouping ServiceService Document Evalutions Authori- Notes
Processing
Data
Transactions
Transfer
Field
Change
Grouping
ServiceService
Document
Evalutions
Authori- Notes
zations

SAP AG 2002

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.

Quicker Development With the BDT
Quicker Development With the BDT
Data Transfer ServiceService Authorizations Processing TA Change Doc. Eval. Notes Field Grouping
Data Transfer
ServiceService
Authorizations
Processing TA
Change Doc. Eval.
Notes
Field Grouping
Data Transfer ServiceService Authorizations Processing TA Change Doc. Eval. Notes Field Grouping  SAP AG 2002

SAP AG 2002

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.

Data Maintenance Functionality
Data Maintenance Functionality

Dialog Maintenance

Configuration 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)

Transfer Mode External Interfaces Authorization Checks Notes Change Documents (Planned)  SAP AG 2002

SAP AG 2002

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

Functionality
Functionality

Maintenance without a Dialog

Direct Input Maintenance Using Function Modules Change Documents

Archiving

Where-Used List

Screen Configuration using Drag&Drop (VCT)

SAP AG 2002

Change Documents Archiving Where-Used List Screen Configuration using Drag&Drop (VCT)  SAP AG 2002

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.

Introduction to the BDT: Unit Summary
Introduction to the BDT: Unit Summary
Introduction to the BDT: Unit Summary  SAP AG 2002 You are now able to: Define

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.

able to: Define the BDT and describe its history. List design targets of the BDT. Describe
BDT Basics
BDT Basics
System Architecture and Example Program with Selection Screen BDT Programming Positioning Application Objects and
System Architecture and Example Program with
Selection Screen
BDT Programming
Positioning
Application Objects and Applications
Basis and the BDT

Contents:

SAP AG 2002

BDT Basics: Unit Objectives
BDT Basics: Unit Objectives
BDT Basics: Unit Objectives  SAP AG 2002 At the conclusion of this unit, you will

SAP AG 2002

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

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: Overview Diagram
BDT Basics: Overview Diagram
BDT Basics: Overview Diagram Course Overview Program Logic Introduction to the BDT Extensions with Table- Participating

Course Overview

Program Logic

Introduction to the BDT

Extensions with Table- Participating Applications

BDT Basics

Extensions with Table- Owning Applications

Dialog

Service Programs and Functionality

SAP AG 2002

Architecture and Dialog Program: Unit Objectives
Architecture and Dialog Program: Unit Objectives
Architecture and Dialog Program: Unit Objectives  SAP AG 2002 At the conclusion of this unit,

SAP AG 2002

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

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

Client / Server Architecture
Client / Server Architecture
SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI Dispatcher Dispatcher Work Work Work Work Process Process Process
SAPGUI
SAPGUI
SAPGUI
SAPGUI
SAPGUI
SAPGUI
Dispatcher
Dispatcher
Work
Work
Work
Work
Process
Process
Process
Process
SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI Dispatcher Dispatcher Work Work Work Work Process Process Process Process

Work

Process

Work

Process

Work

Process

Work

Process

Presentation

Server

Layer

Application

Server

Layer

Process Work Process Work Process Presentation Server Layer Application Server Layer database  SAP AG 2001

database

SAP AG 2001

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.

User-Oriented View
User-Oriented View
Presentation Server Layer Work Process ABAP Program Application Server Layer Database
Presentation
Server
Layer
Work Process
ABAP Program
Application
Server
Layer
Database

SAP AG 2002

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.

Program Flow: What the User Sees
Program Flow: What the User Sees
Screen Screen Selection Selection Screen Screen List List Time  SAP AG 2001 Black Box
Screen Screen
Selection Selection Screen Screen
List List
Time
SAP AG 2001
Black Box

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.

Interaction Between Server Layers Program ABAP Program Start ABAP Processing Block ABAP Processing Block ABAP
Interaction Between Server Layers
Program
ABAP Program
Start
ABAP
Processing
Block
ABAP
Processing
Block
ABAP Runtime System
Start ABAP Processing Block ABAP Processing Block ABAP Runtime System  SAP AG 2001 Time Database

SAP AG 2001

 SAP AG 2001 Time

Time

Start ABAP Processing Block ABAP Processing Block ABAP Runtime System  SAP AG 2001 Time Database
Start ABAP Processing Block ABAP Processing Block ABAP Runtime System  SAP AG 2001 Time Database

Database

Table

Database Table
Start ABAP Processing Block ABAP Processing Block ABAP Runtime System  SAP AG 2001 Time Database

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.

Sample Program: Program Start
Sample Program: Program Start
Program Start

Program

Start

Program Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database
Program Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database
ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System
ABAP Program
Data objects
Screen
ABAP
Processing
Block
ABAP Runtime System
Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table
Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table

Repository

Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table
Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table

Database

Table

Database Table
Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table
Start ABAP Program Data objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table

SAP AG 2001

objects Screen ABAP Processing Block ABAP Runtime System Repository Database Table  SAP AG 2001 Time

Time

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.

ABAP Runtime System Sends Screen
ABAP Runtime System Sends Screen
Program ABAP Program Start Data objects Screen ABAP Processing Block ABAP Runtime System Time 
Program
ABAP Program
Start
Data objects
Screen
ABAP
Processing
Block
ABAP Runtime System
Time
 SAP AG 2001
Program Start Data objects Screen ABAP Processing Block ABAP Runtime System Time  SAP AG 2001

Database

Table

Database Table

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

User Leaves Selection Screen
User Leaves Selection Screen
Program ABAP Program Start Data objects Screen ABAP Processing Block ABAP Runtime System Time 
Program
ABAP Program
Start
Data objects
Screen
ABAP
Processing
Block
ABAP Runtime System
Time
 SAP AG 2001
Program Start Data objects Screen ABAP Processing Block ABAP Runtime System Time  SAP AG 2001

Database

Table

Database Table

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.

Program Requests Data Record from Database Program ABAP Program Start Data objects Database Table Screen
Program Requests Data Record from Database
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
ABAP Runtime System
Time
 SAP AG 2001

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.

Database Returns Data Record Program ABAP Program Start Data objects Database Table Screen ABAP Processing
Database Returns Data Record
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
ABAP Runtime System
Time
 SAP AG 2001

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.

Program Calls Screen Program ABAP Program Start Data objects Database Table Screen ABAP Processing Block
Program Calls Screen
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
Process
Before
Output
ABAP Runtime System
Time
 SAP AG 2001

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.

ABAP Runtime System Sends Selection Screen Program ABAP Program Start Data objects Database Table Screen
ABAP Runtime System Sends Selection Screen
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
Process
Before
Output
ABAP Runtime System
Time
 SAP AG 2001

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.

User Executes User Action Program ABAP Program Start Data objects Database Table Screen ABAP Processing
User Executes User Action
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
Process
Before
Output
Process
After
Input
ABAP Runtime System
Time
 SAP AG 2001

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.

Processing of the ABAP Processing Block Resumes Program ABAP Program Start Data objects Database Table
Processing of the ABAP Processing Block
Resumes
Program
ABAP Program
Start
Data objects
Database
Table
Screen
ABAP
Processing
Block
Process
Before
Output
Process
After
Input
ABAP Runtime System
Time
 SAP AG 2001

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

ABAP Program Flow and User Exits
ABAP Program Flow and User Exits
Screen Screen Screen Screen Screen Screen 1000 1000 2000 2000 3000 3000 PBO PBO PAI
Screen Screen
Screen Screen
Screen Screen
1000
1000
2000
2000
3000
3000
PBO PBO
PAI PAI
PBO PBO
PAI PAI
PBO PBO
PAI PAI
User User Exit Exit
Start
ABAPABAP ProgramProgram FlowFlow
Customer Customer Programs Programs
 SAP AG 2002

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.

Function Module Exit: Flow Diagram
Function Module Exit: Flow Diagram
Application Program X Function Group Exit Function Module EXIT_<prog_name>_001 CALL CUSTOMER FUNCTION
Application Program
X Function Group
Exit Function Module
EXIT_<prog_name>_001
CALL CUSTOMER
FUNCTION
IncludeInclude inin
CustomerCustomer
NamespaceNamespace

SAP AG 2002

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.

Function Module Exits
Function Module Exits
SAP Application Program X Function Group ABAPABAP ABAPABAP ScreensScreens ***Global Data*** DATA: gl_field 90009000
SAP Application Program
X Function Group
ABAPABAP
ABAPABAP
ScreensScreens
***Global Data***
DATA: gl_field
90009000
CALL CUSTOMER
FUNCTION '001‘
EXPORTING
i_vars = gl_field.
FUNCTION exit_prg_001.
*IMPORTING i_vars
INCLUDEINCLUDE ZXaaaU01ZXaaaU01
ENDFUNCTION.
*INCLUDE*INCLUDE ZXaaaU01ZXaaaU01
91009100
CALLCALL SCREENSCREEN 9000.9000.
<additional<additional
processingprocessing logic>logic>
TextText elementelement
GUIGUI interfaceinterface

SAP AG 2002

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.

BDT Programming: Topic Objectives
BDT Programming: Topic Objectives
BDT Programming: Topic Objectives  SAP AG 2002 At the conclusion of this topic, you will

SAP AG 2002

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

Differentiate between the BDT and conventional programming.

Overview of BDT Programming
Overview of BDT Programming
Overview of BDT Programming CustomerCustomer Customer ApplicationApplication Application Function Function Group Group
CustomerCustomer Customer ApplicationApplication Application Function Function Group Group Sub- Sub- FM FB screen
CustomerCustomer Customer
ApplicationApplication Application
Function Function
Group Group
Sub-
Sub-
FM FB
screen screen

SAP AG 2002

Application Program X Function Group Exit Function Module EXIT_<prog_name>_001 CALL CUSTOMER FUNCTION
Application Program
X Function Group
Exit Function Module
EXIT_<prog_name>_001
CALL CUSTOMER
FUNCTION
IncludeInclude inin
CustomerCustomer
NamespaceNamespace

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

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.

Overview of BDT Program Logic
Overview of BDT Program Logic
Overview of BDT Program Logic Visible Application Initial screen Data screen Control Tables DTITL DTITL DCUAD

Visible

Application

Initial screen Data screen Control Tables DTITL DTITL DCUAD DCUAC DCUAD DCUAC ISDAT Before Output
Initial screen
Data screen
Control Tables
DTITL
DTITL
DCUAD DCUAC
DCUAD DCUAC
ISDAT
Before Output
ISDST
Before Output
A
Before
Before
ISSTA
AUTH1
Call
Call
Call Subscreen
Call Subscreen
Start
Call Subscreen
Call Subscreen
Events
After Input
After Input
FCODE
FCODE
BDT
Screens
Cancel
Save
Back
Exit
XCHNG
XCHNG
XCHNG
XCHNG
Status
No
No
No
No
Change ?
Change ?
Change ?
Change ?
Fixed
Yes
Yes
Yes
Yes
DSAVB
Abbr.
No
Abbr .
No
Yes
Save ?
Save ?
Cancel ?
AUTH1
Yes
Yes
No
DCHCK
A
A
Program
DTAKE
DSAVB
DSAVB
A
DSAVC
AUTH1
AUTH1
DSAVE
DCHCK
DCHCK
DTAKE
DTAKE
Logic
DSAVC
DSAVC
DSAVE
DSAVE
DLVE1
DLVE2
End
Screen 1: Events with Dialog, Save Mode
Logic DSAVC DSAVC DSAVE DSAVE DLVE1 DLVE2 End Screen 1: Events with Dialog, Save Mode SAP
Logic DSAVC DSAVC DSAVE DSAVE DLVE1 DLVE2 End Screen 1: Events with Dialog, Save Mode SAP
SAP Basis

SAP Basis

SAP AG 2001

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

Positioning: Topic Objectives
Positioning: Topic Objectives
Positioning: Topic Objectives  SAP AG 2002 At the conclusion of this topic, you will be

SAP AG 2002

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

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

Positioning
Positioning
Positioning  SAP AG 2001
Positioning  SAP AG 2001
Positioning  SAP AG 2001

SAP AG 2001

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

Alternative User Interfaces
Alternative User Interfaces

SAPGUI

WEB

Alternative User Interfaces SAPGUI WEB Visual Basic CHECK   Function Check Module    
Alternative User Interfaces SAPGUI WEB Visual Basic CHECK   Function Check Module    

Visual Basic

Alternative User Interfaces SAPGUI WEB Visual Basic CHECK   Function Check Module    

CHECK

 

Function

Check

Module

Module

 
   
 

DB_UPDATE

Function

Data

Module

Retention

 
Module     DB_UPDATE Function Data Module Retention   Direct Input  SAP AG 2001

Direct Input

SAP AG 2001

Java
Java

Java

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.

Application Objects and Applications: Topic Objectives
Application Objects and Applications: Topic
Objectives
Application Objects and Applications: Topic Objectives  SAP AG 2002 At the conclusion of this topic,

SAP AG 2002

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

Define application objects and applications

Application Object
Application Object

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

Examples

BUPA

SAP Business Partner

BKKA

Bank Account

FICA

Contract Accounts

SAP AG 2002

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.

Positioning of the Business Data Toolset (BDT) Application Objects SAP-SAP- ContractContract BankBank AccountAccount
Positioning of the Business Data Toolset (BDT)
Application Objects
SAP-SAP-
ContractContract
BankBank AccountAccount
SAPSAP BPBP
AdditionalAdditional
BPBP RelationsRelations
AccountAccount
((BKKABKKA))
((BUPABUPA))
((BUPRBUPR))
((FICAFICA))
BPBP RelationsRelations AccountAccount ((BKKABKKA)) ((BUPABUPA)) ((BUPRBUPR)) ((FICAFICA))  SAP AG 2002
BPBP RelationsRelations AccountAccount ((BKKABKKA)) ((BUPABUPA)) ((BUPRBUPR)) ((FICAFICA))  SAP AG 2002
BPBP RelationsRelations AccountAccount ((BKKABKKA)) ((BUPABUPA)) ((BUPRBUPR)) ((FICAFICA))  SAP AG 2002
BPBP RelationsRelations AccountAccount ((BKKABKKA)) ((BUPABUPA)) ((BUPRBUPR)) ((FICAFICA))  SAP AG 2002
BPBP RelationsRelations AccountAccount ((BKKABKKA)) ((BUPABUPA)) ((BUPRBUPR)) ((FICAFICA))  SAP AG 2002

SAP AG 2002

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.

Applications
Applications

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 application

Decoupling

Communication between the applications is conducted via GET or COLLECT function modules

SAP AG 2002

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.

Application Objects and SAP Basis
Application Objects and SAP Basis
Application Objects BDT Application SAP-SAP- SAP- CustomerCustomer Customer ApplicationApplication Application II I
Application Objects
BDT
Application
SAP-SAP- SAP-
CustomerCustomer Customer
ApplicationApplication Application II I
ApplicationApplication Application
Function Function Group Group Sub- FuMo FB Sub- screen screen Function Function Group Group Sub-
Function Function Group Group Sub- FuMo FB Sub- screen screen Function Function Group Group Sub-
Function Function Group Group Sub- FuMo FB Sub- screen screen
Function Function
Group Group
Sub-
FuMo FB
Sub-
screen screen
Function Function Group Group Sub- FuMo FB Sub- screen screen
Function Function
Group Group
Sub-
FuMo FB
Sub-
screen screen

SAP BASIS

SAP AG 2002

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.

Basis and the BDT: Topic Objectives
Basis and the BDT: Topic Objectives
Basis and the BDT: Topic Objectives  SAP AG 2002 At the conclusion of this topic,

SAP AG 2002

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

Discuss the relationship between Basis and the BDT

Overview of Development with the BDT
Overview of Development with the BDT
ApplicationsApplications SAPSAP SAP ApplicationApplication Application II I SAPSAP SAP ApplicationApplication
ApplicationsApplications
SAPSAP SAP
ApplicationApplication Application II I
SAPSAP SAP
ApplicationApplication Application IIII II
CustomerCustomer Customer
ApplicationApplication Application 77 7
SAPSAP BPBP
(BUPA)(BUPA)
DevelopmentDevelopment

DDIC

SAP AG 2002

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.

BDT Development and the Development Workbench
BDT Development and the Development
Workbench
Function Function Function Modules Groups Groups ISSTAISSTA ISDATISDAT Events for Each Application ISDSTISDST
Function Function
Function Modules
Groups Groups
ISSTAISSTA
ISDATISDAT
Events for Each
Application
ISDSTISDST
GETGET
Events for
Screens
PBO Module
Tables
CollectCollect
Program Logic
PBO
• 0010 First Contact
PBCPBC
Events for Each
PAI Module
PBOPBO
View
PAIPAI
PAI
SAP AG 2002

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

b. Event prior to data entry Reading of texts from Customizing tables, formatting of the date etc.

c. Event following data entry. Checking of the entry values. Conversion of the date

Event for preparing tables (sorting, etc)

PBO

PAI

Note:

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

BDT Development: DWB - Events for Each Application
BDT Development: DWB - Events for Each
Application
ISSTAISSTA
ISSTAISSTA
ISDATISDAT ISDSTISDST
ISDATISDAT
ISDSTISDST
FCODEFCODE XCHNGXCHNG
FCODEFCODE
XCHNGXCHNG
DCHCKDCHCK DSAVBDSAVB
DCHCKDCHCK
DSAVBDSAVB
DTAKEDTAKE
DTAKEDTAKE
DSAVCDSAVC DSAVEDSAVE
DSAVCDSAVC
DSAVEDSAVE
DLVE1DLVE1 DLVE2DLVE2
DLVE1DLVE1
DLVE2DLVE2

SAP AG 2002

Initialization

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.

BDT Development: DWB - Events for Each View
BDT Development: DWB - Events for Each View

Change Business Partner

 

Partner

TESTER

 

Name

Form of addr. First name Last name

01
01

John

Tester

 

Address

Street/number

69121 Smithtown
69121
Smithtown

Postcode/City

ZZ

Date of first contact Rating of first contact

Date of first contact Rating of first contact

SAP AG 2002

Create Subscreen with Screen Painter

 

Screen type:

BUS_PBOBUS_PBO
BUS_PBOBUS_PBO
BUS_PAIBUS_PAI
BUS_PAIBUS_PAI
 

activate subscreen

 

Create layout

Flow logic

 

PBO module -> Call

PAI module

-> Call

Events – Create function modules for each view

Create FM "before screen call"Call Events – Create function modules for each view Create FM "before output" Create FB "after

Create FM "before output"Events – Create function modules for each view Create FM "before screen call" Create FB "after

Create FB "after input"Events – Create function modules for each view Create FM "before screen call" Create FM "before

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.

Tables
Tables

Existing tables can be extended by

Includes 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

SAP AG 2002

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.

BDT Development: Data Dictionary
BDT Development: Data Dictionary
ApplicationsApplications SAPSAP SAP SAPSAP SAP CustomerCustomer Customer ApplicationApplication Application II I
ApplicationsApplications
SAPSAP SAP
SAPSAP SAP
CustomerCustomer Customer
ApplicationApplication Application II I
ApplicationApplication Application IIII II
ApplicationApplication Application
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ
Application IIII II ApplicationApplication Application Table BUT000: Append structure ZZ ZZ Table ZZ

Table BUT000:

Append structure

ZZ

ZZ

Table ZZ

Development in the DDIC

SAP AG 2002

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.

BDT Basics: Unit Summary
BDT Basics: Unit Summary
BDT Basics: Unit Summary  SAP AG 2002 You are now able to: Describe in principle

SAP AG 2002

You are now able to:

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

Differentiate between BDT programming and programming with user exits.

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

Define application objects and applications

and application objects Define application objects and applications Discuss the relationship between Basis and the BDT.

Discuss the relationship between Basis and the BDT.

Dialog Contents: Views Field Groups Sections Screens Screen Sequences BDT Screen Processing GUI Menu 
Dialog
Contents:
Views
Field Groups
Sections
Screens
Screen Sequences
BDT Screen Processing
GUI Menu
 SAP AG 2002
Dialog: Unit Objectives
Dialog: Unit Objectives
Dialog: Unit Objectives  SAP AG 2002 At the conclusion of this unit, you will be

SAP AG 2002

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

Differentiate between a view and a screen.

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: Overview Diagram
Dialog: Overview Diagram
Dialog: Overview Diagram Course Overview Program Logic Introduction to the BDT Extensions with Table- Participating

Course Overview

Program Logic

Introduction to the BDT

Extensions with Table- Participating Applications

BDT Basics

Extensions with Table- Owning Applications

Dialog

Service Programs and Functionality

SAP AG 2002

Dialog: Business Scenario An employee requires a certain screen sequence and a certain screen layout
Dialog: Business Scenario
An employee requires a certain screen
sequence and a certain screen layout for a
business partner in the role "prospect".
 SAP AG 2002
Targets for Screen Layout Extensions and changes to screens are possible Add other fields in
Targets for Screen Layout
Extensions and changes to screens are possible
Add other fields
in new frames
in existing frames
Assign fields differently, even between screens
Merge screens
No changes to development environment objects
of the BDT
of other applications

SAP AG 2002

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

Screen->Section->View
Screen->Section->View

Screen Sequence

Screen->Section->View Screen Sequence Address Address R e l a t i o n s h i

AddressAddress

Relationships

Additional Partner Data

View 1

   

View 2

Section 1

View 3

 

View 4

Section 2

View 5

View 6

 

View 7

Section 3

View 8

SAP AG 2002

A screen contains one or more sections

A section contains one or

more views A 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.

Screen Layout: Screen Sequence ZF00
Screen Layout: Screen Sequence ZF00
Screen Layout: Screen Sequence ZF00  SAP AG 2002 A screen sequence contains one or more

SAP AG 2002

A screen sequence contains one or more screens

Screen Layout: Screen(s)
Screen Layout: Screen(s)
Screen Layout: Screen(s)  SAP AG 2002 A screen sequence contains one or more screens A

SAP AG 2002

A screen sequence contains one or more screens

A screen contains one or more sections

Screen Layout: View(s)
Screen Layout: View(s)
Screen Layout: View(s)  SAP AG 2002 A screen sequence contains one or more screens A

SAP AG 2002

A screen sequence contains one or more screens

A screen contains one or more sections

A view contains one or more field groups

Screen Layout: Field Group(s)
Screen Layout: Field Group(s)
Screen Layout: Field Group(s)  SAP AG 2002 A screen sequence contains one or more screens

SAP AG 2002

A screen sequence contains one or more screens

A screen contains one or more sections

A view contains one or more field groups

Screen Layout: Table Field(s)
Screen Layout: Table Field(s)
Screen Layout: Table Field(s)  SAP AG 2002 A screen sequence contains one or more screens

SAP AG 2002

A screen sequence contains one or more screens

A screen contains one or more sections

A view contains one or more field groups

Field groups contain one or more screen fields

View Definition
View Definition

Properties are summarized in a view if they

belong 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)

SAP AG 2002

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.

View Attributes
View Attributes

Event function modules

Before output (PBO): Display explanatory texts,

After entry (PAI): Field checks,

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

Only display view if

the application of the view is active

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

Flow logic of the subscreen

Call function module BUS_PBO in PBO (field grouping, messages)

Call function module BUS_PAI in PAI (determine cursor position)

SAP AG 2002

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.

Additional View Checks
Additional View Checks

Owning application of the view

Carries out checks in a function module

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

All other applications

Carry 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)

SAP AG 2002

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.

Section
Section

Assignment section --> views

Sequence of views by way of position numbers

Frame around a section (exception: header data)

Frame title for each section

SAP AG 2002

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

Screen
Screen

Assignment Screen --> Sections

Sequence of sections by means of item numbers

Representation as

normal screen (full screen) modal dialog box (pop-up)

Screen title for each screen

External screens (not created with the BDT)

SAP AG 2002

So-called subscreen containers are generated automatically In a new system, you may have to generate all screens. Tools -> generate subscreen containers.

Procedure - Step 1
Procedure - Step 1

Change Business Partner:

Change Business Partner:
Change Business Partner:
Change Business Partner:

SAP AG 2001

Empty screen container for screen B1

Procedure - Step 2
Procedure - Step 2

Change Business Partner: Address

Change Business Partner: Address
Change Business Partner: Address
Change Business Partner: Address

SAP AG 2001

Empty screen container for screen B1

Include screen title in screen container title

Procedure - Step 3
Procedure - Step 3

Change Business Partner: Address

Partner

   

TESTER

Partner     TESTER
Partner     TESTER
Partner     TESTER
Partner     TESTER
Partner     TESTER
Partner     TESTER

SAP AG 2001

Empty screen container for screen B1

Include screen title in screen container title

Fill 1st view for 1st section

Procedure - Step 4
Procedure - Step 4

Change Business Partner: Address

Partner TESTER
Partner
TESTER

Name

Partner TESTER Name
Partner TESTER Name
Partner TESTER Name
Partner TESTER Name
Partner TESTER Name
Partner TESTER Name

SAP AG 2001