a treatise on crm (adb) data extraction for business information reporting

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.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: C V Vijay Raj

Created on: 28 July 2010

Author Bio

C V Vijay Raj is a Production/Industrial engineer and works as an SME 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 process centered early business intelligence implementations with SAP in SOA environments.

https://www.sdn.sap.com/irj/sdn/nw-bi

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

Use of surrogates within SAP to meet requirements ...................................................................................... 6

Custom development ...................................................................................................................................... 8

Concept of SAP CRM data extraction ................................................................................................................ 8

Understanding the SAP CRM One Order Framework – A brief...................................................................... 8

Business Documents or BDocs ...................................................................................................................... 8

SAP CRM BW Adapter ................................................................................................................................. 10

Delta initialization of BWA Data sources ....................................................................................................... 11

Delta extraction of BWA Data Sources ......................................................................................................... 13

Implementation of data extraction based on BW Adapter data sources .......................................................... 15

Installing business content BW Adapter based data sources ....................................................................... 15

Customization for BWA data sources ........................................................................................................... 17

Enhancing a BW adapter based data source ................................................................................................... 19

Scenario A ..................................................................................................................................................... 20

Scenario B ..................................................................................................................................................... 25

Scenario C .................................................................................................................................................... 26 Enhancement with CRM Application Enhancement Tool ........................................................................................... 26

Enhancement with CRM Easy Enhancement Workbench ......................................................................................... 38

Extraction of user status of one order objects .................................................................................................. 43

Operational aspects of BW Adapter data sources ........................................................................................... 48

Delta Initialization .......................................................................................................................................... 48

Incremental delta upload ............................................................................................................................... 49

Delta upload .................................................................................................................................................. 51

Conclusion ........................................................................................................................................................ 55

Related Content ................................................................................................................................................ 56

Disclaimer and Liability Notice .......................................................................................................................... 57



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



© 2010 SAP AG 4

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.

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, 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



© 2010 SAP AG 5

the OLAP implementations are carried out hand in hand. In such implementation 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 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 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



© 2010 SAP AG 6

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

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



© 2010 SAP AG 7

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.

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



© 2010 SAP AG 8

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



© 2010 SAP AG 9

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 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;

Figure 2: Structure of a business document or BDoc

SAP CRM makes use of messaging BDocs for data extraction to BW via the SAP CRM BW Adapter.



© 2010 SAP AG 10

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.

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.



© 2010 SAP AG 11

Figure 3: BW Adapter data source flow

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.

Figure 4: BW Adapter Data source Mappings

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.



© 2010 SAP AG 12

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 customer specific BAdI implementations, maps and helps the data extraction from the CRM system using the mBDocs to the data source extract structure.

Figure 5: Delta initialization of BWA Order Data Sources



© 2010 SAP AG 13

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.

Figure 6: CRM middleware flow definition for BW Adapter (SMO8FD)

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 14

Figure 7: Delta extraction framework of BW Adapter based order data sources

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.

Figure 8: Register BDoc message queue CSA* for delta transfer to BW (SMQR)

Once the BDoc is successfully processed the data is written to the BW SAPI delta queue.



© 2010 SAP AG 15

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.

Figure 9: Installation of standard business content data sources (RSA5)

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.

Figure 10: Post process data sources and hierarchy (RSA6)

In contrast with the other SAP data sources, the BW adapter data sources requires 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.

Figure 11: BW Adapter metadata (BWA5)



© 2010 SAP AG 16

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.

Figure 12: Service API metadata for a BW Adapter data source (RSA2)

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 17

Figure 13: BW Adapter data source metadata (BWA1)

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 18

Figure 14: Order segments release maintenance (BWA_SEGREL)

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.

Figure 15: CRM BDoc Modeler (SBDM)



© 2010 SAP AG 19

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.

Figure 16: Parallel processing for initial upload to BW (BWA8)

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.

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.



© 2010 SAP AG 20

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.

1) 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).

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

3) 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.

Figure 17: Partner determination procedure for business transactions (SPRO)

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.

Figure 18: Partner function in business transactions (SPRO)



© 2010 SAP AG 21

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.

Figure 19: Partner function entry in the service transaction - 80000000655 (CRM_UI)

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.

Figure 20: Display BDoc (SMW01)

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 22

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.

Figure 21: Display BDoc body (SMW01)

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.

Figure 22: Display BDoc partners for order object (SMW01)

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 23

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.

Figure 24: BW adapter data source maintenance (BWA1)



© 2010 SAP AG 24

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.

Figure 25: Enhancing the BWA data source, BAdI CRM_BWA_MFLOW (SE18)

Figure 26: Enhancing the BWA data source, CRM_BWA_MFLOW (SE18)



© 2010 SAP AG 25

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.

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 26

Figure 27: BAdI implementation for SAPI Enhancement, RSU5_SAPI_BADI (SE18)

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 27

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.

Figure 28: Ensure AP business content data source for the respective business object is installed

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.

Figure 29: Selecting CRM service transaction from CRM Web UI (CRM_UI)

Select the required transaction for enhancement, i.e. service object, as in this case and use the UI configuration tool to create the enhancement.



© 2010 SAP AG 28

Figure 30: Configuration mode from CRM Web UI (UI configuration tool)

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.

Figure 31: Selection of object part for enhancement (UI configuration tool)

After selecting the object part enhancement, chose new to create the enhancement as shown below.



© 2010 SAP AG 29

Figure 32: Creating the enhancement (UI configuration tool)

The screen opens where the details of the new fields have to be furnished for the creation of the field.

Figure 33: Field details for the new field (UI configuration tool)

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.

Figure 34: Dropdown values (UI configuration tool)

The language dependencies of the new field, if applicable can also be specified in the UI configuration tool.

Figure 35: Translation (UI configuration tool)



© 2010 SAP AG 30

The field can be made available on the CRM Web UI for service transaction as shown below.

Figure 36: Displaying the added field in Web UI (UI configuration tool)

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.

Figure 37: User interface for service transaction (Web UI)



© 2010 SAP AG 31

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.

Figure 38: Overview of extensible business objects (AXTREG)

The below screen shots give a complete detail of the enhancement carried out.

Figure 39: Enhanced BO Part Detail (AXTREG)

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.



© 2010 SAP AG 32

Figure 40: Further generation detail for the business object (AXTREG)

Generation detail displays the detail of the enhancement for each of the enhancement indicators, like for BW.

Figure 41: Detail for enhancement indicator for BW Reporting (AXTREG)

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.



© 2010 SAP AG 33

Figure 42: CRM Table Display - CRMD_SERVICE_H (SE11)

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.

Figure 43: Display domain for new field for call type

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.



© 2010 SAP AG 34

Figure 44: Display domain for new field for call type

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 35

Figure 45: Display business document (BDoc) BUS_TRANSACTION_MEGGAGE (SBDM)

The detail of the enhancement made is viewed under the structure SERVICE_H in the messaging BDoc responsible for data transfer to BW.

Figure 46: Display business document (BDoc) BUS_TRANSACTION_MEGGAGE (SBDM)

The new field is added in the messaging structure SERVICE_H.



© 2010 SAP AG 36

Figure 47: Display messaging structure SERVCIE_H (BUS_TRANSACTION_MEGGAGE - SBDM)

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.

Figure 48: Extract structure for data source 0CRM_SRV_PROCESS_H (RSA6)



© 2010 SAP AG 37

It is ensured that the field is available for data extraction to BW in the transaction RSA6.

Figure 49: Make field available for BW extraction 0CRM_SRV_PROCESS_H (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.

Figure 50: BW Adapter Metadata (BWA1)



© 2010 SAP AG 38

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

Figure 51: Easy enhancement workbench (EEWB)

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 39

Figure 52: Create project - easy enhancement workbench (EEWB)

Figure 53: Create extension - easy enhancement workbench (EEWB)

EEWB allows adding new fields to individual sub-objects of CRM One Order business objects.



© 2010 SAP AG 40

Figure 54: Create extension for business objects- easy enhancement workbench (EEWB)

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.

Figure 55: Define extension type - easy enhancement workbench (EEWB)



© 2010 SAP AG 41

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 – Defines the title for the enhanced field.

Step 3 – The transaction type to which the new field is added is specified here.



© 2010 SAP AG 42

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.

Step 6 – This step is the most important step by the BW aspect, as this is where the fields relevant for BW get determined.

Figure 56: Steps involved in enhancement (EEWB)



© 2010 SAP AG 43

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.

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.

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.



© 2010 SAP AG 44

Figure 57: Configuration of user status (SPRO)

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

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.



© 2010 SAP AG 45

The customization for user status is made in the transaction SBIW in the CRM system.

Figure 58: Process user status (SBIW)

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.

Figure 59: Maintenance of BW status objects (SBIW)

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.

Figure 60: BW status mapping to user status (SBIW)

To extract the texts for the BW status into SAP BW a text data source is generated from SBIW transaction for BW Status Objects.



© 2010 SAP AG 46

Figure 61: Creation of text data source for BW status (SBIW)

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.

Figure 62: Enhancement of data source for user status (RSA6)



© 2010 SAP AG 47

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.

Figure 63: Append structure for BW status object defined (RSA6)

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.

Figure 64: Edit data source to extract BW status object (RSA6)

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 48

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.

Figure 65: Delta initialization for the BWA data source 0CRM_SRV_PROCESS_H (Info Package)

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.

Figure 66: Delta activation for the BWA data source 0CRM_SRV_PROCESS_H (Info Package)

The SAPI delta queue to which data gets written by the CRM BW adapter is displayed in RSA7.



© 2010 SAP AG 49

Figure 67: SAPI delta queue for the BWA data source 0CRM_SRV_PROCESS_H (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.

Figure 68: Execute report SMOX_INCR_DELTA_UPLOAD - Incremental Delta Upload (SE38)



© 2010 SAP AG 50

Figure 69: Parameters for Incremental Delta Upload (SE38)

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.

Figure 70: Schedule incremental delta upload (SE38)

The status of the incremental data upload is monitored from the standard job monitor in SAP using the SM37 transaction.



© 2010 SAP AG 51

Figure 71: Job monitor for incremental data upload (SM37)

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.

Figure 72: Data for the selection written to the delta queue by incremental delta upload (RSA7)

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

Figure 73: Change in service transaction (CRM_UI)

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.



© 2010 SAP AG 52

Figure 74: BDoc for the changed transaction (SMW01)

Once the BDoc is successfully processed by all receivers the data is written to the SAPI delta queue of the BW adapter data source.

Figure 75: After image for the change in the delta queue (RSA7)

The data is then extracted to BW system by executing the delta Info Package for the data source.

Figure 76: Delta Info Package for data extraction (0CRM_SRV_PROCESS_H)



© 2010 SAP AG 53

Figure 77: PSA in BW for the data source 0CRM_SRV_PROCESS_H

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.

Figure 78: CRM Middleware flow definition for BDoc type BUS_TRANS_MSG (SMOFD8)

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.

Figure 79: Customization to deactivate message flow (SPRO)

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.



© 2010 SAP AG 54

Figure 80: Register queue (SMQR)

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.

Figure 81: Services for BWA BDoc type BUS_TRANS_MSG (GNRWB)

The figure below describes the data flow from a debugging and analysis perspective.

Figure 82: BW adapter data source dataflow for debugging and analysis



© 2010 SAP AG 55

Conclusion

The very notion of this paper had happened after a small post SME audit discussion for a CRM BW implementation where a casual question was put to me on writing a paper for CRM analytics similar to the earlier treatise on logistics data extraction. But CRM analytics being a vast topic, it was never a very comfortable question to say yes to, and nor is writing on a concept similar to a normal operational task at hand. But after a while the same feeling persisted, to attempt that very notion, despite being indifferent to the request earlier, that a small part of CRM analytics, application database data extraction, was chosen as a starting point. But now on the completion of the paper, somewhere that satisfaction of this being a complete treatise is absent. A genuine attempt, given the time constraints at hand, has been made to elaborate on the concept and implementation of data extraction from the CRM application database using the BW adapter data sources.

The paper within its framework assays to the best possible extent the concept and implementation of data extraction from the SAP CRM application database to the BW system, though a real life scenario may differ based on the factual requirements at hand. It furnishes an outline of the capabilities offered by SAP with its CRM BW integration for CRM application data reporting, its implementation and operational aspects, to enable real life deployment of a robust CRM solution.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b08e1c2c-40e3-2c10-26b6-bf700e6fd374?QuickLink=index&overridelayout=true



© 2010 SAP AG 56

Related Content

CRM Analytics Wiki on SDN

CRM Analytics page on SAP Help

Analytical CRM – SAP white paper

Note 850817 - CRM-BW: Using BDocs for the enhancements in BAdI

Note 692195 - FAQ: Sales Analytics and CRM-BW data Extraction

Note 639072 - CRM/BW parallel proc. for extracting business transactions

For more information, visit the EDW homepage

http://wiki.sdn.sap.com/wiki/display/CRM/CRM+Analytics

http://help.sap.com/saphelp_crm50/helpdata/en/0d/78c73c13b0ce5be10000000a114084/frameset.htm

http://www.sap.com/solutions/business-suite/crm/pdf/AnalyticalCRM_50046585.pdf

https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=850817

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=692195

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=0000639072&nlang=E

https://www.sdn.sap.com/irj/sdn/nw-bi



© 2010 SAP AG 57

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.