GEKO/TAKO Schnittstellen

Die GEKO und TAKO Schnittstellen sind als Database-Link zwischen den beiden Oracle Datenbanken von BPS und Automat realisiert.

Übermittlungen werden durch Oracle-Transaktionen gesichert. Es gibt somit keine Inkonsistenten wie halb verarbeitete oder fehlerhafte Dateien; eine Transaktion ist immer vollständig erfolgreich oder die Datenbank wird wieder auf den Anfangszustand zurückgesetzt (Rollback). Dies betrifft nicht nur die Schnittstelle an sich sondern auch alle damit zusammenhängenden Änderungen in den Applikationstabellen welche in der gleichen Transaktion erfolgen. Selbst nach Hardware Crashs wird durch die Recovery Funktionen von Oracle ein konsistenter Zustand nicht nur der Applikationstabellen, sondern auch der Schnittstelle wiederhergestellt.

Die Schnittsstelle an sich ist sehr schnell und für Online-Änderungen geeignet, da die Daten nicht zuerst in ein Dateiformat konvertiert werden, und anschliessend wieder decodiert (geparst) werden müssen.

Aktuelle Stammdaten stehen jederzeit als Views zur Abfrage durch das Kommissioniersystem bereit, und nicht nur zu bestimmten Zeiten. Ein separater Batch Prozess für die periodische Aufbereitung von Stammdaten auf dem BPS entfällt.

Die Schnittstelle ist so konzipiert, dass keinerlei Zugriffe von BPS aus in die Datenbank des Automaten erfolgen um jegliche Beeinträchtigung des Zeitverhaltens des Automaten durch BPS auszuschliessen. Alle Schnittstellen-Tabellen und -Views befinden sich deshalb in der BPS Datenbank, und es wird nur ein einseitiger Database Link von Automaten-Datenbank auf BPS Datenbank eingerichtet.

Im folgenden Beispiel richtet der Entwickler in der Oracle Datenbank des Automaten einen DB Link zur BPS Datenbank ein. Auf der Datenbank ZAB hat Ihm der BPS Administrator dazu ein Benützerkonto auf den Namen TAKO mit dem Passwort ASIMOV eingerichtet, und diesem Benützer die erforderlichen Zugriffsrechte auf die Tabellen und Views der Automaten-Schnittstelle gewährt. Die BPS Datenbank hat den globlen Namen GMOS3.WORLD, und hat den TNS Namen ZAB.

  create database link gmos3.world connect to tako identified by asimov using zab;

Die physischen Views und Schnittstellen enthalten an Stelle von _pr_ (wie in der Originalspezifikation für BPS V1) jeweils _geko_ respektive _tako_ im Namen. Für den Zugriff auf die Schnittstelle sollte der Automat deshalb in seiner Oracle Instanz eigene Views oder Synonyme zu definieren. Während die Namen der Views und Tabellen auf der BPS Seite fix sind, steht dem Entwickler des Automaten natürlich frei wie er die Views/Synonyme in der Automaten-DB benennen will. Nachfolgend werden solche auf je eine BPS View und eine BPS Tabelle jeweils mit dem Prefix LLS_ definiert:

  create or replace view lls_articles as select * from zab.v_tako_coll_articles@gmos3.world;
  create or replace view lls_orders as select * from zab.t_tako_orders@gmos3.world;

oder

  create synonym lls_articles for zab.v_tako_coll_articles@gmos3.world;
  create synonym lls_orders for zab.t_tako_orders@gmos3.world;

Ein weiterer Vorteil der Definition solcher Views oder Synonyme im Automaten ist, dass der DB Link oder die Benennung der Tabellen und Views innerhalb BPS geändert werden können, ohne dass in der eigentlichen Applikation des Automaten etwas verändert werden muss.

Die Views auf die Stammdaten haben jeweils den Prefix v_geko_ oder v_tako_.

Die Tabellen der Bewegungsdaten haben jeweils den Prefix t_geko_ oder t_tako_.

• BPS erzeugt die Zeilen mit Status = 0 per INSERT.
• Der Automat verarbeitet die Anforderungen und setzt den Status per UPDATE auf 1, 2 oder 3.
• BPS verarbeitet die Antwort und löscht die Zeile per DELETE.

• BPS erzeugt die Zeilen per INSERT.
• Der Automat verarbeitet die Zeilen und löscht sie per DELETE.

• Der Automat erzeugt die Zeilen per INSERT.
• BPS verarbeitet die Zeilen und löscht sie per DELETE.
• Allfällige Fehler werden im Log des Batchprogramms GekoSync.log respektive TakoSync.log protokolliert.

Die Stammdaten-Views in der BPS Datenbank stehen permanent zur Abfrage zur Verfügung und wiederspiegeln den aktuellen Stand im BPS mit allen per COMMIT bestätigten Mutationen.

Vom Automaten werden die Stammdaten nur zu bestimmten Zeiten abgefragt, z.B. täglich 23.00 oder bei Ereignissen wie z.B. Kommissionierbeginn einer Tour. Diese Zeiten und Ereignisse sind nicht Bestandteil dieses Pflichtenhefts, sondern in der Spezifikation des Automaten festzulegen.

Stammdaten-Mutationen welche auf dem BPS erfolgen werden deshalb nicht unmittelbar auf dem Automaten wirksam, sondern erst zu den festgelegten Zeiten oder Ereignissen.

Da diese Aktionen im Dialog der Programme Offene Touren und Sortimentartikel ausgelöst werden, sollen die Befehle möglichst rasch beantwortet werden. Umfangreichere Aktionen wie Kürzungen und Verschiebungen können dazu führen dass BPS Datensätze in der Grössenordnung der Anzahl Filialen generiert.

Die maximale Anwortzeit des Automaten (d.h. bis alle Datensätze verarbeitet sind) wird wie folgt spezifiziert:

• Für 1 bis 10 Datensätze: 15 Sekunden
• Für 10 bis 150 Datensätze: 60 Sekunden
• Für über 150 Datensätze: Proportional mehr, d.h. bis 300 Datensätzen 120 Sekunden etc.

Das genaue Zeitverhalten zeigt sich erst am realen System, die Angaben oben sind auf der vorsichtigen Seite und werden voraussichtlich erheblich unterschritten. Die Reaktionszeit des Automaten wird hauptsächlich von der Polling-Zeit (zB. all 5-10 sec) bestimmt, die jedoch nicht zu klein gewählt werden darf. Das Polling soll deshalb dynamisch verändert werden, d.h. im Ruhezustand wo keine Kommunikation stattfindet genügt es die Abfrage alle 10 bis 15 Sekunden durchzuführen. Sobald jedoch effektiv eine Anfrage gestellt wird, ist die Wahrscheinlichkeit sehr hoch dass nach Beantwortung gleich noch weitere Anfragen erfolgen. Die Poll-Zeit sollte deshalb nach der Verarbeitung einer Anfrage auf eine kurze Zeit heruntergesetzt werden (z.B. auf 1 oder 0,5 Sekunden). Erst wenn dann mehrmals keine weitere Anfrage mehr erfolgt soll die Pollzeit wieder zurückgesetzt werden auf 10-15 Sekunden. Idealerweise sollten diese Poll-Parameter im GEKO einstellbar sein.

Die Verarbeitung der Pickmengen und der „Ende Kommissionierung“ Meldung erfolgt über einen Batchjob welcher auf dem BPS Scheduler ausgeführt wird. Der Job wird z.B. alle 5 Minuten ausgeführt, wobei dieses Intervall je nach Bedarf duch die Informatik selbständig im Autosys eingestellt werden kann.

Die Verarbeitung der Bestandesmeldungen erfolgt innerhalb des Dialogprogramms und unmittelbar nach Beantwortung der entsprechenden Anforderung durch den Automaten.

An Stelle von _xxxx_ steht jeweils _geko_ respektive _tako_.

Detailposition löschen.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Wird die letzte Position eines Partnerauftrags gelöscht, so wird damit auch der entsprechende Partnerauftrag selbst gelöscht. War es der letzte Partnerauftrag einer Tour, so wird auch die Tour gelöscht.

Detailposition Änderung (Sollmenge und/oder Palettencode).

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Partnerauftrag verschieben.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Partnerauftrag löschen.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Wenn der letzte Partnerauftrag einer Tour gelöscht wird, so wird damit auch die Tour selbst gelöscht.

Bestellpositionen.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Palettenaufgabe zur Wicklung und Etikettierung.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Eine neue Anforderung mit Status 0 wird erstellt wenn sich der Benutzer im BPS Kommissionierprogramm im Druckfenster für die Palettenetikette befindet, und der Rüster statt den Druck auszulösen einen Identifikations-Barcode beim I-Punkt Karton scannt.

Wird die Anforderung vom Automat mit Status 1 quittiert, so ist die Palette in den Verantwortungsbereich des Automaten übergegangen. Der Druckdialog im Kommissionierprogramm wird geschlossen und der Rüster kann weiter kommissionieren.

Wird die Anforderung durch den Automaten mit Status 2 abgelehnt, so wird dem Benutzer im Kommissionierprogramm eine entsprechende Fehlermeldung („Anforderung durch Automat abgelehnt“) angezeigt. Nach quittieren der Fehlermeldung kann der Benutzer die Etikette drucken und die Palette anderweitig abtransportieren.

Es kann im praktischen Betrieb nur immer einen Datensatz mit Status 0 geben. Sollte (durch technischen Fehler oder durch Umgehen der Bedienvorschriften) die Situation entstehen dass mehr als ein Datensatz mit Status 0 vorhanden ist, so wird der Automat alle vorhandenen offenen neuen Anforderungen mit Status 2 ablehnen. Der Bediener der tatsächlich bei der Aufgabestelle an der Reihe ist kann dann entweder den Aufgabestellen-Barcode nochmals scannen um die Anforderung zu wiederholen, oder er kann die Palettenetikette drucken und die Palette anderweitig abtransportieren.

Pickmenge einer Bestellposition.

Bewegungsdaten Automat zu BPS ohne Rückmeldung.

Crossdocking Pickmenge.

Bewegungsdaten Automat zu BPS ohne Rückmeldung.

Abfrage Lagerbestand.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Wenn diese Abfrage gestellt wird, stellt der Automat die Bestände aller im Automatenlager vorhandenen Artikel in die Tabelle t_xxxx_stocklevels, und quittiert anschliessend diese Abfrage.

Die Anfrage wird in der Regel zu einem Zeitpunkt gestellt in welchem die Kommissionieranlage ruht. Sollte die Anfrage jedoch ausnahmsweise zu einem Zeitpunkt erfolgen in welchem die Einlagerung und/oder Kommissionierung im Gange ist, so ist es dem Automat freigestellt ob die Bestände nur effektiv in den Lagerplätzen liegende Gebinde umfassen oder auch solche die in der Anlage unterwegs sind (je nachdem welche Implementierung günstiger ist).

Bestandesmeldungen.

Bewegungsdaten Automat zu BPS ohne Rückmeldung.

GEKO: Nur Bestand der nicht gesperrt ist
TAKO: Nur Bestand in Portalen

Meldung wenn Tour beendet.

Bewegungsdaten Automat zu BPS ohne Rückmeldung.

Tour verschieben.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

Tour löschen.

Bewegungsdaten BPS zu Automat mit Rückmeldung.

An Stelle von _xxxx_ steht jeweils _geko_ respektive _tako_.

Artikelbilder.

Alle Bar Codes zum Scannen.

In BPS verwendete Barcode-Suche auf Grund des gescannten Codes:

• Wenn erste 2 Stellen = 21, 22, 28, 29, oder Länge des Codes kleiner/gleich 8: Vergleiche die ersten 7 Stellen.
• In allen anderen Fällen: Vergleiche die ersten 12 Stellen.

Beispiel:

select collection, art_no
from v_xxxx_barcodes
where substr(barcode,1,7)=’2155667’

Gebindestamm.

Im View erscheinen nur Gebinde mit dem Attribut GEKO oder TAKO.

Absatzkanäle.

Bei Lieferanten zur Bestimmung des Crossdocking Inhalts.
Bei Filialen zur Bestimmung der Grösse.

Sortimentartikelstamm.

Hängige Anforderungen von BPS.

Information zu einer bestimmten Palettennummer.

In BPS V2 ist die Palette über eine 15-stellige LU ID eindeutig identifiziert. Als Palettennummer werden aber nur die niedrigsten 6 Ziffern davon verwendet. Da die Aufbewahrungsdauer der Bewegungsdaten in BPS nicht technisch limitiert ist, könnte es also vorkommen dass dieselbe Palettennummer nach einer gewissen Zeit wieder vorkommt. Damit der View eindeutige Ergebnisse liefert wird er deshalb intern auf Pickdaten limitiert die maximal eine Woche alt sind.

Aus Leistungsgründen soll der Automat nur einzelne Datensätze gezielt nach Palettennummer abrufen (…. where pallet = …..).

Partnergruppen.

Partner (Filialen + Lieferanten).

Der Absatzkanal ist bei Lieferanten analog der Produktesektoren und Produktegruppen belegt, und dient dazu den Inhalt der Crossdocking Gebinde zu klassifizieren. Bei Filialen dient er dazu die Grösse sowie die Sonderfilialen zu unterscheiden.

Die Kommissionierpriorität kommt aus der Partnerliste in der GEKO/TAKO Pickzone.

Der SSCC Prefix ist bei allen Partnern identisch und wird den zentralen System-Einstellungen entnommen (Labeling/LU/SSCC Prefix).

Partner/Touren Verknüpfung.

BoSS Bedarfswelt.

BoSS Bedarfsbereich.

Tourenstamm.