Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:if_om_searchord_oconinfo_conds

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

engine:procedures:if_om_searchord_oconinfo_conds [11.01.2016 ] (aktuell)
Zeile 1: Zeile 1:
 +===== 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 [[dstoreproc>​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 [[dstoreproc>​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-Method|GET |
 +|HTTP-Auth|Optional |
 +|Alias|if_om_SearchOrders_OrderContentInformation_Conditions |
 +|Tags|{{tag>​[if Search Orders Order Content Information Conditions]}}|
 +|Engine-Kategorie|order management |
 +|Engine-Typ|Daten-Änderung |
 +|Letzte Aktualisierung|7.0.5 (2014-05-26)|
 +
 +==== Parameter ====
 +
 +^Name ((Pflichtparameter sind unterstrichen)) ^Standard-Wert ^Beschreibung ((siehe [[webservice:​engine_parameterconventions|Parameter-Konventionen engine/<​Prozedur-Name>​]])) ^SQL-Datentyp((siehe [[:​webservice:​engine_datatypes|Datentypen im Bereich "​engine"​]])) ^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|
 +|Delete|0 |Möchte man zuvor die Input-Schnittstelle leeren, setzt man "​Delete"​ auf "​1"​.\\ |bit|6.0.3|
 +|Separator|'​¶'​ |Gibt an, durch welche Zeichenkette die Werte in den "​Listen-"​Parametern ("​...List"​) getrennt sind\\ |varchar(4)|6.0.3|
 +|CheckByteLengthForStrings|0 |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"​)\\ |bit|7.0.5|
 +==== Rückgabe ====
 +
 +Die Prozedur hat keine Rückgaben.
 +==== Output-Parameter ====
 +
 +|InputNestingLevel|Gibt 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 [[dstoreproc>​om_GetOrders_Conditions_Ad]] (Parameter "​InputNestLevel_OConInfoConds"​).|
 +==== Mögliche Return-Codes ====
 +
 +^Code ^Beschreibung ^Quelle ((direkt meint "von der Prozedur selber"​ und indirekt meint "von intern aufgerufenen Unterprozeduren"​)) ^
 +|-500|Falsche Parameter|direkt und indirekt|
 +==== XML-Schema ====
 +
 +Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema [[http://​resources.dstore.de/​xsd/​webservice_SmartGate/​Response/​EngineProcedure_v1_0.xsd|Response/​EngineProcedure_v1_0.xsd]] validiert.
 +==== Historie ====
 +
 +|7.0.5 |2014-05-26|1. 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-18|1. "​Separator"​ wurde erweitert [von "​1"​ auf "​4"​]\\ 2. Interne Quellcode-Überarbeitung\\ ​ |
 +|6.0.3 |2011-09-07|Erstmalig in dieser Version erstellt\\ ​ |
 +
 +==== Code-Snippets ====
 +
 +Es handelt sich um eine Methode zum Füllen von Schnittstellentabelle wie in [[:​engine:​procedures-background#​input_-tabellen|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 [[:​webservice:​engine:​execute|engine/​execute]],​ z.B. per
 +  curl --header '​Content-Type:​ application/​xml'​ -X POST '​http://<​partner>​-<​kunde>​.dstore.de/​default/​engine/​execute'​ -d '<​xml-daten>'​
 +
 +<code xml>
 +<?xml version="​1.0"​ encoding="​UTF-8"?>​
 +<​ListOfBatches>​
 + <Batch No="​0">​
 + <​Procedure Name="​if_om_SearchOrd_OConInfo_Conds">​
 + <​Parameters/>​
 + </​Procedure>​
 + </​Batch>​
 +</​ListOfBatches></​code>​
  
engine/procedures/if_om_searchord_oconinfo_conds.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)