Legt einen neuen „dStore“-Benutzer (s. mi_GetUserInfo_Ad) inkl. zugehöriem ASE-Login, (ASE-)Datenbank-Benutzer und gleichnamiger Person des Typs „dStoreUser“ an.

ACHTUNG : Zur erfolgreichen Ausführung dieser Prozedur muß der Aufrufer die ASE-Rolle „sso“ haben !

Dazu werden folgende Schritte erledigt :
Anmerkung : Die Aktionen können aufgrund von Beschränkungen im ASE leider nicht in einer Transaktion ausgeführt werden. Daher kann es theoretisch bei einem Fehler dazu kommen, daß nur ein Teil der Schritte ausgeführt wurde. Man kann aber die Prozedur einfach (nachdem die Ursache erkannt und behoben wurde natürlich) erneut aufrufen ! Wir versuchen aber, alle möglichen Fehler VORHER festzustellen (die „-500“-/„-504“-Fehler z.B.), so daß diese Situation hoffentlich eher selten vorkommt.

1. Die ganze Sache setzt einen Login im ASE-Server voraus. Dieser kann über „DBLogin“ angegeben werden (falls mit „NULL“ belegt, wählen wir den gleichen „string“ wie in „UserName“ angegeben).
ACHTUNG : Bis Version 6.0.8 konnte „DBLogin“ von „UserName“ abweichen, ab 6.5.0 ist das aber NICHT mehr erlaubt (⇒ am besten also immer mit „NULL“ belegen)
Außerdem muß natürlich ein entsprechendes Passwort zum Login (→ „Password“) übergeben werden. Zu jedem Login im ASE kann eine Art „Kurzbezeichnung“ (z.B. der „volle Name“) hinterlegt werden - diese übergibt man in „DBLoginDescription“.
ACHTUNG : Optional war „DBLoginDescription“ nur bis Version 6.0.8, ab Version 6.5.0 MUSS „DBLoginDescription“ angegeben sein und mindestens 5 Zeichen (ohne Leertasten am Anfang und Ende) enthalten und darf (ab Version 7.0.2) keine Grossbuchstaben enthalten! Dies wird aber nur geprüft, wenn „UserName“ noch nicht als Login existiert (man kann diese Prozedur hier ja nochmals mit demselben „UserName“ aufrufen, weil z.B. etwas „schief gelaufen“ ist, s. obige Anmerkung). Außerdem prüfen wir ab Version 6.5.0, ob „DBPassword“ mindestens 6 Zeichen (ohne Leertasten) enthält !

Hinweis : Existiert der Login schon, gibt es einen Fehler (neues Verhalten seit Version 6.5.0). Möchte man in so einem Fall aber, daß es weitergeht (etwa weil es bei einer vorherigen Ausführung einen Fehler gab, s. obige Anmerkung), setzt man „AbortIfLoginAlreadyExists“ auf „0“ - „DBPassword“ und „DBLoginDescription“ werden dann aber ignoriert (der Login wird also NICHT aktualisiert) !
Hintergrund für dieses neue Standard-Verhalten (Abbruch wenn der Login schon existiert) ist zu verhindern, daß aus Versehen bei UNTERSCHIEDLICHEN Engines auf demselben ASE-Server versucht wird, denselben Benutzer anzulegen, wobei aber einer sich dann nicht einloggen kann (weil die Passwörter natürlich in der Regel verschieden sind, aber nur einer „den Zuschlag erhalten“ kann - der, der den Benutzer ZUERST anlegt nämlich) !

ACHTUNG : In der derzeitigen Version des ASE können von „DBLogin“, „DBPassword“ und „DBLoginDescription“ nur die ersten 30 Zeichen berücksichtigt werden !

2. Existiert der Login „DBLogin“ bzw. konnte er erfolgreich angelegt werden, wird in der Datenbank, in der diese Prozedur hier aufgerufen wird, ein Benutzer mit dem Namen „UserName“ zu besagtem Login angelegt - dabei entscheidet „DBGroupAdmin“ darüber, ob der neue Benutzer in die (Datenbank-)Gruppe „admin“ kommt („1“) oder der „public“-Gruppe zugeordnet wird („0“).

Hinweis : Existiert der Benutzer schon, gibt es KEINEN Fehler !

3. Anschließend wird in den sogenannten „dstore“-Datenbanken ebenfalls dafür gesorgt, daß ein Benutzer „UserName“ (immer in der „public“-Gruppe) existiert. Besagte Datenbanken sind derzeit :

• „dstore“
• „dstorechecks“
• „dstoreifin“
• „dstoreifout“
• „dstoretempdb“

4. Nun wird „UserName“ in der Tabelle „UserInfo“ registriert.

5. Innerhalb der Engine gibt es ebenfalls (wie in einer ASE-Datenbank auch) „Gruppen“. Diese dienen zur Administration der Rechtevergabe für Prozeduren und der Einschränkung von Prozedur-Aufrufen (s. mi_GetUserGroups_Ad). Im Gegensatz zu ASE-Datenbank-Gruppen kann ein Benutzer in der Engine aber in MEHRERE Gruppen eingeordnet werden (s. mi_ModifyUsersInGroups_Ad). Beim Anlegen eines Benutzers durch diese Prozedur hier hat man nun die Möglichkeit, den Benutzer direkt in eine Gruppe einzuordnen. Dazu übergibt man „UserGroupID“ entsprechend - der Default-Wert steht für die „default“-Gruppe, um die grundlegendsten „Ad“-Prozeduren ausführen zu können.
Beschränkungen :
1.) Sofern der Benutzer, der diese Prozedur hier aufruft, NICHT der „Super Admin“ (Name entspricht dem Namen der Datenbank) und auch NICHT in der Gruppe „super admin“ (ID „0“) ist, muß „UserGroupID“ die ID einer Gruppe sein, der er selbst angehört !
2.) Hier muß im Fall „DBGroupAdmin = 0“ IMMER „NULL“ angegeben werden, weil der neue Benutzer dann der (Datenbank-)Gruppe „public“ angehört und eine Gruppen-Zuordnung keinen Sinn macht, da dieser Benutzer sowieso nur „public“-Prozeduren ausführen kann !

6. Es wird eine Person des Typs „dStoreUser“ angelegt, wobei die Eigenschaft zum Merkmal „UserName“ natürlich mit „UserName“ belegt wird, und als „Password“ der in „CreatePersonWithPassword“ angegebene Wert gewählt wird - bei Angabe von „NULL“ ermitteln wir den SHA1-Wert (i.d.R. mit einem geheimen „salt“, s. „PersonTypeSettings“-Eintrag zum Schlüssel „DefaultEncryptionAlgorithm“) für „DBPassword“.
Hinweis : Wenn „CreatePersonWithPassword“ angegeben ist, sollte dies natürlich „DBPassword“ entsprechen - nur eben verschlüsselt ! Genauer muß es die Form…
{<Verschl.-Algorithmus (max. 10 Zeichen)>}<verschlüsseltes DBPassword, mind. 5 Zeichen, nur Zahlen/Buchst.>
… haben (s.a. pm_GetEncryptionAlgorithm_Pu).
Falls es nicht diese Form hat oder andere Zeichen außer Buchstaben, Zahlen, „-“ und geschweifte Klammern enthält, gibt es einen Fehler !

7. Falls „UserMayCreateNewUsers“ mit „1“ übergeben wird, vergeben wir dem neuen Login noch die ASE-Rolle „sso“ (wird benötigt, um Logins/Benutzer im ASE anlegen zu können) und gewähren dem Benutzer „UserName“ Ausführungsrechte auf diese Prozedur hier - damit der neue Benutzer seinerseits neue Benutzer anlegen kann.

Die Prozedur hat keine Rückgaben.

Die Prozedur hat keine Output-Parameter.

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

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

• mi_CreatedStoreUser_Ad im Engine Playground öffnen

Unformatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/mi_CreatedStoreUser_Ad?UserName=<value>&DBPassword=<value>&DBLoginDescription=<value>'

Mit xmllint ⁵⁾ formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/mi_CreatedStoreUser_Ad?UserName=<value>&DBPassword=<value>&DBLoginDescription=<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'),
	'mi_CreatedStoreUser_Ad',
		array(
			'UserName' => '<value>',
			'DBPassword' => '<value>',
			'DBLoginDescription' => '<value>',
			// 'DBLogin' => NULL,
			// 'DBGroupAdmin' => 1,
			// 'UserGroupID' => 1,
			// 'CreatePersonWithPassword' => NULL,
			// 'UserMayCreateNewUsers' => 0,
			// 'AbortIfLoginAlreadyExists' => 1
		)
);
 
$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="mi_CreatedStoreUser_Ad">
			<Parameters>
				<Parameter Name="UserName"><!-- varchar value --></Parameter>
				<Parameter Name="DBPassword"><!-- varchar value --></Parameter>
				<Parameter Name="DBLoginDescription"><!-- varchar value --></Parameter>
				<!-- <Parameter Name="DBLogin">NULL</Parameter> -->
				<!-- <Parameter Name="DBGroupAdmin">1</Parameter> -->
				<!-- <Parameter Name="UserGroupID">1</Parameter> -->
				<!-- <Parameter Name="CreatePersonWithPassword">NULL</Parameter> -->
				<!-- <Parameter Name="UserMayCreateNewUsers">0</Parameter> -->
				<!-- <Parameter Name="AbortIfLoginAlreadyExists">1</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>