 SAP Configure, Price and Quote APIs with OAuth2SAMLBearerAssertion |
 | SAP CPQ configure, price, and quote solution is part of the SAP Customer Experience solutions portfolio. Furthermore, SAP CPQ offers a reach palette of integration capabilities with other SAP Solutions, for instance, with SAP Commerce Cloud So how does SAP Configure, Price and Quote relate to SAP Kyma and SAP Cloud SDK? Surprise, surprise... |
Putting it all together
Table of Contents
- About me
- SAP CPQ APIs
- Per aspera ad astra. Solution brief.
- Setting up a SAP CPQ Trusted Application (OAuth2 client).
- SAP BTP sub-account and instance level destination definitions.
- Implementation and troubleshooting notes.
- SAP Cloud-SDK with built-in resilience middleware with Kyma runtime to the rescue
- DIY: SAML Assertion and the bearer access token
SAP CPQ APIs
From the documentation...
With API you can update quotes, execute quote actions, create customers or business partners, update users and so on.
For example, if a company uses a separate application to process shipping information after an order has been placed, SAP CPQ API can be used to update a quote with shipping information, such as a tracking number, tracking URL, estimated shipping date, and so on.
The focus of this brief is the SAP CPQ REST APIs with Token API Authentication as documented here: SAP CPQ API Documentation | SAP Help SAP CPQ API Documentation | SAP PDF. |  |
Per aspera ad astra. Solution brief and architecture
At the heart of the solution are:
- SAP CPQ tenant, SAP BTP, Kyma runtime and SAP BTP services.
- SAP BTP multi-tenancy model - with a standalone multi-tenant @sap/approuter deployed to a kyma cluster.
- SAP BTP destination service - with a single instance-level OAuth2SAMLBearerAssertion destination
- optionally one or more sub-account level S/4HANA Private and Public Cloud destinations
- standard SAP components and libraries/SDKs - meaning same application code is deployable to multiple runtime environments.
SAP CPQ easy with kyma-powered multi-tenant application
 |
Good to know:
- all destinations are consumed using
executeHttpRequestSAP Cloud-SDK method with a built-in resilience mechanism. - communication between the SAP approuter's frontend and kyma backend service is intrinsic (local) via the in-cluster mesh.
- on premise destinations are accessible via a supported kyma connectivity proxy component
Setting up a SAP CPQ Trusted Application (OAuth2 client)
Token API Authentication. OAuth 2.0 Assertion Profiles
OAuth 2.0 Assertion Profiles authentication is implemented in SAP CPQ with the aim of standardizing server-to-server authentication. This type of authentication allows administrators to generate an access token without relying on the logged-in user (no need to store passwords).
You will be asked to set up a Trusted Application (an OAuth2 client) with your SAP CPQ tenant and required to enter there an issuer URL.
Issuer - the URL of the system to which the access token needs to be issued. From that URL users will be accessing SAP CPQ .
With SAML bearer grant type, this must be the value of the SAML Assertion issuer.
The
redirect_uri is to be used only with the Authorization code grant type so best is to void it.You will also be provided with the client id, client secret and the token issuance endpoint. Please make a note of them as these values will no longer be available after you have saved the Trusted Application.
Once the OAuth2 application has been created you can choose between JWT and SAML bearer grant types as documented here: OAuth 2.0 Assertion Profiles | SAP Help.
Lets' assume you want to use the SAML bearer grant type as documented here: Generate SAML Bearer Grant Type | SAP Help
In a nutshell, a SAML bearer grant type consists of exchanging a BTP user identity against a bearer access token coming from a SAP CPQ tenant.
We shall be using an OAuth2SAMLBearerAssertion destination to implement the above grant type.
In a nutshell, a BTP user JWT token's user claim is used to create a SAML Assertion as to trigger an IDP-delegated authentication flow to eventually execute a remote (password-less and unmanned) login into SAP CPQ from a BTP application.
Furthermore, a SAML Assertion must be digitally signed with a private key of a signing certificate. That's why you need to provide a public x509 certificate of the signing key in the Trusted Application definition, as follows:
SAP CPQ OAuth2 configuration
The second parameter is the value of the user claim.
 | SAP BTP sub-account and instance level destination definitions |
The very fact the issuer must be a valid URL with the https scheme has another very important ramification.
Namely, that issuer URL requirement disqualifies the usage of a default destination service trust as explained below:
For the assertionIssuer property to work, one would need to have KeyStoreLocation and KeyStorePassword defined (a key pair) for a SAP CPQ destination.
Otherwise, as a fallback, the sub-account's trust key pair would be used, but these settings are configured to always use the issuer which doesn't have https://.
The solution here is to generate or upload a keystore (for example in a p12 file) through the Certificates button, and point KeyStoreLocation to the name of such certificate, with KeyStorePassword as the appropriate password if applicable. Then the assertionIssuer property of a destination would work.
In other words, you must use your own keystore with both private and public keys instead and declare the issuer URL via a destination assertionIssuer property. Please refer to this gist for further details.
Examples of SAP CPQ destination definitions
In order to test these definitions you will need to provide a BTP user JWT token that will have your SAP CPQ user's claim (for instance
user_name if NameId selected in SAP CPQ OAuth2 client definition, as depicted above)Then, you could test the CPQ destinations leveraging SAP Cloud-SDK, for instance:
https://<approuter host>/srv/harmony?destination=cpq-anywhere&path=/customapi/executescript?scriptname=GetOpportunityQuotes
{
"data": [
{
"Quotes": [
{
"DateCreated": "<DateCreated>",
"Offer_Exp_Date": "<Offer_Exp_Date>",
"EditableforSAP": null,
"QuoteEngine": "Quote 1.0",
"TotalSummary": {
"TotalRevenue": 0,
"Service": 0,
"Cloud": 0,
"TotalContractValue": 0,
"OnPremise": 0
},
"OnPremiseRevenue": false,
"DealHealth": "High Risk",
"ContractStart": "<ContractStart>",
"ProcessTypeCode": null,
"IsECS": false,
"ServiceRevenue": false,
"QuoteNumber": "<QuoteNumber>",
"LinkedServicesContract": "New Contract",
"CMSID": "",
"CloudRevenue": true,
"Currency": "EUR",
"QuoteStatus": "Quote In Progress",
"Description": null,
"ValidUntilDate": "<ValidUntilDate>",
"Total": 0,
"ProcessType": "",
"WriteAccess": true,
"IsMain": true,
"QuoteStatusId": 45,
"RestructureType": null,
"PSBundleExtConfigFlag": false,
"ReadAccess": true,
"VisibletoChannelPartner": null,
"ContractEnd": "<ContractEnd>",
"WorkAtRisk": false
}
],
"OpportunityId": "<OpportunityId>"
}
]
}or...simply using a
curl command as explained here.Implementation and troubleshooting notes
During the implementation of the SAP CPQ APIs I have encountered a number of major road blocks. And, to a large extent, both kyma runtime and SAP Cloud-SDK have proven very helpful in overcoming them.
I have gathered a number of implementation and troubleshooting notes to help explain what it was and how it was addressed, namely:
- SAP Cloud-SDK with built-in resilience middleware with Kyma runtime to the rescue
- DIY: SAML Assertion and the bearer access token
- SAP Cloud SDK destinations | SAP Cloud SDK
Per aspera ad astra. Who am I?
You can follow me in SAP Community: piotr.tesny
SAP Kyma Community and SAP BTP, Kyma runtime Q&A Tags
Be balsamiq;
- SAP Managed Tags:
