Prozedur, um eine Beziehung zwischen zwei Personen herzustellen.
Anmerkungen :
1. Die Identifizierung wird case-sensitiv durchgeführt
2. Sollte bereits eine Beziehung bestehen, gibt es keinen Fehler
3. Natürlich können mehrere Beziehungen bestehen; daher gibt es eine „SortNo“, um die Wichtigkeit oder Priorität der Beziehung einzustellen. Die Prozedur legt die neue Beziehung automatisch mit niedrigster (d.h. höchster „SortNo“, weil aufsteigende Sortierung) Priorität an. Um diesen Wert zu ändern, ist die Prozedur pm_PrioritizeARelationship_Pu zu verwenden.
Anmerkung zum Parameter „AccessLevel“ :
1.) Wird hier „NULL“ übergeben, suchen wir nach einer zu den Personentypen der beiden involvierten Personen sowie der „RelationshipID“ passenden Einstellung zum Schlüssel „DefaultAccessLevels“ und übernehmen diese ggf. Ansonsten wird der Wert „0“ gewählt, was bedeutet, daß die identifizierte Person KEINE Zugriffsrechte auf die Daten von „RelatedPersonID“ hat.
2.) Sobald tatsächlich Rechte bestehen sollen (also wenn „AccessLevel > 0“ ist, weil so angegeben oder aufgrund von „DefaultAccessLevels“), MÜSSEN in „RelatedIdentificationValues“ die (case-sensitiv richtigen) Identifizierungsdaten von „RelatedPersonID“ angegeben werden, sonst schlägt das Erstellen der Beziehung fehl !
Anmerkung : Durch welche Zeichenkette die Werte getrennt sind, gibt ebenfalls (wie schon bzgl. „PersonIdentificationValues“) der Wert in „SeparatorInIdentVals“ an.
3.) Wird explizit „AccessLevel > 0“ angegeben, muß in „RelationshipSettings“ zur „RelationshipID“ zum Schlüssel „AllowedAccessLevels“ ein für die beiden Personentypen (von „RelatedPersonID“ und von der identifizierten Person) gültiger Eintrag konfiguriert sein (s. pm_GetRelationshipSettingEntry), der angibt, welche Zugriffsrechte maximal vergeben werden können. Verletzt „AccessLevel“ diese Bedingung, gibt es ebenfalls einen Fehler.
HTTP-Method | POST |
HTTP-Auth | Optional |
Tags | |
Engine-Kategorie | person management |
Engine-Typ | Daten-Änderung |
Letzte Aktualisierung | 7.0.7 (2015-01-29) |
Name 1) | Standard-Wert | Beschreibung 2) | SQL-Datentyp3) | ab Version |
---|---|---|---|---|
PersonIdentificationValues | Liste von Werten, die die Person identifizieren. Diese Werte müssen Eigenschaften zu den Merkmal-IDs sein, die in „PersonTypeSettings“ zur „PersonTypeID“ zum Schlüssel „PersonIdentificationIDs“ hinterlegt sind. | varchar(255) | 3.5.11 | |
PersonTypeID | ID des Personen-Typs dem die zu identifizierende Person angehört. Dieser muß bei einer Identifizierung immer mit angegeben werden, da die Merkmale zur Identifizierung pro Personentyp variieren können. | tinyint | 3.5.11 | |
UniqueID | Eindeutige ID eines Besuchers, die der zu identifizierenden Person aktuell zugeordnet ist. Falls die Identifizierungsdaten zur Person in „SessionManagement“ (zu dieser „UniqueID“) gespeichert sind, darf „PersonIdentificationValues“ auch „NULL“ sein. | varchar(50) | 3.5.11 | |
RelatedPersonID | ID einer Person, zu der eine Beziehung erstellt werden soll. Muß größer als „0“ sein (IDs kleiner „0“ gibt es sowieso nicht, und die ID „0“ ist für die „anonyme“ oder „allgemeine“ Person reserviert) ! | integer | 3.5.11 | |
RelationshipID | Gibt an, welcher Art die Beziehung ist. Nur vom „dStore“ intern verwendete Beziehungen („SystemRelationship = 0“) sind natürlich NICHT erlaubt ! | tinyint | 3.5.11 | |
AccessLevel | 0 | Summe von Zugriffsrechten („0“ für „keine“), die die identifizierte Person auf „RelatdPersonID“ haben soll. Mögliche Einzel-Zugriffsrechte : s. pm_GetRelationAccessLevels. Es kann auch „NULL“ übergeben werden, s. Beschreibung ! | smallint | 5.1.10 |
RelatedIdentificationValues | NULL | Sobald Zugriffsrechte bestehen sollen (also wenn „AccessLevel > 0“ ist oder „NULL“ übergeben wurde und „DefaultAccessLevels“ greifen, s. Beschreibung), müssen hier (case-sensitiv richtig)Identifizierungsdaten von „RelatedPersonID“ angegeben werden. | varchar(255) | 5.1.10 |
SeparatorInIdentVals | '¶' | Gibt an, durch welche Zeichen die Werte in „PersonIdentificationValues“ und (falls angegeben) „RelatedIdentificationValues“ getrennt sind | varchar(4) | 5.5.0 |
Die Prozedur hat keine Rückgaben.
Die Prozedur hat keine Output-Parameter.
Code | Beschreibung | Quelle 4) |
---|---|---|
-679 | Mind. ein Zugriffsrecht darf aufgrund eines „RelationshipSettings“-Eintrags nicht vergeben werden | nur direkt |
-660 | Identifikation fehlgeschlagen | direkt und indirekt |
-624 | Fehlender oder falscher Eintrag in RelationshipSettings | nur indirekt |
-621 | Fehlender oder falscher Eintrag in PersonTypeSettings | nur indirekt |
-602 | Zur defaultUniqueID („VisitorID = -2“) können keinerlei Daten gespeichert oder verändert werden | nur indirekt |
-599 | Lizenz ist ungültig oder abgelaufen | nur indirekt |
-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 |
-550 | Fehlender oder falscher Eintrag in Settings | 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 |
-502 | Die Parameter-Werte der Prozedur können nicht verarbeitet werden (kein passendes Trennzeichen) | nur indirekt |
-500 | Falsche Parameter | direkt und indirekt |
Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.
7.0.7 | 2015-01-29 | „Start-/Finish-Procedure“-Logik eingebaut, s. Ticket #3670 |
7.0.2 | 2013-08-29 | Implementierung des neuen „RelationshipSettings“-Schlüssels „DefaultAccessLevels“ ⇒ Bedeutung für „AccessLevel = NULL“ nun anders, entsprechender Hinweis in der Doku |
6.5.3 | 2013-03-18 | 1. Datentyp von Parameter „SeparatorInIdentVals“ wurde zwecks UTF8-Unterstützung erweitert [von „1“ auf „4“] 2. Interne Anpassungen zwecks UTF8-Unterstützung |
6.5.0 | 2012-09-17 | Holger Wies : Datentyp des Parameters „PersonTypeID“ von „smallint“ auf „tinyint“ korrigiert |
5.5.0 | 2008-01-07 | 1. Neuer Parameter „SeparatorInIdentVals“ 2. Interne Ermittlung der Identifizierungsdaten verlagert auf die neue [interne] Prozedur „_pm_GetIdentValues“ |
5.1.10 | 2007-03-12 | 1. „RelationshipID“ ist jetzt ein „tinyint“ 2. „print“-Ausgabe im Fehler-Fall „-500“ 3. Neue Parameter „AccessLevel“ und „RelatedIdentificationValues“ 4. Ab jetzt : Fehler, wenn die identifizierte und in Beziehung stehende Person identisch sind |
5.1.0 | 2006-02-08 | Ab jetzt ist es verboten für „RelatedPersonID“ den Wert „0“ anzugeben |
3.5.11 | 2001-09-06 | Erstmalig in dieser Version erstellt |
Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:
Unformatierte Ausgabe:
curl -X POST 'http://<partner>-<project>.dstore.de/default/engine/pm_FormARelationship_Pu?PersonIdentificationValues=<value>&PersonTypeID=<value>&UniqueID=<value>&RelatedPersonID=<value>&RelationshipID=<value>'
Mit xmllint 5) formatierte Ausgabe:
curl -X POST 'http://<partner>-<project>.dstore.de/default/engine/pm_FormARelationship_Pu?PersonIdentificationValues=<value>&PersonTypeID=<value>&UniqueID=<value>&RelatedPersonID=<value>&RelationshipID=<value>' | xmllint --format -
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'), 'pm_FormARelationship_Pu', array( 'PersonIdentificationValues' => '<value>', 'PersonTypeID' => <value>, 'UniqueID' => '<value>', 'RelatedPersonID' => <value>, 'RelationshipID' => <value>, // 'AccessLevel' => 0, // 'RelatedIdentificationValues' => NULL, // 'SeparatorInIdentVals' => '¶' ) ); $service->execute($request); $xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument(); $ResultSet = $xml_result->getRowsAsArray();
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="pm_FormARelationship_Pu"> <Parameters> <Parameter Name="PersonIdentificationValues"><!-- varchar value --></Parameter> <Parameter Name="PersonTypeID"><!-- tinyint value --></Parameter> <Parameter Name="UniqueID"><!-- varchar value --></Parameter> <Parameter Name="RelatedPersonID"><!-- integer value --></Parameter> <Parameter Name="RelationshipID"><!-- tinyint value --></Parameter> <!-- <Parameter Name="AccessLevel">0</Parameter> --> <!-- <Parameter Name="RelatedIdentificationValues">NULL</Parameter> --> <!-- <Parameter Name="SeparatorInIdentVals">'¶'</Parameter> --> </Parameters> </Procedure> </Batch> </ListOfBatches>