Strukturen in der Datenbank
Die Strukturen in der Datenbank für die Blech-Laser-Daten-Schnittstelle
Categories:
Der Grundgedanke der Blech-Laser-Daten-Schnittstelle ist, dass damit, im Rahmen der vorhandenen Funktionen, die Kommunikation mit einem Fremdsystem sehr flexibel definiert ist.
Daher wurde die Kommunikation in Tabellen abgebildet.
Strukturen in der Datenbank
Nachfolgend eine ergänzende Beschreibung des Aufbaues der Definition Datenstruktur.
| Tabelle | Funktion |
|---|---|
| lp_daten_struktur | Definiert die Struktur der Dateninhalte, also wie sind die Daten zu importieren bzw. exportieren im Kontext zu den Kieselstein Informationen |
| lp_daten_struktur_feld | Definiert für eine Struktur die Felder welche Importiert bzw. exportiert werden sollen |
| ERP Felder | |
| lp_mapping | Definiert ein Mapping welches es erlaubt bestimmte Werte für die Schnittstellen zu ersetzen |
| lp_mapping_wert | Hier werden die Werte für die jeweiligen Mappings gespeichert |
| lp_sst_parameter | Definiert die Schnittstelle selbst, also Typ, Format, Auslöser etc. |
| lp_sst_lauf | Protokolliert jeden Lauf einer Schnittstelle |
Zusätzlich werden alle erfolgreichen Datenübertragungen protokolliert. Die Beschreibung der Felder findest du unter
Blech-Laser-Daten-Schnittstelle (lp_sst_parameter)
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | integer | Ja | Fortlaufende ID |
| c_transfer_typ | varchar(12) | Ja | Der Typ wie die Daten übertragen werden, wie: REST-DISPATCHER: Es werden Daten über einen HTTP-Post Request an einen anderen Webserver versendet/exportiert bzw. über einen HTTP-Get Request von einem anderen Webserver abgefragt/importiert. REST-RECEIVER: Es können über die Kieselstein-REST Api Daten importiert bzw. exportiert werden. Hierfür gibt es folgende neue Endpunkte: /api/v1/interfaces/{interfaceID}/get-data und /api/v1/interfaces/{interfaceID}/store-data . FILE: Die Schnittstelle importiert bzw. exportiert Daten von/in Dateien. |
| struktur_daten_i_id | integer | Ja | Die Referenz auf die Datenstruktur, welche bestimmt wie die Daten aufbereitet werden sollen. |
| i_ausloeser | smallint | Ja | Hier wird gesteuert bei welchen Aktionen die Schnittstelle ausgelöst wird: • 1 = Shop Timer (System/Automatik) • 2 = Los-Ausgabe • 3 = REST-Endpunkt |
| c_quellname | varchar(256) | Nein | Der Quellname (abhängig je Transfer-Typ) wo die Daten exportiert oder von wo die Daten importiert werden sollen. Dies kann ein Dateiname (mit eventuellen Platzhaltern) oder auch eine URL sein. Mögliche Platzhalter: • ZEITSTEMPEL_STR1 (Format: “yyyyMMddHHmmss) • @@IMPORT_ZEITSTEMPEL@@ • @@IMPORT_FILE_NAME@@ • Felderinhalte können mit @@FELD_NAME@@ ebenfalls verwendet werden |
| c_typ | varchar(1) | Ja | Steuert ob Daten aus dem Kieselstein ERP oder ins Kieselstein ERP importiert werden sollen: • I = Import • E = Export |
| i_daten_modus | smallint | Ja | Steuert ob alle betreffende Datensätze, oder nur welche die sich seit dem letzten Schnittstellenlauf geändert haben, exportiert werden sollen: • 1 = Alle Datensätze • 2 = Nur geänderte Datensätze |
| c_format | varchar(5) | Ja | Das Format in welches die Daten exportiert bzw. importiert werden sollen: • XML • CSV (Beta-Status) |
| c_bereich | varchar(32) | Ja | Der Bereich steuert welche Daten behandelt werden sollen: FERT_TRUMPF_SOLL_MATERIAL Nur Soll-Materialien welche bei der Artikelklasse das TOPS Kennzeichen gesetzt haben. (Nur Export) WW_ARTIKEL_TOPS Nur Artikel welche bei der Artikelklasse das TOPS Kennzeichen gesetzt haben. (Import & Export) FERT_TRUMPF_PROD_ORDER Aktualisiert die Export-Ende Informationen für das Los-Soll-Material. (Nur Import) WW_ARTIKEL_TRU_TOPS_LOG Aktualisiert die Gestehungspreise und Geometriedaten für die Los-Soll-Materialien. (Nur Import) |
| i_sort | integer | Ja | Bestimmt die Reihenfolge in welcher die Schnittstellen mit den selben Auslöser abgearbeitet werden sollen. |
| c_bezeichnung | varchar(64) | Ja | Bezeichnung der Datenstruktur, welche auch als Anzeige im Client dient |
| i_nachverarbeitung_modus | smallint | Nein | Steuert beim Importieren von Dateischnittstellen wie die importierten Dateien behandelt werden sollen: • 0 = Keine Aktion • 1 = Importierte Datei löschen • 2 = Importierte Datei umbenennen (Wenn der Import erfolgreich war wird die Endung „.bak“ hinzugefügt, in einem Fehlerfall wird die Endung „.error“ hinzugefügt) |
| b_aktiv | boolean | Ja | Damit kann die Blech-Laser-Daten-Schnittstelle aktiviert oder deaktiviert werden. |
| personal_i_id_anlegen | integer | Ja | ID des Benutzers, der/die den Parameter erstellt hat |
| personal_i_id_aendern | integer | Ja | ID des Benutzers, der/die den Parameter zuletzt geändert hat |
| t_anlegen | timestamp | Ja | Zeitpunkt der Erstellung des Parameters |
| t_aendern | timestamp | Ja | Zeitpunkt der letzten Änderung des Parameters |
Wichtig: Wenn “Shop Timer” als Auslöser gewählt wird, gibt es im Tab “Automatik” für Export und Import 2 getrennte Parameter (Import Schnittstellen und Export Schnittstellen) um die Intervalle zu setzen.
Logging der Blech-Laser-Daten-Schnittstelle (lp_sst_lauf)
Jedes Mal, wenn ein Schnittstelleneintrag durch einen bestimmten Auslöser (Shop-Timer, Los-Ausgabe oder Rest-Endpunkt) gestartet wird, wird ein Loggingeintrag erstellt.
Am Ende wird ein Endzeitpunkt und der jeweilige Status gesetzt. Im Fehlerfall wird zusätzlich eine Fehlermeldung mitgeloggt.
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | int | Ja | Fortlaufende ID |
| sst_i_id | int | Ja | Referenz auf eine BLDS (SST_Parameter) |
| t_zeitstempel_start | timestamp | Ja | Startzeitpunkt eines Durchlaufs einer BLDS |
| t_zeitstempel_ende | timestamp | Nein | Endzeitpunkt eines Durchlaufs einer BLDS |
| i_status | smallint | Ja | Status des Durchlaufs: 0 = STARTED 1 = FINISHED -1 = ERROR |
| i_anzahl_datensaetze | integer | Nein | Anzahl der bearbeiteten Datensätze im Lauf |
| c_fehlermeldung | text | Nein | Fehlermeldung, falls der Lauf fehlschlägt |
Datenstruktur (lp_daten_struktur)
Definiert die Struktur der Dateninhalte, einschließlich der Informationen darüber, wie die Daten zu importieren bzw. exportieren sind, im Kontext der Kieselstein-Daten.
Aktuell werden die Datenstrukturen ausschließlich für die Blech-Laser-Daten-Schnittstelle.
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | integer | Ja | Fortlaufende ID |
| c_bezeichnung | varchar(64) | Ja | Bezeichnung der Datenstruktur, welche auch als Anzeige im Client dient |
| c_bereich | varchar(32) | Ja | Definiert den Bereich (die Ziel/Quelltabellen) für den die Struktur gültig ist. • Fert-Lossollmaterial • WW-Artikel Wenn die Datenstruktur in einer BLDS verwendet wird, muss der Bereich mit diesen übereinstimmen bzw. können nur Datenstrukturen mit dem gleichen Bereich ausgewählt werden. |
| c_list_item_pfad | varchar(128) | Nein | Definiert die Item in einer XML-Datei wenn mehrer Datenzeilen in einer XML-Datei exportiert werden sollen, welches der Elternknoten ist. Also wo alle Datensätze wiederholt werden sollen. |
| c_default_datum_format | varchar(32) | Ja | Die Formatmaske die für alle Datumswerte aller zugewiesenen Datenstrukturfelder als Default für eine Umwandlung von bzw. in einen Text verwendet wird. Hierfür wird Java SimpleDateFormat verwendet. |
| c_default_nummer_format | varchar(16) | Nein | Die Formatmaske die für alle Zahlenwerten aller zugewiesenen Datenstrukturfelder als Default für eine Umwandlung von bzw. in einen Text verwendet wird. Hierfür wird Java String format() Method verwendet. |
| personal_i_id_anlegen | integer | Ja | ID des Benutzers, der die Datenstruktur erstellt hat |
| personal_i_id_aendern | integer | Ja | ID des Benutzers, der zuletzt die Datenstruktur geändert hat |
| t_anlegen | timestamp | Ja | Zeitpunkt der Erstellung der Datenstruktur |
| t_aendern | timestamp | Ja | Zeitpunkt der letzten Änderung der Datenstruktur |
Datenstrukturfeld (lp_daten_struktur_feld)
Eine Datenstruktur besteht aus beliebig vielen Datenstrukturfeldern, in denen genau definiert ist, wohin der Wert in der Dateistruktur geschrieben werden muss bzw. wo er in einer importierten Datei ausgelesen werden kann.
Alle Datenstrukturfelder einer Datenstruktur werden je nach Transfertyp (Export oder Import) in eine Datei geschrieben oder aus einer Datei gelesen.
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | integer | Ja | Fortlaufende ID |
| struktur_daten_i_id | integer | Ja | Referenz auf die Datenstruktur |
| c_erp_feld | varchar(64) | Nur wenn kein ‘c_fix_wert’ gesetzt ist | Für eine Export-Schnittstelle: der Wert welcher exportiert werden soll. Für eine Import-Schnittstelle: in welches Feld der Kieselstein ERP Datenbank geschrieben wird bzw. wie der Wert interpretiert werden soll. Welche Felder hier zur Verfügung stehen ist durch den Bereich der Struktur und den Transfertyp der verknüpften BLDS (Import / Export) definiert. |
| c_fix_wert | varchar(128) | Nur wenn kein ‘c_erp_feld’ gesetzt ist | Für eine Export-Schnittstelle: der Wert welcher exportiert werden soll wenn kein ERP-Feld definiert wurde. Für eine Import-Schnittstelle: der Wert welcher importiert werden soll, wenn in der Quelle (Beispiel XML-Datei), der Wert nicht enthalten oder leer ist. |
| c_pfad | varchar(128) | Nein | Der X-Pfad in einer XML-Datei wo sich der entsprechende Wert befindet. Der Operator “/” wird verwendet um Elemente zu verschachteln. Zum Beispiel: Test/Test2/Test3 würde in Test3 den Wert aus dem ‘c_erp_feld’ beim Export eintragen und bei Import auslesen. |
| c_attribut_name | varchar(128) | Nein | Wenn der Wert als XML exportiert bzw. importiert werden soll, kann hier ein Attributename definiert werden, welcher sich auf die Daten bezieht. |
| i_sort | integer | Ja | Sortierposition des Datenstrukturfeldes innerhalb der Datenstruktur. |
| c_format_maske | varchar(32) | Nein | Pro Datenstrukturfeld kann die in der Datenstruktur definierte globale Formatmaske (c_default_datum_format oder c_default_nummer_format) überschrieben werden. Diese spezifische Formatmaske wird für die Umwandlung von bzw. in einen Text verwendet, anstatt die globale Formatmaske. |
| mapping_i_id | integer | Nein | Eine Referenz auf ein Mapping, das steuert, wie ein Quellwert in einen Zielwert übersetzt werden kann. Ein Beispiel hierfür wäre die Umwandlung von Fehlercodes in menschenlesbare Texte. |
| personal_i_id_anlegen | integer | Ja | ID des Benutzers, der dieses Feld erstellt hat |
| personal_i_id_aendern | integer | Ja | ID des Benutzers, der dieses Feld zuletzt geändert hat |
| t_anlegen | timestamp | Ja | Zeitpunkt der Erstellung des Feldes |
| t_aendern | timestamp | Ja | Zeitpunkt der letzten Änderung des Feldes |
Mapping (lp_mapping)
Die Mapping-Klasse ist eine Containerklasse mit einem sprechenden Namen (c_bezeichnung), zu der beliebig viele Mappingwerte verknüpft werden können. Eine Mapping-Klasse kann auch für mehrere Datenstrukturfelder verwendet werden, was sie besonders flexibel macht.
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | integer | Ja | Fortlaufende ID |
| c_bezeichnung | varchar(64) | Ja | Bezeichnung des Mappings, welche auch als Anzeigename dient |
| personal_i_id_anlegen | integer | Ja | ID des Benutzers, der das Mapping erstellt hat |
| personal_i_id_aendern | integer | Ja | ID des Benutzers, der das Mapping zuletzt geändert hat |
| t_anlegen | timestamp | Ja | Zeitpunkt der Erstellung des Mappings |
| t_aendern | timestamp | Ja | Zeitpunkt der letzten Änderung des Mappings |
Mappingwerte (lp_mapping_wert)
Pro Datenstrukturfeld kann eine Mapping-Container-Klasse (1) verknüpft werden. Die eigentlichen Mappingwerte pro Feld sind in den beliebig vielen Mappingwerte-Einträgen zu finden.
| Feldname | Datentyp | Pflichtfeld | Bezeichnung |
|---|---|---|---|
| i_id | integer | Ja | Fortlaufende ID |
| mapping_i_id | integer | Ja | Referenz auf das Mapping |
| c_quellwert | varchar(64) | Ja | Quellwert, der im Rahmen des Mappings ersetzt werden soll. |
| c_zielwert | varchar(128) | Ja | Zielwert, der im Rahmen des Mappings den ‘c_quellwert’ ersetzt. |
| personal_i_id_anlegen | integer | Ja | ID des Benutzers, der das Mapping-Wert erstellt hat |
| personal_i_id_aendern | inte ger | Ja | ID des Benutzers, der das Mapping-Wert zuletzt geändert hat |
| t_anlegen | timestamp | Ja | Zeitpunkt der Erstellung des Mapping-Werts |
| t_aendern | timestamp | Ja | Zeitpunkt der letzten Änderung des Mapping-Werts |
Beispiel
Ein Beispiel wie alle Material-Nummern eines Loses als Los-Soll-Materialien hinterlegt werden.
Struktur:
INSERT INTO public.lp_daten_struktur(i_id, c_bezeichnung, c_bereich, c_list_item_pfad, c_default_datum_format, c_default_nummer_format, personal_i_id_anlegen, personal_i_id_aendern, t_anlegen, t_aendern) VALUES
(11, 'Los-Materialien', 'fert_lossollmaterial', 'Materialliste/Daten', NULL, NULL, 11, 11, '2025-01-09 12:51:11.581', '2025-01-09 12:51:11.581');
Struktur Felder:
INSERT INTO public.lp_daten_struktur_feld(i_id, struktur_daten_i_id, c_erp_feld, c_fix_wert, c_pfad, c_attribut_name, i_sort, c_format_maske, personal_i_id_anlegen, personal_i_id_aendern, t_anlegen, t_aendern, mapping_i_id) VALUES
(11, 11, 'LOS_ID', NULL, 'Materialliste/Los/Id', NULL, 1, NULL, 11, 11, '2025-01-15 11:53:24.295', '2025-01-15 11:53:24.295', NULL),
(12, 11, 'LOS_CNR', NULL, 'Materialliste/Los/CNr', NULL, 1, NULL, 11, 11, '2025-01-15 11:53:24.301', '2025-01-15 11:53:24.301', NULL),
(13, 11, 'ARTIKEL_CNR', NULL, 'Materialliste/Daten/Material/CNr', NULL, 2, NULL, 11, 11, '2025-01-15 11:53:24.306', '2025-01-15 11:53:24.306', NULL),
(14, 11, 'ARTIKEL_BEZEICHNUNG', NULL, 'Materialliste/Daten/Material/Caption', NULL, 2, NULL, 11, 11, '2025-01-15 11:53:24.306', '2025-01-15 11:53:24.306', NULL);
Ergebnis als XML-Datei:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Materialliste>
<Los\>
<Id\>16</Id>
<CNr>25/0000003</CNr>
</Los\>
<Daten>
<Material>
<Cnr>25711</Cnr>
<Caption\>Artikel Seitenblech 1</Caption\>
</Material>
<Material>