mySAP CRM E-Commerce conceptual architecture and the components typically customized during a project

Technical Skills Necessary for SAP E-Commerce

When enhancing an SAP E-Commerce Web site, you must first fully understand how this activity could affect the different levels within the application framework. Many skills are required to perform a simple change, such as adding a field in the front end. For example, you would need to understand how to use JSP, Struts (a Model View Controller [MVC] tool that uses Java servlets and JSP technology), back-end communication structures, and the mySAP CRM back end itself — where it might be necessary to change ABAP code and enhance communication structures and Data Dictionary tables. Refer to Table 1 for an overview of the technical skills needed for mySAP CRM implementation activities.

Skill Activities Basis Installs CRM applications and components such as Web Application Server (Web AS), B2B/B2C, Internet Pricing and Configurator (IPC), and TREX. Also connects the CRM applications and components via Remote Function Call (RFC) destinations and Java Connector. Monitors middleware. Java JSP, JavaBeans, Struts Changes the front-end application Object-Oriented ABAP (ABAP OO), Business Add-Ins (BAdIs), Business Application Programming Interfaces (BAPIs) Includes fields not supported by the mySAP CRM back-end system. Implements business logic not supported by mySAP CRM. Java in IPC Implements pricing routines, formulas, requirements, or user exits Functional CRM Sales Configures the back-end application (organizational structure, order types, item category), middleware monitoring (reprocessing of queues and business documents [BDocs], and configuration issues related to master data, transactions, organizational structure Middleware If R/3 back end is in the picture, responsible for the initial loading of configuration and master data from R/3 to mySAP CRM. Also responsible for the performance related to BDocs and queues, debugging of bad BDocs, and queue problems. Network, Internet, ports, firewalls, HTTPS, digital certificates Configures the network for users to connect to the site. Installs security in the network. Implements load-balancing and fail-over capabilities. Assesses bandwidth requirements.

Table 1

Overview of necessary skills for mySAP CRM implementations

When planning an SAP E-Commerce project, it is important that you assemble a team that possesses all of the skills necessary for creating changes that fit your business needs. Often this is a difficult task. A technical team should include a combination of people with different skills who are responsible for enhancing the different layers of the application.

What to Consider for SAP E-Commerce

When planning your SAP E-Commerce project, you should consider the following:

• Front-end development
• Pricing
• CRM Middleware

Front-End Development

SAP E-Commerce applications follow an MVC object-oriented methodology that relates UIs to the underlying data models. This has been the dominant methodology in the development of graphical user interfaces (GUIs) in client- server environments. This development framework allows for separation between the front-end application and the back-end logic. This separation, if designed correctly, allows an application using MVC guidelines to have less code duplication, which makes it easier to modify the code. In larger companies, MVC also helps developers focus on their core technical skills and collaborate during development via clearly defined interfaces. For example, during an SAP E-Commerce implementation you can have some project developers completely focused on working on the front-end application while others can focus on the integration with the back-end business logic. However, for small- and medium-size companies with leaner IT organizations, the MVC development framework can present a challenge. In these companies, the need for an increased number of skills can be a problem. To a certain extent, this model can increase the complexity and time to deliver solutions because, depending on level of change required, you may need to modify multiple layers of code and components. I have seen smaller companies be more successful with a single developer who has multiple skills. Such a developer not only understands the different layers of the MVC model, but also possesses ABAP knowledge. One caveat with this approach — even though companies can get more work done with one resource, these individuals tend to be more expensive because so few developers can do this type of work. The typical application layers where you would perform system modifications are the page layout, page flow, data in the back end, and back-end application programming interface (API). You may need to modify all these layers in case you need to include a new field in a screen, for instance. Page layout. You change the page layout (Web front end) in JSP. This is an e-commerce application’s skin and the visible part to users. The page layout is where users query for information and where the system displays the results. Your Web page exposes your enterprise branding. In this layer, developers perform most of the work to change a Web site’s look and feel according to corporate standards. For instance, when you prepare to implement an SAP E-Commerce application, you must consider if you want to use Adobe (Macromedia) Flash components. This is especially important for a B2C Web site, where a compelling UI is a marketing tool to increase customer interest in doing business with your company. Page flow. Within the MVC model you establish the click-through or purchase path. At this level, you code the sequence of screens and decision points in the component called Struts. The name Struts is a reference to the engineering term “structural,” an invisible component that keeps buildings and houses standing. In the SAP E-Commerce platform, which follows the MVC methodology, Struts is the invisible controller component that integrates with other technologies to provide the model (components to access the back-end logic) and the view (JSP screens). Data in the back end. You use a series of components to reach the data that resides in the back end. Action, business object manager, business object, back-end interface, and back-end object are all components that you have to change if the standard SAP E-Commerce application does not support your requirements. For instance, if you want to populate a new field in the Web front-end application, the JSP has to present this new field and carry the field content to and from the back-end application. Back-end API. SAP has an infrastructure that enables external applications such as SAP E- Commerce to perform actions or retrieve information. You can use BAPIs, BAdIs, or RFCs. You rarely encounter a situation in which an interface program is not already available for your requirements. If you need to populate a new field in the front-end Web application, it could impact the BAPI. You must change the BAPI accordingly to capture or populate that new field. You may need to alter this application layer, depending on the data that needs to be available in the front- end JSP. For example, in one of my previous projects, the customer had a requirement for the front-end Web application to collect some of the shipping instructions. We ended up changing the JSP screen that requests information from the user. The shipping instructions field did not exist, which affected the entire downstream application components, including a BAPI that the Web application called. Ultimately, we had to populate this new field all the way downstream, which also affected the CRM Middleware application that communicated with the R/3 back-end application. Skills tip: A common misconception is that a Java programmer can also fill the role of ABAP programmer on the team. My experience is that even a skilled Java team member has a significant learning curve to master all components of the SAP E-Commerce application. For this reason, you should assign the ABAP programmer role to a different person.

Pricing

You perform pricing calculation and product configuration in mySAP CRM in a component called IPC. You can use IPC as a standalone component or integrate it with other SAP applications. In mySAP CRM, IPC is the pricing engine for all scenarios and is present in all of the different channels — not only SAP E-Commerce. SAP developed this tool in Java because of the need to integrate with applications developed in different platforms such as ABAP, Java, and Visual Basic. IPC has two major components: Sales Pricing Engine (SPE) and Sales Configuration Engine (SCE). These two components are responsible for pricing and configuration of products, respectively. During the planning phases of the project, you must map all of the necessary routines, formulas, and user exits written in ABAP in R/3 to calculate price in mySAP CRM. You must redevelop these routines in IPC/Java so the application can calculate the price correctly in the ERP back end. Again, it is important to know how to translate these routines from ABAP to Java because there is a particular way to develop the logic and the type of return the routines have to yield when the system calls them. If you already implemented pricing logic in R/3, then during the project you must carefully analyze which configurations should be available in the Web application to calculate customer-specific prices correctly. To do this, analyze objects such as pricing procedures, condition types, access sequences, and tables, and select the ones you want the system to replicate into IPC. You must include these objects in the initial synchronization to IPC. Middleware synchronizes configuration objects between R/3, mySAP CRM, and IPC. However, you should filter out unnecessary pricing elements and avoid unnecessary loads in IPC that could cause performance problems. Another step is to turn on the delta changes that synchronize condition records (pricing master data) between R/3 and mySAP CRM, so when prices change in R/3, they flow to mySAP CRM automatically to keep data consistent between both systems. You set this up in the CRM Middleware component. Skills tip: It is critical to assign someone with SAP pricing logic experience to analyze the pricing components (e.g., condition types for freight or discount) necessary for mySAP CRM and IPC. You also need someone with basic ABAP skills who understands pricing logic and can perform a significant amount of debugging during development and testing. Finally, you should include someone with good Java development skills who is responsible for coding the routines, using the pricing APIs available in IPC, and analyzing errors. The amount of involvement of these people depends on the amount of custom code required and its complexity.

CRM Middleware

CRM Middleware is the component responsible for synchronizing data objects between the CRM application and other back-end systems (SAP and non-SAP). It is a set of tables, function modules, programs, and transactions. A component of SAP NetWeaver, CRM Middleware is a standard part of mySAP CRM installations. Hundreds of objects delivered during the mySAP CRM installation support bidirectional integration between mySAP CRM and R/3 (or ECC). CRM Middleware supports the data objects included in Table 2.

Data object Examples Master data Customer master, hierarchy, relationships, material master, bill of materials (BOM), organizational structure, pricing condition records Transaction data Orders, contracts, quotes Configuration Pricing configuration (condition types, pricing procedures, access sequences), country, currency
Table 2	Data objects that CRM Middleware supports

When starting your project, an important discussion that must happen very early in the blueprint phase concerns the synchronization model you want to implement. You should define what system will own what object, how data will flow from one system to another, filtering criteria, and synchronization timing. These definitions drive how you should configure the CRM Middleware to support the requirements. For instance, in the context of sales orders, I’ve seen some situations in which certain order types are created in R/3 (or ECC), but have to flow to mySAP CRM so customers can see them on the Web. I’ve also seen teams create new order types in CRM and R/3 (or ECC) to support the orders generated from the Web. The mySAP CRM system typically owns these orders, which flow to R/3 after the system creates them. Although the system uses the order exclusively in mySAP CRM, you still must configure it in R/3, and then download it. For orders, you should determine matters such as the numbering range for R/3 and mySAP CRM orders, order types, and item categories. You need to go over each object that will coexist in R/3 (or ECC) and mySAP CRM to develop a final synchronization model. Activities follow this model with regard to the design, middleware configuration, and deployment of the final product. Figure 2 depicts the most common objects and the synchronization and ownership considerations that need to take place before you can customize the CRM Middleware.   As you discuss how to set up CRM Middleware, you should consider filtering information to minimize the amount of data that flows to and from mySAP CRM. CRM Middleware provides a tool for you to filter out data that is not relevant to your Web customers. For example, you might want to configure CRM Middleware so that when you create sales orders in R/3 (or ECC), the system downloads only sales order type OR to mySAP CRM. Finally, you should consider how to monitor your SAP E-Commerce application after it is live. You have to monitor R/3 and mySAP CRM queues and the BDocs constantly to avoid out-of-sync data. Many problems, ranging from functional to technical issues, could cause synchronization of objects (configuration, master, and transactional) to fail. For example, if you push a customer hierarchy from R/3 to mySAP CRM and the customer master does not exist, you will encounter problems. Technical problems can range from queue performance (consider configuring the queues for single- threaded or parallel processing) to incorrect connectivity configuration. Skills tip: The middleware monitoring activity is commonly misunderstood because of the broad range of skills required. The work involved typically does not require a full-time team member — except when large amounts of data are involved or when mobile applications are in the scope of the project. The most efficient way to monitor the middleware is to have multiple part-time team members engaged to monitor and maintain the queues and BDocs that the system synchronizes. Typically, a first-level support role should reside with a help desk where this person monitors certain transactions for any problems associated with CRM Middleware. Consider the proper training of your help desk team members to establish consistent monitoring activity. The following skills and resources should comprise your second- and third- level support team:

• Basis: Involved with the configuration of RFC destinations, system administration, and middleware performance
• CRM functional: Responsible for reprocessing queues and BDocs. Handles configuration issues related to master data, transactions, and organizational structure.
• CRM Middleware: In charge of performance related to BDocs and queues processing. Debugs bad BDocs and handles queue issues.