ipc40_configsupp_v202

Configuration Support

SAP IPC 4.0

Document Version 2.02 July 17th, 2003

SAP AG Neurottstrae 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

JAVA is a registered trademark of Sun Microsystems, Inc.

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

JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, 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. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One. All other product and service names mentioned are the trademarks of their respective owners.

Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation.

ORACLE is a registered trademark of ORACLE Corporation.

INFORMIX-OnLine for SAP and Informix Dynamic

ServerTM are registered trademarks of IBM Corp. Documentation in the SAP Service Marketplace

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

You can find this documentation at the following address: http://service.sap.com.

Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

Additional Contacts: Not yet available.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology.

Typographic Conventions Icons

Type Style Represents

Example Text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.

Cross-references to other documentation

Example text Emphasized words or phrases in body text, titles of graphics and tables

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, source code as well as names of installation, upgrade and database tools.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or the ENTER key

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Document History The following changes were integrated since Version 2.01 (July 11th 2003) of this document:

Version Number Chapter Change Short Description

2.02 3 Product Variants Updates in sections

3.1 General Search Settings 3.2 Product-Model-Specific Settings

4.3.1 Overview 36 Table of Contents 4.3.2 Parameters, XCM Components, XCM

Scenarios 37 4.3.3 Default SAP XCM Scenarios 39 4.3.4 Creating Own Components and Scenarios 39

1 INTRODUCTION 6 1.1 About this Guide 6 4.3.5 Folder structure 40

4.3.6 Request parameters versus XCM settings 40

1.2 Related Documentation 7

4.3.7 IMG Customizing versus XCM settings 40 2 IPC ADMINISTRATION AND MONITORING 9

4.3.8 Configuring IPC for CRM Online 41 4.3.9 Which Scenario Does the IPC Use? 42 4.3.10 What Happens If I Pass A Wrong Scenario Name? 42 2.1 IPC Administrator 9

2.2 IPC Dispatcher Load Balancing 9 4.4 Model-Specific UI Settings 42 2.2.1 Scalability with IPC Dispatcher 9 4.4.1 Overview 42 2.2.2 Setting up the IPC Dispatcher 12 4.4.2 Defining Parameter Sets for Product

Families 43 2.3 IPC Server 15 4.4.3 How does the IPC Know How To Select My UINAME configuration? 43 2.4 IPC Data Loader 16

2.5 IPC Logging 16 4.5 Control Parameters 44 4.5.1 Connection Parameters 44 2.6 Monitoring and CCMS Integration 19 4.5.2 Central Information 46

2.7 IPC Enhanced Settings 21 4.5.3 ipcScenario and caller 48 2.7.1 Modifying IPC Services 21 4.5.4 Overview of Pricing Parameters 49 2.7.2 Starting Multiple Servers 23 4.5.5 Settings related to the Struts Framework 51 2.7.3 Multiple IPCs on one Host 24 4.5.6 Client/Server Communication 52 2.7.4 IPC Command Line Interface 26 4.6 UI Parameters 53 2.7.5 Registration of New IPC Commands 27

4.6.1 Overall Appearance 53 4.6.2 Presentation of Characteristics and Values 54 3 PRODUCT VARIANTS 28 4.6.3 Characteristic Groups 56 3.1 General Search Settings 28 4.6.4 Buttons 57

3.2 Product-Model-Specific Settings 29 4.6.5 Multi-Function Area 59 4.6.6 Conflict Handling 61 4.6.7 Message Area 63

4 CONFIGURATION USER INTERFACE 33

4.6.8 Other Parameters 64 4.6.9 Parameters not Described 64

4.1 Introduction 33 5 IMAGE INTEGRATION 65 4.2 Architecture 34

5.1 Static Images 65 4.2.1 Basics on HTTP Communication 34 4.2.2 Where parameter Values are Set 35 5.1.1 Document Replication 66

5.1.2 Properties File for Image Assignment 70 4.3 Extended Configuration Management 36 5.2 Dynamic Product Images 72

Configuration Support: SAP IPC 4.0

1 Introduction

1.1 About this Guide This document is written for system administrators who are maintaining one or several SAP Internet Pricing and Configurator (SAP IPC) systems. The document fits in between the pure technical system installation guides and the application documentation for SAP Pricing, Taxing and Product Configuration (see section 1.2 Related Documentation). Due to the technical necessity of maintaining (some parts of) application-related settings directly at the IPC system, some sections may also be of interest for product modelers in the application area.

It is assumed that readers are familiar with the (scenario-dependent) system landscape SAP IPC is embedded into and basically know how standard system maintenance with SAP IPC is done. The document includes information on advanced system settings. For more information about the architecture of SAP IPC see Installation Guide SAP IPC 4.0 Server.

This document does not provide information for programmers who are involved in software extension or modification projects. Readers interested in programming with SAP IPC should consult the HTML documentation provided with the file system of SAP IPC at 1/ipc/doc (including the Application Programming Interface API documentation).

This document is split into the following sections:

Chapter 2 IPC Administration and Monitoring: This chapter is directed to experienced system administrators. It is relevant for any integration scenario of SAP IPC and it gives background information on the advanced administration of the IPC Dispatcher and the IPC Server, it introduces the logging mechanism of SAP IPC, and references to information on monitoring SAP IPC with CCMS.

Chapter 3 Product Variants: This chapter is directed to system administrators and product modelers. It is relevant for business scenarios applying product variants (in the context of product configuration). It explains how to adjust the product variant search parameters with SAP IPC.

Chapter 4 Configuration User Interface: This chapter is directed to system administrators who need to adjust the user interface for interactive configuration in various application contexts and for several complexity classes of configurable products. Product modelers will help to define properties of user interfaces for interactive configurations that are project- or product-class-specific.

Chapter 5 Image Integration: This chapter is directed to system administrators and product modelers. It is relevant for business scenarios applying interactive product configuration. It explains how to integrate images with interactive product configuration based on SAP IPC.

1 is the directory where SAP IPC is installed on the file system.

6 Version 2.02, July 17th, 2003


Before you read this guide check for updated versions at the following location: http://service.sap.com/crm-inst SAP CRM 4.0

1.2 Related Documentation The SAP IPC 4.0 Configuration Support includes references to various documents that readers should have at hand when reading this document. The following list includes the most important related documents (including information on how to get them):

SAP IPC 4.0 Server Installation Guide: the latest version is available at the SAP Service Marketplace under http://service.sap.com/crm-inst CRM 4.0.

SAP IPC 4.0 Web Applications Installation Guide: the latest version is available at the SAP Service Marketplace under http://service.sap.com/crm-inst SAP CRM 4.0.

HTML documentation provided with the file system of SAP IPC: the version matching your IPC is available with the installation of SAP IPC 4.0 in the doc folder of the installation directory (/ipc/doc/index.html). This documentation includes various hints for SAP IPC system administrators and the API documentation of SAP IPC for programmers.

Application documentation for mySAP CRM 4.0: the application documentation of components basing on SAP IPC are integrated with the application documentation of mySAP Customer Relationship Management (mySAP CRM).

The latest version is available at the SAP Help Portal under http://help.sap.com mySAP.com Cross-Industry Solutions mySAP Customer Relationship Mgmt select release and language The sections closely related to SAP IPC are included in the chapters

o Application Services Application Engines Product Configuration o Application Services Master Data Products Modeling Configurable

Products.

Application documentation for SAP R/3: many application scenarios of SAP IPC are based on master data from SAP R/3. More information on master data maintenance with SAP R/3 can be found in the application documentation of SAP R/3.

The latest version is available at the SAP Help Portal under http://help.sap.com SAP R/3 and SAP R/3 Enterprise SAP R/3 Enterprise Release 4.70 select release and language

The sections closely related to SAP IPC are included in chapter

o SAP R/3 Enterprise Application Components Cross Application Components Classification (CA-CL), SAP R/3 Enterprise Application Components Logistics General (LO)

o SAP R/3 Enterprise Application Components Sales and Distribution (SD). CRM Master Guide 4.0: this document gives an overview of all CRM scenarios and

the components to be installed with the implementation of these scenarios; the latest version is available at the SAP Service Marketplace under http://service.sap.com/crm-inst SAP CRM 4.0.

Version 2.02, July 17th, 2003 7


SAP Notes: all available SAP notes you can find at the SAP Service Marketplace under http://service.sap.com/notes

Note 421480 IPC: Activating the IPC Server log

Note 502461 CRM: CCMS agent PlugIn for IPC

Note 521628 BOM explosion for configurable products

Note 524693 Item-dependent use of subitems

Note 535658 Characteristics cannot be filtered by org areas

Note 5553512 UI-Einstellungen in der Mobile Sales Integration

Note 556883 IPC: com.sap.sxe.sys.exc.SXEIllegalArgumentException: EA

Note 612570 IPC: Usage of dynamic port number

Information on SAP System Monitoring and Alert Management: all relevant information on system monitoring and alert management is accessible at the SAP Service Marketplace under http://service.sap.com/monitoring

CRM Monitoring Installation Guide: information on how to set-up monitoring of mySAP CRM components; the latest version is available at the SAP Service Marketplace under http://service.sap.com/crm-inst SAP CRM 4.0

CCMS Agents: Properties, Installation, and Operation: information on how to set-up a CCMS agent on an IPC system; the latest version is available at the SAP Service Marketplace under http://service.sap.com/~sapidb/011000358700003240702001E

The Apache Jakarta Project Struts: general information on the Struts framework (that is base of the SAP IPC Web application for interactive product configuration) can be found on the public Web site under http://jakarta.apache.org/struts.

2 While writing this document the note was not yet translated into English.



2 IPC Administration and Monitoring This chapter is directed to experienced system administrators. It is relevant for any integration scenario of SAP IPC and it gives background information on the advanced administration of the IPC Dispatcher and the IPC Server, it introduces the logging mechanism SAP IPC, and references to more information on monitoring SAP IPC (preferably with CCMS).

It is assumed that readers are familiar with the SAP IPC system (see SAP IPC 4.0 Server Installation Guide, http://service.sap.com/crm-inst) and the architecture of the complete system landscape (for more information about potential system landscape architectures see CRM Master Guide 4.0 on the SAP Service Marketplace).

You should have an installation of SAP IPC at hand while reading this chapter.

2.1 IPC Administrator For information about how to work with the SAP IPC Administrator see SAP IPC 4.0 Server Installation Guide.

Basically the IPC Administrator is used to maintain standard settings. For more sophisticated, non-standard settings you need to directly edit the parameters file of the IPC Server (for more information see section 2.3 IPC Server).

2.2 IPC Dispatcher Load Balancing To support load balancing, SAP IPC includes the IPC Dispatcher. The IPC Dispatcher allows several IPC servers (that run on the same machine or on different machines) to register, and will distribute IPC sessions evenly among these servers. The dispatcher cannot be used to implement high-availability scenarios, because it would be a single point of failure.

2.2.1 Scalability with IPC Dispatcher If you use the SAP Internet Pricing and Configurator and have more than one SAP IPC Server, the IPC Dispatcher manages IPC sessions to ensure an efficient distribution of sessions between the different servers. When pricing or configuration functions are called from an IPC client (such as CRM Online Application or Internet Sales session), the IPC Dispatcher determines the IPC Server with the fastest response times, and sets up the connection between client and server accordingly. (Each IPC client requires exactly one session on a server.)

Integration The IPC Dispatcher is a standard part of the IPC installation and can be used with its

default settings.

Even if you have a small IPC installation with only one IPC Server, we advise you to leave the dispatcher enabled because: System administration is easier if you want to add more servers to your

installation at a later date.



Communication between clients and one server via the dispatcher is only marginally slower than direct communication between the client and server.

Figure 1 shows the communication sequence between the IPC client, IPC Dispatcher, and IPC servers.

1. Whenever a server starts, the server is registered with the dispatcher.

2. Whenever an IPC client requires a session, a request for a server is sent to the dispatcher.

3. The dispatcher determines which IPC servers are registered, selects the server with the fastest response times, and sends the address of this server (host and TCP/IP port) to the client.

4. The client sends a request for an IPC session to the server.

5. The server opens a session and sends a session ID to the client.

Each subsequent command from the client goes directly to the server and is executed on the server, until the session is closed (by either the user or a timeout).

Figure 1: Communication between IPC Clients, IPC Dispatcher, and IPC Servers

Prerequisites You have not disabled the dispatcher.

Features You can set up your servers to respond to session requests according to the following criteria:

Type of IPC client R/3 client User



If you use this option, the dispatcher first determines which servers are registered that match the criteria, and then selects the server with the fastest response times.

Activities You can use the IPC Dispatcher as it is delivered, but you can configure your installation to match any specific requirements. When setting up an installation that uses the IPC Dispatcher, you must proceed in the following sequence, even if you do not require all steps:

1. Configure the dispatcher. (If the default port number 4444 is used by another application, you can change the port number.)

2. Configure the connection to the dispatcher on all IPC servers, using the local administration tool.

3. Re-start the dispatcher and server(s) by first stopping and then starting them again:

Windows Re-start the IPC services SAP IPC Dispatcher and SAP IPC Server using the service panel: Start Settings Control Panel Administrative Tools Services.

Unix As user ipcadm:

If you have started the dispatcher or a server in its own terminal window (by executing /bin/dispatcher.sh or /bin/server.sh)you can stop it there by pressing .

If you are using IPC 3.0 SP14 or higher and you have started the IPC running ./ipcdispatcher start in /bin and ./ipcserver start /bin:

o To stop the IPC Dispatcher run ./ipcdispatcher stop in /bin

o To stop the IPC Server(s) run ./ipcserver stop in /bin

To start the IPC Dispatcher run ./ipcdispatcher start in /bin

To start the IPC Server(s) run ./ipcserver start in /bin As default one IPC Server will be started. To start more than one server you have to change the ipcserver file. Open it with an editor (for example vi) and look for the following line: SERVER_COUNT=1 Adapt it according to the required number of servers. Normally the number of servers has to correspond to the parameter rfcServerCount in file /lib/properties/dispatcher.properties. If you did not change the rfcServerCount parameter you also do not need to change SERVER_COUNT.



Running ./ipc start in /bin can be used as an alternative to start them all, IPC Dispatcher and IPC Server(s).

Problems at start up will be logged into a number of *.log files placed in /bin.

4. Use an administration tool (either local or remote) to configure complete settings for

one IPC Server, and broadcast the configuration to all other IPC servers.

If required, you can then configure individual IPC servers differently.

2.2.2 Setting up the IPC Dispatcher

General Depending on your application, you can influence the behavior of the IPC Dispatcher. Most of the properties are contained in the file /ipc/lib/properties/dispatcher.properties. Since the IPC Dispatcher is only a specialized IPC Server, some of the settings in the server panel of the IPC Administrator also influence the IPC Dispatcher.

For an explanation of the settings you can perform in dispatcher.properties, consult the HTML documentation provided with the file system of SAP IPC, /ipc/doc/index.html see section Setting-up the IPC Dispatcher. The following settings in the IPC Administrators server panel influence the IPC Dispatcher:

Dispatcher enabled: This setting should not be unchecked; in all standard scenarios, the IPC Dispatcher is a mandatory component.

Dispatcher Port: the TCP/IP port that is used by the IPC Dispatcher for IPCs native protocol. If you install IPC Servers on several computers, the settings Dispatcher Host and Dispatcher Port have to be consistent among all servers.

Encoding: Like the dispatcher port, this setting has to be consistently set up for all servers and the dispatcher. It is not recommended to change this setting.

Remote Administration: applies to IPC Dispatcher like to other IPC servers. Edit Logging Properties: In the panel that opens when you press this button, the

settings beginning with log[Dispatcher] define the IPC Dispatchers logging behavior. You may also want to change /Dispatcher.severity and /Dispatcher/JCO.severity to adjust how much information is logged by the dispatcher in general and by its RFC connectivity component (JCO) in particular.

Dispatcher sessions are typically running a single IPC command, the IPC Dispatchers session timeout is hard-coded to be one minute. There is no way to change this setting.

The IPC Dispatcher can be monitored with CCMS (see below) or with the IPC monitor (described in the HTML documentation provided with the file system of SAP IPC, /ipc/doc/index.html see section The debug guide, subsection Using the IPC Monitor). The monitors functionality has not changed in 4.0.



The subsequent sections describe the following options for configuring the environment of the IPC Dispatcher to suit your specific requirements:

Assigning IPC servers to specific IPC clients Using fixed server ports Disabling the dispatcher

Assigning Servers to Clients The following attributes are supported by the IPC clients.

Attribute Attribute Values Description

type IPC, PME, ISA, CRM, ADM Allowing you to differentiate between the following session types:

IPC: Internet Pricing and Configurator PME: Product Modeling Environment ISA: Internet Sales CRM: CRM Online Application ADM: Administrative tasks

You can always run the IPC Monitor on any server you choose, even if you define only one server for administrative tasks.

client Allowing you to differentiate between, for example, test client and productive client.

userName Allowing you to use one IPC Server for testing and another for productive mode.

userLocation User locations can, for example, be different system names, IP addresses, or host names. For example, this allows you to use specific IPC servers for different application servers.

In the standard installation, all IPC servers support sessions for all IPC client attributes. To assign IPC servers to specific client attributes, edit property ATTRIBUTES in the file ipc/lib/properties/dispatcher.properties in your IPC installation. Some examples are shown below.

ATTRIBUTES = type:PME,IPC,ISA,CRM,ADM The dispatcher uses different IPC servers for each type of session. If less than four servers are registered, as many as possible are given specific tasks (PME only), and one deals with all other sessions. If more than four servers are registered, the servers are distributed evenly between the four types of sessions.



ATTRIBUTES = client:100,200,*

The dispatcher assigns servers to R/3 clients. Client * means any other client.

ATTRIBUTES = type:PME,IPC,ISA,CRM;client:100,200,* The dispatcher first uses the type of session, and then the R/3 client, to assign servers.

ATTRIBUTES = type:PME=1,IPC=10,ISA=3,CRM The dispatcher assigns 10 of 15 servers to IPC, one server to PME and CRM, and three servers to Internet Sales.

Using Fixed Server Ports The default setting of the IPC Server uses one of the pre-defined TCP/IP port numbers for network communication.

When an IPC Server starts up, it checks each port in the list in sequence; the first free port number will be used. If it reaches the end of the list without finding a free port, it allocates a random port.

The list of port numbers to be used by the IPC Server can be changed:

1. Start the Administrator program.

2. Navigate to the Server section.

3. Enter a list of IP addresses. Especially if there is a firewall between server and client, you may need to use specific TCP/IP ports.

For a 4-processor system, you might enter: 9998,9999,9997,9996

It is strongly recommended NOT to use dynamic server ports. Otherwise depending on the sequence of starting up applications a port that is assigned to another (not yet running) application might be used by the IPC Server.

See SAP note 612570 for further information.

Disabling Dispatcher This is only relevant for small installations that only have one IPC Server and do not run a standard scenario like CRM Online or Internet Sales. Even in such cases, you may want to leave the dispatcher enabled (default setting) if you are planning to add additional servers to your installation. If you really want to disable the dispatcher, you need to make the following changes:

1. In the Administrator, disable the dispatcher in the Server section, and enter a server.

2. Inform all IPC clients that the partner port represents a server, not a dispatcher:

Make the following change in the file ipc/lib/properties/client.properties:



Default Attribute Change to Attribute dispatcher = true dispatcher = false

3. Restart the IPC Dispatcher and IPC Server.

For more information about setting up a connection between the IPC Dispatcher and CRM Online Application, see IPC 4.0 Server Installation Guide.

2.3 IPC Server The IPC Server is configured by the file /ipc/lib/properties/parameters.xml. You can maintain the most common settings of this file in the IPC Administrator. Advanced settings have to be performed by directly editing parameters.xml in a text editor. The following settings can be adjusted by maintaining a property in the section of the file.

RFC_THREADS: the number of RFC threads to install. Each RFC thread independently deals with RFC calls, i.e. with the users that use the IPC Server from a SAP CRM system.

RFC_IS_UNICODE: used to connect IPC to a Unicode SAP System. Make sure that the setting of this flag (true, false) corresponds to the unicode setting in IPCs RFC destinations that you have maintained in transaction sm59.

RE_REGISTER_TIME: how long (milliseconds) the IPC Server waits until it contacts the IPC Dispatcher to tell it that it is still operational. This setting is necessary since, if you set the dispatchers serverDownTimeout (dispatcher.properties) to a relatively small value, a heavily loaded IPC Server that e.g. spends a long time with garbage collection will be treated as down by the dispatcher until it re-registers the next time.

SCE_KB_UPDATE_INTERVAL: controls how long IPC waits between checks if knowledge bases that it has buffered in memory are still the most recent version in the respective database tables. If you use no configurable products, please set this to 0 (disabled). If you use a lot of knowledge bases, you might want to increase this value, because every session that uses configurable products will be suspended while this knowledge base update is working.

Compared to previous IPC releases, some settings in parameters.xml are outdated: WORKER_THREADS, LISTENING_TIME: These settings are no longer

used with SAP IPC 4.0. Using it will not affect IPCs behavior in any way. LOG_MESSAGES, LOGFILE, DISPATCHER_LOGFILE,

DATALOADER_LOGFILE: these settings are replaced by the settings you can perform in /ipc/lib/properties/logging.properties which can be maintained in the IPC Administrator.

The IPC Server can be monitored with CCMS (see section 2.5 IPC Logging) or with the IPC monitor (described in the HTML documentation provided with the file system of SAP IPC, /ipc/doc/index.html see section Using the IPC Monitor).



2.4 IPC Data Loader The SAP IPC Data Loader is used for the replication of master data for pricing and product configuration from SAP R/3 to a local database of the SAP IPC Server.

The Data Loader is only included in scenarios that are not based on an SAP CRM backend, as for example SAP IPC Ready-to-Integrate, mySAP Automotive Vehicle Management System, or SAP Internet Sales R/3 Edition.

For information about how to work with the SAP IPC Data Loader see SAP IPC 4.0 Server Installation Guide (http://service.sap.com/crm-inst SAP CRM 4.0).

2.5 IPC Logging In case of problems with SAP IPC the logging information can be very helpful for problem analysis.

When opening an OSS message you can often shortcut the first iteration by attaching an appropriate log file to the message. Note 421480 describes how to activate the log for the IPC Server.

With SAP IPC 4.0 the logging has been altered as to adhere to the requirements of a server application:

Every IPC application writes its log files according to the same mechanism, so that you no longer need to search for information in several files (some with and some without timestamp)

Now a rotating log file schema is supported: log information is alternately recorded to a number of log files. You can choose the number and the maximum size of those log files. Thus you can determine the hard disk space occupied by the log files in advance.

You can determine the extent of logged information for every application and even for every application component (such as the Configuration Engine) individually.

All log settings can be changed in the running system. The logging API is the standard SAP Logging, so that the logging set-up and the

look-and-feel of the IPC log files no longer look different to for example the logging of Internet Sales.

Involved Files All logging settings are made in the file logging.properties during the IPC Installation (in lib/properties). The file can be edited in every text editor; the local IPC Administrator UI provides you with a (simple) editor as well. All IPC applications (such as Server, Data Loader, Dispatcher, IPC in Mobile Sales) are using this file in order to determine their own logging settings.

Categories The following categories are at your disposal to define your own log behavior:

1. Application Categories

/Server: IPC Server



/Dataloader: IPC Data Loader /Dispatcher: IPC Dispatcher /DesktopUI: IPC Desktop UI /MSA: IPC integrated in Mobile Sales /StdUI: SCE Swing UI (standalone) /Admin: IPC Administrator /PME: Product Modeling Environment (PME) /Unknown: all other applications

2. Sub Categories

The following categories can be used in all application categories:

Socket (such as /Server/Socket or /Dispatcher/Socket): Logs detailed information on IPC Server commands

JCO (such as /Server/JCO): Logs detailed information on RFC communication via SAP JCo (SAP Java Connector). This category is treated differently from the others: If you activate the log level DEBUG for this category, a "Level 10" JCO log is activated (this sub category is the only one that cannot be changed on a running server).

SCE (such as /Server/SCE oder /MSA/SCE): Logs messages of the configurator KB_LOADER: Logs messages of the knowledge base loader SCE/CBASE. Logs messages of product variant matching SPE: Logs messages of the Pricing Engine TTE: Logs messages of the Tax Transaction Engine Client: Logs messages of the IPC client LOG_API: Logs messages of the Log API (with which previously the

SXE_LOG.html was written)

LOG: Logs messages of a simplified Log API ENGINE: Logs messages of the PME engine KB_SAVER: Logs messages arising during knowledge base saving UI: Logs messages of the PME UI CRM_ADAPTER: Logs messages of the CRM adapter for PME, that means of

CRM parts called from the PME

Standard Setup IPC is delivered with two typical standard setups.

The file logging_productive.properties contains logging settings for productive use: only true errors and alerts are logged, thus saving performance.

The file logging_debug.properties contains logging settings for newly installed IPC applications: all IPC applications log maximum information in order to help identify errors and problems as quickly as possible. You can use this file

o In order to quickly find the reason for setup problems



o If you want to track an error

o If the SAP Support asks you to make a Debug Level log file that reproduces a problem

Note that when applying logging_debug.properties up to 90% (or even more) of the performance is used for logging, thus it is unsuitable for productive use.

The shipped logging.properties is identical to logging_debug.properties. Thus during the first start of the application you can track on whether the server boots correctly, and whether RFC destinations are maintained correctly.

For productive use logging.properties needs to be adjusted, for example via copying logging_productive.properties to logging.properties.

The standard setting writes the following log files:

IPC Server: /ipcserver.1.log - /ipcserver.4.log (2 MB max) IPC Dispatcher: /ipcdispatcher.1.log - /ipcdispatcher.2.log (1 MB

max)

IPC Data Loader: /ipcdataloader.1.log - /ipcdataloader.2.log (1 MB max)

PME: /bin/pme.1.log - /bin/pme.4.log (250 K max) TTE: /TTE.1.log - /TTE.2.log (1 MB max) Other applications: /ipcapplication.1.log - /ipcapplication.2.log (1 MB

max)

Where is the temporary (user) directory of your operating system, such as for example C:\Documents And Settings\Local Settings\TEMP, C:\TEMP, /tmp, /var/tmp, and is the directory of the IPC installation.

Logging on Multiple Servers The Windows and Unix services of the IPC support running multiple IPC servers on one machine. They are assigned their own application category in order to avoid them writing to the same log file. For example: server for the first server booted.

The shipped property files are already prepared to support up to four servers on the same machine. They log to the files /ipcserver..log.

If you want to run additional IPC servers on the same machine (which is not recommended), you need to define respective new categories and log files (for example by copying all lines of an already defined server).

Further Logging Adjustments The SAP logging used with IPC allows you to adjust

the type of messages that are logged the way messages are logged



the files messages are logged to

In order to be able to modify logging.properties you need to be aware of the following terms:

Category: A module creating log messages. You can configure your logging for every category Independently.

Log: Something log messages are written to, usually a file. Severity: Importance of log messages: the following severities are possible: FATAL,

ERROR, WARNING, INFO, DEBUG

Due to the fact that in IPC multiple applications are running at the same time, and all of them read their settings from logging.properties, every category logs its messages relative to an application category.

Category Examples /Server/SCE: here the configurator logs its messages when running on

the IPC Server. /PME/SCE: here the configurator logs its messages when used as

configuration simulation in PME.

Example If you want to track the communication between CRM and PME you can generate your own debug level log file for the category CRM_ADAPTER.

Insert the following lines in logging.properties: log[CRM] = FileLog log[CRM].pattern = ./crm.%g.log log[CRM].cnt = 4 log[CRM].limit = 2000000 log[CRM].formatter = TraceFormatter /PME/CRM_ADAPTER.logs = log[CRM] /PME/CRM_ADAPTER.severity = DEBUG

The first five lines define the logging location and the way messages are logged: In the current directory four log files are to be written (crm.1.log, crm.2.log, crm.3.log, crm.4.log); no file getting bigger than 2 million bytes. The final two lines associate this log with the category /PME/CRM_ADAPTER and define that this category logs all messages up to DEBUG messages.

2.6 Monitoring and CCMS Integration Managing distributed mySAP.com solutions or client-server systems place high demands on the system administration demands that increase significantly through the inclusion of the Internet in business processes. Using the monitoring architecture of the Computing Center Management System (CCMS), SAP provides a flexible and universally applicable



infrastructure, with which you can monitor the entire IT landscape centrally and which quickly and reliable reports problems that occur.

The monitoring architecture is delivered with every SAP Web Application Server with no additional costs and can be used immediately after installation. The architecture runs on all SAP Web Application Servers and can easily be extended with SAP and non-SAP components.

Measured values and alerts are displayed in the alert monitor (transaction RZ20) in various monitors, organized by topic. These monitors display the data in a tree structure in which the highest alert of a sub tree is reported upward. You can assign analysis and auto-reaction methods (automatic alert notification via e-mail, fax, page, ... or execution of operating system commands) to the alerts.

For more information see http://service.sap.com/monitoring.

The CCMS integration of SAP IPC 4.0 includes the following topics:

Configuration Data: Offering an overview on system configuration data (available for Early Watch Alert)

Heartbeat: Identifying system downtime Log File Monitoring: Standardizing centralized logging

The setup of monitoring is described in more detail in a separate document CRM Monitoring Installation Guide (SAP Service Marketplace: http://service.sap.com/crm-inst SAP CRM 4.0).

Additional information on monitoring SAP IPC in the CCMS environment is included in SAP note 502461.

Be aware that in order to be able to use CCMS monitoring on an IPC system an SAPCCMSR agent has to be installed on the IPC host; see document CCMS Agents: Properties, Installation, and Operation (available on the SAP Service Marketplace via the following link: http://service.sap.com/~sapidb/011000358700003240702001E).

Furthermore there are additional monitoring tools that are not yet fully integrated into the CCMS environment:

Single Activity Trace (SAT): Identifying error and performance problems Further documentation on setting-up and using the single activity trace is in preparation and will be published at the SAP Service Marketplace soon.

An SAP IPC system can also be monitored with the IPC Monitor (an elementary monitoring tool described in the HTML documentation provided with the file system of SAP IPC, /ipc/doc/index.html see section The debug guide, subsection Using the IPC Monitor). The functionality of the IPC Monitor has not changed in 4.0.



2.7 IPC Enhanced Settings

2.7.1 Modifying IPC Services

This chapter applies to Windows installations only.

Use You can modify the Windows services of the IPC Server, IPC Dispatcher and IPC Data Loader, i.e. SAP IPC Server service, SAP IPC Dispatcher service and SAP IPC Data Loader service. The SAP IPC Server service can start several IPC servers on the same computer (this should improve the performance and simplify installing the IPC on (large) multi-processor computers).

Technically the Windows services start one or more Java processes.

Procedure To modify the IPC Windows services the following files (located in \ipc\lib\ properties) have to be adapted:

serverservice.properties dispatcherservice.properties dataloaderservice.properties

All three property files have the same format: A number of lines with name / value pairs separated by =.

As default all lines within those files are disabled by a # character at a lines first position (a # character at the beginning of a line means that this line is handled as a comment). Therefore the IPC Windows services will start with default (hard coded) settings.

serverservice.properties classpath=".;../lib/IPCCustPatch.jar;../lib/IPCPatch.jar;../lib;../lib/SAP_IPC.jar;../lib/thirdParty.jar;../lib/classes12.zip" command="%JAVA_HOME%/bin/java.exe" -Xms64m -Xmx512m -Xrs class=com.sap.sxe.socket.server.JavaServer -loggingCategory Server serverCount= outlog=disabled errlog=disabled

The properties permit the following settings:

classpath: This setting contains the Java class path that is used by the respective IPC application. This can be enhanced with customer-specific classes and libraries (for example, when using Vertex and Taxware for calculating US taxes). Do not change the existing entries. When changing this setting, you should proceed with care as class path problems can lead to complicated errors, which are difficult to analyze.

command: Here, you can change the access parameters of the Java call, which the service uses to start the relevant IPC application. The main application areas should be



the options -Xms and -Xmx, which you can use to set the initial and maximum memory capacity. If another Java Virtual Machine (VM) is used as a hotspot, you can change this line completely. When using Suns Virtual Machine, you should keep the option -Xrs, otherwise the service will be restarted when the user ends the session.

class: Here, you can specify the Java class of the Server, Dispatcher or Data Loader as well as the options when calling this class. Do not change the class names. In general, this property should be the one you have to modify the least often.

Note: -loggingCategory is used to do this server's logging. Logging is configured in ipc\lib\properties\logging.properties.

Windows environment variables can be used inside the value of a command, classpath or class. See example above.

outlog: Here, you specify whether the standard output stream of the servers, dispatchers or data loaders corresponding Java process is written to a log-file (outlog=enabled) or if the standard output stream is not logged (outlog=disabled). Default: enabled.

errlog: Here, you specify whether the standard error stream of the corresponding Java process is written to a log-file (errlog=enabled) or if the standard error stream is not logged (errlog=disabled). Default: enabled

The files used to log the standard output and standard error streams of Java processes are written into the directory \ipc\bin: Dispatcher-related files: IPCDispOut.log, IPCDispErr.log Data-Loader-related files: IPCDataLoaderOut.log, IPCDataLoaderErr.log Server-related files: IPCServOut.log, IPCServErr.log

When only a single server is started: IPCServOut.log, IPCServErr.log

Example To allow the IPC Server to use up to 1 GB of memory:

1. Edit file: \ lib\properties\serverservice.properties. 2. Look for the following line: #command="%JAVA_HOME%/bin/java.exe" -Xms64m

-Xmx512m Xrs. 3. Remove the # character at the beginning of the line and change the maximum

memory capacity (-Xms) to 1 GB (1024 Mbytes): command=java -Xms256m -Xmx1024m Xrs

This type of a setting is recommended for customers with large models or a great deal of products.

4. Save the file.

5. Restart the service to implement the changes.



After restarting, the IPC Server will start with 256 Mbytes memory capacity and allow up to 1024 Mbytes memory consumption.

Take into consideration that incorrect changes to the start parameters of IPC components can cause serious problems. You should only make this kind of adjustments if you have in-depth knowledge of Java calls. When reporting customer problems to IPC support, do not forget to mention any changes that you have made to the service settings.

2.7.2 Starting Multiple Servers The SAP IPC Server service can start several servers on the same computer. This can be particularly useful, for example, when loading computers with 8 or more processors.

An IPC Server service can start several IPC servers. To make this possible:

Windows Specify the following line in \ipc\lib\properties\serverservice.properties:serverCount=

UNIX Specify the following line in /ipc/bin/ipcserver SERVER_COUNT=

As a standard, only one server is started.

Take into consideration that you need to create a sufficient number of RFC destinations. The setting rfcServerCount in \ipc\lib\properties\dispatcher.properties needs to be the same as the total of all serverCount entries for all computers linked with this dispatcher, and you need to maintain this number of RFC destinations (IPC_RFC_SERVER_1, ...) in the transaction sm59. With multiple servers each server can have its own specific classpath, command, class, errlog and outlog parameter. Windows In \ipc\lib\properties\serverservice.properties:

Add the servers number (1, 2, 3, ) behind the parameter name, for example command1="%JAVA_HOME%/bin/java.exe" -Xms256m -Xmx1024m Xrs. If you do not provide a specific parameter, the standard parameter (the one without a specific number, for example command=) is used.

UNIX In /ipc/bin/ipcserver look for the following lines: #CLASSPATH[1]=".:../lib/IPCCustPatch.jar:../lib/IPCPatch.jar: ../lib:../lib/SAP_IPC.jar:../lib/thirdParty.jar:../lib/classes12.zip"#COMMAND[1]="${JAVA_HOME}/bin/java ${JVMOPTIONS}" #CLASS[1]="com.sap.sxe.socket.server.JavaServer -loggingCategory Server1" #OUTLOG[1]="enabled" #ERRLOG[1]="enabled" To activate those entries remove the # character at the beginning of the line. Adapt a line according to your needs.



2.7.3 Multiple IPCs on one Host

Use It is possible to run multiple IPCs (same or different support package levels) on one host.

Procedure (UNIX) On UNIX there are no specific tasks to execute. Just install the IPC more than once into different installation directories.

Each IPC uses ports to communicate. These ports must be different between all IPCs. Configure the ports with the IPC Administrator.

Procedure (Windows) Different installed IPCs will conflict at the following points:

Entry in the Start menu See Start Programs SAP Internet Pricing and Configurator

Entry in the Services panel default Windows service names See Start Settings Control Panel Administrative Tools Services

Entry in the Add/Remove Programs panel See Start Settings Control Panel Add/Remove Programs

To resolve the conflicts you have to execute the following steps:

Rename the Start menu entry Rename the IPCs services Adapt the un-install data in the registry

To install multiple IPC on one host execute the following steps:

First IPC 1. Install into specific directory . 2. Rename the Start menu entry.

3. Rename the IPCs services.

4. Adapt the un-install data in the registry.

Second IPC 1. Install into specific directory . 2. Rename the Start menu entry.

3. Rename the IPCs services.

4. Adapt the un-install data in the registry.



Each IPC uses ports to communicate. These ports must be different between all IPCs. Configure the ports with the IPC Administrator.

Renaming the Start Menu Entry 1. Choose Start Programs SAP Internet Pricing and Configurator. 2. Right mouse click on the entry SAP Internet Pricing and Configurator.

3. Select Rename.

4. In the dialog window, enter a new name to distinguish this IPC installation from other IPC installations and choose OK.

5. Confirm the warning dialog telling you that modifying the folder will affect all users that log on to the computer.

Renaming the IPC Services The default IPC service names are:

SAP IPC Server SAP IPC Dispatcher SAP IPC Data Loader.

To rename an IPC service you have to use the so-called service kit located in directory \bin\svckit. There execute the following commands: build "" Server build "" Dispatcher Also if you are not using the data loader, run: build "" Dataloader

We recommend using the following name pattern for your service names: SAP IPC type is Server, Dispatcher or Data Loader.

The build command will un-install the old default service (installed when the IPC has been installed) and install a new service with the new name. See the output fragment below when running the following command: build "SAP IPC Server of My-CRM-System" Server Uninstalling old NT service ... ... Uninstalling service 'SAP IPC Server'. Service 'SAP IPC Server' successfully uninstalled. Creating new NT service "SAP IPC Server of My-CRM-System" ... ... Installing new NT service "SAP IPC Server of My-CRM-System" ...



... Installing service 'SAP IPC Server of My-CRM-System'. Service name: 'SAP IPC Server of My-CRM-System' Display name: 'SAP IPC Server of My-CRM-System' Event source: 'service.SPCServer' User name: '(default - LocalSystem)' User password: '(none)' Service 'SAP IPC Server of My-CRM-System' successfully installed.

Adapting the Un-Install Data in the Registry

Be careful when editing the windows registry. Only change the requested keys and entries. Changes at other location can crash your system.

1. Choose Start Run 2. Enter regedit and choose OK. 3. In the Registry Editor, navigate to key HKEY_LOCAL_MACHINE SOFTWARE

Microsoft Windows CurrentVersion Uninstall SAP Internet Pricing and Configurator

4. Select the key SAP Internet Pricing and Configurator.

5. Right mouse click and select rename.

6. Change the keys name to a new name to distinguish this IPC installation from other IPC installations.

We recommend using the following name pattern for the new name: SAP Internet Pricing and Configurator

7. Confirm your entry with Enter.

Note that the key (with the new name) is still selected.

8. On the right panel of the registry editor select the DisplayName entry.

9. Right mouse click and select Modify.

10. In the Edit String dialog, change the name in the Value data field to a new name to distinguish this IPC installation from another IPC installations.

We recommend using the following name pattern for the new name: SAP Internet Pricing and Configurator

11. Choose OK to close Edit String dialog.

12. Choose Registry -> Exit to the Registry Editor.

2.7.4 IPC Command Line Interface The IPC command line interface (CLI) allows to execute IPC commands from the dispatcher's and the server's application. The following features are provided:



Can execute any IPC command with any parameters Simplified, procedure-call like syntax for convenience Command results stored in global variables for easy reuse Typical command calls as pre-defined special commands Initialization file called upon server startup

For further information see /ipc/doc/spc/cli.rtf.

2.7.5 Registration of New IPC Commands If you have added new commands to the IPC Server or changed the parameters of existing IPC commands, RFC clients need to know about this change. The repository information on all IPC commands that are available as RFC functions is maintained in a central XML file, called RFCCommands.xml in lib/properties.

In case you have worked with the 2.0C IPC Bridge - this file is the equivalent to file SpcCommands.xml in IPC Release 3.0 and higher.

For each command, you need to maintain one XML tag. This tag defines the import parameters, table parameters, and export parameters. Parameter definitions include:

An RFC name and a Java name for the parameter. The Java name is the actual name of the corresponding IPC parameter, and the RFC name is the name under which you want to access it from ABAP.

The size of the field in ABAP. Flags determining whether the command is to be broadcasted to all IPC servers, and

whether the value is a normal string or a UTF8-encoded Unicode string.

There are a lot of command definitions in the RFCCommands.xml file that is shipped. Just copy one and change it according to your needs.

Make sure that the parameter lengths match those in ABAP. Mismatch of parameter lengths causes bizarre errors because JCo inside the IPC misinterprets the data passed to it (for example, it interprets "ABC", "DEF" as "BCD", "DE").



3 Product Variants With SAP IPC you can replicate material variants from mySAP Product Lifecycle Management (PLM) as product variants to mySAP CRM3. In mySAP CRM product variants are fully specified (fully configured) products that are related to a configurable product and its knowledge base. Besides some other applications the most important use of product variants is the product variant search during (or after) the interactive configuration of the according configurable product with the Web-based configuration user interface. The objective of the variant search is to find a pre-engineered product variant product options similar to the current option selection.

The product variant search has some parameters that can be tuned with SAP IPC. This section gives an overview on how to adapt the settings of the product variant matching with SAP IPC.

To trigger the variant search from the Web-based configuration user interface, the appropriate user interface parameter for variant matching has to be activated (see section 4.6 UI Parameters for more details).

For more information about how to use product variants in mySAP CRM, see application documentation for mySAP CRM 4.0 (http://help.sap.com mySAP.com Cross-Industry Solutions mySAP Customer Relationship Mgmt select release and language Application Services Application Engines Product Configuration Product Variants).

3.1 General Search Settings Use If you want to use product variant settings that differ from the standard and/or if you want to modify the type of search used to find product variants you need to make some adjustments.

This section is aimed at system administrators and product modelers.

Procedure The file /ipc/lib/properties/casebase.properties contains customizing settings for the product variant search with SAP IPC. is the root directory of the IPC Server installation.

The casebase.properties file is optional and is not part of the IPC installation. If you want to use settings that differ from the standard, you need to create this file.

There is currently no user interface to support maintenance of this file. You need to use a text editor. The following settings can be changed:

configCachesize =

3 You also can do product variant search with SAP IPC in application scenarios that are not based on a CRM system (as for example Internet Sales R/3 Edition); in these scenarios the SAP R/3 material variants are replicated to SAP IPC via the IPC Data Loader. The set-up works the same way as described in this section.



Determines the maximum number of configurations that are buffered in the memory at the same time for the product variants. The default value is 20. Higher numbers improve performance but increase the amount of memory space used.

indexCachesize = Determines how many search indexes are kept in the memory at the same time. A search index is the data structure for one product. The default value is 10.

bufferRefreshingPeriod = Specifies that every search index is updated every seconds. Variant matching only takes changes in the product variant master data into consideration after this time interval has passed. The standard time interval is 86400 seconds = 1 day.

fuzzySearch = true or incompleteSearch = true Specifies the search mode to be used for variant matching. There are three different search modes; exact, fuzzy, and incomplete. For more information about the differentiators of the search modes see the application documentation on product variants for mySAP CRM 4.0. Default search mode is exact.

Whenever the casebase.properties file is created or changed, you need to restart the corresponding IPC Server before the settings take effect.

3.2 Product-Model-Specific Settings Use Product-specific adjustments to the product variant matching are made in cooperation between product modeler and system administrator. The product modeler defines the product-model-specific input, and the system administrator enters the settings on the SAP IPC system.

You can maintain the search settings for every configurable product in an Extended Markup Language (XML) file separately. There is currently no user interface to support maintenance of this file.

If you want to change the standard settings for the search, create a file for the configurable product P (P = product name) called casebase_.xml in the Java-CLASSPATH of the IPC (ipc/lib).

You can use the search settings to influence the results of a fuzzy search for product variants. In particular, you can assign weightings and distances to product options.

The IPC contains two files as examples called casebase_wp-940.xml and casebase_KBCA_A0001.xml.

The XML-file has the following basic structure:



You can enter any number of definitions between and to specify a search type. In the case of a fuzzy search, you can also specify a weighting or a distance. Weightings are also available in a limited sense for the incomplete search. If you specify a weighting of 0, the corresponding characteristic is ignored during the search.

Whenever a casebase_.xml file is created or changed, the corresponding IPC Server has to be restarted before the settings take effect.

Search Mode You can assign a certain search mode to the configurable product (that might be different from the search mode defined for the IPC Server).

Setting Product Specific Search Mode To specify the search mode for a configurable product, enter For mode use one of the alternative key values: exact exact search mode incomplete incomplete search mode fuzzy fuzzy search mode. To use the fuzzy search for your product you write:

Weighting You can assign weightings to product options, for example, to specify that the system should weight differences in a web phones screen differently to differences in its communication type.

Define Product Option Specific Weighting To specify the weighting of a product option, enter You would like to express that the difference in the web phones communication type is twice as important as a difference in the screen type, therefore, you enter: Assuming that there are two variants: 1. WP-940-V1: WP_SCREEN: 001 (LCD screen) WP_CONNECTION: 002 (digital) 2. WP-940-V2: WP_SCREEN: 002 (touch screen) WP_CONNECTION: 003 (satellite) The user has selected the following product options:

WP_SCREEN: 002 (touch screen) WP_CONNECTION: 002 (digital)

Then the fuzzy search would detect that the configuration of the variant WP-940-V1 is closer to the users selections than that of the variant WP-949-V2, since conformity in connection type is more important than in screen type.



Distances You can assign distances to product options (characteristic values), for example, to describe that for the characteristic 'Color', the values 'red' and 'violet' are more similar than the values 'red' and 'green'.

In the case of characteristics with a fixed value range, you can maintain distances between the individual values. If a product variant and the configuration of a configurable product differ because of a characteristic with a fixed value range, the distance affects the dissimilarity of both the greater the distance, the less similar the product variant and configuration are to each other.

There are two different types of distances: ordered and unordered.

Ordered distances: here you only need to specify a few distances, the system then determines any further distances itself using the transitive law.

Unordered distances: the system does not assume a relationship between characteristic values, you must manually specify the distance for every combination of values.

Distance Calculation according to the Transitive Law In case of an ordered distance: 1. A characteristic CPU-SPEED has the values NORMAL, FAST, VERY_FAST. 2. You specify that the distance between NORMAL and FAST is "3". 3. You specify the distance between FAST and VERY_FAST to "5". 4. The system automatically derives that the distance between NORMAL and

VERY_FAST is "8".

The default value for the default distance is 0; the default value for the order is 'false'. However, both parameters are not mandatory.

Unordered Distances For a liquid analyzer (KBCA_A0001) there is a characteristic Injection Mechanism (KBCA_INJECTION_MECHANISM) with the following values:

001 (standard) 002 (auto sampling) 003 (sample manager) 004 (generic panel)

Basically the difference between the different injection mechanisms is the same, but there are some exceptions: 1. The auto-sampling and sample manager are nearly the same. 2. The generic panel is similar to auto-sampling and sample manager

(but not as close to them as the two sampling types are to each other). T, you write:

This example states that KBCA_INJECTION_MECHANISM is not an ordered characteristic, and that, as a standard, all product option values should have a distance of "10" from each other (default=10), however, the three distances between 002, 003 and 004 should be different to "10". In this case, the



distance between 002 and 003 is 5, the distance between 002 and 004 is 7 and the distance between 003 and 004 is 7. Assuming that there are two variants: 1. KBCA_V1: KBCA_INJECTION_MECHANISM: 003 (sample manager) 2. KBCA_V2:

KBCA_INJECTION_MECHANISM: 004 (generic panel) The user has selected the auto-sampling (002) injection mechanism. Then the fuzzy search would detect that the configuration of the variant KBCA_V1 is closer to the users selections than that of the variant KBCA_V2.

Ordered Distances This example states that 001 and 002 should be different by five, 002 and 003 by seven and 001 and 003 by twelve (twelve is calculated using order=T). This is obviously an ordered distance as the distance between 001 and 003 is the total of the distance between 001 and 002 (5) and 002 and 003 (7).

In general, the distance definition starts with and ends with Within the distance tag you can specify the order type (e. g. order=T) and the default distance (default=number) or a combination of the two.

Within a distance definition, you write a number of statements in the form:



4 Configuration User Interface This chapter is aimed at system administrators of the SAP IPC Web applications.

It is relevant for any integration scenario that is applying the Web-based configuration user interface (JSP UI Java Server Pages user interface).

It is assumed that readers are familiar with the SAP IPC system (see the SAP IPC 4.0 Web Applications Installation Guide at the SAP Service Marketplace under http://service.sap.com/crm-inst) and the architecture of the complete system landscape (for more information on potential system landscape architectures see the CRM Master Guide 4.0 at the SAP Service Marketplace).

You should have an installation of SAP IPC at hand while reading this chapter.

The IPC integrated in the mySAP CRM Field Sales application uses a different architecture and a different user interface technology (the desktop user interface of my SAP CRM Field Sales is based on the Java Swing library). The desktop user interface for interactive configuration is not covered in this document. For information on the customizing parameters of the Swing UI check SAP notes 535658 and 555351.

4.1 Introduction With release 3.0 of mySAP Customer Relationship Management, SAP introduced the Java Server Pages technology for the user interface (UI) of interactive product configuration with SAP IPC. One of the design goals was to allow easy customization of the user interface. There are two ways which compliment one another to do that:

Modify the Java server pages and/or the action flow. This is suitable for changes in the layout, flow or major changes in the user interface design.

Customize the UI by setting the parameters for the user interface This document describes the customizing.

User interface parameters have already been in place in the Internet Transaction Server (ITS) user interface (Releases 2.x). Experience has shown that customers demand an easy, code-free adaptation of the user interface. Hence, the number of settings has increased significantly with subsequent service packs of release 3.0. From an architectural point of view, handling customization by adapting parameters for interactive configuration (in the configuration file ipcconfig-data.xml) allows a lot of flexibility. In 4.0, the management of this file has been simplified, and merging of customer settings and SAP standard settings (with XCM the eXtended Configuration Management) is now much easier.

The Application Programming Interface (API) documentation does not cover all these new options. This document aims to not only list and group parameters and their meaning, but also to explain the architecture and some background.

Therefore, the main target group of this section is members of the project team (consultants, customers). A certain understanding of the technology and of SAP IPC in general is prerequisite.

It cannot be guaranteed that the list of parameters is complete and completely accurate. You might also want to check the API documentation:



consult the HTML documentation provided with the file system of SAP IPC, /ipc/doc/index.html see section API Documentation, package com.sap.spc.remote.client.object.

4.2 Architecture

4.2.1 Basics on HTTP Communication The user interface for interactive configuration of SAP IPC is started via an HTTP-request to one of the initial Struts-Actions (for general information on the Struts-Framework see http://jakarta.apache.org/struts). Which of the various available initial actions is called, such as command.do, depends on the scenario used. An example how to call the configuration user interface directly can be found in the folder /root/ipc/examples. HTTP is an application level protocol (generally implemented over TCP/IP connections). The HTTP is a stateless protocol based on requests and responses. In this paradigm, client applications (Web browser) send requests to the servers to receive information or to initiate processing. The client has the possibility to transfer data to the server using the HTTP request. Internally, the request is structured similar to a table containing key/value-pairs. Data can be accessed using the appropriate key.

The HTTP-Protocol defines different request methods. Typically GET or POST is used for most requests.

When using the GET method data is encoded using the URL string (such as http://search.yahoo.com/bin/search?p=IPC; the value IPC is assigned to key p). Some servers shorten the length of the request URL so the quantity of data is also restricted. Normally this border is at about 4096 characters.

The POST method is used for sending large amounts of data. The information is transmitted within the body of the request. For the communication between the user session (at the Web browser) and the SAP IPC Web application the POST method is used.

It is important that the keys used in the request are case sensitive. Be aware of keeping the exact spelling of the parameter names when changing or adding parameters. With release 4.0, most parameters of the SAP IPC Web application are written in the style ., all in lower case letters, no underscores.

The parameter controlling whether or not each single user selection on a product option triggers an update of the configuration user interface via execution on the server side is named onlineevaluate; it is either set to T (true) or F (false) and it is assigned to the component behavior of the Web application. To address this parameter the notation behavior.onlineevaluate is used.

You should also keep the spelling of the parameter values, although they are not case sensitive. A misspelled value is often ignored, but can sometimes cause unexpected results.



4.2.2 Where parameter Values are Set

ipcconfig-data.xml and HTTP Request When the IPC is called, it receives the parameters that are part of the original request. During the initialization, the actions ProcessScenarioPropertiesAction.java and ProcessRequestParameterAction.java are executed. These actions parse the ipcconfig-data.xml, read the parameter values therein and merge them with the existing parameters. Existing parameters will not be overwritten by the settings in ipcconfig-data.xml. If a parameter is neither set by the caller nor in the ipcconfig-data.xml, a default value is set.

As a consequence, the following hierarchy applies:

1. Values set by the caller in the original HTTP request. These override values of the ipcconfig-data.xml.

2. Values defined in the ipcconfig-data.xml. This is the most common place for customizing. You may use the default entries or set scenario-specific entries which depend on the calling application (see 4.3 Extended Configuration Management).

3. Parameters which are valid for a certain UI name string which is defined in the knowledge base. This allows a model-specific UI (see section 4.4 Model-Specific UI Settings.) parameter setting.

4. Sometimes an empty value causes a default behavior in the coding. However, since the behavior is not well defined and can be unpredictable, SAP strongly recommends to always set a value for each parameter.

Where can I do what? Ipcconfig-data.xml:

This is the recommended location to set parameters. If you change the values here, you dont have to touch any coding. You can add any parameter to the ipcconfig-data.xml. As explained above, you cannot override parameters that are set by the calling applications. The settings of the ipcconfig-data.xml are settings on application level. They may be specified for certain scenarios (CRM Online, Internet Sales etc.) In 4.0, we have introduced a user interface to maintain these settings. See chapter 4.3 for more information.

It depends on the J2EE engine (and release), whether the ipcconfig-data.xml is reloaded at runtime. You might have to restart the J2EE to load the changed settings

Request (caller): It largely depends on the scenario how to manipulate the parameters of the original request.

If you run an ABAP scenario (CRM, R/3), you have the possibility to define certain settings as part of IMG customizing activities. For more information see chapter 4.3.7.

In Internet Sales, it depends whether you need to change setting for the catalog and/or the basket. The basket calls an action called ItemConfigurationBaseAction containing a method called



setConfigurationParams that sets connection parameters (host, port, etc.), basic parameters (product, language), as well as display mode, the value of behavior.onlineevaluate, and enables product variant search. If you integrate the IPC in your own application, you can define the content of request yourself.

Runtime (receiver): You can change the value of many parameters also at runtime by writing your own action or a JSP page as part of the IPC web application (this is a modification). To set a value use method setProperty() of the interface UIContext. Some parameters (such as the knowledge base name) are read during the initialization process, so you have to change them before they take effect, others (especially UI parameters) can be changed easily during runtime.

For testing purposes, it is very useful to run the IPC Standalone with its own database or against a SAP CRM system. You can change the parameters in the HTML form that is used to call the IPC and/or the ipcconfig-data.xml. This allows you to easily and quickly experiment with the UI.

Extension Framework Besides the general possibility of changing the Look and Feel of the UI, SAP provides a framework to support some typical extensions:

Customer Buttons: Are defined in the ipcconfig-data.xml without having to code anything in the JSPs. For details, see Customer Buttons

Customer Tabs: A pre-defined tab in the Multi-Function Area. Here you can easily include a self-written JSP. For details, see Customer Tab

Customer Parameters: A technical framework to transport self-defined additional parameters from ipcconfig-data.xml to the JSPs. For example, you have implemented a modification and want to make it customizable. In ipcconfig-data.xml, you can add any parameter starting with the prefix customer. In the UI Layer, you can read the value of this parameter using the methods getCustomerProperty etc. in the interface remote.client.object. There are also methods to change the value of such a property at runtime.

4.3 Extended Configuration Management

4.3.1 Overview The IPC is a component integrated with different SAP products.

The behavior of this component depends on

1. the parameters passed from outside when calling the component

2. the default settings of the component for parameters that are not passed from outside.



In SAP CRM, IPC is used for configurable products in CRM Order and Customer Interaction Center (CIC), the Product Workbench and the Product Catalog Maintenance. In these integration scenarios, the purely technical parameters for the connection of the web application to the IPC Server (such as ipc.host, ipc.port, ipc.dispatcher) are passed from the CRM to the IPC Web application (JSP UI) via the HTTP request. Other parameters like behaviour.onlineevaluate are defined in the XCM settings of the Web application.

4.3.2 Parameters, XCM Components, XCM Scenarios

Parameters control the structure, appearance and behavior of the IPC application (e.g. the way how characteristic values are displayed: Options or list box elements).

Components group these parameters. The default components delivered in the SAP area group the parameter according to their function. Components have one or more configurations.



Configurations combine different parameters and their values.

Scenarios combine the different configurations of components to a configuration setting.

Do not confuse the XCM scenarios with the IPC integration scenarios even though the default XCM scenarios delivered in the SAP area deduct from integration scenarios.



4.3.3 Default SAP XCM Scenarios The IPC is shipped with a set of pre-configured scenarios. Each of these scenarios corresponds to one of the IPC integration scenarios:

crmdefault: General settings in the CRM online crmordermaintain: Specific settings for the order transaction within the CRM

online. Inherits general settings from the crmdefault scenario and extends the crmdefault scenario

crmproductsimulation: Specific settings for the product master transaction within the CRM online. Inherits general settings from the crmdefault scenario and extends the crmdefault scenario

isacatalog: Specific settings for the catalog within the internet sales application isab2b: Specific settings for the business to business order transaction within the

internet sales application

isab2c: Specific settings for the business to customer transaction within the internet sales application

vehiclemanager: For vehicle manager transaction velo thirdparty: For integration of the IPC within non-SAP systems

4.3.4 Creating Own Components and Scenarios You can use the XCM Administrator to define parameter settings that differ from the SAP default parameter settings.

1. Start your Browser

2. Start the XCM Administrator with the following URL: http://:/ipc/admin/xcm/init.do



4.3.5 Folder structure The XCM configuration files are arranged in a SAP and a Customer area. This separation ensures that settings you have made for your system will remain intact during upgrades. The SAP area contains default system settings that should not be modified by customers. Both areas contain a configuration and a modification subfolder. 99% of the IPC configuration settings will be made using the XCM Administrator UI in the configuration subfolder.

The modification folder files allow you to extend and redefine the SAP default settings for Business Object Managers, cache settings and initialization behavior.

You need to make changes to files in this folder with an editor in extended XML syntax. For more information refer to ISA Configuration and Modification Guide.

4.3.6 Request parameters versus XCM settings You can pass all parameters that you can specify in the XCM configuration settings also in the HTTP request calling the IPC. The parameters passed in the HTTP request will overwrite (replace) the parameters of the XCM settings (see ipcconfig-data.xml and HTTP Request).

4.3.7 IMG Customizing versus XCM settings You can also set all parameter which you can specify in the XCM configuration in the IMG Customizing. These parameters are used when calling the IPC via HTTP request, i.e. in all CRM-Server-based scenarios like CRM Telesales. The parameters passed in the HTTP request will overwrite (replace) the parameters of the XCM settings.

The settings are made within table COMM_IPC_PROP using transaction SM30. Type Describe the area on which the parameter has an influence. The order

of the type list is

1. scenario

2. caller

3. uiname

4. user

The type with the higher number overwrites the type with the lower number.

Typename Name of the specific type.

Parameter Name of the UI parameter

Parameter Value Parameter value

Type Typename

Scenario CRM

Caller crmordermaintain crmproductsimulation crmproductcatalog Uiname Simple Complex



noconflictexpl User

Setting a parameter and show how the type can be used The parameter behavior.enablesettings has the value T for all CRM applications. The second entry define that the order will set the parameter behavior.enablesettings to F with the exception that all configurable products which has a defined uiname = simple are using the parameter behavior.enablesettings with F. The last row define that the will use his own definition of UI settings.

Type Typename Parameter Parameter Value

Scenario CRM behavior.enablesettings T Caller crmordermaintain behavior.enablesettings F Uiname simple behavior.enablesettings T User behavior.enablesettings F

To define a customer-specific XCM scenario for the CRM applications it is necessary to set a parameter scenario.xcm. Type Typename Parameter Parameter Value

Caller crmordermaintain scenario.scm My_crmordermaintain Caller crmproductsimulation scenario.scm My_crmproductsimulationCaller crmcatalog scenario.scm My_crmcatalog Caller

4.3.8 Configuring IPC for CRM Online This section describes how to define settings for each CRM system. Most customer have more than one CRM system and more than one J2EE server. You can centralize the XCM settings for your whole system landscape in one XCM directory. For this, define a scenario for each of your systems in a central XCM directory.

Using the XCM Administrator, you can then specify this directory in the Options category under Path to customer configuration.



You need to set this Path to customer configuration for each web application and each J2EE server.

4.3.9 Which Scenario Does the IPC Use? The application that integrates the IPC Web application calls this Web application via HTTP request. The XCM scenario that you want to use for your Web application needs to be passed in this HTTP request as parameter either in the URL in the following form: ?scenario.xcm= or as a field of an html form.

4.3.10 What Happens If I Pass A Wrong Scenario Name?

SAP delivers XCM with a so-called bootstrap scenario. Whenever the XCM config manager is unable to find a scenario, it uses this bootstrap scenario.

You define the bootstrap-scenario in the /sap/system/xcm-config.xml. The default value specifies the name of the configuration that the bootstrap scenario will use for the component defined by


4.4.2 Defining Parameter Sets for Product Families You maintain the set of parameters using the XCM Administrator in the component uiname.

SAP delivers three default configurations for the component uiname: simple, complex, noconflictexpl. You can use these configurations or define your own.

4.4.3 How does the IPC Know How To Select My UINAME configuration?

Product configuration requires a configuration knowledge base.

Each root level configurable product requires a knowledge base profile within this knowledge base. The knowledge base profile has a field UINAME. The value of this field must correspond to the name of the uiname configuration you want to use for the Web UI of this product.

If you start the configuration either from CRM Online or Internet Sales, IPC automatically chooses the knowledge base and profile for the product.

It then replaces the set of scenario parameters with the parameters specified in the uiname configuration.



4.5 Control Parameters

4.5.1 Connection Parameters

Finding the IPC Server Whenever the JSP UI is started, it needs to find and connect to an IPC Server. The following steps are processed when the configuration is started:

1. An application (CRM, R/3, Third Party) calls the IPCs URL.

2. The Web server creates an HTTP session.

3. The JSP UIs action creates the object Inclined.

4. The IPC client creates an object IPCSession, which is the client-side view of an IPC user session.

5. The IPC client determines the IPC Dispatchers host, the TCP/IP port and character encoding. For more details see below.

6. The IPC client opens a TCP/IP connection to the dispatcher and sends it a request of the IPC command Connect.

7. The IPC Dispatcher looks at its list of servers and determines the one with the least load.

8. The dispatcher sends a response with the servers host and TCP/IP port back to the client.

9. The client opens a TCP/IP connection to the server and sends it a request of the command CreateSession.

10. The IPC Server creates a server-side IPC session object for the module and SAP client that has been passed.

CRM directly calls the IPC Server

For the determination of the connection details, the same pattern applies as for the other parameters: they can be part of the initial request (that means, they can be defined in the calling application) or be entered in the ipcconfig-data.xml, even be scenario-specific (for example, no dispatcher for CRM).

Before 3.0 SP10, the parameters were listed in a file named client.properties in the folder \WEB-INF\classes\properties. This file is now less important and is only kept for compatibility reasons if no value is specified neither in the request nor in ipcconfig-data.xml. Do not use client.properties for a regular scenario.

If the client cannot determine the connection parameters, or the settings are wrong, or if the IPC Dispatcher or IPC Server determined in the parameters is down or you try to connect to



a server as a dispatcher; in general: if any connection problem occurs, youll see the self-explanatory error message Unknown error.

The connection parameters are: Name: ipc.host Data type: String (URL) Example: superipc.sap.com, localhost This is the URL of the dispatcher or server (if no dispatcher is used). If the Web server and IPC reside on the same machine, you can enter localhost. Name: ipc.port Data type: Integer Default: 4444 (3.0 Dispatcher) This is the TCP/IP port of the dispatcher resp. server as defined in the IPC administrator. You define only the port of the machine that the JSP initially contacts, that is, usually the dispatcher port. The dispatcher will then tell the JSP user interface the port of the IPC Server.

Name: ipc.dispatcher Data type: String Values: true | false Default: true (note: CRM.dispatcher = false) Determines whether the host/port specified above is an IPC Dispatcher or IPC Server. If you try to connect to a dispatcher with dispatcher =