Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:if_om_searchord_oconinfo_conds

if_om_SearchOrd_OConInfo_Conds

Fügt Suchbedingungen in die Input-Schnittstelle der internen Prozedur zur Suche von Aufträgen anhand von Informationen zu Auftrags-Positionen („OrderContentInformation“) ein. Die Ausführung der Suche ist dann anschließend mit om_GetOrders_Conditions_Ad auszuführen, indem man dort den Parameter „InputNestLevel_OConInfoConds“ mit dem Wert belegt, der von dieser Prozedur hier nach dem Aufruf im Ausgabeparameter „InputNestingLevel“ zurückgegeben wird.

Eine Suchbedingung besteht aus :

  • einer „InformationTypeID“
  • einer „Bedingung“

und

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

Anmerkung : Da hier MEHRERE Suchbedingungen übergeben werden können (um diese in die Input-Tabelle einfügen zu lassen), gibt es entsprechende „…List“-Parameter. Im folgenden Abschnitt erläutern wir aber nur EINE solche Bedingung, sprich einen Wert im jeweiligen „…List“-Parameter. Sprechen wir also z.B. von „Operator1“ oder „Condition1“ meinen wir einen Wert in „Operator1List“ bzw. „Condition1List“.

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 und bedeuten
  • „<>“ → | entweder „ungleich“ oder „NOT LIKE“ (je nach den „SearchOptions“)
  • „>“
  • „<“
  • „>=“
  • „⇐“
  • „IN“ → „Condition1“ muß dann eine Liste von „Information“-Werten enthalten, die durch das Zeichen getrennt sind,

welches om_SearchOrders_OInfo_Ad über den Parameter „ValueSeparator_IN_Operator“ mitgeteilt wird !
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“ und evtl. „Condition2“) in ein „decimal(30,10)“ konvertiert und dann verglichen.

Zu den „SearchOptions“. Es muß eine Summe folgender Optionen (derzeit gibt es nicht wirklich viele *g*) 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 !

Man kann nun mehrere Suchbedingungen aufeinmal einfügen, und zwar indem die einzelnen „Bestandteile“ („InformationTypeID“, die „Bedingung“ sowie die „Optionen) jeweils als „Liste“ von Elementen, die durch die in „Separator“ angegebene Zeichenkette getrennt sind, übergeben werden.
In „InformationTypeIDList“ werden die „InformationTypeID“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)“- bzw. „varchar(16384)“-Begrenzung) eingefügt werden, ruft man diese Prozedur einfach erneut auf, dann aber logischerweise mit „Delete = 0“ !

Anmerkung zum Parameter „CheckByteLengthForStrings“ :

Die Werte in den Listen „Operator…List“ und „Condition…List“ sind „string“-Werte und haben daher eine maximale Länge, und zwar hinsichtlich der Anzahl Bytes (nicht etwa Anzahl Zeichen). Bei den „Operator…“-Werten ist die maximale Byte-Länge „2“ und bei den „Condition…“-Werten sind es „2500“ bzw. „1000“ Bytes. Falls ein Element diese Grenze überschreitet, würde das Einfügen in die Input-Schnittstelle zwar trotzdem gelingen, aber es würden unbemerkt Zeichen (am Ende) abgeschnitten und somit verlorengehen. Mit „CheckByteLengthForStrings“ kann daher gesteuert werden, ob dieses unbemerkte „truncate“n ok ist („0“) oder ob vorher geprüft und gegebenenfalls ein Fehler geworfen werden soll („1“).

Nun einige Beispiel-Aufrufe und deren Bedeutung/Folgen :

1.) exec if_om_SearchOrd_OConInfo_Conds '3', '=', '%[Tt]limo', null, null, '1', 1

⇒ Es wird mit „LIKE“ in Informationen zur Informationsart mit der „InformationTypeID = 3“ gesucht, und es kommen nur die Werte in Frage, die auf „Tlimo“ oder „tlimo“ ENDEN.

2.) exec if_om_SearchOrd_OConInfo_Conds '3¶2', '=¶>=', '%[Tt]limo¶5000', '¶⇐', '¶5100', '1¶0', 1

⇒ Wie Beispiel 1.) nur zusätzlich mit einer zweiten Suchbedingung, die folgendes ausdrückt :
Es sollen nur Informationen in Betracht kommen, die zwischen „5000“ und „5100“ liegen - insbesondere muß also der Basis-Feldtyp der Informationsart „Text“ oder „Zahl“ sein, sonst gibt es einen Fehler.

3.) exec if_om_SearchOrd_OConInfo_Conds '3', '=', '%[Tt]limo', null, null, '1', 1
und
exec if_om_SearchOrd_OConInfo_Conds '2', '>=', '5000', '⇐', '5100', '0', 0

⇒ Stellen die gleichen zwei Suchbedingungen dar, wie eben in Beispiel 2.). Nur werden sie eben durch zwei getrennte Aufrufe eingefügt (daher ist beim zweiten Aufruf der letzte Parameter-Wert „0“, da dieser für „Delete“ übergeben wird).

4.) exec if_om_SearchOrd_OConInfo_Conds '3¶4', '=¶=', '%[Tt]limo¶%unzufrieden%', null, null, '1¶1', 1

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

5.) exec if_om_SearchOrd_OConInfo_Conds '3¶4', '=¶=', '%[Tt]limo¶%unzufrieden%', '¶', '¶', '1¶1', 1

HTTP-MethodGET
HTTP-AuthOptional
Aliasif_om_SearchOrders_OrderContentInformation_Conditions
Tags
Engine-Kategorieorder management
Engine-TypDaten-Änderung
Letzte Aktualisierung7.0.5 (2014-05-26)

Parameter

Name 1) Standard-Wert Beschreibung 2) SQL-Datentyp3) ab Version
InformationTypeIDList Liste von IDs (durch <Separator> getrennt), die Informations-Arten (für Auftrags-Positionen) darstellen - die angegebenen Werte werden in der Spalte „InformationTypeID“ gespeichert
varchar(255)6.0.3
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)6.0.3
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)6.0.3
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)6.0.3
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)6.0.3
SearchOptionList Liste (durch <Separator> getrennt) von „Such-Optionen“ (s. Beschreibung) - die angegebenen Werte werden in der Spalte „SearchOptions“ gespeichert
varchar(255)6.0.3
Delete0 Möchte man zuvor die Input-Schnittstelle leeren, setzt man „Delete“ auf „1“.
bit6.0.3
Separator'¶' Gibt an, durch welche Zeichenkette die Werte in den „Listen-„Parametern (“…List“) getrennt sind
varchar(4)6.0.3
CheckByteLengthForStrings0 Gibt an, ob für die einzelnen Elemente in den „Operator…List“- und „Condition…List“-Parametern geprüft werden soll, ob die maximale Anzahl Bytes überschritten ist („1“) oder nicht („0“)
bit7.0.5

Rückgabe

Die Prozedur hat keine Rückgaben.

Output-Parameter

InputNestingLevelGibt an, zu welchem „NestingLevel“ die Daten eingefügt wurden (ein DIREKTER Aufruf führt immer zum Wert „2“). Diese Info braucht man für einen anschließenden Aufruf von om_GetOrders_Conditions_Ad (Parameter „InputNestLevel_OConInfoConds“).

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.5 2014-05-261. Datentyp-Erweiterung diverser Parameter und Variablen wg. der „OrderContentInformation“-Erweiterung [Ticket
#3653]
2. Neuer Parameter „CheckByteLengthForStrings“
6.5.4 2013-04-29Änderungen an der Dokumentation. Direkte Aufrufer dürfen nun davon ausgehen, dass „InputNestingLevel“ nach dem
Aufruf mit „2“ belegt ist.
6.5.3 2013-03-181. „Separator“ wurde erweitert [von „1“ auf „4“]
2. Interne Quellcode-Überarbeitung
6.0.3 2011-09-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_om_SearchOrd_OConInfo_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_om_searchord_oconinfo_conds.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)