Sunteți pe pagina 1din 135

ABAP CRM

Course Material
Index

1. Introduction to CRM

2. Coding in SAP CRM

3. Concept of GUID:

4. Business Transaction Programming Basics:

5. ABAP CRM Tables and FMs

6. CRM One Order Model

7. How to search & Impliment for BADIs

8. Enhancement Framework

1
Introduction to CRM

2
Introduction to SAP CRM: Scenario

Competitive markets, demanding customers, and the need to optimize internal processes put companies
under great pressure. They therefore demand a complete software solution that is easy to use, fully
integrated, customized to meet specific requirements, and flexible to implement.

What is CRM?
Customer Relationship Management (CRM) is a
business strategy that aims to optimize customer
interactions in order to maximize the success of the
business

₃ Customer Relationship Management can help you stay totally connected to your customer so you deliver
the kinds of products and services that they truly need. It keeps the lines of communication open and
helps create lasting and profitable relationships.

₃ Goal of the usage of Customer Relationship Management is also to achieve „One face to the customer“
that means independent via which channel the customer is contacting your company he or she should
get consistent and actual information.

₃ The SAP Business Suite is a suite of business applications to enable companies to manage the
entire value chain across business networks, transforming into a more adaptive business.

₃ The solutions in the SAP Business Suite are open and flexible, supporting databases,
applications, operating systems, and hardware platforms from most major vendors.
₃ The SAP Business Suite consists of the following SAP solutions:
₃ SAP ERP (Enterprise Ressource Planning)

3
₃ SAP CRM (Customer Relationship Management)
₃ SAP SCM (Supply Chain Management)
₃ SAP PLM (Product Lifecycle Management)
₃ SAP SRM (Supplier Relationship Management)

₃ With the SAP NetWeaver platform, IT can be aligned with business requirements. SAP combines
composition technologies and application functionality to reduce IT complexity and increase
business flexibility. With SAP NetWeaver, you can compose applications using enterprise services,
orchestrate business processes and events, manage enterprise information, and deliver applications
and content to users more quickly and cost-effectively.

Company Departments with Customer Interaction

₃ In daily business various departments like Marketing, Sales and Service interact directly and
regularly with customers.

₃ From a software point of view these employees need to have support to fulfill their daily tasks
in an efficient and customer-oriented way.

₃ Additionally based on the operational experiences it is necessary to monitor and analyze your
processes in particular to optimize your future business and customer contacts.

₃ In addition to fulfill the different requirements of various industries (e.g. for Media,
Utilities, Pharmaceuticals, Public Sector, Telecommunications, High Tech) SAP CRM
provides multiple industry-specific scenarios and customizing options.

4
Customer Interactions in Marketing

Key Processes
₃ Campaign management
₃ Customer segmentation
₃ Lead management
₃ E-marketing
₃ Trade Promotion Management (TPM)
₃ Marketing planning and analytics

₃ SAP CRM provides comprehensive marketing functionality for automating the planning,
execution, and measurement of marketing effort.
₃ It unites marketing planning, campaign management, e-marketing, lead management, marketing
analytics, and customer segmentation key functions on a comfortable and configurable interface.

₃ Initiatives toward reaching fixed company goals can be developed and carried out. To do this,
KPIs are determined and measured.

₃ Thanks to integrated analysis functions, the financial results brought about by marketing
plans and campaigns are recorded in real-time. This facilitates qualified decision-making.

Customer Interactions in Sales

Key Processes
• Customer order management, quotations, and contracts
• Account and contact management
• Opportunity management and pipeline
analysis
• Activity management
• Commissions and incentives
• Sales planning and analytics

₃ With Enterprise Sales, Telesales, Field Sales and E-Selling, SAP CRM offers companies first
class solutions for handling customer contact anytime, anywhere.

₃ SAP CRM prepares your sales force to be efficient with time and effective in action, provides the
knowledge needed to turn insight into action, and maintains focus on productive activity to
acquire, grow and retain profitable relationships.

₃ SAP CRM supports sales forecasting and analytics for historical and predictive information,
territory and account management to optimize and increase efficiency of your sales organization,
opportunity and pipeline management to provide full visibility into potential sales, sales processes
and methodologies to leverage company-specific best practices and seamless order to cash
processes to most effectively manage customer demand – consistent interactions, insightful
information, seamless integration, always accessible, simple to use.

5
Customer Interactions in Service
Key Processes

₃ Service Request, Service Order, and Contract Administration


₃ Complaint Management
₃ Case Management
₃ Installed Base Management Knowledge Management
₃ Workflow and Escalation Management
₃ Workforce Management
₃ Service Planning and Analytics

SAP CRM Service supports all aspects of service order processing within the service
organization, from responding to the customer's initial inquiry, quotation creation and
processing, order creation, and assignment to the most appropriate field service
representative, right through to confirmation and billing of the work performed for the
customer.

Customer Interaction Channels

Which channels does an enterprise use to interact with customers?

₃ Within the CRM environment due to the different requirements and processes of various industries there
are existing and supported different interaction channels with customers:
₃ Back-office
Personalized and web-based accesses offer a single-point of entry for all relevant tasks in
marketing, sales and service and integrate all systems that are relevant for an employee within a
single user interface.
₃ Field Service, Offline-User
Various field applications offer everywhere and anytime access to the required information and
processes of field service employees.
₃ Interaction Center
Via the Interaction Center fulfillment of required business processes via telephony and E-mail
integration is supported.
₃ Web Channel Management
SAP CRM offers a complete E-marketing-, E-commerce- und E-service platform with personalized,
convenient and consistent service 24x7x365. Customers can access and research information and
then purchase products or services anytime, anywhere.
₃ Partner Channel Management
Partner Channel Management with SAP CRM combines Web Channel Management and
traditional CRM to a comprehensive partner management solution (collaboration with
resellers, dealers, agents etc.)

SAP CRM Solution Map


SAP Customer Relationship Management provides the insight and analysis you need to
anticipate customer needs and build lasting, profitable customer relationship. SAP CRM
enables integrated industry-specific processes to support customer-facing departments in
6
marketing, sales, and services. Plus, you get a 360-degree view across all customer touch
points and interaction channels – including the Internet, interaction centers, and channel
partners – as well as powerful analytics.

₃ Streamlined business processes supported by technology, integrating customers, suppliers and business
partners, is the key to remaining successful in a competitive market. It can be difficult to visualize,
evaluate, and communicate these business processes. With SAP Solution Maps, you can understand
individual solutions quickly and appraise their potential value for your company. They help focus on the
core processes and functions that can increase a company’s ability to compete, strengthen relationships
with partners, and help a company become closely oriented to the markets and customers it serves.

₃ The Solution Map is a comprehensive collection of industry-specific and cross-industry solutions,


infrastructure and service blueprints, Solution Maps, and Collaborative Maps. Using the industry
knowledge and technical expertise SAP has acquired through extensive business experience and
research, Solution Maps outline specific ways that technology can help integrate companies’ existing
resources and extend business processes beyond the borders of traditional enterprises.

₃ You can access the SAP Solution Map for SAP CRM on the Service Marketplace via the alias
“solutionmaps”.

Solution Manager – CRM Content Supports


Implementation

₃ SAP CRM Business Scenarios are designed to help customers reduce costs, increase revenue, and
7
increase customer satisfaction. They support nested business processes in the areas of sales, service
and marketing, and across various communication channels.
₃ The SAP Solution Manager makes pre-configured CRM content in the form of hundreds of business
processes available.
₃ The business processes are displayed graphically using SAP Component Views®.
₃ CRM Business Content is delivered exclusively with SAP Solution Manager. You can regularly download
updated content from SAP Service Marketplace.

Basics and Architecture

₃ The SAP CRM solution is the sum of all CRM functions and incorporates CRM components as well as
the components SAP Business Intelligence (SAP BI), Supply Chain Management (SAP SCM), and SAP
ERP (SAP ECC or SAP R/3).
₃ A central CRM server with system access through various channels and a connection to other systems
are both contained in SAP Customer Relationship Management (CRM), a part of the SAP Business
Suite. The following application components are supported in SAP CRM:
₃ Interaction Center: Using integrated Interaction Center solutions, clients can contact sales or service
representatives by telephone, fax, or e-mail.
₃ Web Channel (Internet): Internet users may configure and order products or services using SAP CRM
Internet components.
₃ Mobile Clients/Handhelds: Mobile sales representatives and service engineers can access the SAP CRM
system from their laptops or other mobile devices to exchange up-to-date information with the central
CRM server.
₃ The SAP CRM solution offers you the following, fully-integrated connections:
₃ The SAP CRM system as a central CRM server with corresponding application components
₃ The SAP ERP system (SAP ECC or SAP R/3) as a back-end system with tried and true ERP functions
₃ The SAP BI system as a data warehouse solution with comprehensive statistical and analysis functions
₃ The SAP SCM system as a global Available-to-Promise (ATP) check and demand planning solution
₃ The SAP NetWeaver Portal as a tool that provides you with integrated access to all systems

8
SAP CRM and Other SAP Systems

₃ Data is exchanged between the CRM system and a connected ERP system (minimum SAP R/3 Release
3.1I) using the CRM Middleware. A plug-in installed in the SAP ERP system acts as a counterpart to the
R/3 adapter in the SAP CRM system, supporting data communication between the two systems. The
data exchange includes the initial transfer of Customizing, master, and transactional data to the CRM
System, and the transfer of delta data in both directions.
₃ Also a non-SAP ERP system can be connected to SAP CRM.

₃ Sales orders can be entered in the Internet Sales application component, the Interaction Center, a
mobile device, or the CRM server. To confirm whether the requested items can be delivered on time,
you need to run the Available-to-Promise (ATP) availability check. The SAP Supply Chain Management
component performs these functions.

₃ The SAP Business Information Warehouse (SAP BW) is used as a data source for parts of the SAP
CRM solution, and also contains data for consolidation and analysis.

As of SAP ECC 6.0, the plug-in will be contained directly in SAP ECC. Until SAP ECC 6.0
the plug-in is delivered separately and has to be installed.

CRM Middleware

9
₃ The SAP CRM solution supports the handling of CRM business objects (such as customers and
prospects, activities and opportunities, and products and product catalogs) in a variety of application
components including Internet Sales, Service Interaction Center, Telesales and Campaign
Management. Some of these components require external extensions for communication and
integration. These components will be described in more detail in later sections.

₃ The middleware layer supports the controlled data exchange with other systems such as mobile
clients, back-end systems, and data warehouses. A replication procedure guarantees consistent and
up-to-date data in the distributed local databases, especially for mobile users. Message queuing
ensures data delivery and processing.

₃ Software adapters are used to connect to external systems. These adapters are responsible for
assigning data and converting it to other formats. Both the ASCII adapter and external interfaces are
provided for this. The SAP CRM application components also exchange data with the middleware layer
using a CRM adapter.

The SAP CRM component builds on the SAP Basis system, which provides a proven
development platform, scalability, platform independence, and various other SAP tools.
Therefore, the SAP CRM solution can be configured just as flexibly as an SAP ERP system.

SAP CRM and Internet Applications

10
₃ With the Internet Sales and Internet Customer Self-Service application components, Internet users can
access the SAP CRM solution to configure and purchase products from published catalogs, or to request
a particular service. The shipped, standard templates provide a ready-to-run solution, but can also be
adjusted to meet individual requirements.

₃ The Internet application components are made available through a Web server. They are based on
J2EE (Java 2 Enterprise Edition) technology. This technology is an open, non-SAP platform.

₃ Product catalogs are exported from SAP CRM to an external index server for faster access to product
data.

₃ The Internet Pricing & Configurator (IPC) component provides configuration and pricing data for Web
applications. Since the IPC is designed as a separate component, it ensures the high performance
needed in an Internet environment.

₃ Basic CRM data like Business Partners, Products, Orders etc. have to be maintained and set up in
the CRM system itself and can be used in the Web environment.
₃ Within the Web Channel Applications you set up the design, logic etc. of your Web appearance.

SAP CRM Interaction Center Architecture

11
₃ The Interaction Center supports various communication channels, such as telephone, E-mail and fax,
as well as Internet based communication such as Voice over Internet Protocol (VoIP).

₃ You can connect communication channels such as telephone and E-mail using a Communication
Management System. This can be SAP BCM (Business Communication Management or a third party
product).

₃ The IC WebClient multichannel options are consolidated using the Integrated Communication Interface
(ICI) in the Interaction Center. Through the use of new technology such as eXtensible Markup Language
(XML) and Simple Object Access Protocol (SOAP), the open SAP CRM Integrated Communication
Interface (ICI) supports the integration of SAP CRM solutions with communication components such as
computer telephony integration, automatic call list distribution, interactive voice response, e-mail
administration, and chat systems. As a result, companies leverage their existing technology investments.
Beside of ICI the former used connection interface SAPPhone can still be used for upgrading
customers.

SAP CRM Mobile Sales/Service (Laptop Solution)

₃ The SAP CRM components Mobile Sales and Mobile Service support a company’s mobile field sales
and service employees.

₃ Users have complete access to all relevant data on their laptops. However, users can access data only
for their own area of responsibility (for example, all customers in one postal area).

₃ This data is updated by regular data exchange between laptops and the central server. The
communication station serves as a translator between the CRM server and the mobile clients.

₃ The mobile applications are customized using the SAP Mobile Application Studio, an object-oriented,
visual modeling tool.
The CRM Middleware provides the necessary functionality for the data replication to mobile
clients.

SAP CRM: Data Exchange with Laptops

12
₃ Basically the CRM Server contains the CRM Middleware, which handles the data exchange with internal
applications and external major components, such as an SAP ERP Back-End, an SAP Business
Information Warehouse or non-SAP systems. The CRM Middleware also synchronizes the databases of
Mobile Clients with the CRM database.

₃ Mobile Clients: usually laptops running the Mobile Sales/Service Application, which may include the
Sales Configuration Engine (SCE) and the Sales Pricing Engine (SPE)

₃ Mobile Clients typically connect temporarily (for example, via modem) to the CRM Server for data
exchange.
The Mobile Clients are connected to the CRM Server via the Communication Station.

The Continuous Focus on Usability: The SAP UI Roadmap

₃ An intuitive and user-friendly interface is key for the acceptance and success of a CRM implementation.
₃ Especially part-time users are expecting an easy-to-use and consistent user interface.
₃ Depending on the release SAP has offered different UIs.

₃ The CRM WebClient user interface used in CRM 2007 fulfills the above mentioned requirements in a
perfect way and is the result of the UI evolution based on customer and user experiences in different
13
industries.

User Interface Concept – Screen Structure

₃ The screen of the new CRM WebClient User Interface of CRM 2007 is divided into three main areas:
₃ At the top the header area is located.
₃ On the left the navigation bar is located. Navigation area and header area are also known as L-shape.
₃ The center part of the screen is the work area.

User Interface – L-Shape

₃ The L-shape within the user interface provides easy global navigation throughout the entire SAP CRM
application. Generic shortcuts for fast data entry, access, and other information are also included. The L-
shape consists of a header (top) and navigation (left-hand) area.

₃ The position and size of the L-shape is static and its content can be configured as business-
role dependent.

14
User Interface – Entry Page HOME

₃ The HOME page provides:


₃ A quick, direct overview of the current day
₃ Hyperlinks to more detailed information
₃ Predefined content for

– My appointments today – My
tasks today

– Reports – Alerts
– Workflow tasks
₃ The available content and screen structure of the HOME page can be configured per role.
Furthermore individual personalization by each user is supported.

15
User Interface – Overview Page

₃ The overview page provides an overview of all important information regarding a single object in
display mode. It is structured in assignment blocks which can be configured and personalized.
₃ In an assignment block form views, tables and hierarchies can be displayed.
₃ The overview page is non-editable.

₃ The overview page consists of header information that allows detailed object identification and a set of
related information.
₃ The overview page is the target page when following a hyperlink to an object instance.
The overview page contains the hyperlinks for cross navigation to related information.

Overview Page: Main User Interface Elements

16
₃ The main elements of the User Interface are:
₃ Work area title
₃ Work area toolbar
₃ Header area
Assignment blocks

Pre-Configured Roles in SAP CRM


The following applications are run with pre-configured roles:
₃ Sales
₃ Marketing
₃ Service
₃ Interaction Center
Partner Channel Management

SAP CRM Implementation & Operation


SAP Solution Manager

As a member of the project team that is going to implement the chosen SAP CRM solution, you use SAP
Solution Manager for the blueprint, configuration, and testing phase. During the implementation and after
the go-live phase, system administrators use SAP Solution Manager for system monitoring and SAP
services.

17
Your task is to customize a new SAP CRM business transaction according to your company
needs. Therefore you use the Implementation Guide (IMG) to configure a transaction type.

Challenges in Complex System Environments

SAP Solution Manager

SAP Solution Manager: A customer platform for implementation and


operation of SAP Business Suite

18
SAP Solution Manager supports you throughout the entire process of implementing and operating SAP
solutions. It is a platform that supports the industry-solution life-cycle from the business blueprint, through
configuration, to production operation. SAP Solution Manager offers central access to preconfigured
content, tools and methodology that you can use during when evaluating and implementing your systems.
For implementation, these include:
Contents predefined by SAP for evaluating and implementing industry solutions
ASAP procedures for implementing industry solutions
Tried and true implementation and test tools, for example the Implementation Guide (IMG) or the Test
Workbench
An authoring function that you can use to create your own project templates for your implementation
project. This makes SAP Solution Manager an ideal tool for SAP partners and companies involved in
global rollouts.
SAP Solution Manager Operations allows you to configure, administer, and monitor systems and
business processes for a solution. You can work with overall solutions as well as individual systems,
business processes, and software components. You can also set up your own solution support.

SAP Solution Manager as a Central Platform

This infrastructure at the customer’s site offers the following advantages:


SAP Solution Manager collects data from all connected systems. This allows you to access all of the
necessary information in these systems much quicker.
SAP Solution Manager keeps an up-to-date overview of the whole solution with processes and
dependencies
SAP Solution Manager is a tool to:
- Implement and test solutions
- Monitor solutions
- Maintain solutions
- Support users
Spend less time on finding errors and information, get quicker and better support
With SAP Solution Manager, SAP is able to deliver excellent support not only for single systems, but
for a customer’s entire solution.

19
SAP Solution Manager – Use in Implementation

SAP Solution Manager supports you in all phases of the evaluation and implementation. With SAP
Solution Manager, you can carry out the following activities in an evaluation and implementation project:
Project Preparation: The Roadmaps contain information and procedures for all phases of your
implementation project. Work with SAP Solution Manager begins after the evaluation phase. You first use
it to define the project by entering administrative data for the project management procedure (for example,
details about the project deadlines and resources). You set the project scope and you define the system
landscape that you require to implement your solution during the project preparation phase.
Business Blueprint: You define a Business Blueprint by documenting the organizational units, master
data, business scenarios, and business processes that you require to implement your solution. During the
Business Blueprint definition, you read the documentation supplied by SAP and partners, create your own
project documentation and assign individual process steps to transactions.
Realization: You configure your business scenarios in the development system. You check the test
cases delivered with your solution and assign further test cases to individual processes and process steps.
You carry out a consistency check for Customizing of the business processes. That is, you check whether
the various application components have been changed consistently. You synchronize Customizing with
Customizing Distribution. You can organize tests. You can reuse the test cases selected during
configuration. You can analyze the project at any time during its course to gain information about the
project status and the progress when testing or configuring.
Final Preparation: Go Live & Support: Perform remote SAP services and monitor their status. Monitor
and manage your systems using real-time alerts displayed in a system graphic, with weekly SAP
EarlyWatch Alert Reports and Central System Administration tasks.

Roadmap Details

20
Roadmaps are part of SAP Solution Manager. They contain the standard SAP implementation methodology
and cover the most important aspects and phases of a SAP implementation. The Roadmaps provide links to
accelerators and tools that perform project tasks.
You can download the project structure or a roadmap into MS Project to plan your project using the
data in the project structure or roadmap.

CRM Content Supports Implementation

21
SAP CRM Business Scenarios are designed to help customers reduce costs, increase revenue, and increase
customer satisfaction. They support nested business processes in the areas of sales, service, and marketing,
and across various communication channels.
The business processes are displayed graphically using SAP Component Views®.
CRM Business Content is delivered exclusively with SAP Solution Manager. You can download
updated content regularly from SAP Service Marketplace.

SAP Solution Manager – Use in Operations

SAP Solution Manager Operations allows you to configure, manage, and monitor systems and business
processes for a solution. You can work with overall solutions as well as individual systems, business
processes, and software components. You can also set up your own solution support. SAP Solution
Manager (Operations) provides an infrastructure for integrating SAP Support Services and your own
system administration activities.
As a system administrator, you can:
Perform remote SAP services and track their status
Monitor and manage your systems using:
- Real-time alerts displayed in a system graphic
- Weekly SAP EarlyWatch Alert reports
- Central System Administration tasks
Use best practice documents and services relating to Software Change Management
Use Integrated Message Handling for:
- Your own internal support organization
- Enhanced remote support by SAP

Service Level Reporting – Workflow Example

22
Service level reports provide you with a summary of the technical status of the systems in your solution.
For example, they provide an overview of the transactions that generate the greatest load. Service level
reporting is intended to ensure adequate levels of service for all users in accordance with business priorities
and at an acceptable cost. Service level reporting also enables you to manage service levels for business
processes. For example, you can define alert thresholds for transactions in a specific business process that is
carried out across several systems. Service level reports are then updated with this information.
When you set up Service level reporting, you define the contents of the reports and the frequency with
which they are generated.
Service level reports are generated from the aggregated SAP EarlyWatch Alert data that is regularly
sent from the satellite systems in your solution to your central SAP Solution Manager system.
In SAP Solution Manager, Service Level Reporting:
Is triggered regularly, for example, once each week. This is a simple process and requires no expert
knowledge since it is aimed at different areas of management (IT and application management).
Evaluates Key Performance Indicators (KPIs) and derives recommendations for management from
them. For example, it can recommend standard SAP services such as SAP EarlyWatch and Solution
Optimization Services.
Is based on the EarlyWatch Alert knowledge engine and is linked to relevant SAP services such as
SAP GoingLive Check and the SAP GoingLive Functional Upgrade Check

Monitoring with EarlyWatch Alert (EWA) & EarlyWatch

23
System Monitoring

System Monitoring enables you to integrate real-time alerts from SAP's Computing Center Management
System (CCMS), and to display them in the system graphics for your solution. For system monitoring,
software agents collect data that can be used to trigger alerts. The monitoring you configure here will form
the basis for Business Process Monitoring.
24
Central System Administration: You set up administrative tasks to manage the software components
defined in your solution. You can plan administrative tasks. Overview tasks are displayed in the solution
overview.

Business Process and Interface Monitoring

Business process monitoring should detect potentially critical situations as early as possible. The support
organization for your solution should also be able to react to problems as quickly as possible. To this end,
Business Process Monitoring integrates real-time alerts from SAP's Computing Center Management
System (CCMS) as well as additional alerts based on downloads from the remote systems. These alerts are
displayed on the system graphics for your solution.
Business Process Monitoring includes the observation of:
Business application logs (for example application log, worklist log, and so on)
Data transfer using interfaces between software components
Program scheduling management
Technical infrastructure and components that are required to run the business processes
Key figures
Execution of required periodic monitoring tasks
Business Process Monitoring is not only a tool, it comprises:
Detailed procedures for error handling and problem resolution
Precise definition of contact persons and escalation paths
Close integration of the customer’s support organization

Working with Support Desk – Support Process

25
The SAP support desk provides:
Problem monitoring, resolution, and processing
Escalation procedures
Interface with SAP and partners for message exchange
It contains an implementation methodology for the operation of your help desk, and allows for
successful capacity planning and service level reporting.
An integrated customer solution database facilitates gathering, storing, and reusing customer-specific
knowledge.
In addition, searching for and implementing SAP Notes is facilitated by SAP Service Marketplace and
SAP Note Assistant.

Customizing SAP CRM

26
You will now use the Implementation Guide (IMG) to configure the SAP CRM system to meet your own
requirements.
Additionally, you will learn about the enhancement of the application of customer-specific
programming using Business Add Ins (BAdIs).

Application and Customizing

There are two sides to a CRM system:


Application: A normal user calls transactions to carry out daily work (for example, creating sales
orders or accepting complaints as an Interaction Center Agent).
Customizing: Using the Implementation Guide (IMG), you can configure the CRM system to
specifically map the business process to your needs.
The Implementation Guide (IMG) explains the steps in the implementation process, the SAP standard
(factory) Customizing settings, and the system configuration activities. The hierarchical structure of the
IMG is based on the application component hierarchy and lists all the documentation that is relevant to
implementing the SAP system. The main section describes IMG Customizing activities, where the relevant
system settings are made.
By using SAP Solution Manager within the implementation phase, customers have direct integration
with the required Customizing settings for the selected business scenario.

Example: Creating a new Transaction Type


• Create a new transaction type.
• Make specific settings for your new transaction type.
• Maintain item category determination.
• Maintain copy control for transaction types.
• Test your new transaction type.

The Customizing example given above will be described in further detail on the following slides. It gives
you an idea of how a CRM system can be configured. Several Customizing activities are available.
Example: Your company uses opportunity management. However, the standard opportunity transaction
types do not fully meet your specific business requirements.
27
Therefore, you define a new opportunity transaction type and set the relevant parameters to match your
business requirements.
This should be carried out in a typical business scenario, such as creating an opportunity that may result in
a sales order.

Example: Step 1

The first step in the example is to create a new transaction type for the opportunity, which fulfills the
requirements for the business scenario in question.
Usually, this is done by copying an existing entry and changing the relevant parameters in a second step:
Check the standard Customizing for an appropriate entry and, if available, copy it.
Menu path:
SAP Easy Access Menu → Architecture and Technology → Configuration → Customizing → SAP
Reference-IMG → Customer Relationship Management → Transactions → Basic Settings → Define
Transaction Types

Example: Step 2

28
• Create a new transaction type.
• Make specific settings for your new transaction type.
• Maintain item category determination.
• Maintain copy control for transaction types.
• Test your new transaction type.

An important part of creating a new opportunity transaction type is to change the necessary parameters to
meet your specific needs and requirements.
Menu path:
SAP Easy Access Menu → Architecture and Technology → Configuration → Customizing → SAP
Reference-IMG → Customer Relationship Management → Transactions → Basic Settings → Define
Transaction Types

Example: Step 3

29
Simply creating a new transaction type is not sufficient to proceed further within the application.
Depending on the kind of transaction type and the kind of product used, a special item category will be
found. This item category manages further processing. Therefore, you must maintain item category
determination.
Menu path:
SAP Easy Access Menu → Architecture and Technology → Configuration → Customizing → SAP
Reference-IMG → Customer Relationship Management → Transactions → Basic Settings → Define Item
Category Determination

Example: Step 4

30
Maintain copy control at header and item level so that you can create follow-up documents such as
quotations or orders resulting from an opportunity.
Menu path:
SAP Easy Access Menu → Architecture and Technology → Configuration → Customizing → SAP
Reference-IMG → Customer Relationship Management → Transactions → Basic Settings → Copying
Control for Business Transactions:
Define Copying Control for Transaction Types
Define Copying Control for Item Categories

Example: Step 5

31
The last step will be to test your newly created opportunity within the application. To do this, select your
created transaction type.
Access path: E.g. in the role of a Sales Professional: Sales Cycle → Opportunities → Create

Business Add-Ins

If Customizing settings and parameters are not sufficient to meet your requirements, Business Add-Ins
(BAdIs) can be used for further enhancements.
By using Business Add-Ins, customers can insert additional code without modifying the original object.
Menu path:

32
SAP Easy Access Menu → Architecture and Technology → ABAP Workbench → Utilities
→ Business Add-Ins → Definition (SE18)
SAP Easy Access Menu → Architecture and Technology → ABAP Workbench → Utilities
→ Business Add-Ins → Implementation (SE19)
BAdI Implementations can also be created from the IMG.

33
CODING IN SAP CRM

34
Coding in SAP CRM
The coding in SAP CRM is not much different than ABAP coding in any other SAP ERP. ABAP being
the proprietary programming language of SAP, we use it in any of the ERP systems of SAP for
programming and SAP CRM is not an exclusion.

The statements and syntax is very much similar to the normal ABAP programming. The only difference is
CRM ABAP is more a "module" specific ABAP than a pure ABAP. SAP CRM ABAP usually refers to
ABAP coding in the CRM module.

In the early days CRM ABAP was at a "higher" release level than an R/3 system. This meant some
language features used in CRM weren't in use in R/3. The CRM applications are generally written in an
OO based fashion, using a loose MVC paradigm for the system design.

Technically CRM ABAP is not different from regular ABAP from the same release. It is the "design" of
the application which requires the knowledge. However keeping in mind there are some general
conventions in CRM that you will find that aren't always practiced in the R/3 system as much.

 BADI's are used exclusively. We typically don't use traditional user-exits in


CRM.
 Data is always read via function module and/or class method. It is easier to
read data of business objects in CRM via a well defined API instead of direct
table reads. Direct table reads are generally reserved for search scenarios.
 The system was design with full extensiblility in mind. In other words, almost
every business object has a standard "extension" mechanism for customization.
 The core "business logic" was designed UI independent. CRM up to 5.0 has
three UI's that utilize the same core business logic layer.
 ABAP code is written in a "CRM style". This style shows up in how variables
are named, and organization of code. If you understand this standard, the code
is very easy to read.
The key part to CRM ABAP is being able to understand the functional processes of the system and the
data model. It is not about knowing a specific dialect of ABAP, but understanding the application model.

35
Concept of GUID

36
Concept of GUID:
GUID is Globally Unique Identifiers, serve as primary keys for all tables in the CRM. A GUID is
generated by a special algorithm using as input data certain hardware information of the host computer,
the current system time, and a randomly generated number. The GUID can be represented in three
formats: a 32-byte character field or 22-byte character field or a 16-byte raw sequence. It is globally
unique in the sense that two GUIDs produced on any two computers (or even on the same one) at any
time can never be the same.

GUID identifies the master and transaction data uniquely in a system.

In CRM system every transaction/ Object have corresponding GUID and all these are interlinked with
each other. GUID's are also used to relate the HEADER and ITEM level information.

The Function Module ‘GUID_CREATE’ is used for creating GUIDs. Below is the sample code for
creating the GUID.

CALL FUNCTION 'GUID_CREATE' "


IMPORTING
ev_guid_16 = " guid_16
ev_guid_22 = " guid_22
ev_guid_32 = " guid_32
. " GUID_CREATE

37
Business Transaction
Programming

38
Business Transaction Programming Basics:

CRM_ORDER_READ is a universal function module which can be used to get the details of any
business transaction based on the Header GUID, Item GUID or both.
Always pass the IT_REQUESTED_OBJECTS structure to this function module to fetch the
required details only.
Sample objects that can be passed to IT_REQUESTED_OBJECTS are.

• APPOINTMENT Dates
• CUSTOMER_H Customer Header Data
• CUSTOMER_I Customer Item Data
• ORDERADM_H Administration Header
• ORDERADM_I Administration item
• PRIDOC Pricing document
• ORGMAN Organizational Data
• PARTNER Partner Quantity
• SCHEDLIN Schedule Lines

This function module can not be executed directly instead SAP has provided a report
CRM_ORDER_READ for the same for testing purpose. We can pass Business Transaction
Number (Object ID), Header GUID or Item GUID to this report to get the required details.
Like CRM_ORDER_READ we have specific read Function modules for each and every sub-
object data. For example consider the sub-object partner in the business transaction. The read
function module for partner would be ‘CRM_PARTNER_READ_OW’.
CRM_ORDER_MAINTAIN is a universal function module which can be used to modify/create
the data in the Business transactions. It takes the data related to the sub-objects in the import tables
and the information of modified data in a changing parameter CT_INPUT_FIELDS.
This function module can not be executed directly instead SAP has provided a report
CRM_ORDER_MAINTAIN for the same for testing purpose.
Like CRM_ORDER_MAINTAIN we have maintain function modules for each and every specific
sub-object. Example ‘STATUS’, we have ‘CRM_STATUS_MAINTAIN_OW’.
CRM_ORDER_SAVE : CRM_ORDER_MAINTAIN allows you to make changes to a document
in memory/buffer.
CRM_ORDER_SAVE allows you to save those changes made by CRM_ORDER_MAINTAIN, in
database.

CRM_ORDER_INITIALIZE : is used to clear the buffer memory and lock maintenance .


After calling the CRM_ORDER_SAVE, you need to call the following function modules in the
proper order to make the save successful and to initialize the order.
1. BAPI_TRANSACTION_COMMIT
2. CRM_ORDER_INITIALIZE
CALL FUNCTION 'CRM_ORDER_SAVE'
EXPORTING
IT_OBJECTS_TO_SAVE = GT_OBJ_GUIDS
IV_UPDATE_TASK_LOCAL = 'X'.
ENDIF.
39
COMMIT WORK.
CALL FUNCTION 'CRM_ORDER_INITIALIZE'
EXPORTING
IT_GUIDS_TO_INIT = IT_GUIDS_TO_INIT
IV_INIT_FRAME_LOG = 'X'
IV_KEEP_LOCK = 'X'.
CRM_ORDER_READ picks the data from the buffer memory so the old data that was fetched us
again being selected. When you close the session and then reopen, the buffer memory is empty so
new data is loaded.

Try refreshing the buffer before using CRM_ORDER_READ in the same session.

40
ABAP CRM Tables and FMs

41
Demystyfying SAP CRM Technical

1.0 Executive Summary


• Document Purpose

0 Provide functional consultants with the basic technical information enabling them to write
better Functional Specification, reducing the timeframe in development of an object.
1 Reduce the learning curve for Technical Consultants new to SAP CRM.

• Document scope
The document comprises of
· Details about most commonly used master/transaction/enhanced tables
· Details about most commonly used function modules for data
creation/retrieval/maintenance
· Most common data retrievals linking various master/transaction tables.
The information presented in this document has been gathered and analysed after discussions held
with various personnel involved in SAP CRM developments.

2.0 Tables
2.1 Master Data Tables

Table Name Description


Business Partner
BUT000 BP: General data
Contains Business Partner Number, Partner
Category, Partner Type, First Name, Last Name

BUT020 BP: Addresses


BUT050 BP relationships/role definitions: General data
Contains Relationship, Partner Number
(PARTNER1), Relationship Category
BUT051 BP Relationship: Contact Person Relationship
Similar to BUT050 , additionally contains Contact
Person’s Address data
BUT0BK Business Partner: Bank Data & Details
BP Number, Bank Key, Bank Country Key, Bank
Account Number
BNKA Bank Master Data
BUT100 BP: Roles
ADR2 Telephone Numbers (Business Address Services)
ADR6 SMTP Numbers (Business Address Services)
Contains Email – Id of the BP.
ADRC Addresses (Business Address Services)
BP’s Complete Address Details- City, Country,

Code, District, Street, Title No Etc


TSAD3T Table containing the Title text against a Title No.
Note:
Pass the langu key with the
language in which you want the
42
text.
COMM_PRODUCT Master Table for Product
CRMM_BUAG Master table for Business Agreement
CRMM_BUAG_H Header Data for Business Agreement such as Tax
Category, Tax Characteristic, Form key, Business
Agreement Class. Data in this table correspond to
ISU Contract account table FKKVKP.
CRMM_BABR_H Rule data for business agreements – data in this
table correspond to ISU Contract account table
FKKVK
Business Transaction(Service Contracts in Particular)
CNCCRMPRCUSZZBUR Condition Records for Service Contracts. We get
Basic Unit Rate, Standing Charge Rate etc.
(This is a Z table used in a leading ISU SAP-CRM
implementation. You can give the table SAP0090

this is a standard table. – in general all condition


tables have the naming convention CNCC*)
CRMD_ORDERADM_H Contains the Header Information for a Business
Transaction.
Note:
1. It doesn’t store the Business Partner
responsible for the transaction. To
get the Partner No, link it with
CRM_ORDER_INDEX.
2. This table can be used for search
based on the Object Id(Business
Transaction No).
CRMD_CUSTOMER_H Additional Site Details at the Header Level of a
Business Transaction
CRMC_PROC_TYPE Master table Business Transaction Type
CRMC_PARTNER_FCT Definition of Partner Functions
SCPRIOT Priorities for Activities with priority text.
Note:
Pass the langu key with the
language in which you want the
text.
CRMC_PROC_TYPE_T Text for a transaction type
CRMC_ACT_OBJ_T Objective Number and Text for Activities
TJ30T All the status code and text
Transaction Type and its Transaction Type
CRMC_PR_ASSIGN Object.
IBIB Installed Base/Ibase
IBIN Installed Base Components

2. 2 Transaction Data Tables

Table Name Description


CRMD_LINK Transaction GUID set for all the Business
Transactions
CRMD_ORDER_INDEX Contains Header as well as Item details for a
Business Transaction.
Note:
1. It doesn’t store the Business
Transaction No (Object ID).
43
To get the Business Transaction No
link the table with
CRMD_ORDERADM_H
2. This table can be used for search
based on the Partner No
CRMD_ORDERADM_I Stores the Item information for a Business
Transaction. The scenarios where we have a
Contract Header and within contract we have Line
Items for the contract, this table can be useful.
E.g. Service Contracts
CRMD_CUSTOMER_I Additional Site Details at the Item Level of a
Service Contract
SCAPPTSEG Table for individual Appointment Types for a
transaction.
CRM_JEST Individual Object Status for any business
transaction.
CRM_JCDS Current Status for a business transaction along
with set date, set time and status code.

2.3 Table Enhancements

Following tables were enhanced as per the project requirement in a leading ISU-SAP CRM
implementation. Easy Enhancement workbench can be used for enhancing most of the
transactions in CRM.

Table Name Description


BUT000 Fields such as Registration No, SIC Code, Cost to
Serve etc. that appear in the additional details tab
in BP transaction
CRMM_BUAG_H Fields such as Acc in Legacy, Invoice Output,
Clearing Category, Bill Form, Lock Process Type
etc. that appear in the Business Agreement tab in
BP transaction
CRMD_CUSTOMER_H This table is used as an extension of the service
contract header i.e. if there is a requirement to
add new fields to CRMD_ORDERADM_H then; this
table has to be used to add the fields.
CRMD_CUSTOMER_I This table is used as an extension of the service
contract header i.e. if there is a requirement to
add new fields to CRMD_ORDERADM_I then; this
table has to be used to add the fields. For e.g.
fields required for additional site details tab at item
level of Service Contract are added to this table.

44
3.0 Table Links for Data Retrieval

4.0 Data Retrieval


Linking Business Partner Tables logically

· BUT000 - contains the key as Business Partner Number – thus other details of business partner
such as Category, Type, Name, Language, Country, Contact Person etc can be obtained from it by
using the corresponding BP Number.
· BUT0BK- Using the BP Number and Bank Detail ID, details such as Bank Account Number,
Account Holder’s Name, and Name of Bank Account etc can be obtained.
· BUT020 – ADRC – ADR2 – ADR6 is the link of tables used to get the Address Details of the BP
corresponding to Business Partner Number (obtained from BUT000) and the address number from
BUT020 table.
· Roles of Business Partner can be obtained from the table BUT100.
· Contact Person and related details for a BP number (BUT000) can be obtained using the table
BUT051.
· Business Partner’s Roles and Relationship Details for BP number (BUT000) can be obtained
from BUT050.

45
Linking Service Contract Tables Logically

· CRMD_ORDER_INDEX: Contains GUID’s of all the transactions in CRM. Also provides a link to
connect Business Partner with the CRM Transaction.
· CRMD_CUSTOMER_H: Contains Additional Contract Details (enhanced fields), linked to Header
GUID.
· CRMD_CUSTOMER_I: Contains Additional Site Details (enhanced fields), links Header and Item
GUID’s for all the transactions.
· CRMD_ORDERADM_H: Contains Header Details. GUID field can be used to link with
CRMD_ORDER_INDEX.
· CRMD_ORDERADM_I: Contains Item Details. HEADER field can be used to link with
CRMD_ORDERADM_H (header guid).

Categorization of CRM Business Transaction based on Subobject Category

We have used Subobjects to categorize the Business Transactions in CRM for a leading ISU-SAP
CRM implementation.

Business Transaction Name SUBOBJECT CATEGORY


Activity BUS2000126
Service Contract BUS2000112
Lead BUS2000108
Opportunity BUS2000111
Task BUS2000125
Utility contract item BUS2000147

Note:

1. For Example if you want to retrieve all the activities in CRM, pass the OBJECT_TYPE as
‘BUS2000126‘ in CRMD_ORDER_INDEX table.
The Subobject Category can be customized for a business transaction from the transaction SPRO.

5.0 Function Modules


Function Group BUBA_3 – Contains function modules to read and change business partner addresses,
central data, bank details, payment cards, roles. Function modules for contact person and employee specific
information retrieval / change are also included.

For most of the function modules that retrieve data, business partner number is passed as import
parameter. Data is retrieved in the table specified in the interface. Return table returns status
messages.

For most of the function modules that add business partner related details, business partner
number and a table containing the details to be added are passed via the interface. Return table
returns status messages.

5.1 Data Creation

Name Description
GUID_CREATE Create GUID for a Business Transaction
BAPI_BUSPROCESSND_CREATEMULTI Bapi to create Service Contracts programmatically.
Pass the inputfields to be created in the contract.
Note: BAPI_BUSPROCESSND_SAVE must be called

46
after this function call to save the Service Contract.
BAPI_BUSPROCESSND_SAVE Bapi to save the Service Contracts.
BAPI_ECRMISUTO_INIT Initialize the creation of Ibase in CRM
BAPI_ECRMISUTO_CREATEMULTIPLE Create the Installed Base and its components.
Note:
Always call the function module
‘BAPI_TRANSACTION_COMMIT’
after call to any Bapi
CRM_IBASE_INITIALIZE Initialize the changes to be done in Ibase in CRM
CRM_IBASE_SAVE Call this FM to save the changes in the Ibase
BAPI_BUPA_FRG0130_CREATE Bapi to create Business Agreement for a customer
BAPI_BUPA_ADDRESS_ADD Add invoice address for business partner. Pass the
address type as 'rechnung' to add invoice address
BAPI_BUPA_BANKDETAIL_ADD Add bank details for the business partner
BAPI_BUPA_CREATE_FROM_DATA BAPI for business partner creation as Organization,
Person or Group in general role. Same BAPI can be
used to create Contact Person for the Business
Partner
BAPI_BUPR_RELATIONSHIP_CREATE Function module to establish the Business Partner
and Contact Person
Relationship. Pass the Relationship Category as
‘BUR001’
BAPI_BUPA_ROLE_ADD Add Role to Business Partner for e.g. Sold to Party
‘CRM001’, Contact Person ‘BUP001’
BAPI_BUPA_TAX_ADD BAPI Add Tax Number for the existing Business
Partner
BAPI_BUPA_FRG0040_CREATE Create Classification Data for a Business Partner
BAPI_BUPA_FRG0130_CREATE Create Business Agreement
BAPI_BUSPROCESSND_CREATEMULTI BAPI to create Contract. Populate the Header and
Line Item Details before calling the BAPI

5.2 Data Retrieval

Name Description
BAPI_BUPA_ADDRESSES_GET Determine All Addresses
BAPI_BUPA_ADDRESS_GETDETAIL Read Address
BAPI_BUPA_ADDRESS_GET_NUMBERS Read Address Numbers
BAPI_BUPA_BANKDETAILS_GET Determine All Bank Details
BAPI_BUPA_BANKDETAIL_GETDETAIL Read Bank Details
BAPI_BUPA_BANKDETAIL_NUMBERS Read Bank Details Numbers
BAPI_BUPA_CENTRAL_GETDETAIL Read Central Data
BAPI_BUPA_EXISTENCE_CHECK Check Existence of Business Partner
BAPI_BUPA_GET_NUMBERS Read Business Partner Numbers
BAPI_BUPA_RELATIONSHIPS_GET Determine All BP Relationships
BAPI_BUPA_ROLES_GET Determine All Roles
BAPI_BUPA_ROLE_EXISTENCE_CHECK Check Existence of Role
BAPI_BUPA_SEARCH Search Business Partner for Telephone, E-Mail,
Address
BAPI_BUPA_STATUS_GETDETAIL Business Partner: Read Status
BAPI_BUPR_ACTIVITYP_EXISTCHECK Check Existence of Contact Partner Relationship
BAPI_BUPR_CONTP_ADDRESSES_GET Read Contact Person Relationship Addresses
BAPI_BUPR_CONTP_ADDR_GETDETAIL Read Contact Person Relationship Addresses
BAPI_BUPR_CONTP_GETDETAIL Read Contact Person Relationship
BAPI_BUPR_EMPLO_ADDRESSES_GET Read Contact Person Relationship Addresses
BAPI_BUPR_EMPLO_ADDR_GETDETAIL Read Employee Relationship Address
47
BAPI_BUPR_EMPLO_GETDETAIL Read Employee Relationship
BAPI_BUPR_RELATIONSHIP_GET Read General Relationship
BAPI_BUPR_RELSHIP_CHECKEXIST Check Existence of General Relationship
BAPI_BUPR_RELSHIP_GET_DETAIL Read General Relationship
BAPI_BUPR_RESP_EMPLO_CHEKEXIST Read Relationship of Employee Responsible
BUPA_PARTNER_CONTACT_SEARCH Searches business partners for telephone, E-Mail,
address
ECRM_ISU_COMP_BY_ADDRESS Check for Existence of Ibase
CRM_ORDER_GET_HEADER_GUID Get Header GUID for Item GUID pass ref_kind as b
CRM_ORDERADM_H_READ_OW Read the Header Details for a Business
Transaction. Pass the Header guid.
CRM_ORDERADM_I_READ_OW Read the Line Item Details for a line item. Pass the
line item guid.
CRM_ORDER_READ Get all the Service Contract details.
Note: Pass the requested objects to fetch only the
required details.
This can also be used to get the details of
activities/leads/opportunities etc.
CRM_ORDER_GETSTATUS Get status of the Service Contract

Note: CRM_ORDER_READ Function Module

1. CRM_ORDER_READ is a function module which can be used to get the details of any
business transaction based on the Header GUID, Item GUID or both.
2. Always pass the IT_REQUESTED_OBJECTS structure to this function module to fetch
the required details only.
3. This function module can not be executed directly instead SAP has provided a report
CRM_ORDER_READ for the same for testing purpose. We can pass Business Transaction Number (Object
ID), Header GUID or Item GUID to this report to get the required details.

Some Exporting Parameters in CRM_ORDER_READ Function Module

Return Structure Name Details Fetched


ET_ORDERADM_H Header Details of a Business Transaction such as
OBJECT_ID, PROCESS_TYPE etc.
ET_ORDERADM_I Item Details of a Business Transaction such as
PRODUCT, PRODUCT_KIND, HEADER etc.
ET_ACTIVITY_H Header Details of an activity such as PRIORITY,
OBJECTIVE, Address Details etc.
ET_ACTIVITY_I Item Details of an activity.
ET_CUSTOMER_H Additional details at Header level
ET_CUSTOMER_I Additional details at Item level
ET_APPOINTMENT All the dates at Header and Item level
ET_PARTNER Partner Details at Header and Item level
ET_STATUS Status of Business Transaction at Header and Item
level
ET_BILLING Billing related details for a Business Transaction
both at Header and Item (This structure was
enhanced in a leading ISU SAP-CRM
implementation to include BUAG_ID(Business
Agreement) field in a Service Contract
ET_ORDPRP_OBJL_I_D Object List details such as PRODUCT
ET_DOC_FLOW Ref. Details of the previous Business Transaction

5.3 Data Maintenance

Name Description
BAPI_BUSPROCESSND_CHANGEMULTI Bapi to change Service Contracts
48
programmatically. Pass the inputfields to be
modified.
Note: CRM_ORDER_SAVE function module must be
called to save the changed contract explicitly after
call to this function module.
CRM_ORDER_SAVE Save the changes made to the Service Contract.
Just pass the Header_GUID of the service contract.
CRM_APPT_MAINTAIN_SINGLE_OW Maintain the Dates for a Service Contract (Start
Date, End date, Date of Sale, Planned Contract
Start Date etc). Don’t forget to pass the
input_fields to be maintained.
Note: CRM_ORDER_SAVE function module must be
called to save the changed contract explicitly after
call to this function module.
CRM_STATUS_MAINTAIN_OW Maintain the user status of Service Contracts.
Don’t forget to pass the input_fields to be
maintained.
Note: CRM_ORDER_SAVE function module must be
called to save the changed contract explicitly after
call to this function module.
CRM_IBASE_COMP_CHANGE Change the Installed Base components
Note:
Always call the FM
‘CRM_IBASE_SAVE’ to save the
changes done to Ibase
BAPI_BUPA_BANKDETAIL_CHANGE Change Bank Details
BAPI_BUPA_BANKDETAIL_REMOVE Delete Bank Details
BAPI_BUPA_CENTRAL_CHANGE Change Central Data
BAPI_BUPA_ADDRESS_CHANGE Change Address
BAPI_BUPA_ADDRESS_REMOVE Delete Address
BAPI_BUPA_BANKDETAIL_CHANGE Change Bank Details
BAPI_BUPA_BANKDETAIL_REMOVE Delete Bank Details
BAPI_BUPA_CENTRAL_CHANGE Change Central Data
BAPI_BUPA_CENTRAL_SAVEREPLICA ALE Replicating Central Data
BAPI_BUPA_STATUS_REMOVE Business Partner: Delete Status
BAPI_BUPR_ACTIVITYP_CHANGE Change Contact Partner Relationship
BAPI_BUPR_ACTIVITYP_DELETE Delete Contact Partner Relationship
BAPI_BUPR_CONTP_ADDR_CHANGE Change Contact Person Relationship Address
BAPI_BUPR_CONTP_ADDR_REMOVE Delete Contact Person Relationship Address
BAPI_BUPR_CONTP_CHANGE Change Contact Person Relationship Address
BAPI_BUPR_CONTP_DELETE Delete Contact Person Relationship
BAPI_BUPR_EMPLO_ADDR_CHANGE Change Employee Relationship Address
BAPI_BUPR_EMPLO_ADDR_REMOVE Delete Employee Relationship Address
BAPI_BUPR_EMPLO_DELETE Delete Employee Relationship
BAPI_BUPR_RELATIONSHIP_CHANGE Change General Relationship
BAPI_BUPR_RELATIONSHIP_DELETE Delete Relationships
BAPI_BUPR_RELATIONSHIP_REMOVE Delete General Relationship
BAPI_BUPR_RESP_EMPLO_DELETE Delete Relationship of Employee Responsible

5.4 Generic

Name Description
BAPI_CURRENCY_CONV_TO_INTERNAL Function Module to convert the Currency field to
internal format. Enter the currency and amount to
convert.
CCM_GO_BACK_MONTHS Go Back specified number of months from a given
date.

49
5.5 Other

Name Description
ECRM_ISU_ACTIVITY_DISPLAY Displays an activity by taking the Business
Transaction Number for the same.
CRM_CLM_CREATE_CALL_LIST Create call list for activities generated

6.0 Additional Details


6.2 Commonly Used Transactions

Transaction Description
Business Partner
BP (Creation/View/Modification)
CIC0 Customer Interaction Centre
CRMD_ORDER CRM Transaction (Create/View/Modify)
SPRO Configuration related settings
CRMD_CALL_LIST Create/ Maintain Call list
IB51 / IB52 / IB53 Ibase Creation / Change / View
COMMPR01 Maintain Products
PPOSA_CRM Display Organizational Model
SBDM Bdoc maintenance
SMOEAC Administration console – CRM Middleware
SMQ1,SMQ2 Queue monitoring transactions for inbound
and outbound queues.
SMW01 Transaction for monitoring bdocs.

50
CRM One Order Model

51
CRM One Order Model
What are Business Transactions?
Examples:
• Activities
• Tasks
• Leads
• Opportunities
• Sales Orders
• Service Notifications
• Service Orders
• Contracts
• Purchase Orders
• Quotations
• Invoice Requests

What is the „CRM One Order“ Concept?


In SAP CRM mixed documents are possible, for example
 Activity
 plus Sales
Order
 plus Service
Order
 in one document

The Business Transactions in SAP CRM use the „CRM One Order“ model, which is the
foundation for a:

Unified structure for all business partner-specific transactions


• Multi-functional business transactions: one instance approach

• Easy transformation between different transaction object types

Design of central components as compactly / slim as possible Construction kit principle

Advantages of the One-Order Concept


• Split fields into small logical business groups Reusable
objects

52
• Avoid big programs and module pools
• Simple and consistent flow logic for all objects and all levels Handling of error
messages
• Parallel programming possible

• The split of fields into small logical business groups enables the reusage of objects/business
groups, what in the end avoids big redundant programs and/or module pools
• The core components can always be reused (see later slides)
• Therefore no redundant coding for different transaction types necessary
• Therefore less error prone
• The data is send via the same Middleware Bdoc and therefore the mapping to other systems
is also reusable
• Same error messages for the same problem independent which transaction type causes the error

SAP CRM One-Order vs. SAP ERP


R/3-Sales-Document
 E.g. 210 fields in one table (item table)
 not all fields are used by all document types

CRM-Document
 the same data are split into 5 tables
 each document type uses the appropriate tables
o sales data
o shipping data
o pricing
o purchase data
o partners
o service

No More Huge Modulpools

53
SAP CRM One-Order vs. Mobile Sales
The business transaction objects on Mobile Sales have a data model similar to SAP ERP

Different tables for the different document types


Mapping between the two data models done in the Mobile Bridge of the CRM Middleware

• The shown tables give an overview of the used tables in SAP Mobile Sales for sales orders.
Activity information for example is stored in other tables (SMOVBKA,…).
• For further details regarding the CRM Middleware and Mobile Sales/Service please referr to
the corresponding courses

The Playground
Foundation of BT customizing, defined by SAP business transaction object types

54
Foundations Of Business Transaction Customizing (1)

Predefined by SAP: Maximal possible structure of a business transaction


· Definition of basic business transaction - object types
· Definition of business transaction object type - combinations
· Definition of business transaction item – object types
· Definition of assignment of transaction item - object type to transaction - object types

Foundations Of Business Transaction Customizing (2)

The diagramm gives an overview, how the structure of a business transaction is defined. (table
names in orange)
· Definition of basic business transaction - object types: (eg.: BUS2000111 Opportunity;
BUS2000112 Service Contract; BUS2000115 BUS2000126 Business Activity; etc…) This table
[CRMC_SUBOB_CAT] is the design time entry point on header level and defines the existing
header object types
· Definition of business transaction object type - combinations
In this table [CRMC_BUS_SUBOB_C] it is defined, which (header) object types can be combined
(eg.: That a „SALES“ business transaction (BUS2000115) can be combined with “SALES”
(BUS2000115) and also Business Activity Information (BUS2000126), but for example not with the
Service Contract object type (BUS2000112)) Also the number range object is assigned here to the
object type
3) Definition of business transaction item – object types (BUS2000129 Lead Item;
BUS2000130 Opportunity Item; BUS2000131 Sales Item)
This table [CRMC_SUBOB_CAT_I ]is the design time entry point on item level and defines the
existing item object types
· Definition of assignment of
0 In table CRMC_BT_BTI_ASSI the possible combination of header and item object types is
55
defined
1 In table CRMC_IT_ASSIGN_S the item categories (as used in the transaction maintenance)
are assigned to item object types (eg: TAN is an item category of item object type
“BUS2000115“ (Sales)

Foundations Of Business Transaction Customizing (3)


Definition of additional business transaction components (= business transaction -
component types)

Define assignment of component types to


transaction - object types and
transaction item - object types

Result of above steps:

The structural understanding (maximal structure) for each business transaction


object type as defined by SAP

Foundations Of Business Transaction Customizing (4)

In table CRMC_OBJECTS the existing components(like ACTIONS, BILLING, STATUS, etc.) of


a business transaction are defined
The components are then mapped in the next steps to the previously defined header and item object
types:

56
CRMC_OBJECT_ASSI (Header level)
CRMC_OBJ_ASSI_I (item level)

Data Model in the CRM System

Transaction SD11 can be used to view the CRM Data Model. The data model is called
“CRM”

To the right is an extract of the business transaction model. Besides this all other
objects used by CRM (like BP’s, Products, etc.) can also be seen in here

Highlight a node and press the button “Sub-tree” followed by “Graphic”. This will
generate a graphical view of the tables with the proper hierarchy

Partner Set can be found in the Partner Model (PRM_PPROC)

Business Transaction: Basic Structure


„Business transaction kernel“ + „sets“

Structural building blocks (component types):

Component
Subtype
Extension
Set

57
Administration (header/item)
Extension (1x possible for each type)
1:1 relationship via common GUID Sets (Linkhandler)
Subsumption of equal header and item data
4. Optimal data filing Reassignment/grouping
5. Items can be „assigned“ to another header
6. Assignment to header and multiple items possible
7. Grouping
Item number can be renumbered
- User-defined insertion of items and sub-items
For distributed data absorption in several systems possible Referential conjunction only
to generic header or to generic item

Business Transaction: Building Block Component

Component:
Connected to the transaction via a 1:cn - relationship

Business Transaction: Building Block Subtype


Subtype:
Component, which describes a subset of an entity type

58
Business Transaction: Building Block Extension

Extension:
Component,
connected to the transaction (item) via a 1:c - relationship

Business Transaction: Building Block Set


Set:
Component,
connected to the transaction and / or several items via a link

• a set can belong to more than one instance


• a set must be assigned to at least one transaction / item

59
List of Sets (not Complete)

Account Assignment Set Price Calculation Set

Billing Set Pricing Parameter Set

Billing Plan Set Sales Set

Cancellation Set Shipment Costs Set

Date Set Shipping Set

Document Attachment Set Subject Reference Object


Set (*)
Organizational Unit Set
Tax Set
Partner Set
Value Limit Set
Payment Plan Set
Survey Valuation Set
Qualification Requirement
Set Rights Extent

Complete list can be found in the system using transaction SD11

One Order Layer Model

60
A four-layer model is used as a basis for programming in the CRM system. This model makes a strict
differentiation between the user interface, interaction, application logic and database access. Every
layer is separate and contains data in a local memory. Access to the individual levels is carried out via
the interfaces, but can only occur between the next direct layer or in the same layer. (for example, you
can not access the user interface directly from the database layer).
This architectural approach has the following advantages:
Layers can run on different platforms
Layers can be exchanged
Logic runs from one exact point and is always the same
Maintenance friendly
Minimization of database resources
This does not mean, however, that general functions such as foreign key checks, database accesses,
for example, in the screen cannot be used anymore and therefore the programming time may be
slightly higher
Database Layer
The database layer is the interface to the database. All database operations for one object are carried
out at this level (read, delete, add, change). The last original copy of the document before the
changes were saved is kept in the local memory of the database layer.
Object Layer
The object layer contains the complete application logic for editing an object (Changing order header,
adding item, determining price....). The following examples are also included:

Reading Customizing data


Determining default values
Implementing integrity rules
Change object using default values and entries
Maintain application log

61
Register object (sub-objects link to main object, partner order...)
Publish object for events or other objects (for example, saving, partner processing...)
Definition of rules, the object condition in which the fields are changeable and the condition in which they
are not.
The condition after the last change is kept in the local memory of the object layer.
Interaction Layer
The interaction layer controls the business transaction process. It uses the user entries (field changes,
function keys...), the methods called up from the object (FCODE control), the objects which should be
displayed and processed, or the elements in the relevant user interfaces are activated (screen or field
control). The interaction layer is described in a separate document.
User Interface
The user interface carries out the following tasks:
Displaying and entering values (VIEW one or more objects)
Visualizing sub-objects in a transaction and the relevant functions
Other screen options such as foreign key checks and database accesses should not be implemented.
The user interface is described in a separate document.
There are two techniques carried out in the user interface for the One-Order-Concepts :
Screen technique
HTML with ITS Flow Logic

Decoupling UI and Business Logic (MVC - Layer Model - PCUI)

62
Data Posting

Procedure:
The function module CRM_ORDERADM_I_READ_OB is called up from the function group
CRM_ORDERADM_I_OW, in order to write the admin item into the work area.
If the corresponding admin item is not in the object buffer, then CRM_ORDERADM_I_READ_OB calls
up the function module CRM_ORDERADM_I_READ_DB, in order to read the item from the DB buffer.
If the item is not kept in the DB buffer, the function module CRM_ORDERADM_I_READ_DB calls up
CRM_ORDERADM_I_SELECT_S_DB.
If it is not kept in a buffer, the item goes from the DB into the DB buffer, from there into the object
buffer and from there into the work area. After the item has been processed in the work area, it is
written in the object buffer using the function module CRM_ORDERADM_I_DATA_PUT_OB.
When saving, FB CRM_ORDERADM_I_SAVE_DB calls up the generic module
CRM_ORDER_TABLE_SAVE. This generic module determines first of all the admin items that
should be added or changed in the database. Afterwards it calls up the posting module
CRM_ORDERADM_I_SAVE_DU, which writes the admin items in the update task into the database.

63
One Order Layer Model in WinGUI

Procedure:
The function module CRM_ORDERADM_I_READ_OB is called up from the function group
CRM_ORDERADM_I_OW, in order to write the admin item into the work area.
If the corresponding admin item is not in the object buffer, then CRM_ORDERADM_I_READ_OB calls
up the function module CRM_ORDERADM_I_READ_DB, in order to read the item from the DB buffer.
If the item is not kept in the DB buffer, the function module CRM_ORDERADM_I_READ_DB calls up
CRM_ORDERADM_I_SELECT_S_DB.
If it is not kept in a buffer, the item goes from the DB into the DB buffer, from there into the object
buffer and from there into the work area. After the item has been processed in the work area, it is
written in the object buffer using the function module CRM_ORDERADM_I_DATA_PUT_OB.
When saving, FB CRM_ORDERADM_I_SAVE_DB calls up the generic module
CRM_ORDER_TABLE_SAVE. This generic module determines first of all the admin items that
should be added or changed in the database. Afterwards it calls up the posting module
CRM_ORDERADM_I_SAVE_DU, which writes the admin items in the update task into the database.

Call Stack of the CRM Layer Model


CRM_ORDER_MAINTAIN

CRM_ORDER_MAINTAIN_MULTI_OW

CRM_ORDER_MAINTAIN_SINGLE_OW

CRM_ORDER_H_MAINTAIN_OW

CRM_ORDER_H_PREPARE_OW

CRM_ORDERADM_H_MAINTAIN_OW

CRM_<OBJECT>_MAINTAIN_OW

.........

CRM_ORDER_H_COMPLETE_OW

CRM_ORDER_I_MAINTAIN_MULTI_OW

CRM_ORDER_I_MAINTAIN_SINGLE_OW

64
CRM_ORDERADM_I_MAINTAIN_OW

CRM_<OBJECT>_MAINTAIN_OW

.........

CRM_ORDER_I_COMPLETE_SINGLE_OW

CRM_ORDER_I_COMPLETE_MULTI_OW

CRM_ORDER_COMPLETE_SINGLE_OW

CRM_ORDER_COMPLETE_MULTI_OW

CRM_ORDER_FINAL_CALLS_OW

CRM_<object>_MAINTAIN_OW

CRM_<object>_CREATE_OW

CRM_<object>_PUT_OB

CRM_<object>_CHANGE_OW

CRM_<object>_FILL_OW

CRM_<object>_FIELDCHECK_FC

CRM_ORDER_INPUT_DATA_OW

CRM_<object>_MERGE_OW

CRM_<object>_CHECK

CRM_<object>_PUT_OB

CRM_<object>_PUBLISH_OW

Technical, Programming

Package/Function Groups

Packages are subject to the following naming conventions

<component>_<object>_<addition>

Example:
CRM_ORDERADM_H

Function groups are subject to the following naming conventions

<component>_<object>_<addition>_<layer>

Example:
CRM_ORDERADM_H_OW

A package should be created for every sub-object containing everything that belongs to the sub-object.
(application logic, Customizing, interface, ...)
There is a function group for every table. Use a separate function group for application, Customizing,
interface, ....

Document Tables/Time Dependent Tables


Document tables are subject to the following naming conventions
<component>D_<object>_<addition>

Example:
CRMD_ORDERADM_H

65
Time dependent tables (revisions) are subject to the following naming conventions
<component>R_<object>_<addition>
Example:
CRMR_PRICING

Customizing/Text Tables
All Customizing tables (and system tables) are subject to the following naming conventions
<component>C_<object>_<addition>

Example:
CRMC_DOCTYP Customizing document types

Text tables are subject to the following naming conventions


<table name>_T

Example:
CRMC_DOCTYP_T

Message Classes
Message classes are subject to the following naming conventions
<component>_<object>_<addition>
Example:
CRM_ORDERADM_H

A message class should be created for every sub-object.

Function Modules and Reports


FMs and reports are subject to the following naming conventions
<component>_<object>_<method>_<layer>
Examples
CRM_ORDERADM_H_READ_OB

If you are working with several layers, the following conventions


apply: (Analogue to the 4 layer model: D/O/I/U)
Ending: Layer that implements the database
*_DU (for database update) update
Ending:
*_DB (for database buffer) Layer containing the database buffer
Ending: Layer that contains the current data to be
*_OW (for object work area) processed
Ending:
*_OB (for object buffer) Layer in which current data is buffered
Ending: Layer containing the interface (flow
*_IL (for interaction layer) logic/field selection)
Ending:
*_UI (for user interface) Layer containing the interface (screen)
Ending: Layer containing Customizing
*_CD (for Customizing dialogue) maintenance
Ending: Layer containing the read module for
*_CB (for Customizing buffer) Customizing
Ending: Layer containing fieldcheck mehods for
*_FC (for Fieldcheck) fieldselection

66
Ending: Layer containing callback methods for
*_EC (for Event callback) event handler
Ending:
*_AC (for Archiving) Layer containing methods archiving

Important Methods for a Sub-object in a Maintain Method


…_CREATE_...

…_READ_...

…_CHANGE_...

…_FILL_...

…_INPUT_DATA_...

…_MERGE_DATA_...

…_CHECK_...

…_PUT_...

…_PUBLISH_...

…_COMPLETE_..

..._CREATE initializes the data area and procures a guid, if none has been provided externally. The
empty work area up to the guid is transferred into the object buffer. The link handler is called up to
create links for sets. (See “Link handler“ unit)
..._READ reads the data from the global buffer into the work area. If it is not found, it is read from
the database buffer, (if it is not found there, from the database in the database buffer) and then
sent back from again.
..._ CHANGE executes further processing when creating and changing and carries out further
submethods.
..._FILL derives the object with data from Customizing and the master data and transfers the
entries from the interface. Sub methods are called up. If possible, all data should only be
transported into the work area in this routine. After this routine has been run, the data is checked
in the method ..._CHECK.
..._ INPUT_DATA. The entry data is transferred. Only those fields contained in the field name table
are transferred from the interface. This routine is a generic function that can be used by everyone.
When calling up, the structure and structure name are transferred.
..._MERGE_DATA. Other data can be redetermined as well as the changes. For example: When
changing the product number, a new item short text is determined.
..._CHECK. This is where all checks are carried out: Check tables, field selection rules, consistency,
incompletion. Error messages are not issued online, but are logged. The first error does not stop the
procedure. Checks are carried on for as long as possible.
..._ PUT writes the work area back into the global puffer, even when it contains errors (see „Error
handling“).
..._PUBLISH announces the change for any follow-up processing required. For example, when
changing a schedule line quantity, an availability check must be carried out again at the end of item
processing. To be more exact: If several items have been processed, after all item processing – at the
end of the method ...ITEMS_MAINTAIN. See also “Event handler“.
..._COMPLETE is used to carry out group end processing. The event handler is generally called up
67
to process the marked event. Example: The schedule line quantities are changed for several items.
After changing all schedule lines, the availability check and pricing are called up.

Event Handler

The change of data in a specific set might influence any other set. So each set would have to „ask“ all other
sets, if something relevant was changed, that influences this set. To prevent this, the event handler is used.

The relationship between the different sets is defined in table

CRMC_EVENT_CALL
Well defined interface
Events for different stages
dataloss / save / initialize
end of: head / item / all items / document / all documents

Grouping / compress logic

The Event Handler defines the relation and communication between independent
objects Grouping means collect Consumer and execute Callbacks at one single
execution point compress logic means very first data and the very last data

Call Stack for Event Handler

CRM_ORDER_MAINTAIN
CRM_ORDER_MAINTAIN_MULTI_
OW
CRM_ORDER_MAINTAIN_SINGLE_OW
CRM_ORDER_H_MAINTAIN_
OW
CRM_ORDER_H_PREPARE_OW
CRM_<OBJECT>_MAINTAIN_OW
CRM_<OBJECT>_PUBLISH_
OW
CRM_EVENT_SET_EXETIME_OW (end_<OBJECT>)
.........
CRM_ORDER_H_COMPLETE_OW
CRM_EVENT_SET_EXETIME_OW
(end_header_maintain) CRM_ORDER_I_MAINTAIN_MULTI_OW
CRM_ORDER_I_MAINTAIN_SINGLE_OW
CRM_<OBJECT>_MAINTAIN_
OW
CRM_<OBJECT>_PUBLISH_OW
CRM_EVENT_SET_EXETIME_OW
(end_<OBJECT>)
.........
CRM_ORDER_I_COMPLETE_SINGLE_OW
CRM_EVENT_SET_EXETIME_OW
(end_item_maintain)
CRM_ORDER_I_COMPLETE_MULTI_
OW CRM_ORDER_COMPLETE_SINGLE_OW
CRM_EVENT_SET_EXETIME_OW
(end_order_maintain) CRM_ORDER_COMPLETE_MULTI_OW
CRM_EVENT_EXETIME_MULTI_OW
(end_order_multi_maintain) CRM_ORDER_FINAL_CALLS_OW

CRM_EVENT_PUBLISH_OW
In this FB an event is publicized by indication of a GUID, an object (e.g. PARTNER), and an event
(e.g. AFTER_CHANGE). Via the GUID the transaction type is identified, in via the transaction type the
BUS-types. All entries refering to this BUS-types are collected in an internal table. This table is looped

68
via the object and the event and so there are two new tables created – a table with FBs, that can
immediately be executed, and a table with FBs, that should be executed in the future. The entries are
sorted by point of time and priority.
When the first table contains any entries, these are executed at this point.
CRM_EVENT_SET_EXETIME_OW
This building block is retrieved via a GUID, KIND (Header oder Item) and EXE_TIME. First there is a
proof, if all events, which were registered to an earlier point of time, are executed. If not, this will be
done by selecting the FB with the earlier point of time. All EVENTS refering to this point of time are
executed now, and the entries in the internal table are deleted.

Event Handler

Tip: How to Find „your“ Event

Set the user parameter ‘CRM_EVENT_TRACE’ to ‘X’

Run your transaction as normal

In a separate session, call transaction CRMV_EVENT_TRACE (as of release 4.0).

Create/maintain your entry in table CRMC_EVENT_CALL


run report CRM_EVENT_TRACE in SE38. If this report does not exist in your system , then you need
to implement note 451676.
The no. of records shown is set to 250 as default. You may need more. While working in your
transaction, you can refresh the trace report. This will be automatically updated. As a result, you will
be able to see which events have been set, which execution times have been reached, and you can
hopefully decide which combination of event, object and execution time is best for you.
Table CRMC_EVENT_CALL: explanation
CRMC_EVENT_CALL is used to register function modules for events.

69
When an event is published, the event handler finds all function modules (callbacks) interested in
this event and runs them at the appropriate time.
Fields:
SUB_TYPE = Business type (Sales, service etc.)
EXE_TIME = when you want your callback to run. Various execution times are set during the processing of a
transaction, for example, end of item processing, end of header processing. When the event you are registered
for is published, you may need to react immediately, or you may want to wait until a later time-point. For
example,
If partner data is changed, then the pricing data needs to be checked immediately. Orgman however
can wait until the end of header processing to work with this data.
Note: You should not use exe_time ‘immediately’ (001) if you register for the event ‘SAVE’.
PRIO = Priority of callback. Acts as an additional sort criteria as to when callbacks are carried out.
OBJ_NAME = the object you are interested in (e.g. Partner, Orgman)

EVENT = the event you are interested in (e.g. after_create, save, end of header processing)
ATTRI1 = The attribute is used as a filter to cut down on the number of function modules called.
Depending on the object or set, you may not always need to react to an event being published. If you
always need to react, then you should set ATTRI1 to SPACE or <*>. You can assign an attribute to the
callback so that it only reacts when this attribute is set. This attribute is used for example by status
callbacks, or for partner determination. The partner set uses this attribute to communicate for which
particular partner an event has been published (0001 for contact person etc.). The status set
communicates the status change via this attribute.
FUNC_NAM = the name of your callback (it should begin with CRM and end in EC)
ERROR_CHECK = if, for some reason, the callback raised an error, this flag causes the message to be
passed on to the calling program
ONLY_ONE_CALL= callback is only run once
CHANGED_AT = date of change to record
CHANGED_BY = user who made change
CB_FREQ = Frequency and characterization of the callback. This attribute is very, very, important! The
following values are allowed:
SPACE – the callback can be carried out for headers and items. The callback is provided with the object
name, the event, old and new data. Compare with ‘K’
A – Like ‘SPACE’, but without old and new data.
B – The callback can be carried out for header and items. Old and new data are not provided.
C – The callback is carried out only once per transaction. Old and new data are not provided. Note: This is
the only setting that should be used with EXE_TIME ‘080’ (Save).
K - The callback can be carried out for headers and items. The callback is provided with the object name,
the event, and cumulated old and new data. This means that if an event is published more than once, you
get the old data from the initial call, and the new data from the final call. All changes in between are
ignored. Normally, you need to set SPACE if you want to react immediately and K if you react later.
However, for partner data, you need to use SPACE, as partner data cannot be cumulated.
Did I mention that this parameter is very important?
ONLY_HDR = the callback should only be carried out at header level.
ONLY_ITM = the callback should only be carried out at item level.

70
Error Log: Concept

Documents with errors and incomplete data can be saved


Error status blocks follow up actions
Error messages are collect in the application log and can be reprocessed
afterwards

Error Log: User Profile

Not all users are interested in all message details

There is a number of degrees of detail predefined:


Collect only in trace mode
Administrator
Professional User
Backoffice User
Customer

Developer define the minimum degree of detail in system table In customizing the behaviour can be
altered to more details.

System table for error level: CRMC_MESSAGES_S


Logic: If a message is defined as „Backoffice User“, then users with Parameter “CRM_USER_LEVEL“
„1“(customer) are not able to display them, all other levels are able to see the message

Enhancements

Extensibility: Adding Customer Specific Fields

Customer specific fields should be added to the extensions CUSTOMER_H (header) or


CUSTOMER_I (item) whenever possible. These subobjects are reserved for customers‘ use.
In principle, it is also possible to add fields to other subobjects (e.g., PRODUCT_I).
Always add fields to the CRMT_<Subobject>_EXT structure, never directly to the database
table CRMD_<Subobject> !
Use an append structure to the EXT structure or the Customizing Include
(CI_EEW_<Subobject>) for most subobjects.
The fields will automatically be contained in the Messaging BDOC for data exchange.
If the Customizing Include is used, the fields will automatically be available in the People-
Centric UI.

Extensibility: CUSTOMER_H and CUSTOMER_I

The One Order subobjects CUSTOMER_H (customer specific header data) and CUSTOMER_I
71
(customer specific item data) are fully integrated into the One Order framework:
They have object layer function groups (OW, OB, DB, DU).
They are accessible via the standard APIs CRM_ORDER_MAINTAIN and
CRM_ORDER_READ.
They are archived.
They are contained in the Messaging BDOC for business transactions.
Display of change documents for fields in these objects is possible.

EEW for CRM BTX: Overview

The Easy Enhancement Workbench for CRM Business Transactions has been provided
with CRM 4.0.
It allows adding new fields to individual subobjects of CRM 1-Order business objects.
Following attributes of an extension can be defined:
Business Objects (Activity, Sales, Service, …),
Description, type and length of the fields,
Technical names of the fields and data elements (expert mode), Relevant
subobjects to which the fields are added.
Additionally, following field relevancies can be defined:
R/3: extension of R/3 adapter,
Mobile: extension of Mobile Sync BDoc and CDB tables BW:
extension of BW DataSource
XIF adapter (extended by default)

The following functions are currently not supported by the EEW. They may be part of future
enhancements. Inclusion of the new fields in field catalogs (Pricing, ATP)
Enhancement of the screens (e.g., additional tab strips, moving fields to standard tab
strips) Enhancements in R/3 for documents other than sales orders
Currency and quantity fields: only a workaround is
available Integration into BAPIs
Copying control

EEW for CRM BTX: CI Structures

The extensibility concept is based on Customizing Includes


For most of subobject (on item, header or set level) a customizing include is provided
A CI structure is a DDIC structure that extends data and programming model (data
base tables, communication structures, UI structures) of subobjects
For example: Header Data Activity (ACTIVITY_H) CI_EEW_ACTIVITY_H
New fields are appended to relevant customizing includes
The PC-UI framework automatically displays the fields from CI includes

72
EEW for CRM BTX: Integration

Mobile
Enhancement of synchronization Bdoc
BAdI implementation for transferring fields to/ from Mobile Client

R/3
Append structures in R/3
BAdI implementation for transferring fields to/ from R/3 adapter

BW
Append structures for relevant BW extract structures
BAdI implementation

EEW for CRM BTX: Advanced Search

New fields are added to the advanced search area of BSP applications

BAdI implementation for extending the reporting framework query

Registration in reporting framework customizing

Limited to the PC-UI

73
Extensibility: Merge and Check Methods
Each subobject (e.g., SHIPPING, CUSTOMER_I, ...) offers a BAdI
CRM_<Subobject>_BADI with two methods
CRM_<Subobject>_MERGE for merging (deriving) fields of the subobject
CRM_<Subobject>_CHECK for additional checks of the subobject

These methods are called in the function modules


CRM_<Subobject>_MERGE_OW
CRM_<Subobject>_CHECK_OW

Exceptions: For objects PARTNER and PAYPLAN, the BAdIs begin with COM instead of CRM.

Extensibility: Compilation of BAdIs


A variety of BAdIs are available around One Order Business Transactions. We mention only a
collection of selected BAdIs:
CRM_COPY_BADI Copy control for One Order documents
CRM_ORDER_INDEX_BADI Update of table CRMD_ORDER_INDEX
CRM_ORDER_FIELDCHECK Fieldcheck during transaction processing
CRM_CONFIRM_01 Update of field catalog to APO
CRM_UPLOAD_BEA_FILL Mapping of fields to Billing Engine
COM_PAYCARD_BADI Extend Structure for Communication with
Clearing House
ORDER_SAVE Check and manipulate data before docs are saved
CRM_DATAEXCHG_BADI Data Exchange with R/3
CRM_COND_COM_BADI Extension of communication structure for pricing
CRM_BWA_MFLOW BW Extraction

CRM_30A_USER_EXITS Data Exchange with Mobile Clients/Mobile Bridge

REMEMBER the layer model:


DISPLAY: The generic function module „CRM_ORDER_READ“ (and the connected segment FMs)
is called in order to retrieve all relevant data for the one order document
MAINTAIN: The generic function module „CRM_ORDER_MAINTAIN“ (and the connected segment
FMs). Updates the documents object layer after user interaction or for system defaulting
SAVE: The generic function module „CRM_ORDER_SAVE“ (and the connected segment FMs).
Persists the document and the changes in the database.
DO NOT CALL any „save“-related function modules (*_save_*) during the maintain cycle or vice versa. The
latest call in order to prepare the document data for saving (checks, manipulation) should be done in BADI
„ORDER_SAVE“. Use the *_OB FMs in order to modify specific segements

General Procedure

74
Step 1: Display document: „CRM_ORDER_READ“
Step 2: Maintain information: „CRM_ORDER_MAINTAIN“
Step 3: Save information: „CRM_ORDER_SAVE“

DISPLAY: The generic function module „CRM_ORDER_READ“ (and the connected segment FMs)
is called in order to retrieve all relevant data for the one order document
MAINTAIN: The generic function module „CRM_ORDER_MAINTAIN“ (and the connected segment
FMs).
SAVE: The generic function module „CRM_ORDER_SAVE“ (and the connected segment FMs).
DO NOT CALL any save related function modules during the maintain cycle or vice versa. The latest call in
order to prepare the document data for saving (checks, manipulation) should be done in BADI
„ORDER_SAVE“. Use the *_OB FMs in order to modify specific segements

Extensibility: BAdI CRM_BTX_EXTENSIONS

The BAdI CRM_BTX_EXTENSIONS was introduced in CRM 4.0 for industry-specific subobjects in the One
Order.

The aim was to avoid modifications of the central order APIs by IS development.

The BAdI is not intended for customers‘ use!

However, the BAdI could be used on a project basis in case the customer needs to create a new table in
the One Order framework.

Testreport „CRM_ORDER_READ“

Use tx SA38

Middleware and Interfaces

75
CRM Middleware and the One Order Concept
One single mBoc Type (BUS_TRANS_MSG)

One single complex structure (BAD_BUS_TRANSN_MESSAGE) similar to the One

Order segments discussed earlier

Mapping to Mobile Sales sBdoc structure is done in the Mobile Bridge

In line with the 1Order concept there is only one mBdoc type BUS_TRANS_MSG, that is able to carry
all types of process types
The complex structure BAD_BUS_TRANSN_MESSAGE is analogous to the already explained
segment structure of the one order context and that is also used in function modules like
„CRM_ORDER_READ“ or „CRM_ORDER_MAINTAIN“
Use Tx: SBDM in order to go into the structure details

XIF Adapter in the OneOrder Context

The External Interface Adapter (XIF) provides: a service in the CRM Middleware Message Flow
IDOC and XML interface to external systems

76
For detailed information regarding XIF interfacing and the CRM Middleware please refer to the available
standard course for the CRM Middleware

XIF Adapter – Data Structure

One complex Data Type: CRMXIF_BUSTRANS (analogous to mBdoc structure)

Automatically enhanced if EEWB is used(see next chapter)

EEWB = Easy Enhancement WorkBench


Difference between mBoc and XIF Structure: in mBdoc there are the two segments „ORDERADM_H“ and
„ORDERADM_H“, while in the XIF Interface the corresponding fields can be directly found in the segments
CRMXIF_BUSTRANS and the segment „ITEM” inside the CRMXIF_BUSTRANS structure.

IDoc Message Type

One message type: CRMXIF_ORDER_SAVE_M


But different Idoc basic type per CRM Release
CRM 5.0: CRMXIF_ORDER_SAVE_U01
CRM 4.0: CRMXIF_ORDER_SAVE_M02

Again the segmented structure is used for the IDoc-segments

77
Field enhancements need to be made/generated manually

Definition of the Idoc Type can be found in tx: WE30.

Appendix A – Business Transaction Integrity Matrices


Business integrity of business transaction ?

Combination transaction / transaction ?

Assigment item to business transaction?


Assigment extension to transactions / items?
Assigment set to transactions / items?

Business Transaction Integrity Matrices ! (predefined by SAP)

Combined Business Transactions (Transaction / Transaction)

78
79
Combination Transaction / Transaction Item

80
Combination Transaction / Set

81
Combination Transaction �Extension / Component

82
Combination Transaction Item / Set

83
Combination Transaction Item �Extension / Component

Database Tables Belonging to the Model (1) (Object Model 3.0)


Name of Entity Database Table Entity belongs to Object Entity-ID
Account Assignment BBP_PDACC Business Transaction - Account Assignment Set CRM01189
Activity CRMD_ACTIVITY_H Business Transaction CRM01010
Activity Category CRMC_ACT_CATEGOR Activity Parameter CRM06039
Activity Objective CRMC_ACT_OBJ Activity Parameter CRM06040
ATP Profile CRMC_ATP_PROFILE Business Transaction Item Type - Parameter CRM06001
Bid Invitation BBP_PDHSB Business Transaction CRM01029
Billing Plan CRMD_BILLPLAN Business Transaction - Billing Plan Set CRM01171
Billing Plan Date CRMD_BILLPLAN_D Business Transaction - Billing Plan Set CRM01172
Billing Plan Date - Financing CRMD_BILLPLAN_DF Business Transaction - Billing Plan Set CRM01192
Billing Plan Schema CRMC_BILP_PROC Billing Plan Parameter CRM06182
Billing Plan Type CRMC_BILP_TYPE Billing Plan Parameter CRM01122
Billing Plan Type Determination CRMC_BILP_BT Business Transaction Type CRM06181
Billing Plan Type Determination - Transaction Item CRMC_BILP_BT_IT Business Transaction Item Type CRM06196
BT - Field Input Authorization Group - User - Assignment CRMC_FCHECK_UP Business Transaction Type - Parameter CRM06776
Business Transaction CRMD_ORDERADM_H Business Transaction CRM01001
Business Transaction - Billing Set CRMD_BILLING Business Transaction - Billing Set CRM01123
Business Transaction - Cancellation Set CRMD_CANCEL Business Transaction - Cancellation Set CRM01187
Business Transaction - Component Type CRMC_OBJECTS Business Transaction - Component Type CRM00107
Business Transaction - Field Input Authorization CRMC_FCHECK_LEAS Business Transaction Type CRM06775
Business Transaction - Field Input Authorization Group CRMC_CHGLEVEL Business Transaction Type - Parameter CRM06774
Business Transaction - Object Relationship BBP_PDBINREL Business Transaction CRM01019
Business Transaction - Object Relationship CRMD_BINREL Business Transaction CRM01019
Business Transaction - Object Relationship CRMD_BRELVONAE Business Transaction CRM01019
Business Transaction - Object Relationship CRMD_BRELVONAI Business Transaction CRM01019
Business Transaction - Object Type CRMC_SUBOB_CAT Business Transaction - Object Type CRM00105
Business Transaction - Object Type Combination CRMC_BUS_SUBOB_C Business Transaction - Object Type CRM00130
Business Transaction - Payment Plan Set COMD_PAYPLAN Business Transaction - Payment Plan Set CRM01124
Business Transaction - Pricing Parameter Set CRMD_PRICING Business Transaction - Pricing Parameter Set CRM01150
Business Transaction - Pricing Schema Determination CRMC_PRCPROC_DET Business Transaction - Pricing Schema Determination CRM06008
Business Transaction - Pricing Schema Grouping CRMC_DPRICPROC Business Transaction Type - Parameter CRM06009
Business Transaction - Pricing Type Determination CRMC_PRCTYPE_DET Business Transaction - Pricing Type Determination CRM06084
Business Transaction - Sales Set CRMD_SALES Business Transaction - Sales Set CRM01101

84
Business Transaction - Screen Profile CRMC_SSC_SCP_DEF Business Transaction - Screen Profile CRM07231
Business Transaction - Screen Profile Category CRMC_SSC_SPT_DEF Business Transaction - Screen Profile Category CRM07232
Business Transaction - Shipping Set CRMD_SHIPPING Business Transaction - Shipping Set CRM01118
Business Transaction - User Interface - Method CRMC_SSC_UI_METH Business Transaction - User Interface - Method CRM07228
Business Transaction Event CRMC_EVENTS Business Transaction Event CRM06211
Business Transaction Event - Execution Time CRMC_EVENT_EXTI Business Transaction Event CRM06214
Business Transaction Item CRMD_ORDERADM_I Business Transaction CRM01002

Database Tables Belonging to the Model (2) (Object Model 3.0)


Name of Entity Database Table Entity belongs to Object Entity-ID
Business Transaction Item - Object Type CRMC_SUBOB_CAT_I Business Transaction Item - Object Type CRM00106
Business Transaction Item - Schedule Line CRMD_SCHEDLIN Business Transaction CRM01141
Business Transaction Item - Screen Profile CRMC_SSC_ITP_DEF Business Transaction Item - Screen Profile CRM07227
Business Transaction Item - Screen Profile Category CRMC_SSC_IPT_DEF Business Transaction Item - Screen Profile Category CRM07226
Business Transaction Item Type CRMC_ITEM_TYPE Business Transaction Item Type CRM00102
Business Transaction Item Type - Copy Parameter - Determin. CRMC_IT_COPY_MA Business Transaction Item Type CRM00134
Business Transaction Object Type Grouping-Object Type-Assig. CRMC_BO_RANGES Business Transaction Object Type - Grouping CRM00117
Business Transaction Type CRMC_PROC_TYPE Business Transaction Type CRM00100
Business Transaction Type - Mobile Sales Trans. Type-Mapping CRMC_MAP_PROCT Business Transaction Type CRM07249
Business Transaction Type - PPR Sales Check Permission CRMC_PRP_OC Business Transaction Type CRM01441
Business Warehouse - Analysis Phase CRMC_CON_PHASE Sales Cycle CRM06054
Cancellation Rule CRMC_CANCRULES Cancellation Schema Parameter CRM06094
Cancellation Schema CRMC_CANCPROC Cancellation Schema CRM06092
Cancellation Schema Rule CRMC_RULES2PROC Cancellation Schema CRM06095
Cancelling Party CRMC_PARTY Cancellation Schema Parameter CRM06093
Cash Flow - Individual Value Type CRMC_CFTYPE Cash Flow - Individual Value Type CRM06321
Cash Flow - Individual Value Type - Attribute CRMC_CFTYPE_ATTR Cash Flow - Individual Value Type CRM06319
Cash Flow - Individual Value Type - Financing View CRMC_CFTYPE_FVR Cash Flow - Individual Value Type CRM07214
Cash Flow - Value Type CRMS_SBERFIMA Financial Mathematics - Value Type CRM06320
Cash Flow Value Type - Pricing Usage Determination CRMC_CFTYPERELCP Cash Flow - Individual Value Type CRM06328
Cash Flow Value Type - Profile CRMC_CFTYPE_PR Cash Flow Value Type - Profile CRM06316
Cash Flow Value Type Profile - Individual Value Type CRMC_CFTYPE_PRCF Cash Flow Value Type - Profile CRM06315
Cash Flow Value Type Profile - Sales CRMC_CFTYPE_PR_R Cash Flow Value Type - Profile CRM06314
Component Type - Event Function Determination CRMC_EVENT_CALL Business Transaction - Component Type CRM06212
Component Type - Event Structure CRMC_EVENT_STRUC Business Transaction - Component Type CRM06213
Configuration Restriction Price Agreement Schema CRMC_CONFFPROC Business Transaction Item Type - Parameter CRM07207
Contract Classification CRMC_DOCTYPE Business Transaction Item Type - Parameter CRM06772
Copy Filter CRMC_CP_BADI_F Business Transaction Type - Parameter CRM06230
Copy Transaction Item Type - Determination CRMC_IT_COPY_IF Business Transaction Item Type CRM00135
Credit Check Group CRMC_CREDITGROUP Credit Check Group CRM06751
Credit Check Rule CRMC_CREDITRULE Credit Check Group CRM06750
Cumulation Function Module CRMC_CUM_DEF Cumulation Rule CRM06473
Date SCAPPTSEG Date Set CRM01161
Document Attachment BBP_PDATT Business Transaction - Document Attachment Set CRM01188
Evaluation Questionnaire - Level Evaluation Percentage Rate CRMC_LEAD_SV_QL Lead Parameter CRM06147
Evaluation Questionnaire Template CRMC_LEAD_SV Lead Parameter CRM06144
File Interface Parameter CRMC_REQ_REC_E Request Category CRM04223
Financial Mathematics - Value Type AT40 Financial Mathematics - Value Type REU06750
Individual Cancellation Rule CRMD_CANCEL_IR Business Transaction - Cancellation Set CRM01191

Database Tables Belonging to the Model (3) (Object Model 3.0)


Name of Entity Database Table Entity belongs to Object Entity-ID
Internet Transaction Type CRMC_SERVICE_IPT Internet Transaction Type CRM06057
Lead CRMD_LEAD_H Business Transaction CRM01013
Lead Grouping CRMC_LEAD_TYPE Lead Parameter CRM06118
Lead Qualification Level CRMC_LEAD_QL Lead Parameter CRM06116
Marketing Method Schema Determination CRMC_PROD_PROP Business Transaction Type CRM06187
Opportunity CRMD_OPPORT_H Business Transaction CRM01006
Opportunity Origin Kind / Lead Origin Kind CRMC_SOURCE Opportunity Parameter CRM06032
Opportunity Priority / Lead Priority CRMC_OPPIMPOR Opportunity Parameter CRM06031
Opportunity Type CRMC_OPPT_TYPE Opportunity Parameter CRM06010
Organizational Unit Set CRMD_ORGMAN Business Transaction - Organizational Unit Set CRM01186
Partner CRMD_PARTNER Partner Set CRM01109
Partner Rating COMD_PARTNER_ATT Partner Set CRM02103
Partner Team Relationship COMD_PARTNER_REL Partner Set CRM02102
Payment Card - Authorization Check Group COMC_PC_AUTH Business Transaction Type - Parameter CRM06070
Payment Card - Check Result COMC_PC_RESP Payment Plan Parameter CRM06073
Payment Plan Category COMC_PAYPL_CT Payment Plan Parameter CRM06069
Payment Plan Date COMD_PAYPLAN_D Business Transaction - Payment Plan Set CRM01120
Payment Plan Date - Payment Card COMD_PAYPLAN_DC Business Transaction - Payment Plan Set CRM01121
Payment Plan Type COMC_PAYPL Payment Plan Parameter CRM06067
Payment Plan Type - Date Category COMC_PAYPL_D Payment Plan Parameter CRM06068
Price Calculation Condition PRCD_COND Price Calculation Set CRM01138
Price Calculation Item PRCD_ITEM Price Calculation Set CRM01114
Price Calculation Set PRCD_HEAD Price Calculation Set CRM01040
Pricing Parameter History CRMR_PRICING Business Transaction - Pricing Parameter Set CRM01194
Purchase Order Item Confirmation BBP_PDCON Business Transaction CRM01066
Purchasing Organizational Unit BBP_PDORG Business Transaction - Organizational Unit Set CRM01185
Reason for Rejection CRMC_REJECTION Sales Parameter CRM06099
Reference Object CRMD_SRV_REFOBJ Business Transaction - Subject Reference Object Set CRM01137
Request Category CRMC_REQ_TYPE Request Category CRM04218
Request Category - File Interface Parameter CRMC_REQ_REC Request Category CRM04222
Request Category Grouping CRMC_REQT_GRP Request Category CRM04220
Request Category View CRMC_REQTYP_V Request Category CRM04219

85
Response Time Profile - Service Agreement CRMD_ESCAL_REC Service Parameter CRM06457
Rounding Profile CRMC_ROUND_PROFD Rounding Profile CRM06313
Rounding Profile - Rounding Rule CRMC_ROUND_PR_RR Rounding Profile CRM06342
Rounding Profile - Sales CRMC_ROUND_PROFR Rounding Profile CRM06340
Sales Cycle CRMC_CYCLE Sales Cycle CRM06011
Sales Cycle Phase CRMC_CYCPHASE Sales Cycle CRM06025
Sales Kind CRMC_USAGE Sales Parameter CRM06033

Database Tables Belonging to the Model (4) (Object Model 3.0)


Name of Entity Database Table Entity belongs to Object Entity-ID
Sales Phase CRMC_PHASE Sales Cycle CRM01108
Service Availability Profile CRMD_SERWI Service Parameter CRM06455
Service Employee Assignment CRMD_SRVA_STATUS Service Employee Assignment CRM01695
Service Process CRMD_SERVICE_H Business Transaction CRM01008
Service Response Time Profile CRMD_ESCAL Service Parameter CRM06456
Service Type CRMC_SRV_TYPE Service Parameter CRM06458
Service Valuation Type CRMC_VAL_TYPE Service Parameter CRM06459
Shipment Costs BBP_PDFRT Business Transaction - Shipment Costs Set CRM01176
Subject CRMD_SRV_SUBJECT Business Transaction - Subject Reference Object Set CRM01129
Subject Reference Object CRMD_SRV_OSSET Business Transaction - Subject Reference Object Set CRM01128
Tax BBP_PDTAX Business Transaction - Tax Set CRM01181
Telephone Number Reservation ISTT_TCN_TEL_TMP Telephone Number Reservation CRM06936
Transaction - Additional Extension CRMD_CUSTOMER_H Business Transaction CRM01055
Transaction - Procurement Classification BBP_PDPSET Business Transaction CRM01067
Transaction - Purchasing Information BBP_PDHGP Business Transaction CRM01018
Transaction - Screen Profile Category - Control Parameter CRMC_SSC_PAN Business Transaction - Screen Profile Category CRM07235
Transaction - Screen Profile Category Determination CRMC_SSC_SPT_SEL Business Transaction - User Interface - Method CRM07237
Transaction - Screen Profile Determination CRMC_SSC_SCP_SEL Business Transaction - Screen Profile Category CRM07236
Transaction - Set Link CRMD_LINK Business Transaction CRM01005
Transaction Component Type - Item Object Type - Assignment CRMC_OBJ_ASSI_I Business Transaction - Component Type CRM00115
Transaction Component Type - Object Type - Assignment CRMC_OBJECT_ASSI Business Transaction - Component Type CRM00123
Transaction Item - Additional Extension CRMD_CUSTOMER_I Business Transaction CRM01056
Transaction Item - Configuration Relationship CRMD_STRUCT_I Business Transaction CRM01052
Transaction Item - Cumulated Value CRMD_CUMULATED_I Business Transaction CRM01024
Transaction Item - Financing Product CRMD_FINPROD_I Business Transaction CRM01197
Transaction Item - Price CRMD_PRICING_I Business Transaction CRM01022
Transaction Item - Procurement Classification BBP_PDPSET Business Transaction CRM01068
Transaction Item - Product CRMD_PRODUCT_I Business Transaction CRM01021
Transaction Item - Product List CRMD_ORDPRP_I Business Transaction CRM01193
Transaction Item - Purchasing Information BBP_PDIGP Business Transaction CRM01023
Transaction Item - Screen Profile Category Determination CRMC_SSC_IPT_SEL Business Transaction - User Interface - Method CRM07229
Transaction Item - Screen Profile Determination CRMC_SSC_ITP_SEL Business Transaction Item - Screen Profile Category CRM07230
Transaction Item - Service CRMD_SERVICE_I Business Transaction CRM01057
Transaction Item - Service - Resource Requirement CRMD_SRV_DEMAND Business Transaction CRM01139
Transaction Item - Set Link CRMD_LINK Business Transaction CRM01004
Transaction Item Object Type - Financing Profile CRMC_FIN_PROFILE Business Transaction Item - Object Type CRM07223
Transaction Item Object Type - Follow-up Task Type CRMC_LEASING_P_C Business Transaction Item - Object Type CRM06771
Transaction Item Object Type - Processing Type CRMC_BUS_SUBOB_I Business Transaction Item - Object Type CRM00132
Transaction Item Type - Determination CRMC_IT_ASSIGN Business Transaction Type CRM00126

86
BADIs

87
How to search & Impliment for BADIs
How to search for BAdIs?

Introduction
There are multiple ways of searching for BAdIs. My favorite one is using the Performance Trace (formerly known as
SQL trace) transaction code ST05.
This analyzing technique is based on the fact that all BAdIs are registrated in SAP database tables. So for each
BAdI call these database tables will be accessed. The BAdI database tables are SXS_INTER, SXC_EXIT, SXC_CLASS
and SXC_ATTR. These tables are always accessed by the views V_EXT_IMP and V_EXT_ACT. So these two ABAP
views (T: SE11) will be the basis for the trace.
The procedure to discover BAdIs by a Performance Trace will be explained by using the example used below.

Example case
I want to know which BAdIs are called in the transaction "Maintain Business Partners" transaction code BP.

Pre checks
• Check if no other users (T:SM04) or batch jobs (T: SM50) are using the same user as you do.

Trace Actions
Start the Performance trace
• Start transaction ST05 (Performance Analysis)
• Set flag field "Buffer trace"
Remark: We need to trace also the buffer calls, because BAdI database tables are buffered. (especially view
V_EXT_IMP and V_EXT_ACT)
• Push button "Activate Trace"

Execute the Business transaction


• Start transaction BP in a new GUI session
• Push button "Organization"
• Fill in your test data
Name NL4B
Street Olympia
House number 1a/1b
Postal code 1213 NS
City Hilversum
Country NL
• Push button Save

Performance trace
88
• Go back to the Performance trace session
• Push button "Deactivate Trace"

Analyzing the Trace List


Showing the Trace List
• Push button "Display Trace"
The popup screen "Set Restrictions for Displaying Trace" appears
Now we are going to filter the trace on Objects: V_EXT_IMP and V_EXT_ACT.
• Push button "Multiple selections" button behind field Objects
• Fill: V_EXT_IMP and V_EXT_ACT

 Push button "Copy (F8)"


 Fill Operations: OPEN
 Push button Enter
See the result:

Interpreting the Trace list


89
All the interface class names of view V_EXT_IMP start with IF_EX_. This is the standard SAP prefix for BAdI class
interfaces. The BAdI name is after the IF_EX_.
So the BAdI name of IF_EX_ADDR_LANGU_TO_VERS is ADDR_LANGU_TO_VERS.
In transaction SE18 you can see the BAdI definition.

(If you can’t find the BAdI definition name, search in table SXS_INTER.)

Exporting the Trace list


If you’d like to keep your analysis, you can export it to Excel file format.
Actually the file will be saved in tab separated file format, but giving the file the extension .xls it will automatically
be opened by Excel.
• Start menu: List > Save > Local File
• Select Spreadsheet
• Push Enter
• Fill your preferred file location and file name

 Push button "Generate"


 Open the file (in Excel)

90
• Delete the columns and rows you don’t need and the result looks like:

View V_EXT_IMP and V_EXT_ACT


The reason for filtering the result not only on the view V_EXT_IMP but also on V_EXT_ACT is necessary, because
not all BAdIs are implemented in the same way.
For example:
V_EXT_IMP catches BAdI BPTIME_BP001.
V_EXT_ACT catches BAdI ADDRESS_SEARCH

Tips
• Make a full test entry in the Business transaction before starting the Performance analysis.
So during the Performance trace you won’t make mistakes. Making mistakes during the recording will cause extra
trace lines in your trace list.
• Try to start with an empty Business transaction screen.
This tip is best explained by an example.
When I restart transaction BP after I have created, displayed or changed a business partner, the last opened
business partner will be displayed automatically. This means also I will get extra trace lines in my trace list.
To start again with an empty business partner screen you have to close all GUI sessions and login again.
• In the Business transaction you need to fill all required fields so all BAdIs will be called.

Appendix BP analysis
View BadI
V_EXT_ACT R 20 ADDR_LANGU_TO_VERS ADDR_LANGU_TO_VERS
91
V_EXT_IMP R 30 IF_EX_ADDR_LANGU_TO_VERS ADDR_LANGU_TO_VERS
V_EXT_ACT R 20 BUPR_FILTER_RELTYP BUPR_FILTER_RELTYP
V_EXT_IMP R 30 IF_EX_BUPR_FILTER_RELTYP BUPR_FILTER_RELTYP
V_EXT_ACT R 20 BUPR_FILTER_RELTYP BUPR_FILTER_RELTYP
V_EXT_IMP R 30 IF_EX_BUPR_FILTER_RELTYP BUPR_FILTER_RELTYP
V_EXT_ACT R 20 BUPR_FILTER_RELSHP BUPR_FILTER_RELSHP
V_EXT_ACT R 20 BUPA_AUGRP BUPA_AUGRP
V_EXT_IMP R 30 IF_EX_BUPA_AUGRP BUPA_AUGRP
V_EXT_IMP R 30 IF_EX_BPTIME_BP001 BPTIME_BP001
V_EXT_ACT R 20 ADDRESS_SUBSCREEN ADDRESS_SUBSCREEN
V_EXT_ACT R 20 ADDRESS_SEARCH ADDRESS_SEARCH
V_EXT_IMP R 30 IF_EX_ADDRESS_SUBSCREEN ADDRESS_SUBSCREEN
V_EXT_IMP R 30 IF_EX_ADDRESS_SUBSCREEN ADDRESS_SUBSCREEN
V_EXT_IMP R 30 IF_EX_ADDRESS_SUBSCREEN ADDRESS_SUBSCREEN
V_EXT_IMP R 30 IF_EX_ADDRESS_SUBSCREEN ADDRESS_SUBSCREEN
V_EXT_ACT R 20 ADDRESS_SEARCH ADDRESS_SEARCH
V_EXT_ACT R 20 ADDRESS_CHECK ADDRESS_CHECK
V_EXT_ACT R 20 ADDRESS_CHECK ADDRESS_CHECK
V_EXT_ACT R 20 ADDR_TXJCD_CHECK ADDR_TXJCD_CHECK
V_EXT_ACT R 20 ADDRESS_CHECK ADDRESS_CHECK
V_EXT_ACT R 20 ADDR_PRINTFORM_SHORT ADDR_PRINTFORM_SHORT
V_EXT_IMP R 30 IF_EX_ADDR_PRINTFORM_SHORT ADDR_PRINTFORM_SHORT
V_EXT_ACT R 20 BUPA_ROLE_EXPORT BUPA_ROLE_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_ROLE_EXPORT BUPA_ROLE_EXPORT
V_EXT_ACT R 20 BUPA_BANK_EXPORT BUPA_BANK_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_BANK_EXPORT BUPA_BANK_EXPORT
V_EXT_ACT R 20 BUPA_CCARD_EXPORT BUPA_CCARD_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_CCARD_EXPORT BUPA_CCARD_EXPORT
V_EXT_ACT R 20 BUPA_INDSEC_EXPORT BUPA_INDSEC_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_INDSEC_EXPORT BUPA_INDSEC_EXPORT
V_EXT_ACT R 20 BUPA_ADDR_EXPORT BUPA_ADDR_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_ADDR_EXPORT BUPA_ADDR_EXPORT
V_EXT_ACT R 20 BUPA_GENERAL_EXPORT BUPA_GENERAL_EXPORT
V_EXT_IMP R 30 IF_EX_BUPA_GENERAL_EXPORT BUPA_GENERAL_EXPORT
V_EXT_ACT R 20 BUPA_GENERAL_UPDATE BUPA_GENERAL_UPDATE
V_EXT_IMP R 110 IF_EX_BUPA_GENERAL_UPDATE BUPA_GENERAL_UPDATE
V_EXT_ACT R 20 BUPA_BANK_UPDATE BUPA_BANK_UPDATE
V_EXT_IMP R 110 IF_EX_BUPA_BANK_UPDATE BUPA_BANK_UPDATE
V_EXT_ACT R 20 BUPA_CARDS_UPDATE BUPA_CARDS_UPDATE
V_EXT_IMP R 30 IF_EX_BUPA_CARDS_UPDATE BUPA_CARDS_UPDATE
V_EXT_ACT R 20 BUPA_ROLES_UPDATE BUPA_ROLES_UPDATE
V_EXT_IMP R 30 IF_EX_BUPA_ROLES_UPDATE BUPA_ROLES_UPDATE
V_EXT_ACT R 20 BUPA_INDSEC_UPDATE BUPA_INDSEC_UPDATE
V_EXT_IMP R 30 IF_EX_BUPA_INDSEC_UPDATE BUPA_INDSEC_UPDATE
V_EXT_ACT R 20 BUPA_IDENT_UPDATE BUPA_IDENT_UPDATE
V_EXT_IMP R 30 IF_EX_BUPA_IDENT_UPDATE BUPA_IDENT_UPDATE
V_EXT_ACT R 20 ADDRESS_UPDATE ADDRESS_UPDATE
V_EXT_IMP R 30 IF_EX_ADDRESS_UPDATE ADDRESS_UPDATE
92
V_EXT_IMP R 30 IF_EX_ADDRESS_UPDATE ADDRESS_UPDATE
V_EXT_ACT R 20 BUPA_ADDR_UPDATE BUPA_ADDR_UPDATE
V_EXT_IMP R 110 IF_EX_BUPA_ADDR_UPDATE BUPA_ADDR_UPDATE
V_EXT_ACT R 20 BUPA_TAX_UPDATE BUPA_TAX_UPDATE
V_EXT_IMP R 110 IF_EX_BUPA_TAX_UPDATE BUPA_TAX_UPDATE
V_EXT_ACT R 20 FSBP_BPID_UPDATE FSBP_BPID_UPDATE
V_EXT_IMP R 30 IF_EX_FSBP_BPID_UPDATE FSBP_BPID_UPDATE
V_EXT_IMP R 30 IF_EX_BPTIME_BP001 BPTIME_BP001
V_EXT_ACT R 20 FSBP_BP001_UPDATE FSBP_BP001_UPDATE
V_EXT_IMP R 30 IF_EX_FSBP_BP001_UPDATE FSBP_BP001_UPDATE
V_EXT_IMP R 30 IF_EX_BPTIME_BUT021_FS BPTIME_BUT021_FS
V_EXT_ACT R 20 FSBP_BUT021_UPDATE FSBP_BUT021_UPDATE
V_EXT_IMP R 30 IF_EX_FSBP_BUT021_UPDATE FSBP_BUT021_UPDATE
V_EXT_ACT R 20 ADDRESS_SEARCH ADDRESS_SEARCH
V_EXT_ACT R 20 PARTNER_UPDATE PARTNER_UPDATE
V_EXT_IMP R 30 IF_EX_PARTNER_UPDATE PARTNER_UPDATE
V_EXT_IMP R 30 IF_EX_PARTNER_UPDATE PARTNER_UPDATE
V_EXT_IMP R 30 IF_EX_BPTIME_BP001 BPTIME_BP001
V_EXT_IMP R 30 IF_EX_BPTIME_BUT021_FS BPTIME_BUT021_FS
V_EXT_ACT R 20 GOS_SRV_SELECT GOS_SRV_SELECT
V_EXT_IMP R 30 IF_EX_GOS_SRV_SELECT GOS_SRV_SELECT
V_EXT_ACT R 20 ADDRESS_SEARCH ADDRESS_SEARCH

What the New Enhancement Framework Is For – Its Basic


Structure and Elements For Beginners - One

Introduction
Has it ever occurred to you while looking at some complex technology, that you are lost as to what the technology
is actually for? Have you ever had doubts as to whether the complex technology was created exclusively for the
entertainment of the developers? I confess that this thought crossed my mind when I first faced the huge
complexity of the new Enhancement Framework.
But after a second look I found that nothing could have been further from the truth. The "complexity" of this
framework has a clear function, and the basic structure that serves to accomplish this function is actually pretty
simple. In this , I want to explain what it is exactly that the new Enhancement Framework, packaged with
NetWeaver 7.0, provides the software developer. The Enhancement Framework is about resolving an old conflict in
software development: standard software solutions versus proprietary solutions. What the Enhancement
Framework does is to combine the advantages of both the standard (easily maintainable) with the proprietary
solutions (more flexible) while avoiding the drawbacks of both standard software (lack of flexibility) and customized
software (upgrade issues).
At the core of this framework is a simple structure consisting of a hook or an enhancement option and an
implementation element you can attach there. You may already understand that enhancements are preferable to
modifications. To take full advantage of what enhancements over modifications offer, you will need the new
Enhancement Framework. Its purpose: to offer you the ability to enhance the SAP standard software and to
organize these enhancement options and their respective implementation elements as effectively as possible. Don't
expect to learn about all the technical details of the Enhancement Framework in this particular , though. This , will
solely cover the basics of the framework. Once you have a clearer concept of the basics, you will see that the
93
complex structures of the whole framework serve a lot of different functions and still not feel lost within these
structures.

What SAP Does to Bridge the Gap between Standard Software and
Proprietary Solutions
So much for the aim of this ; now let's start to understand the basic gap between standard software and
customized software and how the Enhancement Framework brings you the best of both worlds.
Standard software can have many advantages over proprietary solutions in terms of cost, ease and effort. But
standard software is much like off-the-rack clothing. It doesn't always fit perfectly. There will probably be some
aspects in which standard software does not optimally meet the specific requirements of a process as it is realized
in a particular customer company.
On the other hand, proprietary software is usually better suited to meet your specific requirements. Unfortunately
having a non-standard solution also means a lot of drawbacks. Surely, your company prefers to concentrate on the
things it does best, be it building cars, selling food or whatever other core business and competences it has. So it
isn't really a very attractive option to resolve standard solution limitations by maintenance and further development
of a proprietary IT solution.
Of course, it would be great to have the best of both approaches: to have all the advantages of a standardized
software solution while having the flexibility of a highly customized solution. One way to accomplish this (at least to
a certain extent) is to have a standard solution that can be adapted to the individual needs of your company. SAP
has gone quite a long way in this direction.
Since SAP exposes and delivers the source code of all ABAP-based solutions, a customer theoretically could directly
modify SAP coding. But, of course, this should happen only in a controlled way. It would do no good to change the
source code in a totally ungoverned way. For this reason SAP offered so far two different technological approaches
to enable the customer to adapt SAP source code:
Modifications are changes of a SAP development object. These are supported and tracked by the Modification
Assistant.

Enhancements, on the other hand, do not change the SAP development object, but rather add something to it or
enhance it. Up to now, there were so-called User Exits and Customer Exits where you could put in additional source
code. Since release 4.6 there were also BADIs (Business Add-Ins). A BADI specifies an object-oriented interface
that can be implemented by a customer.

The new Enhancement Framework, packaged with NetWeaver 2004s, is intended to unify these two approaches:
the modifications and the classic enhancement technology. Up to now it integrates all the new enhancement
technologies such as the new BAdI, source code plug-ins, class enhancements, and function group enhancements.
The framework brings with it flexibility so that you have the freedom to adapt a solution to your own needs while
keeping all the advantages of a standard solution.
Simply stated, the new Enhancement Framework is an evolution of classic enhancement technologies. The concept
of enhancing a development object has some important advantages over modifying it. SAP has decided to optimize
the enhancement technology in such a way that you can now use enhancements in many of the situations where
you formally needed to modify the source code.

The Limits of Modifications and Why Enhancements Are More Powerful


Modification has limits almost inherent in this very concept. You face these limits when upgrading or transporting a
modified object. Imagine you have a modified program in your system and your system is upgraded. What
happens to your modifications? First, your modifications are gone, although you can re-insert them using the
Modification Assistant. But reinsertion means a lot of work for you. You have to go through your whole program
and look at all the modifications to see where they fit in the upgraded version of your program. Taking into account
the fact that you often have many modified programs spread over one or many solutions, modifications generate a
lot of work after an upgrade. Further limitations surface when you consider different modifications of the same
development object from parallel or subsequent development systems. All of these problems stem from the fact
94
that modifications are technically a part of the source code unit they modify. And one source unit exists only once
in a system. After an upgrade, a modified development object is first substituted by the unmodified one that comes
with the upgrade. In order to keep the modifications, you have to reinstate them in the new object.
Though the transaction SPAU offers you good support for this task, it is not at all a trivial task. If relevant parts of a
development object have changed, you need expert knowledge of this object to reinsert the modifications. The
administrator who runs the upgrade is most probably not able to merge the modifications properly. Instead of
using your systems at once after the upgrade you need some developers with expert knowledge of the relevant
solutions to attend to the modifications. So you pay for the high flexibility modifications offer with a lot of additional
work during upgrades.
When you have many modifications you surely want to organize them in some way. Unfortunately, as they
technically belong to the program they enhance, there is no possibility to group modifications. You cannot even
organize them at all in a structure of their own. Changes to a development object should, of course, be
documented. Modifications can have no documentation attached to them in the system. It is also not possible to
track who modified which parts of a development object.
Obviously all the limits of modifications originate from the fact that they are part of the object they modify. In
contrast to modifications, enhancements are objects in their own right. If you enhance SAP code these
enhancements are in your namespace, not in that of SAP. They are your objects.
Most of the advantages the Enhancement Framework offers are based on the fact that enhancements are objects
in their own right. You can organize enhancements in a structure of their own and document them in the system.
You can transport them in units of their own. As far as upgrades and transports are concerned, you can transport
enhancements from different systems into one system and keep all these enhancements, plus the ones that exist in
your target system. No enhancement gets lost.
This is the basic conceptual advantage that enhancements have over modifications. A major advantage of the new
Enhancement Framework is that it unifies all the new enhancement technologies in one framework. It is this
framework that realizes the advantages that are possible because enhancements are objects in their own right: The
enhancement framework enables management of different types of enhancements from different systems. They
survive an upgrade without a lot of additional work. You can organize them in a structure of their own and
document all the enhancements in the system.

Why and When to Change SAP Software


At this point you might ask yourself: Why should I change an SAP software solution at all? You should change a
SAP solution only if you have come to the conclusion that none of the possibilities of customizing meet your specific
requirements. First try out everything that is possible by means of customizing. If you are still in need of
adjustments of the standard you should consider enhancements as the means of your choice. As enhancements
are objects of their own they are quite robust in an upgrade. They will cause you far less work than modifications.
In addition to this advantage concerning the work necessary for an upgrade, the new Enhancement Framework
offers you a variety of useful features to manage, organize and document your enhancements. Just as
enhancements have advantages over modifications, not all enhancement technologies within the new framework
are equally suitable if you want to write highly structured code that causes as little work as possible during update.
But this will be explained in detail in another , in which you learn more about the details of the Enhancement
Framework.
Understood in this way, the new Enhancement Framework isn't an open invitation to freely enhance your SAP
solution in as many ways and means as are possible. The Enhancement framework can be compared to a powerful
tool. Think of it like a high-end precision drill which will probably not tempt you to sprinkle holes all over your walls
and furniture. It is merely a comfortable professional means by which you drill a hole whenever you absolutely
need to drill a hole. It is this attitude that you should have towards the Enhancement Framework. With standard
software there may be a necessity to adapt to your needs. Whenever there is a necessity, use enhancements
within the new Enhancement Framework.

The Basic Idea of the Enhancement Framework: How Do Modification- Free


Enhancements Work?

95
Before going into more detail, you should now understand the basic idea of the Enhancement Framework. It
provides a modification-free enhancement technology, enhancing source code units without modifying them.
The basic mechanism is to offer so-called enhancement options in development objects. These enhancement
options function like hooks where you can attach the enhancements. The hooks are part of the development
objects which can be enhanced. When you assign an enhancement to a hook, at runtime the enhancement is
processed when the control flow reaches the hook. In other words: At runtime the enhancement behaves as if it
belonged to the development object it enhances, while the enhancement as a transport object does not belong to
the enhanced object.
As this probably sounds a bit abstract let us have a look at a specific enhancement, the source code plug-in. At
predefined positions in the source code (for example, in a report) you have a particular type of enhancement
option, that is an enhancement point. At these points you can insert an enhancement that is called a source code
plug-in. The respective plug-in is processed after the enhancement point is reached by the control flow. That is, the
source code plug-in behaves at runtime as if it were part of the report while in fact it can belong to another
package.
This is what a source-code plug in looks like:

Ignore the details of the source code enhancement for the moment. This particular example only serves to
illustrate the point of how enhancements function: You have the anchor point or enhancement option, which is an
enhancement point in our particular example. At this enhancement point which is in the orange marked line the
enhancement element 1 (in grey colour) is inserted. The spot flights_display_b and the enhancement
flights_display are units you should not be interested in at this point.

In some way you can compare the enhancement technology with a closet system where you can insert different
elements at particular positions. You need not drill the wood in the side walls, but nevertheless you can attach
boards and other elements where there are already hooks or holders at important positions. The boards and other
elements such as drawer or CD-holder look as if they were integral parts of the closet system while in fact they are
only attached to the walls by hooks or holders.
The holder in our analogy corresponds to the enhancement options. The different elements you can attach there
such as boards, drawers, CD- elements etc. behave like the enhancements. You can not attach a board to the
closet system everywhere you like, but rather only where a holder is prepared. In the same way you cannot
enhance a development object anywhere, but only at predefined positions, which are called enhancement options.
So irrespective of all further refinements, superimposed containers and their respective connections, the basic
structure of how an enhancement functions is as simple as could be:
On the one hand, there are hooks or enhancement options where you can insert enhancement elements. Further
on I will also speak of the definition side of the Enhancement Framework because it is there that the enhancement
options are defined.

On the other hand, there are the enhancement implementation elements that you can attach to a hook or an
enhancement option.

96
The Complexity of the Enhancement Framework
Despite this simple structure the Enhancement Framework as a whole is pretty complex: You have different kind of
enhancement technologies. At different kind of enhancement options you can attach different types of
enhancement elements. The enhancement options are divided in two different classes: Implicit enhancement
options which are provided by the framework and exist without any particular preparation by a developer. Explicit
enhancement options have to be inserted explicitly in the source code. These explicit enhancement options must
belong to a container.
On the implementation side all implementation elements, regardless of whether they enhance implicit or explicit
enhancement options, belong to other containers. The containers on the definition side and those on the
implementation side are assigned to each other with a particular cardinality.
All these different units form a complex structure despite the fact, that the basic concept of a single enhancement
is so simple, as I have just shown you. But this structure is indispensable to accomplish all the aims the framework
is made for. The Enhancement Framework is made to organize and manage a huge mass of enhancement options
and implementations of different types. And it is mainly this aspect that requires the high complexity.
You might ask yourself why you need the containers if you just want to create a single enhancement option and
implement it. The answer is that you hardly ever need only one enhancement. As good software is usually divided
in components, one change (for example an additional field in a structure) necessitates a lot of other changes. And
in real life programming it is not just you, but your team and many other teams that create and so have to
mangage their enhancements options and implementations.
The framework not only offers you that structure to organize and manage your enhancement options and
enhancements, but the compliance with the framework is enforced by the tools. By adhering to the rules you can
be sure that you can fully take advantage of the framework and you will never face a situation in which you have
lots of unorganized enhancements in your system.
In the next , I will explain to you something further about the Enhancement Framework. I want to show you in
which way it is complex and why this level of complexity is needed. The aim of this , simply was to tell you what
the Enhancement Framework is about, why it was developed and what the basic structure of an enhancement is
like.

The new Enhancement Framework Part 2 - What Else You Need to


Know Before Building an Enhancement
This , is part two of a series on the new Enhancement Framework. it gives you the background information you
need to understand what you are doing when you define and implement an enhancement within the new
Enhancement Framework. At the end of this , we should have prepared the ground for building our first
enhancement definition.
You have learnt about the basic structure underlying the Enhancement Framework: It is an enhancement option
and the respective enhancement implementation element. The option can be compared to a hook, while the
enhancement is like a board attached to the hook. What makes modification-free enhancements possible is the fact
that an enhancement option can be developed in one system, and implementations in one or many other
subsequent systems. Once the control flow reaches the enhancement option the respective implementation is
processed though the implementations and the enhancement options are different transport objects.
The Enhancement Framework imposes a useful, complex structure of containers on the different enhancement
options and enhancement implementation elements. In this , I want to introduce the different enhancement
options and explain both the structure of the containers and motivation behind it. It is important to understand
right from the beginning why this structure is very useful for you. Only if you understand the benefits of this
structure, you will be able to take maximal advantage of it. Moreover the compliance to this structure is enforced
by the tools. This means as soon as you build your first enhancement you have to find your way within this
structure. So I have decided to explain another piece of theory before really showing you how to build a new BAdI
in the next ,.

97
The Different Enhancement Technologies
Let me start by giving a sketch of the different enhancement technologies that are part of the Enhancement
Framework. There are different kinds of technologies that provide enhancement options:
Class Enhancements: You can add additional methods, optional parameters, pre- and post-methods to existing
methods.

Function group enhancements: You can enhance the interface of a function module by additional parameters using
function group enhancements.

Source code enhancements: Enhancement points are positions in the source code where you can attach source
code plug-ins that enhance the source code at these positions. While a source code plug-in at an enhancement
point is processed in addition to the original code, the code of a so-called Enhancement Section is substituted by
the respective source code plug-in.

The BAdI is an object-oriented enhancement option. The BAdI defines an interface that can be implemented by
classes that are transport objects of their own. The new BAdI is fully integrated into the Enhancement Framework.
Within the Enhancement Framework a BAdI is an enhancement option or an anchor point for an object plug-in.

Implicit and Explicit Enhancements


There is one major distinction among the enhancement technologies: The implicit enhancement options are
provided by the framework without any effort on the developer's part. This means: The enhancement definition is
for free, while, of course, the implementation has to be inserted. Implicit enhancements comprise class
enhancements, function group enhancements and predefined enhancement points at particular predefined
positions such as the end of a report, a function module, an include or a structure and the beginning and the end
of a method. If there is a need for more or other enhancement options than those provided by the framework, you
can use so-called explicit enhancement options: They have to be inserted explicitly by the developer. There are two
types of explicit enhancement options: BAdIs and explicit enhancement points or sections, where you can insert
source code plug-ins.

The Nature of Developing Enhancements or Why to Group Enhancements


Enhancements are sociable beings. They hardly ever come alone, in particular when you write your programs
according to sound modularization principles. Imagine, you introduce an additional variable as an enhancement.
Probably you will work with this variable, transport it to all the different procedures that need the new variable for
doing their job and maybe show its value in the user interface. That means, you have to enhance the interface of
all these procedures, call these procedures using the new variable and also have to enhance the respective
interface. These considerations corroborate the fact that you will probably have a large number of enhancements
once you start using this technology.
If you have a large number of things, you need some organizing. This is a reason why it is a good idea to group
enhancements. Just imagine the mess on your hard disk if you could not sort the files stored there in folders. The
same is true for enhancements. Moreover, in general you enhance your code for a semantic reason. That is, you
want achieve some aim or other by your enhancements. For example, you add an additional variable because
maybe you want to calculate an additional tax value. This project necessitates other enhancements. A good way to
keep an overview is to keep all the enhancement options belonging to one project together. So it would be great to
have a technology that enables you to group and organize your enhancements.
Of course, the reasons for grouping enhancements apply in equal measure to the definition and the implementation
of enhancements. If you remember the structure of the enhancements you have probably realized that so far we
have talked only about the definition side. The enhancement option is a hook where you can attach an
enhancement. Within the terminology of the enhancement framework the enhancement that you attach to an
enhancement option is called the enhancement implementation element. So BAdI implementations, source code
plug-ins or function group enhancements are different types of enhancement implementation elements.

98
As a matter of fact, enhancement options and their implementations should not be grouped together as they
usually belong to different stages of development. Looking a typical scenario you will easily understand this: The
global IT department of a company develops a program with enhancement options that are implemented later by
the different local subsidiaries. To group these enhancement implementations together with the enhancement
options would undermine the basic idea of the enhancement framework, namely to make room for code that is
processed at runtime at a particular position of a compilation unit, while it does in fact not belong to this
compilation unit. Furthermore, developing these implementations is another project than creating the
implementation. And the grouping should group enhancements that belong to different projects separately.

The Structure of the Containers for Enhancements


So it seems we need at least two containers: one for the enhancement options on the definition side and another
one for the implementation side. Within the Enhancement Framework there are even more container types.
There are simple containers that can only contain enhancement options or enhancement implementation elements
respectively. As a consequence these containers cannot be nested. Moreover, one basic container can only hold
elements of one type: That is a simple container cannot, for example, hold BAdIs and enhancement points at the
same time. To make room for a nested structure there are composite containers that can hold basic containers and
other composite containers. These composite containers can contain basic containers of different enhancement
types. As these composite containers can be nested, you can build a structure that really fulfills the needs of your
project. A simple structure looks like this:

It is important that you have a clear idea of this structure in mind because everything you do when creating an
enhancement happens within this structure. This is due to the fact that the compliance to the rules is enforced by
the framework. This means for you: Every enhancement element has to be part of an enhancement spot. When
you create an enhancement from scratch you always have first to create the respective containers. You can
compare this to creating a method. There is no such thing as a method on its own. A method is always part of a
class. In the same way there is no stand-alone BAdI. Every BAdI is part of an enhancement spot and it is the spot
that is the transport object. It is because of this fact that you cannot build a new BAdI and just forget about the
framework in the way you might be accustomed to from the classic BAdI. It is also not possible to build the BAdI
first and take care later of how it fits in the structure of containers. When building a BAdI you have to put the BAdI
within the relevant structure from the very beginning. But it is only mandatory to have simple containers.
Composite enhancements spots and composite enhancement implementations are not enforced by the tools.
I mention this explicitly because, at first, it might be a bit astonishing for you when you want to create an
enhancement point and you first have to create an enhancement spot. When this happens, you should keep in
mind two things:
Experience has shown that structure has to be imposed by tools. Otherwise when programming it is tempting to
forget about the structure because it is time saving in the beginning. You see the real costs later when you get in
trouble trying to keep an overview of all the different enhancements.

99
You should be aware of the fact that you have only the containers after having created an enhancement spot and a
simple enhancement implementation. You have prepared the ground for building enhancements, but that is all.
Don't delude yourself into thinking that you have already an enhancement option or the respective implementation.

Previously, you have learnt the basic concept of an enhancement. In this , you have seen the different kinds of
enhancement options, you understand the difference between implicit and explicit enhancement option and you
know the structure where the enhancements fit in. In other words, now you have everything you need at hand to
build a BAdI. We will build a BAdI and see all the pieces of theory at work that you have become acquainted with
by now.

How To Define a New BAdI Within the Enhancement Framework -


Part 3 of the Series
This is part three of the , series on the New Enhancement Framework. You get to know some more facts as to
what a BAdI is and when to use it, and then, at last, we start with an example that shows you how to build the
BAdI with the respective tools in the ABAP Workbench and how the code to instantiate and call the BAdI is
integrated in the ABAP language.
In the last section, you have learnt about the basic structure of an enhancement, the different enhancement
technologies within the framework and the containers for enhancement options and enhancement implementation
elements. You need to know them in order not to lose your bearings within the Enhancement Framework when we
now start building a BAdI. If you have a mental map of the entities in the framework, you will find it really to easy
to understand what is going on in the example. So I would recommend you should take your time to recapitulate
theses basics, before proceeding to the practical part of this document.

Some Basics About the BAdI


Many of you know perhaps the classic BAdI. And there is some good news for them: The basic things about the
BAdI itself have not changed a lot, though there are some major improvements, such as a gigantic step forward in
performance. What will be totally new for those familiar with the classic BAdI is the way the new BAdI is embedded
in the container-structure of the Enhancement Framework.
For those not acquainted with the classic BAdI, let me spend some words on what a BAdI is and what it is for:
The BAdI is an object-oriented enhancement option. The BAdI defines an interface that can be implemented by
BAdI-implementations that are transport objects of their own. The new BAdI is fully integrated into the
Enhancement Framework. Within the Enhancement Framework a BAdI is an enhancement option or an anchor
point for an object plug-in.
A BAdI is to put it this way a controlled explicit enhancement option. It is an explicit enhancement option, which
means: BAdIs are not provided by the framework, but they have to be defined explicitly by the developer. Why do
I call it a controlled enhancement option. To understand what this means we have to go a bit deeper into the
methodology of enhancing development objects. Why is it done, and who does it? What is the typical process of
enhancing a development object like?

Providing and Implementing Enhancement Options - Two Different Roles


In this process there are two different roles: There is the so-called option-provider. He is the one who builds an
enhancement option that is a hook where others can attach something to. And it is essential to have such a hook:
Where there is no hook you cannot attach anything. This analogy means, that you can only insert an enhancement
implementation where there is an enhancement option. Of course, there are implicit enhancement options, that
are, so to speak, for free and always available. But there are not implicit BAdIs. If you need a BAdI, somebody has
to define it explicitly. Let us call this role the (enhancement) option provider. In general, the option provider is
identical with the developer of a development object that should offer an explicit enhancement option. Let us call
this object the basic development object. Typically, the developer of the basic development object could be
somebody working in the SAP core who anticipates that the customer or an industry solution might want to add
100
some code at a particular point. In this case he creates both the development object to be enhanced at a later
stage and defines an enhancement option.
An enhancement option that has no implementation does not do a lot when processed, in fact, it has no effect at
all. To make something happen at an enhancement option, you need to implement it. The developer who
implements an enhancement option, or to put it in the analogy, attaches something to the hook, is called the
implementer. He need not care about the details of an enhancement option, but just know how he implements it.
But, of course, he should have a sound knowledge of the way enhancement options function. You might compare
this to somebody who uses a service class. He does not need to know the inside of this class, but just its public
methods or maybe even only the respective interface he is interested in. In the same way, the implementer only
needs a limited knowledge as to how to define an enhancement option.
In the strict sense, many of you are probably only interested in implementing a BAdI. They suppose that SAP
provides the BAdI and calls the respective BAdI methods. All they want to know is what they have to take heed of
when writing the BAdI implementation. But it is quite useful to know a bit more about defining a BAdI, and once
you have understood what a powerful pattern a BAdI is, you might also be tempted to write your own BAdI
definitions. Moreover, it would be a bit long-winded to write two different series of ,s, one for the option provider
and another one for the implementer, because there is a large overlap in the background knowledge. For all these
reasons, I have decided to handle both topics in this one series. But still, I treat building the BAdI in this , and
providing an BAdI implementation in the next one. And you should always keep in mind: Implementing and
defining a BAdI are two different roles. And the same is true for source code enhancements.

The BAdI as a Controlled Enhancement Option


To fully grasp in which way a BAdI is a controlled enhancement option, let us first have look at source code plug-
ins in contrast. This enhancement technology is not controlled at all. This means: The option provider inserts an
enhancement point in the code thereby giving the possibility to attach a source code plug-in. The implementer can
insert any code whatsoever at this enhancement point. The option provider has no control at all on the code that is
written, because generally it is implemented at a later stage of development. Moreover the code of the source code
plug-in has access to all the variables that are visible within the modularization unit that is enhanced. So the option
provider cannot prevent the implementer from changing the value of some variables that should not be touched at
all. In fact he cannot bar the implementer from anything at all.
With BAdIs, things are completely different. The option provider has a firm grip on what the implementer does
insofar as he defines the interface and confines the implementer to the class that implements the BAdI. In detail
this means: A BAdI defines the methods with their signature, that is, which parameters the respective method
imports, exports, changes or returns. The BAdI implementer has to implement these methods defined in the BAdI
interface. We could put it this way: With a BAdI the option provider defines what has to be done, but leaves it to
the implementer how he implements the BAdI. Moreover, the BAdI implementer cannot fiddle with the basic
program. It is assured that a BAdI implementation can only change the parameters handed over to BAdI. The
implementation of a method has a context of its own and the variables of the development object using the BAdI
are not even visible from inside the BAdI implementation.

BAdI Commands in ABAP


There are two ABAP commands for the new BAdI. GET BADI hugo returns a handle to all active instances of the
implementations of the respective BAdI. For example hugo might refer to five active BAdI implementations.
You call a BAdI method with the command: CALL BADI hugo->method. If a method of the BAdI is called, all active
implementations are selected. So this amounts to a loop with the different method calls in it.

When to Use a BAdI?


As a potential option provider you should use a BAdI if you already know that a particular procedure should be
executed at a particular position in your program, but you want leave it to somebody else to specify the specific
content of that procedure. This is typically the case if the details of the procedure vary among different potential
implementers or are so specific that the developer of basic development object does not know them or want to
give the possibility to add different implementations at a later stage.
101
So the developer of the basic development object just writes something like saying: subtract your fees and return
the result. He does not care about what the different fees are and if there is a complex formula, percentages
calculation or just a simple subtraction. To do this the option provider writes a BAdI which contains a method:
subtract_fees CHANGING costs.
This way, a BAdI can be used quite well to understand what enhancements are for from a semantic point of view.
This is because the way BAdIs work is pretty much like our common sense concept of enhancing something.
Usually we do not think: Just add any enhancement, but add something as a means to a particular end. You can
decide yourself how you want to accomplish the end, but the end is defined. This is one analogy to explain a BAdI.
You might compare the usage of BAdIs also to the process when some company delivers the same car body to
different manufactures of multi-purpose vehicles. They all build their specific vehicle on the same car body. The
producer of the car body leaves the technical details to the different manufacturer, but of course it prescribes that
the car suspension has to be build in here and the engine there. In this way, the engine has to be in a particular
place and has to have particular properties, but all the other details are up to the manufacturer of the multipurpose
vehicle.
This process can be compared to the process of multilevel software development I have already sketched: The
program logic of a SAP core program needs some value at a certain point, but the developer of this program does
not know how to calculate this value. So he inserts a method call that should provide this value, but leaves the
actual implementation, that is the calculation to the developer of the next development level. In terms of this
framework, the developer inserts an enhancement option that is a BAdI, providing the respective method in its
interface, and also a call of a BAdI method.

Multiple and Single Use BAdIs


Concerning the programming model, there are two different BAdI types: Single- and multiple use BAdIs. They have
a completely different semantics.
The use case with the calculation I have sketched above is a typical example of a single use BAdI. The basic
program needs the result of a calculation. You leave the implementation details of the calculation to subsequent
levels of development, for example the developers for the particular countries. The business logic requires a result
of the calculation, and it must be exactly one result. The next steps in the program need this result, so you need at
least one BAdI implementation. And there is no way to process many return values, so you need exactly one result.
If you have a single use BAdI, the system takes care that there is exactly one active implementation. This way the
call of the method of a single use BAdI functions like a method call.
Multiple use BAdIs are quite different in this respect. Such a BAdI is suitable for activities, that might be done or
not and that might even be consecutively done in different ways in different implementations when a program is
executed. Imagine you build a BAdI additional_output that might convert data for different additional output
devices such as a Blackberry, handy, etc… Many different active implementations can coexist in the program
simultaneously, but there might also be no active implementation. So the call of a method of a multiple use BAdI is
in a way like sending a message: You do not know and do not care how many services react to the message. It
corresponds to a publish and subscribe mechanism.

Building Our First BAdI

The Use Case


And now let us have a look at an example in detail. Imagine that the developer of the basic program needs the
VAT of different book entries. These entries should be passed to a method that calculates and returns the VAT. As
this developer does not know what the VAT in a specific country is, he defines a BAdI badi_vat with the method
get_vat. This method should return the VAT for a particular value that is passed to the method get_vat.

Building the Enhancement Spot


The first thing you need when creating a BAdI is a container for the BAdI. Up to now we have no container, so we
have to create a (simple) enhancement spot. This is the container in which we develop our BAdI.
We go to the ABAP workbench and navigate there to our local objects. We select:
102
Create->Enhancement->Enhancement-Spot
from the context menu of the local objects folder.
This is what the dialog window looks like:

We enter a name for the enhancement spot and some short text. To name a composite enhancement spot is
voluntary. We are content with our enhancement spot and need no higher level container for the example. In real
life programming, you probably should take advantage of the structure the composite enhancement spots offer you
and always work with these complex containers.

The BAdI Itself


Next we create a BAdI within the new enhancement spot. We select the CREATE icon on the left:

In the dialog window that appears we enter the BAdI name z_badi_calc_vat plus a short description and confirm.
Now we have a BAdI in the list of our enhancement spot. We deselect the property "multiple use", because for our
calculation we need a single use BAdI:

The BAdI Interface


More important is the fact that up now we do not have much of BAdI. We need an interface. In fact, it is the
interface where you define the methods that determine what use you can make of your BAdI. Understood this way,
the interface makes up the identity of a BAdI to a large extent. After clicking the arrow in front of the BAdI name
103
and after doubleclicking Interface in the tree below we can input the name of the interface. You can either choose
the name of an interface that already exists or create a new one. There are no restrictions on the name of the
interface enforced by the framework. But, of course, you should conform to the normal rules for choosing speaking
names in a systematic manner.

Selecting the Change icon leads you to the class builder, where you can create the methods you need for your
BAdI in the same way that you are used to if you are familiar with the class builder. We just type in the name of
the method get_vat and enter the parameters we need.
A BAdI interface has to implement the interface if_badi_interface. But if we create a BAdI interface in the way just
shown this marker interface is already integrated in the BAdI interface. Probably you know how to work with the
class builder, but still I have inserted the following two screenshots to show you: Defining a BAdI interface is just
normal ABAP Objects programming and as simple as could be for anyone familiar with the Class Builder. We define
one BAdI method.

Next we determine the parameters of the method.

We save and activate the interface and the spot.


So let us now take a breath and consider what we have created so far:

104
We have created an enhancement spot and a BAdI with an interface. The interface has one method so far.
Of course, just building a BAdI does not suffice. It does not do anything. You need a BAdI instance, and this
instance must be called somewhere in the code. This is the definition part of a BAdI. But as a BAdI only defines an
interface, you need a class that implements this interface. Remember: A BAdI definition is the option to insert an
object plug-in that does a job at runtime. You still need an object that is plugged in to get something done.

BAdI Commands in ABAP


So it is time to write some ABAP code to use the BAdI. We need a variable that can refer to the BAdI and some
variables which are given as actual parameters to the BAdI method. Next we create a handle for that BAdI and call
the BAdI method get_vat. The respective commands are GET BADI and CALL BADI.

If we run the program it dumps. Considering what I have told you before about the single use BAdI, this is no
wonder. It is mandatory, that there is exactly one active implementation for a single use BAdI. Our BAdI is a single
use BAdI. One way to handle this is to catch the respective exception cx_badi_not_implemented.

Using and Creating a Fallback Class


The other way is the better solution, namely to use a fallback class. A fallback class for a BAdI is used if there is no
active BAdI implementation. This means: The GET BADI command returns a handle to an instance of the fallback
class and the respective CALL BADI calls the methods of the fallback class instance. As soon as there is an active
BAdI implementation, the fallback class is not used any longer at runtime. So using a fallback class serves two
functions at once:
• The program runs with a single use BAdI without raising an exception.

• It is guaranteed that the fallback class is not used any more as soon as a BAdI implementation is
supplied. So a fallback class is only selected conditionally. This is important, because the BAdI provider does usually
not know the details of some process. This is why a BAdI is used.

We select the checkbox the bottom with the text: Call fallback class if no implementation is executed and insert a
name for the class.

105
Clicking the change icon leads us to the class builder. Again the tools do a great job for you: The respective
method of the BAdI interface is already defined. We only have to implement it:

I skip this, because it is no news to anybody familiar with the Class Builder. Of course, we have to save and
activate the class. Then we navigate back to the enhancement spot and activate it.
Running the program again leads to result:
percentage: 20 VAT: 10.
And this is the end of this ,. Now, you know how to build an enhancement spot and a BAdI including the BAdI
interface and a fallback class plus the ABAP commands to use the new BAdI. In the next , you learn how to create
a BAdI implementation inside the respective container, that is the (simple) enhancement implementation and how
to select among the different BAdI implementations using the addition FILTER to the GET BADI command.

How to implement a BAdI And How to Use a Filter - Part 4 of the


Series on the New Enhancement Framework
In the last , we defined a BAdI, provided a fallback class, instantiated the BAdI and called a BAdI method. Of
course, we also provided an enhancement spot, because our BAdI, as every BAdI, needs a container to live in.
As you have learned, the fallback class is chosen in case no BAdI implementation is available. As we have not
created a BAdI implementation so far, the method implementation of the fallback class was used in our example
code. To change this, we create a BAdI implementation in this ,. As soon as there is a suitable BAdI
implementation the methods of the fallback class are not used any longer.
First let us have a short look at the entities we have so far: There is the enhancement spot z_es_calc_tax in which
the BAdI z_badi_calc_vat lives. The BAdI interface defines an important part of the BAdI identity, insofar it defines
the BAdI methods that can be used. Our interface z_if_calc_vat has one method get_vat( ).

106
The definition and the implementation of BAdIs are similar in one respect: Just as you need a container that is an
enhancement spot for a BAdI, you cannot build a BAdI implementation unless you have the relevant container first.
The relevant container type for BAdI implementations is called (simple) enhancement implementation. A simple
enhancement implementation can keep many different BAdI implementations, but with one restriction:
A simple enhancement implementation is uniquely assigned to an enhancement spot. That means: A (simple)
enhancement implementation can keep only BAdI implementations of BAdIs that belong to the spot the simple
enhancement implementation is assigned to. This has the consequence: An (simple) enhancement implementation
cannot keep BAdI implementations that implement BAdIs belonging to different spots.
This being so, we have first to create a container that is uniquely assigned to the enhancement spot our BAdI
belongs to. Despite the fact that we have to do something pretty complex, the respective tool in the SE80 has
paved a smooth way to do this. All you have to do is to press one button. This button is marked with an orange
frame in the screenshot below:

We get to the dialog window, where we can create a (simple) enhancement implementation:

The next dialog window opens:

107
What are we asked to type in here? We have created so far a container for BAdI implementations, that is a
(simple) enhancement implementation. This container is uniquely assigned to our enhancement spot. Once this
connection is established, we can create a BAdI implementation for the BAdI within the enhancement spot. As we
have defined only one BAdI within the enhancement spot, we have no choice. If we had more BAdIs in our
enhancement spot, this would be the point where to select which BAdI we want to implement. As matters stand,
we type in z_bdi_calc_vat_us as the name of the BAdI implementation, confirm and save the enhancement spot in
the next window. There we are: This is (simple) enhancement implementation that contains the BAdI
implementation z_bdi_calc_vat_us:

Obviously, the appearance of a (simple) enhancement implementation in the tool is pretty much like the one of an
enhancement spot: Under the tab Enh. Implementation Elements there is a tree with the BAdI implementation(s)
contained on the right-hand side. On the left, you see the properties of the marked BAdI implementation.
Note: Select the property "Implementation is active" under the header "runtime behavior". If you do this the text
below changes to: "Implementation is called". That is intended to help you understand what the selection you have
just made is for. Farther below, there is a list that shows the properties of the BAdI definition our BAdI
implementation is assigned to.
To better understand the structure in which our objects are imbedded, let us have a look at this sketch:

108
At the top, there is the definition part: In principle, such a spot can contain many different BAdI definitions. Our
enhancement spot contains only one BAdI definition. We have created a container for the BAdI implementations.
This (simple) enhancement implementation is uniquely assigned to the enhancement spot, but one enhancement
spot can have many enhancement implementations assigned to it. We have a one-to-many relationship between
the enhancement spot and the enhancement implementation. With this relationship established, we have assigned
a BAdI implementation to our BAdI. Again, this is a one-to-many relationship: A BAdI definition can have many
BAdI implementations, but a BAdI implementation uniquely belongs to a BAdI.
Only if the relationship between the containers that is the enhancement spot and the enhancement implementation
is established, you can assign a BAdI implementation to a BAdI definition. I have tried to show this in the picture
by the large orange pipe that contains the small grey pipe.
You should keep in mind: When implementing a BAdI, you have first to establish a connection between the
relevant containers. Based on this connection you can go on and implement the BAdI. This principle applies to
source code plug-ins in an analogous fashion.
Now that we have a BAdI implementation, we need an implementing class. We click the triangle in front of the
name of the BAdI implementation in the tree and next double-click Implementing Class:

It works the same way as with the creation of the fallback class in the last ,. As we do not want to reuse an
existing class we enter the name z_cl_calc_vat_us and select the Change icon. Again, we get to the Class Builder
where the relevant interface methods are already defined. In our case it is only the method: get_vat( ).
We implement it:

109
We save and activate the class. If we have not activated the (simple) enhancement implementation before, we
have to activate it now. Now, we return to the program:

We run the program, and what do we get? The result is a percentage of four percent. And this is because the
fallback class is not selected, if we have an active BAdI implementation.
As a next step, we create another BAdI implementation, this time with the VAT rate of Great Britain. To make our
example more like real world programming, we create another (simple) enhancement implementation, that is
another container. This is because implementing the taxes for different countries most probably belongs to
different projects and because the structure of the (simple) enhancement implementations should mirror the
project structure.
We navigate to our enhancement spot and use the same button as we have done above. We name the simple
enhancement implementation z_ei_bad_calc_gb, the BAdI implementation z_bdi_calc_vat_gb, and the
implementing class Z_BDI_CALC_VAT_GB. The implementation of the method get_vat is the same as for the USA
except for the VAT rate, which is 16,5% now. After saving and activating the enhancement implementation and the
class we return to the program and run it again.
This time we get a short dump with the exception cx_badi_multiply_implemented. Remember: We have defined
our BAdI as single use by deselecting the property "Multiple Use". When instantiating a single use BAdI you have to
make sure that there exists only one active non-default implementation. Otherwise you get the respective
exceptions at runtime. These exceptions can be caught, but this is not our strategy here. We want to avoid the
exceptional situation right away.
Obviously, it would also make no sense, because we need exactly one result for our calculation and could not make
any use of if the two BAdI implementations would be called one after another. This was just why we defined our
BAdI as single use. What we need is a way to select among different BAdI implementations. And this is where the
BAdI filter enters the game.
What we need is to change the BAdI definition, that is one we need to add a filter. You can define one or many
filters for a BAdI. We will be modest and be content with one filter. Let us just define the filter in the BAdI
definition, determine filter values for the respective BAdI implementation and use the filter in the instantiation of
the BAdI handle. I hope in hindsight, you will understand what we have done and why.
You should keep in mind that what we do now when modifying our example does not take into account the
differentiation between the BAdI provider and the implementer. In real life it is the BAdI provider who defines a
BAdI with a filter or adds a filter to an existing BAdI. It is also part of this role to use the filter condition in order to
select the respective BAdI implementation in the ABAP code. It is the implementer who determines the filter
value(s) or an interval for one or many BAdI implementations. In the example we do all this ourselves for the sake
of the example.
We start by adding a filter to our BAdI (role of BAdI provider) and to this we navigate to our enhancement spot
and stay in the tab "Enh. Spot Element Definition" that shows a list of all the enhancement elements the spot. We
switch to the change mode, mark our BAdI in the list, and click the Filter icon above. A dialog box opens and we fill
out the relevant fields as shown below:

110
We confirm and get to the next screen. Obviously, the filter is now visible as a property below the BAdI. After
activating the enhancement spot, we double click Implementation and navigate to the respective BAdI
implementation by double-clicking the respective row in the table of BAdI implementations.

We switch to the change mode, click the triangle in front of the BAdI implementation in the tree and then double-
click the filter icon below. In the next window we select the Combination icon, select "Country" as filter and
confirm:

Double-clicking the row below "Combination 1" leads us to the next window:

111
As I have told you above, adding or changing a filter value of a BAdI implementation is part of the implementer's
role.
After we have activated the (simple) enhancement implementation, we navigate back to the spot. Apparently, the
other implementation, that is the one for USA needs also the respective filter value. So we go to the respective
(simple) enhancement implementation and change the BAdI implementation in an analogous manner. The
respective filter value for this country is 'US'. I skip the description of how to do this, because what we do is
identical to what we have done before when creating the filter value for the BAdI implementation
z_bdi_calc_vat_gb. We must take care that we do not forget to activate the (simple) enhancement
implementations and to select the property "Implementation is active" for every BAdI implementation.
Now it is time to return to our program and adapt it to the modified BAdI (this is also the task of the BAdI
provider). Running the syntax check shows you that you need to have a filter parameter in the GET BADI command
if the BAdI you try to instantiate is defined with a filter. The requisite addition to the GET BADI command is
FILTERS. It is after this keyword that you insert the name of the BAdI filter and a value the filter is compared to. Of
course, we also have to take care that an appropriate value can be passed to the GET BADI routine:

If you pass "GB" to the parameter ctry, you will get a VAT rate of 16,5 percent. If the value of the parameter ctry is
"US", the VAT rate will be 4 percent. When the parameter ctry has any other value, we will still get a calculated
value for the data field 'percent'. And this is because we have defined a fallback class for our BAdI. The fallback
class is not only selected if no BAdI implementation is available, but also if none of the existing BAdI
implementations meets the filter conditions in the GET BADI command. Accordingly, we get a VAT rate of 20
percent. And this was the VAT rate we have implemented in the method get_vat in the fallback class.
And this is the end of this ,. You have now learned how to create a BAdI implementation for a given BAdI. You
know that a (simple) enhancement implementation is a container for BAdIs and moreover how and also why to
assign it to a (simple) enhancement spot. That is you have understood the way the different elements of the
enhancement framework interact when implementing a BAdI. And, in the second part; you have learned how to
create a filter for a BAdI, how to determine filter values for BAdI implementations and what the appropriate syntax
for calling a BAdI with a filter is like.

Source Code Enhancements - Part 5 of the Series on the New


Enhancement Framework
In this , I want to address several topics that center more or less around creating source code enhancements. At
the beginning, I focus on the different use cases in which developers outside of SAP create an enhancement
option. In a next step I narrow the scope and ask the question which type of enhancement option you should
prefer as an option provider and in which cases a source code enhancement should be your first choice. As I have
already stated , in general SAP recommends the use of BAdIs. Still the BAdI is no all-purpose weapon. There are
situations in which it is better to use source-code enhancements instead. After sketching these situations I will

112
show you how to create an enhancement point, how to implement an enhancement point and how to overwrite an
implementation created in another system without modifications.

Why to Define an Enhancement Option as a Developer Outside of SAP - the


Different Use-Cases
Let us start by spending some thoughts as to when and why you might want to define an enhancement option as a
non-SAP developer. Of course, it should be clear at the outset that in most cases you will implement enhancement
options if you are a non-SAP developer. But as you will learn soon, there is one group of non-SAP developers that
will take great advantage of defining enhancement options themselves. These are the ones developing solutions
that should be enhanced by somebody else later. I will treat this group in the first use case. In contrast, the second
use case is not confined to a particular group, but to any developer who is interested in keeping an unavoidable
modification as small as possible.
1a.Imagine, you are an ISV, develop your product in ABAP and want to enable your customers to enhance your
product at certain points. In this case, you provide enhancement options where you think they are useful.
1b. The same applies to the IT department of a multinational company. It develops some solution in ABAP and
wants to make room for changes or enhancements that the different local subsidiaries can implement. Again using
enhancement options are the suitable way to do this. Both cases are semantically and technically pretty the same,
so that I decided to subsume them under the same use case.
2. The second use case is a bit more complex to describe: You are a SAP customer and need some enhancement of
a SAP solution. Let us assume that the implicit enhancement options available in the relevant development objects
do not suffice to accomplish this and that there are also no suitable explicit enhancement options. So you are left
with the possibility to modify the relevant SAP development objects. But still there is room for using enhancement
options. To reduce the effort necessary for adapting your modifications after an upgrade it is a good strategy to
keep your modifications small. To minimize the size of your modification you create enhancement options within
the modifications you insert. Then you add all further code to the implementation of these enhancement options.
This way the modifications only contain these enhancement options and all the other additions are part of your
namespace. In this use case modifications and enhancement cooperate in an interesting way.

The Limits of the Enhancement Framework


The very existence of this use case also helps to provide an answer to a question frequently asked: Namely,
whether the new enhancement framework suffices to avoid all modifications. A realistic answer is: A clever use of
enhancements enables you to do without modifications in many cases. On the one hand, there are explicit
enhancement options provided by the developers of the respective solution. On the other hand, there are a huge
number of implicit enhancement options. There are implicit enhancement points at the end of a function module, of
a structure definition, of a report and of an include, in each defining section of a local class, and at the end of the
implementation of a local class. Moreover, you can enhance a function module by additional parameter. A global
class also offers a variety of implicit enhancement options: You can add methods, attributes, and interfaces to the
class. Each method can be enhanced by a pre-exit, a post-exit and an overwrite-exit that substitutes the original
implementation of the method.
Looking at the huge number of different implicit enhancement options it is probably possible to achieve your aim
without modification very often. But still this is not always possible. Let us put it this way: What the new
enhancement framework offers is intended to support modification-free enhancements to as large an extent as
possible. But still, there is no guarantee that this is always possible. In case the enhancement options available for
you do not suffice you should decide to create an enhancement option as a modification.

When to Use Source Code Enhancements


So much for the question when to create an enhancement option and the little excursus on the limits of the
enhancement technology. The next question is what enhancement option you should prefer. In general, SAP
113
recommends using a BAdI whenever it is possible. This is due to the reasons already named: A BAdI has a well
defined interface and because of that the enhancement option provider has a firm control of the implementation.
Moreover, the implementations can only access the data passed to them by the parameters of the respective
methods. And again, it is you the BAdI provider, who determines which data should be passed to a BAdI method.
This great advantage of the BAdI is also a drawback in some situations. Thinking about this leads the way to
understanding under which conditions a BAdI is not the suitable solution if you want to provide an enhancement
option. This is, for example, a situation, in which you do not know which data the potential implementer of your
enhancement options needs or provides. To put this point another way, if you do not know the interface, you
cannot and, of course, should not use a BAdI. Given this condition, you should use the technology of enhancing the
source code.
This enhancement technology comes in two flavors:
- At Enhancement points an implementer can add some lines of code which are executed at runtime when the line
with the statement ENHANCEMENT POINT is reached. Then the control flows proceeds to the next line after the
enhancement point. There can be none, one or many active source code plug-ins (as these enhancement
implementation elements are called) assigned to an enhancement point. All these source code plug-ins are
executed in addition to the code that is enhanced.
- An enhancement point cannot be part of another statement. This means a statement cannot be enhanced. And
that fact sets a limit to the power of enhancement points. For example, there is no way to add a new condition to
the where clause of a select statement by using an enhancement point. This is one prominent use case for an
enhancement section. Imagine you have a select statement:
SELECT a b c FROM my_table INTO wa.
and want to leave it to the implementer to add a where-clause or select other fields from this table. So you mark
the select-statement as an enhancement section, which looks like this:

Don't worry here about the details of the syntax. At this stage, you should just note that the code marked as an
enhancement section is substituted by a source code plug-in as soon as one is provided. Obviously it is required by
the logic of enhancement sections that one enhancement section can have exactly one active implementation.
Let me just restate the main point about the use of source code enhancements: This enhancement technology is
suitable if you want to provide an enhancement option and cannot or do not want to specify an interface.

Defining an Enhancement Point


Now that you know why and when to use source code enhancements you are probably eager to know just how you
create an enhancement point and how you implement it. Before going into any details let me just remind you of
the basic structure of the enhancement framework that applies to source code enhancements as well: When you
define an enhancement point, this point has to be part of an enhancement spot. This means if you cannot use an
existing enhancement spot you have to create one when creating an enhancement point. The same applies in an
analogous way to source-code plug-ins: A source code plug-in is uniquely assigned to an (simple) enhancement
implementation. But this structure should be pretty familiar to anybody in which I show how to implement a BAdI.
(Simple) enhancement implementations serve as container for enhancement implementation elements.
So enough with the background structure. Let us go into the details and create an enhancement point. We go to
the source code that we want to enhance, open the respective unit in change mode, put the cursor on a line and
choose the right mouse menu:

114
In the next dialogue window we enter the name of the enhancement point and the name of the spot plus the name
of the relevant package as shown below.

As a result an enhancement point is inserted into the code before the line where the cursor was:

This is what an enhancement point looks like. An enhancement point has a name that is unique within the source
code unit it belongs to and is uniquely assigned to an enhancement spot.

Implementing an Enhancement Point


Now we switch our role. For the sake of simplicity we provide here both the definition and the implementation of
our enhancement point. Of course, you know by now that the provider of an enhancement option and the
implementer are two different roles. To implement an existing enhancement point is not possible in the change
mode for an obvious reason. Of course not. The one who implements an enhancement option does not want do
modify the program. That is what the whole business of the enhancement framework is about. So we switch to the
enhancement mode by selecting the relevant button:

There we are. We choose the right mouse menu on the line where the enhancement point is and select Create in
the submenu:

We get to this dialog window:

As I have told you have first to provide a container for the source plug-in, that is an enhancement implementation.
Let us call our enhancement implementation ei_my_implementation. Of course you should not forget the

115
explanatory text. It is possible to create a composite enhancement implementation by using the Create icon. But it
is not necessary, and so we do without this meta-container here. And there we are:

Before inserting some code just note that the source code plug-in itself is not named. It is by assigning an
enhancement implementation to an enhancement point that a source code plug-in comes into being. We just enter
the code: WRITE 'implementation'.
After the code for the source code plug-in is supplied we should activate it by selecting the respective button:

Source Code Enhancements - The Structure of the Entities


For those who do not feel totally familiar with the structure of the entities, we have created so far let me just
sketch the structure of entities we are concerned with:

Our enhancement point uniquely belongs to the (simple) enhancement spot es_my_spot. This spot is assigned to
the (simple) enhancement implementation ei_my_implementation. (Simple) enhancement spots containing points
or sections and the relevant (simple) enhancement implementations are in an n to m relationship. That means:
Points belonging to one spot can be implemented by source code plug-ins belonging to different (simple)
enhancement implementations. And source code plug-ins belonging to one (simple) enhancement implementation
can implement points belonging to different (simple) enhancement spot. (This does of course not mean that one
source code plug-in can implement different points) It is the compilation unit that holds the respective (simple)
enhancement spots and (simple) enhancement implementations together: Spots containing points in one report
cannot contain points in other programming units. The same is true for the enhancement implementations in an
analogous way. An enhancement implementation cannot be assigned to points that belong to different
programming units.
Source code plug-ins are unnamed. You create a source code plug-in by assigning a (simple) enhancement
implementation to an enhancement point. In turn, this means that a (simple) enhancement implementation can
only be assigned once to an enhancement point. Otherwise the identity of a source-code plug-in would be blurred.
116
So much for the details of the structure of the entities involved when creating and implementing an enhancement
point. By the way, the structure of the entities and the whole process of defining and implementing is pretty the
same for an enhancement section. There is one notable difference: When implementing an enhancement section
you have to make sure that there is not more than one active source code plug-in.

Replacing Source Code Plug-Ins


Now let us consider in brief how to handle a use case that is a bit more complex. Suppose you are a customer and
want to change a source code plug-in created by a SAP industry solution. The background is that this code is
specific to the industry solution and does not fit your needs totally though your company belongs to the respective
industry. Changing the source code plug-in in the SAP namespace would, of course, mean modifying it. And this is
no attractive move and should be avoided as much as possible. There is a better solution for this problem than
modifying the source code plug-in in the SAP namespace.
The Enhancement Framework provides a nice feature to handle this situation. It enables you to overwrite an
existing source code plug-in by using or creating a (simple) enhancement implementation that is an object of
yours. This means you can substitute a source code plug-in without modifying the plug-in or the code unit it is
plugged in. And this is how it works:
Position the cursor on the enhancement you want to replace, choose the right mouse button and select:
Enhancement Implementation->Replace.
In the next dialogue window we have to enter the name of a new (simple) enhancement implementation. For
reasons already given, it has to be a new one and has to be different from the enhancement implementation to
which the source code plug-in to be substituted belongs:

What we do now is pretty the same procedure as when we originally implemented our enhancement point. We
enter some code and activate it by selecting the button Activate Enhancements. This is what our enhancement
point looks like now:

By using the respective entries in the context menu you can also change and delete source code plug-ins. But you
should keep in mind: You should not touch source code plug-ins created by SAP as this would mean to modify a
SAP object, in this case, the respective (simple) enhancement implementation. If a source code plug-in created by
SAP does not meet your requirements, you should replace it in the way just shown in the last use case. So you
should change and delete only the source code plug-ins you have created yourself. Instead of deleting an source
code plug-in created by SAP you should replace it by an empty source code plug-in. Again, this is the way to avoid
a modification.

Summary

117
By now you should have learned a lot of different things about the source code enhancement technology. Let us
first consider the definition part or the role of the enhancement option provider. You know the use cases for this
enhancement technology: As an option provider source code enhancements are the means of choice if you do not
know the interface of the enhancements to be made. You can also create an enhancement point as a modification
and add the rest of the code you need to a source code plug-in assigned to this enhancement point. This helps
keeping unavoidable modifications small. Apart from these use cases, the enhancement technology recommended
by SAP, in general, is to define a BAdI.
As to the implementing part, you know:
• how to implement an enhancement point,

• how to change or delete an source code plug-in of your own,

• how to replace an existing source code plug-in in the SAP namespace.

118
Enhancement Framework

119
Enhancement Framework
- The new way to enhance your ABAP systems

Learning Objectives
As a result of this session, you will be able to:

• Understand the fundamental idea of the Enhancement Framework and Switch Framework
(available in SAP NetWeaver 2004s)
• Reduce TCO by using enhancement technologies instead of modifications
• Enhance SAP standard objects
• Understand how Enhancement definitions are created

Availability

120
SAP NetWeaver

Adapting SAP Software


One of the advantages of SAP software is the possibility to adapt the software to own
requirements and the possibility of keeping the adaptations during upgrade.

Ways of adaptation:
• Customizing
• Enhancement
• Modification

Motivation
Reducing TCO
• Enhancing objects instead of modifying them reduces the effort for adjustment during SP import or upgrade.
Disadvantages of modifications
• No support for multiple users or projects
• No support for parallel developments
• Will appear much more often in adjustment tools
• Higher adjustment effort (during upgrade & SP import)

121
Evolution of SAP Enhancement Technology

Enhancement Framework

Enhancements – Relations

122
Terminology by Example

Enhancement Browser

Search for
• Enhancements possibilities (Definitions – typically provided by SAP)
123
• Enhancement Implementations (typically done by Customer)

Source Code Plugin – Technology

Source Code Enhancements Overview

Modification-free enhancement of
source code

Implicit Enhancement Option


• At common enhancement places, implicit Enhancement options are available. Examples:
• End of Executable Program, Include, Function group, Dialog module
• Begin/End of Form routine / Function module / Method
• End of a structure
• End of Private/Protected/Public Section of a local class
• ...

Explicit Enhancement Option


• Predefined enhancement options can be defined in source code. They are additionally stored inside
Enhancement Spots.

124
Implicit Enhancement Options

Explicit Enhancement Options

125
Source Code Plugin Technology - Example

Editor Modes for Enhancements

126
Function Group Enhancements

Function Group Enhancements allow:


• Adding new optional parameters to existing function modules

Class/Interface Enhancements
Class/Interface Enhancements allow
addition of:
• optional parameters to existing methods
• methods
• events and event handlers
• references to interfaces
• Exits to existing methods
o Pre-Exit – Called at the beginning of a method
o Post-Exit – Called at the End of a method
o Overwrite-Exit – Replaces the original method

Adding Methods & Parameters

Adding new methods

127
Adding optional parameters to existing methods

Pre/Post Exits

BADIs – Overview
What are BAdIs?
• Business Add-Ins
• is an anticipated point of extension – these points act like sockets and exist in the original coding
• has a well-defined interface in contrast to source code plug-ins and is therefore more stable to changes in
the original coding

Kernel BAdIs - New Features


• Are integrated directly in the ABAP Language/Runtime
• Improved filter support allows non-character filter types (packed, numeric, string) and complex filter
conditions
• Enable reusable implementation instances (Stateful BAdI)
• Control of the lifetime of implementations (BAdI-context)
• Allow for inheritance of implementations
• Can be switched by the Switch Framework

128
Comparison: Usage of Old BAdIs vs. new
BAdIs

129
New BADI’s and Enhancement Framework

Creating BADI in SE80

130
BAdI Migration (Automatic Migration)

Performance Comparison

131
Switch Framework – Motivation

Goal of Switch Framework:


Control visibility of repository objects at runtime through switches
The Switch Framework can be used to
• Switch on industry solutions / Enterprise Add-ons
• Develop new functions without affecting existing ones
• Enhance delivered systems at partner and customer site in the context of the enhancement framework with
own functions

Switch Framework - Motivation


Benefits:
• Industry Solutions are available with every release and SP without delay (i.e. timely provision of legal
requirements), CRT’s* are no longer necessary for add-on systems
• Industry Solutions can be enriched by generic functions from other industries
• Synchronization of release cycles and planning

Switchable Objects
Switchable Objects…
…by package assignment
• Appends, SI-, CI-includes for structures in DDIC
• Fixed value appends to domains
• Secondary Indexes
• Append Search Helps
• Enhancement Implementations
• Switch Business Configuration Sets ( Switch BC-Sets)

…by direct assignment


• Screen elements & Flow logic
• Menu entries & functions
• IMG nodes
• Customizing

132
Direct Assignment: Examples

Switch

133
Business Function

Business Function Set

134
Switch Framework: Architecture

Summary
• The Enhancement Framework offers new possibilities to extend the SAP Standard instead of modifying it.
o Source Code PlugIns
o Function Group Enhancements
o Class Enhancements
o New BAdIs
• The new BAdIs are more flexible and faster than the classic ones.
• The Enhancements offered by Enhancement Framework and some other object types can be witched by
the Switch Framework as part of a Business Function eg. An industry solution

135

S-ar putea să vă placă și