First of all, the deployment and use of CPQ require the installation of three kinds of environments having different roles:

• The first use of CPQ consists in the design and built of the Configurator (resp.Catalog) models i.e. the creation of the complete configuration logic that catches the product knowledge to use it to drive the user during the configuration process (resp. i.e. the creation of the complete product repository and collection structure). This should be done in a ‘Development’ environment.
• Consecutively to the development phase, an environment should be defined for the pre-production environment used to test and validate the Configurator/Catalog models in the context of their integration in the information system.
• And finally, the production environment is the final environment that runs the application for the end users.

DEVELOPMENT ENVIRONMENT

The development environment concerns essentially the use of the Designer in order to design the models that represent the product knowledge. The design process of models is detailed in the reference document Designer User GuideNo Content found for /db/organizations/conga/repositories/current/content/documents/Production/Smart_CPQ/user_guide/designer_getting_started/designer_getting_started.dita.

In addition, all the tests on the correctness of the models must be performed in this environment:

• Unitary tests: tests on the validity of each object individually
• Consistency tests: tests of the consistency of the modeling objects with each other
• Functional tests: tests on the representativeness of the models compared to the product knowledge

The development environment is built according to the architecture of CPQ on:

• a database server
• an application server that deploy the Designer, the Configurator and the Catalog.
• a desktop/laptop with a web browser for each of the business user involved in the design process.

According to the number of business users, the servers can be installed on the same or on different physical machines.

Once the work has been done in the development environment, the repository contains the complete tested models that can be deployed in the pre-production environment.

PRE-PRODUCTION ENVIRONMENT

The pre-production environment should be totally similar to the production environment. Indeed, the pre-production environment is used to test technically and functionally the models within the integrated system: the pre-production environment is used as soon as the Configurator/Catalog is embedded into a tier application or when the services and/or web services of CPQ are used in an external application.

The pre-production environment tests should guarantee the integration of CPQ is correct and thus the models and the configuration processes are correctly restituted by the front application.

The pre-production environment is the integrated test environment: all components of the information system involved in the sales process should be represented so that any of these components could be tested and its behavior be validated including its interactions with the other systems.

PRODUCTION ENVIRONMENT

The production environment is the final environment. The complete integrated solution is deployed in the production environment after having been tested in the pre-production environment.

The production environment is sized and built to support -for the complete solution- the total user workload.

EXCHANGING DATA BETWEEN THE DIFFERENT ENVIRONMENTS

CPQ integrates two kinds of tools to support data exchange between the different environments. The primary level of tools that can be used consists in export and import tools that can be accessed within the Designer or can be used by calls to the dedicated APIs.

The second level is a complete Distribution Tool. This distribution tool relies on export and import functions and integrates in addition a transport layer with a subscription mechanism so that once a new version is released then this version is exported, convey to all the subscriber servers and imported in the subscriber server environment.

To get more details about these tools, please refer to the Designer User GuideNo Content found for /db/organizations/conga/repositories/current/content/documents/Production/Smart_CPQ/user_guide/designer_getting_started/designer_getting_started.dita.

To support an important number of simultaneous user connections, application servers are duplicated.

A logical (like Apache or IIS) or physical (like CISCO) external load balancer is needed to balance the user sessions to the different application servers.

The principle is quite simple, a client request is redirected to an application server node, and during all the client session, the same node must be used (sticky session parameter). Application server nodes have their own JVM and don’t share anything else that the database. This is a strong constraint for our Designer (2 simultaneous users can’t work on separate nodes and share their modifications) but it is adapted to our Configurator runtime (because sessions are totally independent).

In the Annexes, we will give an example of such configuration with apache and Linux.