In order to look at the content of a particular version:

• [In the explorer]

  Click on the version or fix you would like to view

  • The table is updated and shows a line for every object belonging to that version, indicating whether that object has been created or modified.
• [In the working section]

  Click on a filter to browse objects belonging to a certain class only.

  information: In order to precisely identify changes in CP pricing grids, factor grids or drawing grids, when looking at the content of a given version, a naming convention is used based on the concatenation of the following elements, separated with ‘~’:
• CP Primary Key (PK)
• PK of the pricing / drawing method
• Name(s) of the parent(s) method(s)
• PK of the pricing / drawing matrix
• Name of the matrix line variable
• Line range if necessary

  For instance, in the ‘Name’ column: wksMySpace/CP/cpMyCP~wksMySpace/PARAM/smMyMethod~root~wksMySpace/PARAM/pm MyMethod~myPGVar

In order to activate/de-activate a version:

• [In the explorer]

  Click on the icon of the version you would like to de-activate

• [In the menu toolbar]

  Click on the Active togglefield and set it to ‘Off’.

  The version is now de-activated. At runtime when specifying an application date without any ModelVersion, the CPQ Engine will retrieve the current active version (and will ignore all de-activated ones).

  The version is not removed from the caches unless a specific user action.

In order to delete a version:

• [In the explorer]

  Click on the icon of the version or fix you would like to delete

• [In the menu toolbar]

  Click on the delete function

  • [In the popup] Click on OK
    Warning: The deletion of a version is an administrative process that cannot be undone. It should be used under exceptional circumstances (E.g. Database clean up).

    You can use the version de-activation if the physical deletion of data is not required. If you plan to delete a version please ensure that:

  • The first version is removed before the second one, the second one before the third one … and so on.
• No user is active on this version during the deletion process:
  • Neither on the designer side

    Nobody should consult or modify objects of the version under deletion.

  • Nor on the runtime side

    No runtime session pointing to the version under deletion should be alive.

    To ensure that nobody is working on a version you plan to delete, we recommend that you de-activate this version 1 day before the removal (assuming that users do not keep a session alive more than 1 day and that they are not authorized to specifically launch the version you plan to delete)

• The database pre-cache is correctly removed
  • If you delete a version from CPQ Designer User interface, the database cache is automatically deleted when you delete a version
  • If you delete a version using APIs, you have to perform specific service calls to empty the pre-cache
• There is no gap between the versions
  • You may have to modify the application date of the previous/next version to ensure that the timeframe covered by the deleted version is covered by the next one.

    The eventual result of the version deletion will depend on the version hierarchy:

  • For the working version: will be deleted all objects created, modified or deleted with respect to the latest stable version. These operations will be lost.
  • For the latest stable version: all the operations belonging to this version will be merged with the ones in the working version.
  • For each other (historical) version: all the operations belonging to these versions will be merged with the subsequent version.

    Obviously, a version will be deleted along with all its fixes.

For specific projects with a very large number of Fixes, to improve the loading time of the Manage History screen, it is possible to hide the fixes under each version. Only the working fix and the last fix of each version will be displayed.

To do that, use the “Hide all fixes” button as shown below. If you would like to show the fixes again, click the “Show all fixes” button. See below.

The procedure to generate the full text index is the following:

First enter the “Create and Manage Versions” process on the dashboard and click on the “Manage history” tab.

• [In the Explorer]

  Click on the icon of the version or fix for which you would like to generate an index

• [In the menu toolbar]

SEARCH INDEX POLICY

In addition to the search indexation, parameters can be set in the SearchIndexPolicy.xml configuration file to set the scope of objects included in the search index.

The following elements set the scope of indexed data:

• RMO Text: you can either index all Text RMOs, or build a list of user types for which RMO Text will be indexed (by workspace) and a list of empty rmo type (default RMO) for which RMO Text will be indexed (by workspace).
• RMO File: you can index PDF files attached to objects as RMO File.
• Product Links: you can index all Product Links, or a list of links (by workspace)
  Note: on Product Links: Product Links tie a parent SI with its child. Whenever a match is found on the parent or child, both the parent AND child are returned by the search.

  There is one special case when PL and BP are activated: if the BP value is found on the Product Link itself, only the parent of the link is returned by the search engine, not the child.

In addition, two attributes drive the way results will be found by full-text search at runtime:

• Case Sensitivity: you can define if the full-text search should be case-sensitive or not.
• Search Mode: defines how full-text search will behave:
  • ACROSS_FIELDS: for an article to match the full-text search, all words typed in and separated by a space character must be found, but they may be found in separate fields (name, description, RMO, BP, PDF)
  • SINGLE_FIELD: for an article to match the full-text search, all words typed in and separated by a space character must be found in a single field
  • SENTENCE: for an article to match the full-text search, all words typed in and separated by a space character must be found in a single field and there should not be other words between them. Order of words is not taken into account. For example when searching "iPhone 7 Blue" you will get a result for an item with description "iPhone Blue 7" and for an item with description "iPhone 7 Blue" but an item with description "iPhone Blue 64Go 7" will not match. Please note that this search mode may be overridden in the search policy definition in the catalog layout file (fullTextSearchMode property) for a catalog search, and will be overridden in the catalog data provider definition for a search & add from a quote.
    information: The structure of the search index policy is the following:

`<?xml version="1.0" encoding="UTF-8"?>

`

All other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such. This product includes software developed by the Apache Software Foundation https://www.apache.org/