SAP CPQ API

CallidusCloud CPQ API allows external applications to call appropriate methods in CPQ. This helps automation of processes and eliminates the need to manually enter information. For example if company uses a separate application to process shipping information after an order has been placed, CPQ API can be used to update a quote with shipping information, such as tracking number, tracking URL, estimated shipping date, etc.

CPQ API supports quote updates, quote actions execution , customer creation and updates, user updates etc.

Currently, several web services are offered:

  • User level services (creating/updating carts, cart parameters, performing actions upon carts, etc…) Access these services via: <application root>/wsAPI/CPQAPI.asmx
  • Admin level services (updating users, companies…) Access these services via: <application root>/wsAPI/WsSrv.asmx

API EXAMPLE

A common use of CPQ’s API is to change the status of a quote. This type of action falls under the set of user side functions. This set includes the function performCartAction, which performs a workflow action. Based on the workflow setup, certain actions may be restricted because of a user’s rights and the cart/quote status.

This function is generally preceded by the function getActionList, which will return a list of actions available for the specified quote. One of these actions is then used in the performCartAction function.

To access CPQ’s API, use the following URLs:

  • <application root>/wsAPI/CPQAPI.asmx - this is the set of user level functions
  • <application root>/wsAPI/wssrv.asmx - this is the set of admin level functions

For example, to access the functions on the www.webcomcpq.com installation, the following URLs would be used: www.webcomcpq.com/wsAPI/CPQAPI.asmx and www.webcomcpq.com/wsAPI/wssrv.asmx. To view the list of functions that an API URL contains, enter the URL into any Web browser. Click an function to view the parameters that the function takes.

Using the desired installation’s URL, the performCartAction function will parameters: Username, Password, OrderID, ERPOrderID, and Action.
The Username and Password can be any user created on that installation. If the installation is multitenant, then the domain should be included with the Username preceded by a #. For example, to log in with the Username Joe that is in the Webcom domain, Joe#Webcom would be used.

Inactive users will not be able to perform any API calls, since their login data is checked, just as in the standard web based CPQ application. Don't forget that all API calls are case-sensitive.

CPQ workflow is applied to this user when performing an API function. In this example, the user needs to have the correct rights to change a quote’s status.

OrderID is the number of the quote that the function will be performed on. CPQ workflow is applied to the quote used. For this example, the quote needs to be in the correct status in order for a status change to be performed.

The ERPOrderID is an external system’s (ERP) order number that has been assigned to the CPQ OrderID. It is not required b ut is available if necessary.

The Action parameter is XML that describes the action being performed. The XML includes two elements to describe the action: ActionName and ActionParameters. ActionName is the name of the action that will be per formed on the cart/quote. ActionParameters is any parameters t he action needs. For this example, CHANGESTATUS is the ActionName and the new status is the ActionParameters .

The following is example XML that wil l change the statu s of a quote to “Quote Won”: <ACTION>-:$ <NAME>CHANGESTATUS</NAME>-:$ <PARAMETER name=“NewStatus” >Quote Won</PARAMETER>-:$ </ACTION>

More than one action may be included in the XML as long as it stays within the Action tag and includes the same elements.

After the performCarAction function is executed, XML is returned that gives the result of the action. If it was performed correctly, an OK will be included within a RESULT tag. If it failed to complete the action, a NOK will be included. The reason it failed will be included within a REASON tag. In addition, the status the function attempted to change the quote to will be included within a STATUS tag.

To review an example code that uses the CallidusCloud CPQ API click here

XWS (EXTERNAL WEB SERVICE)

XWS is a CPQ tag that allows external services to be called. It also allows for external, noncurrent, product data to be evaluated and used inside expressions. This tag should be used if a product needs to use data from another product, from any table located in the database, or from some other external source.

Syntax for the XWS tag is <*XWS(Fun ctionName, FunctionParameters)*>. For example <*XWS(GETPRODUCTPRICE, Product Name)*> or <*XWS(GETPRODUCTCATCODE, Product Name)*> or <*XWS(GETPRODUCTDESCRIPTION, Product Name)*> would return product price, product part number or product description for a referenced product. For more information on referenced products and product’s hierarchy, see the chapter on Produc t’s Hierarchy.

Another standard example of using the XWS tag would be using it to obtain data from an uploaded table in the database. The expression would likely look like: <*XWS(AUXTABLE, <table_name >, <return_column_name>, <condition_column_1_name>, <condition_value_1>, <condi tion_column_2_name>, <condition_value_2>…) *>. To avoid using a HTTP post with an XWS call, the AUX tag can be used instead to access uploaded table data. Using this tag instead ensures a faster result. The syntax is the same as XWS call except the AUX TABLE is removed and XWS is replaced with AUX.

For example, the following expression would be used to return a value from the field CONTRACT_PRICE in the table called CONTRACTS, where part number in the PartNumber field is equal to the config ured part number of the product: <*AUX(AUXTABLE,CONTRACTS,C ONTRACT_PRICE,PartNumber,<* ProductCode *>)*>

You are here: CallidusCloud SAP CPQ Online HelpSAP CPQ API