Ob Sie nun ein WaWi (Warenwirtschaftssystem) entwickeln, eine Inventurdatenbank oder eine Zugangskontrolle – fast immer treffen Sie auf Barcodes, die zur Identifikation eines Objekts dienen. Das Erstellen solcher Barcodes ist die einfachere, das Lesen die schwierigere Sache. Wir zeigen, wie Sie sich die Entwicklung mithilfe von OPOS – nicht Opus! – erleichtern können.
Es ist eigentlich nicht besonders schwierig, Barcodes mit einem handelsüblichen Barcode-Scanner in eine Anwendung einzulesen. In vielen Fällen sind das Geräte, die in die Tastaturschnittstelle eingeschleift werden. Ein Scan erzeugt dann genau so Zeichen, als seien diese über die Tastatur eingegeben worden.
Der Scanner ist damit universell einsetzbar und Barcodes können in Notepad, Excel, Word oder eben auch in eine Textbox eines Access-Formulars eingelesen werden.
Früher gab es am Kabelanschluss des Barcode-Scanners einen Adapter, an den man den PS2-Stecker der Tastatur andockte. Heute, da fast jedes externe Gerät über eine USB-Schnittstelle verfügt, findet man diese Technik eher selten und auch Barcode-Scanner sind meist mit USB-Steckern ausgerüstet oder zumindest mit einer seriellen RS232-Schnittstelle.
Die Umsetzung dieser seriellen Signale in Tastaturanschläge übernimmt dann ein Treiber des Herstellers, der auf dem System installiert wird und häufig mit einer zusätzlichen Anwendung namens Softwedge daherkommt.
Umständlichkeiten
Gehen wir von einer Anforderung aus, wie sie an jedes Kassensystem gestellt wird: Für eine Reihe von Artikeln auf dem Laufband ist der Preis aus einer Datenbank zu ermitteln.
Die Artikel sind bereits in einer Artikeltabelle gespeichert, die neben eindeutiger IDs für die Datensätze zusätzlich jeweils EAN-Nummern enthält. Der Barcode jedes Artikels wird nun eingescannt, die EAN-Nummer gelesen und über eine Abfrage auf die Artikeltabelle und der EAN-Nummer als Kriterium der Preis ermittelt.
Rein datenbanktechnisch ist das eine leichte Aufgabe, wenn man einmal davon absieht, dass der Vorgang sehr zügig erfolgen muss, was eine ausreichend schnelle Verbindung zum Backend erforderlich macht.
Sehen wir uns aber an, wie hier die üblichen Voraussetzungen aussehen, wenn man dabei einen im Tastaturmodus betriebenen Barcode-Scanner verwendet.
Als Eingabesteuerelement kommt hier praktisch nur ein Textfeld in einem Formular infrage. Das erste Problem, das sich hier stellt, ist die Tatsache, dass dieses Textfeld zu Beginn des Scans zwingend den Fokus haben muss, sich also die Einfügemarke darin befinden muss. In der Eile eines Kassiervorgangs werden Sie dazu sicher weder die Maus, noch die Tab-Taste bemühen wollen.
Alternativ könnte man auch ohne Textfeld arbeiten, die Eigenschaft Tastenvorschau des Formulars auf Ja setzen und so alle “Anschläge” des Scanners etwa in KeyDown-Ereignissen abfangen.
In beiden Fällen aber ist ungewiss, wann denn der Scan abgeschlossen ist. Schließlich kommen die Ziffern als eine Serie von zeitlich versetzten Anschlägen an, was noch nicht mal besonders schnell geht – man kann durchaus dabei zuschauen, wie die Zeichen nach und nach eintrudeln. Nun ist zusätzliche Logik erforderlich, die erst einen vollständigen Barcode identifiziert.
Als Regel könnte man etwa festlegen, dass für einen EAN13-Code nach 12 Zeichen Schluss ist. Was aber, wenn auch Artikel mit EAN8-Barcodes vorkommen, was für kleine Verpackungen etwa gang und gäbe ist Hier schlägt die Regel fehl und andere Mittel zur Ermittlung des letzten Zeichens sind gefragt.
Eine sehr unzuverlässige Methode wäre etwa, die Zeit zu messen, die zwischen den Anschlägen verstreicht, und festzulegen, dass ein Scan dann vollständig ist, wenn innerhalb eines definierten Zeitraums keine neue Tastatureingabe erfolgt.
Machen Sie sich besser keine Gedanken, wie solch ein Vorhaben wasserdicht zu realisieren ist. Es gibt eine erheblich einfachere und stabilere Lösung. Wenn ein Gerät schon serielle Signale sendet, warum sollte man diese dann in Tastaturbefehle umwandeln, statt sie gleich in Ereignisse zu überführen, die von einer maßgeschneiderten Schnittstelle ausgewertet werden können Und genau das ist OPOS.
OPOS
OPOS ist die Abkürzung für OLE for Retail POS. POS wiederum steht für Point Of Sales. Das ist der Oberbegriff für alle Hardware-Komponenten, die im Umfeld der Warenwirtschaft vorkommen können – also Barcode-Scanner, Bondrucker, Kassenladen, Chipkarten- und Magnetstreifenleser, Waagen und vieles mehr. All diese Komponenten verfügen über Treiber, die häufig das Signal der Geräte in serielle Byte-Folgen umwandeln. Das Abgreifen dieser Byte-Folgen über API-Funktionen ist schwierig und setzt mindestens voraus, dass die Spezifikation der Datenpakete bekannt ist. Die Hersteller veröffentlichen diese Spezifikationen jedoch in den seltensten Fällen.
Mit dem OLE im Begriff kommt nun eine weitere Schnittstelle ins Spiel. Tatsächlich ist die Bezeichnung OLE in diesem Zusammenhang veraltet und irreführend. Richtiger wäre COM oder ActiveX, denn das Wesen von OPOS sind ActiveX-Schnittstellen zu den Treibern der Geräte.
Kurz und bündig zusammengefasst funktioniert OPOS für unsere Aufgabe so: Sie instanzieren ein Objekt einer ActiveX-Schnittstelle, die Sie in die Verweise Ihres VBA-Projekts aufnehmen – hier eine OPOS-Scanner-Komponente -, nehmen ein paar Einstellungen vor und werten nun nur noch die Scan-Ereignisse aus, die die Komponente erzeugt. Wie das genau vonstatten geht, finden Sie im Folgenden erläutert.
Voraussetzungen
- Sie haben einen Barcode-Scanner mit einer RS232- oder USB-Schnittstelle.
- Der Hersteller bietet OPOS-Treiber an.
- Sie haben administrative Rechte auf ihrem System.
- Der Hersteller bietet Software an, mit der sich Scanner und OPOS-Schnittstelle im System konfigurieren lassen.
Der letzte Punkt ist nicht zwingend erforderlich, weil sich die Konfiguration im Prinzip auch manuell über Einträge in die Registry erledigen ließe.
Modell
Es ist verblüffend: Da hat ein Konsortium von Herstellern schon vor über zehn Jahren einen Standard verabschiedet und fortlaufend weiterentwickelt, ohne dass dieser trotz aller Vorteile wirklich wahrgenommen würde. Zwar bieten praktisch alle Hersteller OPOS-Support und die entsprechenden Treiber an, dennoch sucht man nach Anleitungen oder Beispiel-Codes im Netz fast vergebens. Die einzigen Dokumentationen dazu finden sich nahezu ausschließlich in recht dürftiger Form in PDFs auf den Support-Seiten der POS-Hersteller.
Auch die Seite des Konsortiums ARTS selbst [1] gibt nicht viel her. Dort kann man das Hauptwerk zu UnifiedPOS, einer kompatiblen Weiterentwicklung von OPOS, herunterladen, die auch die Referenz zu OPOS enthält. Auf den fast 2000 Seiten dieses Dokuments kann man zwar haarklein Spezifikationen zu jeder Hardware-Gattung finden, aber keine konkreten Entwicklerbeispiele.
Eine etwas ältere Version des OPOS Programmers Guide ist übrigens auch auf der Begleit-CD zum Magazin gespeichert.
Dabei ist das Ganze so schwierig nicht. Beginnen wir mit dem generellen Modell von OPOS, wie es in Bild 1 veranschaulicht ist.
Bild 1: OPOS-Modell
Der Barcode-Scanner ist über USB an den Rechner angeschlossen. Es handelt sich hier um ein Modell des Herstellers Metrologic. Beim ersten Einstecken wird Windows vergeblich nach Treibern für das Gerät suchen, aber auch online nicht fündig werden. Entweder Sie haben nun eine mit dem Gerät gelieferte CD zur Hand oder Sie laden die passenden Treiber vom Hersteller-Support herunter.
Dort finden Sie meist allerlei Downloads ohne weitere Anmerkungen, kümmern sich zunächst aber nur um den USB-Treiber, der gemeinhin lediglich die Aufgabe hat, das USB-Gerät über einen virtuellen COM-Port zu veröffentlichen. Ohne diesen Treiber funktioniert alles Weitere nicht.
Sie entpacken also das heruntergeladene Treiberpaket, stecken den Scanner ein und folgen den Anweisungen von Windows, die letztlich in der Aufforderung münden, das Verzeichnis mit den Treibern anzugeben.
Das Gerät zeigt sich nach erfolgreicher Installation im Zweig Anschlüsse des Geräte-Managers von Windows und im Prinzip könnten Sie nun bereits über eine COM-Schnittstelle Kontakt mit dem Scanner aufnehmen und seinem seriellen Port lauschen.
API-Geraffel wollen Sie aber wohl nicht und laden deshalb im zweiten Schritt die OPOS-Treiber zum Gerät herunter. Im Falle unseres Metrologic-Scanners nennt sich die Software etwa MetrOPOS Driver. Die enthält häufig nicht allein den OPOS-Treiber, der lediglich aus einer einzelnen kleinen DLL besteht, sondern auch noch Konfigurationsanwendungen.
Der OPOS-Treiber hat eine bestimmte Aufgabe. Er kennt das Gerät und dessen Treiber ganz genau und kann mit ihm in allen Belangen kommunizieren. Nur der Hersteller des Geräts kann deshalb diesen OPOS-Treiber entwickeln. Die Kommunikation verläuft in beiden Richtungen: OPOS kann vom Gerät lesen und Anweisungen zu ihm senden.
Der Witz an der Geschichte ist, dass der OPOS-Treiber eine standardisierte ActiveX-Schnittstelle anbietet, die einen definierten Satz von Methoden und Eigenschaften beherbergt. Nach außen sieht ein OPOS-Treiber also immer gleich aus. Tatsächlich könnte man diese Schnittstelle verwenden – in unserem Beispiel wäre ein Verweis auf die MetroSO 1.0 Type Library der metroSO.dll zu setzen -, um vom Scanner zu lesen. Allerdings noch ohne Unterstützung durch Events.
Auch sonst wäre noch ziemlich aufwendige Programmierung nötig, um mit dem OPOS-Treiber direkt zu sprechen.
Unabhängigkeit
Das größte Manko bei direkter Ansprache des OPOS-Treibers ist jedoch, dass man damit dem Scanner-Hersteller ausgeliefert ist. Schließlich ist ein Verweis auf die herstellerspezifische DLL zu setzen.
Wollte man den Barcode-Scanner am Kassensystem aber durch ein anderes Modell ersetzen, so müsste man die Anwendung komplett neu erstellen und einen Verweis auf den neuen OPOS-Treiber setzen.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
