In this blog, we want to give you an introduction into the extension concept of solution SAP Variant Configuration and Pricing.

What is the extension concept?

SAP Business Technology Platform does not offer a framework which would allow us to execute customer code tightly coupled to the Pricing service (user exits) or the Variant Configuration service (variant functions), because this concept does not fit well into a multi-tenancy cloud architecture.

We strongly recommend reviewing your pricing procedure and/or configuration model. Ideally, you can (partially) forego custom code and simplify your system:

• Does the custom code make sense in a front-end context vs. in the back end?
• Do you still know why the custom code was implemented in the first place and what exactly it is doing? Is the business value still justifying custom code?
• Can the same or similar result be achieved by standard functionality?

One approach is to avoid customer code in the first place by using extensions provided by SAP. This is a win-win: it simplifies customizing resp. modeling and lowers TCO on customer side while the code works in the cloud engine as well.

Pricing

All SAP pre-delivered ABAP user-exits were analyzed; about 60 relevant routines were identified and implemented within the Pricing service.

Supported Standard Pricing Exits:

https://help.sap.com/docs/SAP_VARIANT_CONFIGURATION_AND_PRICING/60117f3b58cc4876b0cb33b5bc9a7b5f

A subset of pricing exits supported out-of-the-box in a Commerce scenario as documented here (choose your Commerce release):

https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/80c3212d1d4646c5b91db43b84e9db47/cbb57b253ba343bb8d6362da383d8aa7.html

Same for CPQ integration as pricing exits depend on supported pricing attributes
(choose your CPQ release):

https://help.sap.com/docs/SAP_CPQ/f80fbcd4f1c74232839c30ce26886f07/21b0e023c74744b6960d901c9a05619b.html

Configuration

SAP provides a library of predefined variant functions in back end and front end. Customers do not have to maintain any code to use them.

Examples:

• Conversion NUM <-> CHAR
• Various string operations (Concatenate, partial, length, comparison, …)
• Determine number of assigned values in multi-value characteristic
• Number of days between two dates

SAP delivered variant functions:

Conversions:

• SAP_VF_NUM_TO_CHAR
• SAP_VF_CHAR_TO_NUM

String Operations:

• SAP_VF_CONCATENATE
• SAP_VF_SUBSTRING
• SAP_VF_LENGTH
• SAP_VF_LEFT
• SAP_VF_RIGHT
• SAP_VF_COMPARE_STRINGS

Auxiliary functions:

• SAP_VF_COUNT_VALUES
• SAP_VF_DAYS_BETWEEN_DATES
• SAP_VF_CREATE_GUID
• SAP_VF_SYSTEM_ENVIRONMENT

See SAP Notes 2695561, 2790161, and related notes for attached documentation.

Extension framework to call custom code (loose coupling)

If there really is no way of preventing the use of (non-standard) custom code, we introduced a framework that permits the use of custom code via a loose coupling:

Variant functions and pricing exits are mapped to REST calls with well-defined APIs (and thus properly decoupled). The custom code may run in the SAP Business Technology Platform but could be executed in an arbitrary environment in arbitrary language.  

Overview

• The configuration or pricing engine calls the custom code via a REST call.
• Custom code can run anywhere/be implemented in any way – as long as it provides a REST API that respects the well-defined interface.
• In our administration UI, maintain two endpoints: one for (all) pricing exits and one for (all) variant functions.
• If you have multiple exits/functions, you need a dispatcher function or a case/switch statement.
• Requires well-defined interface: only variant functions are supported (not pfunctions) and in pricing only requirements, condition base formulas, scale base formulas, condition value formulas and group key formulas are supported.
• Function calls are traced and can be investigated in the administration UI.
• Supports different kind of authentications via the SAP Destination service.
• Via pilot note 2799818, variant functions in procedures allow multi-value characteristics as parameters (only in cloud engine):
  • If you must read values from multi-value characteristic(s) and/or write values to multi-value characteristic(s), then you cannot use variant functions in LO-VC but you must use pfunctions.
  • Custom pfunctions are not supported by the Variant Configuration service’s extension concept.
  • Workaround (only for procedures, not for constraints):
    • We provide a standard variant function, that tells you if your model is currently executed in VC or in the cloud (or in IPC).
    • We provide above pilot note that disables the VC syntax check, that does not allow you to call variant functions with multi-value characteristics.
    • You can request access to the pilot note via a ticket on component LOD-CPS: please choose the system where you want to implement the note when creating the ticket.
    • You use the standard variant function SAP_VF_SYSTEM_ENVIRONMENT from SAP Note 2790161 in your procedure.
    • If it returns VC as runtime environment, you execute your pfunction.
    • If it returns Cloud as runtime environment, you execute a new custom variant function with multi-value characteristics as input and/or output parameters.
    • That custom variant function would have an empty ABAP implementation in ERP and would only be implemented and executed in the cloud.
• Calling functions causes a performance overhead.
  • Input parameters can be cached in production tenants to avoid unnecessary calls.
  • There is a time-out so that the service is not blocked by outage or bad performance of custom code.
• With a “kill switch” you can disable all calls to the custom web services.
• Keep in mind: avoid custom code if possible, use extensions only where inevitable.

For more details, please refer to the Extension Guide for SAP Variant Configuration and Pricing.