WSDL Overview with Web Services 1.0
Overview
To support a flexible business model, there is a need to provide a way to generate the interface for SOAP interaction in a dynamic manner. This will allow the client to define and make changes to their product, configuration and commerce details and easily generate an interface reflecting the latest changes. To suffice the above requirement, a programmatic way to generate the interface description is needed. The generated WSDL can then be used to generate a SOAP message using standard open source tools including ApacheWSDL2Java. The soap interaction can be automated using the generated WSDL.
- Based on existing SOAP message the WSDL currently will support only the RPC style SOAP interaction.
- Since the current SOAP message defines its own structure and data types literal encoding will be followed to create the SOAP message on our defined schema.
- As of now since interaction is limited only to SOAP over HTTP, the current requirement is to provide the SOAP interaction with support for HTTP as the transport protocol.
Required Fields
Oracle CPQ has 9 WSDLs that define the web services and how to access them. Each WSDL has required fields that must be inputted into the request. There are also required fields that are returned when a web service has successfully processed and when web service is unsuccessful. There are other fields that can be inputted or returned but are not required to have a successfully processed web service or be populated in the response back from the web service. The fields listed below are the ones that are marked as required by the WSDL. These are fields that must always be populated or are returned after a web service is executed.
Administration
Types of WSDL
| Generic |
Basic description of interface common across clients |
The generic WSDL is based on the abstract interface design which independent of any configuration done by FullAccess user of a particular client. Thus this WSDL remains common across all the clients and represents the basic structure of the SOAP message which can be used for interaction between SOAP server and the client. The SOAP message generated based on this WSDL cannot be used directly to perform any operation but is useful for understanding the basic SOAP message structure to be used and explaining the client's SOAP functionality. |
| Specific |
Interface description used to send SOAP message and varies as per the changes by FullAccess user. |
The specific WSDL represents the WSDL, which varies for each client based on their own specified set up including parts, commerce and other modules. This WSDL is used for generating the SOAP message and communication between the SOAP server and the client. Also whenever some changes are affected by the admin this WSDL is generated again for reflecting the latest changes. |
WSDL per Module
Whenever you makes changes to specific set-ups to the above-mentioned areas, this WSDL must be regenerated. Look at the table below to understand WSDL regeneration for individual sections.
| Security
|
Since the SOAP XML for these operations remains the same independent of changes done by FullAccess user the high level and concrete WSDL are same for Security Service.
WSDL is available by default. It has to be regenerated only when a company's base information is modified (for example, supported languages/currencies, and so on.) |
| Commerce
|
Generic WSDL: The high level WSDL will be made independent of any defined processes and therefore the <document> and <attribute> elements within it, will not be defined. Since other elements are common for all processes and already defined in the BM system the WSDL should generate the SOAP message without the document attributes.
Specific WSDL: The concrete WSDL is process specific, to specify the document attributes of various documents and sub-documents defined by FullAccess user in a Commerce Process. Thus one concrete WSDL will be generated per Commerce Process defined. This WSDL is automatically generated every time a Commerce Process is deployed.
|
| Configuration
|
Following the commerce approach, configuration has a common high level and concrete WSDL. For deployed segments, the WSDL is automatically generated at the time of deployment. For the non-deployable segments, the WSDL can be generated manually from the web services section.
Note: For deployable segments, WSDL cannot be generated from the Generate WSDL page.
|
| Parts
|
Generic WSDL: This WSDL being independent of any administration set up, will show all the available fields of custom attributes irrespective of whether they are used or not. This way WSDL remains independent of any given configuration and can be used to generate a SOAP message, since custom fields not used are not considered.
Specific WSDL: The concrete WSDL will change based on number of custom attributes defined by each FullAccess user. Therefore each time the FullAccess user modifies and deploys custom attributes, the WSDL will be regenerated. This WSDL will only define the custom attributes that are used. The WSDL will also specify the properties of the custom attributes as defined by the FullAccess user, such as whether this attribute is required, if it’s a menu type item, and so on.
|
| Price Book Associations
|
WSDL is available by default. It has to be regenerated only when a company’s base information is modified (for example, supported languages/currencies, and so on.). Generic and Specific WSDL are the same for Price Book Associations. |
| Data Tables
|
Generic WSDL: The high level or generic WSDL will be common across all different tables. To retain the generic property of this WSDL, all the default DB column names of BM_SCRIPT_TABLE will be made XML elements. This makes the WSDL independent of any table and describes the basic SOAP message structure of different operations of Data Tables Service.
Specific WSDL: For each table, a different WSDL needs to be generated representing the specific columns of a given table. WSDL is automatically generated whenever the table definition is modified. If a table does not have any rows, a row must be added and the table definition updated, before the WSDL can be generated. The current SOAP message structure will be similar to the SOAP request and responses generated from a given concrete WSDL of a given table.
|
| Groups |
|
| Users |
|
| Exchange Rates |
|
Related Topics
See Also
