engine:procedures:im_modifycondpartsingroups

Inhaltsverzeichnis

im_ModifyCondPartsInGroups_Ad

im_ModifyCondPartsInGroups_Ad

Verwaltet die Zuordnung von (Artikel-)Bedingungs-Teilen zu (Artikel-)Bedingungs-Gruppen.

Ein Bedingungs-Teil ist Bestandteil einer sogenannten Artikel-Bedingung, deren Aufbau kurz beschrieben so aussieht :

Eine Artikel-Bedingung besteht aus Bedingungs-Gruppen, die jeweils aus Bedingungs-Teilen bestehen, die ihrerseits immer drei Bedingungs-Arten (Hierarchie-Bedingung, Vorgänger-Bedingung und Eigenschafts-Bedingung) definieren.

Im folgenden werden die Bestandteile einzeln erläutert. Beginnen wir mit der „kleinsten Einheit“ :

1.) Ein sogenannter Bedingungs-Teil („ItemConditionPart“) definiert drei Bedingungs-Arten :

a) Hierarchie-Bedingung („LevelIDs“)

Diese besteht aus einer Menge von Hierarchien („LevelIDs“), wobei es auch möglich ist, den Wert „,,“ zu definieren, der für „beliebige Hierarchie“ steht.

b) Vorgänger-Bedingung („DomainTreeNodeIDs“)

Dabei handelt es sich um eine Menge von Vorgänger-IDs („TreeNodeIDs“), wobei es auch möglich ist, den Wert „,,“ zu definieren, der „beliebiger Vorgänger“ bedeutet.

c) Eigenschafts-Bedingung

Sie ist immer zu einem Merkmal („NodeCharacteristicID“) definiert und besteht aus einem „Operator1“ und der dazugehörigen „Condition1“, sowie optional aus einem weiteren „Operator2“ und der dazugehörigen „Condition2“. Dazu können Optionen hinsichtlich Vererbung und rekursiver Auswertung bei der Ermittlung der Eigenschaft definiert werden.
Es ist auch möglich, den Wert „-1“ als Merkmal („NodeCharacteristicID“) zu definieren, was den speziellen Fall „KEINE Eigenschafts-Bedingung“ darstellen soll.

Ein Artikel-Element erfüllt einen Bedingungs-Teil genau dann, wenn alle drei Bedingungs-Arten erfüllt sind. Der spezielle (in einer Standard-Installation bereits definierte) Teil …

„beliebige Hierarchie“ und
„beliebiger Vorgänger“ und
„KEINE Eigenschafts-Bedingung“

wird von jedem (nicht gelöschten) Artikel-Element erfüllt.

Hinweis : Der „Active“-Status eines Elementes spielt grundsätzlich keine Rolle !

2.) Durch eine logische Verknüpfung entweder mit „AND“ oder „OR“ von solchen Bedingungs-Teilen ergibt sich eine sogenannte Bedingungs-Gruppe („ItemConditionGroup“).
Artikel-Elemente erfüllen also eine solche Bedingungs-Gruppe, wenn sie entweder alle (bei „AND“) oder mindestens einen (bei „OR“) ihrer Bedingungs-Teile erfüllen.

3.) Mehrere solcher Gruppen können dann ihrerseits wiederum entweder mit „AND“ oder „OR“ verknüpft werden und bilden letztlich eine Artikel-Bedingung.
Artikel-Elemente erfüllen also eine solche (Gesamt-)Artikel-Bedingung, wenn sie entweder alle (bei „AND“) oder mindestens eine (bei „OR“) ihrer Bedingungs-Gruppen erfüllen.

Somit lassen sich einfache und komplexe Bedingungen formulieren. Beispiele :

1.) „Artikel-Elemente der Kategorie X oder Y der Marke Z“
⇒ Dies ließe sich mit einem Bedingungs-Teil …
„Beliebige Hierarchie UND X,Y als DomainTreeNodeIDs UND Eigenschaft Z zum Merkmal Marke“
… abbilden, der als einziger Teil einer Bedingungs-Gruppe angehören würde, die ihrerseits alleine dann schon die gesamte Bedingung darstellt.

2.) „Rot gefärbte Produkte der Marke X oder blau gefärbte Produkte in Kategorie A der Marke Y“
⇒ Dieses etwas kompliziertere Beispiel läßt sich beispielsweise wie folgt mit vier Bedingungs-Teilen und zwei -Gruppen abbilden :
Die beiden Teile …

„Produkt-Hierarchie UND beliebiger Vorgänger UND Eigenschaft rot zum Merkmal Farbe“

und

„Produkt-Hierarchie UND beliebiger Vorgänger UND Eigenschaft X zum Merkmal Marke“

… werden mit „AND“ zu einer Gruppe „1“ verknüpft.
Außerdem verknüpft man die beiden Teile …

„Produkt-Hierarchie UND A als DomainTreeNodeID UND Eigenschaft blau zum Merkmal Farbe“

und

„Produkt-Hierarchie UND A als DomainTreeNodeID UND Eigenschaft Y zum Merkmal Marke“

… wiederum mit „AND“ zu einer Gruppe „2“.
Durch eine „OR“-Verknüpfung der beiden Gruppen ist dann schließlich die gesamte Bedingung definiert.
Anmerkung : Es gibt oftmals mehrere Möglichkeiten der Abbildung, da gerade z.B. die Hierarchie-Bedingung bei einer Verknüpfung zweier Bedinungs-Teile mit „UND“ nur bei einer der Teile definiert werden muß - in unserem obigen Beispiel 2 haben wir die Hierarchie hingegen bei ALLEN Bedingungs-Teilen definiert.

Hinweise :

1.) Das Hinzufügen oder Wegnehmen des durch „ConditionPartID“ angegebenen Bedingungs-Teils zur Bedingungs-Gruppe „ConditionGroupID“ kann nur erfolgen, wenn die Bedingungs-Gruppe nicht verwendet wird !

2.) Wir sorgen immer dafür, daß die „SortNo“s innerhalb der „ConditionGroupID“ lückenlos aufsteigend sind.

3.) Wie man auch am Datentyp von „SortNo“ sehen kann, können einer Bedingungs-Gruppe maximal 256 Bedingungs-Teile zugeordnet werden

HTTP-Method	POST
HTTP-Auth	Optional
Alias	im_ModifyConditionPartsInGroups_Ad
Tags	[im, Modify, Condition, Parts, In, Groups, Ad]
Engine-Kategorie	item management
Engine-Typ	Daten-Änderung
Letzte Aktualisierung	7.0.7 (2015-01-29)

Parameter

Name ¹⁾	Standard-Wert	Beschreibung ²⁾	SQL-Datentyp³⁾	ab Version
ConditionGroupID		ID einer (Artikel-)Bedingungs-Gruppe. Mögliche Werte : s. im_GetItemConditionGroups_Ad	integer	6.0.0
ConditionPartID		ID eine (Artikel-)Bedingungs-Teils, der „ConditionGroupID“ zugeordnet werden soll. Gibt es die Zuordnung schon, entscheidet „DeleteCombination“ darüber, ob sie entfernt („1“) oder die „SortNo“ (→ Parameter „SortNo“) geändert („0“) wird.	integer	6.0.0
SortNo	NULL	Bestimmt die Reihenfolge der Abarbeitung von „ConditionPartID“ (innerhalb aller zugeordneten Bedingungs-Teile) bei konkreter Prüfung der (Artikel-)Bedingungs-Gruppe „ConditionGroupID“.	tinyint	6.0.0
DeleteCombination	0	Wird nur beachtet, wenn die Kombination aus „ConditionGroupID“ und „ConditionPartID“ bereits besteht! Entscheidet, ob die bestehende Zuordnung gelöscht („1“) oder die „SortNo“ (→ Parameter „SortNo“) geändert („0“) wird.	bit	6.0.0

Rückgabe

Die Prozedur hat keine Rückgaben.

Output-Parameter

Die Prozedur hat keine Output-Parameter.

Mögliche Return-Codes

Code	Beschreibung	Quelle ⁴⁾
-569	Der Benutzer hat kein Ausführungsrecht für die Prozedur	nur indirekt
-567	Die Prozedur darf z. Zt. nicht ausgeführt werden	nur indirekt
-566	Die Prozedur darf mit den übergebenen Parametern nicht ausgeführt werden	nur indirekt
-535	Das Datum liegt nicht in der Vergangenheit	nur indirekt
-530	Der Wert ist nicht konvertierbar	nur indirekt
-510	Der Benutzer ist nicht registriert	nur indirekt
-504	Es ist ein Problem aufgetreten, das nicht gelöst werden kann, Prozedur wird daher abgebrochen	nur indirekt
-500	Falsche Parameter	direkt und indirekt
-153	Einer Bedingungs-Gruppe können maximal 256 Bedingungs-Teile zugeordnet werden	nur direkt
-152	Hinzufügen oder Entfernen eines Bedingungs-Teils nicht erlaubt, da die Gruppe bereits verwendet wird	nur direkt

XML-Schema

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

Historie

7.0.7	2015-01-29	Interne Änderung : Datentyp-Erweiterung des „ReferenceKey“ [für „_mi_StartProcedure“-Aufruf]
7.0.4	2014-03-19	Kleine Kosmetik-Korrektur : Bei einigen Code-Zeilen war am Ende ein CR-Zeichen, was wir entfernt haben
6.0.7	2012-05-08	1. Bislang wurde die „IsValid“-Spalte in „ItemConditions“ nicht beachtet bzw. gepflegt 2. Ab jetzt wird auch beachtet, ob der Aufruf dieser Prozedur innerhalb einer Transaktion stattfindet
6.0.1	2010-07-20	Holger Wies : Pflege der „Used“-Information in „ItemCondPartMetaInformation“ ergänzt„
6.0.0	2010-03-26	Erstmalig in dieser Version erstellt

Code-Snippets

Engine Playground

Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:

im_ModifyCondPartsInGroups_Ad im Engine Playground öffnen

cURL

Unformatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/im_ModifyCondPartsInGroups_Ad?ConditionGroupID=<value>&ConditionPartID=<value>'

Mit xmllint ⁵⁾ formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/im_ModifyCondPartsInGroups_Ad?ConditionGroupID=<value>&ConditionPartID=<value>' | xmllint --format -

dStore_php

use dStore_php\WebService;
 
$service = new WebService\Service( WebService\Scheme::HTTP,'<partner>-<project>.dstore.de', 80);
 
$request = new WebService\Requests\Engine\Procedure\Request(
			new WebService\Requests\AccessData('default'),
	'im_ModifyCondPartsInGroups_Ad',
		array(
			'ConditionGroupID' => <value>,
			'ConditionPartID' => <value>,
			// 'SortNo' => NULL,
			// 'DeleteCombination' => 0
		)
);
 
$service->execute($request);
 
			$xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument();
			$ResultSet = $xml_result->getRowsAsArray();

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="im_ModifyCondPartsInGroups_Ad">
			<Parameters>
				<Parameter Name="ConditionGroupID"><!-- integer value --></Parameter>
				<Parameter Name="ConditionPartID"><!-- integer value --></Parameter>
				<!-- <Parameter Name="SortNo">NULL</Parameter> -->
				<!-- <Parameter Name="DeleteCombination">0</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>

¹⁾

Pflichtparameter sind unterstrichen

²⁾

siehe Parameter-Konventionen engine/<Prozedur-Name>

³⁾

siehe Datentypen im Bereich "engine"

⁴⁾

direkt meint „von der Prozedur selber“ und indirekt meint „von intern aufgerufenen Unterprozeduren“

⁵⁾

I.d.R. auf Unix-artigen Systemen bereits installiert, Bestandteil der libxml2, siehe http://www.xmlsoft.org