Overview
Admins can create Configuration Integrations for each Product Family to send Configuration data to a partner system when an Integration action is invoked on a Configurator within the Product Family.
A Configuration integration can be created with a partner system that requires Oracle CPQ Configuration data and meets one of the following requirements:
- A CRM system with a standardized integration with Oracle CPQ (Oracle Sales, Oracle On Demand, Salesforce, or Microsoft Dynamics) that accepts SOAP calls.
This Configuration integration will be accomplished through an Http Post integration. See the Http Post Integration section for more information.
- A system that accepts REST or SOAP calls.
This Configuration integration will be accomplished through a Custom integration. See the Custom Integration section for more information.
Use Case: Oracle Commerce On Premise Integration
A Custom Configuration integration is used in CPQ’s integration with Oracle Commerce On Premise (Commerce). In this eCommerce scenario, when an eCommerce customer clicks the Add to Cart Integration action on the Oracle CPQ Configurator, an integration is triggered and the Oracle CPQ configXML file is sent to a Commerce Web Service, which uses the data to add the configured product to a Commerce shopping cart. A redirect URL is also defined within the Configuration integration so that the eCommerce customer is taken to the Commerce shopping cart page when the integration is triggered.
See the topic Oracle Commerce On Premise Integration for more information on the CPQ-Commerce integration.
Administration
Accessing the Configuration Edit Integration Page
- Click Admin to go to the Admin Home Page.
-
Click Catalog Definition in the Products section.
The Supported Products page opens.
-
Confirm that Product Families is selected in the Navigation drop-down menu and click List.
The Supported Product Families page opens.
-
For the Product Family with the integration you want to edit, select Integrations from the Navigation drop-down menu and click List.
The Edit Integration page opens.
The Integration Type selected determines if the integration is active, how the integration is executed, and what options appear on the Edit Integration page.
The following options can be selected for Integration Type:
| Integration Type | Description |
|---|---|
| None | The integration is inactive. Nothing will be sent to a partner system when the Integration action is invoked. The Edit Integration page can still hold values for an Http Post integration, but the integration will not be active unless Http Post is selected for Integration Type. |
| Http Post | A SOAP message (generated by the SOAP Generator XSL that is uploaded by the admin) will be sent to the endpoint URL of the CRM system that Oracle CPQ is integrated with. Oracle CPQ will parse the response from the CRM using the Result Parser XSL file that is uploaded by the admin. |
| Custom | A REST or SOAP payload containing the configXML file of the current Configuration is sent to the partner system’s endpoint URL (defined within a Data Table, see the section Defining the Custom Integration Partner Endpoint URL section for more information) when the Integration action is invoked. |
|
Client-side |
This integration type enables the sharing of data between Oracle CPQ and a partner site (e.g. this integration type can be used to enable "Add to Cart" functionality for Oracle CX Commerce). |
Http Post Configuration integrations use SOAP calls to send and receive data with the partner CRM system.
The following properties are available on the Edit Integration page when Http Post is selected for Integration Type:
| Property | Description |
|---|---|
| Name | The displayed name of the Integration action’s button in the Configurator. |
| Variable Name | The variable name of the Integration action that will be used by the system when needed. |
| Hide in Reconfiguration |
Determines whether or not the Integration action will be present on the Configurator during reconfiguration of the product.
|
| Description | An optional description of the integration for admin reference. |
| ID Field |
If Oracle CPQ is integrated with Salesforce, the ID Field must hold the variable name of the Configuration attribute in the Product Family that will map to the Salesforce Opportunity ID. Note: If Oracle CPQ is integrated with a CRM other than Salesforce, the ID Field will not be on the Edit Integration page. |
| SOAP Generator XSL | The XSL file that will generate the SOAP call sent to the partner system when the Integration action is invoked. |
| Endpoint URL |
The SOAP API Endpoint of the CRM system where the SOAP call will be sent when the Integration action is invoked. The Endpoint URL for an Http Post Configuration Integration is the same Endpoint URL that is defined for an integration between CPQ’s Commerce module and the CRM system. To change the Endpoint URL, open a ticket on My Oracle Support. |
| Result Parser XSL | The XSL file that will parse the SOAP response from the CRM. |
The SOAP Generator XSL and Result Parser XSL files used in Http Post Configuration Integrations are similar to the corresponding files used in the Oracle CPQ Commerce module’s integration with a CRM.
If your Oracle CPQ site is integrated with a CRM, you can access these Integration XSL Files (to use them as starting points for creating Http Post Configuration Integration XSL Files) by opening a Commerce integration ( Admin > Process Definition > Integrations (from the Navigation drop-down) > Integration Name ).
Each XSL file must be modified in order to make it specific to Configuration as opposed to Commerce.
Custom Configuration integrations can use either REST or SOAP calls to send and receive data with the partner system.
The Partner URL, which is added to an Oracle CPQ Data Table, is the literal Partner Endpoint URL where the REST payload will be sent when the integration is invoked.
The terms “Partner URL” and “Endpoint URL” cannot be used interchangeably when discussing custom Product Family integrations.
| Property | Description |
|---|---|
| Name | The displayed name of the Integration action’s button in the Configurator. |
| Variable Name | The variable name of the Integration action that will be used by the system when needed. |
| Hide in Reconfiguration |
Determines whether or not the Integration action will be present on the Configurator during reconfiguration of the product.
|
| Description | An optional description of the integration for admin reference. |
| Action |
Determines whether or not the integration is active or inactive, and , and what the success and error messages will be for the integration.
|
| Endpoint URL |
The location where the user will be directed to after invoking the Integration action in the Configurator.
|
The Custom Integration Partner Endpoint URL(s), as well as the name(s) of operations that will be performed and the username of a partner user to perform the Web Service call(s), must be defined in an Oracle CPQ Data Table named INT_SYSTEM_DETAILS.
Each row in the Data Table must be have a distinct operation name that can be called by the advanced function within the Custom Configuration integration so that Oracle CPQ knows which partner username and endpoint to use when sending the REST/SOAP call. For example, a Data Table that contains four operations would use the following structure:
| INT_SYSTEM_DETAILS | ||
|---|---|---|
| {System-Operation1} | {Partner username to call Web Service} | {Web Service URL Endpoint for Operation 1} |
| {System-Operation2} | {Partner username to call Web Service} | {Web Service URL Endpoint for Operation 2} |
| {System-Operation3} | {Partner username to call Web Service} | {Web Service URL Endpoint for Operation 3} |
| {System-Operation4} | {Partner username to call Web Service} | {Web Service URL Endpoint for Operation 4} |
Using the structure above, the INT_SYSTEM_DETAILS Data Table for a Custom Configuration integration with Commerce On Premise could be:
| INT_SYSTEM_DETAILS | ||
|---|---|---|
| {ATG-Login} | webServiceUser | https://sample.atg.com/rest/login |
| {ATG-GetSessionNumber} | webServiceUser | https://sample.atg.com/rest/getsessionnumber |
| {ATG-Logout} | webServiceUser | https://sample.atg.com/rest/logout |
| {ATG-SyncQuote} | webServiceUser | https://sample.atg.com/rest/syncquote |
When Define Advanced Function is selected for Action, clicking Define Function will open a BML editor with the following characteristics:
-
configXML (an XML file generated by Oracle CPQ based on current Configuration data) is the default input.
Admins can access the current configXML file of a Configuration on the Configuration XML tab of the Pipeline Viewer. For more information, see the topic Pipeline Viewer.
- The expected return type is String.
-
Expected return format:
Status=[Success/Error]~Message=[any string]where
[Success/Error]specifies whether or not the message is a success message or an error message, and where[any string]is the body of the success/error message.For example:
Return "Status=Success~Message=Working";or
Return "Status=Error~Message=Error in Web Service call" - A Web Service call (or multiple Web Service calls) should be made within the function in order to send the REST/SOAP payload via
urldatabypost(in most cases) to the partner system.
When Define Advanced Function is selected for Endpoint URL, clicking Define Function will open a BML editor with the following characteristics:
-
configXML (an XML file generated by Oracle CPQ based on current Configuration data) is the default input.
Admins can access the current configXML file of a Configuration on the Configuration XML tab of the Pipeline Viewer. For more information, see the topic Pipeline Viewer.
- The expected return type is String.
- The expected return format is a simple string, which will be a full URL.
If an advanced function was defined and saved for the Endpoint URL of a custom Product Family integration, and then Simple is selected for the Endpoint URL and the integration is applied/updated, the advanced function that was previously defined will be cleared.
Administrators can configure a “Client-side” integration to add the Add to Cart button on a Oracle CX Commerce site. The “Client-side” integration enables the sharing of data between Oracle CPQ and Oracle CX Commerce.
| Property | Description |
|---|---|
| Name | The displayed name of the Integration action’s button, e.g. Add to Cart. |
| Variable Name | The variable name of the Integration action that will be used by the system when needed. |
| Hide in Reconfiguration |
Determines whether or not the Integration action will be present on the Configurator during reconfiguration of the product.
|
| Description | An optional description of the integration for admin reference. |
| Action |
Determines whether or not the integration is active or inactive, and , and what the success and error messages will be for the integration.
|
| Endpoint URL |
The location where the user will be directed to after invoking the Integration action in the Configurator.
|
Notes:
- The “Add To Cart” BML lists the top-level price as the model price. If administrators want the price to roll-up the prices of all child level items, uncomment lines 85 ( priceTotal = bomTotalPrice + priceTotal; ) and 165 ( priceTotal = priceTotal + atof(sPrice0); )
- The “Add To Cart” BML references File Manager locations. Administrators must modify the BML on a per site basis.
- Refer to the Integrating Oracle CX Commerce and Oracle CPQ Implementation Guide for detailed instructions.
