Archive for the ‘FileDirector’Category

FileDirector WorldWide – Das Netzwerk

… Anbei ein kleines Video von Hans- Volker Mann, der erst kürzlich unseren US-Distributor – Active Data Systems – besucht hatte und sich beim Rückweg fleißig verflog ;-) – Gottseidank wieder im Office:

ZD YouTube FLV Player


Active Data Systems: http://www.activedatasystems.com/
FileDirector WorldWide: http://www.filedirectorworldwide.com/

Spielberg & joe auf der DMS 2009

Spielberg ist da – Auch für Dich. Wenn Du magst, kannst Du uns besuchen kommen.

email_dms

Deine Einladungskarte bekommst Du kostenlos, wenn Du Dich vorab registrierst: Link. Viel Spaß auf der DMS – vielleicht sehen wir uns ja?

17

08 2009

IBM Client Access Integration

Der Codeless Connector von Spielberg erfährt im Rahmen eines Updates ein kleines Feature, was die AS400- Kunden sicherlich begeistern wird. Es mag schon fast wie Zauberei klingen, aber der CodeLess Connector schafft, was nur wenige können. Er integriert vollständig in das E-Series Client Access und kann

1. Den gesamten Inhalt der Terminalemulation sehen
2. Indexmerkmale & Treffer an FileDirector WinClient übergeben

AS400

Das ganze konfiguriert mann mit 1-2 Mausklicks…

16

08 2009

“Ein Bild serialisieren”

Christoph Schwarz und Jan Frost haben mich beide sozusagen “geplättet”. Ich bin völlig baff.

Die haben den FileDirector 2.1 (der bald zu haben ist) soweit, dass er automatisch Post/Briefe/Papier klassifizieren (unterteilen in Lieferscheine, Rechnungen, Frachtbriefe, Gutschriften usw.) und dann automatisch auslesen kann. Wohl gemerkt, wir sprechen nicht über Formularerkennung sondern über intelligente Lesung!

Das ganze funktioniert in etwa so, dass z.B. ein unbekannter Lieferant beim ersten Scannen/ Anlernen z.B. einer Rechnung trainiert wird (Adresse/ Kopfdaten/ Aufbau und Länge von Rechnungsnummer, etc.) und beim zweiten Rechnungsscan des gleichen Lieferanten automatisch ausgelesen werden kann. Hierbei wird z.B. die Mehrwertsteuer gegen die Rechnungssumme total gerechnet. Die Kopfdaten und die serialisierten Informationen (Beträge, usw.) können nach dem Scanvorgang z.B. an ein Finanzsystem übergeben werden. Der Client meldet sich nur dann wieder, wenn er sich unsicher ist, z.B. Beträge oder Rechnungsnummern falsch oder unsicher gelesen worden sind. Hier kann der Anwender in einer Nacherfassungsmaske überprüfen und korrigierend eingreifen.

Das ganze (Klassifizierung und Serialisierung) läuft serverseitig ab, der Anwender bekommt nur einen Button für die Nacherfassung/ Überprüfung. Clientseitig muss kein Zusatzprogramm installiert werden, das ganze System ist 100% in FileDirector integriert.

Das ganze ist soger Batch/ Massentauglich, es können gleich mehrere Anwender in die Nacherfassungsmaske begeben und so können tausende von Nacherfassungen auf mehrere Anwender verteilt werden, um den Durchfluss zu erhöhen, hier zielt das System auch auf die absolute Massenverarbeitung, selbst wenn die automatische Verarbeitung schon relativ genau ist.

Das ganze funktioniert nicht nur unter Laborbedingungen sondern auch in der “Wildnis” sehr gut, so dass es in der 2.1 zu kaufen ist. Der Preis von Spielberg für dieses System ist übrigens eine absolute Kampfansage.

Ich bin stolz wie Oskar und präsentiere Euch das System gerne, es ist so einfach, dass selbst ich es begreife…

14

01 2009

Clustering & High Performance Computing

Hello,

thank you for paying attention to this year’s FileDirector Workshop held at CAENS, where we had a focus on “Load Balancing”/ “High Performance Clustering”/ “Replication” in combination with FileDirector. For me it was a great experience to have a chat with you all!

Please find below some useful links regarding our workshop:

CLUSTERING

iSCSI target device driver:
http://www.rocketdivision.com/wind.html
http://www.stringbeansoftware.com/products.asp

Windows Server 2003 iSCSI initiator:
http://www.microsoft.com/downloads/details.aspx?familyid=12cb3c1a-15d6-4585-b385-befd1319f825&displaylang=en

Clustering Setup Guideline for VMware & WS2K3:
http://www.blkmtn.org/files/VMware%20clustering%201.0.pdf
(unsupported/ better use iSCSI!)

What is the QUORUM used for?
http://207.46.196.114/WindowsServer/en/library/a88fd196-fa56-420b-bfb9-51de37bbcf941033.mspx?mfr=true

Metabase Synchronization in WS2003:
http://www.webservertalk.com/showthread.php?threadid=252322&perpage=1&pagenumber=13

28

06 2008

FileDirector 2.0 “Raves”

..Ein wenig aus der Plaudertasche. FileDirector 2.0 wird mit den bisher erwarteten Features kommen, allerdings gibt’s (derzeitiger Stand der Entwicklung) noch eins oben drauf.

1. FileDirector 2.0 ist startbar aus dem Internet Explorer
2. FileDirector 2.0 bietet eigene www- Engine basierend auf IIS (IIS weiterhin nutzbar)
3. FileDirector 2.0 bietet eigene Datenbank (SQL+Oracle weiterhin nutzbar)

Gerade Punkt 3 ist für viele preislich interessant. Die eigene Datenbank kann aus dem Enterprise Manager gesteuert werden (Backup/ etc) und ist eine echte preisliche Alternative zu Microsoft SQL Server (Middleware Prinzip beachten).

Punkt 2 (WWW- Engine) ist für mich sträflich/ töricht diese zu nutzen, da für mich nichts über einen gut gepflegten und konfigurierten IIS geht. Offenbar sah man sich bei Spielberg dazu genötigt, da immer noch viele mit der Konfiguration von IIS5/6/7 kämpfen…. Na Ja. Sofern der IIS weiterhin nutzbar ist, lasse ich das mal aussen vor…

Das war’s soweit. Juhuuu!
Gruß von Captain Blaubär!

28

01 2008

SSL: was bedeutet das eigentlich, was bringt uns das für FileDirector?

;-) Also schön. Ich versuche mal mit Händen und Füßen zu erklären… SSL bedeutet „Secure Socket Layer“, auch TLS oder “Transport Layer Security”. Schon ziemlich viel Sicherheit in den paar Abkürzungen, oder?

Vorsicht! Hier geht es einmal nicht um die digitale Signatur von Dokumenten (das können wir auch), sondern es geht um sichere Kommunikation. Mit SSL kann man schon mal eine Menge machen. Es hilft ungemein. Ich werde mal versuchen, die Thematik mit einfachen Mitteln ein wenig näher zu bringen.
Manchen Administratoren ist SSL auch ein Dorn im Auge, denn SSL ermöglicht den Anwendern nahezu unprotokolliert aus dem Firmennetz hinauszukommen, um zB. Banküberweisungen zu machen, oder auch sonstigen Unfug.
Die Anwender wissen also, dass die Verbindung von A nach B verschlüsselt ist und bekommen das auch angezeigt. Meist durch das „Schloss- Symbol“ in der Fußzeile oder in und neben der Adressleiste im Internetexplorer. Ohne zu tief in die Details eingehen zu müssen, wissen wir also dass beim „surfen mit dem Schloss“ uns erstmal keiner über die Schulter gucken kann (es sei denn unsere Kiste ist verseucht, aber das schließe ich mal aus…).

SSL hat noch mehr Vorteile, doch immer der Reihe nach.
Zunächst erstmal müssen wir es schaffen, dass der Client (Surfer/ Anwendungsbenutzer) dem Server (Webseitenanbieter/ Anwendungsanbieter) vertraut. Das geht mit Hilfe eines Zertifikates. Wie heißt es so schön? „Garantiert die Identität eines Remotecomputers“. Ein Zertifikat kann man also nicht nur für die Signatur eines Dokumentes verwenden, sondern um sich als garantiert echter Webserver auszuweisen. Ich pappe dem Webserver also eine Briefmarke oben „drauf“. Allerdings kann ich nicht irgendeine Briefmarke draufpappen, es sollte schon so eine sein, welcher die Anwender auch vertrauen (Vertrauensstellung…) können. Üblicherweise kann ich mich an einen Diensteanbieter (Stammzertifizierungsstelle) wenden. Davon gibt es eine Menge: Geotrust, Verisign, etrust …; das ist in etwa so wie mit dem Straßenverkehrsamt und dem Autokennzeichen. Das kostet zunächst mal Geld. Um so ein Kennzeichen zu bekommen muss man sich ja auch ausweisen (Personalausweis, Handelsregisterauszug…). Aber: Alle Polizisten vertrauen Flensburg und so kommt es, dass wir eine zentrale Stammzertifizierungsstelle haben. Mit so einem Verkehrszeichen darf ich dann also rumfahren und werde ich geblitzt, dann vertraut mir auch der doofe Fotoapparat in sofern, als dass er weis dass ich sozusagen „ich“ bin und nicht jemand anders. So funktioniert das auch mit den Webseiten und den Zertifikaten.

Trustcenter, “Pfade”…
Aber, man kann das Spiel noch ein wenig weiter spielen. Wenn Sie in Ihrem Internetexplorer einmal auf „Zertifikat anzeigen klicken“ und dann auf Zertifizierungspfad, stellen Sie doch einen längeren Weg der Vertrauensstellung fest. Man kann das in etwa mit den regionalen Straßenverkehrsämtern vergleichen. Im Auftrag des Kraftfahrtbundesamtes stellen die nämlich die Kennzeichen aus. Also vertraut das Kraftfahrtbundesamt dem Straßenverkehrsamt Duisburg, dieses wiederum mir und so bekomme ich mein Kennzeichen für mein Auto. Bei digitalen Zertifikaten geht das noch ein Stück weiter, denn fast jedes große Unternehmen besitzt selbst ein sogenanntes Trustcenter welches wiederrum Zertifikate ausgibt (Zertifikate können unterschiedliche Zwecke haben, im Moment sprechen wir über die Identität eines Remotecomputers).
Es ist in etwa so wie wenn Helmut Meier Familie Müller vertraut, dann tut es Sohnemann Meier ebenso, oder Papa sagt – Mercedes ist cool, dann findet Sohnemann das auch. Ein richtiger Pfad also.

toofast

… so sieht das aus, wenn eine Vertrauensstellung im Straßenverkehr funktioniert:

Da bei unserer internen Verkehrsbehörde (Rosi) bescheid gewusst wird, dass ich das war, darf ich die zwanzig Euro wohl denn auch blechen… Trotzdem erinnere ich mich sehr gerne an dieses Foto.

…Fälschen von Kennzeichen möglich?
Aber ein KFZ- Kennzeichen kann ich ja fälschen, wie kann ich da sicher sein, dass ein SSL- Zertifikat echt ist? Niemals! Wir müssen vertrauen. Windows vertraut per default mehreren Trustcentern. Rauskriegen, wem Ihr vertraut könnt Ihr, wenn Ihr in der Kommandozeile „certmgr.msc“ eingebt und Euch in die „vertrauenswürdigen Stammzertifizierungsstellen“ bewegt. Das sind sozusagen die Kraftfahrtbundesämter, denen Windows vertraut.
Missbrauch möglich? Ja klar! Allerdings schützen wir uns in der deutschen Gesetzgebung in etwa so: „fälsche ich ein Autokennzeichen, so begehe ich eine Urkundenfälschung“. Oder so ähnlich. Da mir das aber im Internet nix bringt, da wir bei einer Verfolgung von Straftätern meist leer ausgehen, müssen wir schon technische Algorithmen mit einbauen. Es ist in etwa so wie mit einem Fingerabdruck, den wir da mit einbauen. Dieser muss dann aber auch zum „Remotecomputer“ also der Webseite passen. Wichtig ist also hier der „FQDN“ („fully qualified domain name“) also www.dasistmeinewebsite.de, das darf nicht abweichen! Ist hier ein Fehler in der URL, dann sagt mir mein Browser oder meine Applikation, dass da was nicht stimmt, oder derjenige der da sagt er sei jemand ist überhaupt nicht dieser jemand. Dann verweigert der Browser (die Applikation) typischerweise erstmal die Fortführung der Applikation und meldet dieses. Gleichso ist es mit dem Datum und der Uhrzeit (siehe Ablaufdatum eines Zertifikats). Übrigens: Weicht die Uhrzeit vom Server mehr als 5 Minuten von der des Clients ab, so gibt es ebenfalls eine Fehlermeldung. Dann gibt es noch Sperrlisten, sollte also ein Trustcenter mitteilen, das ein darunterliegendes Trustcenter oder ein Remotecomputer nicht mehr vertrauenswürdig ist (im Sinne von „hat gekündigt“ oder „bezahlt nicht“ oder „wurde gehackt“) dann ist es ebenfalls vorbei mit der Vertrauensstellung. Dennoch, traue ich auch dem Trustcenter von www.dasLstmeinewebsLte.de, kann mich das System nicht vor evtl. Phishing Atacken schützen.

Also geht es erst einmal nicht um die „Verschlüsselung“, sondern um die Identität! Und das gibt mir den Vorteil, dass jemand anders nicht sagen kann, er wäre John Lose. Da fällt mir gerade ein, dass mein Personalausweis abgelaufen ist, ach du liebe Güte!

Verschlüsselung
Dann, sofern wir wissen dass jemand wirklich jemand ist, dann geben wir auch unseren Benutzernamen und unser Kennwort preis. Hier haben wir den großen Vorteil, dass mir keiner meine EC Karte aus dem Portemonnaie mopsen kann. Jetzt wo wir beide schon auf einem sicheren Kanal funken, werden wir uns über einen gültigen Schlüssel unterhalten, der unser Gespräch verschlüsselt. (Phase 1 und Phase 4 der Verschlüsselung; Phase 2 und 3 werden verwendet, sofern der Server auch vom Anwender einen „Personalausweis sehen will).

Schutz vor dem Lauschangriff
Dann kann mir zunächst mal keiner die Sitzung „mopsen“ oder unerlaubt zuhören („session hijacking“/ „man in the middle“) zumindest wird es relativ schwer. Ich habe ebenso den Vorteil, dass mein Gespräch nicht verändert wird von Leuten die sonst immer meinen was anderes sagen zu müssen oder irgendwelche Gerüchte verbreiten, wie zB. Proxies und so’n Gestrüpp. Die wissen zwar, dass wir miteinander sprechen aber zuhören wird relativ schwierig, den Inhalt sehen sie also nicht.

Was bringt mir das im DMS?
Da FileDirector auch http spricht, kann er dieselbe Verschlüsselung und die gleichen Authentifizierungsmechanismen verwenden. Es kann also niemand anders vorgeben, mein FileDirector Server zu sein. Ebenso kann mir niemand zuhören oder die Daten verändern, sofern sie von A nach B transportiert werden. Ich habe kein Problem mit Proxys oder Anwendungsfiltern, die mich nerven könnten oder irgendwelchen Spielkindern, die wissen wollen was Onkel Joe mit seinem Server spricht. Das geht nämlich nur uns zwei was an.

SSL ist also eine ziemlich coole Sache, sofern man sie mal verstanden hat.

Tipps:
Übrigens, man kann es auch ein wenig „kostengünstiger“ haben, mit einer eigenen „Stammzertifizierungsstelle“, reicht vollkommen aus. Oder ganz billig: mal eben mit dem selfssl script (iisreskit); doch Vorsicht beim selfssl script: Hier ist der Server seine eigene Stammzertifizierungsstelle.
Wenn Ihr wissen wollt, wie TLS oder SSL wirklich funktioniert, so schlagt doch einfach mal auf wikipedia nach!

Links:
Windows PKI: http://technet.microsoft.com/en-us/library/bb735132.aspx
Trustcenter bei Tecchannel: http://www.tecchannel.de/sicherheit/grundlagen/402017/index10.html
SSL/ TLS bei Wikipedia: http://de.wikipedia.org/wiki/Transport_Layer_Security
Selfssl/ ISS RESKIT: http://www.msxfaq.de/tools/selfssl.htm

22

10 2007