Wie ihr vielleicht schon auf unserer Facebook-Seite mitbekommen habt, ist das ITWU-Team ab dem 01.08.2014 um seinen ersten Auszubildenden reicher! Damit ihm die Zeit zwischen der Schule und dem Ausbildungsbeginn aber nicht langweilig wird, treibt sich Dominik schon seit Anfang Juli im ITWU-Büro herum und nutzt die Zeit, um IBM Notes und Domino schonmal unter die Lupe zu nehmen.

Ganz im Geiste des WM-Fiebers hat unser neues fleißiges Bienchen auch glatt schon sein erstes "Whitepaper" fertiggestellt:

 

Schaut doch einfach mal rein, vielleicht ist ja auch für euch der ein oder andere neue Tipp dabei. Uns bleibt jedenfalls nur noch, Dominik und uns eine schöne und erfolgreiche Ausbildungszeit zu wünschen - sie fängt definitiv schonmal gut an!

Habt ihr vielleicht auch noch ein paar nützliche Endanwender-Tipps für Notes 9? Dann schreibt sie uns doch bitte in die Kommentare - vielleicht kriegen wir ja noch eine zweite Fussballmannschaft voll Winken

 

 

In unserem neuesten Anwenderbericht stellen wir euch im Detail unser Projekt bei der SICK AG vor, die kürzlich ihre bisherige Workflow-Engine durch unseren ITWU Kernel abgelöst hat. Den vollständigen Bericht findet ihr auf unserer Referenzseite unter dem Titel: SICK optimiert Workflow mit ITWU Kernel.

Und ich erzähle euch nun, warum ihr euch den Bericht unbedingt durchlesen solltet:

Unserer Meinung nach sind die internen Prozesse eines Unternehmens ständig wachsende Gebilde, die sich kontinuierlich an Veränderungen von innen und außen anpassen müssen. Diese Veränderungen sind nicht nur personeller oder inhaltlicher, sondern oft auch technischer Art.

  • Die Umstellung eines Bearbeitungsschrittes von einem ausgeschiedenen auf einen neuen Mitarbeiter gehört nun wirklich zu den einfachen Veränderungen;
  • die Erweiterung des Workflows um einen zusätzlichen Bearbeitungsschritt ist da schon etwas anspruchsvoller - aber auch diese Anforderung sollte jede gute Workflow-Engine mehr oder weniger einfach lösen können.
  • Weit weniger absehbar sind da die technologischen und plattformabhängigen Veränderungen, an die sich Workflows in Zukunft anpassen müssten. 

Interne Geschäftsprozesse und die darunterliegenden Workflows kontinuierlich zu optimieren, ist zudem eine der besten Möglichkeiten eines Unternehmens, die Effektivität und Produktivität seiner Mitarbeiter hochzuhalten. Natürlich sollten sich die Mitarbeiter bei der Bearbeitung eines Sachverhaltes nicht jede Woche in einen neuen Prozess einarbeiten müssen, aber festgefahrene Strukturen, die durch immer gleichbleibende Arbeitsschritte über Jahre hinweg entstehen, sind doch wohl ohne Zweifel die absoluten Innovations- und Produktivitätskiller. 

 

Die innovativen Sensorlösungen des SICK-Konzerns erkennen Objekte auch im lückenlosen Produktstrom. Für die Kunden von Sick bedeutet dies schlankere Prozesse und die optimale Auslastung ihrer Maschinen. Ein Ziel, welches auch Sick durch die kontinuierliche Optimierung der internen Workflows verfolgt.

 

Damit wir interne Geschäftsprozesse kontinuierlich optimieren und an äußere Veränderungen anpassen können, müssen die Workflow-Engines, auf denen sie basieren ebenfalls flexibel und anpassbar sein. Wenn der Hersteller der Workflow-Engine, die ihr in eurem Unternehmen einsetzt aber auf einmal verkündet, dass er die Weiterentwicklung der Lösung einstellt, ist guter Rat teuer. Wer kann euch garantieren, dass sich die Workflow-Engine auch weiterhin an die technologischen Entwicklungen der Zukunft anpassen lässt?

Genau vor diesem Problem stand auch die SICK AG - und wenn ihr euch diese Frage ebenfalls stellt, mit eurer aktuellen Workflow-Engine nicht mehr ganz zufrieden seid oder auf der Suche nach einer geeigenten Workflow-Engine seid, kommt ihr gar nicht drum herum, euch den Anwenderbericht durchzulesen. Wer weiß, vielleicht seid ihr mit unserer Lösung dann bald genauso zufrieden wie Christoph Märkle, der Leiter der Applikationsentwicklung in der Business Unit Photoelectric Sensors & Fibers bei der SICK AG:

"Die Umstellung auf den ITWU Kernel verlief reibungslos. Die Anwender haben davon so gut wie nichts mitbekommen."

Was sind denn eigentlich eure speziellen Anforderungen an die Workflow-Engine eurer Wahl? Wir freuen uns wie immer über eure Kommentare!

 

 

Im vorherigen Artikel habe ich euch schon die Technologie der Managed Mail Replica (MMR) von IBM Notes und Domino näher gebracht - diesmal geht es ums Detail:

Wie verhalten sich MMRs, was ist bei der Konfiguration wo einzustellen, welche Stolperfallen sollte ich beachten und was mache ich in dem Fall, dass doch etwas schief läuft?

Wie bereits erläutert versetzt euch MMR in die Lage, eure Notes Clients direkt vom Home Server des Benutzers via Push mit neuen E-Mails zu versorgen. Der Client ist somit stets up2date und der Benutzer hat ein deutlich performanteres System. Möchte man die Technologie mit Microsoft Outlook vergleichen, so sind MMRs mächtigere lokale OST-Files.

Bei der Konfiguration von MMR geht es um das Zusammenspiel von drei Komponenten:

  1. Der Home-Mail Server des Benutzers.
  2. Eine Richtlinie, welche MMR für den Benutzer aktiviert.
  3. Der Notes Client des Benutzers, welcher eine lokale verwaltete Replik seines Postfachs erhält.

Abb. 1: Mittels einer Desktop Richtlinie wird die MMR erzeugt und eine Verbindung zwischen IBM Domino Server und IBM Notes Client gewährleistet.

 

Der Benutzer selbst bekommt von der lokalen Replik, bis auf den Performance Schub, reichlich wenig mit. Einzig im Postfach wird er oben links darauf hingewiesen, dass das Postfach auf dem er gerade arbeitet, lokal liegt. Um alles andere kümmert sich der Client selbst. Während der Benutzer in seinem Postfach auf dem Server arbeitet, wird im Hintergrund die lokale Replik erzeugt. Anschließend wechselt der Client automatisch "on the fly" auf diese lokale Replik und der Benutzer arbeitet weiter.

 

Abb. 2: Das Postfach zeigt dem Benutzer den Speicherort seiner Datenbank.

 

Für Administratoren oder neugierige Benutzer gibt es auch noch eine weitere Möglichkeit, zu validieren, dass es sich wirklich um eine lokale Replik handelt. In den Datenbankeigenschaften wird eine MMR als Datenbanktyp "Verwaltete Replik" ausgewiesen. Dadurch werden ebenfalls ein Großteil der Einstellungsmöglichkeiten deaktiviert, da diese ja vom Server übernommen und dort zentral eingestellt werden können.

 

Abb. 3: In den Datenbankeinstellungen erkennt man, dass es sich um eine aktive verwaltete Replik handelt.
 

Dabei bringen MMRs noch deutlich mehr als nur einen Performance Schub. Sie reparieren sich selbst. Erkennt der Client ein Problem mit der Datenbank wird der Benutzer automatisch auf die Serverreplik umgeleitet und die lokale Replik neu erstellt. Ob das in der Praxis wirklich funktioniert kann ich nur raten. Ich habe nun seit mehr als einem Jahr eine MMR und habe es jedenfalls noch nicht bemerkt, ob ich zwischendurch mal auf der Serverreplik gearbeitet habe.
 

Konfiguration von Managed Mail Replica

Soviel zur Arbeit mit einer MMR, nun kommen wir zu den Einstellungen der Server-Richtlinie:

Damit eure Mitarbeiter in den Genuss der MMRs kommen, müsst ihr in der Server-Richtlinie eure Desktop-Einstellungen aufrufen und unter dem Reiter "Mail" die Einstellungen für die Mailfiles und die verwalteten Repliken anpassen. Im Feld "Lokale Maildatei" könnt ihr aus dem Drop-Down Menü am besten den Punkt "Verwaltete Replik erstellen oder lokale Replik in verwaltete Replik konvertieren" auswählen. So wird auch bei Benutzern, welche bereits eine lokale Replik auf ihren Rechner haben, diese lokale Replik in eine verwaltete Replik umgewandelt.

 

Abb. 4: Desktopeinstellungen für MMR: bereits vorhandene lokale Repliken sollte man umwandeln und für den vollkommenen Performance Schub die lokale Mail.Box aktivieren!

 

Außerdem gibt es bei den MMR Einstellungen die Option "Selektive Replik", mit der man nur einen Teil der Datenbank lokal replizieren kann und der Rest auf dem Server verbleibt. Um den Wechsel unauffällig im Hintergrund vollziehen zu können, sollten aber stets gesamte Postfächer via MMR repliziert werden. Schlußendlich muss man noch entscheiden für welchen Zeitraum die E-Mails lokal vorgehalten werden sollen. Da bei uns eine serverseitige Archivierungsrichtlinie stets alle E-Mails "älter als 365 Tage" archiviert steht diese Einstellung in Abbildung 4 auf 365 Tagen. Möchte man hingegen sicherstellen, dass die E-Mail ewig lokal vorrätig bleiben, erhöht man den Wert entsprechend. Achtung: Dadurch werden Archivierungskriterien nicht übersprungen! Archivierte E-Mails verschwinden auch immer aus lokalen Postfächern, sobald das nächste mal repliziert wird!

Apropos Replizierung: eine MMR repliziert immer dann, wenn auf dem Server eine neue E-Mail bereit liegt und dies unabhängig von den übrigen Replizierungseinstellungen. Dennoch ist es sinnvoll darauf zu achten, dass man auch gleichzeitig die lokalen Replizierungseinstellungen mit Hilfe der Server-Richtlinie unter "Vorgaben - Replizierung" setzt. Damit sorgt man dem Problem vor, dass im Postfach erstellte E-Mails und Entwürfe nicht nur beim Eintreffen einer neuen E-Mail auf den Server repliziert werden. Der Benutzer merkt so etwas spätestens dann, wenn er auch ein Tablet nutzt und unabhängig vom Arbeitsplatz arbeitet. Ohne festeingestellte Replizierungsintervalle kann es an einem ruhigen Tag sonst mitunter Stunden dauern bis die E-Mail auf den Server repliziert wird.

 

Überwachung und Deaktivierung von Managed Mail Replica

Nachdem die Richtlinie gespeichert und zugewiesen wurde, beginnt der Server selbstständig mit der Bereitstellung der lokalen Repliken. Über den Fortschritt erhält man in der Administrationsoberfläche oder via Konsolenbefehl leider keine Rückmeldung. Hat man nicht entsprechende Monitoring-Lösungen, wie z.B. das ITWU Simple Client Logging, muss man sich ggf. händisch davon überzeugen, dass die lokalen Postfächer umgestellt wurden. Die Benutzer werden es einem auf jeden Fall danken.

Für den Benutzer ist es via Verknüpfungen nun unmöglich, auf seine auf dem Server gespeicherte Postfach-Datenbank zuzugreifen. Nach wenigen Sekunden wechselt er stehts automatisch auf seine lokale Replik. Sollte es doch einmal nötig sein, so muss der Benutzer die Datenbank über den "Database Open"-Dialog (STRG + O) öffnen. Navigiert er auf diesem Wege zu seinem Postfach auf dem Server, switcht das Mailfile nicht auf die lokale Replik.

Solltet ihr irgendwann MMR wieder deaktivieren wollen, z.B. weil eure Nutzer einen ThinClient erhalten und sowieso nur den IBM Notes Client via Citrix durchgereicht bekommen, so könnt ihr die Richtlinie entsprechend anpassen und die lokale bzw. verwaltete Replik löschen lassen. Bei der Übernahme der Richtlinienangaben löscht der Client dann automatisch die lokale Datenbank und leitet den Nutzer wieder auf die in seiner Arbeitsumgebung definierte Datei um.

 

Abb. 5: Die MMR-Einstellungen können ebenfalls dafür genutzt werden, um lokale Repliken zu verhindern.

 

Solltet Ihr Unterstützung bei der Einrichtung oder dem RollOut von MMR haben oder Interesse am ITWU Client Logging haben könnt ihr euch jederzeit gerne bei uns telefonisch melden 05251 288160 oder uns an info@itwu.de eine E-Mail schreiben !
Oder habt ihr MMR vielleicht schon im Einsatz? Dann freuen wir uns darauf, über eure Erfahrungen und Einschätzungen in den Kommentaren zu lesen. Hop hop Winken


 

 

Mit Hilfe der Managed Mail Replica (MMR) nutzt ihr die Vorteile von serverbasierten Postfächern und Client Repliken zugleich. Sie ermöglichen, dass Nutzer auf dem Client - wie auf Traveler Endgeräten bereits gewohnt - Mails via Push Service empfangen können. Bei einer missgünstigen Konfiguration kann dies aber schnell zum Nachteil führen. In diesem Artikel wird die MMR Technologie erläutert. In einem späteren Artikel wird auf die Konfiguration von MMR im Detail eingegangen.

Der Vorteil von serverbasierten Postfächern ist im Wesentlichen, dass E-Mails direkt bei Ankunft sichtbar sind und nicht erst auf das nächste Replizierungsintervall warten müssen. Einher gehen aber auch die Nachteile der Reaktionsgeschwindigkeit, da die Daten ja stets erst über das Netzwerk bzw. ggf. sogar Internet übertragen werden müssen.

Bei lokalen Repliken hat man hingegen den enormen Performanceschub in der Bedienung. Wechselt man in einen Ordner oder klickt "Neue E-Mail" so reagiert der IBM Notes Client direkt und ohne Verzögerung. Der Nachteil ist allerdings, dass man die regelmäßigen Replizierintervalle abwarten muss. Gerade bei einem Telefonat "Ich schicke dir das mal eben [...] und schon angekommen?" wird sowas immer gerne zur Geduldsprobe. Von Kunden, die lokale Mail Repliken nutzen und parallel zum Notes Client der Traveler eingesetzt wird, hören wir auch immer häufig die Frage, warum die Mail immer schneller auf dem Handy sei als auf dem PC. Replizier-Techniken sind in der Regel leider eher asynchron und Zeit verzögert, im Gegensatz zu Push-Techniken.

 

Abb. 1: Gleichzeitig eingesetzte Replizier- und Push-Technologie sind dem Benutzer schwer vermittelbar.

 

Mit MMR ist man nun in der Lage, beide Vorteile zeitgleich zu nutzen und die Nachteile über Bord zu werfen. Eine MMR unterscheidet sich technisch kaum von einer normalen lokalen Replik. So kann auch jede bereits vorhandene lokale Replik eines Postfachs einfach in eine MMR umgewandelt werden. Einzig eine Eigenschaft der Datenbank zeichnet die Replik als "Verwaltete Replik" aus: erreicht den Nutzer auf dem Server eine neue E-Mail, so wird diese direkt vom Server an die von ihm lokal verwaltete Replik repliziert. Die Verzögerung beträgt nun kein Replikationsintervall mehr, sondern höchstens wenige Sekunden. Eine MMR ermöglicht somit, dass die vom IBM Notes Traveler bekannte Push-Technologie auch im Client Umfeld Einzug hält.

 

Abb. 2: Mittels MMR werden alle Endpunkte via Push-Technologie versorgt.

Da MMR stets nur vom Server in Richtung Client pusht, ergibt sich aber die vom Anwender ggf. gespürte Abweichung seines Postausgangs. Schreibt der Anwender nun lokal eine E-Mail, so wird diese - korrekte Einstellungen vorausgesetzt - direkt an den Server übermittelt und dem Empfänger direkt zugestellt. Dieser Sendeprozess sorgt in diesem Moment aber nicht vollautomatisch dafür, dass auch die Mailreplik des Anwenders auf dem Server mit der neuen E-Mail versorgt wurde, dies geschieht doch erst im nächsten definierten Replizierintervall. In diesem kurzen Zeitfenster sieht der Anwender somit seine gesendete E-Mail z.B. nicht auf seinem mobilen Endgerät oder in iNotes. Um diesem Effekt möglichst stark entgegen zu wirken, kann der Administrator mittels einer Desktop-Richtlinie Repliziereinstellungen verteilen.

Wenn ihr mehr über MMR erfahren möchtet, müsst ihr entweder den nächsten Blog-Eintrag zum Thema MMR-Konfiguration abwarten oder uns gleich persönlich auf das Thema ansprechen - entweder telefonisch (05251 288160) oder per E-Mail info@itwu.de. Unsere Superadmins freuen sich schon auf eure Fragen.