The first version of SAP CPQ (Configure Price Quote) was released two decades ago and since then the application has been reinvented few times. From a technical perspective, it means that lots of different integration technologies became part of the toolkit you can use to connect to SAP CPQ.
For example, for APIs (application programming interface), the application provides multiple types and flavours and it is not easy to see which option is the best match for your project requirements.
We will try to give you a short but comprehensive summary of all the different SAP CPQ connectors with their pros and cons. The goal being that you have a one-pager that you can read and immediately apply to the development of your SAP CPQ integration.
SOAP APIs
What is it?
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.
Each method expects a 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 SAP 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.
When to use it?
The APIs should be used when you have the time to develop SOAP calls. 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 majority of the standard tasks you will need a single API call.
Some downsides
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). For example: Let's say that you use a web method that creates a new quote, but a user's focus is on single element in that process. Quotes are the biggest object in SAP CPQ and the parent of all objects used during the quotation process - the user would have to provide lots of data which they may not know from the perspective of their current task. Atomic REST APIs might be a better choice for point-level operations.
REST APIs
What is it?
In parallel to the global paradigm shift from SOAP to REST, the SAP CPQ UI (user interface) layer evolved and was fully replaced so that the application gets a responsive UI.
Other re-implementations were also completed or and there are also those that are still being developed or released, e.g., version two of the engine was released in which administration pages use newer technologies.
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 can be read here, but in essence, as the application itself uses the same APIs, it is expected that you build and maintain an SAP CPQ session in an equivalent way, or forward a sessionless token in between calls.
Why use it?
Noticeable specifics of REST APIs are that these are granular - it means that a single API call executes a single atomic operation that roughly corresponds to a single click in SAP CPQ.
If you, for example, create a single configurable product in the setup, you will be able to track API calls that run for every click you execute inside the Product Setup Wizard. You will have to create a chain of all those web method calls to create a product programmatically with REST. With SOAP, this 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 that 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 a product, you would need one call to authenticate and another short one to update the single attribute data.
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, the 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.
Is there even something negative?
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 only on data types (especially as some properties are database ids) so assistance of SAP consultants might be needed in come cases.
The individual API Types
Let us spend some more time on individual types of APIs now. It will get a bit technical from this point onwards.
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, all of which 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 mimicSAP CPQ application behaviour and communicate with the server in the way the application itself does from a client browser.
Administration APIs
SAP CPQ setup pages were refurbished a few times, but the last re-implementation comprises the gradual migration of setup pages to an Angular framework. Next to the move towards a newer generation technology, SAP's goal is to improve pages response time.
Only a few modules were migrated up to this point with 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.
A /basic/api/token API call should first be made to authenticate 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 script deployments are also another important set of APIs that belong to this group, but do not stem from the setup re-implementation effort.
APIs that Use JWT
The business needs of some APIs required the use of 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.
Quote 2.0 APIs
With the introduction of the new quote engine, APIs were exposed that work just for that engine version.
Here you are expected to use Basic authentication, resulting in SAP completing a very diversified list of authentication methods that CPQ supports.
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 integrations is the 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 full API by assigning a result value to the ApiResponse environment variable. You can also set the script (hence the API itself) to expect input parameter values.
Events Subscription
The APIs above are a mechanism for you to trigger an action on the 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).
CPQ currently publishes an event when a product is added, updated or removed or when an order is placed, but the list of events will be added to by SAP in the future.
SAP CPQ as a Part of Intelligent Enterprise
As SAP CPQ, like all CX software, belongs to the SAP architecture, there are integration flows readily available in the 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 everything manually.
Conclusion
There are multiple means to integrate to SAP CPQ and it is quite hard to differentiate the 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.
We want to provide the best information on CPQ. Want to know more or how our experts can help you implement and connect CPQ? Contact us!