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.
Damit man hier unabhängig bleibt, wurde für OPOS eine weitere Ebene eingezogen, die die Abstraktion erhöht. In Bild 1 ist das die Ebene der geräteunabhängigen OPOS-ActiveX-Komponenten.
Die ActiveX-Komponente kennt den Satz von standardisierten Methoden und Eigenschaften eines OPOS-Treibers. Über diesen Methodensatz spricht sie ihn an. Der Clou daran aber ist, dass die Komponente den Treiber selbst gar nicht kennen muss. Sie erfährt alles Nötige dazu aus der Windows-Registry, nachdem man ihr lediglich den Namen eines sogenannten Service Objects angegeben hat. Dort steht dann, welche Treiber-DLL anzusprechen ist, um die Kommunikation herzustellen.
Natürlich müssen zuvor diese Registry-Einträge gesetzt worden sein. Das erledigt man entweder manuell oder sinnvoller über eine Anwendung, die dafür bestimmt ist. In unserem Fall kommt diese Anwendung gleich mit dem Metrologic-OPOS-Treiberpaket, das bereits heruntergeladen und installiert wurde.
OPOS-Konfiguration
In Bild 2 sehen Sie einen Ausschnitt der Konfigurationssoftware MetrOPOS.
Bild 2: OPOS-Konfiguration eines Metrologic-Barcodescanners
Die Sache ist denkbar einfach: Sie geben nur an, über welche Hardware-Schnittstelle der Scanner angeschlossen ist (USB), um welches Modell es sich handelt (Voyager 9520) und vor allem einen benutzerdefinierten Namen (metroscanner), über den der Scanner später angesprochen werden soll. Nach Übernehmen der Einstellungen schreibt das Tool alle benötigten Daten in die vorgesehenen Stellen der Registry.
Sie können auch mehrere Profile anlegen, falls Sie mehrere Scanner am System betreiben. Wichtig sind dabei jeweils die eindeutigen Namen zur Kennzeichnung der Scanner.
Besonders komfortabel ist es allerdings nicht, wenn Sie auf dem Zielsystem, etwa dem Kassensystem, immer erst die Konfigurationssoftware installieren müssen, um den Scanner einzurichten. Das ist aber auch nicht unbedingt erforderlich, wenn Sie wissen, welche Einträge in die Registry geschrieben werden müssen. Dann reicht schon die Weitergabe und ActiveX-Registrierung des OPOS-Treibers aus – hier: metroSO.dll – und eine .reg-Datei, die den passenden Zweig der Registrierungsdatenbank enthält. Dieser Zweig ist ebenfalls standardisiert und findet sich immer unter:
HKEY_LOCAL_MACHINE\SOFTWARE\OLEforRetail\ServiceOPOS\Scanner
Für jede Geräteart gibt es hier einen eigenen Zweig – Scanner, Scale, Printer et cetera.
Unterhalb dieser Schlüssel befinden sich die benutzerdefinierten Einstellungswerte unter dem Namen, den Sie für das Gerät vergeben möchten.
Der Baum für den in Bild 2 konfigurierten Scanner stellt sich unter Vista etwa wie in Bild 3 dar.
Der Schlüssel metroscanner enthält die Werte aus Bild 4.
Bild 3: Registry-Baum für eine OPOS-Scanner-Konfiguration (Vista)
Bild 4: Einstellungen für den OPOS-Scanner in der Registry
Für eine Weitergabe brauchen Sie nun lediglich den Zweig metroscanner aus der Registry in eine .reg-Datei zu exportieren und auf dem Zielrechner wieder zu importieren, ohne eine Konfigurationssoftware zu installieren. Bedenken Sie jedoch, dass der OPOS-Treiber nur dann funktionieren kann, wenn bereits ein serieller Treiber für das Gerät installiert wurde.
Übrigens enthält der Schlüssel mehr Werte als unbedingt nötig. Wichtig sind meist nur zwei: Die ProgID des OPOS-Treibers (Metrologic.Opos.Scanner) und der Name der Treiberdatei (MetroSO.dll).
OPOS-Controls
Damit wären wir endlich auf der untersten Ebene des OPOS-Modells (siehe Bild 1) angekommen, der OPOS-ActiveX-Komponente, die sich in Gestalt eines OPOS-Scanner-Steuerelements manifestiert.
Diese Komponenten auf Grundlage des ARTS-Standards kann eigentlich jedermann entwickeln, der sich dazu bemüßigt fühlt.
Es ist aber eine weitere Eigentümlichkeit von OPOS und Beweis für dessen Nischendasein, dass diese Komponenten fast ausschließlich aus der Feder von Curtis Monroe [2] stammen.
Seine freien Komponenten sind quasi Referenz und werden selbst von so namhaften Herstellern wie Metrologic verwendet. Folgerichtig sind sie auch bereits im OPOS-Treiberpaket MetrOPOS enthalten.
Sollte Ihr Hersteller keine OPOS-Steuerelemente anbieten oder beipacken, dann laden Sie einfach Monroes Komponenten unter [3] herunter.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo