Agent der XML erstellt.

[CLI_Andreas_Schmidt]

Hi an alle,

dieser Lotus Script Agent erstellt XML Dokumente aus einer Notes Ansicht.

Gruesse

Andreas Schmidt

http://www.lotus-schmidt.de

Sub Initialize
     Dim session As New NotesSession
     Dim db As NotesDatabase
     Dim  view As NotesView
     Dim doc As NotesDocument
     Dim marke As Variant
     
     Set db = session.CurrentDatabase
     Set v = db.GetView("AKP")
     Set doc = v.getfirstdocument
     
     
     
 REM Open xml file named after current database
     Dim stream As NotesStream
     Set stream = session.CreateStream
     filename$ = "c:\jadxl\" & Left(db.FileName, Len(db.FileName) - 3) & "xml"
     If Not stream.Open(filename$) Then
           Messagebox "Cannot open " & filename$,, "Error"
           Exit Sub
     End If
     Call stream.Truncate
     
 REM Export current database as DXL
     Dim exporter As NotesDXLExporter      
     Set exporter = session.CreateDXLExporter
     Call exporter.SetInput(doc)
     Call exporter.SetOutput(stream)
     Call exporter.Process
     
End Sub

[Meff]

Hi Andreas,

wäre nicht schlecht, wenn Du zu diesem Agent ein kleines Anwendungsbeispiel hinzufügen könntest. Mit XML kann man viele schöne Dinge treiben aber oft fehlt einem der Ansatz dazu.

Meff

[CLI_Andreas_Schmidt]

Ich arbeite zur Zeit an einem Parser der mir anhand einer DTD, die Inhalte prüft und in Java einlesen kann um sie dann im Web zur Verfügung zu stellen.

Wenn ich da was habe, dann stelle ich es in Forum.

Gruss

Andreas Schmidt

[Don Pasquale]

Hallo Andreas,

irgendwie schreit dieser Code nach einer Fortsetzung
bzw. einer Vollendung mit einer While .. Wend Schleife.
Als Namen finde ich die UniversalID schöner.


   Dim session As New NotesSession
   Dim db As NotesDatabase
   Dim ndoc As NotesDocument
   Dim nView As NotesView
   Dim stream As NotesStream   
   Dim exporter As NotesDXLExporter
   
   Dim sname As String
   Dim cpath As String
   
   cpath = "d:\data\xml\"   
    ' PARAMETRISIERBAR MACHEN
   
   '---------------------------------------------------------------------
   
   Set session = New NotesSession
   Set db = session.CurrentDatabase
   
   Set nView = db.GetView ( "($ALL)" )
   
   
   Set nDoc = nView.GetFirstDocument
   
   '---------------------------------------------------------------------
   
   While Not nDoc Is Nothing
      
      Set stream = session.CreateStream
      
      sName = cPath & nDoc.UniversalID & ".xml"   
      
      
      If Not stream.Open( sName ) Then
         Messagebox "Cannot open " & sName,, "Error"
         Exit Sub
      End If
      
      Call stream.Truncate
      
      Set exporter = session.CreateDXLExporter ( nDoc, stream )
      Call exporter.process ()'
      
      
      Set nDoc = nView.GetNextDocument ( nDoc )
      Set stream = Nothing      
      
   Wend
   
   

[Axel_Janssen]

(werde jetzt ein bischen out_of_topic, bzw. ich erweitere das topic und damit ist es auch eigentlich nicht mehr Tipps und Tricks Forum. Find das aber persönlich nicht so schlimm, gerade in eher turbulenten Zeiten wie diesen.

werds Morgen mal ausprobieren. Was macht man dann mit dem xml file?    
Jetzt nicht böse gemeint, aber wo ist der konkrete Nutzen für den Kunden? Das ist ein konkretes Problem von mir: Ein Kunde hat Budget für "Neue Technologie" nicht aber für Domino. Vielleicht ließe sich dieser konkrete Business case viel besser und einfacher mit Domino Mitteln lösen. Aber das Budget ist eben gebunden an "Neue Technologie".

Domino Dokumente und XML-Dokumente sind eigentlich ziemlich ähnlich. Es sind Datenstrukturen, die prinzipiell einen hohen Grad an Flexibilität hinsichtlich der Struktur der enthaltenen Daten-(Felder) erlauben.
Bei XML ist das abhängig von  der dtd, dem xml-schema. Beides kann man mit mehr oder eben auch weniger Beschränkungen definieren.

Domino und XML benötigen eine Art Client zur Anzeige. Da ist man bei xml flexibler aber aufwendiger zu erstellen. GUI, die das xml liest, darstellt, da-reinschreibt, xslt/xsl-fo, das weiß wie es aus dem xml so etwas wie HTML oder PDF (Beispiel) erzeugt.  
Ich halte die Behauptung xml Dokumente wären menschenlesbar schon länger für 83.7% Propaganda. Stimmt vielleicht für triviale Beispiele. Reale xml Dokumente sehen aber mehr wie ein dxl-File aus und das ist nicht sonderlich lesbar.

Das ist vielleicht die Tragik von Domino und "der Öffnung gegenüber den Standards". Wir hatten und haben eine fertige RAD-Plattform, die beschränkt aber effizient ist.
Wir haben diese ganzen tollen Standards, aber was machen wir damit? Ralf hat mich genau da von der von mir vorher von mir vernachlässigten Swing-Technologie überzeugt, weil da war plötzlich ein konkreter Anwendungsnutzen (s. UI GroupCal).
Genau das ist kompliziert.

Das geht vom Anwendungsnutzen aus:
http://www-106.ibm.com/developerworks/library/x-wxxm19.html?ca=dnt-436
Gipfelt dann in Sätzen wie

To convert these files in XML, you can use XML Import (XI), a project I developed previously in this column. As you might remember, XI uses regular expressions to parse text documents and import them to XML.

Aber das gipfelt so oft in solchen Sätzen... Google ist dein Kumpel.

Gruß Axel  

[Don Pasquale]

Hi Axel,

für mich ist das klar, der Kunde will das so, weil er von
Gesetz wegen verpflichtet ist, seine Korrespondenz
SO aufzubewahren, dass man sie 10 Jahre später
noch lesen kann.
Und ich vermute mal, in 10 Jahren wird es kein Problem sein
einen XML-fähigen Browser aufzutreiben.
Ob es Lotus da noch gibt, ob die dann aktuelle Version
abwärtskompatibel sein wird, oder Du noch eine
Alte Version auftreibst, bzw. diese noch installierst.

Von den vorteilen von xml als schnittstelle in einer heterogenen Umwelt will ich nicht reden, davon habe ich zuwenig erfahrung.
Aber ich vermute dass es so ist.
Ciao
Don Pasquale

[Axel Janssen temp]

Mit der Archivierung, in 10 Jahren noch lesbar:
Genau so argumentiert mein Chef auch.
Hab ich erst nicht so gesehen, ist aber ein gutes Argument.

Das mit der heterogenen Umwelt stimmt auch. Nur bin ich darauf momentan nicht so gut zu sprechen, weil ich momentan ziemlich darin versage MS-SOAP und Java.Axis-SOAP dazu zu bringen, sich gegenseitig zu verstehen.

Gruß Axel

[Don Pasquale]

Scherz :
Ich finde: "der Kunde will es so" ist auch ein gutes Argument.
 

Ciao
Don Pasquale

[MartinG]

...Archivierung ist derzeit mein Lieblingsthema, bzw. muss mich leider damit auseinandersetzen..


...einen XML fähigen Browser gibt es sicherlich in 10Jahren noch, die grosse Frage ist ob dieser XML sinnvoll darstellen kann.

Ich persönlich halte die ganzen Diskussionen über Dinge wie was für Dateiformate in 10Jahren noch lesbar sind für etwas übertrieben (zumindest für viele Bereiche).

Ich kann mir beim besten Willen nicht vorstellen das die heutigen Standardformate wie PDF, TIF - aber auch DOC,XLS etc in der Zukunft nicht mehr gelesen werden können. Klar kann es Probleme geben - aber die sind in der Vergangenheit immer kosmetischer Natur gewesen und m.W. fehlte es nie irgendwo inhaltlicher Art. Da bin ich einfach der Meinung das die Basis der Dokumente von heute so unglaublich gross ist das ich mir nicht vorstellen das das Lesen in 10Jahren ein Problem sein soll.

Anders sieht es natürlich aus wenn mehr als 10J.  Archivierungszeit gefordert wird z.B. im Sinne von Produkthaftung etc. Aber hier stellt sich die Frage ob man da überhaupt auf Softwareprodukte setzen soll.

Hier kommt halt nicht nur die Formatfrage in Spiel sondern auch die Medienwahl und Haltbarkeit etc und hier ist die grosse Frage ob es nicht sinnvoller ist auf ganz andere Weg zu setzen. Ich hatte letzte Woche einen Vertreter von Microbox im Haus www.microbox.de die setzen im Prinzip auf eine Art Mikrofilm (nur halt entsprechend moderner). Die Präsentation dazu war ziemlich überzeugend, bin mal gespannt was bei uns daraus wird...

[Axel Janssen temp]

Der Vorteil von xml gegenüber tif ist, daß es Volltextmässig durchsuchbar ist und das auf die Daten zugegriffen werden kann. Tif kann man sich ja nur angucken.

Der Vorteil von xml gegenüber doc, xls, nsf, pdf ist, daß man ein sich selbst beschreibendes Datenformat hat. Jede halbwegs moderne Programmiersprache implementiert heute xml Parser, xslt-engines, etc.

Man kann dann also auf den Archivdatenbestand von einer beliebigen Plattform zugreifen, ohne sich um Schnittstellen mit com, Domino Object Model oder pdf-APIs zu kümmern.

Mit xindice existiert eine hoffentlich gute und auf größere Datenbestände skallierbare   xml-Datenbank, was auch Vorteile dagegen bringt, Daten einfach im Filesystem abzulegen.

Korrigiert mich, wenn ich falsch liege.

Manche Leute übertreiben es mit dem xml. Für viele Bereiche ist es aber durchaus sinnvoll. Gerade in Verbindung mit darauf aufbauenden Zusatz-Zeuch wie SOAP.


Gruß Axel
 

[Don Pasquale]

@MartinG.

In diesem Fall war der Vergleich nicht tif und XML sondern Lotus Dokument und XML. Ich finde die Sachlage ist dann nicht mehr so eindeutig.

MIKROFILM ? Und wie lässt sich dann ein einzelnes Dokument
von einem Client aus recherchieren ?

Ciao
Don Pasquale

[MartinG]

...mit Deinen Argumenten hast Du sicherlich recht - ich bin hauptsächlich nur Admin und auch nicht so tief in der Materie drin weshalb ich von Deinem Thread auch nur die Hälfte verstehe (was ist eine xslt - engine?)

Ich kann mich nur so dunkel an eine Diskussion über OpenOffice und XML erinnern wo dann XML trotz offenem Dateiformat nicht so ohne weiteres lesbar war. Laut Marketing was ich immer wieder höre ist doch XML wunderbar im Notepad lesbar...

[Axel Janssen temp]

@MartinG.

In diesem Fall war der Vergleich nicht tif und XML sondern Lotus Dokument und XML. Ich finde die Sachlage ist dann nicht mehr so eindeutig.

MIKROFILM ? Und wie lässt sich dann ein einzelnes Dokument
von einem Client aus recherchieren ?

Ich fand das einen interessanten Punkt. Vielleicht als second level archive.

[MartinG]

...die Jungs von Microbox haben dafür eine intersante Lösung. Das ganze hier zu beschreiben würde allerdings ein wenig zu weit führen.

Die Technik ganz stark vereinfacht beruht darauf das man die Dokumente auf einem netzwerkfähigen Microfilmdrucker ausdruckt und dabei noch entsprechend indiziert damit man Sie hinterher wieder auffinden kann. Hinterher gibt es wieder entsprechende Texten zur Redigitalisierung im Fall das die Daten wieder gebraucht werden.

Klar ist bei einer solchen Archivierung hinterher keine Volltextsuche möglich, die Frage ist halt ob das auch zwingend notwendig ist. Wenn ich halt sehe was unser Archivierungssystem wo wir Lieferscheine, Auftragsbestätigungen per Cold und manueller Archivierung erfassen kostet ist es schon die grosse Frage ob es da nicht sinnvoller ist für Langzeitarchivierung auf so ein Prdukt zu gehen.

[Axel Janssen temp]

was ist eine xslt - engine?

führt jetzt zu weit, das zu erklären

Laut Marketing was ich immer wieder höre ist doch XML wunderbar im Notepad lesbar...

Stand der Diskussion ist, daß xml (über die APIs/Parser) wesentlich besser Maschinen- als Menschenlesbar ist.

Jede neue Technologie ist verknüpft mit einer Menge simplifizierenden Marketing.
Ich reg mich darüber noch nicht mal auf und wenn irgendein Naseweis sagt: Aber ich habe doch gelesen das mit [xml | Webservices | MS.NET | whatever] bleibe ich ganz sachlich.

Bin z.B. damit beschäftigt, einen Java Webservice mit MS-VisualBasic6 zu konsumieren. Ich hab gar nicht damit gerechnet, daß es einfach ist und natürlich gibt es da bei MS irgendwelche komischen Zusatz-Files, die alles ein bischen komplizierter machen.

Gruß Axel

 

[Don Pasquale]

Wo liegt denn so etwas preislich ?
Ist das eine Alternativ zur Jukebox ?

Ciao
Don Pasquale

[MartinG]

...die Rolle wo archiviert wird kostet so um die 40EUR und darauf passen:

A0   =  600 Seiten
A1   =  1200 Seiten
A2   =   2400 Seiten
A3    =  4800 Seiten
A4    =  9600 Seiten

Dazu kommen noch die Kosten für das Gerät - oder wohin bei uns vermutlich eher der Trend geht das wir dieses als Dienstleistung machen lassen. Dann kostet das ganze pro Band zwischen 250 und 360EUR (je nach Anzahl der Beauftragung). Die Daten müssen dann entweder im TIFF Format, PDF, HPGL oder nochmals ein paar Spezialformate die mir allerdings nichts sagen (wie z.B. RLC, CalComp etc...) auf DVD o.ä. angeliefert werden...