A treatise on SAP CRM information reporting

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com
© 2010 SAP AG 1
A Treatise on CRM (ADB) Data
Extraction for Business Information
Reporting
Applies to:
Customer Relationship Management (CRM 7.0) with my SAP Business Suite and Business Warehousing
(BW) with SAP NetWeaver 7.x.For more information, visit the EDW homepage.
Summary
The article focuses on the concept and implementation of SAP Customer Relationship Management (CRM
7.0) application database (ADB) data extraction for business information reporting. CRM BW analytics
offered by SAP is a vast topic due to the extensive and tight integration offered by SAP between the two
applications, and thus the content presented in this paper would largely confine to the data extraction from
the application database of SAP CRM 7.0 system using its BW adapter framework. The paper explores in
detail the concept behind the SAP CRM BW Adapter used for exchange of information between SAP CRM
and NetWeaver BW, and the steps involved in configuring and implementing the same. Analytics for CRM
mobile clients, consolidated databases (CDB) remain outside the scope of this paper.
Author: Vijay Raj
Company: Hewlett-Packard
Created on: 31 August 2010
Document Version: 2.0
Author Bio
Vijay Raj is a Production/Industrial engineer and works as a subject matter expert and lead
consultant for Business Intelligence with SAP NetWeaver BW 7.x and Business Objects, and
executes multiple business intelligence/enterprise data warehousing implementations for
enterprises across the globe. He focuses on business process centered early business
intelligence implementations with SAP in SOA environments.

A Treatise on CRM (ADB) Data Extraction for Business Information Reporting
© 2010 SAP AG 2
Table of Contents
Introduction .........................................................................................................................................................3
The CRM Application..........................................................................................................................................3
The paradigm of packaged application development.........................................................................................4
Adoption of SAP standard solution – An early BI scenario.............................................................................5
Use of surrogates within SAP to meet requirements ......................................................................................8
Custom development ....................................................................................................................................10
Concept of SAP CRM data extraction ..............................................................................................................10
Understanding the SAP CRM One Order Framework – A brief ...................................................................10
Business Documents or BDocs ....................................................................................................................11
SAP CRM BW Adapter .................................................................................................................................13
Delta initialization of BWA Data sources.......................................................................................................15
Delta extraction of BWA Data Sources .........................................................................................................16
Implementation of data extraction based on BW Adapter data sources.......................................................19
Installing business content BW Adapter based data sources.....................................................................................19
Customization for BWA data sources ........................................................................................................................22
Enhancing a BW adapter based data source.............................................................................................................25
Scenario A .................................................................................................................................................................25
Scenario B .................................................................................................................................................................32
Scenario C .................................................................................................................................................................33
Enhancement with CRM Application Enhancement Tool .............................................................................33
Enhancement with CRM Easy Enhancement Workbench............................................................................44
Extraction of user status of one order objects ..............................................................................................51
Operational aspects of BW Adapter data sources........................................................................................56
Delta Initialization.......................................................................................................................................................56
Incremental delta upload............................................................................................................................................57
Delta upload...............................................................................................................................................................59
Conclusion ........................................................................................................................................................63
References / Related Content ..........................................................................................................................64
Copyright...........................................................................................................................................................65

© 2010 SAP AG 3
Introduction
SAP Customer Relationship Management (CRM 7.0) application which comes as a part of my SAP Business
Suite is arguably evolving as the best customer relationship management solution currently available in the
market. There was a time when the CRM solution offered by SAP was looked up on as a less competent
product against the other competitor CRM products available in the market. But over a period of time during
the life cycle of this product SAP has been largely successful in positioning its CRM solution as arguably the
best, and changing the perception of the industry. Behind this success, much is attributed to the extensive
integration that SAP has offered for its CRM solution, with its counterpart analytic application, Business
Intelligence, and the backed ERP, which forms a part of SAP ECC 6.0 on the SAP NetWeaver platform.
There perhaps is no product which can match the capability offered by the CRM BW combination that SAP
has offered for its customers. Thus the integration between SAP CRM and SAP BW forms the basis for the
analytical applications delivered with my SAP CRM Analytics. And, for this very reason, my SAP CRM
Analytics happen to remain a vast topic that a complete treatise on the same would apparently end up in
writing a voluminous book, something which I would tactfully refrain to as a pretext. Thus the content of this
paper is confined to basics of the CRM BW adapter framework, for application data, which forms the basis
for data transfer from CRM to BW. The concept behind the CRM BW adapter framework is discussed in
detail with emphasis on the data extraction from the CRM Application Database (ADB). It shall also cover the
necessary configurations to be carried out in the SAP CRM system for data extraction to the BW system.
The paper would exclude the data extraction for SAP mobile CRM which is configured for mobile clients
exchanging data with the CRM server, though the same also fundamentally works based on the CRM
middleware and the BW adapter.
The CRM Application
A customer relationship management solution is primarily responsible for the interface of an enterprise with
its customers, clients, partners and sales prospects. Unlike an ERP, the functionality expected out a CRM
application is different, essentially due to the dynamic market and ever changing needs of the customer. A
good CRM solution offers tight integration to automate and synchronize business process with customer
centric activities of marketing to after sales service/support. It involves all stages starting from the
identification of prospects from the market, followed by sales conversion, execution (which generally
happens in the core ERP application, demanding the need for tight integration of a CRM application with
core ERP application) and after sales support. Thus a CRM application should be a flexible platform that
supports end to end processes across and beyond the enterprise.
A good CRM implementation should also be capable of addressing key questions relating to the customers,
market dynamics, sales and service operations. The analysis of information captured by the CRM application
is thus the basis for marketing campaigns, opportunity and sales planning and service execution, which is
often described as the closed loop scenario by SAP. A closed loop scenario is the complete cycle from
capturing the data, analysis of data, and applying the results in the operational areas. The results are then
returned from the operational level to be fed back into the analysis. This constitutes a closed loop

© 2010 SAP AG 4
incorporating analysis, operation, and feedback. A successful and comprehensive CRM solution calls for
close integration with a customer information platform, where all relevant customer information is gathered
consistently, and analytical insights have to be provided in the operational processes to enable informed
decision making.
The dynamic nature of the market and ever changing customer needs require the technology and application
to be based on a framework that would cater the same.
For all these reasons, my SAP CRM is tightly integrated with NetWeaver BW, and helps with the following;
 Measure and assess the success of business by collecting all relevant data and monitoring the
corresponding key performance indicators.
 Predictive capabilities to identify hidden patterns and trends that drive business, and apply these
learning to predict future trends and carry out efficient operations.
 Application of the analytical results to operational processes to enable decision making at process
level.
 Available standard business content extractors to facilitate automated collection of relevant data from
CRM.
Data Mining in BW for CRM Analytics
 Clustering; for customer segmentation.
 Association analysis: for cross selling behavior.
 Decision trees: for identifying specific profiles that impact a particular behavior observed
 Scoring: for combining different aspects in an overall evaluation.
 Linear and multi-linear regression: to extrapolate data for prediction and behavioral trends.
Thus my SAP CRM consists of an operational CRM system together with a data warehouse that serves as a
consistent organizational customer knowledge base.
The paradigm of packaged application development
One of the prime motives behind this paper happened when it was observed, as a part of audits for SAP
CRM-BW implementations, that consultants adopt the same method of data extraction for the SAP CRM
system as that of an SAP ECC system. It is true that the same method of data extraction definitely works,
and it is in this context that a reiteration of the often lesser spoken paradigm of packaged application
development is made. The paradigm of packaged application development, as I would call, can be put up as
a set of simple points, which determines the approach that needs to be adopted while executing an SAP
implementation.
A package application is a commercial application program or collection of programs developed to meet the
needs of a variety of users or customers, than custom designed for a specific user or company. SAP too has
its own products or packaged applications that meet the desired requirements of a variety of enterprises. An
organization procures the packaged application as a product and deploys the same depending up on its
needs and requirements to facilitate and carry out its operations.

© 2010 SAP AG 5
In packaged application deployments, as with SAP implementations, right solution adoption (often referred to
as right ‘solutioning’ in the industry, paradoxically with ‘solutioning’ itself being a wrong usage in English
language) is the key, and is the backbone of all successful implementations. A wrong solution adoption often
affects business operations, maintenance, and scalability, upgrades and change management process.
The product and its functionality knowledge is very important in driving the right solution adoption. A crystal
clear understanding of features offered by the packaged application, the scenarios under which the same
can be leveraged is the stepping stone for the right solution adoption. With SAP applications, the consultant’s
business process assimilation remains the basic prerequisite and his expertise, judged up on by the
understanding and working knowledge of the respective SAP product, is required to be successfully able to
map the former to the latter.
The below three points, in sequence often drives the right solution adoption
1. Adoption of standard SAP solution, business content as for BI.
2. Use of surrogates within SAP to meet requirements
3. Custom development within the framework of the SAP solution.
Adoption of SAP standard solution – An early BI scenario
Adoption of the standard solution is the first and the best principle when it comes to successful solution
deployments. The packaged application, as with SAP, provides the standard functionality, along with
scenarios, where the same needs to be deployed. Use of standard solution decreases implementation
efforts, increases quality of deployment, easier scalability and maintainability, and remains compatible with
upgrades.
From a standard solution perspective, SAP recommends use of CRM BW adapter framework for BW adapter
based CRM data sources, than using classical methods of data extraction similar to SAP ECC. Specific
focus on early BI scenario is taken as most of the SAP CRM deployments have BW, often in parallel, in the
implementation roadmaps.
As in case of SAP Business Intelligence, a consultant is expected to have a crystal clear understanding of
each of the standard business content data models delivered by SAP, how underlying information from SAP
ECC, CRM, SRM, SBO etc is modeled by standard SAP which itself is a huge task, apart from fundamental
knowledge of business process and technology understanding (SAP BI as a data warehousing application).
This is very important from the perspective of success of an early BI implementation, where the OLTP and
the OLAP implementations are carried out hand in hand. In such implementations due focus is laid on the
information requirements of the organization, together with the automation of business process and
leveraging the advantages of an ERP application for the same. BI consultants play a very important role in
these implementations by active participation, right from the business process analysis and blueprint phase
and helps determining the necessary configuration and fields for capturing information after analyzing the
information requirements of the organization. After studying the information requirements of the organization,
in these implementations, the consultant analyzes the same with the data models offered by SAP as part of
the business content, and provides analysis oriented inputs for the SAP OLTP consultants. CRM BW being a

© 2010 SAP AG 6
robust competent solution offered by SAP, BW implementations often happen hand in hand along with the
CRM implementations. Below is explained a sample scenario, where the same happens during an early BI
implementation.
For e.g. an organization having CRM and BW in parallel in its implementation roadmap, as a part of its
service process has an information requirement for analyzing costs of service. A service for the customer, as
a part of service process can happen as a paid service, warranty service, goodwill service, FOC, etc, and the
costs incurred differs based on the type of service transaction (i.e. whether it is a paid service, warranty
service, goodwill, free of charge etc.). The same service, say a replacement of a part, incurs different costs
on the organization depending on the type of the transaction, i.e. paid service, under warranty, goodwill, FOC
delivery etc. For reporting to happen for this kind of requirement, in early BI implementations, the BI
consultant has to ensure whether he/she is having the underlying data for meeting the organizations
information requirement. The BI consultant, with his/her solution knowledge understands that, SAP, in its
standard business content has got the provisions for meeting this kind of requirements. The standard SAP
business content data model for CRM Cost and Revenue Analysis as a part of Service Analytics provides the
info-object called accounting indicator (0CRM_AC_IND) which is specifically delivered by SAP to meet this
kind of requirements. The accounting indicator when set in the CRM system can serve as a distinguishing
parameter in addition to differentiation by cost elements. Thus incurred costs and earned profits are identified
by sales volume, warranty or good will. The accounting indicator serves as the criterion to differentiate
between billable, non-billable, and partially billable products for pricing and controlling purposes. Non-billable
and partially billable services and parts are those provided under warranty or in goodwill. The accounting
indicator is used for differentiation of products for pricing in service, based on absolute or percentage
discounts and surcharges. Accounting indicator in the pricing conditions controls pricing for products
covered. It also helps in differentiation of actual costs in controlling, where CRM is integrated with ECC
controlling, where the accounting indicator is used to differentiate actual costs and expenses while posting to
an internal order. Every service order in SAP CRM, when configured appropriately (single object controlling
based on transaction types), creates an internal order in ECC for settlement. The accounting indicator thus
influences the determination of value fields for the profitability segment in the profitability analysis. The
related internal order settles its costs to different receivers, where associated costs are settled to a specified
cost center.
To address the information requirement of the service department of the organization, the BI consultant has
to ensure that the required data is captured in the SAP CRM system. If the data is not captured at this level,
the BI application will never be able to meet the information requirement, though from a process level CRM
will still be able to carry out the operations. The data model provided by SAP standard for CRM Cost and
Revenue Analysis, as a part of the standard business content will be unable to fetch any data if the source
system, i.e. SAP CRM in this case, as it is not configured for the same. This disconnect normally happens
when, the requirements provided by the organization happens at two levels, where people heading and
managing operations in the organization drive the CRM implementation. They will not be able to envisage
the information requirements from a holistic perspective, which requires highest level insights. A BI

© 2010 SAP AG 7
consultant, involved with the early BI implementation, resolves this disconnect by incorporating the holistic
view at the process level. Early BI implementations, though challenging, ensures that all information
requirements are met, in comparison with normal BI implementations, where BI starts after OLTP
implementation or with live OLTP systems, where sometimes certain information requirements are not met
with data not being captured at process level at all.
To use the accounting indicator for meeting information requirements, the activation of the accounting
indicator is required, and entries have to be maintained in SAP CRM in customizing. The information
requirement as a part of the process also determines whether the same needs to be captured at the header
level or item level. When captured at the header level, it gets copied to all items. And the accounting
indicator can be set at the item level, in scenarios where items can have different pricing, for example, when
a replacement part is procured and the service is free, which happens to be two different items of the same
service order. Note that the accounting indicator is only used for the posting of costs to the receiving cost
collector and revenues are always posted without the usage of an accounting indicator.
Thus, the above looks example explores how the standard BI solution offered by SAP gets implemented in
an early BI implementation for CRM service, and the approach of adopting the standard remains as the first
principle behind all successful package application deployments.
Figure 1: Approach for early stage BI implementation with SAP

© 2010 SAP AG 8
Use of surrogates within SAP to meet requirements
There are scenarios in real life implementations, where features provided by SAP do not directly meet the
requirements at business. SAP, by standard, does not meet, include or cover the scenarios available at
hand. It is under these circumstances that the consultant needs to look for alternative solutions within the
framework provided by the packaged application, i.e. the SAP product. Such scenarios would require the
consultant to go beyond the standard solutions offered by the packaged application, yet remain confined to
the framework provided. Identification and deployment of surrogates is required to meet the out of box
requirements arising during the course of the real life implementation. A surrogate, as I would call, is a
functionality that can be leveraged from the standard features provided in the packaged application, to meet
different kind of scenarios in implementations, outside the set of standard scenarios provided. In depth
knowledge of business process and in depth product or packaged application knowledge, i.e. SAP standard,
is required to provide surrogate solution for requirements outside standard scenarios of the packaged
application. The surrogate solution requires deep expertise both at business process level and at SAP
product level. Below is explained, an example of the adoption of a surrogate solution when desired
functionality is not available as a part of the standard solution, but is leveraged from the standard SAP
solution as a surrogate.
The scenario comprises of external authorized service centers carrying out service on behalf of the OEM,
say an automobile manufacturer. Whenever there is a part failure in automobile sold by the OEM, the
external authorized service centers carry out the required service for the end customer, which even may
require the replacement of the part. In part replacement, in case of paid service, it is a sale for the service
center to the end customer fulfilled from the stock owned by the service center. But in case of a warranty
service, i.e. failure of parts covered by the warranty tenure, the service center still would carry out the service
for the end customer by replacing the part from the available stock. After the service, in cases of warranty,
the service center raises a claim on the OEM for services borne by it, where a part to part replacement is
executed by the OEM. The scenario gets even complex as both financial settlements, in case of service by
the service center, and part replacement are possible under warranty. The OEM, as a part of its business
transformation program, wanted to implement SAP CRM, which would require a customer call logging
feature followed by processing of service center claims as part of the service process, in addition to the other
marketing and sales functionalities offered by SAP CRM. The claim would be created online and has an
approval process. It should capture the failure details of the equipment, the meter reading at the point of
failure, and should also be tightly integrated with SAP ECC (core ERP application) for logistic execution of
the part to part replacement and reimbursements. SAP CRM as a part of the standard does not directly have
this feature commonly required by automobile and large equipment manufacturing industries for processing
service claims. Often, the existent warranty claim available in CRM is mistaken to serve this process, as from
name, the required process and object is similar. The warranty claim available in CRM is more from a
vendor/supplier warranty process, where the failed part is covered under warranty by the vendor from whom
the OEM has procured the same, and the standard scenario needs to be differentiated from the requirement
at hand which is completely different.

© 2010 SAP AG 9
A deep analysis of the requirement from a process level will indicate that the same can be met by the CRM
complaints object, provided with CRM service. The CRM complaint object, when made accessible through
the CRM WUI has provisions for capturing the failure on equipment or its individual parts, with the use of
subject profile multi level categorization, meter reading of the equipment, with the use of forward install base
measurement counter reading attached to the complaint and the other required details. The complaint object
being closely and tightly integrated with ECC sales order can also take care of the logistic execution in SAP
ECC 6.0 for dealer claims as well as part to part replacement, and financial settlement to the service center
from the OEM.
This is an example of using surrogate functionality in the standard way to meet out of box requirements
arising in real life implementations.
Following is described a second example, which throws more light to the concept of surrogates where
consultant leverages standard functionality for requirements not provided as a part of standard SAP solution.
The scenario was a part of an SAP implementation for metro rail business. As a part of analysis
requirements for maintenance and operations for metro rail business, the management was interested in
monitoring and analyzing key performance indicators which included mean time between failures, mean time
to repair, availability, breakdown durations and revenue hour breakdowns for metro trains. As a part of the
solution scope, the organization, with its existent ERP modules based on SAP ECC 6.0, had decided to use
SAP ECC 6.0 PM module for carrying out maintenance and service operations of trains, and get the same
integrated to it. The scenario required SAP ECC 6.0 module of plant maintenance to be used for
maintenance operations, and the attempt was to leverage the standard content delivered by SAP BW for
ECC plant maintenance to meet the analysis requirements. As a part of the process, the ECC PM notification
captures the information of breakdowns, which has a subsequent maintenance order which carries out the
actual maintenance aspect. The standard business content data model for ECC PM in BW cover notifications
(header, items, causes, tasks and activities) along with DSO for breakdowns, mean time to repair and mean
time between repair, and maintenance orders, cost and operations. The challenge imposed was to configure
train in the SAP ECC 6.0 system, as a metro train at any point of time is comprised of a set of wagons. Any
failure occurring in the metro train is always at the level of the wagon for which a notification gets created.
Train, in rail road / metro rail industry is commonly referred to as rolling stock. The challenge as a part of the
implementation was to identify the right technical object offered by SAP PM for the rolling stock which would
serve as a surrogate, and thus enable capturing the process level information and will meet analytic needs of
the organization. The technical objects offered by SAP PM are so powerful, that when configured the right
way they enable capture the process level information and suit the analytic requirements in the simplest and
standard way. As part of the example provided, the wagon, of the rolling stock, was configured as the
equipment as a fleet object, identified by numbers, with specific dimensions and loading capacities, and
other details. The rolling stock, i.e. the train, on the other hand, was configured as the standard PM
functional location. The wagons, i.e. the equipments, are assigned to functional location, which forms the
surrogate for rolling stock/train, using standard object networking and the break down information, with

© 2010 SAP AG 10
measurement readings get captured at the wagon level, for which a maintenance activity is carried out. All
the analysis requirements are met out of the standard data model driven out of BW with minimal
enhancements.
Thus in identifying surrogates, a great deal of expertise is required, both at the packaged application level
and at the process level, so that seemingly out of box requirements are met within the framework offered by
SAP. This even today remains the niche aspect and the cornerstone for successful SAP implementations.
Custom development
In ERP and enterprise data warehouse/ business intelligence implementations, it is not uncommon to have
requirements at hand, that can absolutely be not met by the packaged application, both not fulfilled by
standard functionality and by surrogates. It is this context, that the consultant for the packaged application,
say SAP, resort to the last option of custom development. In packaged application implementations, at least
in BW, this often remains confined to a specific module or a set of modules, and customers go for the
packaged application, with SAP at its best, for the strong foundations they offer for the technology and
application platform. Custom developments take more effort, offer lesser scalability and maintainability.
Concept of SAP CRM data extraction
One of the prime reasons for the above literature, though from a highest level, was to give a deeper insight to
the methodology for right solution adoption. Sometimes BW consultants adopt the commonly practiced SAP
ECC 6.0 concept of data extraction from the CRM system to BW. Though the same always works, and that
both the applications are based on the same framework, it is not an indication of the right solution adoption,
as SAP, by standard, has offered the CRM BW adapter for this very specific purpose.
Understanding the SAP CRM One Order Framework – A brief
It is very important to understand the CRM One Order framework for business transactions, before
implementing the extraction of CRM data to SAP BW. Unlike ECC 6.0, SAP CRM has a more encapsulated
object based approach which takes a little more time for consultants new to CRM to understand the way
CRM functions. Lack of readily available documentation too adds to this challenge, but once the basic
concepts underlying the SAP CRM solution is clear, it is far simpler to understand and work with in
comparison to SAP ECC 6.0. This ease can also be attributed to the very structured and equally flexible
framework of CRM One Order. Every SAP CRM one order object has a business object type assigned to it,
for e.g. the service order object, and comprises of the a set of order segments, that holds specific data like,
the transaction header, transaction item, partner data, dates, organization data, subject profile data etc. All
transactions whether the service order, sales order, complaint, opportunity etc. are technically handled in a
similar way by SAP CRM with its one order framework. All these different order objects are distinguished by
the CRM business object type (for e.g. business object type ‘BUS2000116’ determines the service object).
The business object type basically controls the functions (fields and methods) available for an object from the

© 2010 SAP AG 11
business object repository. A business object type can have many transaction types (similar to a document
type) which define properties and characteristics such as partner determination procedure, text determination
procedure, organizational data profile, and user status profile. For example a service call ticket and a service
order share the same underlying BOR object type and hence have the same available fields (e.g., priority,
status, etc.) and methods (e.g. create, display, execute) – but are different transaction types. Thus they have
different properties and characteristics. On the other hand, a Service Info Request is a completely different
business object type, meaning it really has different functionality and fields.
The transaction CRMD_ORDER is used to display all transaction in the SAP CRM backend within the CRM
one order framework. Likewise the tables CRMD_ORDERADM_H, CRMD_ORDERADM_I etc., function
modules CRM_ORDER_READ, CRM_ORDER_SAVE etc. apply across all one order transactions, may it be
a service order, opportunity, service info request, complaint etc.
Business Documents or BDocs
The CRM BW adapter forms the framework which is primarily responsible for extraction of data into the SAP
Business Information Warehouse from the SAP CRM application database. The SAP CRM transactions use
business documents or BDoc for writing the transactions to the CRM application database and also for all
other communications. Every business object, which transacts with the application database to request or to
write data, uses a BDoc and each of the CRM business transactions have their own dedicated BDoc. It is like
a semantic layer that resides above the CRM application database. A business document or the BDoc is
defined as a set of transaction statements, which represent a logical object. It encapsulates all business data
that necessary to run a business process, for e.g. a sales order. A BDoc has different sets of data partitioned
in terms of segment. Segments are mapped to a table where the mapping defines the relation between
abstraction and physical database. Segments correspond to logical tables. A segment is a part of every
business document and has at least one segment table per segment. The fields of a segment are equivalent
to the columns/ fields of a table, but the segments and fields need not have direct physical representations.
Physical tables and columns are mapped into segments and fields and are defined in the repository. In CRM,
all interactions with the application tables, may it be writing to it, or sending data to an external system, all
happens through the semantic framework of b-docs.
Depending on their purpose there are different types of BDocs available in the SAP CRM system. These are
broadly classified into three as follows;
a) Messaging BDocs (mBDocs) – The message exchange with CRM server applications, ECC 6.0 and
external system takes place within the CRM middleware using messaging BDocs. Messaging BDocs
will not be exchanged with mobile clients and hence will not be stored in the CDB for mobile clients.
There exists no real difference between a BDoc and BDoc messages, as the latter signifies its use
for data transfer between different systems, may it be SAP ECC 6.0 or BW. It gives a standard
structure to facilitate data exchange. They are also sometimes referred to as online documents. No

© 2010 SAP AG 12
mapping between segments and database tables in the middleware side exists and they only
transport gross data.
b) Synchronization BDocs (sBDocs) – These are used only for data synchronization with mobile clients,
and there exists a mapping between the BDoc segments and the consolidated databases (CDB).
They can also be assigned to messaging BDocs. They were also called write BDocs.
c) Mobile application BDocs – These are used for mobile sales/service applications to query databases.
They were also sometimes referred read BDocs.
A BDoc type consists of a header and a body. The BDoc header consists of one single data segment, the so-
called control segment and the BDoc body consists of one or more data segments and one error segment.
The control segment merely contains header information, and the individual data segments contain the
actual table entries that form the corresponding business object. The error segment is used to store error
information. Every data segment contains segment fields, which is also referred to as segment attributes.
These fields are mapped to actual data fields of physical database tables. In BDoc types used for data
exchange between mobile clients and the CRM Server, a data segment is mapped to exactly one database
table, whereas in BDocs used, for example, on the client side only, a data segment can also be mapped to a
join of tables or to a table view. The below figure shows the structure of a business document;
SAP CRM makes use of messaging BDocs for data extraction to BW via the SAP CRM BW Adapter.

© 2010 SAP AG 13
SAP CRM BW Adapter
The middleware layer in SAP CRM mainly supports the controlled data exchange with other systems, i.e.
mobile clients, backend systems like SAP ECC 6.0 and data warehouses like SAP NetWeaver BW. The
connections to external systems are established via software adapters and they map and convert data to
various formats. The CRM application components also exchange data with the middleware layer via a CRM
adapter. An adapter, in general, is a framework that translates one interface into another compatible
interface.
The BW adapter in SAP CRM forms the an essential layer of CRM BW integration hence serves as the basis
for transferring data for all analytical applications delivered with my SAP CRM Analytics.
The BW Adapter translates the BDoc data into a structure compatible with SAP BW, that is, to the extract
structure of a BW data source, so that the data is extracted to SAP BW through the Service API. It is called
up as part of the flows for the following BDoc types:
a) sBDoc types for synchronizing the consolidated database (CDB) and the mobile clients
b) mBDoc types for the message flow within the CRM server
The sBDoc based data extraction, for mobile clients, would remain outside the scope of this paper, and here
focus is laid out only on data extraction from the CRM application database, which uses, mBDocs. With the
appropriate BDoc type, the BW Adapter extracts the following objects into the SAP BW:
a) CRM business transactions (mBDoc)
b) Documents for CRM billing (mBDoc)
c) Objects relevant for mobile clients (sBDoc)
Extracting data using the BW Adapter requires additional information, called BW Adapter metadata. This
metadata comprises of the assignment of the required data source to the concerned BDoc. Thus, for using a
data source for data extraction requires the activation of BW adapter metadata as a fundamental pre-
requisite. The BW adapter metadata maps the fields of the mBDoc to the fields of the extract structure.
The BW Adapter thus in the process of data transfer to BW performs the following
a) Relevance Check: that is whether the BDoc is relevant for BW delta upload. This is achieved by the
flow control mechanism present in the CRM middleware which calls a number of services for every
BDoc message. This is not relevant for an initial data upload, and has been discussed in detail in the
following sections.
b) Completion Service: adds information from the database to those BDocs that contain the changed
data.
c) Mapping of the BDoc structure to the extract structure of a Data source.

© 2010 SAP AG 14
The CRM BW data extraction happens with the help of a special type BDoc called the messaging business
document or the m-BDocs. Below is given a figure, which gives the framework of CRM BW data extraction
and the complete concept of data extraction in detail in the following sections.
Transactions in SAP CRM are based on the one order framework, and each of them are based on the
business object types, may it be the service order, complaint etc. These one order objects have specific
business documents or BDocs associated with them and so do they have the respective order segments and
segment attributes. The data source for extraction also works based on these same objects, the order
segments and the business documents underlying the BW Adapter. SAP, as a part of its configuration has
provided the mechanism for making available these order segments and BDocs for BW data extractions. The
consultant has to ensure that only the required order segments are made available for data extraction to SAP
BW taking into consideration the performance aspects too. The required order segments are released for
data extraction and the individual fields of the BDoc is mapped to the fields of the extract structure.

© 2010 SAP AG 15
Delta initialization of BWA Data sources
The BW adapter, as discussed above, works as an interface which transfers the data from SAP CRM
systems to the BW system. Thus whenever a transaction is entered /created in the SAP CRM application,
the same after writing to the application database is pushed out to the external system using a compatible
structure called the messaging BDoc or mBDoc. These BDocs serves as an outbound structure from the
SAP CRM system to the external system and the triggering of the same is governed by the CRM middleware
flow controller and are determined once an entry is made to the application tables.
Delta initialization, being a process where an initial upload of data is carried out to a BW system, occurs
without integration to CRM Middleware. The middleware in our scenario is largely responsible for triggering
the outbound from SAP CRM system once the data has been written to the application database. The CRM
middleware determines the delta for subsequent extractions and, in the case of a delta upload, transfers data
to SAP BW using the Service API. Though the CRM middleware is not used for initialization, the system
would still use the respective mBDocs which reads data from the CRM application database and transfers
the same to the extract structure of the data source.
Activation of BW adapter metadata, which maps the BDoc fields to the extract structure fields, is a
prerequisite for using the BW adapter based data sources delivered by SAP for CRM data extraction. It has
to be noted that the data source and BW adapter metadata are separate entities, though in the latest
releases of SAP CRM, the latter gets automatically activated with the activation of the former.
As in the case for other SAP BW extractors, a delta initialization of a BW adapter based data source is also
carried out by means of an INIT Info Package. Once a delta initialization Info Package is executed, the SAP
BW system calls up the BW Adapter using the standard Service API. For data extraction from application
databases, the CRM BW Adapter with the help of mBDocs transfers the data stored in the CRM application
database to the BW system using the respective extract structure. A mapping module, SAP delivered with

© 2010 SAP AG 16
customer specific BAdI implementations, maps and helps the data extraction from the CRM system using the
mBDocs to the data source extract structure.
Delta extraction of BWA Data Sources
Upon the event of creating, changing or deleting of a transaction in the CRM application, the same
information is communicated via CRM middleware in the form of a BDoc. The flow controller component of
the CRM middleware calls up the BW Adapter. The flow control, which is an integral part of the CRM
middleware, is a virtual machine to process BDoc messages. The CRM middleware flow control calls a
number of services for every BDoc message and passes the BDoc message as a parameter to the services
that are called. Services are function modules that perform particular tasks on a BDoc message, including
determining the fact that whether the message is relevant for BW or not. Furthermore the flow control writes
into the flow control log file. The CRM middleware flow definition is displayed in the transaction SMO8FD in
SAP CRM and is primarily responsible for sending the data to the BW delta queue via the adapter.

© 2010 SAP AG 17
The BW Adapter in the event of a change to a transaction in the CRM Application, first checks whether the
change communicated via the BDoc, is relevant for SAP BW or not. A change is relevant if a data source for
the BDoc is active and in case if it is not relevant, the change is not transferred to SAP BW and the process
is completed. If the relevance check is successful, the BW Adapter calls up the mapping module responsible
for converting the BDoc data into the extract structure. The type of Business Add-In (BAdI) called up by the
BW Adapter also depends on the BDoc type:
a) mBDoc types: The focus of this paper, these BDoc types, are used for data extraction from the CRM
application database, and uses the BAdI CRM_BWA_MFLOW. This BAdI helps the change of
assignments delivered by SAP.
b) sBDoc types: This part definitely lies outside the scope of this paper and is applicable for data
extraction for consolidated databases for mobile clients. The BAdI CRM_BWA_SFLOW is used for
customer specific enhancements.
The mapping module called up during delta upload and the BAdI's that are called up are the same as those
called up during the initialization of the delta process. The change is transferred to SAP BW using the
Service API. For both initial upload and delta uploads, the same mapping module (SAP-delivered mapping
and customer-specific BADI implementation) is used. Table SMOXHEAD contains the name of the mapping
module. Mapping metadata is stored in table SMOXRELP. The CRM BW adapter based data sources works
based on the after image delta with deletion, AIMD, where the changed record, the after image, is pushed to
the BW delta queue by the BW adapter. The after image then gets extracted to BW by the delta Info
Package executed on the BW side.

© 2010 SAP AG 18
The BW delta works on processing queue BUS_TRANS_MSG. Upon the event of a change in the
transaction, the BDoc message gets created and the BDoc would have the queue
CSA_ORDER_<transaction number>. For transfer of the data to the BW delta queue, the CSA* queue
should be registered in the transaction SMQR in the SAP CRM system.
If the queue is not registered the BDoc message generated for the transaction will never be written to the BW
delta queue, and the status of the same will be yellow.

© 2010 SAP AG 19
Once the BDoc is successfully processed the data is written to the BW SAPI delta queue.
Implementation of data extraction based on BW Adapter data sources
Installing business content BW Adapter based data sources
Data sources based on CRM BW Adapter, are delivered by SAP as a part of the standard content. In order
to use the data sources for extraction, the same needs to be installed from the standard delivery version. The
data sources delivered as a part of the standard SAP content, as in case of other data sources is available in
the transaction RSA5, installation of data sources form business content.
As in the case of any other SAP delivered data source, the BW adapter based data sources are also
activated from transaction after transferring the application component hierarchy from transaction RSA9.
After installation of the selected data source, say, 0CRM_SRV_PROCESS_H (CRM Service Order Header
Data), is available in the transaction RSA6, the post process data source and hierarchy.

© 2010 SAP AG 20
In contrast with the other SAP data sources, the BW adapter data sources require the BW adapter metadata
to be active for their use. The BW Adapter metadata comprises of the assignment of the Data source to a
BDoc. In SAP CRM versions after CRM 5.0 the BW Adapter metadata gets activated automatically after the
data source is activated in RSA5 transaction. For versions prior to 5.0, this activity had to be carried out
manually in transaction BWA5. The transaction BWA5 in CRM is still used for metadata version management
of BW Adapter. Once the data source is activated in RSA5, the corresponding BW adapter metadata is also
activated, and the same is checked in transaction BWA5. Transaction BWA5 after 5.0 is still used for
metadata delta selection and version comparison but not for activation anymore.
As in the case of service API metadata activation in RSA5, choose ‘select delta’ to mark inactive data
sources or to highlight differences between active and delivered versions. The BW adapter metadata is
stored in the following tables,
a) Header information - table SMOXHEAD
b) Mapping information - table SMOXRELP
c) Global selection conditions - table SMOXGSEL
d) Attribute key fields - table SMOXAFLD
The transaction RSA2, as for any other SAP delivered data source, gives the service API metadata. The
CRM BW adapter based data sources also works on the after image delta with deletion, AIMD, and is also
determined by the BW adapter.

© 2010 SAP AG 21
Other than the Service API metadata (given in RSA2), the BW Adapter metadata can be viewed in the
metadata tab of the transaction BWA1. The BWA1 transaction is also used to maintain the BW Adapter data
sources. The metadata tab of BWA1 gives the associated BDoc related to the data source, the mapping
module which maps the associated BDoc to the data source extract structure and the selection module for
carrying out the initialization of the BW Adapter data source.

© 2010 SAP AG 22
Customization for BWA data sources
After installing the SAP delivered BW adapter data sources, it has to be ensured that all order segments
associated with the CRM one order transaction object required for reporting are available with the data
source. It has a performance consideration too, where the data extraction is carried out into SAP BW for
those segments for which data is captured and that are applicable for reporting. The transaction
BWA_SEGREL helps releasing the required order segments for data extraction into BW. The earlier versions
of CRM before 4.0, data from segments that are not present in the standard extractors are obtained by
enhancing field information separately using CRM_ORDER_READ or by any other function in enhancement
BAdI implementation, and this extracted information is added to the enhanced structure. But with the later
CRM versions, more segments are provided in addition to those existent. These standard segments are
directly available for extraction and have to be released for data extraction. The consultant is given the
choice of activating these new segments only if required, and keeping them inactive if not required. This
helps improved performance of data extractors.
The enhancement would allow the additional option of ‘release/un-release segments’ in BWA_SEGREL for
flexibility of extraction of specific segments. This allows easy enhancement of the data sources in the BAdI
implementation, and avoids the need for fetching additional data separately in the BAdI.

© 2010 SAP AG 23
The business document or the BDoc associated with the SAP BW data source is displayed in the transaction
SBDM in the CRM system. For e.g. the business document BUS_TRANSACTION_MESSAGE is associated
with the data source 0CRM_SRV_PROCESS_H. The BDoc BUS_TRANSACTION_MESSAGE is a
messaging BDoc used for data transfer of the service order object to external systems including BW. The
respective BDoc segments are viewed in the transaction SBDM as shown below.

© 2010 SAP AG 24
The transaction BWA1 helps maintenance of the BW Adapter based CRM data sources. Here a BW adapter
based data source with corresponding BW adapter metadata can be created, data sources delivered by SAP
can be changed, and also the data source with BW adapter metadata is enhanced. The BW adapter enables
enhancement of the standard functionality of the service API in SAP BW. As a part of the definition of a BWA
data source a BDoc is assigned to the data source in the BW adapter. In the case of a delta update, the BW
adapter is called up in the flow variant of the BDoc, and adds the data to the corresponding BW delta queue.
The BW adapter works in the messaging flow as well as in the synchronization flow. But a data source can
only be created and changed for data sources based on synchronization flow.
The SAP CRM system allows use of parallel processing to improve the performance of the BW Adapter data
sources. The transaction BWA8 in the CRM system is used to setup parallel processing for initial upload to
BW. This accelerates the data extraction of one order data sources using parallel processing. During the
data selection for the initial upload using parallel processing, the load on the application server is distributed
across several processes belonging to a server group. Parallel processing is applicable only to data sources
that extract data using the BW Adapter which are connected to the BDoc BUS_TRANSACTION_MESSAGE.
Entering too large of a number of processes has negative consequences on system performance. And, thus
SAP as a rule of thumb suggests that the maximum number of parallel processes should be approximately
one and a half times the number of processors on the application servers. The parallel processing is
dispatched to a server group, and in case a server group is not specified, the system uses all application
servers for the initialization. Other than using parallel processing for the data selection, the settings for data
updates to SAP BW in parallel in the IMG activity 'Maintain Control Parameters for Data Transfer' can be set.
This is applicable for all SAP delivered data sources. If the server group cannot be reached during data
extraction or if one of the processes generates an error once executed, the extraction process terminates,
thereby avoiding data inconsistencies.

© 2010 SAP AG 25
Enhancing a BW adapter based data source
Enhancing a BW adapter based data source is different from other service API based data sources. Before
getting into the details of SAP CRM BWA data source enhancement, the consultant should clearly
understand the enhancement framework offered by SAP CRM. Any CRM application, more than front end
office automation, should be flexible enough to capture data related to the ever changing customer behavior
and the dynamic market in which it is a part of. It should also be able to churn the data captured by the
application into useful information that can be used by the management of the organization for both
operational and strategic decision making. The CRM application provides a set of standard fields as a part of
the CRM order objects distinguished by business transaction type, but often from a process level these
objects requires to be enhanced to capture all the required data. Thus SAP CRM, from an application
perspective, provides the enhancement framework, required for the capturing the detailed data related to the
customer as well as the market.
The enhancement associated with the CRM data sources, can be classified into the following types, based
on the scenarios commonly arising out in an implementation.
a) Scenario A: Additional fields not present in the standard data source (service order header data) but
part of the same order object (say additional partner function in the service order header).
b) Scenario B: Additional fields not present in the standard data source (service order header data) but
captured as a part of a different order object (say a service contract/info request object which can be
a preceding document).
c) Scenario C: Additional fields required to capture extra information along with the order object, say an
additional classification of service process in service order.
Scenario A
There are scenarios occurring in CRM BW implementation where, the standard extractor provided by SAP
needs to be enhanced from fields captured as a part of fields captured in the CRM order object, say an
additional partner function in the service order header. Whenever an application object, i.e. service order,
gets changed successfully, the application starts the outbound processing, notifying interested components
about the change. Messaging flow dispatches the notification to receivers. Examples for application objects
are: business partner, product, service order, and conditions. The additional partner function, say area sales
manager, is captured as a part of the service order header data for our example.

© 2010 SAP AG 26
Before deciding for enhancements, the consultant should clearly understand partner determination
procedure to know the relationship that the respective partner function bears with the transaction.
The CRM middleware flow controller decides the events related to flow for a order object, and the
enhancement of the order data source also is governed by the same to a large extent. For this very reason,
an illustration of the same is provided here before describing the procedure for enhancement for the sake of
brevity. It is to be noted that the same mapping modules are called up for a delta initialization too which
happens without the use of the flow definitions.
The same data the respective partner, i.e. the area sales manager, for is entered and saved for the service
transaction object.

© 2010 SAP AG 27
Once the data is entered for the partner function, and saved, the data is written to the application tables. The
CRM middleware flow controller also determines the out bounds for this business object. As far as the data
extraction to the BW system is concerned, the BDoc BUS_TRANSACTION_MESSAGE is of interest.
As a part of the CRM order object, the BDoc structure BUS_TRANS_MSG_PARTNER returns the data for all
partner functions with the messaging BDoc, including the custom partner. When the data for the partner is
entered in the service order, the same is passed through the messaging BDoc in the structure for partners to
all out bounds including the BW delta queue, but the mapping for the custom partner does not exist and thus
requires enhancement. The BDoc is displayed in the transaction SMW01 for the BDoc type
BUS_TRANS_MSG. The messaging BDoc generated after saving the service order transaction displays the
data.

© 2010 SAP AG 28
The BDoc BUS_TRANSACTION_MSG, as shown below, returns the data for all the order object segments
with the messaging BDoc, including those for the partners.
The BDoc structure BUS_TRANS_MSG_PARTNER, as shown below, returns the data for all partner
functions with the messaging BDoc, including the custom partner.
The respective data source, here 0CRM_SRV_PROCESS_H, has to be enhanced for including the
additional partner data in the service order header. The inclusion of the new field is carried by adding an
append structure to the standard extract structure in the transaction RSA6.

© 2010 SAP AG 29
Figure 23: Changing the data source to include append structure (RSA6)
It is also possible to map the respective segment field of the messaging BDoc to the field of the extract
structure in the BW adapter maintenance in BWA1.

© 2010 SAP AG 30
After enhancing the data source with the append structure fields, logic has to be written to populate the data
to the data source. The logic is implemented using the BAdI definition, CRM_BWA_MFLOW, provided by
SAP standard. Here it is possible to use a field that has already been used for the BDoc.
The BAdI CRM_BWA_MFLOW is used for enhancement of data sources in the messaging flow, and helps
modification of mapping relationships between BDoc and extract structure for data sources supported by the
BW Adapter in the message flow. The system calls up BAdI implementation directly using the delivered SAP
standard mapping. The documents in the BAdI are made visible for the data sources for business
transactions and extra fields are added to the extracted data. The function module CRM_BADI_GET_XIF is
used for this purpose. The SAP delivered implementation CRM_BWA_ENHANCE_EX gives an insight on
this. The function module forms a part of the CRM XIF interface for data transfer, and is used instead of the
conventional method of using CRM_ORDER_READ. The function module CRM_BADI_GET_XIF accesses
the BDoc data from memory and helps improving the performance of the data extraction for the BWA data
sources.

© 2010 SAP AG 31
The function module CRM_BWA_BDOC_XIF stores the values in the global variables. These values for the
BDoc information and the list of BDoc segments are used for getting the XIF output on BAdI implementation.
This function module serves as a local memory for storing the BDoc information and the list of BDOC
segments used when extracting data to the BW system. The information is used by another function module
CRM_BADI_GET_XIF to get the relevant XIF structures for individual business transactions. The function
module, CRM_BADI_GET_XIF, is called by the BW Adapter for enhancement of data sources in messaging
flow BAdI, CRM_BWA _MFLOW, and depending upon the data source name, which is the input parameter,
calls the function module for XIF conversion. For e.g. in the case of the data source
0CRM_SRV_PROCESS_H, the function module CRMXIF_BWA_MAP_SERVICE is called for XIF
conversion. In case the data source name is not specified, the system checks for the business object type,
from the first entry in the BDoc and provide the relevant XIF structure. The CRM_BWA_BDOC_XIF function
module must be active for this function module to work. The CRM_BWA_BDOC_XIF function module
provides the BDoc information that is used for the XIF representation of BDoc data.

© 2010 SAP AG 32
Scenario B
The scenario B as described here differs from the above mentioned case as the additional fields, not a part
of the standard data source (service order header data), are part of the different order object (say a contract,
complaint, or a service info request which can be a proceeding document). The data for the same is captured
with this different transaction, and the instance for the BDoc for this object also is different. This kind of
enhancement is similar to a common data source enhancement, and the BW adapter data sources also
support this method of enhancement. This is similar to the classical method of data source enhancement and
the data source extract structure is appended with the required fields, and unhidden to transfer data to BW.
The logic is implemented in the standard BAdI definition RSU5_SAPI_BADI for populating the additional
fields. The function modules provided by SAP CRM, like CRM_ORDER_READ, is used for data retrieval, or
the data is extracted by reading data from the CRM application tables. The function module
CRM_ORDER_READ, for test purpose is executed from a report CRM_ORDER_READ from SE38 as single
test function in transaction SE37 is not possible for sorted tables used as import parameters.
CRM_ORDER_READ is a function module which is used to get the details of any business transaction
based on the Header GUID, Item GUID or both. CRM_ORDER_READ need to be only when the GUID for
the proceeding transaction has been obtained, else data is extracted accessing application tables or by other
function modules provided.

© 2010 SAP AG 33
The enhancement being similar to any common SAP data source is not elaborated with the most granular of
detail in this paper.
Scenario C
Often in CRM implementations scenarios arise where additional fields are required to capture extra
information along with the order object, say an additional categorization of service process in service order.
These enhancements if standalone, like those in ECC, makes it difficult as SAP CRM is an application that
has tight integration with many systems, like SAP ECC 6.0, NetWeaver BW and other external systems.
Thus SAP as a part of its CRM application has provided an enhancement framework to meet the scenarios
mentioned here. The BW consultant has to clearly understand the enhancement framework provided by SAP
CRM, as the same will help in deciding how data needs to be captured as a part of the business process.
SAP has provided the easy enhancement workbench (EEW) in CRM for this very purpose, and thus helps
enhancing the CRM objects ensuring and taking care of all aspects related to technical definition of the new
field, screen level changes for the new field for capturing data, value helps and dropdowns for the new field,
and the integration aspects with backend, reporting and mobile systems. From SAP CRM 7.0, SAP has
provided the application enhancement tool (AET) in addition to the CRM easy enhancement workbench
(EEW) for making enhancements simple and flexible. Earlier in CRM implementations the new field created
in EEW was then displayed and configured using the UI Configuration Tool. With the introduction of
application enhancement tool (AET) for structural enhancement in SAP CRM 7.0 adding a custom field has
become even easier and has made the CRM enhancement framework in SAP CRM simpler and flexible. The
AET is part of the new CRM Web UI and is seamlessly integrated with the UI Configuration Tool. Adding a
new field and making it available on the UI does not require deep technical knowledge and reduces
development efforts to a large extent. Moreover the enhanced field can be easily extended to integrated
applications like NetWeaver BW.
The paper as a part of this scenario would explore the initial framework of enhancement with CRM easy
enhancement workbench, but would describe the extraction detail along with the enhancements with CRM
application enhancement tool.
Enhancement with CRM Application Enhancement Tool
With latest version of SAP CRM, the Application Enhancement Tool (AET) has been introduced to enhance
CRM applications and is used to display, create, change, and delete enhancements. The Application
Enhancement Tool in SAP CRM is integrated in the UI Configuration Tool, and can be started in this tool.
The fields added to an application are available in the UI configuration of the corresponding UI component
and view. These new fields available on the user interface are made available by adding them to the view.

© 2010 SAP AG 34
Following are the main functions offered by the CRM Application Enhancement Tool:
a) Creating custom fields
b) Defining dropdown list boxes for custom fields
c) Translating field labels and entries in dropdown list boxes
d) Assigning search helps and check tables to custom fields
e) Making new custom fields available in search criteria and/or result lists, business intelligence (BI)
reporting, R/3 Adapter, CRM Mobile, and CRM interactive reporting, this depends on the enhanced
business object
f) Using different data types, such as characters, dates, times, and numbers
g) Reusing fields in other business objects, if these business objects are based on the same
enhancement place
In our scenario, a new field needs to be added to the service order header, called call type, a classification
intended specifically for analysis purpose. The field is not available as a part of standard, as the classification
is required more from an analysis perspective, than the business transaction type, which is required more at
a process level to determine status, dates, partners, pricing etc.
As a part of the implementation it has been decided that the field needs to be enhanced at the service call
header level, and the enhancement is implemented within the framework for enhancement provided by SAP
CRM. The CRM 7.0 Application Enhancement Tool is used due to its flexibility; ease of implementation and
for minimizing the total cost of ownership, over classical procedures of enhancements.
Before carrying out the enhancement using the SAP CRM Application Enhancement Tool, necessary CRM
technical configuration has to be carried out in the system and it has to be ensured by the BW consultant that
the data source concerning to the relevant business object has to be activated. The activation of the data
source is important, as the data source also is an impacted object in the generation of the enhancement. An
inactive data source would result in the failure of the enhancement generation.

© 2010 SAP AG 35
Once the CRM technical activities for CRM UI configuration is carried out and sufficient authorization are
provided, the enhancement of the business objects is done from the CRM Web UI. Login to the CRM Web
UI, either using the URL or transaction CRM_UI; and select the respective transaction.
Select the required transaction for enhancement, i.e. service object, as in this case and use the UI
configuration tool to create the enhancement.
The appropriate part for creation of the enhancement needs to be selected before the creation of the new
field. Here the service data header has been chosen as the object part for enhancement.

© 2010 SAP AG 36
After selecting the object part enhancement, chose new to create the enhancement as shown below.
The screen opens where the details of the new fields have to be furnished for the creation of the field.
The details of the new field includes the technical properties of the field, the enhancement and the field
identifiers, the description, dropdown values, check table and other aspects. The ‘relevance for BW reporting’
also needs to specified as this is important for data extraction to BW. If the field is not relevant to BW
reporting, for e.g. a description, the flag can be unchecked. Once generated, field is added across all objects.
The values of the drop down can also be specified at the UI configuration level as shown below.

© 2010 SAP AG 37
The details of the new field includes the technical properties of the field, the enhancement and the field
identifiers, the description, dropdown values, check table and other aspects. The ‘relevance for BW reporting’
also needs to specified as this is important for data extraction to BW. If the field is not relevant to BW
reporting, for e.g. a description, the flag can be unchecked. Once generated, field is added across all objects.
The values of the drop down can also be specified at the UI configuration level as shown below.
The language dependencies of the new field, if applicable can also be specified in the UI configuration tool.
The field can be made available on the CRM Web UI for service transaction as shown below.

© 2010 SAP AG 38
The field is now available to capture the data in the service transaction, and is also present in all related
objects to help data transfer to BW. The following section gives a detail of the same.
The details of the enhancement carried out through the UI configuration tool in SAP CRM is displayed in the
transaction AXTREG. It gives a detail of the enhanced business objects, with the detail of the enhancement.
It gives a detail of the generation that has taken place for the new field.
The below screen shots give a complete detail of the enhancement carried out.

© 2010 SAP AG 39
In addition to the enhancement to concerned BO part, the detail of further generation, as for mobile data
transfer, BW data transfer etc. is viewed under the generation details for further generation.
Generation detail displays the detail of the enhancement for each of the enhancement indicators, like for BW.

© 2010 SAP AG 40
After carrying the enhancement using the application enhancement tool, it is seen that the following objects
gets modified with the newly added field. First and foremost the application database table,
CRMD_SERVICE_H is added with the new field as an include.
It is noted that the domain generated for the new field holds the dropdown values in the value range. The
code for call type, say 1, 2, 6 etc. gets extracted as a part of the CRM service transaction and the master
data comprising of the texts is separately extracted to the BW system for reporting. The infoobject for the
same will be a custom one with texts.

© 2010 SAP AG 41
In order to extract the master data for the new field call type, a custom master data text data source is
created in SAP CRM. The data source extracts the text data to the BW system for call types. The text data
source will be created in transaction RSO2 based on the generated domain object as a part of the AET.
In addition to the application tables, the BDoc structure for the service transaction, the selection and mapping
module of the BW Adapter metadata, the extract structure etc. is adjusted with the new field. The detail of the
extension to the BDoc BUS_TRANSACTION_MESSAGE, related to 0CRM_SRV_PROCESS_H is viewed
from the transaction SBDM (BDoc Modeler).

© 2010 SAP AG 42
The detail of the enhancement made is viewed under the structure SERVICE_H in the messaging BDoc
responsible for data transfer to BW.
The new field is added in the messaging structure SERVICE_H.

© 2010 SAP AG 43
The field gets automatically added to the extract structure of the data source as the same during its creation
is made BW relevant. Making the enhancement BW relevant results in inclusion of the field in the extract
structure, adjustment of the BW adapter metadata and the extraction program that populate data for this
field.

© 2010 SAP AG 44
It is ensured that the field is available for data extraction to BW in the transaction RSA6.
The BW adapter mapping is also automatically generated for the data source. The field of the extract
structure is mapped to the respective BDoc segment field.
Enhancement with CRM Easy Enhancement Workbench
The Easy Enhancement Workbench is a development tool with which SAP application business objects,
including SAP CRM business objects, are extended in a simple manner. Customer enhancements to a
business object are defined via wizards that reside above the data dictionary layer. The workbench then
does all development work and the database tables, screens and application logic are created automatically.

© 2010 SAP AG 45
Finally the customer enhancement is included in the SAP standard. This helps enhancements and
modifications without ABAP knowledge and the possibility of extending the SAP standard.
An extension created using the easy enhancement workbench does not differ technically from one created
manually as 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
objects required 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 system
landscape must be set up in order to be able to use system-wide generation. The system landscape must be
set up in order to be able to use system-wide generation. 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 enhanced fields are also made relevant
to BW extraction.
The project is at the highest level in an EEWB enhancement.
A project combines several extensions and all generated objects belonging to a project are transported
together; it is not possible to transport an individual extension. The package (development class) of the
generated objects is also determined in the project.

© 2010 SAP AG 47
Extensions are created at the next level. An extension refers to a Business Object and an extension type.
The definition of the extension takes place via Business Object-specific wizards. When an extension has
been defined and generated, the object type post processing typically appears at the next level. These are
activities that must be executed manually by the user. An extension is only considered to be ready when it
has been generated correctly and all required post processing activities have been executed.

© 2010 SAP AG 48
The following screenshots describe the steps to add additional fields using the wizard for new fields in the
CRM easy enhancement work bench.
Step 1
Step 2

© 2010 SAP AG 49
Step 3 – The transaction type to which the new field is added is specified here.
Step 4 – Specifies the technical characteristics of the field to be added.
Step 5 – The assignment of the field is important from a BI aspect as well as it eventually determines the
relationship, whether the fields need to be captured at header level or at item level.

© 2010 SAP AG 50
Step 6 – This step is the most important step by the BW aspect, as this is where the fields relevant for BW
get determined.
When specified relevant for BW extraction the following aspect of data extraction are taken care during the
generation of the new field. The new field is included in;
a) Respective database tables as a part of the enhancement, irrespective of BI relevance.
b) Respective business document for the transaction including those responsible for out bounds into
BW
c) Extract structure of the data source – the field needs to be made available for extraction by un-hiding
the same in the transaction RSA6.
d) Generates a BAdI implementation for definition CRM_BWA_MFLOW that transfers the field to the
data sources. The implementation generated by EEW can be identified and displayed from the
transaction SE18 for BAdI definition CRM_BWA_MFLOW.
e) The data captured for the new EEW enhancement fields gets extracted in RSA3 without the need for
implementing a custom logic for the same.

© 2010 SAP AG 51
The screenshots of the same has not been included here for the EEW field, but will be illustrated in detail for
the enhancement mentioned in the below section using the new CRM Application Enhancement Tool.
The additional activities required in BW have to be manually carried out, which includes;
a) Creation of custom infoobject for the new fields
b) Loading master data to the infoobject if the field holds master data.
c) Inclusion of the new infoobject in the DSOs and InfoCubes.
d) Mapping of transformation rules, extraction and loading of data.
The consultant while using the easy enhancement workbench has to be very clear of its technical
implications. The wizard sits above the data dictionary layer, and creates and modifies a number of data
dictionary objects during generation. Any change required has to be carried out at the wizard level, and any
modification at the dictionary level would lead to inconsistencies.
Extraction of user status of one order objects
This section of the treatise describes the necessary configuration that needs to be carried out in the SAP
CRM system for extracting the user status of a CRM order object. This is included as the same always is
important from an analysis perspective and reports are often driven from the values retuned for the user
status. Before making the required configuration in the CRM system, the BW consultant should know the
status management concept and its implementation in SAP CRM. The status management framework in
SAP is defined under two categories;
a) System Status – The system status is a status set by the system, which gives information whether
the system has executed a specific business transaction on an object. This is technical in nature and
can have states open, in process, released, distributed etc. and is defined in the
CRMC_STATUS_PROC table.
b) User Status – The user status is the status that is set by the user to the transaction and is created as
additional information to the existing system status. A user status is defined in a status profile
created in SPRO customizing for business transactions. As many statuses can be defined and
activated in customizing and a status profile is then assigned to the following in customizing for
business transactions:
 Transaction type (for header status)
 Item category (for item status)
The header status is independent of the item status with the exception of status completed.
A status profile can be assigned to several transaction types and item categories. The system status and
user status influences the business transactions in the same way.

© 2010 SAP AG 52
In our scenario here, we consider the CRM complaint object for which multiple status profiles with different
user statuses is configured in the CRM system from a process level. The user status is of importance from a
reporting perspective.
Here our focus is on extracting user status for an order transaction, and the customization required for the
same. In order to extract the user status for a CRM business transaction, the respective BWA order data
source is enhanced. The BW status is defined in customizing, based on the analysis requirement on
statuses. It is possible that a business object type has different transaction types, and with each of this
different transaction type having a status profile with user status. All statuses that are currently active for an
object viz. business partner, product master, transaction data etc are displayed. It is possible that any
number of statuses is active at the same time. But certain numbers of status values mutually exclude each
other as in the case of statuses "In process" and "Completed".

© 2010 SAP AG 53
The different statuses are combined using a BW status object and a BW status is assigned to each of the
individual user statuses. The status that active in the source system at the point when data is extracted is
then transferred to SAP BW using the BW status object. BW status object groups are used to arrange the
BW status objects semantically.
The customization for user status is made in the transaction SBIW in the CRM system.
Create one or several BW status object groups (three characters) to arrange status objects semantically.
Create a BW status object. The data is later extracted into SAP BW using the three-character name of the
BW status object group and the four-character name of the BW status object.
Use the possible entries function to select a combination of user status and status profile. Assign a status
number (not equal to 0) in the BW Status field to this combination. The status numbers in this way is used to
order the statuses in BW semantically within a BW status object.

© 2010 SAP AG 54
To extract the texts for the BW status into SAP BW a text data source is generated from SBIW transaction
for BW Status Objects.
After carrying out the required customization, and importing the customizing request using SCC1, in
landscapes with separate customizing, development and unit test clients for CRM development, the data
source, 0CRM_COMPLAINTS_I in this scenario, is enhanced to extract the user status for the CRM
complaint object. The paper takes the complaint object as an example scenario instead of the service order
header followed across, as the BW status object for complaints is not available as a part of standard in SAP
CRM. For the service orders the BW status object SVTK, service lifecycle, is provided by standard under BW
status object group ONE, and only entries depending on the requirement need to be created in customizing,
along with data source enhancement.
The enhancement of the data source is carried out from RSA6 for the data source 0CRM_COMPLAINTS_I.

© 2010 SAP AG 55
Extend the extract structure by adding a field of the data type CRMBWST with the technical name
BWSTYYYXXXX, where YYY stands for the BW status object group and XXXX for the BW status object. In
our case YYY corresponds to ONE and XXXX to ZCLA, making the extract structure field BWSTONEZCLA.
It is to be ensured that the field for the extraction is selected, and that the selection and hide field indicators
in RSA6 are not set. However the ‘field only’ known in exit indicator must be set. Selecting the flag ‘field only’
ensures that the field in the extract structure is not passed to the extractor at runtime.
During extraction, the extended field is automatically filled with the BW status number for the status active at
the time of the extraction.

© 2010 SAP AG 56
Operational aspects of BW Adapter data sources
The section focuses on the operational aspects of data extraction for the BW adapter based data sources in
the SAP CRM system. The data is loaded into BW in a productive environment after the data sources have
been implemented and customized to the requirements at hand during the solution implementation. As a first
step, the data source is initialized to extract and carry out an initial update of data residing in the CRM
application database to SAP BW system. The process of initialization, like any SAP data source, generates a
delta initialization pointer and a delta queue, which helps extracting the new and changed transaction in the
CRM application on a regular operational basis.
Delta Initialization
The process of initialization is similar to that of any SAPI data source, and is achieved by the execution of an
INIT info package for the concerned data source.
Upon the event of initialization of the data source the respective queues get generated for the SAPI and the
BW Adapter. The SAPI delta queue is displayed in transaction RSA7 and that of the BW adapter is displayed
in the transaction BWA7.

© 2010 SAP AG 57
The SAPI delta queue to which data gets written by the CRM BW adapter is displayed in RSA7.
Incremental delta upload
In certain scenarios it is possible that the data extraction from CRM to BW for a particular data source does
not get all the required field information. It can also be due to the fact that while doing the extraction initially,
the corresponding BW objects for all the fields may not have been created and the mapping rules may not
have been adopted. This results in some of those fields not getting uploaded to the BW system. Under these
circumstances a re-initialization of the data source is often considered as the solution, but doing a repeat of
the initial upload may prove to be performance intensive if the data in the initial upload volume is high.
It is in this context that SAP has provided the solution of an "incremental delta upload", which uploads only
the set of data specified by selection conditions for a data source. An incremental delta upload is carried out
by the execution of the report SMOX_INCR_DELTA_UPLOAD in the CRM system specifying the destination
system, data source name and the data selection.

© 2010 SAP AG 58
The report reads data from the application database and fills the delta queue for the selection conditions
specified. The data is the extracted from the delta queue to the BW system by the execution of the delta Info
Package. The incremental delta upload functionality is never a standard functionality recommended by SAP,
but often helps in data upload to BW during BWA data source related cutovers.
SAP also provides the option to schedule the execution of the report to upload data to the delta queue of the
data source.

© 2010 SAP AG 59
The status of the incremental data upload is monitored from the standard job monitor in SAP using the SM37
transaction.
After the successful execution of the report for incremental delta upload, the data for the specified selection
parameters for the data source is written to the BW delta queue. The data is displayed in RSA7 and is
subsequently extracted into the BW system by the execution of the delta Info Package.
Delta upload
Every time a CRM order transaction is changed or a transaction is created or deleted, the data is written to
the CRM application database. Consider the scenario where the call type is changed in the service
transaction in the screenshot below from ‘warranty’ to ‘beyond warranty’.

© 2010 SAP AG 60
When the change is saved in the CRM web user interface, the data gets written to the application tables in
the CRM system. Together with this, the CRM application triggers the BDoc message
BUS_TRANSACTION_MESSAGE which further helps the concerned adapters process the outbound.
Once the BDoc is successfully processed by all receivers the data is written to the SAPI delta queue of the
BW adapter data source.

© 2010 SAP AG 61
The data is then extracted to BW system by executing the delta Info Package for the data source.
The data comes to the PSA of the data source after the execution of the Info Package and it is extracted to
the further layers of the enterprise data warehouse, like the DSO and the InfoCubes for enterprise reporting.
For the delta functionality of a BW adapter data source to work, as discussed before in the concept, the BW
consultant has to ensure the following;
a) Flow definition is active and defined for the CRM middleware flow controller.
The service CRM_UPLOAD_BW_SRV runs for creating BW Delta in Flow services. In case the functionality
of CRM timestamp analysis is used for analysis in BW, the time stamp service
CRM_UPLOAD_BW_TSS_DTRACK_SRV, for calculation of performance key figures defined is found in the
middleware flow definition. The point is made in this context as the same is available in the screenshot
above. Ensure the message flow BDoc type is active, and that no entry is made to deactivate the same in
customizing in the screenshot below.

© 2010 SAP AG 62
b) Ensure that the BDoc type BUS_TRANS_MSG for outbound processing gets created. The BDoc is
triggered when the transaction is saved and data is written to the CRM application database.
c) Ensure the CRM queue CSA* is registered in transaction SMQR. The queue is responsible to process all
outbound from SAP CRM, including to the BW Adapter. The queue is processed immediately, and when
stuck prevents data transfer to BW. The queue needs to be processed if the same is displayed in SMQ1 at
any point of time; else the status of the BDoc remains in yellow.
d) Ensure the generators responsible for BW adapter delta have been generated. The same is found in the
transaction GNRWB. Activate these services as they are responsible for determining the delta, filling the
BWA queue and the delta queue.

A treatise on SAP CRM information reporting

A treatise on SAP CRM information reporting

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A treatise on SAP CRM information reporting

Similar to A treatise on SAP CRM information reporting (20)

Recently uploaded

Recently uploaded (20)

A treatise on SAP CRM information reporting