Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

RTF-Export aus Mail-DB

<< < (4/5) > >>

Marinero Atlántico:
Kann das, was Thomas gesagt hat, bestätigen.
 
Wir benutzen DXL in einem größeren Projekt zur Archivierung.
In DXL - also xml mit Domino.dtd - werden alle Elemente eines Notes Dokuments (inklusive Hot-Spots, Attachments, eingebettete Objekte, etc) in xml umgesetzt. Diese Datei kann dann in das Archiv geschoben werden.
Dies kann im einfachsten Fall das Dateisystem sein.
Diese dxl Datei kann problemlos und jederzeit in ein Notes-Dokument zurück konvertiert werden.
Eingebettete Objekte und Attachments stehen dabei auch zwischen bestimmten tags in dem dxl und zwar als base-64 encoding der binären Daten.
Für Generierung von DXL und erstelle_Notes-Element_aus_DXL existieren Klassen und Methoden und ich schau jetzt nicht extra nach (vielleicht später).
Jedenfalls brauchst du nicht das xml Toolkit, weil das nur für 5 war.
 
Allerdings ist die menschenlesbarkeit von xml sehr anstrengend. Wir setzen deshalb zusätzlich zur Ansicht (und zur Archivierung von zahlreichen Dateitypen wie MS-Word, MS-Excel, Visio, noch einiges mehr) PDF-Generierung ein.

Darüber hinaus haben wir noch einige für Archivierung vermutlich generell interessante Zusatzfeatures dabeigebaut:
Wir speichern ausserdem die Attachments und eingebetteten Objekte noch einmal separat und konvertieren viele Dateitypen in PDF und jagen die vorher durch einen Volltextsuche-Indexierer.
 
Bestimmte Felder des Notes Dokuments werden auch durch den Indexierer gejagt (für Schlagwortsuche).
Vom Notes Dokument wird auch ein PDF Abbild gezogen.

Eine Suche geht also über vordefinierte Schlagwörter und über Volltext. Dafür gibt es eine Notesmaske, die Webservices, einen IE als OLE-Objekt, etc. benutzt. Ja, es läuft stabil.

Die Kommunikation zwischen den Notes Datenbank und den Archivierungsservices läuft über Webservices.
Die Archivierungsservices selbst laufen auf Tomcat, benutzen viele Java openSource Geschichten (Volltextsuche, XML-Datenbank, Webservices, Webframework, Scheduling von Prozessen) und 2 nicht unbedingt triviale Anwendungen von uns selber. 

Der Nachteil von DXL (und unserer Lösung allgemein) sind,
- dass man ziemlich viel Speicherplatz benötigt (DXL allgemein, viel Information redundant als dxl und PDF). Speicherplatz wird aber immer billiger und ist schon ziemlich billig.
- Webservices sind auch nicht gerade ein Performancekiller auch wenn man den übertragenen Stream zippt. Für viele Archivierungsaufgaben benötigt man aber keine Killer-Performance.
Der Bedarf des Kunden für Archivierung liegt vornehmlich in einer größeren Übersichtlichkeit der Anwendung für die User und nicht im Sparen von Speicherplatz

Die Vorteile von dieser Lösung sind,
- dass für den Anwender eine Wiederherstellung aus dem Archiv leicht möglich ist und es eine sehr komfortable Archivsuche gibt mit PDF als Vorschau.
- sehr lose Bindung zwischen Notes DB und Archivierungsservice und der Komponenten untereinander bietet eine flexible Architektur, wo auf Änderungen der Archivierungspolitik der Organisation gut reagiert werden kann (s.u.). Bestimmte Funktionalität kann auch isoliert von den anderen benutzt werden (z.B. serverseitige PDF Generierung)

Es läuft soweit sehr stabil. Wir versuchen jetzt noch die Skallierungs-Constraints-Grenzen nach aussen zu verschieben.  Bei sehr, sehr vielen DXL-Konvertier Operationen hintereinander, existiert möglicherweise ein Memory Leak auf Notes Seite. Das lässt sich aber managen und beruht - wenn ich das Mittwoch in meinem urlaubsreifen Kopf richtig verstanden habe - auf einem offiziellen Notes-Bug.

Aus Sicht der Anwendung extrem große Attachments (größer als 300 MB) sind bisher auch noch nicht getestet.

Wg. der langfristigen Archivierungs-Politik des Kunden sollen nun die Archivdokumente nicht mehr in einer xml DB abgelegt werden, sondern in IBM Storage Server (oder wie das heisst). Dadurch dass Client-Seite und Server Seite der Archivierung nur durch standardisierte Webservices gekoppelt sind, lässt sich dies relativ leicht nachträglich erweitern.

Gruß Axel

Marinero Atlántico:
bzgl. rtf. Schamloses Selbstzitat aus einem anderen Kontext:

--- Zitat von: Marinero Atlántico am 21.09.04 - 15:10:22 ---Notes-RichText benutzt kein unicode-encoding. Vielmehr ist es etwas anderes, wenn ich mich recht erinnere sogar proprietäres.
Hier gibt es ein paar Einträge von der anderen Richtung. Notes --> RTF.
http://www.nsftools.com/tips/NotesTips.htm

--- Ende Zitat ---
In dem Blog einfach nach rtf suchen.

TMC:
Klingt sehr interessant, Axel, Eure Lösung.


--- Zitat von: Marinero Atlántico am 26.09.04 - 09:38:34 ---Allerdings ist die menschenlesbarkeit von xml sehr anstrengend.
(...)
Der Nachteil von DXL (und unserer Lösung allgemein) sind,
- dass man ziemlich viel Speicherplatz benötigt (DXL allgemein, viel Information redundant als dxl und PDF).
--- Ende Zitat ---

Aus Interesse:
Warum speichert Ihr DXL-content zusätzlich als PDF?
Wäre es da nicht einfacher, den Inhalt über einen Viewer anzuzeigen?

Marinero Atlántico:
Es gibt keinen dxl viewer und kann es wg der Heterogenität der Daten auch nicht geben.
Das ist auch eine Dokumentverwaltungsanwendung.
D.h. das Wichtige sind die eingebetteten bzw. angehängten Dokumente (MS-Word und sowas).
Die werden in dxl einfach base 64 enkodiert.
Damit kann wirklich keiner was anfangen.
Ein normales Word-Dokument sieht ungefähr so aus:

--- Code: ---ab0k13l4898

--- Ende Code ---

etc.
Das überfordert einfach den Betrachter.
Man kann dafür auch nicht mal eben so einen Viewer schreiben. 

Gilt btw. für xml allgemein, dass die Menschenlesbarkeit von xml tendentiell überschätzt wird, nur weil es ein Text Format ist, ist es noch lange nicht lesbar.

PDF ist eigentlich für Archivierung konkret sowieso das bessere Format als dxl, weil es so erstmal nicht beschreibbar ist.
Es gibt in den IT-Organisationen gewaltige und z.T. total veraltete "Richtlinien zur Archivierung", wo nicht-Beschreibbarkeit ein extrem wichtiges Thema ist. Schliesslich läuft Archivierung oft auf der Basis von komplexen Rechtlichen Bestimmungen statt (Vorhaltefristen, etc.).

Genaugenommen ist PDF ein bei vielen Kunden akzeptiertes Archivierungsformat. Auf der anderen Seite gibt es ja Tools zur PDF Manipulation. Zumindest kann man das bestimmt irgendwie gegen Editieren sichern, falls das nötig wird. Das sind aber genau die Fragen, die durch die umfangreichen Archivierungsbestimmungen nicht geklärt werden. Da wird dann gerne so getan als wäre .pdf sowas wie .tif.

Das DXL dient mehr für Transport und wird ausserdem für die Wiederherstellung vorgehalten.

Wiederherstellung und klassische Archivierung sind eigentlich 2 unterschiedliche Themen.
Traditionell hiess wohl Archivierung v.a. Vertiffung. Da ist eine Wiederherstellung ja quasi undenkbar.

Axel:
Hi,

danke für die Hinweise, Namenskollege.  ;) ;D


Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete