5.8.2.1.15.30.  Reverse Search - Resolve check (automatic)
5.8.2.1.15.30.1.  Resolve check - Use case

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.

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.

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

  • Also see Section 5.12.7.2, “Benefits of classification according to CNSORDERNO and CNSTYPECODE”.

5.8.2.1.15.30.2.  Resolve check - Preconditions/Preparations
  1. Classification according to CNSORDERNO and/or CNSTYPECODE

    [Important]Important

    Information on how to differentiate between CNSORDERNO and CNSTYPECODE, meaning when to classify according to what, can be found under Section 5.12.7, “Classification according to CNSORDERNO / CNSTYPECODE ”.

    [Note]Note

    Classifying is a required precondition, otherwise an error message appears when executing the context menu command Reverse Search - Resolve check (automatic).

    This task can be performed semi-automatically for the whole catalog with the plugin "Batch classification of projects" (see Section 5.12.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 displayed.

  2. Update the full-text index (if not already done by automated process).

    If in PARTproject, setting options, the option Automatically update full-text search index when changes are made has not been activated, you have to update manually via PARTadmin now (see Section 1.3.8.6.3, “Full-text search index” in PARTsolutions - Administration Manual).

5.8.2.1.15.30.3.  Resolve check - Catalog analysis
  1. Download the current SVN state.

    Download changed files in directories / projects from server

    Download changed files in directories / projects from server

  2. Update full-text search index (if not already done in an automated process).

    If in PARTproject, in the setting options, the option Automatically update full-text search index when changes are made has not been activated, you have to update manually via PARTadmin now (see Section 1.3.8.6.3, “Full-text search index” in PARTsolutions - Administration Manual).

  3. Before starting with the analysis make sure that you have deleted the file resolvecheck.cfg in your local catalog folder. Otherwise the resolve check will use the existing results from the existing file.

    [Note]Note

    After each analysis, under $CADENAS_DATA/23dlibs/<catalogname>, the configuration file resolvecheck.cfg is created, which lists all results.

    Before performing the run again, delete this file in order to get a "clean" result.

    Exemplary excerpt:

    [REVERSEANALYSIS]
    pfad/projectname.prj=GEOMDATE;Tabellenzeilen;Varianten;Automatische Suche möglich 
    (0 oder 1)z.B. project.prj=01.01.2019;1;10;1
    ...
    ...
    ganz unten 
    [COMMON]
    REVERSEANALYSIS=Datum des letzten Laufs

    A new initial check can also be forced via config setting. See Section 5.8.2.1.15.30.8, “ Resolve check - Config settings”.

  4. In the context menu of the desired catalog, under Automation, execute the command Reverse Search - Resolve check (automatic).

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

  5. 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 in the dialog box Results.

    Example:

    Example on "Results"

    Example on "Results"

  6. Check the results.

    The column Amount shows 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).

    In the column Projects, the value in brackets shows how many projects there are in the respective category.

    The following table shows the meaning of icons.

    One or several parts under this node are not yet resolved. The blue exclamation mark stands for different cases:

    • Projects with value ranges

    • The automatic search takes too much time

    • Manual creation of the reverse search necessary

    Classification is missing (projects were ignored)

    An error message is displayed.

    This subsection is resolved in one way or another and does not require special attention:

    • Automatic calculation of the reverse search

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

    • Projects without value ranges

    ----------------------------------------------------------------------------------------

    • Projects with an irrelevant value range (Dimension attribute)

      The automatic resolving was successful, however, the order number or the type code contain an unallowed value range variable of the type Function attribute or Dimension attribute.

      [Note]Note

      Details on this can be found under Section 7.8.13, “ Identification type ”.

    For this project, a manual reverse configuration is saved. (<project name>_pnoreverse.cfg available)
    Project will be resolved and written in the Lucene index.

    The following table shows the meaning of the individual categories.

    Under Projects, there are two main levels differentiating if projects have value ranges at all. Projects with value ranges are subdivided in 4 categories.

    Projects with value ranges Category Meaning
     

    1

    Automatic calculation of the reverse search: For projects listed here, the reverse search could not be calculated automatically. 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 down to project level cross-catalog.

    2

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

    3

    Manual reverse search available (on catalog level there is a configuration file pnoreverse.cfg)

    4

    Manual creation of the reverse search necessary

    All projects not assigned to category 1-3, will appear in category 4.

    May be that it is possible to achieve an automatic resolving by certain adjustments in the project structure. Notes on this are found under Section 5.8.2.1.15.30.9, “ Reverse Search - Resolve check (automatic) - Avoid problematic constructs”. Otherwise the reverse search has to be created manually. See Section 5.8.2.1.15.32, “ Reverse TypeCode Rule Editor ”.

    Projects without value ranges   

    Effort estimation is simply possible:

    • Category 4 is empty -> everything perfect

    • Category 4 is not empty

      If the catalog could not be completely resolved, adjustments for projects in category (4) Manual creation of the reverse search necessary are needed:

      -> Check, if the affected projects can be resolved by structural changes (see Section 5.8.2.1.15.30.9, “ Reverse Search - Resolve check (automatic) - Avoid problematic constructs”). If this is not possible, reverse configs of the type pnoreverse.cfg have to be created (see Section 5.8.2.1.15.32, “ Reverse TypeCode Rule Editor ”).

      Export list and Export csv file will provide detailed information.

      • -> Button Export list

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

        (simple listing of project paths)

      • -> Button Export csv file

        All listed projects will be exported.

        Example: CSV opened in a spreadsheet program

        Example: CSV opened in a spreadsheet program

        • PRJ_PATH: Path to corresponding project

        • NN: Standard number

        • QASTATE: Current QA state of project

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

        • SUBTYPE:

          • 0: Project does not contain any value ranges (yellow fields).

          • 1: Project contains value ranges (yellow fields) and Automatic calculation of the reverse search does not work. -> A manual creation of the reverse search is needed.

          • 2: Project contains value ranges (yellow fields) and Automatic calculation of the reverse search works, so that these projects can be automatically resolved.

          • -1: Classification according to CNSORDERNO or CNSTYPECODE is missing. Compare above icon with red exclamation mark.

          • -2: Project contains value ranges (yellow fields); Auto Reverse Search runs into a timeout. -> Manual reverse scripts are needed.

        • RANGES: Number of value ranges (yellow fields). If RANGES is 0, then SUBTYPE is also 0)

        • ROWS = Number of table rows

        • AMOUNT = Number of variants

        • HASPNO: For this project a manually created reverse script (_pnoreverse.cfg) 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.

        • REPORT: Detailed report on how the algorithm is resolving the order number. Field is only filled, if a manual script is required.

5.8.2.1.15.30.4.  Resolve check - Activation
  1. Check out the SVN catalog (if not already done for the catalog analysis).

  2. Update full-text search index (if not already done for the catalog analysis).

    [Note]Note

    This is required in order for projects listed in category Inclusion in full text index up to max. 50,000 lines to be indexed anew.

  3. Run Resolve Check via context menu command Reverse Search - Resolve check (automatic) (if not already done for the catalog analysis).

  4. Click Apply.

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

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

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

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

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

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

    • Rows without variants or with an manual reverse configuration (3) 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. Check-in the SVN catalog.

  6. In order for the Reverse Search to be really available, the flag "Auto reverse Search" has to be activated.

    [Note]Note

    The activation can only be performed by an authorized person!

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

    [Note]Note

    The activation can only be performed by PCOM Admins!

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

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

    Details on this can be found under Section 6.10, “ Publish catalog ”.

5.8.2.1.15.30.5.  Resolve check - 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 really 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 (except already done automatically).

      See Section 1.3.8.6.3, “Full-text search index” in PARTsolutions - Administration Manual.

    3. Perform Resolve check

    4. Resolve check -> Apply

    5. Update full-text search index again.

    6. Check in catalog into SVN.

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

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

5.8.2.1.15.30.6.  Reverse Search – Test Order Number Search
5.8.2.1.15.30.6.1. Functional description

In PARTproject -> Project selection -> context menu of catalog (or subdirectory or project) -> Automation, you can find the function Reverse Search – Test Order Number Search.[27]

With this you can check which parts from an automatically created list of order numbers or type codes (concatenated by values of yellow fields) can be found, so that you can be sure that these will lead to correct hits when searching with PARTdataManager, for example.

Furthermore you can check a certain list (either initially or the output result of an automatic generation after adjustments to optimize results have been performed).

Order number or type code search

Order number or type code search

5.8.2.1.15.30.6.2. Preconditions/Preparations

Perform the following steps before starting a test run:

  1. Always use latest released V12 version.

  2. Make sure that you have installed the current SVN catalog with the latest updates and changes on catalog.

  3. Make sure that you are doing a “fresh” resolve check.

    For this, under $CADENAS_DATA/23dlibs/<catalogname>, delete the configuration file resolvecheck.cfg before starting the resolve check.

  4. In PARTadmin, in the configuration file reverselookup.cfg, in the key generategraph, insert the catalog.

  5. Update display index + full-text search index in PARTadmin.

5.8.2.1.15.30.6.3. Example (testing automatically created list)
  1. Select catalog directory, subdirectory or project and click the context menu command Reverse Search – Test Order Number Search.

    Context menu command "Reverse Search – Test Order Number Search"

    Context menu command "Reverse Search – Test Order Number Search"

    -> The same-named dialog box is opened.

    Context menu command "Reverse Search – Test Order Number Search"

    Context menu command "Reverse Search – Test Order Number Search"

  2. Settings:

    • Destination path export list: Click the search button ... and choose a directory. (The export list will be saved in this directory.)

    • Amount per project: Amount of numbers to be tested

    • Open list after test: Yes/No

    • Storage method:

      • All in one list

      • Separate list per project

  3. Click on Start.

    -> A list with randomly generated order numbers is created (see progress bar under Generation of order numbers) and in a second step, these numbers are tested (see progress bar under Test the search).

    -> After the test run you will receive a summary of the result directly in the program.

    -> Furthermore the results are written into the automatically generated export list. The result occurs in the last column. Found numbers are marked with "OK", not found with "FAIL".

    The individual columns:

    • Order number: Tested order number

    • MIdent: MIdent of order number

    • Project: Tested project

    • Project path: Project path of tested project

    • Test result: OK/FAIL

    CSV file loaded in Excel

    CSV file loaded in Excel

  4. Optionally

    If there were failed searches and the Reverse Search functionality has been optimized, you can load and test the result list again by using the Load list button.

Example (initial testing of a list with defined order numbers/type codes)

Alternatively you can start testing with a list of defined order numbers/type codes. Then the setting under Amount per project is not relevant.

Start the process by clicking on Load list.

-> The directory set under Destination path export list is opened. Choose the desired CSV file.

[Note]Note

The structure of the list has to be as follows:

  • In the first line any column name

  • In the second line the catalog name with the exact spelling as it is used in the SVN

  • Then all lines with the order numbers or type codes to be tested

-> The function is executed and the results are written into the loaded CSV file.

The test result can be found in the last column. Found numbers are marked with "OK", not found with "FAIL".

5.8.2.1.15.30.6.4. Online testing
  1. Testing order number via "Reversemap Service"

    If the reverse search was already activated for the online usage, you can test order codes manually with the reversemap service.

    Just type in the URL in the browser and see if you get back the MIdent:

    https://webapi.qa.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1

    https://webapi.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1

    catalog = -> Catalog you want to search for

    part = -> Order code you want to search for

    exact = -> 1 (exact search for order code); 0 (ignore uppercase/lowercase)

    Result "OK"

    Example "mident"

    Example "mident"

    Result "Error"

    Example "error"

    Example "error"

  2. Test order codes on 3Dfindit portal or supplier portal

    You can also search for order codes on 3Dfindit portal or the supplier portal (config key has to be activated before it is working on supplier portal).

    Please make sure that you have already selected the catalog on 3Dfindit. The Order code search is not working in the standard search bar on 3Dfindit!

5.8.2.1.15.30.7.  Resolve check - 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.

  • 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 sub-catalogs (for example, the Standard catalog of DIN, ISO, EN, etc.). In such a case please perform the search in the respective sub-catalog.

  • 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 resolve_check.cfg and *.qacheck are evaluated. E.g., the ResolveChecker writes to resolve_check.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.30.8.  Resolve check - 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.30.9.  Reverse Search - Resolve check (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.




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

[27] Corresponding plugin files have to be stored under %CADENAS%/libs/all/plugins: resolve_check_tester.cfg, resolve_check_tester.def, resolve_check_tester.vbb