CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Learn About All Ways to Integrate to SAP CPQ

11 min read

The first version of SAP CPQ (Configure Price Quote) was released two decades ago and the application was reinvented for few times since then. From technical perspective, it means that lots of different integration technologies became part of the toolkit you can use to connect to SAP CPQ.
On the example of APIs (application programming interface), the application provides multiple types and flavors and it is not easy to see which option is the best match for your project requirements.

This article will try to give you a comprehensive, but short systematization of all different SAP CPQ connectors and also provide pros and cons for those.
The goal was that you have a one-pager that you can read and right away jump to the development of your integration toward SAP CPQ.


Table of Contents

SOAP APIs

This is the first web interface that SAP CPQ exposed and it was developed and intended to be used in the standard SOAP (Simple Object Access Protocol) paradigm.
We were constantly extending the list through the years and all of them you can find in the standard help pages.

Each method expects username and password for the action executor as parameters in the SOAP envelope and almost all have a single, main XML parameter where you are expected to package all input data.
The help pages will, as a rule, give you input and output XML (eXtensible Markup Language) schema, a list of input and output examples and a short description on the execution flow.

The APIs should be used when the time needed to develop SOAP calls is not a problem and with that you can rely on validation checks and security measures enforced by SOAP.
Another plus of these APIs is that they execute macro-level operations, meaning that for the most of the standard tasks you will need a single API call.
Later, you will learn about granularity of our REST (Representational State Transfer) APIs and a different level of effort needed to support tasks like creation of a single product.

The negative side of the APIs is that you have to work with large input XML schemes and provide values for multiple fields (not just for the required fields, but also for the fields without which your objects would contain incorrect business data). Let us say that you are to use the web method that creates a new quote, while your focus is on single element in that process. Quote is the biggest object is SAP CPQ and the parent for all objects used during quotation process - you will have to provide lots of data and you also may not know those, from the perspective of your current task. Atomic REST APIs might be a better choice for point-level operations. 

The APIs cover different administrative tasks as well as end-user side operations.

REST APIs

In parallel to the global paradigm shift from SOAP to REST, SAP CPQ was evolving and the UI (user interface) layer was fully replaced so the application gets responsive UI.
Other reimplementations were also completed or those are still gradually enrolling as planned, e.g., the version two of the engine was released and administration pages are being reimplemented to use newer technologies.

For all these efforts we have exposed lots of new APIs to enable the application functioning. We have also made a decision that all APIs that the applications itself uses will be exposed externally as public web methods.
This opened a vast new field of possible operations to execute inside of SAP CPQ, triggered from somewhere outside.

All groups of REST APIs and individual members of a class, with all JSON (JavaScript Object Notation) parameters described you can always find at this URL: https://yourCPQenvironment/webapihelp/index .

Almost all REST APIs expect a preceding authentication call to obtain a token and expect the token forwarded for all consecutive calls. More on how to authenticate to use our REST APIs you can read here, but in essence, as the application itself uses the same APIs it is expected that you build and maintain SAP CPQ session in an equivalent way, or forward a sessionless token in between calls.

Noticeable specifics of the REST APIs is that those are granular - it means that a single API call executes a single atomic operation that roughly corresponds to a single click inside of SAP CPQ.
If you, for example, create a single configurable product in the setup and open Network tab inside of the browser development tools, you will be able to track API calls that run for every click you execute inside of the Product Setup Wizard. All those web method calls you will have to chain to create a product programmatically by REST. With the SOAP that would be a single API call.

"How can that be a plus for the REST APIs from any perspective?" you might ask. The answer is the APIs were not developed with this perspective in mind - those were exposed to enable you to quickly execute a point change in SAP CPQ. If you, for example, need to update an attribute label inside of a product, you would need one call to authenticate and another short one to update the single attribute data inside of the product.
With SOAP APIs you would need to provide values for all product fields (which for a hierarchy might be quite a lot) and be careful not to overwrite something with incorrect data.
Also, with REST you can do many operations that are simply not supported with the original fixed SOAP schema: the product creation SOAP API enables you to create simple products and gives limited support for configurable products, while with REST you can do anything that the application itself can (in this example it means creation of systems of products).

So, the benefits of the APIs are the shear number of operations that you can execute and low development effort needed to build REST calls. 
The negative side might be large effort needed to execute macro-level operations and additional support needed for those (e.g. roll back of all successful operations to remove partial data if an API call in the middle of a sequence fails). Also, it is hard for external people to understand semantics of some JSON properties as Swagger focuses on data types only (especially as some properties are database ids) so assistance of SAP consultants might be needed in come cases.

Let us spent more time on individual types of APIs now.

APIs for End User Operations

When responsive design was introduced for all end user pages in the application, the whole UI was naturally re-coded. With this, for every operation executed in the UI another API was exposed to support it and all of those immediately became available for public use. 
You need to authenticate by calling /api/rd/v1/Core/LogIn method at first and then forward the obtained CSRF(Cross-site Request Forgery) header token and ASP.NET_SessionId and WebCom-lbal cookies for all consecutive web calls. You should mimic SAP CPQ application behavior and communicate with the server in the way the application itself does from a client browser.
A code example on how to do that you can find in this page.

Administration APIs

SAP CPQ setup pages were refurbished for few times, but the last reimplementation effort comprises gradual migration of setup pages to Angular framework. Next to the move toward a newer generation technology the goal is to get pages with faster response.
Only a few modules were migrated up to this point, although those being the key ones (products, attributes, users and few more). You can recognize migrated setup pages by containing setupSpa in the URL.

Here also, the gain is that all the new APIs became immediately available for external use.
One should call /basic/api/token API to authenticate at first and then forward the obtained OAuth 2.0 Bearer token to every following web call. Instructions are located in the mentioned authorization help page.

Web methods for scripts deployment are also another important set of APIs that belong to this group, but do not stem from the setup reimplementation effort.

APIs that Use JWT

Business requirements for a few groups of APIs were that they use JSON Web Token for authentication, to conform to a higher-level architecture.
To use one you should set Shared Secret in the application pages, use a public service to generate a JWT token and then just forward it with every next call.
More details on this you can find in the documentations page that covers authentication for REST web methods.

Quote 2.0 APIs

With the introduction of the new quote engine APIs were exposed that work just for that engine version.
Documentation for those you will find at https://yourCPQenvironment/webapihelp/index page in the "Quotes" grouping (URLs of the APIs start with "/api/v1/quotes").
Here you are expected to use Basic authentication and with that we have completed a very diversified list of authentication methods that we support.

Special Purpose REST APIs 

There are several REST APIs exposed to cover certain isolated tasks and they do not belong to the groupings above.
Two examples of this are: the web method for content files upload (supports several types of authentication) and the SCIM ( System for Cross-domain Identity Management) API (for user maintenance that conforms to the specification, and also uses the bearer token for authentication).

Expose a Custom API

One of the most popular CPQ integration potentials is possibility to expose a custom REST API, with any background logic, in just a few clicks. Namely, every global Python script is automatically exposed as an external API and you can invoke it on the following URL: http://yourCPQenvironment/customapi/executescript?scriptname=yourScriptName. 
You convert your script to an API fully by assigning a result value to ApiResponse environment variable. You can also set the script (hence the API itself) to expect input parameter values.
Read more about it in our development portal.

Events Subscription

The APIs above are a mechanism for you to trigger an action on CPQ side. But action triggering can be invoked from the opposite direction too, if you subscribe to a SAP CPQ domain event.
You perform the setup by choosing an event, entering a webhook URL (that our engine will call when the event occurs) and by entering the call parameters (like authentication data).
We currently publish an event when a product is added, updated or removed or when an order is placed, but the list of events will keep growing in future.
More information you can find here.

SAP CPQ as a Part of Intelligent Enterprise

As SAP CPQ, as all CX software, belongs to the architecture, there are integration flows already available in SAP API Hub that link different components of Customer Experience Solutions or S/4HANA to SAP CPQ. You do not have to recreate the integration content, just reuse the packages on your own instance of the Cloud Integration capability within SAP Integration Suite.
You can go further with exploiting the potentials of SAP Integration Suite and, for example, include SAP API Management in your system architecture to automatically forward the CSRF tokens in between calls, instead of coding all manually.

Conclusion

There are multiple means to integrate to SAP CPQ and it is quite hard to differentiate details for all of those, especially if you are just starting with SAP CPQ.
This article will give you a compact overview with all options listed, coupled with pros and cons and the most important use cases for each of those.
Our goal was that you feel self assured to start with development of connectors toward SAP CPQ, right after reading the article. Also do use the documentation links available in the article to get development details for each of the existing options.

Overlay