powered by CADENAS

Manual

Manual

5.8.2.1.15.18.  Reverse search ‒ Resolve check (automatic)
5.8.2.1.15.18.1. Use case

In order for parts to be found via search for Order number or Type code, 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 (article numbers) or type codes built from complex value ranges (yellow fields) values are found.

  • Via order number / type code, articles on PARTcommunity portals can safely be found and correctly be ordered. Cross-links between portals are possible. External assistants can directly request geometry by calling order number / type code instead of using a complex list of deeplinks.

  • 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 3.2.17.2, “Benefits of classification according to CNSORDERNO and CNSTYPECODE”.)

Within the scope of a Resolve check following initial steps are required

  1. Check out SVN catalog.

  2. Classification according to CNSORDERNO and CNSTYPECODE

    [Note] Note

    Classifying is a required precondition, otherwise an error message appears.

    This task can semi-automatically be performed for the whole catalog with the plugin "Batch classification of projects" (see Section 5.13.6, “ Batch classification of projects ”).

    Dialog box "Attribute Classification"

    Dialog box "Attribute Classification"

    This then results in an entry under Variable with Order Number and/or Variable with Type Code.

    [Note] Note

    In the course of Test directory/Test project (Testmeta) there will be a check, if an entry exists under Variable with Order Number and/or Variable with Type Code. The following figure shows the respective entry in the CNS classification. Here, the often used feature names CNSORDERNO and CNSTYPECODE are shown.

  3. Update the full-text search index.

    See Section 1.3.8.6.2, “Context menu commands in detail ” in PARTsolutions / PARTcommunity4Enterprise - Administration Manual.

  4. Performing a Resolve check (see next section)

    [Note] Note

    Classifying is a required precondition. See above.

  5. 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 5.8.2.1.15.18.6, “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 5.8.2.1.15.20, “ Reverse TypeCode Rule Editor ”).

  6. If the projects listed in the categories Automatic calculation of the reverse search, Inclusion in full text index up to max. 50,000 lines and Manual reverse search available shall be marked in the program, please click on Apply.

    [Note] Note

    Create the full-text search index again. This is required in order for the projects listed in the category Inclusion in full text index up to max. 50,000 lines to get indexed again.

  7. Check in the SVN catalog.

  8. In order for the functionality to be actually available, the flag "Auto reverse Search" has to be activated.

    [Note] Note

    The activation can only be performed by an authorized person!

  9. Optionally, the Reverse search (automatic) can be activated for PCOM portals.

    [Note] Note

    The activation can only be performed by PCOM Admins!

  10. Execute the command Generate QA catalog... (for testing)

  11. Execute the command Publish Live state... (fee-based)

Activation of Reverse Search (automatic) after catalog analysis / improvement

If the activation of Reverse Search (automatic) happens subsequently after a catalog analysis or improvement, the following steps are needed:

  1. Activation of the flag "Auto reverse Search"

    [Note] Note

    The activation can only be performed by an authorized person!

  2. Optionally, the Reverse search (automatic) can be activated for PCOM portals.

    [Note] Note

    The activation can only be performed by PCOM Admins!

  3. Execute the command Generate QA catalog... (for testing)

  4. Execute the command Publish Live state... (fee-based)

Analysis after catalog changes

  1. Basically:

    For new or changed projects, Testmeta will check if the projects are resolvable and if ORDERNUMBER/TYPECODE are classified and will issue warnings / errors - if necessary.

    • If something cannot be resolved according to Testmeta error message, there are two possibilities:

      • Reconstruction what shouldn't happen for new projects, according to modelling guidelines.

      • Using a manual reverse script, which shouldn't happen as well, according to modelling guidelines.

  2. What happens if a variable or variable value is changed?

    For all projects, which can be resolved by Automatic calculation of the reverse search, in this case, no further adjustments have to be made apart from new publication of the catalog.

  3. What happens if a variable is cancelled or added?

    For all projects, which can be resolved by Automatic calculation of the reverse search, in this case, no further adjustments have to be made apart from new publication of the catalog.

  4. What is the update procedure?

    If there are changes, this is the required approach:

    1. Check out catalog from SVN

    2. Update the full-text search index.

      See Section 1.3.8.6.2, “Context menu commands in detail ” in PARTsolutions / PARTcommunity4Enterprise - Administration Manual.

    3. Perform Resolve check

    4. Resolve check -> Apply

    5. Update full-text search index again

    6. Check in catalog to SVN

    7. Execute the command Generate QA catalog... (for testing)

    8. Execute the command Publish Live state... (fee-based)

5.8.2.1.15.18.2. Process in Detail
  1. In the context menu of desired catalog, under Automation, call the command Reverse search ‒ Resolve check (automatic).

    [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.

    Results

    Results

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:

[REVERSEANALYSIS]
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 
[COMMON]
REVERSEANALYSIS=Date of last run

[Note] Note

A new initial check run can be forced via config setting. See below.

5.8.2.1.15.18.3. User interface in detail

Sections

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 5.8.2.1.15.18.6, “Reverse Search (automatic) - Avoid problematic constructs”. Otherwise the reverse search has to be created manually. See Section 5.8.2.1.15.20, “ 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).

Icons

One or several parts are not resolved yet.

Classification missing

An error message is displayed.

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.

Buttons

  • 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

    • 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.

5.8.2.1.15.18.4. Special notes
  • When performing the automatic calculation at the reverse search under $CADENAS_DATA\index\cat\cat_resolve_check\graph eine Datei 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.

  • 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.

  • When generating the CIP file of a catalog, in the catalog's file dir.prj, the results of the resolve check will be set in the form of following keys:

    • CATMETRICS_SEARCHABLE_PROJECTS

      Number of projects which should be found (All visible projects and projects with SEARCHINDEX=ON)

    • CATMETRICS_REVERSE_CLASSIFIED

      Number of projects with a classified order number or type code variable

    • CATMETRICS_REVERSE_STATIC

      Number of projects without value ranges

    • CATMETRICS_REVERSE_CONFIG

      Number of projects with manual reverse scripts

    • CATMETRICS_REVERSE_LUCENE

      Number of projects with order numbers and type codes indexed by lucene

    • CATMETRICS_REVERSE_GRAPH

      Number of projects which can be solved via auto reverse search

    • CATMETRICS_REVERSE_FAILED

      Number of projects which can't be found by the reverse search

    Background information: In order to create the information which shall be written into the dir.prj, the configuration files resolvecheck.cfg and *.qacheck are evaluated. E.g., the ResolveChecker writes to resolvecheck.cfg for which projects an automatic Reverse Search is possible. For the case that someone changed a project without executing the ResolveChecker the information is read from *.qacheck, where Testmeta is writing to, and for changed projects Testmeta has to be called in any case, because otherwise publication is not possible.

5.8.2.1.15.18.5. 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.)

[COMMON]
# maximum graphsearch searches per project
MAXHEURISTICS=10000
# maximum time in minutes to use when counting variants
MAXTIME=15
# maximum time in minutes when checking graphsearch results
MAXTIMETEST=15
# always recheck the graphsearch even if we already have a saved result
NEVERSKIPGRAPH=0

5.8.2.1.15.18.6. Reverse Search (automatic) - Avoid problematic constructs

Definitions for variable abbreviations

  • RNG: Value range variable defining a range

    Example:

    [10:100]

  • NMD: Value range variable with distinct values

    Example 1

    'x','b','y',...

    Example 2 (Value range variable with naming)

    1,'txt1',2,'txt2',...

  • ALG: Variable based on Attribute algorithm

    Example:

    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.

    Example:

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

    RNG=[10:100]

    NR= xyz 500

    NR=xyz ALG
    ALG=10*RNG

    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
      ALG=10*NMD

    • 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.

      RNG=[10:100/10]

      NR= xyz 500

      NR=xyz ALG
      ALG=10*RNG

    Solution:

    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.

    Example:

    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
    ALG2=123
    Else If ALG1='abc' then
    ALG2=789
    End if
    NR=DIN ALG2

    Problem:

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

    Solution:

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

    If RNG='xyz' then
    ALG2=123
    Else If RNG='abc' then
    ALG2=789
    End if
    NR=DIN ALG2

  • Example 3 - No separator between value range variables

    Example:

    NR=RNG1RNG2

    Problem:

    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.

    NR=RNG1-RNG2

  • Example 4 - No unique paths with same result

    Example:

    ALG:

    RNG : 0,1,2,3

    If a=1 then
    ALG='01'
    Else if a=2 then
    ALG='0$RNG.'
    End if

    Problem:

    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.