powered by CADENAS

Manual

Manual

5.8.2.1.15.16. Auflösungscheck Reverse Search
5.8.2.1.15.16.1. Anwendungsfall

Damit Bauteile via Suche nach Bestellnummer bzw. Typcode gefunden werden können, auch die, bei denen CNSORDERNO und CNSTYPECODE aus Wertebereichswerten aufgebaut sind, müssen bestimmte Voraussetzungen erfüllt sein. Ist die Zahl der Kombinationsmöglichkeiten, die sich aus Wertebereichen ergeben zu groß, wird nicht indexiert, sondern eine Reverse Search eingesetzt, welche ebenfalls erfolgreiches Finden der Wertebereichswerte ermöglicht.

Der Auflösungscheck prüft, ob Kataloge im Volltextsuch-Index auflösbar sind oder ob eine Reverse Search notwendig ist. Ist der Katalog entsprechend vorbereitet, kann auch in den komplexesten Fällen erfolgreich mit Bestellnummer bzw. Typcode gesucht werden.

Die Benefits einer Reverse Search sind:

  • Immer gute Suchergebnisse, da eben auch die aus komplexen Wertebereichswerten aufgebauten Bestellnummern bzw. Typcodes gefunden werden.

  • Via Bestellnummer / Typcode können Artikel auf PARTcommunity-Portalen sicher gefunden und korrekt bestellt werden. Es werden keine Deeplinks mehr benötigt.

  • Initiale Artikelzuordnung von ERP-Nummer zu PARTsolutions Projekten auf Basis von Bestellnummer / Typcode wird vereinfacht, da diese absolut eindeutig sind.

(Für Details siehe auch Abschnitt 3.2.17.2, „Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE“.)

Hierzu werden folgende Schritte benötigt:

  1. Klassifizierung nach CNSORDERNO und CNSTYPECODE

  2. Volltextsuchindex ab V11 SP8 (neu erzeugt)

  3. Durchführen des Auflösungscheck

  4. Falls der Katalog nicht vollständig aufgelöst werden konnte, sind Anpassungen für die Projekte unter Kategorie "Manuelle Erstellung der Rückwärtssuche notwendig" vorzunehmen:

    -> Prüfen Sie, ob die betreffenden Projekte durch strukturelle Umstellungen aufgelöst werden können (siehe Abschnitt 5.8.2.1.15.16.6, „Reverse Search (automatisch) - Problematische Konstrukte vermeiden“). Sollte dies nicht möglich sein, müssen manuell Reverse-Konfigs vom Typ pnoreverse.cfg erstellt werden (siehe Abschnitt 5.8.2.1.15.17, „Reverse TypeCode Regeleditor“).

5.8.2.1.15.16.2. Ablauf im Detail
  1. Rufen Sie im Kontextmenü des gewünschten Katalogs unter Automatisierung den Befehl Auflösungscheck auf.

    [Hinweis] Hinweis

    Voraussetzung: Der Volltextsuchindex muss aktuell sein.

    Nach beendetem Prozess erscheint eine entsprechende Meldung, ob der Katalog vollständig aufgelöst werden kann oder nicht.

  2. Klicken Sie auf OK.

    Ein initialer Auflösungscheck kann je nach Kataloggröße einige Zeit in Anspruch nehmen. Hat sich bei erneutem Aufruf nichts oder wenig verändert, wird nach wenigen Sekunden wieder das Ergebnis angezeigt. Es werden nur geänderte Projekt getestet.

    -> Die Ergebnisse des Auflösungschecks werden detailliert angezeigt.

    Auflösungsergebnisse

    Auflösungsergebnisse

Alle Projekte, die mit der Automatischen Rückwärtssuche gelöst werden können, landen in der ersten Kategorie (Automatische Berechnung der Rückwärtssuche).

Alle Projekte, die bis zu insgesamt 50.000 Varianten aufgelöst werden können, erscheinen in Kategorie 2 (Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen).

Alle Projekte, die mit der Manuellen Rückwärtssuche gelöst wurden, kommen dann in Kategorie 3 (Manuelle Rückwärtssuche vorhanden).

Der Rest landet in Kategorie 4 (Manuelle Erstellung der Rückwärtssuche notwendig).

Eine Aufwandsabschätzung zur Erreichung höchster Suchergebnisqualität ist einfach möglich:

  • Kategorie 4 ist leer -> alles perfekt

  • Kategorie 4 ist nicht leer -> Liste exportieren (siehe unten)

Unter $CADENAS_DATA/23dlibs/<catalogname> wird die Datei resolvecheck.cfg erzeugt, die zentral alle Ergebnisse auflistet.

Beispielhafter Ausschnitt:

[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

[Hinweis] Hinweis

Ein erneuter initialer Prüflauf kann via Konfig-Einstellung erzwungen werden. Siehe unten.

5.8.2.1.15.16.3. Benutzeroberfläche im Detail

Rubriken

Unter Projekte werden zwei Hauptebenen angezeigt, in denen unterschieden wird, ob Projekte überhaupt Wertebereiche besitzen. Projekte mit Wertebereichen werden detailliert in 4 Gruppen unterschieden.

  • Projekte mit Wertebereichen:

    • Automatische Berechnung der Rückwärtssuche: Für die hier aufgelisteten Projekte konnte die Rückwärtssuche automatisch berechnet werden. Eine heuristische Überprüfung hat keine Fehler ergeben.

      Unter $CADENAS_DATA/index/cat/cat_<catalogname>/graph wird eine Datei graphlookup.map erzeugt. Diese enthält katalogübergreifend alle Informationen bis hinunter auf Projektebene.

    • Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen

    • Manuelle Rückwärtssuche vorhanden

    • Manuelle Erstellung der Rückwärtssuche notwendig

      Evtl. lässt sich durch gewisse Anpassungen innerhalb der Projektstruktur eine automatische Auflösung doch noch erreichen. Hinweise hierzu finden Sie unter Abschnitt 5.8.2.1.15.16.6, „Reverse Search (automatisch) - Problematische Konstrukte vermeiden“. Ansonsten muss die Rückwärtssuche manuell erstellt werden. Siehe Abschnitt 5.8.2.1.15.17, „Reverse TypeCode Regeleditor“.

  • Projekte ohne Wertebereiche:

Anzahl: Anzahl der Varianten pro Projekt. Bei Projekte ohne Wertebereiche ist der Wert gleichbedeutend mit der Anzahl Tabellenzeilen und bei Projekte mit Wertebereichen gibt der Wert die Anzahl der Varianten an bzw. wenn leer, dann sind die Varianten über 25000 (Limitwert, weiter wird nicht geprüft).

Icons

Ein oder mehrere Teile unter diesem Knoten sind noch nicht gelöst.
Der Teilbereich ist auf die eine oder andere Art gelöst und braucht keine Aufmerksamkeit mehr.
Zu diesem Projekt ist eine manuelle Reversekonfiguration hinterlegt. (<projektname>_pnoreverse.cfg vorhanden)
Projekt wird aufgelöst in den Luceneindex geschrieben.

Schaltflächen

  • Liste exportieren:

    Es werden alle Projekte unter Manuelle Erstellung der Rückwärtssuche notwendig exportiert.

    (einfache Auflistung der Projektpfade)

  • Csv exportieren: Es werden alle gelisteten Projekte exportiert.

    Beispiel: CSV geöffnet in Tabellenkalkulationsprogramm

    Beispiel: CSV geöffnet in Tabellenkalkulationsprogramm

    • IS_COMPLEX: Wahr, wenn es gelbe Felder gibt, d.h. Sachmerkmal oder Geometriemerkmal

    • SUBTYPE:

      • 0: keine gelben Felder

      • 1: gelbe Felder und Automatische Berechnung der Rückwärtssuche geht nicht. -> Es wird eine manuelle Erstellung der Rückwärtssuche benötigt.

      • 2: gelbe Felder und Automatische Berechnung der Rückwärtssuche geht

    • RANGES = Anzahl gelber Felder (wenn RANGES 0 ist, sieht man auch bei SUBTYPE 0)

    • ROWS = Anzahl der Zeilen in der Tabelle

    • AMOUNT = Anzahl der Varianten (0 bedeutet es gibt mehr als 25000 in diesem Projekt, weiter wird nicht gezählt)

    • HASPNO = Zu diesem Projekt ist eine _pnoreverse.cfg Datei schon vorhanden (manuelle Konfigurationslösung)

    • HASFLAG = Das VARSEARCHRESOLVEORDERNO Flag ist hier schon auf 1 gesetzt und Projekt kommt in Lucenesuche. Muss beachtet werden, um nicht über das Limit von 50000 pro Katalog zu kommen.

  • Anwenden: Die Funktion betrifft die Kategorien Automatische Berechnung der Rückwärtssuche, Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen und Manuelle Rückwärtssuche vorhanden.

    Hier im Beispiel würde "Anwenden" 9 Projekte betreffen (6+1+2).

    Hier im Beispiel würde "Anwenden" 9 Projekte betreffen (6+1+2).

    Mit Klick auf Anwenden wird das Auflösungsflag gesteuert.[34]

    • Bei Projekten in der Rubrik Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen wird das Flag auf 1 gesetzt.

    • Bei Projekten in der Rubrik Automatische Berechnung der Rückwärtssuche wird das Flag auf 2 gesetzt.

    • Zeilen ohne Varianten oder mit einer manuellen Resolvekonfiguration bleiben auf 0.

    Mit Klick auf Anwenden bestätigen Sie, dass für die potentiellen x Projekte das Flag gesetzt wird.

    [Hinweis] Hinweis

    Hierfür werden Schreibrechte auf dem betreffenden Katalog benötigt. SVN-verwaltete Kataloge müssen zuvor ausgecheckt werden und nach der Modifizierung wieder eingecheckt.

5.8.2.1.15.16.4. Besondere Hinweise
  • Bei der automatischen Berechnung der Rückwärtssuche wird unter $CADENAS_DATA\index\cat\cat_resolve_check\graph eine Datei graphlookup.map erzeugt. Diese Datei wird beim Upload auf Online-Portale standardmäßig ignoriert und muss zur Verwendung explizit von CADENAS freigeschaltet werden. (Gilt nur für < V11 SP8.)

  • Die Suche nach Bestellnummer oder Typbezeichnung funktioniert auf Online-Portalen nur im betreffenden Katalog (in PARTdataManager auch über alle Kataloge).

    Sinnvollerweise wird man eine Suche immer im gewünschten Katalog durchführen. Manchmal besteht ein Katalog aber aus Unterkatalogen (der Normenkatalog beispielsweise aus DIN, ISO, EN, etc.). In einem solchen Fall führen Sie die Suche bitte im betreffenden Unterkatalog aus.

5.8.2.1.15.16.5. Konfig-Einstellungen

Die Konfigurationsdatei findet sich unter $CADENAS\libs\all\plugins\resolve_check.cfg:

Die Qualität der heuristischen Überprüfung bei der automatischen Berechnung der Rückwärtssuche kann mittels der ersten drei Schlüssel eingestellt werden.

Wird NEVERSKIPGRAPH auf 1 gesetzt (Default ist 0), wird bei jedem Lauf eine komplette Neuberechnung durchgeführt. (Zu Testzwecken evtl. sinnvoll, wenn die automatische Generierung verbessert wurde.)

[COMMON]
# maximum graphsearch searches per project
MAXHEURISTICS=1000
# 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.16.6. Reverse Search (automatisch) - Problematische Konstrukte vermeiden

Definitionen für verwendete Variablenabkürzungen

  • RNG: Wertebereichsvariable die einen Bereich definiert

    Beispiel:

    [10:100]
  • NMD: Wertebereichsvariable mit konkreten Werten

    Beispiel 1

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

    Beispiel 2 (Wertebereichsvariable mit Benennung)

    1,'txt1',2,'txt2',...
  • ALG: Variable basierend auf Merkmalalgorithmus

    Beispiel:

    ALG = '$A.-$B.-$C.-$D.-$E.-$F.-$G.'
  • TAB: Variable mit festen Werten

  • NR: Aufzulösender Wert (Bestellnummer / Typecode)

Die folgende Abbildung zeigt den Einstellungsbereich für oben erwähnte Wertebereichsvariaben.

Variablenmanager -> Status

Variablenmanager -> Status

Problematische Konstrukte

  • Beispiel 1 - Indirekte, berechnete Verwendung des Wertebereichs

    [Hinweis] Hinweis

    Bei der Verwendung von Algorithmen gilt folgende Einschränkung:

    Ein Algorithmus ergibt "vorwärts" immer einen konkreten berechneten Wert, aber "rückwärts" kann der im Algorithmus verwendete Wert nicht erschlossen werden, wenn eine arithmetische Operation verwendet wird; direkte Substitution hingegen funktioniert.

    Beispiel:

    Die Bestellnummer (NR) resultiert aus dem String 'xyz' und einem Merkmalalgorithmus.

    RNG=[10:100]

    NR= xyz 500

    NR=xyz ALG
    ALG=10*RNG

    Problem: ALG kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert von RNG nicht ermittelt werden.

    Gleiches würde auch für folgende leicht abgewandelte Fälle gelten, da auch hier eine arithmetische Operation durchgeführt wird:

    • NMD=15,20,30

      NR= xyz 200

      NR=xyz ALG
      ALG=10*NMD
    • Wertebereich mit Schrittweite. Das würde einer Liste von festen Werten entsprechen (10,20,30,...,100), funktioniert aber aufgrund obiger Einschränkung trotzdem nicht.

      RNG=[10:100/10]

      NR= xyz 500

      NR=xyz ALG
      ALG=10*RNG

    Lösung:

    Eine Lösung könnte evtl. darin bestehen, die Wertebereichswerte so zu bestimmen, dass eine Berechnung mittels ALG unterbleiben kann und direkt RNG zur Bestimmung von NR verwendet wird.

  • Beispiel 2 - Vorwärts-Auflösung mit Algorithmen

    [Hinweis] Hinweis

    Der Wert eines Algorithmus kann nicht gesetzt werden.

    Beispiel:

    ALG1: Vorwärts zu einem Wertebereich

    ALG1=RNG (ALG1 fußt auf einem Wertebereich)

    ALG2: IF Statement zur Bestimmung des angezeigten Bestellnummerwertes

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

    Problem:

    ALG1 kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert nicht gesetzt werden.

    Lösung:

    Verwenden Sie im IF-Statement direkt den Wertebereich anstatt der Algorithmus-Variablen.

    If RNG='xyz' then
    ALG2=123
    Else If RNG='abc' then
    ALG2=789
    End if
    NR=DIN ALG2
  • Beispiel 3 - Kein Trenner zwischen Wertebereichsvariablen

    Beispiel:

    NR=RNG1RNG2

    Problem:

    Es gibt keinen Trenner zwischen den zwei Wertebereichen, so dass nicht klar ist, aus welchen Einzelwerten Bestellnummer/Typecode (NR) zusammengesetzt wurde.

    NR='3412' könnte eine z.B. eine Kombination aus '341' und '2' sein oder aus '34' und '12'.

    Lösung: Setzen Sie einen Trenner zwischen die Wertebereichsvariablen, dann ist klar, welches Element zur Wertebereichsvariablen 1 und welches zur Wertebereichsvariablen 2 gehört.

    NR=RNG1-RNG2
  • Beispiel 4 - Keine eindeutigen Pfade mit gleichem Ergebnis

    Beispiel:

    ALG:

    RNG : 0,1,2,3

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

    Problem:

    ALG hat mehrere Optionen, die teilweise gleich sind. In der ersten Bedingung "01" und in der zweiten Bedingung "01".

    Wenn ALG denselben Wert annimmt, kann die Rückauflösung nicht gelingen. Es kann nicht entschieden werden, ob der Fall "a=1" oder "a=2" vorliegt. Damit ist dann sekundär auch eine Aussage über RNG=1 falsch.



[34] Schlüssel VARSEARCHRESOLVEORDERNO. Auf Projektebene steht dieser in der Projektdatei, auf Katalogebene in $CADENAS_DATA/23d-libs/<katalogname>/dir.prj. Keine GUI-Entsprechung. Manuelles Eingreifen ist nicht nötig.