Thursday, May 11, 2023

#968 - OIC for Oracle CPQ


This post covers using the Oracle CPQ adapter as well as the generic OIC REST adapter to interface with Oracle CPQ. The use case is very simple - set the Prepared By Title value for a set of Quotes, the latter known as Transactions in CPQ.

Oracle CPQ from an Integration Perspective

For those who don't know - Oracle CPQ = Configure, Price, Quote. This is one of the CX SaaS family of apps; often used together with another CX app such as Oracle Engagement Cloud or SFDC.

Before drilling down into OIC for CPQ, let's look at CPQ itself. A Quote in CPQ, as already stated, is known as a Transaction. Let's look at one of these - 

A quote essentially is comprised of a header section and then the individual line items.

The CPQ UI uses the CPQ REST apis - and it's easy to check out which are being invoked - 


Now, when it comes to updating a quote/transaction, we need to know about CPQ's collaborative quoting. This allows multiple users to work on the same quote simultaneously. 

We will see this explicitly when it comes to the OIC integration - here we will need 2 invokes of CPQ - the first is to "open" a quote and the second takes care of the update. The first invoke will return a cacheId and this will be used for the update along with the quoteId to identify the quote/transaction. Again, this 2 phase approach is necessary for collaborative quoting.

I now update the Quote header, title field in the UI - and then check which api has been invoked.

The actual url is - 


Ok, so let's try this out the se case in OIC.

Create an OIC Connection for CPQ

Create the CPQ Integration

I begin with setting up some variables - offset and limit will be used for fetching the quotes from CPQ.

I will iterate over the batch read until no more quotes are returned - 

Now to the first use of the CPQ connection - here we get a collection of Transactions (yes, transactions = quotes in CPQ speak).

I map the following fields to the similarly named variables I created earlier - 

Then comes a Switch on whether Quotes have been returned - The condition is configured as follows - 

The Otherwise Path just flips the variable to 'false' - 

I add an Assign action to Route 1 - this is essentially a placeholder for logic to come later. I also increment the offset - 

I then test the integration - I see the fetch count is 15 - 

I execute the following in a browser 

and see the totalResults = 306

This fits in well as the counter started at 0, so we had 16 fetches - 15 with 20 quotes and 1 with 6 quotes.

Back to the Integration Canvas - I now iterate over the quotes returned and select each for update. I use the same REST api as I see, when doing the same in the CPQ UI - _open_transaction

I specify this as follows in OIC - 

I need to map the following field - 

The source is here - 

I also need to set the target field to a value of "-1". This ensures a new cache id will be generated.

The next step is to update the quote header and save the quote. We use the cleanSave_t api. 

This is the modus operandi in OIC - here I use the generic OIC REST adapter, just to show how that works with CPQ - 

Creating a Generic REST Connection to Oracle CPQ

I will invoke the following api - 

btw. the api docs are here.

Back in the design canvas - I have dropped the REST connection and named it SaveUpdatedQuote.

It is configured as follows - 

The full request payload can be found at the end of the post. In this simple scenario, I am only updating the following field - Title. 

You will see this field in the Documents structure of the request payload. 

The mapping is simple - 

Map the id from the current quote.
Map the Cache instance id returned by the _open invoke. 
I also hardcode the Prepared By Title to "Set By OIC".

I run the integration and validate in Oracle CPQ -

The Prepared by Title for each quote has been set accordingly - 

We can improve throughput for this use case by splitting the integration in 2 - 

Integration 1 - reads from CPQ in batches of 20, while integration 2 does the _open and _cleanSave. Both integrations are async, with integration 2 giving us a degree of parallelism. 


No comments: