eigene "Replizierung"

[Demian]

Moin,moin alle zusammen,

habe da mal ne Frage. Ich will in einer Datenbank Personaldaten pflegen. Jetzt sollen nach Änderungen die Personaldaten entwrechend aktualisiert werden. Ich hatte mir das so vorgestellt, dass ich via getdocumentbykey das enstprechende Mitarbeiterdokument suche, lösche und ersetze.

Soweit ja kein PRoblem. Mir stellt sich nur die Frage, was passiert, wenn das Dokument in der anderen Datenbank von jemandem geöffnet ist???

Hat jemand schonmal eine ähnliche Konstellation gehabt?

Gruß
Demian

[m3]

 

Dokument in der View anklicken, Dokument geht in der MAske auf, Daten ändern, speichern, Maske schließen.

Wo brauchst Du da getdocumentbykey?

Suchen, löschen, neu anlegen ist ein klassisches Anti-Pattern in der Notes-Entwicklung. Siehe http://www.wissel.net/blog/d6plinks/SHWL-778HCT und http://www.lotus.com/ldd/bpmpblog.nsf/dx/lotsadocs1

was passiert, wenn das Dokument in der anderen Datenbank von jemandem geöffnet ist

a) welche "andere" Datenbank. Etwas mehr Input bitte.
b) Replikationskonflikt?

[Demian]

 

Mir fällt gerade auf, ich hab das was ganz fundamentales vergessen:

Die Personaldaten sind in mehreren Datenbanken vorhanden und sollen aber nur in einer gepflegt werden und die Änderungen in die anderen DB's übertragen werden. Sorry. Wenn man in der Eile schreibt...

Was den Link betrifft: Meine Englisch-Kenntnisse belaufen sich eher auf Grundwissen, aber was ich so rauslese, geht sowas nur nachts per Agent, wenn keine Dokumente geöffnet sind???

Sprich wenn ich morgens um 8 Uhr die Anschrift ändere, würde die neue Anschrift erst am nächsten Tag in den anderen Datenbanken vorhanden sein. Ist dann aber eher bescheiden, wenn beispielsweise um 9 Uhr ein Brief an die alte Anschrift geschrieben wird

Sehe ich das richtig???

Gruß
Demian
 

[Driri]

Sagen wir mal so, wenn Du das tagsüber machst, während Benutzer auf die Dokumente zugreifen, wird es vermehrt zu Speicherkonflikten kommen, wenn Du im Hintergrund die Dokumente updatest.

Du müßtest dann also dafür sorgen, daß das Dokument nicht im Zugriff ist (z.B. per Lock). Dokumente, die im Zugriff sind, müßtest Du dann überspringen und später abarbeiten.

Von daher ist ein Updatelauf in der Nacht, wo mit hoher Wahrscheinlichkeit kein User auf die Dokumente zugreift, die einfachere Variante.

[Demian]

Moin Driri,

nachts die Dokumente zu aktualisieren ist schon einfacher. Der Nachteil ist halt, wie oben geschrieben, dass dann evtl Briefe an falsche Adressen gehen. Gut, die meisten machen nen Nachsendeauftrag und die Wahrscheinlichkeit, dass genau an dem Tag der Änderung an die Person nen Brief raus geht ist auch eher gering, aber ich weiß jetzt schon was los ist, wenn genau die 2 Sachen nicht zutreffen.

Wie man abfragt, ob ein Dok zur Zeit von jmd. geöffnet ist, habe ich glaub ich mal gelesen und wäre nicht so das Problem. Aber was meinst du mit überspringen und später abarbeiten? Das wäre ja nur über eine "Endlos-Schleife" lösbar, oder?

Gruß
Demian

[Driri]

Du mußt halt sicherstellen, daß geöffnete Dokumente anders bzw. zu einem späteren Zeitpunkt verarbeitet werden. Andernfalls wirst Du dich mit Speicherkonflikten rumschlagen dürfen. Das Überspringen war ein Beispiel.

[Demian]

Gut, werde dann mal sehen, wie ich das handhabe. Evtl. mache ich einfach nen B-Agenten der ne E-Mail an alle betroffenen schickt, dass sich was geändert hat mit dem Hinweis, dass die Änderungen erst am nächsten Tag ersichtlich sind. Und die Änderungen übernehmen, werde ich dann nachts durch einen weiteren Agent. Dann können die betroffenen Sachbearbeiter die neue Anschrift ja erfragen, wenn wirklich an dem Tag unbedingt was raus muss.

Ja, glaube so mach ich das. Ist wohl das sauberste.

Danke für die Anregungen. 

Gruß
Demian

[koehlerbv]

Es führen da sicherlich viele Wege nach Rom. Das sauberste wäre, überhaupt nicht mehr im Frontend zu speichern, aber das dürfte Eure bestehenden Datenbanken extrem umkrempeln und bedeutet so oder so einen Riesenaufwand.

Ich würde allerdings nicht wegen jedem Pippifax den Leuten eine Mail schicken - die kriegen sonst die Krise, lesen das Zeugs nicht mehr bzw. merken sich das im entscheidenden Moment eh nicht.
Auch da gibt es Alternativen: Beispielsweise erzeugst Du Antwortdokumente bei Änderungen, die die gemachte Änderung verzeichnen. Im PostOpen des eigentlichen Dokuments prüfst Du auf Antwortdokumente und lässt bei Bedarf eine Messagebox aufpoppen. Nach Übertrag der Änderungen werden die Antwortdokumente wieder gelöscht.
Um die eigentliche DB(s) nicht vollzumüllen, kann man diese Verweisdokumente auch in eine externe DB legen, die man ab und an nach Lauf des Updates auch mal löschen kann.

Möglichkeiten gibt es - wie gesagt - mehr als eine.

Bernhard

[Demian]

Moin Bernhard,

was genau meinst du mit im Frontend speichern? Die Doks sollen ja ganz normal gespeichert werden. Im Postsave würde ich dann auf Änderungen prüfen und im Backend die Aktualisierungen auf die anderen DB's vornehmen. Die eigentliche DB ist noch nicht existent. Ich wollte das nur vorab schonmal klären um die grobe Richtung planen zu können.

Das mit den Antwortdoks verstehe ich nciht ganz. Sollen die in der Datenbank sein, in der die Daten gepflegt werden, oder in der in der die Daten aktualisiert werden?


Gruß
Demian

[koehlerbv]

was genau meinst du mit im Frontend speichern?

Das verstehe ich nun wieder nicht. Wieviel Arten, im Frontend zu speichern, kennst Du denn?

Das mit den Antwortdoks verstehe ich nciht ganz. Sollen die in der Datenbank sein, in der die Daten gepflegt werden, oder in der in der die Daten aktualisiert werden?

Antwortdokumente oder andere, spielt nicht unbedingt DIE Rolle. Es müssten Dokumente sein, die im PostOpen eines Dokuments, für welches eine Änderung ANSTEHT, erreichbar sind, um die erforderliche "Warnung vor dem Hunde" ausgeben zu können.

Bernhard

[Demian]

Moin Bernhard,

wenn ich Frontend und Backend höre denke ich immer an eigenes Script. Aber die Dokumente werden ja auf "normalem" Wege gespeichert. Ist das dann Frontend?

Durch den Tipp mit dem Erreichbar sein, weiß ich jetzt wie ich das mache. Ich mache einfach eine neue Ansicht und Maske, in der die Änderungen gespeichert werden. Dann mach ich nen Agenten der stündlich oder so läuft und die Doks abarbeitet, wenn diese nicht gelockt sind und nach Änderungen löscht. Die gelockten werden übersprungen und beim nächsten Durchlauf wird versucht diese dann abzuarbeiten.

Ja genau so mache ich das.

Vielen Dank für den Tipp mit den Antwortdoks.

Gruß
Demian

[HarryB]

Die eigentliche DB ist noch nicht existent. Ich wollte das nur vorab schonmal klären um die grobe Richtung planen zu können.

Habe ich das richtig verstanden, dass das Ganze noch programmiert werden soll? In diesem Fall würde ich das ganze Konzept noch mal überdenken...

Viele Grüße
Harry

[Demian]

Moin,moin,

ich sachs mal so. Die Datenbank als solche ist eigentlich fast fertig. Nur die "Replizierung" nicht.
Inwiefern soll ich das Konzept nochmal überdenken? Ich denke die Lösung mit den extra Dokumenten die die Änderungen festhalten und dann vom Agenten abgearbeitet werden ist doch ganz annehmbar, oder nicht?


Gruß
Demian

[HarryB]

Ich denke die Lösung mit den extra Dokumenten die die Änderungen festhalten und dann vom Agenten abgearbeitet werden ist doch ganz annehmbar, oder nicht?

Ich kenne die genauen Anforderungen und die Umgebung nicht, allerdings scheint mir dein Konzept furchtbar kompliziert.

Ich hätte entweder:

• Notes Bordmittel benutzt, indem ich die entsprechende Datenbank für die Replizierung mit "hoher Priorität" kennzeichne und nur auf eine Datenbank (die Quelldatenbank) Schreibzugriff erlaubt ist. Dann stellt man die Replizierung zwischen den Servern für Datenbanken mit hoher Priorität auf 5 Minuten ein und voilá.
• Die Alternative wäre, dass die Zieldatenbanken die Stammdaten gar nicht speichern, sondern sich bei Bedarf live aus der Stammdatenbank holen.

Viele Grüße
Harry

[Demian]

Moin Harry,

Notes Bordmittel benutzt, indem ich die entsprechende Datenbank für die Replizierung mit "hoher Priorität" kennzeichne und nur auf eine Datenbank (die Quelldatenbank) Schreibzugriff erlaubt ist. Dann stellt man die Replizierung zwischen den Servern für Datenbanken mit hoher Priorität auf 5 Minuten ein und voilá.
Die Alternative wäre, dass die Zieldatenbanken die Stammdaten gar nicht speichern, sondern sich bei Bedarf live aus der Stammdatenbank holen.

Darüber habe ich auch schon nachgedacht. Das Problem ist nur, dass die Dokumente in der "Quelldatenbank" Daten enthalten, die die anderen Sachbearbeiter/innen nicht sehen dürfen. Aus dem Grund programmier ich mir die Replizierung lieber selbst und lasse diese dann bei bestimmten Änderungen laufen.

Naja, so kompliziert ist es eigentlich nicht:

In Datenbank a werden Personaldaten gepflegt und in Datenbank b,c,d usw. sollen zum Beispiel nur die Anschriften verfügbar sein und bei Änderungen in Datenbank a auch aktualisiert werden.

Problem ist, dass ich nicht von mir behaupten kann, Notes zu kennen, geschweige denn alle Möglichkeiten die Notes bietet. Alles was ich weiß, erarbeite ich mir selbst. Und da bleibt sicherlich einiges auf der Strecke, was für andere selbstverständlich ist.


Gruß
Demian