As a part of the SAP HANA initiative of collaborating with SAP and building solutions on the SAP HANA foundation, we have modeled and built a solution for a business case for complex pricing calculations for the consumer products, retail, and distribution industries. A prerequisite is SAP ERP Central Component (ECC) with HANA in a sidecar database. You can use either SAP Customer Relationship Management (CRM) or ECC for the priced catalog use case we present.

The solution is based on the sidecar (secondary database) approach: The SAP HANA database with its in-memory computational design can provide significant performance improvements for existing pricing solution in the short term. (To learn more about HANA see the sidebar “SAP’s Strategy for In-Memory Computing.”)

Companies can use this database in the near term to achieve performance gains. In the longer term, a pricing engine natively developed in SAP HANA and powered by SAP HANA through application development techniques that are optimized for parallel in-memory processing can take advantage of new enterprise data management and application development logic. This can enable them to fully exploit advances in hardware technologies (Figure 1).

In addition to using the secondary database approach that is available, extensive data modeling to optimize the in-memory access in SAP HANA also helps drive performance. In contrast to traditional SAP client server architecture in which all the table operations (such as joins) are performed in the application layer, in the HANA model much of these operations are actually performed in the database (Figure 2). This helps push the complex calculations to the database level by leveraging the stored procedures, attribute, and calculation view capabilities of SAP HANA.

An exponential increase in pricing performance can result from executing data intensive operations in the database level itself as opposed to the application layer.

Business Issue: Pricing 

Businesses in the consumer products, retail, and distribution industries are constantly trying to capture a larger portion of a dynamic and highly competitive market. Additionally, they also need to maintain competitive pricing levels for their existing demanding customers while managing very tight margins. To increase market penetration, businesses should rely on a sales force that’s equipped with the right tools and applications to make that possible. Having a real-time pricing tool with the capability to price entire product catalogs and provide performance benefits on the online e-commerce channel can be a game changer for a business in this space. It leads to better visibility of the cost of goods and margins, which can lead to competitive pricing, greater cross-sell and up-sell opportunities, sales penetration, and customer retention due to better services, effective promotions, and deals. Our clients in this industry have fairly complex product pricing that includes millions of pricing conditions that change dynamically on a daily basis because of the sourced price, merchandising contracts, discounts, promotions, customer agreements, and localized market intelligence feeds. The performance and response times of price computation in ECC, particularly for large complex pricing requirements, has traditionally been a challenge. With large volumes of normalized pricing data, the ECC pricing procedure-based calculations are generally the long pole in the overall response time during order creation. With the online Web-based order entry becoming a prime channel of engagement accompanied by customer expectations and impatience, faster response time during the order checkout process can be the difference between the order being captured or losing the customer to a competitor. Add to this the pricing needs for channels such as B2B priced catalogs, offline pricing needs, or invoice creation for a large product base across multiple variations of customer and vendor agreements just exacerbates the performance issue.

Case Study: Pricing at a Distribution Client

One of our clients in the distribution industry had a complex pricing procedure with multiple condition types, steps, and accesses:

• Approximately 140 condition types
• Approximately 200 Steps
• More than 400 accesses

It also had a rising volume of condition records:

• More than 50 million condition records
• Parallel jobs reaching a time window and hardware ceiling

 

SBS*= Shared Business Services

Performance Concerns 

Figure 3

Solution Approach

The solution was envisioned with a goal to demonstrate performance gains and scalability of the pricing solution leveraging HANA. A proof of concept approach was developed iteratively with increasing levels of complexity and data volumes (Table 1).

Solution Architecture

Figure 4 shows a solution architecture overview of SAP HANA as an accelerator.

This is a classic architecture that has been around since the initial architecture stages of SAP HANA. Depending on the current system release, the integration is progressively better than prior versions of HANA and is supported by an integrated development tool chain that manages code and data modeling. In this scenario, the business suite still uses its classical database as its primary persistence, but it is also connected to a SAP HANA database that serves as its secondary persistence. It uses a replication service (usually SLT) to replicate a subset of the application tables into SAP HANA's column store.

While most read and write database operations are against the classical system database, a careful selection of queries, typically high volume and low performance ones, are against the mirror tables in the remote SAP HANA database. These are queries that are performed immensely faster in SAP HANA, such as calculations involving large numbers of records.

Depending on the system release, accessing SAP HANA involves a varying level of difficulty or can be different than accessing local tables. The following capabilities are available in the current version of ECC to access SAP HANA via a secondary database connection:

• Native SQL access via EXEC SQL
• Object-based and dynamic SQL access via ABAP database connectivity (ADBC)
• OpenSQL if a table of the same name and structure exists in the local system
• Call SAP HANA stored procedures via native SQL or ADBC
• Application accelerator that allows you to switch database access in particular reports from the primary to the secondary persistence by configuration – without making changes to the code

Figure 5 depicts the data and control flow of the pricing sidecar prototype.

There are four SAP components used in this pricing accelerator solution:

1. SAP NetWeaver 7.0 (ECC 6.0): This main component is used as the main system in which all the pricing configurations are made and the environment in which the batch program calculate pricing catalog resides.
2. SAP NetWeaver Gateway with a user interface (UI) add-on: This component has two purposes in this solution:
   1. oData Service Provider: The function modules to process the pricing catalog are being exposed as an oData Web service. SAP NetWeaver Gateway provides the necessary infrastructure to publish the function modules as an oData Web service. This Web service allows any oData client to call the function module to retrieve the pricing catalog.
   2. User interface (UI) Add-on: SAP UI5, which is SAP’s Web interface development technology, is used as the front-end UI for the prototype. The UI Add-on is installed in SAP Netweaver Gateway to support SAPUI5 libraries and applications. By installing the UI Add-on in SAP NetWeaver, the need for a separate server to handle SAPUI5 is eliminated.
3. SLT: This component replicates necessary data from SAP NetWeaver 7.0 (ECC 6.0) into the SAP HANA system. This component replicates the data in real time so any changes made to the pricing configuration are replicated in the SAP HANA system. This ensures that the data in the SAP HANA system always uses the latest set of data.
4. SAP HANA system: This is where the new logic for the pricing resides. The calculations are being done at database level by using stored procedure and calculation views. SQL script language is used in the calculation view and stored procedure.

The pricing procedure solution consists of two types of applications:

1. SAP ABAP applications consist of two programs to compare the run time of pricing catalog generation using standard SAP pricing function module and then to call an SAP HANA calculated view. The program calls a function module to generate a pricing catalog accordingly.

For generating a pricing catalog using standard SAP pricing function module, the program calls a wrapper function module that pre-populates necessary parameters based on user input and calls standard SAP function module for pricing calculation. Once the result is returned by the wrapper function module, the pricing catalog is then displayed on the screen/spool.

For generating pricing catalog using the SAP HANA pricing data model, first the data model is created using multiple attribute and calculation views. Several stored procedures are also created to support variety of views to replicate the logic of the standard SAP pricing function module. The final view is then called by an ABAP function module using an ABAP secondary database connection (ADBC). SAP ABAP language provides classes that set up the secondary database connectivity and methods to call stored procedure and queries to any SAP HANA views. By taking this approach, the heavy lifting is done in SAP HANA so that the hardware and software power of SAP HANA can be leveraged. This function module returns a pricing catalog which is then displayed on the screen/spool by the calling program.

1. The SAPUI5 Web application uses the same two function modules that are used by the ABAP application solutions. These functions are exposed as oData Web services by using features provided by SAP NetWeaver Gateway.

SAPUI5 Web application calls the corresponding Web services based on user input. Once the data is retrieved from oData Web services, it is then displayed in the screen. The user has two options (one with the pricing call to ECC on the traditional database and the other with ECC connected to HANA) generate the pricing catalog and can compare the time it takes to generate the catalog.

This solution showcases the ability of the Web application to harness SAP HANA’s capability to provide users with responsive and robust applications when a large amount of data needs to be processed and analyzed.

Findings 

Scenario 1 – Pricing performance with and without HANA. The data retrieval is encapsulated within a function module. The first performance testing approach uses a wrapper program to call a data retrieval function module and this program is scheduled as a background job.

In this scenario, the data volume is 1,204 customers and each customer has about 1,500 materials. The pricing condition records vary from 1 to 1,225,453 records.

Table 2 and Figure 6 compare the runtimes for priced catalogs using standard pricing and pricing using the HANA data model. As the data volume increases with the additional customer catalogs, the runtime increases exponentially using the standard pricing function on the traditional database whereas the pricing based on the HANA data model remains almost flat-lined.

 

Scenario 2

In this scenario the same function modules are exposed as oData Web Services. An SAPUI5-based UI application is created to consume the Web service and the timing is measured using a JavaScript front-end timer. There are some performance overheads from the Web service and SAPUI5 application, so the run time result is higher compared to performance testing in scenario 1. This scenario is a representative of the online order entry/eCommerce Channel.

As Table 3 and Figure 7 show, the data volume increases with the additional customers. The runtime increases exponentially using the standard pricing function on the traditional database whereas the pricing based on the HANA data model remains almost flat-lined.

While having the latest and greatest version of SAP ERP that supports SAP HANA natively might be a long-term answer, not all organizations are ready to take this plunge in the short term for a variety of reasons such as stability of the new solution or lack of a business case to make the change. Retooling resources with the new technology, training, and other change management impacts have to be factored in.

With the sidecar option, organizations can focus on specific processes that can benefit from the exponential performance gains of SAP HANA in the short term, and develop a longer-term roadmap to get the entire ERP on the SAP HANA backbone. The findings of the pricing on SAP HANA solution demonstrate this.

You can extend the concept to improve key business transactions that are performance intensive and that can be game-changers for companies. Some candidate scenarios include material requirements planning (MRP)/Advanced Planning & Optimization (APO) planning runs that now can run across a much larger sourcing and supply network. This concept can also be extended to areas like billing/invoice creation for industries such as utilities, in which near real time smart meters generate large volumes of data which could be  processed in HANA faster than traditional ECC and help drive down holding and interest costs.

About Deloitte

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.