Personengebundene Profildokumente

[Marinero Atlántico]

Ein Notes-ini Eintrag scheint auf 255 Zeichen beschränkt zu sein.
Wenn man mehr Zeichen braucht, sollte man ein Personengebundenes Profildokument benutzen. Right
Witzig. Das erste mal das ich das mache.
Sind damit eigentlich irgendwelche Probleme verbunden?
Ich brauche das in diesem Kontext:

1. Langer Formelsprachencode hinter Button startet (Button wird von user gedrückt, logisch)
2. Formelsprachencode ruft LotusScript Agenten auf.
3. Langer Formelsprachencode benutzt Werte, die der LotusScript Agent ermittelt hat, für die Weiterverarbeitung.

Ich muss also Werte aus dem Kontext des called LotusScript Agenten im Kontext des aufrufenden Codes verfügbar machen.
IMHO geht das am besten über Environment Variablen und wenn Datenmenge >255 chars (1 char = 2 Byte. ja klar, oder. da lacht der Jens:-) ) dann eben über persönliche Profildokumente.

Die ganze Konstruktion führt natürlich auch dazu, dass Werte nur über einen kurzen Zeitraum in dem persönlichen Profildokument gehalten werden.
Wo werden diese persönlichen Profildokumente eigentlich gespeichert. Auf dem Server? Auf dem Client?
Blähen sie den Gesamtspeicherbedarf der nsf stark auf? Ich denke. Nein.

pls explain

Axel

[Thomas Schulte]

Was du da vorhast ist potentiell tödlich für deine Anwendung. Nicht wegen des Speicherbedrafes der ist zu vernachlässigen sondern wegen der Tatsache das einmal aufgerufene Profildokumente solange wie du den Client nicht wieder runterfährst im Arbeitspeicher verweilen.
An deiner Stelle würde ich einfach, wenn es schon einDokument pro User ist ein stinknormales Notes Dokument erstellen, das mit Leser und Autorenfeldern auf den Server und auf den Anwender hin dichtmachen und dann ganz normal über eine Ansicht und GetDocumentByKey holen.

[Marinero Atlántico]

Das Profildokument hat nur 1 Feld. Wert ist ein String mit 1000 chars (mehr oder weniger). Ist das wirklich so problematisch?
Soviel Speicher kann das doch gar nicht belegen. Oder?
Dann wird eben ein Teil des Arbeitsspeichers belegt.
Ich bin traditionell auch Gegner von Profildokumenten.
Alternative wäre mehrere Notes-Ini Einträge.
Mehrere, weil die Felder eben insgesamt länger sind als 255 chars.
Da die Felder einzelnen Felder aber variable Längen haben, ist das auch ein bischen problematisch.


Gruß Axel

[klaussal]

Das Problem dabei ist, dass Änderungen am Profil-Dok erst nach Neustart des Client gezogen werden, weil das Dok eben im Cache gehalten wird.
Das ist der Knackpunkt. Ich würde auch ein ganz Stinknormales Dok daraus machen.

klaus

[Thomas Schulte]

Das Profildokument hat nur 1 Feld. Wert ist ein String mit 1000 chars (mehr oder weniger). Ist das wirklich so problematisch?
Soviel Speicher kann das doch gar nicht belegen. Oder?

Darum (um den Arbeitsspeicher) geht es doch gar nicht. Wenn deine Einstellungen im Profildokument sich während einer Session des Benutzers nicht ändern dann hast du da keine Probleme mit. Veränderst du aber den Eintrag und willst dann den veränderten Eintrag nutzen ohne Den Client zwischendurch zu beenden, dann hast du Probleme weil du immer den alten Wert zurückbekommen wirst egal was du versuchst. Deswegen sind Profildokumente ja bei eindeutigen Nummern so ziemlich die schlechteste aller Möglichkeiten die man sich vorstellen kann

[Thomas Schulte]

Klauss war schneller

[klaussal]

Code

Klauss war schneller

.... trotz des hohen Alters.. 

[Marinero Atlántico]

Das ist zwischen den hooks NotesClient hochfahren ein Read-Only cache. 
Vielen Dank für die Info 
Schlau von mir, dass ich diesen Profildokument-Quatsch jahrelang ignoriert habe.

Wir nehmen vermutlich doch die Notes.ini.
Auf Skript wird der Gesamtwert in 5 Teile mit 255 chars zerlegt und in 5 Notes-ini Variablen gespeichert. Das sollte reichen.
Scope-mässig ist das auch klar. D.h. die werden dort nur sehr kurz gehalten und am Ende des Aufrufs des Formel-Agenten gelehrt (= kein Müll). Ausser bei Abstürzen. Aber sehr unwahrscheinlich und wenn dann unproblematisch.
Will da nicht noch mehr Dokumente, Ansichten erzeugen.

Irgendwelche Einwände?

Gruß Axel
 

[klaussal]

... es soll ja Leute geben, die spielen mit dem Editor rum.....

[Marinero Atlántico]

Darum (um den Arbeitsspeicher) geht es doch gar nicht. Wenn deine Einstellungen im Profildokument sich während einer Session des Benutzers nicht ändern dann hast du da keine Probleme mit. Veränderst du aber den Eintrag und willst dann den veränderten Eintrag nutzen ohne Den Client zwischendurch zu beenden, dann hast du Probleme weil du immer den alten Wert zurückbekommen wirst egal was du versuchst. Deswegen sind Profildokumente ja bei eindeutigen Nummern so ziemlich die schlechteste aller Möglichkeiten die man sich vorstellen kann

@All:
In meinem Test hat sich eben ergeben, dass es sich hier um ein FALSCHE INFORMATION handelt.
Man kann sehr wohl in Personengebundene Profildokumente Sachen reinschreiben und auslesen.
Updates auf besagtes Profildokument werden wirksam, ohne dass der Client neu gestartet werden muss. Getestet mit einem 4.6er Client. Wir werden das noch mit einem 5er Client testen. 

@Jens, @Bernhard, @Eknori, @Glombi oder @Lossa: Kann bitte hier mal jemand für Klarheit sorgen.

... es soll ja Leute geben, die spielen mit dem Editor rum.....

Könnten Sie mir bitte diese Andeutung erklären. Ich verstehe sie nicht.


mfg Axel

[klaussal]

... man kann ja mit dem Editor die notes.ini ganz einfach verändern... 

klaus

[Thomas Schulte]

Wenn deine Einstellungen im Profildokument sich während einer Session des Benutzers nicht ändern dann hast du da keine Probleme mit.

@All:
In meinem Test hat sich eben ergeben, dass es sich hier um ein FALSCHE INFORMATION handelt.

Würdest du deinen Test freundlicherweise spezifizieren.

[Marinero Atlántico]

Ja:

Ein Agent startet zunächst den Script agenten und dann den Formelsprachen Agenten (s.u.)

Script Agent

Code

Set docProfil = db.GetProfileDocument( "UserData" , session.username)
				If Not docProfil Is Nothing Then
					docProfil.AddressData = StrData
					Call docProfil.save(True,True)
					Print "Profildokument (UserData) wurde mit Onlinedaten gespeichert."
				End If

kurz später wird dann über Formelsprache ausgelesen:

Code

FIELD AddressData := @GetProfileField("userData"; "AdressData"; @UserName);
@prompt([oK];"AddressData"; AddressData);

Man kann das mehrmals aufrufen und andere Werte in das Profildokument schreiben. Es ist jeweils der neue Wert da.

@Klaus: User, die ihre notes.ini verändern sind nicht mein Problem. Wenn die das machen, ist das der ihr Fehlverhalten. Schliesslich können sie so auch ihren gesamten Notes-Client lahmlegen, wenn sie es wollen.
 
Das ist quasi eine Websphere MQ Anbindung einer vorhandenen, komplexen, historisch gewachsenen Notes Legacy Anwendung. Der Formelsprachen-Agent wäre sehr aufwendig in Skript umzuschreiben (weil ziemlich umfangreich). Mit Formelsprache kann man aber nicht so gut bzw. überhaupt nicht auf Websphere MQ (ex MQ-Series) zugreifen

Gruß Axel

[TMC]

Axel, ich kann keine offiziellen Quellen nennen, aber meine bisherige Erfahrung zeigte:
Wenn ein Profildokument in einer DB *programmatisch* gesetzt wird, und dessen Inhalt dann wieder *programmatisch* ausgelesen wird, hatte ich noch keine Probleme (wenn logischerweise die DB auf dem selben Server angesprochen wird) bezügl. Cache.
Wenn allerdings ein User manuell in ein Profil-Dok geht, dort was ändert, und dann gleich danach z.B. eine Dialogbox aufruft, welche die Inhalte des Profil-Doks zieht, so gibt es ein Cache-Problem und die Änderung ist oft nicht gleich da.

Andere Frage:
Du schreibst, dass Du hier sowohl @Formula als auch LS verwendest, und zwischen den beiden wohl Variablen (Strings) austauschst.
Wenn ich bisher sowas machte, dann hatte ich mich eigentlich immer auf 1 Sprache geeinigt, das war dann meist LS. Dann erübrigte sich nämlich der Umweg über notes.ini, Profiledoc, normales Doc, etc., um Variablen zu übergeben.
Kannst Du Deine @Formula nicht gleich in LS umsetzen?

Matthias

[Marinero Atlántico]

Wenn ich bisher sowas machte, dann hatte ich mich eigentlich immer auf 1 Sprache geeinigt, das war dann meist LS. Dann erübrigte sich nämlich der Umweg über notes.ini, Profiledoc, normales Doc, etc., um Variablen zu übergeben.
Kannst Du Deine @Formula nicht gleich in LS umsetzen?

Hi,

normalerweise würde ich das umschreiben. Hier handelt es sich aber um eine komplexe, mehrfach erweiterte Anwendung. Das sind 4,5 Seiten Formelsprache im Ausdruck.
Dies in Script umzuschreiben würde ca. 1 Tag dauern. Und dann beeinflusst das evtl. die Responsivität (Performance) in einem spürbaren Ausmaß. Dies stösst dann ggbfls auf Akzeptanzprobleme.
Da ist dann auch anderer Code, der genauso aufgebaut ist. Würde ich es gründlich machen, müßte ich die auch ändern.
Aus all diesen Gründen ist das persönliche Profildokument hier eigentlich ganz sinnvoll.

Gruß Axel

[animate]

Meine Erfahrung mir Profildokumenten:

Sie und damit ihr Inhalt werden im RAM gespeichert, um sehr schnellen Zugriff zu ermöglichen
Ich kann nicht sagen, ob die Werte, die ich gerade auslese, aktuell sind oder alt
Aktualisierung findet nicht zwingend bei Beenden + Neustart des Clients statt
In Webanwendungen tödlich
Ich verwende sie nie wieder, lieber einfache Dokuemente

[koehlerbv]

Userbezogene ProfileDocs erfüllen eigentlich genau den Zweck, den man von ihnen erwartet: Sie sind schnell (weil im RAM gechached), und da sie personenbezogen sind, sind sie immer aktuell (weil - wenn man die Userbezogenheit nicht irgendwie übel unterläuft - sie jede vom User vorgenommene Änderung eben auch im RAM wiederspiegeln). Und wenn der Client beendet wird, geht auch der Pointer zum Cache verloren. Beim Neustart werden sie bei erster Anforderung neu eingelesen !
Genau das sollte aber gar kein Problem darstellen - siehe oben.

Übel wird es hingegen bei gemeinsam verwendeten ProfileDocs. Diese sollten nur dann zum Einsatz kommen, wenn die ProfileDocs äusserst selten geändert werden (Konfigurationen zum Beispiel). Häufig schliesst aber genau diese Bedingung "selten geändert" den Einsatz von ProfileDocs aus, und der erfahrene Programmierer verwendet schnell erreichbare "normale Dokumente".

HTH,
Bernhard

PS: Wenn ich Axels Anforderungen richtig gelesen habe, sind daher persönliche ProfileDocs die richtige Lösung für sein Problem. Die NOTES.INI und dann auch noch das Splitten von Strings ist ein übles Vorgehen, unsicher dazu - und macht wegen Chaching de facto keinerlei Unterschiede.

[Glombi]

Profildokument sind
- schnell da im Cache
- u.U. unbrauchbar da im Cache

Also: Diese nur verwenden, wenn deren Inhalt sich innerhalb einer Session nicht ändert.

Ich versuche mal im folgenden einige Links zu sammeln. Wenn genug da sind bzw. auch Interesse besteht, sollten wird das mal als BP zusammenstellen:

http://www-10.lotus.com/ldd/today.nsf/0/f1e0daa9317ae8a6852565560071fb87?OpenDocument
http://www.dominopower.com/issues/issue200409/00001383001.html
http://www.breakingpar.com/bkp/home.nsf/0/87256B280015193F87256D26006BA928


Bei einem meiner Kunden sind Profile Dokument verschwunden. als der Server gecrashed ist. Da diese für fortlaufende Nummern verwendet werden, war das unschön.

Andreas

[Glombi]

Aus der KBASE:
Title:   
   @GetProfileField Function Pulls From Database Cache Over the Web
Product:   Lotus Domino  >  Lotus Domino Server  >  Version 5.x
Platform(s):   Platform Independent
Date:   13.09.2004
Doc Number:   1095930


This document is based on the following Software Problem Report (SPR):
About SPRs
SPR Number   SPR Status   SPR Fixed Release
HMEA4HPUGD   Under Investigation   Not Applicable
Problem
The @GetProfileField function is designed to retrieve a field from a profile document and cache the field value for the remainder of the session.

However, the @GetProfileField function has the capability of pulling information from cache and never actually updates current cached information, prevent current information from getting to the profile document.  The servers shows that the agent ran, but the information is pulled from the database cache.



Solution
This issue has been reported to Lotus Quality Engineering.  As a workaround, instead of modifying the Profile Document's item values, try deleting the profile document and recreating it via LotusScript.   For example:

set doc = db.GetProfileDocument( profilename$, username$ )
call doc.remove( true )
set doc = db.GetProfileDocument( profilename$, username$ )
doc.fieldname = "new value"
call doc.save( false, false )

[Marinero Atlántico]

unsere bisherigen Ergebnisse sind stabil. D.h. für diesen Verwendungszweck (PersonenProfile strikt: reinschreiben aus LS -> auslesen mit Formelsprachencode, der den LS-Script Agenten vorher gestartet hat (alles ein Prozess) scheint es wirklich stabil zu funktionieren).
Nun sind caches in verteilten Umgebungen wirklich nicht trivial zu implementieren.