powered by CADENAS


Manual  Resolve check Reverse Search Use case

In order for parts to be found via search for Order number or Typcode, included those where CNSORDERNO and CNSTYPECODE are build by value range values, certain preconditions have to be fulfilled. If the number of possible combinations resulting from the value ranges is too big, no indexing will take place, but instead a Reverse Search is used, which enables finding of value range values as well.

The Resolve check checks if a catalog is resolvable in the full-text search index or if a Reverse Search is necessary. If the catalog is accordingly prepared, even in most complex cases searching for Order number or Type code will be successful.

The benefits of a Reverse Search are:

  • Always good search results since even order numbers / type codes built from complex value ranges values are found.

  • Via order number / type code articles on PARTcommunity portals can safely be found and correctly be ordered. No deeplinks are required.

  • Initial article assignment of ERP numbers to PARTsolutions projects on the base of order number / type code is simplified, as numbers are absolutely unique.

(For details also see Section, “Benefits of classification according to CNSORDERNO and CNSTYPECODE”.)

For this following steps are needed:

  1. Classification according to CNSORDERNO and CNSTYPECODE

  2. Full-text search index as of V11 SP8 (newly created)

  3. Performing a Resolve check

  4. If the catalog could not be completely resolved, adjustments for projects in the category "Manual creation of the reverse search necessary" have to be made.

    -> Check if respective projects can be resolved by structural changes (see Section, “Reverse Search (automatic) - Avoid problematic constructs”). Shouldn't this be possible, you have to manually create Reverse Configs of the type pnoreverse.cfg (see Section, “ Reverse TypeCode Rule Editor ”). Process in Detail
  1. In the context menu of desired catalog, under Automation, call the command Resolve check.

    [Note] Note

    Precondition: The full-text search index has to be up-to-date.

    After finished process a respective message is displayed whether the catalog could be completely resolved or not.

  2. Click OK.

    An initial Resolve check may take some time depending on catalog size. At further processes, if there were no or only little changes, the result is displayed after a few seconds, because only changed projects are tested.

    -> The results of the resolve check are displayed in detail.



All projects which can be resolved with the automatic reverse search are shown in the first category (Automatic calculation of the reverse search).

All projects which can be resolved with less than 50.000 variants are shown in category 2 (Inclusion in full text index up to max. 50,000 lines).

All projects which are resolved with the manual reverse are shown in category 3 (Manual reverse search available).

The rest is shown in category 4 (Manual creation of the reverse search necessary).

An effort estimation on realisation of highest search result quality is simply possible:

  • Category 4 is empty -> everything perfect

  • Category 4 is not empty -> Export list (see below)

Under $CADENAS_DATA/23dlibs/<catalogname> the file resolvecheck.cfg is created which centrally lists all results.

Exemplary excerpt:

path/project name.prj=GEOMDATE;table rows;variants;automatic search possible (0 or 1)
z.B. project.prj=01.01.2019;1;10;1
very below 
REVERSEANALYSIS=Date of last run

[Note] Note

A new initial check run can be forced via config setting. See below. User interface in detail


Under Projects there are two main levels where the distinction is made if projects have value ranges at all. Then projects with value ranges are differentiated in 4 groups:

  • Projects with value ranges:

    • Automatic calculation of the reverse search: For projects listed here the reverse search could be automatically calculated. A heuristic check did not reveal any errors.

      Under $CADENAS_DATA/index/cat/cat_<catalogname>/graph a file graphlookup.map is created. It contains all information cross-catalog down to project level.

    • Inclusion in full text index up to max. 50,000 lines

    • Manual reverse search available

    • Manual creation of the reverse search necessary

      May be an automatic resolving can still be achieved by some adjustments within the project structure. Notes on this can be found under Section, “Reverse Search (automatic) - Avoid problematic constructs”. Otherwise the reverse search has to be created manually. See Section, “ Reverse TypeCode Rule Editor ”.

  • Projects without value ranges:

Amount: Amount of variants per project. At Projects without value ranges the value means the number of table rows and at Projects with value ranges the number of variants or if empty then the variants are over 25.000 (limit value, no further check).


One or several parts are not resolved yet.
The subarea is resolved in one way or another and does not need to be regarded.
For this project, a manual reverse configuration is saved. (<project name>_pnoreverse.cfg available)
Project will be resolved and written in the Lucene index.


  • Export list:

    Exports all projects under Manual creation of the reverse search necessary.

    (simple listing of project paths)

  • Export csv file: All listed projects will be exported.

    Example: CSV opened in a spreadsheet program

    Example: CSV opened in a spreadsheet program

    • IS_COMPLEX: True, if there are yellow fields (object attribute or geometry attribute

    • SUBTYPE:

      • 0: no yellow fields

      • 1: yellow fields and Automatic calculation of the reverse search does not work. -> A manual creation of the reverse search is needed.

      • 2: yellow fields and Automatic calculation of the reverse search works

    • RANGES = Number of yellow fields (if RANGES is 0 then under SUBTYPE there is also 0)

    • ROWS = Number of table rows

    • AMOUNT = Number of variants (0 means there are more than 25000 in this project, no further counting from here)

    • HASPNO = For this project a _pnoreverse.cfg file is already available (manual configuration solution)

    • HASFLAG = The VARSEARCHRESOLVEORDERNO flag is already set to 1 and the project is taken in the Lucene index. You have to regard not to exceed the limit of 50000 per catalog.

  • Apply: This function concerns the categories Automatic calculation of the reverse search, Inclusion in full text index up to max. 50,000 lines and Manual reverse search available.

    Here in this example "Apply" would affect 9 projects (6+1+2).

    Here in this example "Apply" would affect 9 projects (6+1+2).

    Clicking on Apply affects the setting of the resolve flag.[34]

    • At projects in the section Inclusion in full text index up to max. 50,000 lines, the flag is set to 1.

    • At projects in the section Automatic calculation of the reverse search, the flag is set to 2.

    • Rows without variants or with an manual reverse configuration remain on 0.

    When clicking on Apply you confirm that the flag will be set for x potential projects.

    [Note] Note

    For this write permission is required for the respective catalog. Catalogs managed with SVN have to be checked out before and after modification checked in again. Special notes
  • When performing the automatic calculation at the reverse search under $CADENAS_DATA\index\cat\cat_resolve_check\graph a file graphlookup.map is created. This file will be ignored during the upload on online portals by default and has to be explicitly unlocked by CADENAS. (Only applies for < V11 SP8.)

  • Searching for Order number or type code only works in respective catalog on Online portals (in PARTdataManager over all catalogs as well).

    Always a search should usefully be performed in the desired catalog. However, sometimes a catalog consists of subcatalogs (for example, the Standard catalog of DIN, ISO, EN, etc.). In such a case please perform the search in the respective subcatalog. Config settings

The configuration file can be found under $CADENAS\libs\all\plugins\resolve_check.cfg:

The quality of the heuristic check for the automatic calculation of the reverse search can be adjusted via the first three keys.

If NEVERSKIPGRAPH is set to 1 (default is 0) at each run a complete recalculation is performed. (May be makes sense on testing purposes if the automatic generation has been enhanced.)

# maximum graphsearch searches per project
# maximum time in minutes to use when counting variants
# maximum time in minutes when checking graphsearch results
# always recheck the graphsearch even if we already have a saved result
NEVERSKIPGRAPH=0 Reverse Search (automatic) - Avoid problematic constructs

Definitions for variable abbreviations

  • RNG: Value range variable defining a range



  • NMD: Value range variable with distinct values

    Example 1


    Example 2 (Value range variable with naming)


  • ALG: Variable based on Attribute algorithm


    ALG = '$A.-$B.-$C.-$D.-$E.-$F.-$G.'

  • TAB: Variable with fixed values

  • NR: Value to be resolved (Order number / Type code)

Following figure shows the setting area for above mentioned value range variables.

Variable Manager -> Status

Variable Manager -> Status

Problematic constructs

  • Example 1 - Indirect, calculated use of value range

    [Note] Note

    When using algorithms following restriction applies:

    "Forwards" an algorithm results in a concrete calculated value, however, "backwards" the value used in the algorithm cannot be extrapolated, if an arithmetic operation is used; however, direct substitution works.


    The order number (NR) results from the string 'xyz' and an attribute algorithm.


    NR= xyz 500

    NR=xyz ALG

    Problem: ALG can be allocated to a unique value, however, due to above restriction the value of RNG cannot be detected.

    The same would apply for following slightly modified cases, because here, also an arithmetic operation is performed:

    • NMD=15,20,30

      NR= xyz 200

      NR=xyz ALG

    • Value range with step width. This would be adequate to a list of fixed values (10,20,30,...,100), however, also doesn't work due to above restriction.


      NR= xyz 500

      NR=xyz ALG


    A solution possibly could be to determine the value range values in a way that a calculation via ALG could be omitted and to use RNG directly to determine NR.

  • Example 2 - Forward resolving with algorithm

    [Note] Note

    The value of an algorithm cannot be set.


    ALG1: Forward to a value range

    ALG1=RNG (ALG1 is based on a value range)

    ALG2: IF Statement to determine the displayed order number value

    If ALG1='xyz' then
    Else If ALG1='abc' then
    End if


    ALG1 can be allocated to a unique value, however, the value cannot be set due to above restriction.


    In the IF statement, directly use the value range instead of the algorithm variable.

    If RNG='xyz' then
    Else If RNG='abc' then
    End if

  • Example 3 - No separator between value range variables




    There is no separator between the two value ranges so that it doesn't become clear from which single value the order number / type code (NR) is combined.

    For example, NR='3412' could be a combination of '341' and '2' or of '34' and '12'.

    Solution: Set a separator between value range variables. Then it is clear, which element belongs to value range variable 1 and which to value range variable 2.


  • Example 4 - No unique paths with same result



    RNG : 0,1,2,3

    If a=1 then
    Else if a=2 then
    End if


    ALG has multiple options which are partial equal. In the first condition "01" and in the second condition "01" as well.

    If ALG has the same value reverse resolving cannot be successful. It can not be determined if we have case "a=1" or "a=2". As a consequence a statement about RNG=1 is also wrong.

[34] Key VARSEARCHRESOLVEORDERNO. On project level it is in the project file, on catalog level in $CADENAS_DATA/23d-libs/<catalog name>/dir.prj. No GUI equivalent. Manual intervention not needed.