EPCIS

Der erste Ansatz welche bis 2.23.2 im Einsatz war erzeugte die zu übermittelnden XML Dokumente in zwei Schritten: Die Daten wurden im Client Programm zusammengestellt und über eine Warteschlange an den zentralen EPCIS Dienst (Service) übergeben. Der EPCIS Dienst formatierte dann die Daten zu XML Telegrammen und übermittelte diese per HTTP POST an den zentralen EPCIS Server.

Der erste Ansatz hat sich in der Praxis aus zwei Gründen als nicht optimal herausgestellt: Zum einen werden häufiger als ursprünglich angenommen Änderungen respektive Erweiterungen an den XML-Telegrammen benötigt, was jedes Mal eine neue Release von BPS erfordert. Zum anderen ist das Konzept mit der geteilten Datenzusammenstellung, Übergabe, und dann Generierung der Telegramme kompliziert, ausserdem speziell aufwändig wenn neue Daten hinzukommen für welche die Tabelle der Queue wieder erweitert werden muss.

Die neue Implementierung ab 2.23.3 verlagert die Datenermittlung und Generierung der XML Telegramme in ein Skript. Über die Warteschlange wird jetzt nur noch das fertige Telegramm an den EPCIS-Dienst weitergegeben, welcher dieses dann an den zentralen EPCIS Server übermittelt.

Somit ist es jetzt nicht mehr erforderlich für jede EPCIS Anpassung eine neue BPS Release zu erstellen. Es genügt dazu ein neues Script zu erstellen oder ein bestehendes anzupassen.

Diese Anpassungen können weiterhin durch IBK gemacht werden. Sie könnten auf Wunsch aber zukünftig auch kundenseitig selber gemacht werden.

Folgende Scripts existieren derzeit:

Grundsätzlich gibt es 2 verschiedene Varianten wie die EPCIS Ereignisse in BPS entstehen:

Bei den Packlinien der Fleischproduktion (ZFL) werden Gebinde befüllt und sofort einem Empfänger zugeordnet (kommissioniert). Die Gebinde sind mit einem fest angebrachten Tag mit RFID und Barcode versehen, der einen GRAI Code beinhaltet.

Ein Gebinde ist im Fleisch gemäss BPS Terminologie eine LU da es mehrere TU beinhalten kann.

Während der Registrierung an der Packlinie wird der GRAI des gefüllten Gebindes vom angeschlossenen RFID Leser übernommen und zusammen mit den übrigen Pickdaten in der Tabelle t_orderpicks abgespeichert.

Gleichzeitig werden folgende EPCIS Events generiert:

• Ein Event zur Löschung des alten GRAI (DELETE / decommissioning)
• Ein Event für den Packprozess (ADD / packing)
• Ein Event für die Zuordnung zum Empfänger (OBSERVE / picking)

In den übrigen Bereichen (ZMC, ZKS, ZVM) werden Gebinde / Pakete / Sixpack etc. (=TU) auf eine Palette oder in einen Tainer (=LU) kommissioniert.

Tausch-Paletten oder Tainer sind zwar auch Mehrweggebinde, haben jedoch keine individuelle Kennung in Form eines GRAI. Stattdessen arbeitet man hier mit einem SSCC der als Barcode auf der Empfängeretikette sichtbar ist. Mittels spezieller Zebra-Drucker kann die erstellte Empfängeretikette auch ein RFID-Tag enthalten, sodass die SSCC ebenfalls per Scanner oder per RFID Funk gelesen werden können.

Beim Abschluss einer Palette wird der SSCC erzeugt, und gleichzeitig ein EPCIS Event generiert:

• Event für die Kommissionierung (ADD / picking)

Werden Pickdaten aus einer aktiven Tour gelöscht , so wird für die betroffenen GRAI oder SSCC wieder ein Event generiert:

• Event für die Löschung (DELETE / picking)

Wenn nur ein Teil des Inhalts des GRAI oder SSCC gelöscht wird, werden im Event die entsprechenden Teilmengen pro Artikel aufgelistet.

Wenn alles gelöscht wird das in einem bestimmten GRAI oder SSCC war, so enthält das DELETE Event keine einzelnen Artikelmengen und umfasst so das ganze Gebinde respektive die ganze Palette.

Gemischte Arten von DELETE Events gibt es wenn zuerst nur ein Teil des SSCC/GRAI, und später noch der Rest gelöscht wird. Dann gibt es zuerst ein DELETE mit Artikel-Teilmengen, und zuletzt noch DELETE ohne Artikel-Teilmengen.

Keine EPCIS DELETE-Events werden erzeugt wenn eine aktive Tour z.B. per DB-Befehl oder Purgehistory-Script gelöscht wird.

Grund-Voraussetzung zur Aktivierung der EPCIS Event-Erzeugung in den BPS Client Programmen ist die Angabe eines gültigen Scripts in Central System Settings/EPCIS:

Der Dateiname des Script ist relativ zum BPS Installationsverzeichnis. Es ist aber auch möglich einen kompletten Dateipfad als absolute Adresse anzugeben, z.B. wenn der Script auf einem Netzwerk-Share liegt.

Ab 2.24.6: Mit «CustomPackLine» kann eine Pseodo-Packlinie angegeben werden welche bei GRAI-Events aus einer Kundenbestellung verwendet werden soll um Packereignisse mit Aktion «ADD» zu erzeugen. Für die angegebene Packlinie muss ein «Readpoint» definiert sein (siehe weiter unten). Das kann eine existierende echte Packlinie sein, oder eine rein virtuelle Packlinie welche ausschliesslich für die Kundenbestellungen verwendet wird.

Weiter ist hier bei «SU» die Eingabe der GLN des Absenders erforderlich wie sie im Feld SU des Events abzufüllen ist.

Der Parameter «SsccPrefix» ist hingegen erst ab Version 2.24 an dieser Stelle erforderlich, bis dahin wird noch die alte Einstellung unter Central System Settings/Labeling/LU verwendet um den SSCC zu generieren:

Für jede Packlinie an der GRAI Gebinde gepackt werden, muss der EPCIS Lesepunkt (Readpoint) unter Central System Settings/EPCIS definiert sein:

Bei den übrigen Bereichen wo SSCC- statt GRAI-Events generiert werden, wird statt eines Packlinien-Readpoints die Einstellung «EPCIS Ort» im Zonenstamm verwendet:

Ab Script gmos113.js werden unter Central System Settings/EPCIS/Tradegroups die Zuordnungen zwischen der Touren-ID und der im EPCIS Event verwendeten Handelsgruppe (Tradegroup) benötigt:

Bei «Schlüssel» wird die Touren-ID eingegeben, und bei «Wert» die Bezeichnung der Handelsgruppe. Ist für eine bestimmte Touren-ID kein Schlüssel vorhanden, so wird das Tradegroup-Element im EPCIS Event weggelassen.

Das Programm «EPC Dienst» muss auf dem PC oder Server mitinstalliert werden wo der Dienst dann ausgeführt werden soll:

Das geschieht entweder explizit im benutzerdefinierten Setup, oder implizit wenn die vollständige Installation gewählt wurde. Der Dienst wird vom Setup zunächst auf manuellen Start eingestellt, sodass er in der Dienstverwaltung gestartet werden muss. Natürlich können Sie den Dienst auf automatischen Start umstellen sobald alles korrekt konfiguriert ist:

Der Dienst protokolliert Fehler, Warnungen und Informationen nebst in der optionalen Logdatei auch in der Windows-Ereignisverwaltung:

Der EPC-Dienst kann nur eine BPS Datenbank bedienen. Bei mehreren BPS Systemen müssen die entsprechenden Dienste auf separaten PC respektive virtuellen Maschinen installiert und eingerichtet werden.

Es ist empfehlenswert, für den EPC-Dienst einen separaten BPS-Benutzer anzulegen. Dieser Benutzer benötigt keinerlei spezielle Berechtigungen, muss also auch in keiner Gruppe sein:

Die Einstellungen für den EPC Dienst erfolgen unter Local Installation Settings/EPC-Service.

Beachten Sie, dass die Einstellungen auf dem PC respektive Server gemacht werden müssen auf dem der Dienst ausgeführt wird. Die minimal erforderlichen Parameter sind «Connection», «User», «PIN», und «EpcisServer».

Achten sie darauf, dass die angegebene Verbindung (Connection) ebenfalls unter Local Installation Settings vorhanden ist wie im Beispiel oben. Andernfalls kann es sein, dass der Dienst die Verbindung nicht findet und eine ungültige Verbindung reklamiert.

Ab 2.23.3 steht ein einfaches Simulationsprogramm zur Verfügung das installiert wird wenn sie das Feature «Simulationsprogramme» im Setup-Programm anwählen. Es wird intern von IBK für die Software-Entwicklung verwendet, steht ihnen aber «As-Is» für allfällige Tests ebenfalls zur Verfügung:

Das Programm kann von einer Kommandozeile aus gestartet werden, statt den Dienst zu starten. Das ist hilfreich um live zu verfolgen was passiert, und ob es Fehler gibt, statt jedes Mal in der Windows Ereignisanzeige nachzuschauen.

Ab 2.24 finden sie dazu um BPS Startmenü das Icon «BPS Kommandozeile 2.24.x» wenn sie das entsprechende Feature im Setup angewählt haben. Ansonsten öffnen sie eine normale Windows Kommandozeile und fügen das bin Unterverzeichnis des BPS Installationsorts zur Umgebungsvariable PATH hinzu.

Starten sie dann das Programm mit dem Befehl epcservice –e:

Mit Ctrl-C kann das Programm beendet werden.

Das Log wird als Textdatei im CSV Format geschrieben:

Die folgenden Spalten sind vorhanden:

• Zeitstempel
• Status
  • Success: Erfolgreiche Übermittlung (Spalten Aktion und EPC immer gefüllt)
  • Error: Fehler (Spalten Aktion und EPC bei allgemeinen Fehlern nicht immer gefüllt)
• Aktion
  • Add: Hinzufügen eines EPC
  • Delete: Löschen eines EPC
  • leer: bei allgemeinen Fehlern
• EPC: bleibt leer bei allgemeinen Fehlern
• Meldung: Status der Übermittlung resp. Fehlermeldung im Klartext

Wenn die Erweiterung des Dateinamens .csv lautet, so kann die Datei per Doppelklick auch direkt in Excel geöffnet werden. Sie können so die Möglichkeiten von Excel nutzen um die Datei zu durchsuchen, zu filtern oder zu sortieren:

Zu den EPCIS Servern liegen keine aktuellen Informationen vor, letzter Stand:

Die EPCIS Event-Versorgung erfolgte ursprünglich durch BPS via HTTP POST auf den Endpunkt http://<EpcisServer>/BTSHTTPReceive/BTSHTTPReceive.dll?EPCIS.

Inzwischen kann statt dessen auch die komplette URL frei angegeben werden, indem die Einstellung «EpcisServer» mit «http:» oder «https:» beginnt, statt dort nur die Serveradresse oder IP einzugeben.

Die folgenden Event Typen werden erzeugt:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epcis:EPCISDocument
 xmlns:epcis="urn:epcglobal:epcis:xsd:1"
 xmlns:migros="http://epcis.migros.net/migros/"
 xmlns:gmos="http://epcis.migros.net/gmos/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 creationDate="2020-06-29T11:30:47.916Z"
 schemaVersion="1.1">
    <EPCISBody>
        <EventList>
            ...
        </EventList>
    </EPCISBody>
</epcis:EPCISDocument>

Die «EventList» enthält jeweils ein oder mehrere «AggregationEvent» nacheinander (hier durch … symbolisiert). Beim Hinzufügen eines GRAI aus der Fleischabpackung sind es jeweils zwei (für Packen + Kommissionieren), ansonsten jeweils eines.

Die Event Definition beschreibt alle Elemente die bei BPS verwendet werden. In der nachfolgenden Tabelle ist die Verwendung in den verschiedenen Event-Typen dokumentiert.

Es handelt sich um ein Subset aller im M-EPCIS Implementation-Guide definierten Elemente. Diverse dort als KANN definierte Elemente werden von BPS nicht verwendet.

Dafür sind zusätzliche Elemente gmos:… vorhanden welche betriebsspezifische Informationen enthalten.

<AggregationEvent>
    <eventTime>2014-02-26T04:44:37+02:00</eventTime>
    <eventTimeZoneOffset>+02:00</eventTimeZoneOffset>
    <parentID>urn:epc:id:grai:7613264.00307.100005001097</parentID>
    <childEPCs>
        <epc>urn:epc:id:sgtin:7617100.052078.0</epc>
        <epc>urn:epc:id:sgtin:7617100.069803.0</epc>  
        <epc>urn:epc:id:sgtin:7617020.076259.0</epc>  
    </childEPCs>
    <action>ADD</action>
    <bizStep>urn:epcglobal:cbv:bizstep:packing</bizStep>
    <readPoint>
        <id>urn:epc:id:sgln:7617007.09913.00800104000000000001</id>
    </readPoint>
    <bizLocation>
        <id>urn:epc:id:sgln:7617007.09913.00800104</id>
    </bizLocation>
    <bizTransactionList>
        <bizTransaction type="urn:epcglobal:cbv:btt:po">
            http://epcis.migros.net/gmos/documents/po/16526508
        </bizTransaction>
    </bizTransactionList>
    <extension>
        <childQuantityList>
            <quantityElement>
                <epcClass>urn:epc:idpat:sgtin:7617100.052078.0</epcClass> 
                <quantity>2.45</quantity> 
                <oum>KGM</uom>
            </quantityElement> 
            <quantityElement>
                <epcClass>urn:epc:idpat:sgtin:7617100.069803.0</epcClass> 
                <quantity>6</quantity> 
            </quantityElement> 
            <quantityElement>
                <epcClass>urn:epc:idpat:sgtin:7617020.076259.0</epcClass> 
                <quantity>10</quantity> 
            </quantityElement> 
        </childQuantityList>
        <sourceList>
            <source
             type="http://epcis.migros.net/migros/elements/destination/SU">
                urn:epc:id:sgln:7617007.00000.0
            </source>
        </sourceList>   
        <destinationList>
            <destination
             type="http://epcis.migros.net/migros/elements/destination/UC">
                urn:epc:id:sgln:7617007.00445.0
            </destination>
        </destinationList>
    </extension>
    <migros:LUAttrDeliveryTime>2014-02-27T00:00:00+02:00
    </migros:LUAttrDeliveryTime>
    <gmos:TripName>T09C Nachmittagsfuhre Charcuterie</gmos:TripName>
    <gmos:TradeGroup>FLM1</gmos:TradeGroup>
    <gmos:OrderPosition>16526508.0010</gmos:OrderPosition>
    <gmos:conveyance>O</gmos:conveyance>
    <gmos:Packline>12</gmos:Packline>
    <gmos:Trip>1</gmos:Trip>
    <gmos:DestinationZone>1</gmos:DestinationZone>
    <gmos:ArticleKey>1234</gmos:ArticleKey>
    <gmos:OrderNumber>12345678</gmos:OrderNumber>
    <gmos:OrderSize>15</gmos:OrderSize>
    <gmos:GraiSequenceOfOrder>3</gmos:GraiSequenceOfOrder>
</AggregationEvent>

• Zur besseren Lesbarkeit wurde zusätzlicher Whitespace eingefügt.
• Alle gmos:… Elemente haben zusätzlich ein xmlns-Attribut, welches zur besseren Lesbarkeit weggelassen wurde.
  Ohnehin ist es wohl überflüssig, da der Namespace für gmos Elemente ja bereits bei epcis:EPCISDocument spezifiziert ist.