Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:if_im_searchtreenodes_conds

if_im_SearchTreeNodes_Conds

Fügt Suchbedingungen in die Input-Schnittstelle von im_SearchTreeNodes_Pu bzw. im_SearchTreeNodes_Ad ein.

Eine Suchbedingung besteht aus :

  • einer „NodeCharacteristicID“
  • einer „Bedingung“

und

  • „Optionen“ (o.a. „SearchOptions“)

Grundsätzlich besteht eine „Bedingung“ aus einem „Operator1“ und der dazugehörigen „Condition1“, sowie optional aus einem weiteren „Operator2“ und der dazugehörigen „Condition2“. Folgende Möglichkeiten für „Operator1“ gibt es :

  • „=“
  • „!=“ → | Diese beiden Operatoren sind grundsätzlich identisch, aber bei „!=“ kann auch der „LIKE“-Operator angewandt
  • „<>“ → | werden (s. „SearchOptions“), was dann einem „NOT LIKE“ entspricht. Ansonsten bedeuten beide „ungleich“.
  • „>“
  • „<“
  • „>=“
  • „⇐“
  • „IN“ → „Condition1“ muß dann eine „¶“-separierte Liste von „Value“-Werten (aus „NodeCharacteristicValues“) enthalten

Wenn „Operator2“ etwas enthält, dann muß es eines der folgenden Zeichen sein :

  • „<“
  • „⇐“

Außerdem muß in einem solchen Fall „Operator1“ dann etweder „>“ oder „>=“ enthalten !
Bei Vergleichs-Operatoren wird immer der „Basis-Feldtyp“ beachtet, also z.B. bei einer „>“-Suche in einem Merkmal, das Zahl-Eigenschaften besitzt, werden die Werte (und die Bedingung in „Condition1“) in ein „decimal(30,10)“ konvertiert und dann verglichen.

Zu den „SearchOptions“. Es muß eine Summe folgender Optionen sein :

  • „1“ : Der „LIKE“-Operator soll angewandt werden.

ACHTUNG : Diese Option ist nur erlaubt, wenn der Such-Operator (→ „Operator1“) „=“ oder „!=“ ist und die „BasicFieldTypeID“ des Merkmals (in dem gesucht werden soll) NICHT „0“ (für „Ja/Nein“) ist !

  • „2“ : Es sollen auch „vererbte“ Eigenschaften berücksichtigt werden.
  • „4“ : Es soll auch/nur in „ValueDetails“ gesucht werden.

ACHTUNG : Diese Option ist nur erlaubt, wenn der Such-Operator (→ „Operator1“) „=“ ist UND gleichzeitig Option „1“ gewählt ist !
Anmerkung : AUCH in „ValueDetails“ wird nur gesucht, wenn die „BasicFieldTypeID“ des Merkmals „2“ (für „Text“) ist, sonst wird NUR in „ValueDetails“ gesucht.

  • „8“ : Es soll auch nach Eigenschaften in den Nachfolgern (Elemente UNTERHALB von Elementen der in der Suchprozedur durch den Parameter „LevelID“ angegebenen Hierarchie) gesucht werden.
  • „16“ : Besagt, daß das Merkmal (in dem gesucht werden soll) „rekursiv“ ist UND auch tatsächlich „rekursiv“ zu suchen ist.

Anmerkung : Wir gehen bei „rekursiven“ Merkmalen immer davon aus, das alle „referenzierten“ Merkmale den gleichen Basis-Feldtyp besitzen !

Sonderfall :

Es kann auch „-1“ als „NodeCharacteristicID“ angegeben werden - damit kann man direkt nach „TreeNodeID“s suchen.
Allerdings muß als „SearchOption“ in diesem Fall immer „0“ angegeben werden. Es sind alle Operatoren wie oben beschrieben erlaubt, mit Ausnahme der „ungleich“-Operatoren „!=“ und „<>“.
Die Werte in „Condition1“ bzw. „Condition2“ müssen sich in eine „integer“-Zahl konvertieren lassen bzw. im Falle
des „IN“-Operators muß „Condition1“ eine „¶“-separierte Liste von „integer“-Werten enthalten.

Man kann nun mehrere Suchbedingungen aufeinmal einfügen, und zwar in dem die einzelnen „Bestandteile“ („NodeCharacteristicID“, die „Bedingung“ sowie die „Optionen) jeweils als „Liste“ von Elementen, die durch die in „Separator“ angegebene Zeichenkette getrennt sind, übergeben werden.
In „CharacteristicIDList“ werden die „NodeCharacteristicID“s übergeben, in „Operator1List“ die „Operator1“-Werte usw.

Sämtliche “..List„-Parameter müssen daher logischerweise immer die gleiche Anzahl Elemente, sprich die gleiche Anzahl „Separator“ enthalten !

ACHTUNG :

Ist in einem “…List„-Parameter „Separator“ zweimal direkt hintereinander enthalten oder ist „Separator“ ganz am Anfang oder Ende eines “…List„-Parameters, dann enthält diese Liste quasi ein „leeres Element“. Sind die Werte nun „strings“, ist nicht klar, ob dies als „NULL“ oder '' zu interpretieren ist !
Daher wurde folgende Konvention getroffen : Ein leeres Element wird immer als „NULL“ interpretiert !
Möchte man aber '' angeben (z.B. für „Condition1“), so sind zwei Fälle zu unterscheiden :
1.) Wird nur EINE Bedingung übergeben, d.h. enthalten die “…List„-Parameter jeweils nur ein Element, belegt man den entsprechenden Parameter einfach mit ''. Möchte man „NULL“ angeben, setzt man ihn auch auf „NULL“.
2.) Werden MEHRERE Bedingungen angegeben, ist an der entsprechenden Stelle (also zwischen zwei „Separator“en bzw. am Anfang oder am Ende) ' ' (das Leerzeichen, ascii-code „32“) anzugeben.

Beispiele (wir gehen in allen Beispielen von „¶“ als „Separator“ aus) :
1. “ Condition1List = 'test¶ ' würde bedeuten, daß bei der ZWEITEN Bedingung '' in die Spalte „Condition1“ eingetragen wird
2. „ Condition1List = 'test¶' würde bedeuten, daß bei der ZWEITEN Bedingung „Condition1“ „NULL“ bleibt
3. “ Condition1List = NULL bedeutet, daß in der (einzigen) Bedingung „Condition1“ „NULL“ bleibt
4. „ Condition1List = ' ' (zwei aufeinander folgende Leerzeichen) bedeutet, daß '' in „Condition1“ eingetragen wird

Hinweis : Man beachte, daß '' (der „leere string“) und ' ' (ein Leerzeichen) und ' ' (zwei Leerzeichen) identisch sind, d.h. ein Vergleich mit “=„ ergibt „true“ !

Wenn man eine neue Suche startet, sollten evtl. von einer vorherigen Suche vorhandene Suchebedingungen natürlich vorher
entfernt werden. Dazu ist „Delete“ mit „1“ zu belegen. Können nicht alle Suchbedingungen (wg. der „varchar(255)“-Begrenzung) eingefügt werden, ruft man diese Prozedur einfach erneut auf, dann aber logischerweise mit „Delete = 0“ !

Nun einige Beispiel-Aufrufe und deren Bedeutung/Folgen :

1.) exec if_im_SearchTreeNodes_Conds '7', '=', '%[Ss]hirt', null, null, '1', 1

⇒ Es wird mit „LIKE“ in Eigenschaften zum Merkmal mit der „NodeCharacteristicID = 7“ gesucht, und es kommen nur die Werte in Frage, die auf „Shirt“ oder „shirt“ ENDEN.

2.) exec if_im_SearchTreeNodes_Conds '7¶53', '=¶>=', '%[Ss]hirt¶50', '¶⇐', '¶100', '1¶24', 1

⇒ Wie Beispiel 1.) nur zusätzlich mit einer zweiten Suchbedingung, die folgendes ausdrückt : Aufgrund der „SearchOption = 24“ („16 + 8“) werden die Eigenschaften zum Merkmal mit der „NodeCharacteristicID = 53“ REKURSIV ausgwertet (wenn das Merkmal nicht rekursiv sein sollte, gibt es einen Fehler beim Aufruf der Suchprozedur !), und es wird auch in Nachfolgern (Elemente UNTERHALB von Elementen der in der Suchprozedur durch den Parameter „LevelID“ angegebenen Hierarchie) gesucht.
Die eigentliche Bedingung ist : Es sollen nur Eigenschaften in Betracht kommen, die zwischen „50“ und „100“ liegen - insbesondere muß also der Basis-Feldtyp der referenzierten Merkmale „Text“ oder „Zahl“ sein, sonst gibt es einen Fehler.

Handelt es sich bei dem Merkmal mit der ID „53“ z.B. um ein rekursives „Verkaufspreis“-Merkmal, ist die Einheit der referenzierten Merkmale „EUR“ und wird als „LevelID“ der Suchprozedur die in „Settings“ zum Schlüssel „ProductLevelID“ konfigurierte ID übergeben, dann bedeutet diese zweite Suchbedingung übersetzt :
„Alle Produkte, die (oder eine Variante) zwischen 50 und 100 Euro kosten“

3.) exec if_im_SearchTreeNodes_Conds '7', '=', '%[Ss]hirt', null, null, '1', 1
und
exec if_im_SearchTreeNodes_Conds '53', '>=', '50', '⇐', '100', '24', 0

⇒ Stellen die gleichen zwei Suchbedingungen dar, wie eben in Beispiel 2.)

4.) exec if_im_SearchTreeNodes_Conds '7¶8', '=¶=', '%[Ss]hirt¶%[Ss]hirt', null, null, '5¶7', 1

⇒ Gibt einen Fehler (“-500„), da in „Operator2List“ und „Condition2List“ nur ein Element übergeben wurde. Richtig wäre :

5.) exec if_im_SearchTreeNodes_Conds '7¶8', '=¶=', '%[Ss]hirt¶%[Ss]hirt', '¶', '¶', '5¶7', 1

⇒ Die erste Bedingung entspricht Beispiel 1.), mit dem Unterschied, daß AUCH in „ValueDetails“ gesucht werden soll, da „SearchOption = 5“ („1 + 4“) gewählt wurde. Ist der Basis-Feldtyp des Merkmals NICHT „Text“, wird NUR in „ValueDetails“ gesucht.
Die zweite Bedingung ist offensichtlich identisch mit der ersten, bis auf zwei Ausnahmen : „NodeCharacteristicID“ ist „8“ (nicht „7“) und aufgrund der „SearchOption = 7“ („1 + 2 + 4“) sollen auch VERERBTE Eigenschaften beachtet werden.

HTTP-MethodGET
HTTP-AuthOptional
Aliasif_im_SearchTreeNodes_Conditions
Tags
Engine-Kategorieitem management
Engine-TypDaten-Änderung
Letzte Aktualisierung7.0.2 (2013-08-29)

Parameter

Name 1) Standard-Wert Beschreibung 2) SQL-Datentyp3) ab Version
CharacteristicIDList Liste von (Merkmal-)IDs (durch <Separator> getrennt) - die angegebenen Werte werden in der Spalte „NodeCharacteristicID“ gespeichert
varchar(255)5.5.0
Operator1List Liste (durch <Separator> getrennt) der einzufügenden Vergleichsoperatoren für den ersten Teil der Bedingung - die angegebenen Werte werden in der Spalte „Operator1“ gespeichert
varchar(255)5.5.0
Condition1List Liste (durch <Separator> getrennt) der einzufügenden Vergleichswerte für den ersten Teil der Bedingung - die angegebenen Werte werden in der Spalte „Condition1“ gespeichert
varchar(16384)5.5.0
Operator2List Liste (durch <Separator> getrennt) der einzufügenden Vergleichsoperatoren für den zweiten Teil der Bedingung - die angegebenen Werte werden in der Spalte „Operator2“ gespeichert
varchar(255)5.5.0
Condition2List Liste (durch <Separator> getrennt) der einzufügenden Vergleichswerte für den zweiten Teil der Bedingung - die angegebenen Werte werden in der Spalte „Condition2“ gespeichert
varchar(16384)5.5.0
SearchOptionList Liste (durch <Separator> getrennt) von „Such-Optionen“ (s. Beschreibung) - die angegebenen Werte werden in der Spalte „SearchOptions“ gespeichert
varchar(255)5.5.0
Delete0 Möchte man zuvor die Input-Schnittstelle leeren, setzt man „Delete“ auf „1“.
bit5.5.0
Separator'¶' Gibt an, durch welche Zeichenkette die Werte in den „Listen-„Parametern (“…List“) getrennt sind
varchar(4)5.5.0

Rückgabe

Die Prozedur hat keine Rückgaben.

Output-Parameter

Die Prozedur hat keine Output-Parameter.

Mögliche Return-Codes

Code Beschreibung Quelle 4)
-500Falsche Parameterdirekt und indirekt

XML-Schema

Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.

Historie

7.0.2 2013-08-29Datentyp der Parameter „Condition1List“ und „Condition2List“ sowie Variablen „Condition1“ und „Condition2“
erweitert
6.5.3 2013-03-181. „Separator“ wurde erweitert [von „1“ auf „4“]
2. Interne Quellcode-Überarbeitung
6.5.0 2012-09-17Überflüssigen „_mi_GetCurrentUser“-Aufruf entfernt
6.0.0 2010-03-26Neuer Spezial-Fall “-1„ als „NodeCharacteristicID“ möglich (zur Suche nach „TreeNodeID“)
5.5.1 2008-07-29Kleiner Doku-Fehler
5.5.0 2008-01-07Erstmalig in dieser Version erstellt

Code-Snippets

Es handelt sich um eine Methode zum Füllen von Schnittstellentabelle wie in Hintergrundinformationen zu Engine-Prozeduren erläutert. Die Methode kann ausschließlich per engine/execute in einem gemeinsamen Batch mit komplementären Prozeduren verwendet werden.

engine/execute

XML zur Ausführung mit der Methode engine/execute, z.B. per

curl --header 'Content-Type: application/xml' -X POST 'http://<partner>-<kunde>.dstore.de/default/engine/execute' -d '<xml-daten>'
<?xml version="1.0" encoding="UTF-8"?>
<ListOfBatches>
	<Batch No="0">
		<Procedure Name="if_im_SearchTreeNodes_Conds">
			<Parameters/>
		</Procedure>
	</Batch>
</ListOfBatches>
1)
Pflichtparameter sind unterstrichen
4)
direkt meint „von der Prozedur selber“ und indirekt meint „von intern aufgerufenen Unterprozeduren“
engine/procedures/if_im_searchtreenodes_conds.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)