Our 3D CAD supplier models have been moved to 3Dfindit.com, the new visual search engine for 3D CAD, CAE & BIM models.
You can log in there with your existing account of this site.
The content remains free of charge.
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 (gelbe Felder) aufgebauten Bestellnummern (Artikelnummern) bzw. Typenschlüssel gefunden werden.
Via Bestellnummer / Typenschlüssel können Artikel auf PARTcommunity-Portalen sicher gefunden und korrekt bestellt werden. Querverlinkungen von Portalen ist möglich. Externe Assistenten können statt mit einer komplexen Deeplinkliste auch über den Aufruf von Artikelnummer/Typenschlüssel direkt Geometrie anfordern.
Initiale Artikelzuordnung von ERP-Nummer zu PARTsolutions Projekten auf Basis von Bestellnummer / Typcode wird vereinfacht, da diese absolut eindeutig sind ("Urfüllung").
(Für Details siehe auch Abschnitt 3.2.18.2, „Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE“.)
Im Rahmen des Auflösungscheck werden initial folgende Schritte benötigt
Klassifizierung nach CNSORDERNO und CNSTYPECODE.
Diese Aufgabe kann für den ganzen Katalog halbautomatisch mit dem Plugin Projekte im Batchlauf klassifizieren (siehe Abschnitt 5.13.6, „Projekte im Batchlauf klassifizieren“) erledigt werden.
Im Ergebnis erfolgt dann ein Eintrag unter Variable mit Bestellnummer und/oder Variable mit Typenschlüssel.
Aktualisieren Sie den Volltextsuchindex.
Siehe Abschnitt 1.3.8.6.2, „Kontextmenübefehle im Einzelnen“ in PARTsolutions / PARTcommunity4Enterprise - Handbuch für Administration.
Durchführen des Auflösungscheck (siehe nächster Abschnitt)
|
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.17.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.20, „Reverse TypeCode Regeleditor“).
Wenn die in den Kategorien Automatische Berechnung der Rückwärtssuche, Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen und Manuelle Rückwärtssuche vorhanden ausgewiesenen Projekte programmintern entsprechend gekennzeichnet werden sollen, klicken Sie unbedingt auf !
Damit die Funktionalität auch tatsächlich zur Verfügung steht, muss das Flag "Auto reverse Search" aktiviert werden.
Optional kann die Reverse search (automatic) für PCOM Portale aktiviert werden.
Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)
Aktivierung der Reverse Search (automatic) nach Katalog-Analyse/-Verbesserung
Erfolgt die Aktivierung der Reverse Search (automatic) nachgeschaltet zu einer Kataloganalyse, bzw. -verbesserung, sind folgende Schritte notwendig:
Analyse nach Katalogänderungen
Bei neuen oder geänderten Projekten prüft Testmeta, ob die Projekte auflösbar und ob die ORDERNUMBER/TYPECODE klassifiziert sind und gibt Warnungen / Fehler aus.
Was passiert, wenn eine Variable bzw. ein Variablenwert geändert wird?
Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.
Was passiert, wenn eine Variable entfällt oder dazukommt?
Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.
Wie ist der Ablauf, wenn eine Analyse der Katalogdaten durchgeführt werden soll?
Wenn sich Änderungen ergeben haben, ist die folgende Vorgehensweise für das Katalog-Update durchzuführen:
Aktualisieren Sie den Volltextsuchindex.
Siehe Abschnitt 1.3.8.6.2, „Kontextmenübefehle im Einzelnen“ in PARTsolutions / PARTcommunity4Enterprise - Handbuch für Administration.
Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)
Rufen Sie im Kontextmenü des gewünschten Katalogs unter Automatisierung den Befehl Reverse search ‒ Auflösungscheck (automatisch) auf.
Nach beendetem Prozess erscheint eine entsprechende Meldung, ob der Katalog vollständig aufgelöst werden kann oder nicht.
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.
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 nicht leer -> (siehe unten)
Unter $CADENAS_DATA/23dlibs/<catalogname>
wird die Datei resolvecheck.cfg
erzeugt, die
zentral alle Ergebnisse auflistet.
[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 | |
---|---|
Ein erneuter initialer Prüflauf kann via Konfig-Einstellung erzwungen werden. Siehe unten. |
Unter Projekte werden zwei Hauptebenen angezeigt, in denen unterschieden wird, ob Projekte überhaupt Wertebereiche besitzen. Projekte mit Wertebereichen werden detailliert in 4 Gruppen unterschieden.
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.
Manuelle
Rückwärtssuche vorhanden (auf Katalogebene gibt es eine
Konfigurationsdatei pnoreverse.cfg
)
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.17.6, „Reverse Search (automatisch) - Problematische Konstrukte vermeiden“. Ansonsten muss die Rückwärtssuche manuell erstellt werden. Siehe Abschnitt 5.8.2.1.15.20, „Reverse TypeCode Regeleditor“.
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).
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. |
Es werden alle Projekte unter Manuelle Erstellung der Rückwärtssuche notwendig exportiert.
Csv exportieren: Es werden alle gelisteten Projekte exportiert.
IS_COMPLEX: Wahr, wenn es gelbe Felder gibt, d.h. Sachmerkmal oder Geometriemerkmal
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
-1: Klassifikation fehlt. Vergleiche oben das Icon mit rotem Ausrufezeichen.
RANGES = Anzahl gelber Felder (wenn RANGES 0 ist, sieht man auch bei SUBTYPE 0)
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.
Mit Klick auf wird das Auflösungsflag gesteuert.[33]
Mit Klick auf bestätigen Sie, dass für die potentiellen x Projekte das Flag gesetzt wird.
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.
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.
Beim
Erstellen der CIP-Datei des Katalogs werden in der dir.prj
des Katalogs die
Ergebnisse des Auflösungscheck in Form folgender Schlüssel
gesetzt:
CATMETRICS_SEARCHABLE_PROJECTS
Anzahl von Projekten, die gefunden werden sollten (alle sichtbaren Projekte und Projekte mit SEARCHINDEX=ON)
Anzahl von Projekten mit einer klassifizierten Bestellnummer oder Typecode Variable
Anzahl von Projekten mit Bestellnummern und Typecodes, die über Lucene indexiert sind.
Anzahl von Projekten mit automatischer Berechnung der Rückwärtssuche
Anzahl von Projekten, die nicht mit der Reverse Search gefunden werden können
Hintergrundinformation: Um die Informationen
zu erstellen, die in die dir.prj
geschrieben werden,
werden die Konfigurationsdateien resolvecheck.cfg
und
qacheck.cfg
ausgewertet. In resolvecheck.cfg
schreibt
z.B. der ResolveChecker, für welche
Projekte eine automatische Reverse Search möglich ist. Es kann aber
sein, dass jemand ein Projekt geändert hat, ohne den ResolveChecker auszuführen.
In diesem Fall wird die Information aus der qacheck.cfg
gelesen, in
welche Testmeta schreibt, und Testmeta muss auf jeden Fall für
geänderte Projekte aufgerufen werden, da sie ansonsten nicht
publiziert werden können.
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=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
Definitionen für verwendete Variablenabkürzungen
Die folgende Abbildung zeigt den Einstellungsbereich für oben erwähnte Wertebereichsvariaben.
Beispiel 1 - Indirekte, berechnete Verwendung des Wertebereichs
|
Die Bestellnummer (NR) resultiert aus dem String 'xyz' und einem Merkmalalgorithmus.
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:
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
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
ALG1 kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert nicht gesetzt werden.
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
NR=RNG1RNG2
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
If a=1 then ALG='01' Else if a=2 then ALG='0$RNG.' End if
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.
[33] 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.