5.8.2.1.16.
Automatisierung
5.8.2.1.16.26.
Reverse Search – Auflösungscheck
(automatisch)
|  |
| Zurück | Weiter |
- 5.8.2.1.16.26.1. Auflösungscheck - Anwendungsfall
- 5.8.2.1.16.26.2. Auflösungscheck - Voraussetzungen/Vorbereitungen
- 5.8.2.1.16.26.3. Auflösungscheck - Kataloganalyse
- 5.8.2.1.16.26.4. Auflösungscheck - Aktivierung
- 5.8.2.1.16.26.5. Auflösungscheck - Analyse nach Katalogänderungen
- 5.8.2.1.16.26.6. Reverse Search – Bestellnummernsuche Testen
- 5.8.2.1.16.26.7. Auflösungscheck - Besondere Hinweise
- 5.8.2.1.16.26.8. Auflösungscheck - Konfig-Einstellungen
- 5.8.2.1.16.26.9. Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden
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.
Damit Bauteile via Suche nach Bestellnummer [Order number] bzw. Typcode gefunden werden können, auch die, bei denen CNSORDERNO und CNSTYPECODE aus Wertebereichswerten aufgebaut sind, müssen bestimmte Voraussetzungen erfüllt sein.
Der Auflösungscheck [Resolve check] 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 [Order number] 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. Querverlinkung 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").
Siehe auch Abschnitt 5.12.7.2, „Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE“.
Klassifizierung nach CNSORDERNO und/oder CNSTYPECODE
![[Wichtig]](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/images/important.png)
Wichtig Informationen zur Unterscheidung von CNSORDERNO und CNSTYPECODE, also wann nach was zu klassifizieren ist, finden Sie unter Abschnitt 5.12.7, „Klassifizierung nach CNSORDERNO / CNSTYPECODE “.
Diese Aufgabe kann für den ganzen Katalog halbautomatisch mit dem Plugin Projekte im Batchlauf klassifizieren [Batch classification of projects] (siehe Abschnitt 5.12.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 (wenn nicht bereits automatisiert geschehen).
Sofern in den Einstellungsoptionen von PARTproject die Option Volltextsuchindex bei Änderungen automatisch aktualisieren [Automatically update full-text search index when changes are made] nicht aktiviert war, müssen Sie dies jetzt unbedingt selbst manuell via PARTadmin ausführen (siehe Abschnitt 1.3.3.6.6.3, „Volltextsuchindex “ in PARTsolutions Administration - Handbuch).
Laden Sie den aktuellen SVN-Stand herunter.
Geänderte Dateien in Verzeichnissen/Projekten vom Server herunterladen [Download changed files in directories / projects from server]
Aktualisieren Sie den Volltextsuchindex (wenn nicht bereits automatisiert geschehen).
Sofern in den Einstellungsoptionen von PARTproject die Option Volltextsuchindex bei Änderungen automatisch aktualisieren [Automatically update full-text search index when changes are made] nicht aktiviert war, müssen Sie dies jetzt unbedingt selbst manuell via PARTadmin ausführen (siehe Abschnitt 1.3.3.6.6.3, „Volltextsuchindex “ in PARTsolutions Administration - Handbuch).
Bevor Sie die Analyse starten, stellen Sie sicher, dass die existierende
resolvecheck.cfgin Ihrem lokalen Katalogverzeichnis gelöscht ist. Ansonsten wird der Auflösungscheck die bestehenden Ergebnisse aus der existierenden Datei verwenden.![[Hinweis]](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/images/note.png)
Hinweis Nach jeder Analyse wird unter
$CADENAS_DATA/23dlibs/<catalogname>die Konfigurationsdateiresolvecheck.cfgerzeugt, die zentral alle Ergebnisse auflistet.Löschen Sie diese vor einem erneuten Lauf, um wieder ein sauberes Ergebnis zu erhalten.
[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
Ein erneuter initialer Prüflauf kann auch automatisiert via Konfig-Einstellung erzwungen werden. Siehe Abschnitt 5.8.2.1.16.26.8, „ Auflösungscheck - Konfig-Einstellungen“.
Rufen Sie im Kontextmenü des gewünschten Katalogs unter Automatisierung [Automation] den Befehl Reverse Search – Auflösungscheck (automatisch) [Reverse Search - Resolve check (automatic)] auf.
Nach beendetem Prozess erscheint eine entsprechende Meldung, ob der Katalog vollständig aufgelöst werden kann oder nicht.
Ein initialer Auflösungscheck [Resolve check] 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 im Dialogfenster Auflösungsergebnisse [Results] detailliert angezeigt.
Die Spalte Anzahl [Amount] zeigt die Varianten pro Projekt. Bei Projekte ohne Wertebereiche [Projects without value ranges] ist der Wert gleichbedeutend mit der Anzahl Tabellenzeilen und bei Projekte mit Wertebereichen [Projects with value ranges] gibt der Wert die Anzahl der Varianten an bzw. wenn leer, dann sind die Varianten über 25000 (Limitwert, weiter wird nicht geprüft).
In der Spalte Projekte [Projects] gibt der Zahlenwert in Klammern an, wieviele Projekt es in der jeweiligen Kategorie gibt.
Die folgende Tabelle zeigt die Bedeutung der Icons.
Ein oder mehrere Teile unter diesem Knoten sind noch nicht gelöst. Das blaue Ausrufezeichen steht für verschiedene Möglichkeiten:
Klassifikation fehlt (Projekte wurden ignoriert) [Classification is missing (projects were ignored)]
Es erscheint eine Fehlermeldung
Der Teilbereich ist auf die eine oder andere Art gelöst und benötigt keine Aufmerksamkeit mehr:
----------------------------------------------------------------------------------------
Projekte mit nicht relevantem Wertebereich (Dimensionsmerkmal) [Projects with an irrelevant value range (Dimension attribute)]
Die automatische Auflösung war zwar erfolgreich, allerdings enthält die Bestellnummer bzw. der Typcode eine unzulässige Wertebereichsvariable vom Typ Funktionsmerkmal [Function attribute] oder Dimensionsmerkmal.
Hinweis Details hierzu finden Sie unter Abschnitt 7.8.14, „ Typ-Identifikation “.
Zu diesem Projekt ist eine manuelle Reversekonfiguration hinterlegt. (<projektname>_pnoreverse.cfg vorhanden) 
Projekt wird aufgelöst in den Luceneindex geschrieben. Die folgende Tabelle zeigt die Bedeutung der einzelnen Kategorien.
Unter Projekte [Projects] werden zwei Hauptebenen angezeigt, in denen unterschieden wird, ob Projekte überhaupt Wertebereiche besitzen. Projekte mit Wertebereichen werden detailliert in 4 Kategorien unterschieden.
Projekte mit Wertebereichen [Projects with value ranges] Kategorie Bedeutung Automatische Berechnung der Rückwärtssuche [Automatic calculation of the reverse search]: 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>/graphwird eine Dateigraphlookup.maperzeugt. Diese enthält katalogübergreifend alle Informationen bis hinunter auf Projektebene.Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen [Inclusion in full text index up to max. 50,000 lines]
Manuelle Rückwärtssuche vorhanden [Manual reverse search available] (auf Katalogebene gibt es eine Konfigurationsdatei
pnoreverse.cfg)Manuelle Erstellung der Rückwärtssuche notwendig [Manual creation of the reverse search necessary]
Alle Projekte, die nicht Kategorie 1-3 zugeordnet werden, erscheinen in Kategorie 4.
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.16.26.9, „ Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden“. Ansonsten muss die Rückwärtssuche manuell erstellt werden. Siehe ???.
Projekte ohne Wertebereiche [Projects without value ranges] Eine Aufwandsabschätzung zur Erreichung höchster Suchergebnisqualität ist einfach möglich:
Falls der Katalog nicht vollständig aufgelöst werden konnte, sind Anpassungen für die Projekte unter Kategorie (4) Manuelle Erstellung der Rückwärtssuche notwendig [Manual creation of the reverse search necessary] vorzunehmen:
-> Prüfen Sie, ob die betreffenden Projekte durch strukturelle Umstellungen aufgelöst werden können (siehe Abschnitt 5.8.2.1.16.26.9, „ Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden“). Sollte dies nicht möglich sein, müssen manuell Reverse-Konfigs vom Typ
pnoreverse.cfgerstellt werden (siehe ???).Detaillierte Informationen erhalten Sie durch und Csv exportieren [Export csv file].
Es werden alle Projekte unter Manuelle Erstellung der Rückwärtssuche notwendig [Manual creation of the reverse search necessary] exportiert.
Es werden alle gelisteten Projekte exportiert.
IS_COMPLEX: Wahr, wenn es gelbe Felder gibt, d.h. Sachmerkmal oder Geometriemerkmal
1: Projekt enthält Wertebereiche (gelbe Felder) und Automatische Berechnung der Rückwärtssuche [Automatic calculation of the reverse search] geht nicht. -> Es wird eine manuelle Erstellung der Rückwärtssuche benötigt.
2: Projekt enthält Wertebereiche (gelbe Felder) und Automatische Berechnung der Rückwärtssuche [Automatic calculation of the reverse search] geht, sodass diese Projekte automatisch aufgelöst werden können.
-1: Klassifikation nach CNSORDERNO oder CNSTYPECODE fehlt. Vergleiche oben das Icon mit rotem Ausrufezeichen.
-2: Projekt enthält Wertebereiche (gelbe Felder); Auto Reverse Search läuft in einen Timeout. Es werden manuelle Reverse Skripte benötigt.
RANGES: Anzahl Wertebereiche (gelbe Felder). Wenn RANGES=0 ist, dann ist auch SUBTYPE=0)
HASPNO: Zu diesem Projekt ist bereits ein manuell erstelltes Reverse Skript (_pnoreverse.cfg) 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.
REPORT: Detaillierter Report, wie per Algorithmus versucht wird, die Bestellnummer aufzulösen. Feld ist nur ausgefüllt, wenn ein manuelles Skript benötigt wird.
![Geänderte Dateien in Verzeichnissen/Projekten vom Server herunterladen [Download changed files in directories / projects from server]](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_b2305aabac31406a8a753b9cf6371825.png)
![Beispiel zu Auflösungsergebnisse [Results]](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_1c32bf841cfc4d7ca3c576ee6ebbfd72.png)
Checken Sie den SVN-Katalog aus (sofern nicht bereits für die Kataloganalyse geschehen).
Aktualisieren Sie den Volltextsuchindex (sofern nicht bereits für die Kataloganalyse geschehen).
Führen Sie den Resolve Check mittels Kontextmenübefehl Reverse Search – Auflösungscheck (automatisch) [Reverse Search - Resolve check (automatic)] aus (sofern nicht bereits für die Kataloganalyse geschehen).
Wenn die in den Kategorien (1) Automatische Berechnung der Rückwärtssuche [Automatic calculation of the reverse search], (2) Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen [Inclusion in full text index up to max. 50,000 lines] und (3) Manuelle Rückwärtssuche vorhanden [Manual reverse search available] ausgewiesenen Projekte programmintern entsprechend gekennzeichnet werden sollen, klicken Sie unbedingt auf !
Mit Klick auf wird das Auflösungsflag gesteuert.[24]
Bei Projekten in der Kategorie Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen [Inclusion in full text index up to max. 50,000 lines] (2) wird das Flag auf 1 gesetzt.
Bei Projekten in der Rubrik Automatische Berechnung der Rückwärtssuche [Automatic calculation of the reverse search] (1) wird das Flag auf 2 gesetzt.
Zeilen ohne Varianten (Wertebereiche) oder mit einer manuellen Resolvekonfiguration (3) bleiben auf 0.
Mit Klick auf bestätigen Sie, dass für die potentiellen x Projekte das Flag gesetzt wird.
Damit die Reverse Search 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 QA Stand generieren... [Generate QA catalog...] (zum Testen)
Ausführen des Befehls Live Stand publizieren... [Publish Live state...] (kostenpflichtig)
Details hierzu finden Sie unter Abschnitt 6.10, „ Katalog publizieren “.
![Hier im Beispiel würde "Anwenden [Apply]" 9 Projekte betreffen (6+1+2).](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_93ad40c1012b4484b1d886d2f703f9a3.png)
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 [Automatic calculation of the reverse search] 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 [Automatic calculation of the reverse search] 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 (außer bereits automatisiert geschehen).
Siehe Abschnitt 1.3.3.6.6.3, „Volltextsuchindex “ in PARTsolutions Administration - Handbuch.
Ausführen des Befehls QA Stand generieren... [Generate QA catalog...] (zum Testen)
Ausführen des Befehls Live Stand publizieren... [Publish Live state...] (kostenpflichtig)
In PARTproject -> Projektauswahl -> Kontextmenü des Katalogs (bzw. eines Unterverzeichnisses oder Projekts) -> Automatisierung [Automation] finden Sie die Funktion Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search].[25]
Hiermit haben Sie die Möglichkeit zu prüfen, welche Teile aus einer automatisch erstellten Liste von Bestellnummern bzw. Typenschlüsseln (zusammengesetzt aus Werten gelber Felder) gefunden werden, sodass Sie sicher sein können, dass diese z.B. bei einer Suche im PARTdataManager zu korrekten Treffern führen.
Außerdem können Sie auch eine bestimmte Liste prüfen (entweder initial oder das Outputergebnis der automatischen Generierung nachdem Anpassungen zur Verbesserung der Ergebnisse vorgenommen wurden).
Führen Sie folgende Schritte aus bevor Sie den Testlauf starten:
Stellen Sie sicher, dass Sie den aktuellen SVN-Katalog inklusive der letzten Updates und Änderungen installiert haben.
Stellen Sie sicher, dass ein "frischer" Auflösungscheck durchgeführt wird.
Löschen Sie hierzu unter
$CADENAS_DATA/23dlibs/<catalogname>die Konfigurationsdateiresolvecheck.cfgbevor Sie den Auflösungscheck starten.Fügen Sie den Katalog in PARTadmin in der Konfigurationsdatei
reverselookup.cfg, im Schlüsselgenerategraphein.
Wählen Sie das Katalogverzeichnis, ein Unterverzeichnis oder ein Projekt und klicken Sie auf den Kontextmenübefehl Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search].
Kontextmenübefehl "Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search]"
-> Das gleichnamige Dialogfenster wird geöffnet.
Kontextmenübefehl "Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search]"
-> Es wird zunächst eine Liste zufälliger Bestellnummern erzeugt (siehe Fortschrittsbalken unter Erzeugung der Bestellnummern [Generation of order numbers]) und im zweiten Schritt werden diese Nummern getestet (siehe Fortschrittsbalken unter Test der Suche [Test the search]).
-> Nach dem Testlauf erhalten Sie die Zusammenfassung der Ergebnisses direkt im Programm.
-> Außerdem werden die Ergebnisse in die automatisch generierte Exportliste geschrieben. Das Testergebnis steht in der letzten Spalte. Gefundene Nummern sind mit "OK" gekennzeichnet, nicht gefundene mit "FAIL".
Wenn es fehlgeschlagene Suchen gab und die Reverse Search Funktionalität optimiert wurde, können Sie mit die Ausgabeliste erneut laden und testen.
![Kontextmenübefehl "Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search]"](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_4fa4d9c395a243769083be8e97d607ef.png)
![Kontextmenübefehl "Reverse Search – Bestellnummernsuche Testen [Reverse Search – Test Order Number Search]"](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_11c00cbbb75d4970a547a4c83c8e1574.png)
Beispiel (initiales Testen einer Liste definierter Bestellnummern/Typecodes)
Alternativ können Sie auch gleich mit einer Liste definierter Bestellnummern/Typecodes testen. Die Einstellung unter Anzahl pro Projekt [Amount per project] ist dann nicht relevant.
Starten Sie den Prozess mit Klick auf .
-> Das unter Zielpfad Exportliste [Destination path export list] eingestellte Verzeichnis wird geöffnet. Wählen Sie die gewünschte CSV-Datei.
-> Die Funktion wird ausgeführt und die Ergebnisse werden in die geladene CSV-Datei geschrieben.
Das Testergebnis steht in der letzten Spalte. Gefundene Nummern sind mit "OK" markiert, nicht gefundene mit "FAIL".
Bestellnummern testen via "Reversemap Service"
Wenn die Reverse Search bereits für die Online Verwendung aktiviert wurde, können Sie Bestellnummern manuell mit dem "Reversemap Service" testen.
Geben Sie einfach die URL im Browser ein und sehen Sie, ob Sie den MIdent zurückbekommen.
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 = -> Katalog in dem gesucht werden soll
part = -> Bestellnummer nach der gesucht werden soll
exact = -> 1 (Exakte Suche nach der Bestellnummer); 0 (Groß-/Kleinschreibung ignorieren)
Bestellnummern testen auf 3Dfindit oder Supplier Portal
Sie können auch auf dem 3Dfindit- oder einem Supplier-Portal nach Bestellnummern suchen (entsprechender Config-Key muss zuvor auf dem Supplier-Portal aktiviert worden sein.
Stellen Sie sicher, dass Sie den Katalog auf 3Dfindit bereits selektiert haben. In der Standard-Suchleiste von 3Dfindit funktioniert die Bestellnummernsuche nicht.
Bei der automatischen Berechnung der Rückwärtssuche wird unter
$CADENAS_DATA\index\cat\cat_resolve_check\grapheine Dateigraphlookup.maperzeugt. 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 [Order number or type code] 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.prjdes 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.prjgeschrieben werden, werden die Konfigurationsdateienresolve_check.cfgundqacheck.cfgausgewertet. Inresolve_check.cfgschreibt 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 derqacheck.cfggelesen, 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
RNG: Wertebereichsvariable die einen Bereich definiert
[10:100]
NMD: Wertebereichsvariable mit konkreten Werten
'x','b','y',...
Beispiel 2 (Wertebereichsvariable mit Benennung [Value range variable with naming])
1,'txt1',2,'txt2',...
ALG: Variable basierend auf Merkmalalgorithmus [Attribute algorithm]
ALG = '$A.-$B.-$C.-$D.-$E.-$F.-$G.'
TAB: Variable mit festen Werten [Variable with fixed values]
Die folgende Abbildung zeigt den Einstellungsbereich für oben erwähnte Wertebereichsvariaben.
![Variablenmanager [Variable Manager] -> Status](https://webapi.partcommunity.com/service/help/latest/pages/de/ecatalogsolutions/doc/resources/img/img_91ebf40534084c9e8cb7f8a012273639.png)
Beispiel 1 - Indirekte, berechnete Verwendung des Wertebereichs
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.
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-RNG2Beispiel 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.
[24] 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.
[25] Die entsprechenden Plugin-Dateien müssen unter %CADENAS%/libs/all/plugins liegen: resolve_check_tester.cfg, resolve_check_tester.def, resolve_check_tester.vbb