CLIENT Project

Enhancements
Enterprise Architecture Guidelines

Version: 1.7
Last Revision Date: Friday,November10,2006
Print Date: Friday,May8,2015

PAGE: 1 OF 14
10:10 AM

DATE: 5/8/2015

Document Statistics
Document
Identification

The following is current information about the document: (Maintain all relevant section)
Title

CLIENT Project Enhancements Development Guidelines

Version

1.0

Creation Date

09-20-2006

Authors

Satya Narendrula, Jeff Mueller, Narendra Gupta & Patrick

Stoneking
Enhancements

Development Type
Document Status

Revision
History

Approval
History

The following is a history log of revisions to the document:

Version

Author Of Revision

Creation Date

Comments

1.1

Narendra Gupta

9-29-2006

1.2

Satya Narendrula

10-03-2006

1.3

Narendra Gupta

10-03-2006

1.4

Satya Narendrula

10-04-2006

1.5

Narendra Gupta

10-06-2006

1.6

Mustafa Mustafa

11-09-2006

1.7

Michael Biel

11-10-2006

Added in the contents in the

EEW Section 2.5
Added content to SAP vs
External Development section
Added/Modify the content in
section 2.1,2.2,2.5 and 3.0
Decision trees are added for
review by team
Add the content in the section
3.2
Added Recommendation
Matrix (SAP vs. Ext Tools)
Changed title.
Added Enhancement Tool
Recommendation Matrix.
Modified Java reference.

The following is a log of approvals:

Version

Approver

Approval Date

Comments

1.1

Name of the
approver

mm-dd-yyyy

Initial version

PAGE: 2 OF 14
10:10 AM

DATE: 5/8/2015

Table of Contents
1.

PURPOSE...................................................................................................................4

2.

ADDITIONAL DATA ELEMENTS.........................................................................4

2.1
EXTENDING EXISTING TABLES VS. CREATING NEW TABLES: RULES....................4
2.2
DATA ARCHIVAL...................................................................................................4
2.3
EEW (EASY ENHANCEMENT WORKBENCH)........................................................5
2.3.1
Purpose........................................................................................................5
2.3.2
Features........................................................................................................5
2.3.3
Easy Enhancement Workbench for Business Partner..................................6
2.3.4
Easy Enhancement Workbench for Partner/Product Ranges.......................6
2.3.5
Adding New Fields in the PPR Standard Set Types....................................6
2.3.6
Easy Enhancement Workbench for Installed Base Management................7

3.

ADDITIONAL FUNCTIONALITY IN SAP...........................................................7

3.1
3.2

USERS EXISTS / BADIS........................................................................................7

FUNCTION MODULES (BAPI)...............................................................................8

4.

SAP CRM OR R/3 VS EXTERNAL DEVELOPMENT........................................9

5.

SAP ENHANCEMENT TOOLS............................................................................14

PAGE: 3 OF 14
10:10 AM

DATE: 5/8/2015

1. Purpose
The purpose of this document is to provide guidelines in the development of
enhancements of CLIENT Project. This document can be used by Project Managers,
Team Leads, System Architects and Development/Support teams in making
decisions about enhancements developments during the implementation and
maintenance phases of the project.
The below sections in this document describes the identified enhancements
categories and details of them.

2. Additional Data Elements

Additional Data Elements refers to the data elements which are not provided by
SAP with in the standard SAP-CRM or R/3 solutions. However, based on business
requirements additional data elements may need to be captured for transactional,
report or interface purposes.
Refer to the decision tree (Extending existing tables and Creating Z-tables) to
understand the strategy on additional data elements as enhancements.
Refer to data governance documents to find the additional data elements in
CLIENT project.
2.1

Extending existing tables vs. Creating new tables: Rules

If a business requirement or function requires few additional data elements along
with standard data elements then it is recommended to extend the existing tables.
These additional data elements may satisfy a business transaction or reports or they
can be used as place holders for indicator/statuses for future system processes.
New tables are generally created to support an additional business functions which
do not exists as a standard function.

2.2

Data Archival
It is recommended that, for any additional data that may need to be captured and
archived in the future using a tool such as DART, this data be captured by
extending the appropriate table to include new fields. Archiving zTables is not
straight forward and requires additional work.

PAGE: 4 OF 14
10:10 AM

DATE: 5/8/2015

2.3

EEW (Easy Enhancement Workbench)

2.3.1

Purpose

The Easy Enhancement Workbench is a development tool with which SAP applications
(called Business Objects in the following document) can be extended in a simple manner.
Customer enhancements to a Business Object are defined via wizards. The Workbench
then does all development work for the user; databank tables, screens and application
logic are created automatically. Finally the customer enhancement is included in the SAP
standard.
This also allows users without ABAP knowledge the simple possibility of extending the
SAP standard.
An extension created using the Easy Enhancement Workbench does not differ technically
from one created manually. In both cases transportable ABAP objects are created and the
same Customer Exits, Business Transaction Events or BADIs are implemented
The difference lies exclusively in the manner in which the required objects are created.
The automation offered by the Easy Enhancement Workbench is achieved by template
objects that are adapted to the extension definition and created by a generator.
The functionality of the Easy Enhancement Workbench is therefore only available for
specially prepared Business Objects, mainly from the CRM environment.
The type of extension is also predefined. In most cases the customer is offered the
possibility to add user-defined databank tables or fields.
In most cases the extension takes place system-wide. For example, when extending a
Business Object in the CRM the data exchange to the connected R/3 system is extended
and a new table is also created in the R/3.
The system landscape must be set up in order to be able to use system-wide generation.
2.3.2

Features

In the EEW, an assistant guides you through the enhancement process. The new fields in
the ABAP Dictionary and on the user interface are then automatically generated by the
system.
You can enhance objects from different CRM applications. You can find specific
information about these objects in the following documentation.

PAGE: 5 OF 14
10:10 AM

DATE: 5/8/2015

2.3.3

Easy Enhancement Workbench for Business Partner

Using the Easy Enhancement Workbench (EEW) for business partner in SAP CRM you
can easily extend the data model of business partner by new fields or tables and integrate
them in the business processes.
You can also convert the extensions in the business partner data model, which you
created using the Business Data Toolset previous to SAP CRM 3.1 and which were
limited to the SAP GUI user interface, to the People-Centric UI user interface.
2.3.4

Easy Enhancement Workbench for Partner/Product Ranges

Using the Easy Enhancement Workbench (EEW) for partner/product ranges (PPR) you
can easily extend the standard set types by new fields. The new fields are available in the
SAP GUI and People-Centric UI user interfaces and are also transferred to the CRM
Field Applications. The EEW uses customization includes for extensions in the standard
set types for PPRs.
The following standard set types can be extended for PPRs:

2.3.5

The standard set type for Consumer Products

The standard set type for Activity Management
The standard set type for Design Registration
The standard set type for Channel Management

Adding New Fields in the PPR Standard Set Types

With the Easy Enhancement Workbench, you can add new fields to the following PPR
objects:

Organizational Data
Business Partner References
Product References
Validity Periods

SAP CRM supports you in the following functions:

Integration of new fields in the user interface (SAP GUI and People-Centric UI)
Transfer of new fields to the Mobile Bridge (interface for the CRM Field
Applications)

PAGE: 6 OF 14
10:10 AM

DATE: 5/8/2015

For these functions, the system automatically generates all objects and table entries
required.
2.3.6

Easy Enhancement Workbench for Installed Base Management

With the Easy Enhancement Workbench, you can add new fields to the data model of
installed base management. SAP CRM supports the integration of these fields in the user
interface of the People-Centric UI.

3. Additional Functionality in SAP

To support business requirements in User interfaces, System interfaces, Enhanced system
functionality and reports, it is often require to develop the code in SAP business systems.
The categories of this code are explained in this section.
3.1

Users Exists / BADIs

User Exits allow us to add our own functionality to SAP standard program
without modifying it. These are implemented in the form of subroutines and hence are
also known as FORM EXITs. The userexits are generally collected in includes and
attached to the SAP program by the SAP.
The finding the correct userexit and how to find it if one exists for the purpose. Once the
correct userexit is found the necessary customer code is inserted in the customer include
starting with the z. n the form routine.
Types:

There are mainly six types of EXITs in sap which have been collected in the form of
enhancement packages and attached to standard code in SAP. These are different from
USEREXIT in the way that they are implemented in the form of Functions while in
USEREXITS we use form routines for their implementation. These are also sometimes
known as function exits.
These start from the word EXIT_ followed by the program name and then followed by a
three digit number. (e.g. EXIT_SAPMV45A_002)
1) MENU EXITS
2) FUNCTION EXITS
3) TABLE EXITS
4) SCREEN EXITS
5) KEYWORD EXITS
6) FIELD EXITS
PAGE: 7 OF 14
10:10 AM

DATE: 5/8/2015

BADI: Business Add-Ins are a new SAP enhancement technique based on ABAP Objects.
They can be inserted into the SAP System to accommodate user requirements too specific
to be included in the standard delivery. Since specific industries often require special
functions, SAP allows you to predefine these points in your software.
As with Customer Exists two different views are available:

In the definition view, an application programmer predefines exit points in a

source that allow specific industry sectors, partners, and customers to attach
additional software to standard SAP source code without having to modify the
original object.
In the implementation view, the users of Business Add-Ins can customize the
logic they need or use a standard logic if one is available.

In contrast to customer exits, Business Add-Ins no longer assume a two-level

infrastructure (SAP and customer solutions), but instead allow for a multi-level system
landscape (SAP, partner, and customer solutions, as well as country versions, industry
solutions, and the like). Definitions and implementations of Business Add-Ins can be
created at each level within such a system infrastructure.
BADI is just an object-oriented version of user-exit. Instead of entering program code
into some function module (as in customer-exit), you define some class which has to
implement predefined methods and those methods are fired at predefined points just like
an old user-exit. Some BADI can have multiple independent implementations which is
much better for software deployment as several developers can implement the same
BADI independently.
3.2

Function Modules (BAPI)

Function modules are used to support user interfaces, forms, reports, workflow and
interfaces. When RFC enabled attribute is set to enabled, such BAPI is called as
RFC; these objects can be called from external systems (XI, Visual Composer, etc.)
BAPI (Business Application Programming Interface) is a set of interfaces to objectoriented programming methods that enable a programmer to integrate third-party
software into the SAP system. For specific business tasks such as uploading transactional
data, BAPIs are implemented and stored in the SAP system as remote function call (RFC)
modules.
BAPIs are defined in the Business Object Repository (BOR) as methods of SAP business
object types or SAP interface types and are implemented as function modules.

PAGE: 8 OF 14
10:10 AM

DATE: 5/8/2015

4. SAP CRM or R/3 vs External Development

Any custom development with in SAP CRM and R/3 requires the use of ABAP. Examples of this custom development include
developing a User Exit or developing a new Function Module (or BAPI).
CLIENT uses Java development on Websphere for all non-SAP customizations. Java based web application development is used to
develop one or more business functions that do not fit in SAP CRM or R/3 environments.
Additional Information Pro-External
There are no existing SAP
transactions that fit the
business scenario

Pro - External

Decision Points

Business Scenario does

not fit within SAP's
applications suite

Pro - SAP
Business Scenario fits well
within SAP's applications
suite

Functional Fit

The external solution is

mostly isolated from SAP
from a data and process
perspective and has very
few touch points
SAP data is not the primary
driver for this process and
special versions of SAP
Data is not required

Low Integration with SAP

and Few SAP touch points

Data Replication is minimal

and data is not relavent to
the SAP Landscape
Majority of the data is nonSAP centric.

PAGE: 9 OF 14

Tightly Integrated with SAP

Integration with
SAP

Data Replication
Data Customization

Additional Information ProSAP

Transaction documents are
used for what they were
intended
Document Flow is unaltered
Fits with SAP's Development
Strategy
Fields are used as the were
intended to be
Standard SAP Exists can be
used for integration.
Existing data and tables can be
leveraged

Data Replication is minimal

and is relavent to the SAP
Landscape

Minimal amounts of data is

replicated from external sources

Can leverage existing SAP

constructs

Solution can leverage core data

constructs

DATE: 5/8/2015 10:10 AM

The opportunity for a

custom solution leverages
the flexablity of the external
tool set

Custom Interface is meets

or beats to SAP standard
interface

External development
techniques are leveraged
to improve performance

Significant performance
gains can be achieved
through external
development
Can leverage single signon
and does not produce SOX
related transactions or
reports

Insure that proper security

measures are capable and
we are NOT generating
SOX related transaction
data
Solution is understandable
from a technical
perspective easily learned
by CLIENT Staff
Solution can leverage
existing development
infrastructure
Solution has little affect on
SAP's upgrade and support
strategy
Overall the development
and maintenance cost are
more cost effective than an
SAP development

No special staffing or
resources are required

Leverages existing SAP

user interface components

Existing user interface

constructs can be used as a
starting point.
A user efficient interface can be
developed

SAP's existing infrastructure

provides acceptable
performance

SAP's performance is not an

issue that needs to be
overcome

User Experience

Performance

Security & SOX

Compliance

Staffing /
Knowledge

Cost effective over SAP

Leverages existing security

authorizations - SAP is the
system of record
No special staffing or
resources are required

Solution is understandable from

a technical perspective easily
learned by CLIENT Staff

Cost effective over External

Initial Cost

Cost effective over SAP

Cost effective over External

On-Going
Maintenance cost

Cost effective over SAP

Cost effective over External

Total Cost

Reasonable or No
additional charges incurred
No support issues incurred

PAGE: 10 OF 14

Licensing Use
Licensing - Support

Reasonable or No
additional charges incurred
Does not affect SAP's
Support License

DATE: 5/8/2015 10:10 AM

Solution leverages standard

user exits and data extensions.
Reducing maintenance and
testing cost of upgrades an
support packs
Overall the development and
maintenance cost are more cost
effective than an external
development

The following decision tree should be used in consideration with the above decision
points table.

PAGE: 11 OF 14
10:10 AM

DATE: 5/8/2015

PAGE: 12 OF 14
10:10 AM

DATE: 5/8/2015

The following are factors to consider in choosing the SAP CRM or R/3 platform vs. an
external development platform. The decision table and tree should also be referenced.

SAP vs. External Platform Consideration Matrix

CLIENT Project Considerations

Development Environment
SAP CRM or R/3 * External Development

Fits Existing SAP Application

Data is SAP Relevant
Performance is Acceptable in SAP, not Java
Produces SOX Related Transaction
Total Cost is Reasonable in SAP, not Java
Enhancements to Core Modules
Must Modify SAP Code (not an enhancement)
Fits Existing Java Application
Data is Java Relevant
Performance is Acceptable in Java, not SAP
Produce no SOX Related Transactions
Total Cost is Reasonable in Java, not SAP
* Assumes SAP enhancement is possible

Preferred

PAGE: 13 OF 14
10:10 AM

DATE: 5/8/2015

5. SAP Enhancement Tools

The following table lists the decision points in choosing which Enhancement Tool should
be used within SAP.

Enhancement Tool Recommendation Matrix

EEW

Source
Code
Plug-In

Parameter
Interface

BADI

User
Exit

Business
Object
Builder

CRM Business Partner Fields

CRM Business Partner Tables
CRM ABAP Source Code
CRM Function Module
R/3 and CRM Enhancement Option
R/3 ABAP Source Code
R/3 Function Module
BAPI
R/3 and CRM Business Object and
Components
Preferred

PAGE: 14 OF 14
10:10 AM

DATE: 5/8/2015