CRM FieldApp Customizing

Overview Presentation:
Operating and Customizing Field Applications in SAP CRM

SAP CRM 5.0 Field Applications
Content
Field Applications in SAP CRM mySAP CRM Powered by SAP NetWeaver: Mobile Scenario
CRM Middleware and Mobile .NET Client
Operating Field Applications in SAP CRM

System Landscape Data Distribution and Synchronization System Administration and Monitoring
Customizing Field Applications in SAP CRM

Server-Side Customizing Process Client-Side Customizing Process Software Logistics
Further Information
SAP AG 2005, SAP CRM 5.0 Field Applications, 2 of 34
Field Applications in SAP CRM

Field applications is a key capability within SAP CRM, providing marketing, sales, and service functionality in an offline environment on notebooks or PDA devices: There are four SAP CRM standard applications:
Mobile sales Mobile service Mobile sales for handheld Mobile service for handheld
Mobile sales and mobile service are based on the following:

CRM middleware Mobile .NET client
Mobile Sales / Mobile Service provide marketing, sales, and service functionality on a notebook (or Tablet PC). CRM Middleware and Mobile .NET Client are the technologies supporting these notebook-based applications. Mobile Sales for Handheld and Mobile Service for Handheld are supported by Mobile Infrastructure (Mobile Java Client), another technology provided by SAP, targetting handheld devices. This technology is not discussed in this presentation.
Challenges in Field Applications

Comprehensive support of mobile users in their daily work Offline availability of all relevant customer-related data Seamless integration with other CRM components to guarantee integrated processes between in-house and field users Information sharing between online and offline users by leveraging intelligent replication services Easy deployment and automatic installation of laptops in the field
Content


Further Information
mySAP CRM Powered by SAP NetWeaver
SAP CRM Marketing Sales Service Analytics Channel Management Interaction Center E-Commerce CRM Integration Services SAP NetWeaver People Integration Information Integration Process Integration Application Platform Field Applications in SAP CRM Mobile Sales: Laptop/Handheld/Online Mobile Service: Laptop/Handheld Mobile .Net Client (SAP CRM) Mobile Browser Client Mobile Java Client
SAP NetWeaver Mobile
As part of SAP NetWeaver Mobile, Mobile .NET Client (SAP CRM) is a client technology designed and optimized for Microsoft Windows-based, occasionally server-connected CRM field applications running on mobile devices with a large footprint, such as notebooks. The CRM Integration Services (CRM Middelware) provide mobile client synchronization facilities to ensure seamless integration of business data and processes between inhouse- and field users.
CRM Middleware: Facts

Mobile client synchronization
Data replication using publish and subscribe concept Automatic redistribution of data upon changes
Value change in replication-relevant data fields (minor realignment) Changed data assignments for mobile sites (major realignment)
Automatic installation and upgrade of mobile clients Central backup and recovery of mobile data
Cross-component system administration and monitoring Back-end integration Groupware integration
The CRM Middleware provides the means to keep multiple offline, occationally connected, mobile clients in a consistent state in sync with the CRM Server. Data is replicated to mobile clients according to a replication model based on the publish & subscribe concept. This means, a mobile client has to subscribe to certain data in order to receive this data. The CRM Middleware takes care of re-distributing data in case of data changes (minor realignment) as well as subscription rule (major realignment) changes. Besides business data, also software or runtime data (installation packages, upgrades) can be distributed to mobile clients using the CRM Middleware. In case e.g. a notebook has to be replaced, data can be recovered fast and easily. The Consolidated Database (CDB) on the CRM Server contains all data from all mobile clients, so that the CRM Middleware can extract any subset of data needed and make it available for any mobile client. The CRM Middleware also provides various tools for system administration and monitoring. Real-time data exchange between a CRM Server and a Groupware Server can also be provided by the CRM Middleware. So, e.g. Business Partners in Mobile Sales can be integrated with contacts in Microsoft Outlook. The CRM Middleware provides full Back-End integration of the CRM System into mySAP ERP as well as non-SAP Back-Ends using various adapters and plug-ins.
Mobile .NET Client: Facts

Design-time environment: Mobile Application Studio
Integration with Microsoft Visual Studio .NET Modifying and enhancing field applications in SAP CRM
Set of visual modeling tools
Source-code generation Change management and modification support Multiuser development Translation support Software logistics
Runtime frameworks
Business framework layer User interface framework layer
Mobile .NET Client provides a runtime framework for CRM Field Applications as well as a design environment to customize these applications. The design environment, Mobile Application Studio (MAS), is integrated with Microsoft Visual Studio .NET and provides a set of visual modeling tools to facilitate application development as well as a code generator to generate source code from the application meta-data which is stored in the Mobile Application Repository (MAR). The MAS together with the MAR handles multiuser development and provides proper change management for development objects. Multilanguage translations for labels and captions are handled Software logistics, based on the standard R/3 transport system in conjunction with the CRM Middleware, exist for application meta-data as well as for generated runtime files (-> upgrades). The runtime frameworks consist of a business framework layer and a user interface framework layer. The business framework layer contains a logic layer which defines the interfaces exposed to application developers and a data access layer (DAL) which defines services for accessing the local user database. The user interface framework layer consists of a core layer which interacts with the logic layer of the business framework and which defines the core interaction components and their behaviour, and a control layer which defines the actual controls that appear on the screen (all derived from .NET controls) and the interaction between the controls and the core (-> peer layer).
8
Content


Further Information
SAP CRM System Landscape: Mobile Scenario
mySAP ERP
UDB UDB UDB Periodically, the mobile clients dial up the communication station to exchange data via the CRM Middleware.
Mobile Clients with CRM Field Application
Communication Station
MAS MAS
ODBC
MAS
MAR
Mobile Repository Server with Mobile Application Repository (MAR)
CDB CRM Server with CRM Middleware
Other Systems
Mobile Development Workstations with Mobile Application Studio (MAS)
Mobile Development Environment

Permanent communication facilities Temporary dial-up facilities
CRM Server The CRM Server is the heart of the system landscape. Here the CRM Online application components as well as the CRM database reside. The CRM Middleware is a software component on the CRM Server providing, among others, various services to integrate mobile clients. The consolidated database (CDB) is part of the CRM database (certain set of tables) and contains the consolidated data from all mobile clients. This means that the local user database (UDB) on every mobile client is a subset of the CDB. In case of a crash or loss, it is very easy to replace every mobile client / UDB by just extracting the respective data from the CDB. Communication Station The communication station acts a switch site for mobile clients to connect to the CRM Server to exchange data. The data packages in the outbound queue of a mobile client are wrapped as BDoc messages in DCOM calls. These DCOM calls are transformed into remote function calls (RFCs) on the communication station to be further processed by the CRM Middleware. The similar way vice versa holds true for data packages that are received by mobile clients. Mobile Client The Mobile Clients are usually notebooks or Tablet PCs where the application component, e.g. SAP CRM Mobile Sales, is installed. The application works on a local user database (UDB) in offline mode and the user exchanges data on a regular basis with the CRM Server using the communication station (see above). Also software upgrades are sent to mobile clients using the same mechanism. Mobile Repository Server The Mobile Repository Server is part of the mobile development environment and hosts the Mobile Application Repository (MAR). In the MAR all application meta-data, like business objects, business queries, tiles, tile sets, etc. are stored. Mobile Development Workstation On the Mobile Development Workstation (MDW) the Mobile Application Studio (MAS) is installed. The MAS is integrated with Microsoft Visual Studio .NET and acts as the design environment for mobile applications. The MAS connects to the MAR via ODBC and provides visual modeling tools as well as code generators to generate the application runtime files (e.g. , *.dat, *.vb, *.dll, etc. ) from the meta-data. Whenever new runtime files are created, an upgrade package can be sent to the CRM Server and distributed to the mobile clients using the CRM Middleware.
10
Content


Further Information
11
Data Distribution: Publish and Subscribe Concept

Star-like data distribution to mobile sites Publish and subscribe concept:
Sites have to subscribe to publications to receive data
Predefined industry-specific patterns for data replication provided by SAP Replication model, which can be adapted to customer-specific needs
CRM Server with CRM Middleware CDB
Mobile Sites / Clients
A B
Every mobile client has to be identified as a logical site within the system. Every site is a potential sender and receiver of data. The data on every mobile site is a subset of data present in the Consolidated Database (CDB) on the CRM Server. The data distribution mechanism follows a Publish & Subscribe approach. This means, the information HOW data can be distributed is by default already present in the system (Replication Objects and Publications); to determine which mobile site should actually receive which data requires the creation of Subscriptions. By creating a subscription and assigning it to a mobile site, the system knows what data records have to be sent to this site. SAP delivers predefined replication models, meaning Business Document (BDoc) Type definitions, Replication Objects and Publications. However, the replication model can be adapted to the specific needs of a customer. For more details refer to section Server side customizing process.
12
Data Synchronization
Mobile Clients Communication Station CRM Server with CRM Middleware
UDB UDB UDB ConnTrans Message Transfer Service .NET Connector from SAP Mobile Client Adapter
Data Access Layer
CDB
Client Outbound Queue

Data Package (Business Document BDoc Messages)
Server Inbound Queue

Data Package (BDoc Messages)
Client Inbound Queue

Server Outbound Queue

Data synchronization between mobile clients and the CRM Server: Every write operation on the mobile client user database which changes existing data, creates new data or deletes data, also places a respective BDoc message in the client outbound queue. A BDoc message contains the (delta) information about the data object (e.g. a sales order) along with the action performed on this data object (e.g. changed delivery date). Thus, the CRM Middleware later on knows what action(s) have to be executed when the BDoc message is received by the CRM Server. To synchronize data with the CRM Server, the mobile user starts the synchronization process using the Connection and Transport Handler ConnTrans. ConnTrans establishes a dial-up connection and uses the Message Transfer Service to send BDoc messages from the mobile client to the CRM Server and to receive BDoc messages from the CRM Server. On the Communication Station, the SAP .NET Connector takes care of transforming the DCOM calls, in which the BDoc messages are wrapped, into RFC calls, which can be processed by the CRM Middleware. The Mobile Client Adapter is the part of the CRM Middleware which takes care of processing BDoc messages from and to mobile clients. Sending software upgrades to mobile clients uses the same mechanism. Upgrade packages are wrapped in a certain type of BDoc message to be sent to the mobile clients.
13
Content


Further Information
14
System Administration: Administration Console

Centralized administration using the administration console Management of the following:
Subscriptions Sites Device users
Automated generation of the following:

Subscriptions Sites
The central tool for mobile system administration is the Administration Console on the CRM Server. Mobile sites are maintained with the Administration Console as well as subscriptions and other organizational data. Site and subscription maintenance can be automated using generation facilities. The other entities relevant to the replication model, replication objects and publications, are also maintained in the Administration Console. Further details are explained in section Server side customizing process.
15
System Monitoring: CRM Middleware Monitoring Cockpit Centralized monitoring using the CRM middleware monitoring cockpit Displays status and information about the following:
Generation
BDoc types Replication objects Publications
Runtime
Message processing and tracking Inbound and outbound queues Replication and realignment services
Data synchronization Performance statistics System settings Background jobs

The central tool for mobile system monitoring is the CRM Middleware Monitoring Cockpit on the CRM Server. This tool provides a comprehensive overview of the whole system status. It displays generation information for various meta-data, like BDoc Types, runtime information, like queue statuses and adapter statuses, and other relevant system information.
16
System Monitoring: Alerts

Integrated proactive alert monitoring
If an alert is raised, the alert monitoring framework (CCMS) does the following:
Sends an e-mail or pager message to notify an administrator Executes a program that takes corrective measures
Situations that raise alerts include the following:

Messages in error state Messages for which a back-end feedback exceeds a certain time Queues in error state (for example, broken connection to back end, queues not registered, queues on hold, queue demon stopped) Amount of queue entries exceeding a certain threshold (for example, if mobile users do not synchronize regularly)
The Computing Center Management System (CCMS) is used to handle alerts. The system administrator can define what actions should be performed in different alert cases. Situations that will raise alerts are e.g. BDoc messages in an error state or exceeded time limits.
17
System Monitoring: CRM Data Integrity Manager

Ensuring data consistency using the CRM data integrity manager
SAP CRM
Cross-component comparison and synchronization of business objects at the following levels:

Object instance Field
Synchronize Compare
mySAP ERP Back End
CRM internal data comparison between the following:

CRM application database Consolidated database (CDB)
In order to ensure data consistency accross the various involved systems and databases in the distributed landscape, the CRM Server provides a tool called CRM Data Integrity Manager (DIMA). With the DIMA two databases can be compared and synchronized in case the data have become out of sync.
18
Content


Further Information
19
Server-Side Customizing Process: Facilities

The CRM server provides tools that allow you to model the following:
Mobile data distribution (replication model)
Based on publish and subscribe Fully declarative (100% code free)
Definition of replication criteria Definition of complex object dependencies (1:n, n:m relations)
Predefined industry-specific patterns available
Mobile persistence and synchronization layer

Mobile client schema definitions Business document (BDoc) type definitions
The CRM adapter framework provides user exits that allow the following:
Customizing the default data exchange between CRM server and mobile clients
For example, new/changed business objects, properties, and so on
Implementation of new business processes

In order to tailor CRM Field Applications to the special needs in a certain customer case, various adaptations might have to be made. The facilities on the CRM Server are the following:
Customizing the replication model Following the publish & subscribe concept, every customer can adapt the data distribution logic within his CRM system according to his special requirements. Although SAP delivers predefined replication patterns, the customer can make changes to these patterns or add own patterns. All these customizing steps a pure modeling and require NO coding. Customizing mobile client schema- and BDoc Type definitions The CRM Field Applications come with a standard data structure (tables, BDocs, mappings), which can be adapted by the customer. Implementing user exits The CRM Adapter framework provides various user exits which allow the customer to change or enhance the standard business logic of the CRM system.
Besides the adaptations on server side, it might be neccesary to customize the application, running on the mobile clients, also. Please refer to section Client side customizing process for more details.
20
Server-Side Customizing Process: Replication Model

1 BDoc Type 1:1 relation Replication Object Assign a replication object (including replication type) to a BDoc type Determine and assign possible criteria fields 2
Publication Publication
Model publications by specifying certain combinations of criteria fields (including operators)
3 Subscription Subscription Subscription Model or generate subscriptions by specifying actual values for each criteria field used in the publication
SiteID
SiteID
SiteID
Assign subscriptions to sites
Steps to define the replication for a certain business object (BDoc type, e.g. business partners): Step 1: Create a replication object for a BDoc type and specify the replication type, e.g. bulk, intelligent, dependent, etc. For an intelligent replication object, you also have to specify potential criteria fields for distribution. Step 2: Create one or more publications for a replication object. For a publication you can specify which criteria fields from the replication object can be used and with which operators (e.g. country with operator = and ZIP code with operator between, meaning a range of zip codes). Dependent replication objects need to be assigned to a dedicated publication only if they have additional criteria fields (-> intelligent dependent replication), otherwise they are distributed with their parent replication object. Step 3: Create (or generate) subscriptions from publications by specifying actual values for the criteria fields defined in the used publication. Step 4: Assign a subscription to one or more sites. Such a subscription site assignment clearly defines what data sets have to be distributed to a certain site.
21
Server-Side Customizing Process: Administration Console

Example publication:
Customer BDoc type:
CAPGEN_OBJECT_WRITE
Replication object:
CAPGEN_OBJ_WRITE
Criteria fields: COUNTRY (Operator EQ)
POST_CODE1 (Operator BT)

Intelligent replication Some dependent replication objects
This example shows the publication Customer & Prospects (by Country + ZIP Code) Its a publication for distributing Business Partners. The underlying BDoc Type is CAPGEN_OBJECT_WRITE, the respective meta description of a business partner in the CRM system. The choosen criteria fields for this publication are COUNTRY and POST_CODE1. Both criteria fields are part of the Address Segment, BPADDRESS_OBJECT, of BDoc CAPGEN_OBJECT_WRITE. Business Partners are distributed by intelligent replication, because the corresponding replication object CAPGEN_OBJ_WRITE is of type intelligent, meaning it has defined replication criteria fields. Two of them are the choosen ones (country and post_code1) for this special publication. Business Partners have some dependent objects which follow in distribution (e.g. CUST_MAT_INFO).
22
Server-Side Customizing Process: BDoc Modeler

Example BDoc type:
Customer BDoc type:
CAPGEN_OBJECT_WRITE
Root segment:
CAPGEN_OBJECT
Associated table:
(SMO)KNA1
Address segment:
BPADDRESS_OBJECT
Associated table:
(SMO)ADRC
Segment field containing, for example, the customer number:
KUNNR
This example shows the definition of the meta data for business partners, the BDoc Type CAPGEN_OBJECT_WRITE, in the BDoc Modeler. The tree structure on the left hand side shows the BDoc structure with all segments and associated tables. On the right hand side the choosen view displays the segment fields for the address segment BPADDRESS_OBJECT. The primary key field, e.g., is SFAADRC. The field containing the customer number is KUNNR.
23
Server-Side Customizing Process: Summary

Design Time
ABAP Workbench -> Defining tables -> Implementing user exits BDoc Modeler -> Modeling BDocs Administration Console -> Modeling replication objects, publications, subscriptions
Runtime
CRM Adapter Framework CRM Applications
Message Flow
Realignment Services
Generator
Persistence Services
Metadata Repository
(BDoc types, replication objects, publications, subscriptions, message flow definitions)
Consolidated Database (CDB)
Summary of the server side customizing process The ABAP Workbench, the BDoc Modeler and the Administration Console are the main tools to model meta data which is stored in a repository. With the ABAP Workbench, tables can be maintained and user exits can be implemented. BDoc Types are modeled with the BDoc Modeler while the Administration Console is used to model the entities of the replication model. Runtime data is generated using the repository meta data. The definitions of the replication model are e.g. used to generate the realignment services. The CRM Adapter framework handles the initial data load and data requests from the CRM application database to the consolidated database (CDB) for mobile data. Additional components are:
The Mobile Bridge, which transforms CRM business data into a mobile specific format. The CRM Validation Service, which stores data sent from the mobile devices in the CRM application database.
All adapter framework components contain user exits that allow to enhance the existing data exchange between CRM and the CRM field applications.
24
Content


Further Information
25
Client-Side Customizing Process: Facilities

The Mobile Application Studio allows you to model:
Presentation layer
Screen elements
Tiles Tile sets Business components Applications
Business logic layer

Business objects and relationships Business queries Combo engines Business rules
Resources
String resources Custom resources
Splash images Button images Customer logos Other custom resources
Besides adaptations on the CRM Server in order to tailor CRM Field Applications according to customers needs, also adaptations of the application itself, running on the mobile clients, can be done. The tool which accomplishes this task is the Mobile Application Studio (MAS). The MAS provides the tools to model the screen elements of the application and the application business logic.
26
Client-Side Customizing Process: Architecture

Runtime
CRM Field Application Persistence and Synchronization Layer
User Database
Design Time
Business Logic Layer
Presentation Layer MAR

Mobile Development Workstation with Mobile Repository Server with Mobile Application Repository (MAR)
Mobile Application Studio (MAS)

The Mobile Application Studio (MAS) which is integrated with Microsoft Visual Studio .NET is the design environment to customize CRM field applications. CRM field applications, like e.g. SAP CRM Mobile Sales, are build in three layers, the User Interface Layer (UIL), which is the presentation layer for user inand output, the Business Object Layer (BOL), which contains the application business logic and the Business Document (BDoc) Layer, which is the persistence and synchronization layer. All elements (development objects) of the UIL and BOL are stored in the Mobile Application Repository (MAR) on the Mobile Repository Server. The MAS connects to the MAR and allows the user to model UIL and BOL elements using the various designers provided by the MAS. This means a user can change, add or delete screen elements, parts of the business logic, like e.g. business rules or object relationships, and so on. After the modeling step(s) the MAS user can generate source code using the build-in generators and other runtime objects in order to make the new modeled application behaviour available for application users. BDocs are not modeled using the MAS but using the BDoc Modeler on the CRM Server. Also the database table structures are modeled on the CRM Server. However, the correct table structures as well as the BDoc information have to be available on every mobile client to allow the application to run properly.
27
Client-Side Customizing Process: Summary

Design Time
Mobile Application Studio
Set of visual modeling tools to model, for example, screen elements and business objects
Runtime
CRM Field Application
User Interface Layer
Other Systems Business Object Layer

Screen Elements Business Objects
Application Repository Interface
BDoc Layer
Synchronization
Generator
CRM Server with CRM Middleware
Mobile Application Repository
Source code (*.vb) Executables ( *.dll) Runtime metainformation (*.dat) etc.
UDB
CDB
Summary of the client side customizing process Design Time: The Mobile Application Studio (MAS) integrated with Microsoft Visual Studio .NET provides the design environment to model development objects, like e.g. screen elements, which are stored in the Mobile Application Repository (MAR). The Application Repository Interface provides the interface to the MAR and defines the MAS logic and rules. A generator which is integrated in the MAS generates the various runtime files from the meta-data in the MAR. Some important runtime files are: UIL: MS<X>.dll (e.g. MSA.dll): application user interface behaviour *.dat files: runtime meta-information of all interaction components *.loc files: language specific texts for interaction components, controls and framework messages BOL: sfabol.dll: application business logic ArsRep.dat: runtime meta-information of all BOL entities and BDocs MsgInfo<language>.dat: language specific information of all string resources Runtime: The CRM field application consists of three layers, the User Interface Layer (UIL), the Business Object Layer (BOL) and the BDoc Layer (BDL). The UIL contains the graphical user interface, the BOL contains the application business logic and the BDL, in connection with the data access layer (DAL) part of the BOL, provides read / write access to the user database and synchronizes data with the CRM Server via the CRM Middleware. 28
Content


Further Information
29
Transport of Metadata / Development Objects

Development Quality Assurance
Transport Order
Middleware Metadata; User Exit Implementations
Production
Transport Order
Middleware Metadata; User Exit Implementations
CRM Server DEV
Transport Order
Change List with Development Objects
CRM Server QUAL
Transport Order
CRM Server PROD
Attach Change List to Transport Order
Import Change List
Import Change List
Transport Agent
Transport Agent
Transport Agent
MAR DEV
MAR QUAL
MAR PROD
Software logistics for Middleware Meta Data and source code, like user exit implementations, is accomplished by using the standard ABAP WebAS correction and transport system (CTS). The import of the Middleware Meta Data triggers the generation of the runtime components automatically within the target system. Subscriptions are not transported, but have to be created in every system. Software logistics of development objects which are stored in the Mobile Application Repository (MAR), meaning transport of change lists from one system to another (e.g. DEV to QUAL), is also accomplished using the CTS. The MAS user works on certain development objects in the context of a change list. When the development is finished, the changes have to be transported to the quality assurance system in order to test them. Therefore, the change list is attached to a transport order and released. The Transport Agent running on the DEV Mobile Repository Server sends the change list from the DEV MAR to the DEV CRM Server. From there the change list is transported to the QUAL CRM Server and imported into the QUAL MAR. In a similar way, the change list is transported to the PROD CRM Server and imported into the PROD MAR. The application runtime objects, however, have to be generated in each of the three systems (DEV, QUAL, PROD) seperately and distributed to the mobile clients (see next slide).
30
Software Deployment
Mobile Development Workstation Mobile Repository Server CRM Server with CRM Middleware
Client Outbound Queue Mobile Upgrade Package (*.mup)
Runtime Object Change List Mobile Upgrade Package (*.mup)
Runtime Object Change List Mobile Upgrade Package (*.mup)
Mobile Application Studio (MAS) Generator

Upgrade Script (*.rbn)
MAR
Transport Agent
Data Package
Runtime Objects
Mobile Upgrade Console

Data Package
Mobile Upgrade Package (*.mup)
Mobile Clients
UDB UDB UDB
Client Upgrade Service
Communication Station
The upgrade process for mobile clients is similar in all three systems (Development, Quality Assurance and Production). In the first step all necessary application runtime files must be generated from the metadata in the Mobile Application Repository (MAR) and must be present on the (Master) Mobile Development Workstation (MDW). The Mobile Upgrade Console, installed on the MDW, is then used to create a Mobile Upgrade Package using an Upgrade Script. An Upgrade Script contains a complete description of an upgrade and consists of Upgrade Units. Upgrade Units contain information about files, folders and commands that need to be executed on mobile clients when changes have been made to the mobile client application. The Mobile Upgrade Package is stored in a change list on the MAR and is transported, as are other change lists containing meta-data, to the CRM Server. Mobile Clients must subscribe to a specific publication, similar to subscribing to business data, in order to receive the Mobile Upgrade Package. The Mobile Upgrade Package is wrapped in a special type of BDoc Message and transferred to the Mobile Clients when they connect to the CRM Server via the Communication Station. The Client Upgrade Service running on the Mobile Client automatically executes the Upgrade immediately upon receipt. If there is only a low-bandwidth network available, such as a telephone line, the Mobile Upgrade Package can be shipped on a CD. In this case, only a trigger to execute the upgrade is sent via the CRM Middleware / BDoc mechanism.
31
Content


Further Information
32
Further Information
Online Knowledge Products SAP Service Marketplace http://service.sap.com/okp SAP CRM 2005 Learning Maps SAP Service Marketplace http://service.sap.com/rkt-crm > SAP CRM 2005 Online Documentation Help Portal http://help.sap.com/ > Documentation > mySAP Business Suite > SAP Customer Relationship Management
Important areas in the online documentation:

Help Portal http://help.sap.com/ > Documentation > mySAP Business Suite > SAP Customer Relationship Management Field Applications SAP CRM Powered by SAP NetWeaver > Process Integration > CRM Integration Services > CRM Middleware SAP CRM Powered by SAP NetWeaver > Application Platform > CRM Mobile Technology
Further helpful quick-links on the SAP Service Marketplace:

\CRM-FIELD-APPLICATIONS \CRM-MW \NW-MOBILE > Mobile Client Technology (mySAP CRM)
33
Copyright 2005 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.
34

CRM FieldApp Customizing

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CRM FieldApp Customizing

Uploaded by

Copyright:

Available Formats

Overview Presentation:

Operating and Customizing Field Applications in SAP CRM

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

Field Applications in SAP CRM

Mobile sales and mobile service are based on the following:

SAP AG 2005, SAP CRM 5.0 Field Applications, 3 of 34

Challenges in Field Applications

SAP AG 2005, SAP CRM 5.0 Field Applications, 4 of 34

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

mySAP CRM Powered by SAP NetWeaver

SAP NetWeaver Mobile

SAP AG 2005, SAP CRM 5.0 Field Applications, 6 of 34

CRM Middleware: Facts

Cross-component system administration and monitoring Back-end integration Groupware integration

SAP AG 2005, SAP CRM 5.0 Field Applications, 7 of 34

Mobile .NET Client: Facts

SAP AG 2005, SAP CRM 5.0 Field Applications, 8 of 34

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

SAP CRM System Landscape: Mobile Scenario

Mobile Clients with CRM Field Application

CDB CRM Server with CRM Middleware

Mobile Development Workstations with Mobile Application Studio (MAS)

Mobile Development Environment

Permanent communication facilities Temporary dial-up facilities

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

Data Distribution: Publish and Subscribe Concept

CRM Server with CRM Middleware CDB

Mobile Sites / Clients

SAP AG 2005, SAP CRM 5.0 Field Applications, 12 of 34

Data Access Layer

Client Outbound Queue

Server Inbound Queue

Client Inbound Queue

Server Outbound Queue

SAP AG 2005, SAP CRM 5.0 Field Applications, 13 of 34

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

System Administration: Administration Console

Automated generation of the following:

SAP AG 2005, SAP CRM 5.0 Field Applications, 15 of 34

Data synchronization Performance statistics System settings Background jobs

System Monitoring: Alerts

Situations that raise alerts include the following:

SAP AG 2005, SAP CRM 5.0 Field Applications, 17 of 34

System Monitoring: CRM Data Integrity Manager

Cross-component comparison and synchronization of business objects at the following levels:

mySAP ERP Back End

CRM internal data comparison between the following:

SAP AG 2005, SAP CRM 5.0 Field Applications, 18 of 34

Operating Field Applications in SAP CRM

Customizing Field Applications in SAP CRM

Server-Side Customizing Process: Facilities

Predefined industry-specific patterns available

Mobile persistence and synchronization layer

Implementation of new business processes

Server-Side Customizing Process: Replication Model

Model publications by specifying certain combinations of criteria fields (including operators)

Assign subscriptions to sites

SAP AG 2005, SAP CRM 5.0 Field Applications, 21 of 34

Source code (.vb) Executables ( .dll) Runtime metainformation (*.dat) etc.