Mail-Routing nach Replikation erzwingen?

[Michael.T]

Hallo zusammen,

ich habe ein Problem in einer Workflow-Anwendung in replizierter Umgebung:

Beim Abschließen eines Workflowschritts wird eine Mail mit DocLink auf das, zu bearbeitende Dokument, versendet. Wenn der nächste Bearbeiter auf einer anderen Replik arbeitet, wird nach derzeitigen Einstellungen die Mail früher zugestellt als das Dokument repliziert wird. Öffnet der User nun den Link, wird er auf die, von ihm aus gesehen, entfernte Replik umgeleitet. Je nach Leitung ist das ganze dann sehr unperformant.

Nun meine Frage: Gibt es eine Möglichkeit zu erzwingen, dass die Serverreplikation vor dem Mail-Routing durchgeführt wird, so dass das o.g. Problem nicht auftreten kann?

Vielen Dank für Eure Hilfe!
Michael Timmermann

[Glombi]

Hallo und willkommen im Forum!

Das Mail-Routing ist unabhängig von der Replikation.
Man kann nun an einigen Stellen schrauben:
a) Die Datenbank in sehr kurzen Intervallen replizieren.
b) Eine Replizierung per LotusScript anstoßen. Z.b. in dem Script, welches das Mail sendet.
c) Das Mail-Routing verlagern: Statt das Mail direkt loszusenden, wird ein Request-Dokument angelegt. Ein periodischer Agent versendet dann die Mails, nachdem dieser geprüft hat, ob das Dokument auf allen Server vorhanden ist.

Eine Kombination von a) und c) wäre sinnvoll.

Es muss dann in einem Konfigurationsdokument hinterlegt werden, auf welchen Server nachgesehen werden soll.

Andreas

[Michael.T]

Hallo Andreas,

danke für die schnelle Antwort! Sowas hatte ich schon befürchtet. Das Replikationsintervall haben wir schon extrem verkürzt. Die Methode mit den Server-Requests(c) erzeugt natürlich zusätzliche Fehlerquellen zur Lösung eines eigentlich so einfachen Problems. Vor allem ärgert mich die Verhältnismäßigkeit, weil die User sich wahrscheinlich nur in der Einführungspase so auf ihre Workflowschritte stürzen.

Was passiert, wenn man in einem gemeinsamen Verbindungsdokument für Replikation und Mail-Routing die Anzahl der kritischen Mails für sofortiges Routing auf 0 oder einen sehr hohen Wert setzt. Wird die Replikation und das Routing dann nicht etwa zeitgleich stattfinden oder wird das Routing noch an anderer Stelle geregelt?

Bei dem Ansatz (b), bei dem man die Replikation im Hintergrund vom Benutzer anstoßen lässt bevor die Mail verschickt wird, wäre für mich ein K.O. Kriterium, wenn die entferte Replik bei der Replikation automatisch zum Arbeitsbereich hinzugefügt oder bei vorhandenen "Kacheln" nach oben geholt würde. Dann würde er wahrscheinlich bei der nächsten Benutzung der Anwendung aus Versehen in der entferten Replik landen. Weiss dazu jemand etwas?
Ansonsten finde ich den Ansatz nicht so schlecht, da in diesem Projekt standortübergreifende Workflows eher die Ausnahme sind. Man müsste die Replikation ja nur dann anstossen, wenn das Mailfile des Empfängers auf einem entferten Server liegt.

Das Forum verfolge ich schon länger und habe dank der vielen kompeteten Beiträge in den meisten Fällen schon etwas brauchbares in alten Artikeln gefunden. Ich hoffe ich kann demnächst auch mal etwas beitragen.

Schön Grüße, Michael

[koehlerbv]

Hallo Michael,

meinst Du wirklich, dass das ein sooo einfaches Problem ist in einer verteilten Umgebung ? Ich meine: Nein, das ist kein einfaches Problem.

Da für das Versenden von Mails und die Replikation (naturgemäss) zwei unterschiedliche Tasks verantwortlich sind, kannst Du diese nicht miteinander koppeln. Auch das Setzen von Prioritäten ändert da nichts.

In Fällen, bei denen den Usern nicht zu vermitteln ist, dass Mails ankommen und auf noch nicht replizierte Dokumente verweisen (was ja durchaus öfters vorkommt), arbeite ich mit der Variante c), die Andreas "Glombi" genannt hat. Hier allerdings mit der Abweichung, dass ein Agent in allen Repliken werkelt, der auf neue oder veränderte Dokumente wirkt. Dieser schaut nach neuen Mail-Dokumenten (die also nicht direkt versendet werden). Der Agent löst dabei hinsichtlich der Recipients auch Gruppen (rekursiv) und Rollen (die der Einfachheit halber auch zulässige Adressaten sind) auf und "merkt" sich dieses Dokument als "versandt" (er erzeugt ein neues Item in dem Mail-Dokument mit seinem Servernamen - dies zur Vermeidung von Replizierkonflikten). Wenn ein Server erkennt, dass Items mit allen beteiligten Servernamen vorhanden sind, löscht er dieses Maildokument, da alle Versandoperationen ausgeführt sind.

Trivial ist ist das natürlich nicht - aber wie schon gesagt: Auch das Problem ist alles andere als trivial. Aber sehr interessant 

Bernhard

[Michael.T]

Hallo Bernhard,

vielen Dank für deine Antwort! Du hast natürlich recht, daß der technische Hintergrund nicht ganz ohne ist.  Es wäre ja auch sonst zu einfach. 

Wir werden es sehr ähnlich zu deiner Beschreibung lösen. Unser Modul sieht allerdings separate Anfragedokumente für jeden angebundenen Server vor, die nacheinander auf den betreffenden Servern gelöscht werden.

Schöne Grüße, Michael