Das Notes Forum
Domino 9 und frühere Versionen => ND9: Entwicklung => Thema gestartet von: ralph71 am 25.04.19 - 09:26:36
-
Hallo zusammen,
ich möchte einen Agenten nicht mit Client-, sondern mit Serverberechtigung ausführen lassen.
Hintergrund: nur der Server sieht alle Kundennummern, der Client ja nach Berechtigung nur Teile davon. Soll also eine neue Kundennummer angelegt werden, dann muss eine freie Kundennummer (ich addiere zur letzten Nummer die Zahl 1) gefunden werden.
Client-Aufruf:
Dim session As New NotesSession
Dim db As NotesDatabase
Set db = session.CurrentDatabase
Dim agent As NotesAgent
Set agent = db.GetAgent("ZneueKundennummer")
Call Agent.Run()
Agent auf Server:
Sicherheit: Ausführen im Namen von: da steht ein vollberechtigter Server drin
Sicherheit: Sicherheitsstufe zur Laufzeit: 3
Rufe ich den Agenten mit Admin-Rechten auf, funktioniert dieser problemlos, weil der Admin alle Dokumente sehen darf. Dh obige Einstellungen wirken sich nicht auf den Aufruf aus.
Was tun?
Vielen Dank!
-
Hallo,
z.B. ein "Dummy-Dokument" mit der zuletzt vergebenen Nummer mitführen und die nächste mögliche Nummer über dieses Dokument ermitteln.
Andreas
-
Auf diese Idee bin ich schon gekommen.
Aber viel besser wäre es, die Agent unter anderem User zu starten. Ist das nicht möglich?
Edit: insgesamt habe ich über 6000 Nummernkreise. Dh hier überall die Max-Werte bestimmen und dann immer mitziehen ist irgendwie nicht so toll... :-\
-
Die Abfrage für die Nummer könntest Du via Webservice machen.
Der Webservice liefe dann mit den Server rechten.
-
Ein Dokument in der Datenbank für jeden User (z.B. ein Profildokument), in den schreibst Du beim Aufruf rein, was gesucht wird (z.B. welcher Nummernkreis). Der Agent wird vom Server signiert und mittels agent.RunOnServer (noteid -> die des Profils) aufgerufen. Der Agent liest aus dem Dokument, was er suchen soll, sucht, findet und schreibt zurück in das Profil. Die aufrufende Aktion wirft das Profil weg und holt es neu, dort steht dann die neue Nummer.
-
Bei Profildokumenten ist die Anzahl innerhalb der DB begrenzt, da bin ich auch schon mal auf die Nase gefallen.
Aber die Idee hat was:Einfach die User ein Dokument erstellen lassen mit der Suchanfrage und dann einen zweiten Agenten mit Noteid aufrufen um den Wert zu erhalten.
Oder noch einfacher:Der Anwender erstellt ein richtiges Kundendokument ohne Kundennummer und ein Agent im Hintergrund schreibt diese dann direkt automatisch rein.
-
Oder man trennt sich von dem Blödsinn fortlaufender Nummern und generiert die Kundennummer mit einem anderen Algorithmus.
-
Kategorisierungs-Fehler nutzen, um die Kundennummern trotz fehlender Leserechte zu lesen, ist keine Option?
-
Oder man trennt sich von dem Blödsinn fortlaufender Nummern und generiert die Kundennummer mit einem anderen Algorithmus.
Egal wie viel Aufwand man betreibt.
Wenn zwei gleichzeitig zugreifen.
Wenn die DB im Cluster ist.
Dann hat man doppelte Nummern.
Selbst wenn das Dokument gesperrt wird.
Wenn das erste mal ein Dokument gar nicht mehr freigegeben wird...
Einen anderen Algorithmus zu nutzen ist einfacher.
Wenn es aber unbedingt fortlaufende Nummern sein müssen.
Dann ist dies hier ein Ansatz einer Lösung:
https://blog.thomasbandt.de/39/2081/de/blog/sql-server-eindeutige-id-ohne-identity-erzeugen.html
-
So, jetzt hat's etwas gedauert.
Ich habe es jetzt mit einer weiteren Datenbank gelöst. Dort werden alle Nummernkreise und die dazu höchste Kundennummer gespeichert. Die Maskenfelder können direkt nicht gepflegt werden (schreibgeschützt).
Das Skript holt sich über ein einfaches getdocumentsbykey die letzte Nummer, addiert eins dazu, generiert den Kunden und schreibt diese dann wieder in die Datenbank zurück. Die Hilfedatenbank hat keine Replik. Das reduziert die doppelte Nummernvergabe erheblich und ist für die vorhandene Erfassungskultur ausreichend (zum Glück).
Fortlaufende Nummer: wenn die Kundennummer gleichzeitig ein Schlüssel für zb örtliche Zuständigkeiten ist und eine Gesamtzeichenzahl nicht überschritten werden darf, dann bleibt da nicht viel übrig.
@ralf_b: Kundendokument ohne Nummer erstellen lassen und Agent..... -> genau das war ja mein ursprünglicher Ansatz.
Webservice: Mal ein ganz anderer, interessanter Ansatz.😀
Danke für die guten Überlegungen!
Grüße
Ralph