Die realen Geschäftsobjekte werden im Schema als Entitäten abgebildet, welche auf physische Tabellen referenzieren. Wir unterscheiden dabei zwischen eigenständigen Hauptobjekten, wie einem Patienten oder einem Arzt, und abhängigen Unterobjekten, wie einer einzelnen Blutdruckmessung innerhalb einer Behandlungsakte. Die Eigenschaften dieser Objekte werden als Attribute definiert. Eine technische Besonderheit bilden virtuelle Attribute, deren Werte nicht physisch in der Datenbank gespeichert, sondern zur Laufzeit dynamisch berechnet werden. Die tagesaktuelle Aufenthaltsdauer eines Patienten ist ein solches virtuelles Attribut, das bei jedem Aufruf live aus dem Aufnahmedatum errechnet wird und somit niemals veralten kann.

Um redundante Definitionen zu vermeiden, unterstützt das Schema eine echte objektorientierte Vererbung. So kann eine allgemeine Basis-Entität wie „Medizinisches Ereignis“ grundlegende Attribute wie das Datum und den behandelnden Arzt zentral vorgeben. Konkrete Entitäten wie „Operation“ oder „Visite“ erben von dieser Basis und erweitern sie lediglich um ihre jeweils spezifischen Fachfelder. Ist eine Basis-Entität im Schema als „abstrakt“ markiert, dient sie rein der Vererbung und kann vom Anwender nicht als eigenständiger Datensatz angelegt werden.

Aus Gründen der Nachvollziehbarkeit und Compliance, die besonders bei Behandlungsdaten essenziell sind, löscht MyTISM Datensätze standardmäßig nicht physisch. Löscht ein Anwender ein Objekt über die Benutzeroberfläche, wird dieses über das sogenannte Soft-Delete-Verfahren (Ldel) in der Datenbank lediglich als unsichtbar markiert. Ein unwiderruflicher Hard-Delete, der die Daten physisch von der Festplatte tilgt, erfolgt erst durch automatisierte Hintergrunddienste nach Ablauf definierter Aufbewahrungsfristen.

Entitäten existieren im System selten isoliert, sondern sind über Relationen miteinander verknüpft. Die Architektur erzwingt dabei bidirektionale Beziehungen. So ist jederzeit auswertbar, welche Medikamente ein bestimmter Patient aktuell erhält und umgekehrt, welchen Patienten ein bestimmtes Medikament verabreicht wurde. Die Anwendungsarchitektur ist zudem konsequent modular aufgebaut, sodass fachliche Erweiterungen – wie etwa ein integriertes IT-Ticketsystem – als gekapselte Module an das Kernschema angedockt werden können.

Für Ausfallsicherheit und mobile Einsätze bietet das System eine tiefgreifende Offline-Fähigkeit. Der Laptop eines Notarztes im Rettungswagen kann durch eine lokale MyTISM-Instanz völlig autark betrieben werden. Sobald das Gerät wieder über eine Netzwerkverbindung zum Hauptsystem verfügt, synchronisiert der Client alle erfassten Offline-Daten vollautomatisch mit dem zentralen Server.

Die Datenmodelle wachsen in Enterprise-Projekten erfahrungsgemäß schnell zu komplexen Netzwerken heran. Ein einzelner Patient ist mit Aufnahmen verknüpft, diese wiederum mit Behandlungen, Diagnosen und Medikamenten, welche ihrerseits feingranulare Dosierungsanweisungen enthalten. Um bei solch tief verschachtelten Informationsbäumen den Überblick zu behalten, stellt das Framework für Power-User und Fachadministratoren das Werkzeug entityTool bereit. Dieses Tool generiert aus dem aktuellen Zustand eines laufenden Servers heraus eine interaktive, grafische Visualisierung des gesamten Schemas. Die Darstellung kann bequem im Web-Browser betrachtet und durchsucht werden. Sie dient als essenzielle Arbeitsgrundlage, um komplexe Lesezeichen-Filter oder Auswertungen über mehrere Relationen hinweg fehlerfrei zu konzipieren.

Die visuelle Positionierung von Formularen im Navigationsbaum des Clients wird über das <Folder>-Tag gesteuert. Dieses Tag wirkt sich auf alle nachfolgenden Deklarationen aus, bis ein neues <Folder>-Tag definiert wird.

Die visuelle Repräsentation eines Objekts in der Software wird primär über das <ui>-Tag der jeweiligen Entität gesteuert. Das Attribut description definiert hierbei, wie das Objekt in Suchfeldern und Listen als lesbarer Text formatiert wird.

Das Verhalten einzelner Eingabefelder (<attr>) lässt sich über sogenannte UI-Tipps detailliert justieren. Um ein mehrzeiliges Textfeld anstelle eines standardmäßigen, einzeiligen Eingabefeldes zu erzwingen, wird der UI-Tipp Area verwendet.

Bei booleschen Entscheidungen (Ja/Nein) erlaubt die Datenbank oftmals einen dritten, undefinierten Zustand (NULL). Dieser unbestimmte Zustand kann auf der Oberfläche durch den Tipp triState:false explizit verboten werden, um eine klare Entscheidung vom Anwender zu erzwingen.

Alternativ steht für diesen Zweck der dedizierte Custom-Datentyp type="Boolean2VL" zur Verfügung, der den Einsatz des UI-Tipps obsolet macht.

Die Client-GUI schneidet bei String-Eingaben standardmäßig überflüssige Leerzeichen am Anfang und Ende des Textes automatisch ab. Für spezifische Formate, bei denen Leerzeichen zwingend erhalten bleiben müssen, kann diese Automatik deaktiviert werden.

Entitäten, deren Daten nur zur Laufzeit aggregiert werden und niemals in der Datenbank gespeichert werden sollen, können von der Persistenz ausgeschlossen werden.

Die Speicherung großer Dateianhänge (BLOBs) wird über das Attribut streamResource="true" im <db>-Tag aktiviert. Um den Speicherplatzbedarf zu optimieren, kann die automatische Historisierung für diese Binärdaten gezielt abgeschaltet werden.

Spezielle, nur lokal relevante Daten wie Lagerbestände lassen sich über das Attribut forbidDirectChanges="true" vor jeglicher manueller Manipulation über den Client schützen.

Die Einhaltung datenschutzrechtlicher Vorgaben (DSGVO) wird zentral im XML-Schema deklariert. Hierfür stellt das Schema dezidierte Tags wie <GDPRDataCategory>, <GDPRBusinessInterest>, <GDPRProcessingPurpose>, <GDPRProcessingLegalBasis>, <GDPRLaw> und <GDPRRetentionPurpose> zur Verfügung. Ein Hintergrunddienst im Applikations-Server berechnet anhand dieser deklarativen Tags vollautomatisch die physischen Löschfristen für die entsprechenden Datensätze im System.

Die fundamentale Serverkonfiguration erfolgt in der zentralen Datei mytism.ini innerhalb des Abschnitts [DBMan].

Bei großen lokalen Entwicklungsdatenbanken verzögern die routinemäßigen Datenprüfungen den Serverstart oft erheblich. Diese systemweiten Integritätsprüfungen lassen sich über spezifische Parameter konfigurativ abschalten, um den Boot-Vorgang massiv zu beschleunigen.

Alternativ schließt der Parameter integrityCheckEntitiesToExcludeFromNToMAndDoubleIdCheck gezielt einzelne, datenintensive Entitäten von diesen Prüfungen aus.

MyTISM nutzt für die Persistenzschicht das Prinzip des Scaffolding. Aus den Deklarationen im Schema erzeugt der Build-Prozess vollautomatisch Java-Basisklassen. Diese Klassen kapseln die gesamte Persistenzlogik sowie alle grundlegenden Getter- und Setter-Methoden. Das Framework generiert zusätzlich dedizierte NN-Getter (get*NN()), um skalare NULL-Werte auf der Datenbankebene typsicher im Java-Code abzufangen.

Entitäten können über das XML-Attribut abstract="true" explizit als abstrakte Basisklassen deklariert werden.

Um redundante Pfadangaben zu vermeiden, wird das Basis-Package für die Code-Generierung global im einleitenden <Schema>-Tag definiert.

Für Entitäten mit spezifischer Geschäftslogik muss der Code-Generator angewiesen werden, eine manuell erweiterbare Java-Klasse zu erzeugen.

Zusätzliche Funktionsbereiche lassen sich über das Modulsystem einbinden, welches im Schema inklusive des jeweiligen Providers deklariert wird.

Die Modularisierung wird auf Code-Ebene durch ein intelligentes Vererbungssystem abgebildet. MyTISM sammelt den Code aus verschiedenen Modulen und baut daraus automatisch eine strikte Vererbungskette aus Aspekt-Klassen auf.

Eine zentrale Architekturregel besagt, dass alle Relationstypen (n-1, 1-n, n-m) in MyTISM in der Regel bidirektional definiert sind. Fehlt im XML-Schema die explizite Deklaration einer solchen <backRelation>, generiert das System diese Rückrelation jedoch völlig automatisch im Hintergrund.

In seltenen Ausnahmefällen, wie massiven Performance-Engpässen in rein unidirektional geplanten Schnittstellen, kann diese Automatik durch das Attribut ignoreReverseRelations="true" unterdrückt werden.

Die Datenbankarchitektur von MyTISM verlangt eine strikte Graphenstabilität innerhalb einer laufenden Transaktion. Dieses essenzielle Konzept wird als „Frapping“ bezeichnet. Es besagt, dass eine identische Datenbank-ID innerhalb einer Transaktion immer auf dieselbe Java-Instanz im Arbeitsspeicher verweisen muss. Laden zwei Abfragen innerhalb desselben Vorgangs zufällig dasselbe Objekt, stellt das Frapping sicher, dass Modifikationen synchron auf exakt derselben Instanz erfolgen.

Backend-Entwickler rufen Daten klassischerweise über queryBO() ab, was einen echten OQL-Request an die Datenbank sendet. Sollen speicherschonend zuerst die lokalen Caches geprüft werden, ist die Methode tx.getBOsByAttrs() die performantere Wahl.

Temporäre Attribute, die nicht persistiert werden sollen, können dynamisch über die Transient Properties Map an Objekte gehängt werden. Damit diese bei Transaktionsabbrüchen (Rollbacks) korrekt zurückgesetzt werden, müssen zwingend transaktionsgebundene Properties genutzt werden.

Bei der Implementierung virtueller Attribute gelten strenge Vorgaben. Methoden, die im Schema definierte virtuelle Attribute bereitstellen, müssen zwingend mit der @Override-Annotation versehen werden.

Virtuelle Attribute können als lokal zu cachen markiert werden, um performancekritische Berechnungen zu minimieren. Dabei muss die zugehörige Getter-Methode zwingend mit einem führenden Unterstrich benannt werden. Da Arrays in Java stets veränderlich sind, dürfen sie bei der Nutzung von gecachten virtuellen Attributen niemals direkt als Referenz aus dem Getter zurückgegeben werden.

Der Lebenszyklus eines Business Objects durchläuft vor dem Speichern spezifische Hooks des Interfaces de.ipcon.db.core.SaveAwareI. Die Methode verifyOnClient() dient ausschließlich lokalen Plausibilitätsprüfungen auf dem Client, ohne teure Datenbankzugriffe auszulösen. Serverseitig wird zunächst beforeVerifyOnServer() für sehr schnelle Datenmanipulationen aufgerufen.

Die eigentlichen Datenprüfungen unter Einbezug der Datenbank erfolgen strikt in der Methode verifyOnServer(). Ausschließlich hier darf bei erkannten Integritätsfehlern eine SaveVetoException geworfen werden. Haben alle Instanzen das Speichern genehmigt, stößt das System abschließend afterVerifyOnServer() für asynchrone Nachberechnungen an, wobei hier keine Werte mehr am Objekt verändert werden dürfen.

Um verschachtelte Code-Blöcke zu vermeiden, sollte jeder Hook mit einem ressourcenschonenden „Early Exit“ beginnen.

Das Überschreiben von isReadOnly-Methoden erfordert hohe Disziplin. Trifft die eigene logische Bedingung für den Leseschutz nicht zu, muss zwingend die Super-Klasse über super.isReadOnly(a) aufgerufen werden.

Beim Überschreiben von Settern muss stets als erster Befehl der Wert über super.setXYZ(xyz) gesetzt werden, bevor die eigene Logik greift. Getter von persistenten Attributen sollten nicht manuell überschrieben werden und dürfen keinesfalls Exceptions werfen, da dies die Benutzeroberfläche sofort zum Absturz bringt.

Beim endgültigen Entfernen von Objekten aus einer n-m-Relation darf niemals z. B. setMedikamente(null) aufgerufen werden. Es muss zwingend über den Iterator der Relation iteriert und explizit removeMedikament(m) aufgerufen werden.

Ein Objekt-Identitätsvergleich für boolesche Werte darf niemals über Konstrukte wie == Boolean.TRUE erfolgen; stattdessen ist konsequent .booleanValue() zu nutzen.

Innerhalb von Konstruktoren dürfen niemals asynchrone Threads gestartet werden, da hier auftretende Fehler stillschweigend verschluckt werden.

Verändert sich das Datenmodell derart, dass MyTISM es nicht automatisch anpassen kann, müssen Updates zwingend über versionierte Skripte verteilt werden. Der Update-Prozess durchläuft zwei isolierte Phasen. Die Methode runUpdateScriptsStage1() führt native SQL-Skripte aus, bis sie auf das erste .orm-Skript stößt. Erst danach führt runUpdateScriptsStage2() die objektrelationalen .orm-Skripte aus, welche regulär neue Datensätze innerhalb einer Transaktion anlegen können.

Die API UpdateHandlerTools bietet wichtige Hilfsmethoden für das Schreiben dieser Skripte.

Die Performance bricht massiv ein, wenn ein ORM-Skript neue Tabellen anlegt, Daten migriert und sofort riesige OQL-Abfragen absetzt, da die erforderlichen Datenbank-Indizes erst nach einem weiteren Serverneustart greifen.

Für das Schreiben von Unit-Tests für komplexe Transaktionen bietet das Framework mächtige Mocking-Möglichkeiten über Interceptoren an.

„Strukturelemente“ ist der systemweite Oberbegriff für alle UI-Elemente und Masken, mit denen Anwender Daten anzeigen, suchen oder manipulieren. Während reguläre Anwender diese Masken im Alltag lediglich bedienen, können Administratoren sie im Hintergrund über Konfigurationsdateien versionieren und detailliert anpassen. Das Framework unterscheidet dabei fünf primäre Typen von Strukturelementen:

Neben individuell erstellten Masken existieren vordefinierte Basis-Elemente, die tief im Systemkern verankert sind. Diese tragen in der Benutzeroberfläche üblicherweise den Namenszusatz „(Vorgebaut)“, um sie als unveränderliche System-Elemente zu kennzeichnen. Im Gegensatz zu regulären Objekten können diese Elemente im Navigationsbaum weder verschoben noch verlinkt werden. Für eigene Anpassungen müssen diese System-Elemente zwingend zuvor manuell kopiert werden.

Die Formularauswahl in MyTISM arbeitet strikt kontextbezogen. Für ein und dasselbe Datenbank-Objekt können abhängig vom jeweiligen Anwendungsfall oder der Benutzerrolle völlig unterschiedliche Formulare existieren. Öffnet ein Anwender einen Datensatz, ermittelt die Engine das passende Formular anhand einer fest definierten Regelhierarchie:

Der Navigationsbaum auf der linken Seite ist das zentrale Steuerungselement des Clients. Über das Tastenkürzel STRG+L können Power-User hier sehr schnell sogenannte Aliase von bestehenden Einträgen erzeugen, um individuelle Arbeitsbereiche zusammenzustellen.

Systemweite Vorgaben für die Benutzeroberfläche können direkt im Navigationsbaum unter „Admins/Mytism/Benutzerverwaltung/Variablen“ gesteuert werden. Sollen beispielsweise Tooltips in Tabellen systemweit deaktiviert werden, wird der Wert der Variable tables.showTooltips angepasst. Diese globalen Parameter lassen sich präzise für einzelne Benutzer oder ganze Benutzergruppen überschreiben. Um bei einer großen Anzahl an Benutzern den Ordner „Alle Benutzer“ übersichtlich in alphabetische Unterordner zu gruppieren, können die Variablen users.view.group.minElements und users.view.group.maxElements beispielsweise auf den Wert 5 gesetzt werden.

Strukturelemente können über das Tool „Struktur-Synchronisation“ (oder „DateiSystemSync“) als XML-Dateien in das lokale Dateisystem exportiert werden. Der Aufruf dieses Tools erfolgt im Client über den Menüpunkt „Administration → System-Objekte syncen“. Dieser XML-Export ist essenziell, da er eine professionelle Versionskontrolle der gesamten Oberfläche ermöglicht.

Damit ein Strukturelement exportiert werden kann, muss in seinen Eigenschaften zwingend ein Dateiname (bzw. relativer Pfad) hinterlegt sein. Die Schaltfläche „Dateiname vorschlagen“ generiert dabei automatisch einen passenden Namen, der die Ordnerstruktur des Elterpfads logisch widerspiegelt.

In der Sync-GUI stehen Administratoren verschiedene Aktionen zur Verfügung. Die Liste der Elemente lässt sich filtern und verschiedene Detailstufen für Log-Meldungen sind zuschaltbar. Die Aktion „Vergleichen“ aktualisiert die Liste und gleicht den Stand zwischen der Datenbank und dem Dateisystem für einen manuellen Überblick ab. Die Aktion „Alles synchronisieren“ importiert oder exportiert automatisch alle Elemente basierend auf ihrem Status und speichert die finalen Änderungen in der Datenbank.

Dies ermöglicht zwei klassische Deployment-Workflows. Beim Export passen Administratoren bestehende Elemente direkt im Live-System an und exportieren diese in das lokale Dateisystem, um die neue Version in der Versionskontrolle zu sichern. Beim Import entwerfen Entwickler neue Masken auf einem separaten Testsystem und übertragen die XML-Dateien anschließend auf den Live-Server. Die Synchronisations-GUI erkennt diese als neue oder geänderte Dateien und importiert die neue Version sicher in die Live-Datenbank. Eine Funktion „Sync automatisch durchführen“ zur selbsttätigen Überwachung existiert zwar, gilt jedoch als fehleranfällig und wird im professionellen Betrieb selten genutzt.

Damit der System-Scanner die exportierten Dateien korrekt als Strukturelemente erkennt, gelten zwingende Suffix-Regeln für Dateinamen. Diese lauten .frm.xml für Formulare, .bkm.xml für Lesezeichen, .tpl.xml für Schablonen, .bst.xml für Codebausteine und .als.xml für Aliase. Eine technische Sonderrolle nehmen Reports ein, die im Rahmen der Synchronisation separat in zwei Dateien verwaltet werden.

Jede dieser XML-Dateien besteht aus einem Wurzel-Element, das dem Typ des Strukturelements entspricht, also beispielsweise <Formular> oder <Schablone>. Dieses Wurzel-Element besitzt essenzielle Attribute zur Systemregistrierung. Das Attribut Name definiert die Beschriftung in der GUI. Das Attribut ElterPfad definiert den logischen Ordner-Pfad im Navigationsbaum. Fehlen Ordner in diesem Pfad, legt MyTISM sie beim Import automatisch an. Das Attribut Prioritaet bestimmt, welches Element standardmäßig geöffnet wird, falls für einen Datensatz mehrere Masken existieren. Der Standardwert des Systems ist hierbei meist -50. Zuletzt gibt es das Attribut Tid für die technische ID, die jedoch vom System automatisch vergeben wird und manuell niemals gesetzt werden sollte.

Unterhalb des Wurzel-Elements definieren spezifische Kind-Elemente den Inhalt. Das Tag <Beschreibung> dient als interne Notiz für Entwickler und wird Endanwendern nicht angezeigt. Das Tag <BOTyp> legt fest, an welche Entität dieses Strukturelement gebunden ist. Das Tag <Parameter> bildet den Kernbereich, in dem das detaillierte Layout des Formulars oder die Abfrage des Lesezeichens hinterlegt wird. Zuletzt steuert das Tag <Gruppen>, welche Benutzergruppen das Element überhaupt sehen dürfen.

Neben echten persistierten Daten existiert die virtuelle Entität „BX“, für die spezielle BX-Formulare angelegt werden. Sie werden primär genutzt, um komplexe Suchmasken oder interaktive Dashboards abzubilden. Diese BX-Objekte halten lediglich temporäre Werte zur Ablaufsteuerung oder zur Ein- und Ausgabe im Arbeitsspeicher, die niemals fest in der Datenbank gespeichert werden.

Im <Parameter>-Bereich eines Formulars (.frm.xml) wird das visuelle Layout mit hochspezialisierten UI-Tags aufgebaut. Das grundlegende Layout-Konzept basiert auf einem intern entwickelten Java-GridLayout.

Die exakte Positionierung der Elemente kann optional explizit über die Attribute e-x und e-y gesteuert werden, wobei das Präfix „e-“ für „Element“ steht. Um beispielsweise zwei Felder auf derselben horizontalen Zeile zu platzieren, wird e-y="same" genutzt. Der Umbruch auf die nächste Zeile ist das Standardverhalten, kann aber auch explizit mit e-y="next" erzwungen werden.

Die Breite und Höhe von Feldern steuern Administratoren über die Attribute minSize und prefSize. Die Maßeinheit „c“ steht hierbei für die Zeichenbreite und ist die zu favorisierende Vorgabe. Die Syntax erwartet dabei stets ein Tupel aus horizontaler und vertikaler Ausdehnung.

Zusammengehörige Felder lassen sich zur besseren Strukturierung durch das Tag <Border> optisch einrahmen. Dieses Element sollte jedoch sparsam eingesetzt werden, da zu viele ineinander verschachtelte Rahmen das Formular optisch stark belasten. Der gezielte Einsatz von simplen <Label/>-Tags für Zwischenüberschriften führt in komplexen Masken oftmals zu einem ruhigeren UI-Design. Das Container-Element <View> dient hingegen als unsichtbarer Basis-Container, der Kind-Elemente in einem Raster gruppiert.

Für dynamische Masken steht das Tag <visibleIf> zur Verfügung. Damit lassen sich ganze Formularbereiche zur Laufzeit über Groovy-Skripte ein- oder ausblenden. Dies kann mit einem <ToggleButton> kombiniert werden, um auf- und zuklappbare Bereiche zu konstruieren. Wechselt der Nutzer den Button, wertet ein anschließendes Skript die Sichtbarkeit neu aus und klappt den definierten Bereich auf.

Für die eigentliche Dateneingabe bietet MyTISM einen umfassenden Katalog an Widgets. Das Standard-Eingabefeld für Strings oder Zahlen ist <Text>. Es lässt sich über selectAllWhenFocused="true" so konfigurieren, dass der gesamte Text beim Fokussieren markiert wird. Über lineWrap="true" wird ein weicher Zeilenumbruch erzwungen. Sollen in der Akte mehrzeilige Notizen gerendert werden, muss zwingend class="ITextArea" deklariert werden. Für strukturierte Inhalte oder Log-Ausgaben steht das <Editor>-Tag mit Syntax-Highlighting bereit. Das Tag <StyledText> fungiert als Rich-Text-Editor für formatierte Fließtexte. Dieser Editor lässt sich über onlyTextFormattingActions="true" strikt auf reine Textformatierungen limitieren. Das simple <Label> dient der reinen Anzeigebeschriftung.

Für boolesche Werte steht das Tag <CheckBox> zur Verfügung. Dieses Widget kann über triState="true" auch drei Zustände annehmen. Eine visuelle Alternative ist der <ToggleButton>, der als Knopf zwischen zwei Zuständen wechselt und über falseText beziehungsweise trueIcon dynamisch sein Aussehen ändert. Das Tag <ComboBox> erzeugt ein klassisches Dropdown-Menü. Dieses verbietet über chooseOnly="true" Freitext-Eingaben und erlaubt über nullable="true" leere Auswahlen. Spezifisch für Zeit- und Datumsangaben existiert der <DateChooser>. Er rendert ein Kalender-Icon zur Datumsauswahl, dessen Formatierung über das Attribut format exakt gesteuert wird. Sollen stattdessen Zeitdauern erfasst werden, kombiniert der <SimpleTimespanChooser> ein Zahlenfeld mit einem Dropdown für die jeweilige Zeiteinheit.

Für die Einbindung relationaler Datenstrukturen existieren hochspezialisierte Widgets. Das Tag <Table> zeigt 1:n-Relationen direkt als eingebettete Liste im Formular an. Soll ein vorhandenes Datenbankobjekt verknüpft werden, rendert <Popup> ein Suchfeld inklusive Such- und Neuanlage-Icons. Für hierarchische Strukturen eignet sich das <Tree>-Tag hervorragend. Für Ressourcenplanungen existiert das komplexe Gantt-Element <Scheduler>.

Das Verhalten all dieser Eingabefelder lässt sich detailliert und dynamisch anpassen. Das Setzen des Flags disabled="true" verhindert das Editieren und graut das Feld optisch permanent aus. Das Flag editable="false" verhindert das Editieren ebenfalls, belässt das Feld jedoch in seiner regulären optischen Darstellung. Um Formatierungen auf reinen Anzeigetexten zu nutzen, imitiert disguiseAsLabel="true" das Styling eines klassischen Labels. Für komplexe Geschäftslogiken lassen sich Felder mit den Skript-Tags editableIf und alsoMandatoryIf zur Laufzeit steuern. So kann beispielsweise ein Feld dynamisch zum Pflichtfeld gemacht werden, sobald spezifische Bedingungen eintreten.

Das Tag <Element> dient in Formularen oft als feingranularer Wrapper, um das Labeling von Widgets zu überschreiben. Das Setzen von hideForNullBO="true" sorgt beispielsweise dafür, dass ein verknüpftes Element komplett aus der Maske verschwindet, wenn das zugrundeliegende Objekt den Zustand null hat. Da sich Datenbank-Schemata über die Jahre weiterentwickeln, ist das Attribut missingPropertiesPolicy im Wurzel-Knoten essenziell. Es steuert mit den möglichen Werten error, ignore oder log exakt, wie das Formular reagieren soll, wenn ein im XML-Layout referenziertes Attribut im zugrundeliegenden Datenmodell fehlt.

Ausladende Formulare werden klassischerweise in Reiter unterteilt, wofür das Tag <TabbedView> mit seinen <Tab>-Kindern genutzt wird. Aus Gründen der Performance werden Inhalte von Tabs standardmäßig erst dann vom Server geladen, wenn der Nutzer den Reiter explizit anklickt. Soll der Inhalt jedoch bereits beim initialen Öffnen der Maske geladen werden, muss dieses Ladeverhalten explizit auf lazy="false" geändert werden.

Interaktionen werden als Aktionen deklariert und flexibel in Toolbars gerendert. Mit dem Attribut toolBar lassen sich Buttons in die Standard-Toolbar der Tabelle einfügen. Durch den Wert topMdiOnly werden sie in der Haupt-Toolbar des Client-Fensters platziert. Die Engine trennt bei Aktionen strikt zwischen reiner Sichtbarkeit über <availableOn> und Klickbarkeit über <enabledOn>.

Um Standardfunktionen von Tabellen zu verbergen, wird die entsprechende Action mit einem leeren Tag überschrieben.

In allen Formular-Panels kann nativer Drag-’n’-Drop-Support für Dateien konfiguriert werden. Das folgende Skript prüft vor dem Upload sicherheitshalber, ob der Datensatz bereits gespeichert wurde, und validiert anschließend das Dateiformat.

Listen innerhalb von Formularen werden im <Parameter>-Bereich durch das Tag <Table> definiert. Die Darstellung der Spalten kann hierbei direkt über das Attribut columns gesteuert werden, wobei oftmals die Kurznotation zum Einsatz kommt. Die Definitionen der einzelnen Tabellenspalten werden in dieser Notation zwingend durch ein Pipe-Zeichen (|) voneinander getrennt. Innerhalb einer Spalte werden zusätzliche Eigenschaften durch ein Komma abgetrennt. Spalten, die in diesem String nicht explizit deklariert werden, blendet das System in der GUI automatisch aus. Soll die Spaltenüberschrift vom reinen Attributnamen abweichen, wird der neue Titel in einfache Anführungszeichen direkt hinter den Namen geschrieben. Breitenangaben erfolgen kompakt durch einen Zahlenwert plus Einheit, wobei neben Pixeln vor allem die Zeichenbreite (c) favorisiert wird.

Die Kurznotation unterstützt die komplexe Mehrfachsortierung. Wenn nach mehreren Spalten sortiert werden soll, wird die Priorität direkt als Zahl an das Schlüsselwort asc oder desc angehängt. Um bei polymorphen Tabelleninhalten den exakten Typ des Datensatzes anzuzeigen, wird zudem das System-Attribut Bot.Name als Spalte deklariert.

Diese Kurzschreibweise hat jedoch technische Grenzen, wenn eine Spalte tiefgreifende Modifikationen erfordert. In diesen Fällen muss zwingend auf das ausführliche XML-Tag <Column> ausgewichen werden.

Die dynamische Filterung dieser formulinternen Tabellen wird exakt wie bei regulären Lesezeichen über <filter>-Tags innerhalb des <Query>-Elements gesteuert. Die Filterlogik reicht dabei von simplen Text- und Datumsfiltern bis hin zu dynamischen und kaskadierenden Dropdowns.

Schablonen (.tpl.xml) definieren die strikten Regeln für die Anlage neuer Datensätze. Im <Parameter>-Bereich können über das Tag <newInstance> Skripte hinterlegt werden, die das neu erzeugte Objekt beim Klick auf „Neu“ mit Standardwerten vorbelegen. Das Kind-Tag <Formular> steuert dabei präzise, welches Formular sich direkt nach der Initialisierung für den Anwender öffnen soll.

Um komplexen Layout-Code nicht mehrfach kopieren zu müssen, können komplette GUI-Ansichten in Codebausteine (.bst.xml) ausgelagert werden. Ein Formular kann diesen Baustein über das <Include>-Tag referenzieren. Der XML-Parser des Systems ersetzt den <Include>-Befehl beim Laden exakt durch den im referenzierten Codebaustein hinterlegten Inhalt.

Zudem unterstützen diese Codebausteine auch dynamische Übergabeparameter. Diese werden im <Include>-Tag als Attribute definiert und im Baustein selbst via $IP{…​} variabel aufgelöst.

Innerhalb der XML-Konfiguration von Strukturelementen steuern Power-User und Administratoren die Objektdarstellung primär über das Attribut format. Dieses Attribut nimmt einen validen CBOFormat-Ausdruck entgegen und kommt bei einer Vielzahl von Oberflächenkomponenten zum Einsatz.

Auswahllisten und ComboBoxen nutzen das Attribut, um festzulegen, wie ein referenziertes BO in der Dropdown-Liste für den Anwender dargestellt wird.

In Tabellenspalten (<Column>) wird das Werkzeug eingesetzt, um verknüpfte Relationen innerhalb einer einzelnen Zelle ansprechend aufzubereiten. Zusätzlich steht hier das Attribut toolTipFormat zur Verfügung. Dieses definiert eine alternative Maskierung, die dem Anwender beim Verweilen mit dem Mauszeiger über der Zelle als Tooltip eingeblendet wird.

Labels und Textfelder nutzen das CBOFormat als dynamische Formatierungsschablone für die reine Datenanzeige. Die zwingende Voraussetzung für die korrekte Evaluierung des Formats ist das gleichzeitige Setzen des Attributs property.

Auch im Kalender- und Scheduler-Modul steuert das Format das visuelle Erscheinungsbild. Innerhalb des <Scheduler>-Elements wird dem contactMapper über das Attribut format ein entsprechender Ausdruck übergeben, um die Beschriftung von Kontakten und Terminen im Zeitraster zu manipulieren.

Neben den projektspezifischen Strukturelementen existieren vordefinierte Basis-Elemente aus dem System-Core. Diese Core-Elemente liegen im Quellcode-Verzeichnis unter /nrx/de/ipcon/db/core/resources und werden beim Build-Prozess fest in die zentrale Kernel-JAR einkompiliert. Ein Hintergrunddienst liest diese XML-Dateien bei jedem Serverstart aus und legt sie in der Datenbank an. Architektonisch sind diese System-Elemente als strikt unveränderlich zu betrachten. Sollen Änderungen an diesen Core-XMLs wirksam werden, müssen Entwickler die Anpassungen direkt im Code vornehmen. Anschließend muss die Marker-Datei .checked-initialdata im Serververzeichnis gelöscht und das System neu gestartet werden.

Die Architektur unterscheidet strikt zwischen dem globalen ClientContextI (ctx) und dem formularspezifischen FormContextI (ftx). Der globale Kontext verwaltet systemweite Aktionen, wie das Speichern laufender Transaktionen oder das Aufrufen globaler Dialoge. Zudem steuert der globale Kontext GUI-Aufrufe, wie das Öffnen eines definierten Lesezeichens über ctx.openView(). Der formularspezifische Kontext ist hingegen ausschließlich für Detailaktionen innerhalb einer spezifischen Maske zuständig. Die Engine injiziert in alle GUI-Skripte standardmäßig die Variablen ctx, ftx, tx sowie das aktuelle Business Object bo.

Beim Zugriff auf Eigenschaften des Form-Kontexts aus Groovy heraus sollte stets die ausführliche Getter-Schreibweise genutzt werden. Groovy bevorzugt bei Properties andernfalls fehlerhaft interne Methoden wie isRoot(), was zu unerwarteten Werten bei der Code-Evaluierung führt.

Die Breadcrumb-Navigation ermöglicht den kontextbasierten Zugriff auf Objekte innerhalb einer verschachtelten Formular-Hierarchie. Dadurch können Skripte bei uneindeutigen Relationen den logischen Pfad der Datenstruktur rückwärts auflösen. Dieser Navigationszustand wird exklusiv für den aktuellen Thread in einem lokalen Speicher vorgehalten. Das System verzichtet bewusst auf ein vererbbares ThreadLocal, um zu verhindern, dass asynchron abgespaltene Threads die Historie erben und Race Conditions auslösen. Ein interner Zähler dient als Verschachtelungsschutz und stellt sicher, dass bei kaskadierenden Aufrufen stets der äußerste Einstiegspunkt den Start definiert.

Die API des BreadcrumbFinders bietet spezifische Methoden zur Durchsuchung der Hierarchiekette. Die Methode findParentBO() liefert das direkte Eltern-Objekt, während findFirstBOOfType() das erste Objekt eines definierten Typs sucht. Bevor Backend-Komponenten auf Schema-Attribute zugreifen, muss der Kontext initialisiert und abschließend bereinigt werden. Um Speicherlecks zu verhindern, ist hierbei zwingend das Try-Finally-Muster anzuwenden.

Die Formular-Engine basiert auf einem streng synchronisierten Model-View-Konzept. Über Action-Hooks klinken sich Entwickler direkt in den Datenaustausch zwischen Datenbank und Benutzeroberfläche ein. Die Engine injiziert innerhalb dieser XML-Skript-Tags automatisch feste Kontext-Variablen: bo (aktuelles Business Object), rootBO (Basis-BO der Maske), fe (spezifisches FormElementI), ftx, tx und den Lade-Kontext bol.

Der Hook <onRefresh> löst aus, wenn Daten aus dem Model in die GUI geladen werden. Der Hook <onSync> feuert beim Zurückschreiben der Eingaben aus der GUI in das zugrundeliegende BO. Dies geschieht typischerweise beim Verlassen eines Eingabefeldes oder unmittelbar vor dem Speichern des Formulars.

Für direkte Interaktionen in Listen existiert der Hook <onAfterSelectValue>, der unmittelbar nach der Selektion eines Tabellenwerts feuert. Das folgende Beispiel nutzt diesen Hook, um eine versehentliche Mehrfachselektion programmatisch zu unterbinden.

Zusätzlich existieren die Hooks <onFocusGained> und <onFocusLost>, die beim Betreten und Verlassen eines Eingabefeldes auslösen.

Virtuelle Eigenschaften berechnen sich zur Laufzeit dynamisch und können für Optimierungszwecke gecacht werden.

Innerhalb virtueller Attribute darf zum Nachladen von Daten ausschließlich der BOLoader und niemals direkt eine Transaktion aufgerufen werden. Da Java-Arrays grundsätzlich veränderlich sind, darf ein gecachter Rückgabewert eines virtuellen Array-Attributs niemals direkt modifiziert werden. Die generierten Getter-Methoden von persistenten Attributen dürfen keinesfalls überschrieben werden, da dies das GUI-Formular blockiert.

In der XML-Deklaration virtueller Eigenschaften dienen Breadcrumbs häufig dem Zugriff auf übergeordnete Kataloge im Datenbaum.

Ein weiterer Anwendungsfall ist das Filtern von Listen basierend auf dem Root-Kontext, der meist durch die „BX“-Entität abgebildet wird. Das System greift hierbei auf das Haupt-Konfigurationsobjekt zu, um globale Einstellungen für die Auswertung heranzuziehen.

Das Konzept GrooqlFilter verbindet Formularmasken direkt mit OQL-Abfragen. Ein Groovy-Skript prüft Objekte im Arbeitsspeicher und wird vom Framework gleichzeitig in eine korrespondierende Datenbankabfrage transformiert.

Für Konsistenztests auf der Benutzeroberfläche existiert die Hook-Methode verifyOnClient(). Diese dient der reinen clientseitigen Validierung von Eingabeformaten, bevor Daten an den Server übertragen werden. Innerhalb dieser Methode besteht eine akute Deadlock-Gefahr. Es dürfen hier niemals asynchrone GUI-Interaktionen wie Bestätigungsdialoge aufgerufen werden. Für fachliches Feedback muss stattdessen eine SaveVetoException geworfen werden, deren Nachricht das System fängt und als Dialog anzeigt.

Beim GUI-Threading darf der Event-Dispatcher-Thread (EDT) der Swing-Oberfläche niemals durch Datenbank-Operationen blockiert werden. Für die asynchrone Ausführung komplexer Berechnungen im Hintergrund stellt das Framework die Utility-Klasse SPU bereit.

Muss ein Prozess auf eine Antwort warten, ohne die Benutzeroberfläche einzufrieren, initiiert das System einen sekundären Loop.

Für temporäre, rein GUI-gesteuerte Auflistungen müssen Dummy-Objekte mit flüchtiger ID und zugewiesenem BOLoader initialisiert werden.

Formulare können für dynamisches GUI-Styling HTML-Fragmente evaluieren, um spezifische Werte farblich hervorzuheben. Dies kommt häufig in Tabellenzellen zum Einsatz, bei denen ein virtuelles Attribut im <get>-Block einen formatierten HTML-String zurückgibt.

Werden in diesen HTML-Skripten Icons über das <img>-Tag geladen, müssen in aktuellen Java-Versionen die Attribute height und width zwingend deklariert werden.

Mittels des <renderer>-Tags lässt sich das Zeichnen von Tabellenzellen durch Groovy-Skripte vollständig überschreiben. Wird ein solcher Custom-Renderer implementiert, muss der visuelle Zustand im else-Zweig zwingend zurückgesetzt werden. Da die Rendering-Engine GUI-Zellen beim Scrollen recycelt, würden visuelle Modifikationen andernfalls auf falsche Datensätze übertragen.

Der programmatische Zugriff auf GUI-Elemente erfolgt über den Array-Operator des FormContexts.

Schalten Skripte die Sichtbarkeit von Elementen dynamisch um, schlägt ein sofortiges Neuladen (Refresh) oft fehl, da der Zeichenprozess noch nicht abgeschlossen ist. Zur Vermeidung dieser Race-Condition wird der Update-Befehl über die Klasse SPU asynchron in die Queue delegiert.

Für dynamische Masken können XML-Codebausteine zur Laufzeit programmgesteuert geladen und geparst werden.

Für das Debugging lassen sich Konsolenausgaben direkt in Skript-Blöcken platzieren, welche im Client über die „Groovy-Konsole“ ausgelesen werden.

Die Engine verarbeitet die bereitgestellten Daten nacheinander. Sie läuft über die ausgewählten Hauptobjekte und löst dabei die definierten Relationen hierarchisch auf. Die Strukturierung großer Datenmengen erfolgt über logische Gruppen, welche redundante Daten zusammenfassen und optische Abschnitte – wie etwa den Wechsel zur nächsten Station – generieren.

Als primäre Rendering-Engine dient eine modifizierte und um Rich-Text-Fähigkeiten erweiterte Version des Open-Source-Tools JasperReports. Reports lassen sich standardmäßig in diverse Formate wie PDF, HTML, CSV, Excel oder RTF exportieren oder inklusive Client-Vorschau ausdrucken. Für unformatierte, stark textbasierte Dokumente, wie beispielsweise seitenlange psychiatrische Gutachten, steht alternativ eine leichtgewichtige AsciiDoc-Engine zur Verfügung.

Klassische Reporting-Tools erfordern oftmals hochkomplexe und fehleranfällige SQL-Abfragen direkt im Report-Layout, um Datengruppen oder Sortierungen zu erzeugen. MyTISM verzichtet im Layout vollständig auf direkte Datenbankabfragen. Die Datengrundlage wird stattdessen über eine XML-basierte Definition fest am jeweiligen Objekttyp (Entität) verankert. Diese Definition steuert zentral, welche Relationen aufgelöst und in welcher Reihenfolge die Daten an das Layout übergeben werden. Soll eine vollständige Patientenakte generiert werden, wird der Report an der Entität „Patient“ verankert, woraufhin das System dann etwa die chronologische Behandlungs-Historie automatisch bereitstellt.

Das Layout-Konzept von JasperReports basiert nicht auf statischen Tabellen, sondern auf sogenannten Bändern (Bands). Das Kernelement ist das Detailband, welches für jeden einzelnen Datensatz – beispielsweise für jedes Medikament einer Inventarliste – wiederholt gerendert wird. Dieses Detailband wird von Kopf- und Fußbändern (Header und Footer) umschlossen. Diese äußeren Bänder steuern Seitenumbrüche oder Gruppenwechsel, um etwa am Ende einer Liste die summierten Behandlungskosten abzugrenzen.

Das System unterscheidet konzeptionell zwischen dynamischen Ad-hoc-Reports und eigenständigen Reports. Ad-hoc-Reports werden vom Anwender direkt aufgerufen, indem er beispielsweise spezifische Patienten in einem Lesezeichen markiert und den Report über das Kontextmenü für exakt diese Treffermenge anfordert. Eigenständige Reports ermitteln ihre Datengrundlage hingegen völlig selbstständig anhand einer fest im Report vorkonfigurierten OQL-Abfrage, ohne dass eine vorherige Benutzerauswahl erforderlich ist.

Darüber hinaus wird zwischen Einzel-Reports und Listen-Reports unterschieden. Ein Einzel-Report fokussiert sich auf die Details eines spezifischen Objektes, wie den individuellen Arbeitsvertrag eines Arztes. Ein Listen-Report arbeitet mehrere Objekte iterativ ab, wie beispielsweise die aggregierte Liste aller diensthabenden Ärzte einer Nachtschicht.

Um die abstrakten Datenmodelle in das Dokument zu überführen, nutzt die Engine spezifische Platzhalter. Felder greifen direkt auf die Attribute der übergebenen Business Objects zu. Variablen dienen systemseitigen Berechnungen zur Laufzeit, wie beispielsweise für Seitenzahlen oder aggregierte Rechnungssummen. Parameter ermöglichen die interaktive Dateneingabe durch den Benutzer vor der Generierung, um etwa den Auswertungszeitraum eines Schichtplans einzugrenzen. Zusätzlich übernehmen Lokalisierungs-Makros die automatische Übersetzung statischer Textbausteine.

Subreports erlauben es, andere Reports als wiederverwendbare Module in einen Hauptreport einzubetten. Dies ist besonders nützlich, um Daten aus völlig unterschiedlichen Entitäten in einem einzigen Dokument zusammenzuführen, beispielsweise beim Einbetten einer Medikamentenliste in die Patientenakte. Dank der Systemarchitektur steht ein Report, der für eine Basis-Klasse definiert wurde, durch Polymorphie automatisch auch allen abgeleiteten Unterklassen zur Verfügung. Die Sichtbarkeit jedes Reports bleibt dabei stets strikt an das zentrale Rechtesystem gekoppelt.

Die Erstellung eines neuen Reports erfolgt im Client typischerweise über die vorgebaute Schablone im Navigationsbaum. Jeder Report wird dabei fest an einen spezifischen BO-Typ gebunden, wie beispielsweise an die Entität „Vertrag“. Eine konfigurierbare, numerische Priorität steuert die Anzeigereihenfolge in den Kontextmenüs. Bei etwaigen Konflikten gewinnt stets der speziellste BO-Typ oder die höchste Priorität.

Durch das Setzen der Checkbox „Auch für Unterklassen des BO-Typs nutzbar“ wird ein Basis-Report polymorph für alle abgeleiteten Sub-Entitäten freigeschaltet. Ein auf der Basisklasse „Vertrag“ definierter Bericht steht somit automatisch auch für spezialisierte Typen wie „Arztvertrag“ oder „Wartungsvertrag“ zur Verfügung.

Im selben Formular werden die zulässigen Druckziele konfiguriert, wie etwa eine PDF-Vorschau oder der direkte physische Druck. Sind in den Einstellungen explizite Sprachen hinterlegt, limitiert das System die L10n-Übersetzung im finalen Druckdialog strikt auf diese sprachliche Auswahl.

Zwei zentrale Flags im Formular steuern das Ausführungsverhalten der Rendering-Engine. Ist die Option „ist eine Liste“ aktiviert, iteriert der Report in einem einzigen Durchlauf über eine gesamte Menge markierter Objekte, anstatt nur ein einzelnes Element zu verarbeiten. Dieses Verhalten ist essenziell für aggregierte Übersichtsberichte, wie etwa tabellarische Auflistungen mehrerer Datensätze.

Das Flag „ist eigenständig“ bewirkt hingegen, dass der Report die aktuelle GUI-Selektion des Anwenders vollständig ignoriert. Die Datengrundlage wird in diesem Fall autark über eine fest integrierte OQL-Abfrage ermittelt.

Für das System-Debugging durch Power-User bieten die Formulare dedizierte, schreibgeschützte Reiter. Die Reiter „Verarbeitete Parameter“, „Verarbeitete Report-Definition“ und „Verarbeitete Anker-Definition“ visualisieren den fertig aufgelösten XML-Quellcode unmittelbar vor der Übergabe an die Rendering-Engine.

Globale Standardwerte für Automatik-Reports, wie die generelle Seitenausrichtung oder bevorzugte Schriftgrößen, werden in der Datei schema.xml über das Element <report> definiert.

Zusätzlich lassen sich spezifische Steuerungsattribute direkt an den einzelnen Entitäts-Attributen deklarieren. Dadurch können interne IDs auf automatischen Reports standardmäßig ausgeblendet, Spaltenbreiten angepasst oder Sortierungen hartkodiert werden.

Die Anker-Definition steuert die Datenbeschaffung und ersetzt direkte SQL-Queries im Layout. Im einfachsten Fall definiert das Root-Element lediglich den fundamentalen Startpunkt für die Abfrage.

Das Auflösen von 1:n- oder n:m-Relationen erfolgt zwingend über das Tag <many>, welches die referenzierten Objekte sortiert an das Layout übergibt. Durch die Vergabe eines Alias (alias="P") lassen sich die einzelnen Elemente der Relation später im Layout gezielt über das Feld $F{P} ansprechen.

Daten-Gruppierungen erfordern eine strikte Synchronisation zwischen dem Jasper-Layout und der Anker-Definition. Die Sortierung im <many>-Tag des Ankers muss exakt der groupExpression der Layout-Gruppe entsprechen, da die Engine die Daten sequenziell verarbeitet. Bei einem Gruppenwechsel löst die Engine automatisch den „Group Footer“ aus, um beispielsweise aggregierte Zwischensummen zu drucken. Bleibt die groupExpression leer, iteriert die Gruppe nicht über Daten, sondern verschachtelt lediglich Layout-Bereiche, was als Workaround für extrem lange Reports dient.

Virtuelle Eigenschaften können direkt innerhalb des Ankers spezifisch für den jeweiligen Report deklariert werden.

Für eigenständige Reports wird die Abfrage direkt im XML über das Tag <Query type="Text"> deklariert. Diese Abfrage befüllt das systemseitige Variablen-Array $P{BOS} bei der Ausführung automatisch mit den ermittelten Objekten. Über das Attribut fieldWidth kann die Breite des zugehörigen Suchfeldes in der GUI gesteuert werden. Für komplexe Filterungen bietet das Tag <transform-script> die Möglichkeit, Abfrageresultate programmatisch zu modifizieren, bevor sie an die Engine übergeben werden.

Sollen Eingabeparameter vor der Ausführung als interaktiver Auswahldialog präsentiert werden, muss das Attribut isForPrompting="true" gesetzt sein.

Über das Property choiceScript lassen sich im Dialogfenster dynamische Dropdown-Listen generieren. Die mögliche Eingabe wird durch chooseOnly="true" strikt auf die vorgegebenen Werte limitiert. Das Property nullable="true" steuert, ob die Dropdown-Auswahl leer gelassen werden darf.

Über das Attribut rawInputDefinition kann ein komplettes MyTISM-Auswahl-Popup inklusive OQL-Filtern direkt in den Dialog injiziert werden. Hierbei müssen sämtliche XML-Sonderzeichen streng als Entities escaped werden, um die Syntax nicht zu brechen.

Um eine einheitliche Typografie zu gewährleisten, können in der XML-Definition übergreifende Schriftarten deklariert werden.

Standardmäßig werden Datenmengen in Detail-Bändern vertikal untereinander aufgefaltet. Sollen Listeninhalte stattdessen horizontal nebeneinander dargestellt werden, muss das Attribut printOrder="Horizontal" im Root-Tag gesetzt werden. Die verfügbare Seitenbreite muss hierbei exakt auf die konfigurierte columnWidth und das optionale columnSpacing aufgeteilt werden. Die Summe aus Spaltenbreite und Spaltenabstand, multipliziert mit der Anzahl der Elemente, darf die verfügbare Druckbreite der Seite niemals überschreiten.

Bilder müssen initial als reguläres Business Object vom Typ „Bild“ importiert und als „BildPosten“ verknüpft werden. Für Vektorgrafiken (SVG) ändert sich die deklarierte Klasse des Parameters, und in der imageExpression muss ein BatikRenderer-Objekt instanziiert werden.

Zur visuellen Aufbereitung aggregierter Daten nutzt die Engine das Tag <barChart>. Die Datenübergabe erfolgt über ein gekapseltes categoryDataset, welches in verschiedenen categorySeries definiert, wie die Achsen und Balken zu rendern sind.

Werden in den Layouts Hintergrundfarben definiert, muss das Attribut mode="Opaque" zwingend gesetzt sein, da die Farbe andernfalls transparent bleibt. Laufzeitsummen werden über das Attribut calculation="Sum" deklariert.

Für die Darstellung von dynamischen Seitenzahlen im Format „Seite X von Y“ existiert ein spezifischer architektonischer Workaround. Zwei Textfelder werden nebeneinander platziert und werten die Systemvariable $V{PAGE_NUMBER} zu unterschiedlichen Rendering-Zeitpunkten aus.

Das Einbinden von untergeordneten Subreports in einen Hauptreport erfordert zwingend die Definition von exakt zwei Parametern im Hauptdokument. Ein Parameter wird für die Jasper-Engine benötigt, der andere referenziert das zugrundeliegende Business Object des Reports.

Zum grafischen Bearbeiten der Layouts darf ausschließlich das externe Tool iReport in der Version 2.0.5 verwendet werden. Die Kompatibilität muss in iReport strikt auf „JasperReports 2.0.0 - 2.0.1“ limitiert werden, da neuere XML-Formate nicht unterstützt werden.

Um in Entwicklungsumgebungen eine Autovervollständigung für das Jasper-XML zu gewährleisten, kann eine DTD-Deklaration eingebunden werden.

Um redundanten XML-Quelltext zu vermeiden, nutzt das System Codebausteine. Dies sind eigenständige Strukturelemente, in die wiederkehrende Layout-Fragmente zentral ausgelagert werden. Die Definition des Quelltextes wird vom Wurzelelement <Codebaustein> umschlossen. Diese Bausteine lassen sich per Referenz über das Tag <Include> in andere Reports einbinden. Sollen dynamische Werte übergeben werden, werden diese als Parameter deklariert und innerhalb des Bausteins über die Syntax $IP{…​} aufgelöst.

Die AsciiDoc-Engine dient der Generierung stark textlastiger, narrativer Dokumente. Ein AsciiDoc-Report wird über ein XML-Skelett definiert, das zwei wesentliche CDATA-Blöcke enthält: das visuelle Erscheinungsbild (PDFTheme) und den Inhalt (Asciidoc).

Das Styling erfolgt zentral im YAML-Format innerhalb des PDFTheme-Blocks. Über Spalten-Definitionen positionieren Sie Logos im Header und lassen das System Seitenzahlen im Footer generieren.

Der Inhalt des <Asciidoc>-Tags wird vom System als ein einziger Groovy-GString evaluiert. Der Block beginnt als Groovy-Skript zur Definition lokaler Variablen und Konstanten. Am Ende des Skripts geben Sie den Textkörper als evaluierten GString über return """\ …​ """ zurück.

Der GString kann unterbrochen werden, um Relationen iterativ als Tabellenzeilen zu generieren und das Ergebnis anschließend zusammenzufügen.

Für fixe Layout-Strukturen, wie Unterschriftenblöcke, werden randlose, unsichtbare Tabellen genutzt. Für die Einrückung von Texten empfiehlt sich die Deklaration eigener Variablen für geschützte Leerzeichen am Dokumentenanfang.

Da der AsciiDoc-Parser reservierte Zeichen nutzt, müssen MyTISM-spezifische Erweiterungen teilweise manuell über Pass-Macros geschützt werden:

Sollen Sternchen innerhalb eines fettgedruckten Textes erscheinen, müssen diese mit Pluszeichen geschützt werden (+*+).

Bilder werden mittels $I{…​} integriert, wobei der Ausdruck zwischen den Klammern als Groovy-Code ausgewertet wird.

Der Lifecycle der Engine gliedert sich in vier strikte Phasen. In der Design-Phase wird der Blueprint im Designer erstellt. Während der Kompilierungs-Phase wandelt die Engine das XML in eine prozedurale Java-Klasse um, wobei Syntaxfehler zum Abbruch führen. In der Befüllungs-Phase iteriert die Engine zeilenweise durch den Datenstrom der BOsDataSource. Zuletzt transformiert die Export-Phase die befüllte Report-Instanz in das finale Zielformat.

Reports können von Backend-Entwicklern interaktionsfrei in Hintergrundskripten oder serverseitigen Actions generiert werden. Die zentrale API für diese Automatisierung ist die Klasse de.ipcon.db.report.PrintingServices. Um den Druckprozess einzuleiten, muss das Report-Objekt über seine TID und einen neuen Datenbank-Transaktionskontext geladen werden.

In interaktiven Actions kann die Client-API-Methode ctx.showStringInputDialog() genutzt werden, um Parameter zur Laufzeit abzufragen. Benutzereingaben können vor der Übergabe typsicher in reguläre Java-Datumsobjekte konvertiert werden.

Die Engine erzwingt in den XML-Skript-Blöcken strenge Variablen-Bindings und isolierte Kontext-Scopes. Im Scope der Anker-Query steht ausschließlich die Variable loader zur Verfügung. Innerhalb der Definition von virtuellen Eigenschaften sind die Variablen bo und log injiziert. Bei Listen-Reports stellt die Engine das Basis-Array der iterierten Objekte über den Parameter $P{BOS} bereit.

Um Datenmengen zielgerichtet an JFreeChart-Diagramme oder Subreports zu übergeben, muss der Backend-Entwickler den Datenstrom manuell in eine BOsDataSource kapseln.

Sollen JFreeCharts visuell angepasst werden, kann der Code über eine dedizierte Java-Klasse programmatisch modifiziert werden. Diese Customizer-Klasse muss zwingend von JRAbstractChartCustomizer erben.

Für komplexe Sortierungen innerhalb von Crosstab-Buckets kann ein maßgeschneiderter Comparator in das Report-XML injiziert werden. Für Layout-Anpassungen von Kreuztabellen bietet JasperReports Attribute wie whenNoDataCell oder crosstabCell[isBlankWhenNull].

Die alternative AsciiDoc-Engine evaluiert den gesamten Inhalt des <Asciidoc>-Tags als einen einzigen Groovy-GString. Dem Report übergebene Parameter werden im AsciiDoc-Skript automatisch in Groovy-Variablen mit dem Präfix param_ transformiert.

Die Verarbeitung erfolgt in zwei getrennten Stufen. Zuerst löst das System den GString auf, berechnet Variablen und fügt normale Datenfelder ein. Im letzten Schritt werden spezielle Bildausdrücke ausgewertet. Dies erlaubt es, die Kriterien für Bilder dynamisch über Variablen zusammenzusetzen, bevor die Bilddatei geladen wird. Bilder, die als binäre BLOBs in der Datenbank liegen, können nativ evaluiert und in den Text gerendert werden.

Die aktive Datensprache bestimmt, in welcher Sprache die Werte in Lesezeichen, Listen und Formularen angezeigt werden. Sie lässt sich über das Menü „Ansicht → Datensprache ändern“, den Shortcut „Strg+L“ oder das Globus-Symbol in der Werkzeugleiste anpassen.

Wenn Sie einen Datensatz öffnen, werden die Texte zunächst in der aktuell aktiven Sprache angezeigt.

Weicht die aktive Datensprache von der Programmsprache ab, wird sie zur visuellen Kontrolle stets im Fenstertitel jedes Formulars und Lesezeichens in eckigen Klammern (z. B. „[DE]“) angezeigt.

Der Menüeintrag „Datensprache ändern“ im Menü „Ansicht“ öffnet den Dialog zur Sprachauswahl.

Ebenso erreichen Sie diesen Dialog über den Action-Button mit dem Globus-Symbol in der Werkzeugleiste.

Daraufhin öffnet sich ein separates Dialogfenster zur Sprachauswahl.

Wählen Sie in diesem Dialog die gewünschte Zielsprache aus und bestätigen Sie Ihre Eingabe. Sobald Sie die Sprache gewechselt haben, aktualisiert sich der Indikator im Fenstertitel. Gleichzeitig laden alle mehrsprachigen Felder im Formular oder Lesezeichen automatisch die Texte der neu gewählten Sprache.

Wechseln Sie die Sprache erneut, passen sich der Fenstertitel und die Inhalte sofort wieder entsprechend an.

Alle Eingaben, die Sie in mehrsprachigen Feldern tätigen, werden automatisch unter dieser neuen Sprache gespeichert.

Lesezeichen passen die angezeigten Werte in den Spalten für mehrsprachige Felder vollautomatisch an die aktuell gewählte Datensprache an. In der deutschen Spracheinstellung werden Ihnen die entsprechenden Daten somit auf Deutsch angezeigt.

Wechseln Sie über das Globus-Symbol oder das Ansicht-Menü in den englischen Modus, werden die Daten im Lesezeichen entsprechend mit ihren englischen Übersetzungen angezeigt.

Wird ein Datensatz aus einem englischsprachigen Lesezeichen geöffnet, stellt das System das resultierende Formular automatisch auf Englisch ein. War der Datensatz bereits in einem anderen Fenster geöffnet, rückt dieses in den Vordergrund und übernimmt sofort die neu gewählte Spracheinstellung. Dies gewährleistet eine durchgängige Konsistenz zwischen Lesezeichen und Formular, sodass Sie auch bei einem Sprachwechsel stets die richtigen Einträge pflegen.

Um diese Pflege im Formular zu erleichtern, müssen Sie auf einen Blick erkennen können, welche Datenfelder überhaupt übersetzbar sind. Nicht jedes Feld in einem Formular ist nämlich mehrsprachig, da beispielsweise eine Artikelnummer oder ein Preis sprachunabhängig ist. Zur schnellen Erkennung sind alle übersetzbaren Felder mit einem Globus-Symbol markiert.

Das System passt die Darstellung des Symbols automatisch an die Art des Eingabefeldes an, um das Formular übersichtlich zu halten und den Lesefluss nicht zu stören.

Bei einzeiligen Textfeldern wird der Globus platzsparend am rechten Rand direkt neben dem Eingabefeld platziert, ohne den eingegebenen Text zu verdecken.

Bei mehrzeiligen Textbereichen (Text Areas) befindet sich der Globus dezent rechts oben neben dem Eingabebereich. Dadurch wird kein vertikaler Platz verschwendet und das Symbol bleibt auch beim Herunterscrollen sichtbar.

Ein Hover über das Globus-Symbol blendet direkt den Text der Standardsprache in einem Tooltip ein, sofern ein solcher existiert. Zusätzlich liefert der Tooltip am unteren Rand direkt einen praktischen Hinweis zur Bedienung des Symbols.

Sollte für das Feld noch kein Text in der Standardsprache hinterlegt worden sein, weist der Tooltip stattdessen nur explizit auf die Funktion des Symbols hin.

Für die Erfassung und Pflege mehrsprachiger Daten unterstützt MyTISM zwei unterschiedliche, sich ergänzende Arbeitsabläufe, die für verschiedene Alltagsszenarien optimiert sind.

Der erste Workflow („Globale Erstanlage“) eignet sich ideal für die vollständige Erfassung neuer Datensätze. Hierbei stellen Sie die globale Datensprache der Maske einmalig auf die gewünschte Zielsprache ein, um anschließend alle Felder des Formulars nacheinander in einem Rutsch für diese Sprache zu befüllen.

Der zweite Workflow („Gezielte Detailkorrektur“) kommt bei der Bearbeitung bereits bestehender Daten zum Einsatz. Müssen Sie lediglich ein einzelnes Feld (wie die Artikelbeschreibung) in mehreren Sprachen korrigieren oder ergänzen, wäre das globale Umschalten der gesamten Maske zu aufwändig. Für diese punktuelle Pflege öffnen Sie über einen Klick auf das Globus-Symbol eines Feldes direkt den interaktiven Schnell-Editor.

Dieser Schnell-Editor ist für einen effizienten und flexiblen Arbeitsablauf konzipiert:

Für die Auswertung mehrsprachiger Daten in Lesezeichen stellt die Object Query Language (OQL) erweiterte Filter-Funktionen bereit. Da mehrsprachige Felder in der Datenbank intern als Schlüssel-Wert-Paare verarbeitet werden, bietet OQL leistungsstarke Spezial-Operatoren, um diese zu durchsuchen.

Für jedes im XML-Schema definierte mehrsprachige Feld generiert das System spezifische Zugriffsmethoden in den Entity-Klassen. Dabei wird technisch strikt zwischen dem persistenten physischen Map-Attribut (Typ L10nString, z. B. Bezeichnungen1 im Plural) und dem virtuellen Alias-Attribut (Typ L10nedString, z. B. Bezeichnung1 im Singular) unterschieden.

Die nachträgliche Umstellung eines bestehenden Textfeldes auf Mehrsprachigkeit erfordert eine technische Anpassung und ein Update des MyTISM-Systems. Dieser Vorgang umfasst die Änderung im zugrunde liegenden Datenschema sowie eine begleitende Migration der bereits vorhandenen Daten in der Datenbank.

Die Lokalisierung der Benutzeroberfläche und programmseitiger Ausgaben wird an zahlreichen Stellen systemweit unterstützt. Neben dem direkten programmgesteuerten Zugriff können Platzhalter im Format $R{key} definiert werden, die das System vor der Darstellung zur Laufzeit durch die passende Übersetzung des aktiven Locales ersetzt.

Diese Platzhalter und Übersetzungen werden in folgenden Bereichen angewendet:

Für die Lokalisierung halten Instanzen des Typs L10nPackProviderI (primär de.ipcon.tools.L10n auf Server- und Hilfsebene sowie de.ipcon.db.AbstractClient im Client) benannte Sprachpakete (L10nPack) im Speicher bereit. Diese Pakete gruppieren Textbausteine unterschiedlicher Sprachen unter eindeutigen Identifikatoren.

Wird ein $R{key}-Platzhalter aufgelöst oder L10n.msg() aufgerufen, ermittelt MyTISM automatisch eine Liste der beteiligten und relevanten Objekte des aktuellen Kontextes:

Basierend auf diesen Objekten wird eine Liste relevanter Sprachpakete (L10nPacks) erstellt und kaskadierend nach dem Schlüssel durchsucht. Der erste gefundene Treffer wird zurückgeliefert.

Das Lokalisierungssystem speichert und synchronisiert Übersetzungsdaten aus zwei physischen Quellen, die zur Laufzeit im L10nCache konsolidiert werden:

In den XML-Konfigurationsdaten von Lesezeichen, Formularen oder Schablonen werden statische Bildschirmtexte mit dem Makro $R{Schluessel} lokalisiert.

Ist der L10n-Schlüssel exakt identisch mit dem Attributnamen der Entität, generiert das System das Übersetzungslabel vollautomatisch, sodass das $R{…​}-Makro im XML entfallen kann. Lesezeichen-Filter unterstützen die Übersetzung ihrer Titel über dasselbe Makro, wie in <filter type="bool" title="$R{Erledigt}"/>.

Sollte für einen Aufruf keine gültige Übersetzung gefunden werden, zeigt das System stattdessen den rohen L10n-Schlüsselnamen in der Benutzeroberfläche an. Schlüssel müssen daher zwingend als lesbare, „sprechende Namen“ definiert werden, damit fehlende Übersetzungen eindeutig zugeordnet werden können.

Die Verwaltung aller UI-Übersetzungstexte erfolgt im Navigationsbaum unter „Admins → MyTISM → Lokalisierung → Lokalisierungs-Bündel“. Bündel sollten für eine saubere Bereichstrennung dediziert nach Fachbereichen angelegt werden (z. B. de.example.bo.Geschlecht).

Legt ein Administrator ein völlig neues Bündel manuell über die GUI an, muss zwingend das Häkchen bei „Vorgeladen“ (Preload) gesetzt und die Pfadposition auf 0 konfiguriert werden.

Für groß angelegte Massenübersetzungen durch externe Dienstleister lassen sich diese dynamischen Sprachbündel als Textdatei im .properties-Format exportieren. Die Export-Logik nutzt die Option „Locale 2“ für die Zielsprache, während die Option „Locale 1“ in der generierten Datei lediglich als auskommentierte Referenzsprache für den Übersetzer dient. Dabei sind die Standardwerte für den Export von Bündeln (wie Locales und Pfade) intelligent voreingestellt. Die physischen L10n-Bündeldateien verzichten zudem beim Export auf das Wrapping von Textwerten.

Die GUI-Maske für L10nBundle wurde zudem erweitert, um das Auffinden von Duplikaten in Core, Modulen oder im Projekt zu erleichtern und somit die langfristige Wartbarkeit zu stärken.

Bei Quertabellen berechnen die virtuellen Attribute L10nName und L10nBeschreibung ihre Übersetzungen vollautomatisch basierend auf den regulären Feldern für Name und Beschreibung über msg(getName(), [Object this]).

Auf Backend-Ebene stellt die Klasse de.ipcon.tools.L10n die primäre API für alle programmatischen Lokalisierungsprozesse der Programmsprache bereit.

Durch diesen Import steht die Methode msg() nativ für lokalisierte Exception-Messages zur Verfügung.

Für die Übergabe einzelner Textparameter existieren bequeme Kurzschreibweisen.

Übersetzungsstrings mit hochdynamischen Parameterstrukturen werden systemintern via java.text.MessageFormat aufgelöst.

Die dazugehörige .properties-Datei nutzt die choice-Logik von Java für Fallunterscheidungen und Pluralbildung.

Soll ein UI-Text völlig unabhängig von der aktuell eingestellten Oberflächensprache des angemeldeten Benutzers in einer fest definierten Sprache gerendert werden (z. B. für automatisierte Export-Dokumente), muss das gewünschte Locale explizit an die API übergeben werden.

In automatisierten Unit-Tests dürfen Systemmeldungen der Programmsprache niemals über harte Strings verglichen werden. Der erwartete Text muss stets dynamisch über das L10n-System aufgelöst werden, da der Test andernfalls auf Maschinen mit abweichendem Standard-Locale fehlschlägt.

Es muss zwingend die Variante der msg()-Methode mit drei Parametern genutzt werden, um durch die Übergabe des Entitäts-Objekts den korrekten Suchpfad zu gewährleisten.

Die entkoppelte Architektur definiert klares Systemverhalten bei Teilausfällen:

Nur Alarmsystem aktiv:
Ist das Alarmsystem aktiv, das Benachrichtigungssystem jedoch deaktiviert, werden Alarme weiterhin überwacht. Auslösende Alarme generieren MyTISMBenachrichtigungsAuftrag-Objekte, die unbearbeitet in einer Warteschlange in der Datenbank verbleiben. Wird das Benachrichtigungssystem reaktiviert, arbeitet es diese Warteschlange ab und stellt die Nachrichten nachträglich zu.

Nur Benachrichtigungssystem aktiv:
Ist das Benachrichtigungssystem aktiv, das Alarmsystem jedoch deaktiviert, werden keine automatischen, alarmbasierten Aufträge generiert. Benachrichtigungsaufträge, die auf anderem Wege im System eingehen (z. B. manuell oder per Skript), werden jedoch sofort verarbeitet. Bei einer späteren Reaktivierung des Alarmsystems werden verpasste Auslösungen – abhängig von der individuellen Konfiguration des Alarms – nachträglich nachgeholt.

MyTISM stellt vier spezifische Alarmtypen bereit.

Um die zu überwachende Objektmenge gezielt einzuschränken, nutzt das System sogenannte BOMasken. Eine BOMaske filtert die Datenbasis vor, sodass ein Alarm beispielsweise ausschließlich für Patienten auf der Intensivstation greift.

Bei allen Terminen lässt sich eine Vorwarnzeit konfigurieren, um Benachrichtigungen mit definiertem Vorlauf zum eigentlichen Ereignis zu versenden. Bei Hinweisen und Wiedervorlagen definieren Auslösekriterien präzise, auf welche Attribut-Änderungen das System reagiert (z. B. „wird gesetzt auf Wert kleiner als“).

Die primären Meldewege von MyTISM sind klassische E-Mails sowie Direkt-Benachrichtigungen im grafischen Solstice-Client. Zusätzlich unterstützt das System die Anbindung echter Hardware-Smartphones als SMS-Gateways.

Empfänger können Benutzer, Benutzergruppen oder dynamische Adressen wie die „Adresse des Patienten“ sein. Das System garantiert technisch eine strikte Deduplizierung: Ein Empfänger erhält pro Alarmauslösung exakt eine einzige Benachrichtigung, selbst wenn er über mehrere Wege adressiert wurde.

Für den Empfang von Alarmmeldungen im MyTISM-Client muss im XML-Nutzerprofil des Anwenders zwingend ein entsprechendes Plugin konfiguriert sein. Mit dem Parameter silent="yes" sammelt das Plugin neue Meldungen unaufdringlich in der Taskleiste. Die Konfiguration silent="no" öffnet hochpriorisierte Popups sofort im Vordergrund auf dem Bildschirm.

In der Benutzeroberfläche des Benutzerformulars lassen sich Adressen und kryptografische Präferenzen definieren:

Einfache Konfiguration:
E-Mail-Adressen, die im Reiter „Einfache Benachrichtigungskonfiguration“ eingetragen werden, generieren im Hintergrund automatisch MyTISMAdresseEmail-Objekte.

PGP-Konfiguration:
Im Reiter „Benachrichtigungssystem“ → „Adressen“ kann der öffentliche Schlüssel für verschlüsselte Nachrichten hinterlegt werden. Der Import erfolgt aus der lokalen Datei /.gnupg/pubring.gpg oder über einen Keyserver (Variable pgpKeyServer).

Kryptografische Präferenzen:
Es kann festgelegt werden, ob verschlüsselte/signierte Mails gewünscht sind („Nie“, „Wenn möglich“, „Zwingend“, „Standard“) oder ob das ältere Inline-Format erzwungen werden soll.

Adressen-Priorisierung und Fallback:
Empfänger-Ziele (MyTISMAdresseSolstice oder MyTISMAdresseEmail) werden über das Attribut Position priorisiert. Der Versand erfolgt der Reihe nach, bis die erste Zustellung erfolgreich ist; nachfolgende Adressen dienen als Fallback.

Die Verwaltung der Alarme erfolgt unter „Admins → MyTISM → Alarme“. Mitglieder der Systemgruppe „Admins Alarmsystem“ besitzen vollen Zugriff.

Aktivierung:
Neue Alarme werden im Status „vorbereitet“ (deaktiviert) angelegt und erst durch das Setzen der Checkbox „Alarm ist aktiv“ scharfgeschaltet.

Testmodus:
Ist das Flag „Testmodus“ aktiv, werden keine Benachrichtigungen versendet und keine AlarmAusloesung-Objekte angelegt. Das System schreibt lediglich Log-Einträge zur Simulation.

Alle Alarme verfügen über folgende grundlegende Felder:

Name / Beschreibung:
Kurzname und Hilfetext, welcher dynamisch in Benachrichtigungen verwendet werden kann.

Empfänger (CC / BCC):
Angabe von CC- und BCC-Empfängern unter Berücksichtigung der systemweiten Deduplizierung.

Benachrichtigungsvorlage:
Referenz auf die GSP-Vorlage zur Definition von Layout und Inline-Bildern.

Alte Alarme nur auslösen wenn nicht älter als:
Definiert im Reiter „Erweitert“, wie weit verpasste Auslösungen (z. B. nach einem Ausfall) in der Vergangenheit liegen dürfen, um nachgeholt zu werden.

Verantwortlicher:
Benutzer, der bei System- oder Skriptfehlern des Alarms benachrichtigt wird. Seine E-Mail-Adresse dient bei ausgehenden Mails als Absender. Ohne expliziten Verantwortlichen wird der interne System-User des Alarmsystems als Absender genutzt.

Bei Ausfall benachrichtigen:
Optionale Gruppe, die bei Skript- oder Systemfehlern zusätzlich informiert wird.

Überwachung starten ab:
Datum in der Zukunft, ab dem die Überwachung scharfgeschaltet wird.

Der „Einfache Termin“ löst zu einem festen Zeitpunkt unabhängig von Datenobjekten aus. Er kann einmalig („…​ am/um“) oder wiederkehrend („…​ wiederholen nach Muster“) per Cron-Syntax konfiguriert werden. Das System unterstützt klassische Cron-Muster (z. B. */5 für alle fünf Minuten) sowie proprietäre Makros (z. B. @weekly für Sonntag 0:00 Uhr oder 4/@lastOfM für den letzten Mittwoch im Monat).

Vorwarnzeit:
Die Benachrichtigung kann gezielt vor dem Ereignis ausgelöst werden (z. B. 15m).

System-Verhalten: Einmalige Termine werden nach ihrer Auslösung gelöscht.

Ein BO-basierter Termin überwacht eine Menge von Geschäftsobjekten und berechnet individuelle Auslösezeitpunkte. Die Objektmenge wird über eine BOMaske definiert. Der Auslösezeitpunkt wird über zwei Wege bestimmt:

Neuterminierung nach Auslösung:
Standardmäßig löst ein BBT pro Objekt nur einmal aus. Ist das Flag „Alarm bleibt auch nach Auslösung weiterhin aktiv“ gesetzt, wird nach der Auslösung ein neuer Zeitpunkt berechnet. Das Skript muss hierbei zwingend ein Datum in der Zukunft zurückliefern, um Endlosschleifen zu verhindern.

Ein Hinweis reagiert auf aktive Ereignisse in der Datenbank ohne Echtzeit-Garantie (Latenz im Sekundenbereich). Für blockierende, sofortige Reaktionen muss die Methode verifyOnServer() der jeweiligen Objekt-Klasse genutzt werden.

Einfache Hinweis-Ereignisse:

Hinweis-Ereignisse über Auslösekriterien:

Auslösekriterien definieren präzise Änderungen über drei Eigenschaften:

Mehrere Kriterien sind standardmäßig mit OR verknüpft, können aber über die Checkbox „Alle Kriterien müssen zutreffen“ mit AND verknüpft werden. Zusätzlich kann gefiltert werden, welcher Benutzer oder ob ein Mitglied einer Gruppe die Änderung durchgeführt hat.

Wiedervorlagen reagieren auf Inaktivität und prüfen, ob definierte Kriterien innerhalb einer Wartezeit nicht eingetreten sind.

Inaktivitätszeit:
Wartezeit bis zur Auslösung (z. B. 2d).

Neuterminierung nach Kriterienerfüllung:
Ist das Flag „Alarm bleibt auch nach Kriterienerfüllung weiterhin aktiv“ gesetzt, läuft die Überwachung nach einem eingetroffenen Ereignis weiter.

Neuterminierung nach Auslösung:
Ist das Flag „Alarm bleibt auch nach Auslösung weiterhin aktiv“ gesetzt, feuert die Wiedervorlage nach Ablauf der Inaktivitätszeit in wiederkehrenden Intervallen neu.

Manuelle Benachrichtigungen werden über die Schablone „MyTISM-Benachrichtigungsauftrag ohne Vorlage (Vorgebaut; Versenden)“ an Benutzer, Gruppen oder andere NotificationReceiverCollectionI versendet. Die Schablone enthält Felder für Empfänger, Betreff, Text, Zeichensatz, Priorität und Anhänge.

Platzhalter ($R{…​}) in Text und Betreff werden durch das L10n-System übersetzt. Das Benachrichtigungssystem ermittelt die Sprache (Locale) in folgender Reihenfolge:

Damit Popups im Solstice-Client angezeigt werden, muss das Plugin im XML-Profil des Benutzers eingetragen sein:

Damit Benachrichtigungen geladen werden, benötigen Benutzergruppen Leserechte auf die Schema-Klassen der Datei core-benachrichtigung.xml (u. a. MyTISMBenachrichtigung, MyTISMBenachrichtigungsAuftrag, MyTISMBenachrichtigungsVorlage). Um eigene Nachrichten zu verfassen, sind zusätzlich Erstellen- und Schreibrechte erforderlich.

Über die Einstellungen-Variable notifications.catchall kann ein globaler Standardempfänger hinterlegt werden. Dieser wird genutzt, wenn der eigentliche Empfänger gelöscht wurde, „Anmeldung verweigern“ aktiv ist oder keine konkreten Adressen hinterlegt sind.

Der Hintergrunddienst NotifyAdminsOfFailedBenachrichtigungsAuftragsService informiert Administratoren über endgültig fehlgeschlagene Benachrichtigungsaufträge. Der Verteiler wird über die Variable notification.recipients.mytismBenachAuftragFailed als komma-separierte Liste konfiguriert. Die Vorlage liegt unter /nrx/de/ipcon/resources/services/bs/NotifyAdminsOfFailedBenachrichtigungsAuftrags.bs.xml.

Administratoren können über OQL-Ausdrücke in der Suchleiste von Lesezeichen prüfen, ob Benachrichtigungen für spezifische Objekte erzeugt wurden.

Generelle Benachrichtigungsaufträge:

Alarmspezifische Aufträge:

Beide Systeme werden über die zentrale Konfigurationsdatei mytism.ini gesteuert.

Um das Versenden aller Benachrichtigungen (insbesondere E-Mails) systemweit zu stoppen, muss das Benachrichtigungssystem in der mytism.ini deaktiviert werden:

Die Drosselung wird pro Übertragungskanal konfiguriert:

Fehlen diese Parameter, greifen die Standardwerte (sendingRateLimitCheckDurationInSecondsDefault=60, sendingRateLimitMaxSendingCountDefault=120), was maximal 120 Benachrichtigungen innerhalb von 2 Minuten erlaubt.

Um das Rate Limiting vollständig abzuschalten, muss mindestens ein Parameter auf den Wert -1 gesetzt werden:

Ist der Parameter gesetzt, führt das System vor jedem Versand eine millisekundengenaue Prüfung durch. Ist eine Nachricht zum Sendezeitpunkt mindestens eine Millisekunde älter als die definierte Anzahl an Tagen, wird sie verworfen.

Treten beim Versenden Fehler auf, erhalten Aufträge den Statuscode 3 (WAITING_FOR_RETRY) und das System versucht in 30-Minuten-Intervallen einen erneuten Versand. War die Versendung erfolgreich, wird der Status auf 4 (SUCCESSFULLY_SENT) gesetzt. Fehlgeschlagene Solstice-Popups bei abgemeldeten Benutzern lösen keinen Retry aus.

Administratoren prüfen fehlgeschlagene Aufträge im Lesezeichen „Admins/MyTISM (Vorgebaut)/Benachrichtigungen/MyTISM-Benachrichtigungsaufträge (Vorgebaut)“ über den Filter „Mit 'echten' Fehlern“.

Das SMS-Gateway basiert auf der Android-App „Android SMS Gateway“ und wird über ein physisches Smartphone betrieben.

BOMasken mit reinen Groovy-Skripten belasten das System, da jedes Objekt einzeln ins RAM geladen wird (O(N)). Bevorzugen Sie OQLBOMasken oder GrooqlBOMasken, da diese direkt auf Datenbankebene filtern.

Müssen Skripte verwendet werden, sind „Early Exits“ vorgeschrieben. Prüfen Sie billige Attribute immer zuerst, bevor teure Abfragen (Many-Relationen) ausgewertet werden:

Die PostgreSQL-Systemtabelle bas verwaltet Auslösezustände für BBTs und Wiedervorlagen und wird direkt über SQL-Ebene gepflegt.

Hat ein BBT für ein Objekt nicht ausgelöst:

Bei der Alarmauslösung wird zuerst die Methode trigger() der Alarm-Klasse aufgerufen. Liefert diese true, wird die Auslösung als abgearbeitet betrachtet; Benachrichtigungsskripte und Standard-Benachrichtigungen werden übersprungen. Standardklassen liefern false zurück.

Sollen E-Mails programmatisch Dateien angehängt werden, muss die Klasse das Interface de.ipcon.messaging.email.DataSourceConvertibleI implementieren.

Alternativ kann die Klasse MyTISMAnhangBOEintrag verwendet werden, um ein lesbares PDF zu generieren.

Wird der Anhang über ein Groovy-Skript gesteuert:

Zur Erstellung von Aufträgen steht eine Fluent API zur Verfügung (alternativ auch ein Builder-Pattern):

Für Aufträge ohne Vorlage existieren Setter wie .setSubjectSource und .setSubjectSourceIsFixed. Wird api.sendNotification aufgerufen und der Auftrag ist nicht neu oder wurde mit abweichender Transaktion erstellt, wirft das System eine IllegalStateException.

Aufträge werden nach strikten Regeln versendet:

Bedingte Alarme ignorieren Änderungen an Entitäten wie Alarm, AlarmAusloesung, MyTISMBenachrichtigung und MyTISMBenachrichtigungsauftrag (inklusive aller Subklassen), um kaskadierende Endlosschleifen zu verhindern.

Das System unterscheidet architektonisch zwischen zwei Arten der Löschung. Das weiche Löschen (Soft Delete) markiert Datensätze über die Benutzeroberfläche im Hintergrund lediglich als „gelöscht“, entfernt sie jedoch nicht physisch. Dies ermöglicht die sofortige Wiederherstellung bei fehlerhaften Eingaben, erfüllt jedoch nicht die gesetzlichen Anforderungen zur Datenvernichtung.

Für die gesetzeskonforme Vernichtung existiert das harte Löschen (Purge). Ist eine gesetzliche Aufbewahrungsfrist abgelaufen, erzwingt dieser Vorgang das unwiderrufliche physische Entfernen des Datensatzes aus der Datenbank.

Die DSGVO-Architektur basiert auf ineinandergreifenden Parametern:

Ein Hintergrunddienst berechnet die Löschfristen ressourcenschonend asynchron, um zeitkritische Prozesse wie das Speichern medizinischer Befunde nicht zu blockieren. Geringfügige Fristüberschreitungen werden dabei toleriert.

Zusätzlich greift das Lösch-Vetorecht: Entfällt der primäre Verarbeitungszweck eines Datensatzes, kann ein verknüpfter Datensatz die Löschung blockieren. So verhindert eine unbezahlte, abrechnungsrelevante Rechnung die Löschung der verknüpften Patientenakte.

Zwei Dienste überwachen den Datenlebenszyklus:

Die Dienste werden über die reguläre BS-Maske angelegt und mit einem CronJob versehen. Die XML-Konfigurationen für das <Sync>-Feld finden sich unter /nrx/de/ipcon/resources/services/bs/.

Der Task zur endgültigen Löschung (de.ipcon.db.Purger) wird ausschließlich im Abschnitt [Purger] der Datei mytism.ini gesteuert. Das System erzwingt die 30-Tage-Karenzzeit. Als Sicherheitsmechanismus berechnet der Purger das erwartete Löschdatum unmittelbar vor dem Löschvorgang zwingend neu. Nur bei exakter Übereinstimmung mit dem in der Datenbank gespeicherten Datum wird der Datensatz gepurged. Abweichungen aktualisieren lediglich den Datenbank-Eintrag.

Wiederverwendbare rechtliche Konstrukte werden im XML-Schema als globale Elemente definiert. Elemente wie <GDPRProcessingPurpose>, <GDPRLaw>, <GDPRDataCategory>, <GDPRBusinessInterest>, <GDPRProcessingLegalBasis> und <GDPRRetentionPurpose> werden zwingend als direkte Unterelemente des Wurzelknotens <Schema> platziert und niemals innerhalb von Entitäten verschachtelt.

Ein <GDPRBusinessInterest> repräsentiert das legitime Geschäftsinteresse. Der <GDPRProcessingPurpose> definiert den Verarbeitungszweck, der über <LegalBasis> eine gesetzliche Grundlage referenziert.

Für das referenzierte Gesetz (<GDPRLaw>) verlangt das Attribut country zwingend den ISO 3166-1 alpha-2 Ländercode. Über url kann ein Weblink zur Online-Ressource hinterlegt werden.

Diese Bausteine werden abschließend in einer <GDPRDataCategory> gebündelt.

Die <GDPRDataRetentionPolicy> legt Fristen und Regeln für eine Datenkategorie fest. Die Angabe der gesetzlichen Grundlage über ein <Law>-Tag ist zwingend erforderlich.

Die Dauer (period) wird case-insensitive angegeben (z. B. "10y"). Der Startzeitpunkt (start) kann calendar_year_end, business_year_end oder custom sein. Auslöser (trigger) sind Ereignisse wie termination (Vertragsende), creation oder last_transaction. Das Datenprüfintervall auf Löschfähigkeit wird über evaluationFrequency definiert. Dokumentierend sind lastAssessmentDate (letzte rechtliche Bewertung) und rightsAndFreedomsAssessed (ob Betroffenenrechte und -freiheiten bei Fristfestlegung formell abgewogen wurden).

Entitäten müssen zwingend mit einem <gdpr>-Tag ausgestattet werden, welches die Entität mit einer Datenkategorie verknüpft. Das Element <affectedPerson> referenziert die betroffene Person. Ohne expliziten retentionStartDatePath gilt das Erstellungsdatum als Startpunkt.

Das Element <retentionVeto> definiert Verknüpfungen zu Datensätzen, die ein Lösch-Veto einlegen können.

Überwachte Entitäten müssen das Core-Interface GDPRRelevantBaseI implementieren. Zusätzlich stellt die Klasse de.ipcon.db.core.GDPRRelevantI Hilfsmethoden bereit.

Das Interface erzwingt auf Datenbankebene zwei Attribute:

Die Sicherheitsmarge von 30 Tagen ist in der Backend-Konstante GDPRTools.SAFETY_MARGIN_DAYS_BEFORE_DELETION verankert.

Die Klassen GDPRRetentionInitService und GDPRRetentionUpdateService im Package de.ipcon.db.gdpr erben von GDPRRetentionService und arbeiten chronologisch.

Der Initialisierungsdienst liest die Konfiguration aus dem Schema-XML und identifiziert alle relevanten Entitäten. Er berechnet das frühestmögliche Löschdatum und speichert dieses sowie den Zeitstempel der Berechnung ab.

Der Aktualisierungsdienst operiert iterativ in konfigurierten Zeitintervallen. Er berechnet das Datum für relevante Entitäten komplett neu. Nur bei einer Abweichung zum aktuell gespeicherten Datum wird ein Schreibvorgang ausgelöst.

Da Soft-Delete-Objekte physisch verbleiben, müssen Entwickler in eigenen OQL-Abfragen zwingend den Zusatz WHERE NOT Ldel verwenden. Wird dies vergessen, verarbeitet das System weich gelöschte Daten, was zu kritischen Fehlinformationen führt.

Das Rechtesystem basiert auf dem Architektur-Konzept der Positivliste. Im Grundzustand verfügt ein Benutzer über keinerlei Rechte im System; er sieht weder Daten noch Formulare. Zugriffsberechtigungen müssen explizit und gezielt gewährt werden.

Jede Berechtigung basiert auf vier Parametern:

Die Definition von Berechtigungen erfolgt im Formular der jeweiligen Gruppe im Reiter „Rechte-Zuweisungen“. Über sogenannte BO-Masken wird definiert, auf welche Datenbestände zugegriffen werden darf. Das System erlaubt hierbei eine feingranulare Steuerung auf Spaltenebene. Über Konfigurationsfelder können Rechte auf einzelne Attribute isoliert werden, um beispielsweise den Lesezugriff auf eine Patientenakte zu gewähren, während das Attribut „Diagnose“ für diese Gruppe verborgen oder schreibgeschützt bleibt.

Um Befugnisse hart zu entziehen, wird das Flag „Ablehnen“ bei der Aktion gesetzt. Dieses Flag wirkt als absolutes Veto, das sämtliche Rechte überschreibt, die dem Nutzer eventuell durch andere Gruppenmitgliedschaften gewährt wurden. Das Flag „Ablehnen aufheben“ deaktiviert ein solches Veto für privilegierte Benutzergruppen gezielt. Technische Voraussetzung hierfür ist, dass die aufhebende Zuweisung exakt dieselbe BO-Maske und dieselben Aktions-Flags besitzt wie die ursprünglich verbietende Zuweisung.

In den Ordnereinstellungen lässt sich die Sichtbarkeit für bestimmte Gruppen definieren; eine leere Liste beschränkt den Zugriff standardmäßig auf Administratoren. Innerhalb von Strukturelementen steuert die Relation „Gruppen“ (im XML über das Tag <Gruppen>) die Sichtbarkeit im Navigationsbaum, unabhängig von den eigentlichen Datenrechten.

Zusätzlich kann jedem Strukturelement ein Groovy-Skript zur dynamischen Sichtbarkeitssteuerung angehängt werden, in das die Variablen user und struktur injiziert werden.

Die Verwaltung von Anwendern erfolgt im Navigationsbaum unter „Admins → MyTISM → Benutzerverwaltung“. Werden systemweite GUI-Verhaltensweisen über „Einstellungen-Variablen“ konfiguriert und an Benutzer oder Gruppen gebunden, greift eine harte Priorisierung.

Damit die Priorisierungskette evaluiert wird, muss in der Definition der Variable das Flag „Ueberschreibbar“ gesetzt sein. Ist dieses Flag nicht aktiv, ignoriert das System alle benutzer- oder gruppenspezifischen Zuweisungen und erzwingt global den Standardwert. Ist das Flag aktiv, gilt folgende Priorität:

Um bei tausenden Systembenutzern die Übersicht zu wahren, gruppiert MyTISM den Ordner „Alle GUI-Benutzer“ anhand globaler UI-Parameter automatisch.

Während GUI-Rechte statisch konfiguriert werden, erlauben Hooks in der BO-Klasse dynamische Evaluierungen zur Laufzeit. Schreibrechte werden in einer fest definierten Hierarchie geprüft: Zuerst wird das Schema-XML ausgewertet (z. B. readonly="true" oder virtuelles Attribut). Gibt diese Basis-Prüfung false zurück, evaluiert die Engine den PermissionHandler, um Gruppenrechte und BO-Masken zu prüfen.

Über die Methode isReadOnly() lassen sich Attribute programmatisch sperren.

Analog erzwingt die Methode isMandatory() Pflichtfelder programmatisch auf Backend-Ebene.

Wird in einer BOMaske ein Skript hinterlegt, injiziert der Server zur Laufzeit die Variablen bo, schema, entity, att, maske, user und log in den Auswertungskontext.

Einfache Skript-Masken sind ineffizient, da das Skript für jedes Objekt bei jedem Datenzugriff im Arbeitsspeicher iterativ ausgewertet werden muss. Die Lösung ist das Two-Step-Filtering der GrooqlBOMaske: Im ersten Schritt wird das Skript auf SQL-Ebene in eine OQL-Abfrage transformiert, um eine Datenbankvorfilterung zu erzielen. Im zweiten Schritt führt die Methode fits() auf Java-Ebene die finale Evaluierung im Speicher durch.

Die OQLBOMaske verlagert die Filterung exklusiv in die Datenbank. Sie nutzt keine Groovy-Skripte, sondern leitet direkte OQL-Klauseln aus dem Feld WhereClauses ab. Aufgrund der nativen Evaluierung auf Datenbankebene ist die OQLBOMaske für systemkritische Hintergrunddienste stets die performanteste Architektur-Wahl.

Hintergrunddienste agieren proaktiv und autonom im System. Sie ermöglichen beispielsweise den automatisierten nächtlichen Import von Systemdaten, den selbstständigen Versand von Benachrichtigungen oder die kontinuierliche Überwachung von Beständen. Diese Auslagerung von Routineaufgaben in den Systemhintergrund reduziert menschliche Fehler und entlastet die Anwender im operativen Betrieb signifikant.

Jeder Business Service erfordert zwingend die Angabe eines Verantwortlichen sowie einen beschreibenden Namen. Im Feld „Bei Ausfall benachrichtigen“ kann eine Administrator-Gruppe definiert werden, die bei Skriptfehlern alarmiert wird. Für reguläre Skripte muss im Feld „Java-Klasse“ der Standardwert de.ipcon.db.sync.ScriptService hinterlegt werden. Ein „Business Node“ repräsentiert in der Architektur die physische Server-Instanz beziehungsweise den Netzwerkknoten.

Die zeitliche Ausführungsvorschrift wird über ein XML-Snippet in klassischer Cron-Syntax gesteuert. Das folgende Beispiel konfiguriert eine tägliche Ausführung um exakt 15:10 Uhr:

Der Parameter interrupt="true" erzwingt den Abbruch eines noch laufenden Prozesses desselben Jobs bei der nächsten fälligen Ausführung. Der Standardwert false erlaubt parallele Überschneidungen, beispielsweise bei langlaufenden Datenimporten.

Neben der Cron-Syntax sind erweiterte Makros zulässig: @yearly (1. Jan, 0:00 Uhr), @monthly (Erster des Monats), @weekly (Sonntag, 0:00 Uhr), @daily (Mitternacht) und @hourly (volle Stunde). Ein Intervall wie */5 im Minuten-Feld definiert „alle 5 Minuten“. Schrittweiten wie 0-23/2 im Stunden-Feld definieren „jede zweite Stunde“. Spezielle Wochentags-Definitionen wie @lastOfM oder @lastOfY sind ebenfalls möglich (z. B. 4/@lastOfM für den letzten Mittwoch des Monats).

Eine Ausführungsvorschrift kann den Dienst auch als ununterbrochenen Dauerläufer deklarieren, was für Echtzeit-Schnittstellen erforderlich ist:

Die Logik des Dienstes wird im Reiter „Script“ in einem XML-Knoten hinterlegt. Der Groovy-Code wird in ein <Sync>-Tag sowie einen CDATA-Block eingebettet.

Fest vorgegebene Systemwerte werden als XML-Dateien (.initialdata.xml) in den Modul-Ordnern deklariert und beim Serverstart automatisch importiert. Die Grundstruktur definiert die zu befüllenden Datenbankspalten.

Bei der Spaltendefinition im <column>-Tag ist keine explizite Datentypangabe erforderlich. Alle Werte im Daten-Block müssen in doppelte Anführungszeichen gesetzt und durch Semikolons getrennt werden. Das Parsing ist intern an die deutsche System-Locale gebunden; für Fließkommazahlen muss daher zwingend das Komma als Dezimaltrennzeichen verwendet werden. Für mehrzeilige Inhalte müssen Zeilenumbrüche als \n escaped und im <column>-Tag das Attribut replaceEscaped="true" gesetzt werden.

Über ein integriertes Groovy-Skript lässt sich das Update-Verhalten steuern:

Die Methode start() importiert ausschließlich fehlende Werte und ignoriert bestehende Datensätze (Standard). Die Methode importAndUpdateExisting() importiert fehlende Werte und überschreibt bestehende Datensätze zwingend. Die Methode updateExistingOnly() aktualisiert ausschließlich bereits vorhandene Einträge.

Hintergrunddienste werden im Backend als Subklassen der Basisklasse de.ipcon.db.sync.ScriptService implementiert. Die Engine injiziert implizit folgende API-Methoden und Variablen in die Skriptumgebung:

Aus Performance-Gründen nutzen Hintergrunddienste kein aktives Event-System, sondern basieren auf einem ressourcenschonenden Polling-Mechanismus. Datenschutz-Dienste lauschen nicht auf Änderungen, sondern pollen relevante Datensätze in ihren festgelegten CronJob-Intervallen auf neuen Berechnungsbedarf.

Komplexe Initialdaten-Szenarien erfordern Groovy-Logik innerhalb des <script>-Tags.

Beim Skripten von Initialdaten gelten zwei architektonische Restriktionen. Erstens kann die Spalte vattrName für Core-Entitäten nicht verwendet werden, da für diese Module keine projektspezifischen Custom-Klassen mit den erforderlichen Konstanten generiert werden können. Zweitens unterstützt der XML-Parser das direkte Initialisieren von 1:n- oder n:m-Relationen nativ nicht. Solche komplexen Verknüpfungen müssen als Workaround manuell über Groovy-Closures im Skript-Block iteriert und relationiert werden.

Die Bereitstellung der Deploy-Seite erfolgt zentral in der mytism.ini. Fehlt die Sektion [DeploySite], greift das System auf die Basiswerte der jetty.xml zurück. Der Parameter useCauldron steuert das Architekturmodell (0 für isolierte Deploy-Instanz, 1 für Bündelung mit APIs).

Der Parameter requireAuthentication regelt den zwingenden Web-Login. Bei 1 muss sich ein Benutzer authentifizieren und berechtigt sein. Bei 0 ist die Seite öffentlich erreichbar, jedoch blendet MyTISM den Reiter „Dokumentation“ aus Sicherheitsgründen vollständig aus.

Um den Server vor Überlastung zu schützen, greifen weitreichende Netzwerklimits. Die Parameter backlog bzw. tlsBacklog definieren das harte Limit der ServerSocket-Warteschlange (Standard: 10), um abgewiesene Verbindungen schnellstmöglich zu verwerfen.

Das System wartet maximal 210.000 Millisekunden (gesteuert durch maxWaitForAuth) auf die Anmeldung eines Clients, bevor die Verbindung getrennt wird.

Zusätzlich greift eine zweistufige IP-Quota: Der Parameter softMaxUnauthedBCHPerIP fungiert als weiche Grenze (Standard: 50 unauthentifizierte Verbindungen derselben IP). Ab diesem Wert wird jede weitere Anfrage um den Faktor delayFactorUnauthedBCH (Standard: 200ms) verzögert. Der Parameter hardMaxUnauthedBCHPerIP blockiert bei 150 parallelen Verbindungen derselben IP sofort alle weiteren Versuche.

In Produktionsumgebungen wird Cauldron hinter einem Reverse-Proxy (Nginx) betrieben. Der Parameter host in der mytism.ini muss dann zwingend auf localhost gesetzt werden, damit die Applikation nicht nach außen offensteht.

Im Multi-Node-Clusterbetrieb werden weder Session-Daten noch der Applikations-Cache zwischen den Knoten synchronisiert. Daher muss im upstream-Block der Nginx-Konfiguration zwingend ip_hash (Sticky Sessions) aktiviert werden, um einen Split-Brain-Zustand und den Verlust der Authentifizierung zu vermeiden.

Statische Frontend-Dateien sollten direkt über Nginx ausgeliefert werden. Für WebSockets müssen in der Konfiguration Upgrade-Header zugelassen werden.

Für eine verschlüsselte HTTPS-Verbindung müssen Administratoren in der Backend-Definition (cauldron.conf) Zertifikatsdaten hinterlegen.

Die spezielle Bookmark-API dient als dedizierte Schnittstelle, um Lesezeichen dynamisch an Drittanwendungen auszuliefern. Für die Validierung zustandsloser Tokens (JWT) muss in der mytism.ini ein Schlüsselverzeichnis hinterlegt werden.

Diese Zugriffstokens werden administrativ über das Kommandozeilen-Tool generiert und kapseln die interne Gruppen-ID als Claim.

Die Konfiguration projektspezifischer REST-APIs erfolgt über die Datei cauldron.conf. Sobald die Datei existiert, werden programmierte Änderungen zur Laufzeit überwacht und sofort wirksam.

Der application-Block repräsentiert einen isolierten Context. Ein kritischer Parameter für interaktive Frontends ist der sessionStore: Da Cauldron bei Änderungen einen internen Neustart durchführt, gehen Benutzersitzungen verloren, sofern sie nicht über den sessionStore gesichert werden.

Das API-Routing folgt dem CRUDL-Paradigma. Verzeichnisse müssen englische Substantive im Plural sein (z. B. /patients). URLs müssen der Konvention /<Ressourcenname-Plural-Englisch>/<id|action|nix> folgen. Jede HTTP-Aktion muss als separates Groovlet vorliegen: create.groovy, read.groovy, update.groovy, list.groovy und delete.groovy. Die Methode GET dient ausschließlich dem Abfragen von Ressourcen und darf niemals sensible Daten in der URL transportieren.

Das Routing wird von oben nach unten abgearbeitet. Neben HTTP-Methoden (get, post) existiert das Verb ws (WebSockets) und das universelle Verb all. Dynamische URL-Bestandteile werden durch Platzhalter (@) deklariert; reguläre Ausdrücke durch einen Doppelpunkt (:).

Das Verb ignore: weist Cauldron an, einen passenden Request stillschweigend abzubrechen. Spezifische HTTP-Statuscodes werden über error: gesendet (es existiert kein Mechanismus für Custom-Fehlerseiten).

Eigenprogrammierte Filter müssen zwingend das Java-Interface javax.servlet.Filter implementieren.

Zudem lässt sich ein Validierungs-Closure für Login-Pflichten erzwingen.

Die Entwicklung eines Servlets folgt einem 4-Phasen-Modell:

Cauldron injiziert die Variablen params und headers. Es existieren keine hartcodierten Obergrenzen für HTTP-Header. Über application.properties erhält der Entwickler Zugriff auf eine ConcurrentHashMap für applikationsweites In-Memory-Caching. Für die Datenausgabe werden html und json injiziert; Variablen werden beim HTML-Rendering nicht automatisch escaped (Gefahr von Cross-Site Scripting).

Um Code-Duplizierung zu vermeiden, kann eine mit @groovy.transform.BaseScript(Superklasse) annotierte abstrakte Superklasse verwendet werden. Die Annotation muss auf einer Package-Deklaration oder einem expliziten Import-Statement platziert werden.

Die Variable dbm repräsentiert die zentrale Datenbank-Verbindung. Das hart konfigurierte Limit für gleichzeitige Datenbankverbindungen liegt bei 128 (Timeout: 10.000 Millisekunden). Jede aktive Verbindung wird nach maximal 300.000 Millisekunden zerstört.

Daten müssen zwingend über queryBO() abgefragt werden (direkte String-Konkatenation für SQL-Befehle ist verboten).

dbm ist ein nicht-cachender Loader; Entitäten mit derselben ID erzeugen unterschiedliche Java-Instanzen. Für komplexes Caching muss der dbm über einen CachingBOLoader gekapselt werden.

Sollen Objekte in eine neue Transaktion überführt werden, muss tx.frapBOFromCache() genutzt und das Ergebnis zwingend neu zugewiesen werden. Das direkte Überführen eines Objekts via include() in eine zweite Transaktion wirft eine harte Exception.

In Cauldron wirft die Änderung eines Business Objects ohne vorheriges tx.includeBO() eine Exception (im Gegensatz zum Solstice-Client, der eine Persistierung lautlos ignoriert).

Für Entwicklungszwecke (z. B. mit React) kann Cauldron über export CAULDRON_ENVIRONMENT="development" konfiguriert werden. Bei der Einbindung über Symlinks müssen deklarierte Pfade ggf. relativ umgeschrieben werden. Ein lokaler Nginx muss so konfiguriert werden, dass er bei unbekannten Pfaden auf die index.html des Frontends zurückfällt.

In XML-Definitionen sind Attribute wie displayProperty (ersetzen durch property), displayFormat (format) und leftClass (leftEntity) veraltet. displayClass ist gestrichen. Standardwerte werden über initDefaults() definiert, nicht mehr über default="…​". Das Attribut showFtsPopup bei Lesezeichen ist obsolet und im Backend ist die parameterlose Variante der Methode getDataSource() weggefallen. Für Tests wird heute der TestBOLoader mit nativem queryInterceptor anstelle der ausgemusterten Klasse MockTransaction verwendet.

Der MyTISM Server lebt für gewöhnlich vollständig in seinem eigenen Projektverzeichnis. Übersicht über die Standarddatei- und Ordnerstruktur.
Je nach Projekt und Server können weitere Dateien notwendig und vorhanden sein.

Das Vorhandensein bestimmter leerer Systemdateien im Projektverzeichnis signalisiert dem Server, dass ressourcenintensive Initialisierungen bereits in der Vergangenheit erfolgreich durchgeführt wurden. Administratoren können diese Dateien löschen, um beim nächsten Neustart eine zwingende Prüfung oder Neuanlage zu erzwingen.

Über den Abschnitt [DBMan] in der Datei mytism.ini lässt sich das Startverhalten feinjustieren. Langwierige System-Checks können durch die Zuweisung des Wertes 1 explizit unterdrückt werden.

Sollen sehr große Tabellen aus Performancegründen vom Doppel-ID-Check ausgeschlossen werden, können diese kommagetrennt definiert werden.

Um eine lokale synchronisierende Instanz für Testzwecke zu betreiben, muss der Server explizit als nicht-autoritativ konfiguriert werden.

Der Datenbankmanager (DBMan) loggt den Startvorgang und die Skript-Ausführungen in der Datei daily.log im Verzeichnis /.<projektkuerzel>/logs/. Die Log-Level werden zentral in der Datei log4j.conf konfiguriert.

Die verteilte Systemarchitektur basiert auf physischen Rechner-Knotenpunkten (Business Nodes) und organisatorischen Einheiten (Business Units). Ist beim Start in der mytism.ini und der .init-syncaccount keine nodeID hinterlegt, sucht die Methode DBMan.assureServerBN automatisch nach einem Node, der zum Hostnamen passt, oder legt diesen an und persistiert die ID in der mytism.ini.

Business Units (BU) sind abstrakte Entitäten zur Generierung autarker Nummernkreise für eindeutige Identifikationsmerkmale (z. B. Rechnungsnummern). Ist der Maximalwert eines Bereichs überschritten, liefert die Abfrage null zurück, was von der aufrufenden Logik zwingend abgefangen werden muss.

Business Units dürfen zwingend nur serverseitig in der Methode verifyOnServer() zugewiesen werden, um ID-Kollisionen zu verhindern.

Bei der Implementierung muss der Synchronisations-Status berücksichtigt werden. Über tx.isSyncMode() muss geprüft werden, ob die Transaktion gerade durch einen Netzwerk-Sync empfangen wird. Ist dies der Fall, dürfen im Code absolut keine Seiteneffekte (wie weitere Datenänderungen oder Exceptions) ausgelöst werden, da dies die Integrität der Netzwerksynchronisation zerstört.

Der Coredata-Generator (de.ipcon.schema.generators.CoreData) orchestriert den strukturellen Systemstart im Backend. Er befüllt die globale Tabelle der Basis-Objekt-Typen (BOT), legt den initialen Administrator an und generiert Basis-Formulare, Sammelordner, Standard-Druckziele sowie Standard-Reports.

Zusätzlich importiert der Generator vorgebaute Strukturelemente aus dem Projektpfad de/ipcon/db/core/resources anhand der kompilierten Liste ResourceIndex. Der Import erfordert spezifische Dateiendungen (.bkm, .frm, .tpl, .rpt, .bst) sowie den exakten Elementtyp als XML-Root-Knoten.

Die Klasse DBMan koordiniert die chronologische Ausführung von System-Updates. Update-Skripte unterliegen einer strikten Namenskonvention (YYYY-MM-DD-XXX_Migration.orm oder .sql), um die Ausführungsreihenfolge technisch zu erzwingen. Fehlt diese Konvention, ist die Ausführung undefiniert und führt zu Abhängigkeitsfehlern. Erfolgreich ausgeführte Skripte werden in der internen Datenbanktabelle bupd protokolliert.

Bei einer leeren, neuen Datenbank überspringt das Backend historische Migrationen und loggt diese lediglich als erledigt. Auf bestehenden Systemen greift ein zweistufiger Prozess:

Stage 1:
Das System führt ausschließlich SQL-Skripte aus. Stößt es auf das erste .orm-Skript, pausiert die Skriptausführung. Der Schema-Generator gleicht nun die Datenbank an das aktuelle XML-Modell an. Ungefährliche Aktionen (z. B. neue Spalten) werden sofort ausgeführt; zerstörerische Aktionen (Spaltenlöschungen, Typänderungen, neue Indizes) werden blockiert und aufgeschoben.

Stage 2:
Das System führt die .orm-Skripte aus, welche die volle Persistenzschicht und interne Validierungslogik der Objekte nutzen. Wirft ein Skript eine ServerRestartRequiredException oder folgt auf ein .orm-Skript ein weiteres SQL-Skript, erzwingt das Backend einen kontrollierten Neustart und setzt die Abarbeitung danach nahtlos fort. Unbehandelte Exceptions führen zum harten Abbruch des Serverstarts.

Erst nach erfolgreichem Abschluss aller Skripte führt das System die aufgeschobenen, zerstörerischen Schemaanpassungen aus.

Bei schemaverändernde Migrationen hilft die Klasse de.ipcon.db.update.UpdateHandlerTools.

Bei der Umbenennung ganzer Entitäten muss die spezialisierte Methode renameEntity genutzt werden.

Das System stellt implizite Standard-Imports zur Verfügung und erlaubt über das injizierte stmt-Objekt die Ausführung nativer SQL-Befehle.

Vor komplexen Migrationen müssen programmatische Existenz-Prüfungen genutzt werden.

Der Integrity-Check repariert beim Serverstart verwaiste Relationen und korrupte Transaktionshistorien, beispielsweise wenn sich Entitätstypen im Schema geändert haben oder weggefallen sind. Reparatur-Transaktionen erscheinen im Log legitimerweise als gelöscht (Ldel). Sie werden regulär über das Netzwerk synchronisiert, bleiben in GUI-Lesezeichen jedoch absichtlich unsichtbar.

Backend-Entwickler können Systemprüfungen aus einem Update-Skript heraus für den nächsten Neustart erzwingen.

Werden Tabellen manuell via SQL verschoben und der Integrity-Check ist deaktiviert, korrumpiert die Transaktionshistorie. Metadaten müssen in diesem Fall zwingend manuell repariert werden.

Die Konfiguration der Download-Seite erfolgt in der Sektion [DeploySite] der mytism.ini. Fehlt die Sektion, greift das System auf die internen Einstellungen der jetty.xml zurück.

Der Parameter requireAuthentication regelt den Login-Zwang. Steht der Wert auf 1, müssen sich Benutzer mit dem Solstice-Passwort legitimieren und zwingend Mitglied der Gruppen „Admins“, „RG_Solstice_Login“ oder „RG_Deploy“ sein. Bei 0 ist die Seite öffentlich zugänglich; der Reiter „Dokumentation“ wird aus Sicherheitsgründen ausgeblendet, es sei denn, der Aufruf erfolgt über „localhost“.

Der Parameter reauthEveryXDays definiert die Gültigkeit des Dawn-Tokens (Standard: 90 Tage) für den Zugang zur Deploy-Seite. Dies betrifft nicht den Login im Solstice-Client; eine gecachte Applikation kann offline problemlos gestartet werden.

Der Parameter useCauldron=1 weist das System an, die interne Webserver-Instanz für die Deploy-Seite mitzunutzen. Ein Wert von 0 startet isoliert einen separaten Mini-Server.

Im Nginx muss der HTTP-Header zwingend gesetzt werden:

Für ein individuelles Client-Logging muss im Home-Verzeichnis des Benutzers ein Konfigurationsordner angelegt werden, der dem Java-Paketnamen entspricht (z. B. ~/.com.oashi.m). Die dort abgelegte Datei client-log.conf wird von Dawn erkannt und anstelle der Standardkonfiguration angewendet.

Dawn splittet Verzeichnisse zur Speicheroptimierung. Die Executable und Desktop-Verknüpfungen liegen im Profilverzeichnis (Windows: %USERPROFILE%\appdata\roaming\, Linux: ~/.local/share/dawn/). Der Cache (JRE und JAR-Module) wird ausschließlich lokal abgelegt (Windows: %USERPROFILE%\appdata\local\dawn\, Linux: ~/.cache/dawn/), unterteilt in die Ordner app/ und jre/.

Dawn lässt sich über die Kommandozeile fernsteuern, was Headless-Aufrufe via SSH ermöglicht. Der Befehl dawn help listet alle Optionen auf.

Der Befehl remove -headless entfernt die Applikation aus dem Cache. Verschwindet der letzte referenzierende Hardlink auf eine JAR-Datei, wird diese endgültig gelöscht. Für eine restlose Bereinigung müssen die Verzeichnisse unter AppData (respektive ~/.cache und ~/.local) manuell gelöscht werden. Zur Speicheroptimierung diene die Parameter -run-keep und -log-keep (Aufbewahrungsfrist für Run-Verzeichnisse, Client-Logs und interne Dawn-Logs in Sekunden).

Dawn ist installationsfrei und hinterlässt daher weder versteckte Registry-Keys, noch geplante Windows-Aufgaben oder anderweitige systemweite Spuren.

Alle Binärdateien werden isoliert im Pile-Verzeichnis (~/.cache/dawn/pile/) abgelegt. Der Dateiname generiert sich aus dem Originalnamen und Teilsegmenten des SHA256-Hashes, um Dateinamenskollisionen über Server hinweg auszuschließen. Werden identische Standard-Bibliotheken in unterschiedlichen Projekten mit projektspezifischen Keys signiert, verändert sich der Hash; Dawn behandelt diese als unterschiedliche Artefakte.

Zur Speicherschonung erzeugt Dawn im Laufzeitverzeichnis keine physischen Kopien, sondern Inode-Hardlinks, die auf die Originaldateien im Pile referenzieren. Hardlinks wurden gewählt, da Softlinks unter Windows Administrator-Rechte erfordern. Dies dedupliziert den Speicherverbrauch lokal innerhalb eines Benutzerprofils.

Auf Multi-User-Systemen (z. B. Terminalserver) existiert kein globaler Shared Cache. Caches liegen exakt so oft auf der Festplatte, wie es aktive Benutzerprofile gibt. Manifest-Dateien (*.ds) und die log4j.conf bilden eine Ausnahme und werden physisch kopiert.

Die Garbage Collection läuft asynchron. Dawn startet die Java Virtual Machine (JVM) und pausiert den eigenen Aufräum-Thread kurzzeitig, um Systemressourcen während der Bootphase zu schonen. Anschließend löscht der Prozess verwaiste Binärdaten im Pile und tote Laufzeitverzeichnisse.

Die finale DawnSpec (solstice.ds) existiert auf dem Server physisch nicht; ein Backend-Servlet generiert sie in Echtzeit aus der Schablone solstice.dst. Bei Updates berechnet das Servlet neue Hashes, die der Client erkennt. Neue Third-Party-Bibliotheken müssen händisch in die solstice.dst eingetragen werden.

Ein automatisierter, globaler Downgrade durch einen Netzwerkbefehl existiert nicht. Rollbacks erfolgen über den regulären Update-Pfad: Die fehlerhafte Bibliothek wird auf dem Server durch die ältere Version überschrieben.

Durch den Abgleich von Dateigrößen und Hashes schließt die Architektur Starts mit fragmentierten Dateien aus. Abgebrochene Downloads müssen jedoch von vorne beginnen (keine HTTP Range Requests).

Erkennt Dawn eine neuere Version seiner selbst, überschreibt sich das Binary automatisch. Der aktuell initiierte Boot-Vorgang wird jedoch noch mit der alten Version abgeschlossen; die neue Logik greift ab dem nächsten Start. Ein Downgrade der Dawn-Executable ist ausgeschlossen.

Für die Softwareentwicklung, das Erstellen von Migrationsskripten und das System-Troubleshooting ist der Aufbau einer autarken lokalen Laufzeitumgebung zwingend erforderlich. Die fundamentale Basis besteht aus einer lokalen PostgreSQL-Datenbankinstanz sowie einem aktuellen Java Development Kit (JDK). Nach der Konfiguration der Systemvariablen auf dem Host-System wird der Applikationsquellcode aus dem zentralen Repository in das lokale Projektverzeichnis ausgecheckt.

Ein frisch ausgechecktes System erfordert im ersten Schritt die Bereitstellung einer leeren Datenbankstruktur. Das zentrale Kommandozeilen-Tool von MyTISM wertet hierzu die Konfigurationsparameter im Projektverzeichnis aus und legt eine entsprechende Instanz in der PostgreSQL-Datenbank an. Die Ausführung erfolgt über das Terminal:

Die Laufzeitkonfiguration des lokalen Applikationsservers ist über drei zentrale Steuerdateien organisiert:

Der lokale Server unterstützt verschiedene Ausführungsmodi. Um den Server vom Terminal zu entkoppeln und als Hintergrunddienst auszuführen, wird der Parameter start verwendet:

Für das interaktive Debugging können Log-Ausgaben im Vordergrundmodus direkt in das Terminalfenster (stdout) geleitet werden:

Dieser Initialisierungsprozess bootet die Middleware-Komponenten, validiert das XML-Schema, registriert die autonomen Hintergrunddienste und öffnet die Ports für eingehende Client-Verbindungen.

Sobald der Server Verbindungen akzeptiert, kann der Solstice-Client gestartet werden. Das primäre Werkzeug für die lokale Entwicklung ist das Bash-Skript start-client. Es stellt eine Verbindung via Dawn her und bietet erweiterte Debugging-Optionen:

Die integrierte Hilfe dokumentiert die Parameter zur Verbindungs- und Agentensteuerung:

Die initiale Authentifizierung an frisch aufgesetzten Instanzen ohne eingespieltes Datenbank-Backup erfolgt über das Standard-Konto „Admin“. Damit weitere Benutzer auf die Solstice-Schnittstelle zugreifen können, müssen diese administrativ der Systemgruppe RG_Solstice_Login zugewiesen werden.

Der Basisbetrieb wird primär durch die Dateien mytism.ini, log4j.conf und .mytism_session gesteuert. Das übergeordnete Server-Logging wird zentral in der log4j.conf konfiguriert (z. B. log4j.rootLogger=INFO, stdout, daily). Für ein granular gesteuertes, lokales Client-Logging wird eine separate Datei namens client-log.conf im Projektverzeichnis angepasst.

Brechen automatisierte Tests oder Serverprozesse mit der Exception „too many open files“ ab, limitieren die File-Descriptoren des Linux-Betriebssystems den Durchlauf. Administratoren müssen als root den Eintrag fs.file-max = 2097152 in die Datei /etc/sysctl.conf einfügen und mittels sysctl -p dauerhaft anwenden.

Bei der Taktung von Hintergrunddiensten via Cron-Job ist die Zeitumstellung (Daylight Saving Time) zwingend zu berücksichtigen. Ereignisse, die in die Zeitstunden von Daylight-Saving-Korrekturen fallen, werden architekturseitig stillschweigend nicht oder mehrfach ausgeführt. Dies muss bei der Planung systemkritischer Tasks einkalkuliert werden.

Vor dem Start eines synchronisierenden Servers nach dem Einspielen eines physischen Backups müssen administrative Bereinigungen im Dateisystem vorgenommen werden. Das rigorose Löschen aller generierten .checked-*-Dateien zwingt den Server zu einer vollständigen Neuprüfung. Die Datei .checked-sync enthält die IDs der zuletzt übertragenen Business Transactions und muss zwingend entfernt werden. Ebenso ist die Datei .init-keygen zu löschen, damit das System beim Neustart die lokale bi-Tabelle leert und den Sync-Ansatz neu initialisiert. Das Entfernen von .init-streamcopy erzwingt einen sauberen Abgleich der BLOBs im filesRoot-Verzeichnis, woraufhin der Hauptserver fehlende BLOBs automatisch überträgt.

Kommt es durch fehlerhafte Sync-Vorgänge zu ID-Kollisionen in polymorphen Relationen (z. B. zwei Objekte mit exakt derselben ID), ist ein strenger Reparatur-Ablauf auf dem autoritativen Server zwingend einzuhalten:

Um den Serverstart zu beschleunigen oder Check-Routinen notfallmäßig zu umgehen, bietet die Datei mytism.ini spezifische Flags im Abschnitt [DBMan]. Zudem lassen sich extrem große Tabellen gezielt vom zeitaufwendigen Doppel-ID-Check ausnehmen.

Der Systemstart beinhaltet einen automatischen Check auf verwaiste Dateien (Orphaned BLOBs) im filesRoot-Verzeichnis. Verzögert dieser Prozess den Start extrem, lässt sich der Check über das Flag noIntegrityBLOBChecks=1 in der mytism.ini temporär deaktivieren.

Modul-Tests erben zumeist direkt von der Klasse GroovyTestCase. Damit diese verlässliche Ergebnisse liefern, müssen sie absolut unabhängig voneinander und in völliger Isolation laufen. Um Cache-Lecks und Wechselwirkungen zwischen aufeinanderfolgenden Tests zu verhindern, müssen am Ende jedes Tests zwingend die Transaktion geschlossen und statische Caches geleert werden.

Schlagen Unit-Tests fehl, weil Strukturen in der In-Memory-Datenbank nicht gefunden werden, fehlt in der setUp()-Methode oftmals der Initialisierungsaufruf. Damit byTid-Methoden den Cacheloader korrekt aktualisieren können, muss zwingend tx.injectInitialDataFor(TBO.class) ausgeführt werden.

Ein weiteres Kernkonzept für die Graphenstabilität im Arbeitsspeicher ist das Frapping („Festzurren“). Für alle Business Objects innerhalb einer Transaktion gilt die Regel, dass bei identischer Datenbank-ID auch die Java-Instanz im Speicher zwingend identisch sein muss. Die Methode tx.frapBOFromCache(bo) mutiert das Objekt nicht in-place, sondern garantiert durch Rückgabe der gefrappten Instanz die strikte Eindeutigkeit des Objektgraphen.

In automatisierten Tests dürfen Fehlermeldungen niemals gegen hartcodierte Strings geprüft werden. Das System muss L10n-Schlüssel dynamisch auflösen, da Tests auf Servern mit abweichender OS-Locale andernfalls unweigerlich fehlschlagen. Für den exakten Abgleich in Assertions muss zwingend die Aufruf-Variante der Übersetzungs-Methode mit drei Parametern genutzt werden.

Das Logging innerhalb des Codes birgt spezifische Gefahren, die zwingend umschifft werden müssen.

Mit diesem Kapitel schließen wir den administrativen und architektonischen Betrieb von MyTISM (Teil 4) ab. Sie haben nun das Rüstzeug, um das System in hochkritischen Szenarien sicher zu warten und zu reparieren. Im folgenden TEIL 5: Referenzen finden Entwickler und Power-User das vollständige OQL-Referenzhandbuch für komplexe Datenbankabfragen sowie die verbindlichen Best Practices und Coding Conventions für die Entwicklung im MyTISM-Ökosystem.

MEX fungiert als vorgeschalteter Präprozessor, der fehlende ORM-Features (z. B. Unions, Subclass-Casting, Prefetching) transparent nachrüstet und komplexes natives SQL vermeidet. MEX besteht aus geschweiften Klammern {}, die serverseitig schrittweise ausgewertet und ersetzt werden.

Alle Eingabe- und Strukturkomponenten leiten sich architektonisch von FPanel ab. In sämtlichen Skript-Blöcken (wie <onAction>, <onRefresh>, <visibleIf>, <editableIf>) stehen standardmäßig folgende injizierte Variablen zur Verfügung: