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
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:
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 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
*>)*>
