Generator für fortlaufende IDs mit jährlicher Rücksetzung – Unterstützung mehrerer Präfixe

In diesem Artikel erläutert Tamás, einer unserer Bibliotheksentwickler, die Entwicklungsentscheidungen hinter der in der Bibliothek verfügbaren Baustein-App „Yearly Resetting Sequential ID Generator – Multi-Prefix Support“.

Warum ich ihn so entwickelt habe

Ich habe diesen Logikblock entworfen, um ein sehr praktisches Problem zu lösen: die Generierung von IDs auf eine Weise, die zuverlässig, leicht wiederverwendbar und schnell in vielen Apps einsetzbar ist.Mein Ziel war es, dass die ID selbst alles enthält, was zur Berechnung der nächsten ID benötigt wird. Jeder Teil der ID hat eine klare Funktion:* Das Präfix gibt an, zu welcher Sequenz die ID gehört.* Das Jahr unterteilt die Sequenz zeitlich.* Die Zahl gibt die Reihenfolge innerhalb dieses Jahres an.

Aufgrund dieser Struktur musste ich keine Reset-Logik einführen. Die aktuellste vorhandene ID enthält bereits alle Informationen, die zur Generierung der nächsten ID erforderlich sind. Solange die letzte ID gültig ist, lässt sich die nächste ID stets auf vorhersehbare Weise berechnen.

Ich habe das Jahr direkt in die ID aufgenommen, da es die Datensätze auf natürliche Weise zeitlich voneinander trennt. Außerdem ermöglicht es, die Nummerierung jedes Jahr automatisch neu zu starten, ohne dass ein planmäßiger Reset oder eine manuelle Aktualisierung erforderlich ist.

Das Präfix dient als Grenze zwischen verschiedenen Sequenzen. Dadurch ist es möglich, mehrere unabhängige Nummerierungssequenzen innerhalb derselben Tabelle zu führen. Das Ändern des Präfixes bedeutet lediglich, eine andere Sequenz fortzusetzen.

Ich habe eine Validierung hinzugefügt, da der gesamte Ansatz von einer konsistenten ID-Struktur abhängt. Wenn eine vorhandene ID nicht dem erwarteten Format entspricht, könnte die Fortsetzung der Sequenz zu verwirrenden oder inkonsistenten Ergebnissen führen. Ich ziehe es vor, frühzeitig zu stoppen, das Problem sichtbar zu machen und die Generierung falscher IDs zu vermeiden.

Ich habe mich für eine konnektorbasierte Abfrage entschieden, damit der Logikblock mit verschiedenen Tabellen arbeiten kann, ohne dass die Kernlogik geändert werden muss. Sobald der Konnektor konfiguriert ist, müssen Sie nur noch die tableId und das Präfix angeben, und derselbe Logikblock kann an mehreren Stellen wiederverwendet werden.

Für mich bestand das Ziel nicht nur darin, IDs zu generieren, sondern ein wiederverwendbares Muster zu schaffen, bei dem das ID-Format selbst definiert, wie die Nummerierung funktioniert. Das sorgt dafür, dass die Logik einfach, vorhersehbar und über verschiedene Apps hinweg leicht wiederverwendbar bleibt.

Was dieser Logikblock tut

Dieser Logikblock generiert fortlaufende IDs, die jährlich zurückgesetzt werden und folgende Struktur aufweisen:Präfix + Jahr + laufende Nummer

Beispiel: TEST20240001 TEST20240002

Wenn das Jahr wechselt, beginnt die Nummerierung automatisch wieder bei 1: TEST20250001

In derselben Tabelle können mehrere Präfixe vorhanden sein. Jedes Präfix verfügt über eine eigene, unabhängige Sequenz: ORD20240001 ORD20240002 INV20240001 INV20240002

Der Logikblock gewährleistet: * ein einheitliches ID-Format * einen automatischen jährlichen Reset * eine unabhängige Nummerierung pro Präfix * die frühzeitige Erkennung fehlerhafter historischer IDs * die frühzeitige Erkennung von numerischen Überläufen

Warum der Konnektor Teil des Designs ist

Bevor die nächste ID generiert wird, benötigt der Logikblock die aktuellste vorhandene ID für das jeweilige Präfix. Der Konnektor führt eine gefilterte Suche durch:* Datensätze filtern, bei denen die ID mit dem Präfix beginnt* absteigend nach _sequenceNumber sortieren* den aktuellsten Datensatz zurückgeben

Da das Präfix Teil des Filters ist, verfügt jedes Präfix selbst innerhalb derselben Tabelle über einen eigenen Laufzähler. Dadurch bleiben die Sequenzen isoliert und vorhersehbar.

Wie der Build aufgebaut ist

Die eigentliche Implementierung verwendet drei Trigger. Diese Struktur ist beabsichtigt. Ich wollte, dass der Logikblock von oben nach unten leicht nachzuvollziehen ist, während die Hauptlogik dennoch separat und wiederverwendbar bleibt. Anstatt die Logik also auf viele bearbeitbare Trigger zu verteilen, habe ich sie in drei Phasen gegliedert:1. USER CONFIG: EINGABEPHASE 2. MAGIC – Validierung + ID-Generierung 3. USER CONFIG: AUSGABEPHASE

Dies sorgt für ein gutes Gleichgewicht zwischen Benutzerfreundlichkeit und Kontrolle.* Im ersten Trigger definieren Sie die Eingaben.* Der zweite Trigger enthält die interne Logik, die normalerweise nicht bearbeitet werden muss, damit der Logikblock funktioniert.* Im dritten Trigger legen Sie fest, was mit dem generierten Ergebnis geschehen soll.

Das bedeutet, dass man normalerweise nicht im Trigger der Kernlogik arbeiten muss. Es müssen lediglich die Eingangs- und die Ausgangsseite konfiguriert werden. Das war eine der wichtigsten Entwurfsentscheidungen: den Logikblock wiederverwendbar zu machen, indem nur die Teile offen gelegt werden, die üblicherweise geändert werden müssen.

Trigger 1 – BENUTZERKONFIGURATION: EINGABESTUFE

Dies ist der erste Trigger, mit dem Sie interagieren. Sein Zweck besteht darin, die Eingabewerte zu definieren, die der Logikblock benötigt, bevor eine ID generiert werden kann. In der Praxis wird dieser Trigger verwendet, um Folgendes zu definieren:* Das Präfix: _configPrefix* Die ID-Länge: _configIdNumberFormat* Die an den Konnektor übergebene Tabellen-ID: tableId

Was die einzelnen Werte bedeuten

_configPrefix: Diesist der Text, der an den Anfang jeder generierten ID gesetzt wird. Damit legen Sie fest, welche Sequenz generiert werden soll.

Beispiele:* ORD* INV* TEST

Wenn _configPrefix = ORD ist, berücksichtigt der Logikblock nur vorhandene IDs, die mit ORD beginnen, und setzt ausschließlich diese Sequenz fort. Dieser Wert erfüllt also zwei Funktionen gleichzeitig:* Er definiert das sichtbare Präfix in der endgültigen ID.* Er legt fest, welche historischen IDs der Konnektor als Quelle für die nächste Nummer verwenden soll

Das bedeutet, dass unterschiedliche Präfixe in derselben Tabelle unterschiedliche Sequenzen erzeugen**._configIdNumberFormat**

Hiermit wird die Länge des numerischen Teils der ID festgelegt. Sie legen diesen Wert als mit Nullen aufgefüllte Zeichenfolge fest. Beispiele:000000000000000000

Die Anzahl der Nullen bestimmt die Breite des numerischen Teils.

Beispiele:0000 → 0001, 0002, 0003 … 9999 000000 → 000001, 000002 … 999999

Dieser Wert legt nicht die tatsächliche Zahl fest. Er definiert das Format, in das die Zahl passen muss. Ich verwende ihn für zwei Zwecke: * um der generierten Zahl führende Nullen hinzuzufügen * um zu überprüfen, ob die nächste Zahl noch in die zulässige Länge passt

tableId

Dies legt fest, welche Tabelle der Connector abfragen soll.

In der Praxis sorgt dies dafür, dass der Logikblock für verschiedene Tabellen wiederverwendbar ist. Sie können denselben Logikblock kopieren und auf eine andere Tabelle verweisen, indem Sie lediglich diesen Wert im Konfigurationstrigger ändern.

Der Logikblock durchsucht die Tabellen nicht selbst. Er übergibt „tableId“ und „_configPrefix“ an den Konnektor, und der Konnektor gibt die aktuellste passende ID aus dieser Tabelle zurück.

So werden sie gemeinsam verwendet

Diese drei Werte legen gemeinsam das Verhalten des Generators fest:* „tableId“ teilt dem Logikblock mit, wo er suchen soll* „_configPrefix“ gibt an, welche Sequenz fortgesetzt werden soll* „_configIdNumberFormat“ legt fest, wie der numerische Teil aussehen soll

Praktische Hinweise zur Einrichtung

Achten Sie bei der Konfiguration des Logikblocks darauf, dass:* „tableId“ auf die richtige Tabelle verweist* „_configPrefix“ mit dem Präfix übereinstimmt, das Sie fortsetzen möchten* „_configIdNumberFormat“ der gewünschten Ziffernlänge entspricht

Wenn Sie das Präfix ändern, setzen Sie die alte Sequenz nicht mehr fort. Sie beginnen oder setzen eine andere präfixspezifische Sequenz fort. Wenn Sie die Länge des Zahlenformats später erhöhen, erwartet der Logikblock dieses breitere Format bei der Validierung bestehender IDs in diesem Tabellen- und Präfixbereich.Der Konnektor ruft die aktuellste ID ab, die dem Präfix entspricht, und speichert sie in _stateLastId. Falls noch keine ID vorhanden ist, stellt LINK() sicher, dass der Generator dennoch die erste gültige ID erzeugen kann.

Warum der Konnektor Teil des Designs ist

Der Konnektor ist nicht nur ein technisches Detail. Er ist Teil der Wiederverwendungsstrategie. Ich verwende den Konnektor, um die aktuellste vorhandene ID aus der Zieltabelle auszulesen. Der Konnektor erhält die Tabellen-ID als Eingabe, wendet den Präfixfilter an, sortiert die Datensätze nach _sequenceNumber in absteigender Reihenfolge und gibt den aktuellsten passenden Datensatz zurück.

Dies ist aus zwei Gründen wichtig.

Erstens ermöglicht es dem Logikblock, die Nummerierung ausgehend vom tatsächlichen Zustand der Tabelle fortzusetzen.

Zweitens lässt sich der Logikblock dadurch viel einfacher wiederverwenden. Wenn Sie die Schaltfläche in eine andere App kopieren, müssen Sie die Logik nicht neu schreiben. Sie müssen lediglich den Konnektor auf die richtige Tabelle verweisen und die erforderliche Konfiguration vornehmen. Dies ist das praktische Muster hinter der Erstellung:* Erstellen Sie die Schaltfläche einmal* Legen Sie die Tabelleneingabe im Konnektor fest* Definieren Sie das Präfix und das Zahlenformat* Verwenden Sie sie bei Bedarf wieder

Das war eine bewusste Entscheidung, um eine schnellere App-Erstellung zu ermöglichen.

Was macht der Konnektor im Logikblock?

Was hier geschieht:* Der Konnektor empfängt die Tabellen-ID* Der Konnektor empfängt das Präfix* Der Konnektor filtert Datensätze nach dem Präfix* Der Konnektor sortiert Datensätze nach _sequenceNumber in absteigender Reihenfolge* Der Konnektor gibt die aktuellste übereinstimmende ID zurück

Der Konnektor unterstützt außerdem einen sehr wichtigen Anwendungsfall: mehrere Entitäten in derselben Tabelle.

Wenn dieselbe Tabelle Datensätze wie die folgenden enthält: ORD20240001 MAT20240011

dann sollte der Logikblock diese nicht als eine gemeinsame Sequenz behandeln. Jedes Präfix sollte erst ab seinem eigenen aktuellsten Wert fortgesetzt werden.

Daher filtert der Konnektor zunächst nach Präfix. Das bedeutet, dass die nächsten Werte wie folgt lauten: ORD → ORD20240002, MAT → MAT20240012

Ich habe mich für dieses Modell entschieden, da verschiedene Entitäten in derselben Tabelle vorkommen können, was jedoch nicht bedeutet, dass sie dieselbe fortlaufende Nummer teilen sollten.

Eine Anforderung an die Einrichtung sollte ebenfalls klar erwähnt werden: Der Konnektor benötigt eine Authentifizierung, daher muss ein Token generiert und den Authentifizierungseinstellungen des Konnektors hinzugefügt werden. Ich betrachte dies als Einrichtungsaufwand und nicht als Teil der Logik des Logikblocks selbst, aber es ist dennoch ein wichtiger Schritt, um den Logikblock nutzbar zu machen.

Trigger 2 – MAGIC: Validierung + ID-Generierung

Dieser Trigger bildet die Kernlogik des Logikblocks. Er führt nacheinander drei Schritte aus: 1. prüft, ob die letzte übereinstimmende ID die erwartete Struktur aufweist; 2. prüft, ob die nächste Nummer noch in die konfigurierte numerische Länge passt; 3. generiert die nächste ID

Ich habe diese Schritte in einem Trigger zusammengefasst, da sie zum selben Entscheidungsablauf gehören. Bevor ich eine neue ID erstelle, möchte ich drei Fragen beantworten: * Ist die vorherige ID strukturell sicher in der Verwendung? * Würde die nächste Zahl noch in das Format passen? * Wenn ja, wie sollte die nächste ID lauten?

Formatvalidierung

Expression

REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + DATETIMETOTEXT(App info.Current Date and Time, 'YYYY') + Variable._configIdNumberFormat), '^' + Variable._configPrefix + '[0-9]{4}' + '[0-9]{' + LEN(Variable._configIdNumberFormat) + '}$','ok')

Was diese „ expression “ bewirkt

Dieser expression prüft, ob die aktuellste ID genau der Struktur entspricht, die der Logikblock erwartet. Er arbeitet in folgender Reihenfolge: 1. LINK(...) übernimmt Variable._stateLastId.id, wenn der Konnektor einen Wert zurückgegeben hat. 2. Falls noch keine ID vorhanden ist, verwendet LINK(...) einen Fallback-Wert, der wie folgt aufgebaut ist: * Variable._configPrefix * DATETIMETOTEXT(...,'YYYY') * Variable._configIdNumberFormat3. Dieser Fallback-Wert wird einbezogen, damit die Validierung auch dann eine gültige Struktur zur Auswertung hat, wenn es sich um die erste generierte ID handelt.4. Variable._configPrefix definiert das genaue Präfix, mit dem die ID beginnen muss.5. DATETIMETOTEXT(...,'YYYY') wird nicht als Übereinstimmungswert innerhalb des regulären Ausdrucks selbst verwendet, ist aber Teil der Fallback-Struktur, damit der Fallback wie eine echte ID-Form aussieht.6. LEN(Variable._configIdNumberFormat) legt fest, wie viele Ziffern der numerische Teil enthalten muss.7. REGEX_REPLACE(...) prüft dann die gesamte Zeichenfolge anhand dieses Musters: * Präfix * genau 4 Ziffern für das Jahr * genau N Ziffern für den numerischen Teil8. Wenn die gesamte Zeichenfolge übereinstimmt, wird der gesamte Wert durch „ok“ ersetzt.9. Wenn keine Übereinstimmung vorliegt, bleibt der ursprüngliche Wert unverändert.10. Der Trigger prüft anschließend, ob das Ergebnis mit „ok“ übereinstimmt. Ist dies nicht der Fall, wird die Ausführung beendet.

Dieser „ expression “ extrahiert also keine Werte für Berechnungen. Seine Aufgabe besteht darin, zu überprüfen, ob die ID die erwartete Struktur aufweist, bevor numerische Logik angewendet wird.

Warum ich mich dafür entschieden habe

Ich habe mich dafür entschieden, die vollständige ID-Struktur zu validieren, bevor numerische Logik angewendet wird. Ich habe es so aufgebaut, weil der Rest des Triggers feste Positionen voraussetzt:* Präfix am Anfang* Jahr unmittelbar nach dem Präfix* Zahl unmittelbar nach dem Jahr

Wenn die vorherige ID dieser Konvention nicht entspricht, wäre eine Inkrementierung ausgehend von ihr unzuverlässig.

Außerdem habe ich mich dafür entschieden, hier den Fallback LINK(...) einzubauen, damit die erste generierte ID keine separate Validierungslogik benötigt. Der gleiche Validierungspfad funktioniert unabhängig davon, ob eine ältere ID existiert oder nicht. Ich breche den Trigger absichtlich ab, anstatt zu versuchen, fehlerhafte IDs zu reparieren. Eine automatische Korrektur würde Datenprobleme verschleiern und könnte eine Sequenz erzeugen, die zwar gültig aussieht, aber auf falschen Eingaben basiert.

Überlaufschutz

Expression

LEN(IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat), LEN(Variable._configPrefix), 4) = DATETIMETOTEXT(App info.Aktuelles Datum und Uhrzeit, ‚YYYY‘), RIGHT(Variable._configIdNumberFormat + TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1), LEN(Variable._configIdNumberFormat)), RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat))))

Was diese „ expression “ bewirkt

Diese „ expression “ berechnet, wie der nächste numerische Teil lauten würde, und ermittelt anschließend dessen Länge. Sie funktioniert in folgender Reihenfolge: 1. LINK(...) verwendet die letzte ID, sofern vorhanden. Ist dies nicht der Fall, greift sie auf „Variable._configPrefix + Variable._configIdNumberFormat“ zurück. 2. MID(..., LEN(Variable._configPrefix), 4) liest die 4 Zeichen unmittelbar nach dem Präfix aus. Diese werden als Jahresteil der vorherigen ID behandelt. 3. DATETIMETOTEXT(...,'YYYY') liefert das aktuelle Jahr zum Vergleich. 4. IF(...) entscheidet, ob der numerische Teil fortgesetzt oder zurückgesetzt werden soll: * gleiches Jahr → inkrementieren * anderes Jahr → bei 15 beginnen. Im Inkrement-Zweig entfernt REGEX_REPLACE(...) das Präfix und die vierstellige Jahreszahl vom Anfang der vorherigen ID, sodass nur der numerische Teil übrig bleibt.6. TEXTTOINTEGER(...) + 1 wandelt diesen numerischen Text in eine Zahl um und erhöht ihn um 1.7. TOTEXT(...) wandelt die neue Zahl wieder in Text um.8. Variable._configIdNumberFormat + ... fügt das konfigurierte Nullformat vor den Wert ein.9. RIGHT(..., LEN(Variable._configIdNumberFormat)) behält nur die erforderliche Anzahl an Ziffern bei.10. Im Reset-Zweig erzeugt RIGHT(Variable._configIdNumberFormat + '1', LEN(...)) die erste zulässige Zahl für ein neues Jahr.11. LEN(...) ermittelt die Länge des resultierenden numerischen Teils.

Der Trigger vergleicht diese Länge mit der zulässigen Länge aus „Variable._configIdNumberFormat“. Sollte der nächste numerische Teil zu lang sein, wird die Ausführung abgebrochen.

Warum ich mich dafür entschieden habe

Ich habe mich dafür entschieden, die nächste Zahl auf dieselbe Weise zu berechnen, wie die ID tatsächlich generiert wird, anstatt eine separate Formel zu verwenden, um zu erraten, wann die Zahl die zulässige Länge überschreiten würde.

Ich habe es so aufgebaut, weil ich wollte, dass die Überlaufprüfung genau denselben Regeln folgt wie die tatsächliche ID-Generierung. Das verringert die Wahrscheinlichkeit, dass die Validierungslogik und die Generierungslogik später auseinanderdriften.

An dieser Stelle anzuhalten ist sicherer, als fortzufahren. Wenn der nächste numerische Wert nicht mehr in die konfigurierte Länge passt, würde die resultierende ID die von Ihnen konfigurierte Struktur verletzen.

Wenn das Zahlenformat beispielsweise 0000 lautet, ist 9999 gültig, 10000 jedoch nicht. Ich möchte, dass der Logikblock dies vor der Erstellung des Datensatzes erkennt, nicht erst danach.

Logik zur ID-Generierung

Expression

Variable._configPrefix + DATETIMETOTEXT(App info.Aktuelles Datum und Uhrzeit, 'YYYY') + IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat), LEN(Variable._configPrefix), 4) = DATETIMETOTEXT(App-Info.Aktuelles Datum und Uhrzeit, 'YYYY'), RIGHT(Variable._configIdNumberFormat + TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1), LEN(Variable._configIdNumberFormat)), RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat)))

Was diese „ expression “ bewirkt

Dies ist der „ expression “, der die endgültige ID bildet. Er arbeitet in folgender Reihenfolge: 1. „Variable._configPrefix“ fügt das konfigurierte Präfix am Anfang der ID hinzu. 2. „DATETIMETOTEXT(App info.Current Date and Time, 'YYYY')“ fügt das aktuelle vierstellige Jahr hinzu. 3. LINK(...) verwendet die letzte vom Connector zurückgegebene ID, sofern vorhanden. Wenn der Connector keine ID zurückgibt, wird „Variable._configPrefix + Variable._configIdNumberFormat“ als Ausweichstruktur verwendet. 4. MID(..., LEN(Variable._configPrefix), 4) liest die 4 Zeichen unmittelbar nach dem Präfix aus. Diese werden als Jahresteil der vorherigen ID behandelt.5. DATETIMETOTEXT(...,'YYYY') wird hier erneut verwendet, damit der „ expression “ entscheiden kann, ob die vorherige ID zum aktuellen Jahr gehört.6. IF(...) steuert die beiden möglichen Pfade: * dasselbe Jahr → Nummerierung fortsetzen * anderes Jahr → auf 17 zurücksetzen.7. Im Zweig „gleiches Jahr“ entfernt REGEX_REPLACE(...) das Präfix und die vierstellige Jahreszahl vom Anfang der vorherigen ID, sodass nur der numerische Teil übrig bleibt.8. TEXTTOINTEGER(...) + 1 ** erhöht diesen numerischen Wert um 1.9. TOTEXT (...) wandelt den erhöhten Wert wieder in Text um.10. Variable._configIdNumberFormat + ... fügt das konfigurierte Null-Format vor den neuen Wert ein.11. RIGHT (..., LEN(Variable._configIdNumberFormat)) behält nur die erforderliche Anzahl an Ziffern bei, sodass der numerische Teil immer eine feste Länge hat.12. Im Reset-Zweig erzeugt RIGHT (Variable._configIdNumberFormat + '1', LEN(...))** die erste Zahl einer neuen jährlichen Sequenz.13. Das Präfix, das aktuelle Jahr und die formatierte Zahl werden zur endgültigen ID verkettet.

Die endgültige Ausgabe hat also immer folgende Struktur:Präfix + Jahr + Zahl mit fester Länge

Warum ich mich dafür entschieden habe

Ich habe mich dafür entschieden, die nächste ID vollständig aus der aktuellsten tatsächlichen ID in der Tabelle abzuleiten. Ich habe es so aufgebaut, weil die vorherige ID bereits alles enthält, was die Logik benötigt:* zu welchem Präfix die Sequenz gehört* zu welchem Jahr sie gehört* wie der letzte numerische Wert lautete

Das bedeutet, dass ich keine separate Zählertabelle, kein gespeichertes Jahresfeld und keinen planmäßigen jährlichen Reset benötige.

Außerdem habe ich mich für eine Formatierung mit fester Länge entschieden, da dies die Struktur vorhersehbar und die Validierung einfacher macht.

Der Nachteil ist, dass die „ expression “ von einer strengen ID-Struktur abhängt. Deshalb erfolgt der Validierungsschritt an erster Stelle. Ich habe diesen Kompromiss in Kauf genommen, da ein strenger und lesbarer Vertrag hier nützlicher ist, als zu versuchen, viele lose Eingabeformate zu unterstützen.

Trigger 3 – USER CONFIG: OUTPUT STAGE

Dies ist der letzte Trigger im Logikblock. Sein Zweck besteht darin, zu definieren, was mit der generierten ID geschehen soll, sobald _stateOutput einen gültigen Wert enthält.

Wichtig ist hierbei, dass diese Phase bewusst offen für Sie gelassen wurde.

Wenn _stateOutput nicht leer ist, können Sie entscheiden, was der Logikblock als Nächstes tun soll. In der aktuellen Konfiguration zeigt der Trigger eine Hinweismeldung an, die die nächsten Schritte erklärt: * Fügen Sie die konfigurierte Tabelle zur App hinzu * Ersetzen Sie den Schritt „Nachricht“ durch einen Trigger „Datensatz erstellen“ * Verwenden Sie _stateOutput als neue Datensatz-ID

Ich habe es so aufgebaut, da das Ausgabeverhalten je nach Anwendungsfall variieren kann.

Möglicherweise möchten Sie:* sofort einen Datensatz anlegen* die ID zunächst in einer anderen Variablen speichern* die ID in einem längeren Workflow verwenden* zusätzliche Bedingungen überprüfen, bevor Sie in die Tabelle schreiben

Anstatt ein festes Ausgabeverhalten festzulegen, habe ich die Ausgabestufe konfigurierbar gehalten.

Deshalb gibt es an beiden Enden des Logikblocks eine für den Benutzer sichtbare Konfiguration:* Die Eingabestruktur ist konfigurierbar* Das Ausgabeverhalten ist konfigurierbar* Die Kernlogik bleibt in der Mitte

Vorgehensweise bei der Variablennamensgebung

Interne Variablen verwenden ein Unterstrich-Präfix:* _configPrefix* _configIdNumberFormat* _stateLastId* _stateOutput

Dies hilft Ihnen, schnell zwischen Konfigurationswerten und internen Verarbeitungsvariablen zu unterscheiden.

Entwurfsgrenzen

Der Logikblock geht von folgender Struktur aus:Präfix + Jahr + Nummer. Jedes Präfix verfügt über eine eigene, unabhängige Nummernfolge.

Der Logikblock unterstützt keinen gemeinsamen Zähler für mehrere Präfixe.

Werden das Jahr oder die numerischen Teile innerhalb der ID verschoben, muss die „ expressions “ entsprechend angepasst werden.

Zusammenfassung der Entwurfsentscheidungen

Wenn ich den gesamten Logikblock auf die ihm zugrunde liegenden Kernentscheidungen reduziere, sind dies folgende:* Ich wollte eine schnelle Wiederverwendbarkeit, daher ist der Logikblock konfigurationsgesteuert.* Ich wollte, dass die Tabelle die „Quelle der Wahrheit“ ist, daher basiert die nächste ID immer auf dem neuesten tatsächlichen Datensatz.* Ich wollte, dass die Logik wartbar bleibt, daher ist die Berechnung an einer Stelle zentralisiert.* Ich wollte, dass mehrere Entitäten in einer Tabelle sauber zusammenarbeiten, daher hat jedes Präfix seine eigene unabhängige Sequenz.* Ich wollte, dass die ID-Struktur über die Zeit hinweg konsistent bleibt, daher ist das Jahr Teil der ID und die Sequenz wird automatisch zurückgesetzt, wenn das Jahr wechselt.* Ich wollte die Tabelle vor fehlerhaften Mustern schützen, daher verhindern Formatvalidierung und Überlaufprüfungen falsche IDs, bevor ein Datensatz angelegt wird.* Ich wollte, dass der Ablauf des Triggers lesbar bleibt, daher sind die Aufgaben in klare Schritte unterteilt: Konfiguration, Validierung, Generierung, Ausgabe.

Deshalb sieht der Logikblock so aus, wie er aussieht. Er ist nicht nur ein ID-Generator. Es handelt sich um ein wiederverwendbares Muster für die kontrollierte ID-Erstellung, das versucht, Einfachheit, Wiederverwendbarkeit und Datenschutz in Einklang zu bringen und gleichzeitig die jährliche Segmentierung direkt in die Struktur der ID zu integrieren.

Machen Sie mit

Treten Sie der Community bei, um Verbesserungen zu teilen, zusätzliche Einheiten vorzuschlagen, Probleme zu melden oder architektonische Entscheidungen zu diskutieren.