Altova MobileTogether Designer

Mit Hilfe der Aktion "DB-Struktur lesen" können Daten aus einer definierten Datenbank ausgelesen und in einer Seitenquelle namens \$MT_DBSTRUCTURE gespeichert werden. Diese Seitenquelle wird ausschließlich mit Daten befüllt, die bei Ausführung der Aktion "DB-Struktur lesen" abgerufen werden.

Definieren der Aktion "DB-Struktur lesen"

Wenn Sie die Aktion "DB-Struktur lesen" in das Ereignisfenster ziehen, wird eine \$MT_DBSTRUCTURE-Seitenquelle zum Design hinzugefügt (wird im Fenster "Seitenquellen" angezeigt). Welche Datenbank gelesen werden soll, wird in den Einstellungen der Aktion (Abbildung unten) definiert. Diese Einstellungen werden weiter unten beschrieben.

Struktur lesen aus/von

Definiert, wo sich die Datenbankstruktur befindet: ob in Lösung oder auf dem Server. Bei der Struktur kann es sich um eine der Datenbank-Seitenquellen in der Lösung handeln oder um eine Datenbank, die über eine auf MobileTogether Server gespeicherte Verbindung aufgerufen wird. Informationen zu gespeicherten Datenbankverbindungen finden Sie in der Beschreibung von serverseitigen Datenbankverbindungen im Handbuch zu MobileTogether Server.

Anmerkung: Serverseitige Datenbankverbindungen stehen nur auf Windows-basierten MobileTogether Servern zur Verfügung, daher können Datenbankstrukturen auf Linux- oder macOS-basierten MobileTogether Servern nur aus in der Lösung enthaltenen Datenbankstrukturen gelesen werden.

Verbindungsname

Der Verbindungsname kann als XPath-String-Wert (siehe Abbildung unten) eingegeben werden. Wenn eine Struktur aus der Lösung definiert wurde (siehe vorheriger Punkt), steht auch der Verbindungsname in einer Auswahlliste zur Auswahl.

Tatsächliche Struktur/Mögliche Struktur lesen:

Die Seitenquelle \$MT_DBSTRUCTURE hat eine Struktur, die eine Obermenge bildet, die Komponenten enthält, die in verschiedenen Datenbanktypen zur Verfügung stehen.

•Tatsächliche Struktur lesen: Liest die Struktur der angegebenen Datenbankverbindung und ermöglicht Ihnen, die importierte Struktur auf Basis von Komponentennamen zu filtern (siehe Abbildung oben).

•Mögliche Struktur lesen: Es wird diejenige Obermenge von Nodes der Seitenquelle \$MT_DBSTRUCTURE befüllt, die der Struktur der angegebenen Datenbankverbindung entspricht und für die Daten zurückgegeben werden können. Tabellen der Datenbankstruktur, die auf diese Weise gelesen werden, werden nicht anhand ihres Namens identifiziert.

Filter

Diese Option wird nur angezeigt, wenn die Option Tatsächliche Struktur lesen (siehe vorherige Option) ausgewählt ist. Sie können damit filtern, welche Datenbankkomponenten ausgelesen werden sollen. Sie können die Komponenten auf eine der folgenden Arten filtern:

•Nach Auswahl: Aktivieren Sie die Kontrollkästchen der Komponenten, die ausgelesen werden sollen (siehe Abbildung oben). Um die ausgewählte Komponente weiter nach Namen zu filtern, definieren Sie einen XPath-Ausdruck in Form einer Sequenz von Strings, die die Namen der auszulesenden Komponenten angeben. Wenn eine bestimmte Komponente Vorfahren-Komponenten hat, werden auch diese automatisch ausgelesen. So wird z.B. bei Auswahl einer Spalte automatisch auch die übergeordnete Tabelle der Spalte gelesen.

•Nach XPath: Der XPath-Ausdruck muss eine Sequenz von Arrays sein (siehe Abbildung unten). Das erste Element in jedem Array ist der Komponententyp, der ausgelesen werden soll (tables, columns, usw.); diese Elemente sind als Schlüsselwörter bekannt. Die verfügbaren Schlüsselwörter werden in einem Popup-Fenster angezeigt, das erscheint, wenn Sie den Cursor über die Schaltfläche XPath der Option platzieren; Die Groß- und Kleinschreibung spielt bei Schlüsselwörtern keine Rolle. Die darauf folgenden Elemente des Array (ab dem zweiten Element) stellen die Namen des zu lesenden Komponententyps dar. So werden etwa in dem XPath-Ausdruck in der Abbildung unten die Spalten mit den Namen Author und Publisher aus Tabellen namens Book ausgelesen.

Fehlerverarbeitung

Mit der Option Bei Fehler können Sie definieren, wie bei Auftreten eines Fehlers vorgegangen wird. Da die Fehlerbehandlung für diese Aktion genau definiert werden kann, werden Fehler in solchen Aktionen (für die eine Fehlerbehandlung vorgesehen ist) als Warnungen und nicht Fehler behandelt. Der Vorteil davon ist, dass Sie Fehler bei Aktionen, für die bereits eine Fehlerbehandlung definiert wurde, nicht überprüfen müssen. Die folgenden Fehlerbehandlungsoptionen stehen zur Verfügung:

•Skript abbrechen: Sobald ein Fehler auftritt, werden alle nach diesem Ereignis durchzuführenden Aktionen beendet. Dies ist das Standardverhalten bei Auftreten eines Fehlers. Wenn Sie möchten, dass auch bei einem Fehler fortgefahren werden soll, wählen Sie entweder die Option Weiter oder Throw aus.

•Weiter: Die Aktionen werden nicht beendet. Sie können stattdessen auswählen, was in jedem der beiden Fälle (kein Fehler (Bei Erfolg) oder Auftreten eines Fehlers (Bei Fehler)) geschehen soll. So kann z.B. ein Meldungsfeld definiert werden, das den Benutzer darüber informiert, ob eine Seite erfolgreich geladen werden konnte oder nicht.

•Throw: Wenn ein Fehler aufgetreten ist, wird mit dieser Option eine Ausnahme ausgelöst, die in der Variablen der Try/Catch-Aktion gespeichert wird. Mit dem Catch-Teil der Try/Catch-Aktion wird definiert, welche Aktion bei Auftreten eines Fehlers durchgeführt werden soll. Wenn kein Fehler auftritt, wird die nächste Aktion verarbeitet. Nähere Informationen dazu finden Sie im Abschnitt zur Aktion "Try/Catch Ausnahme".

Was geschieht zur Laufzeit?

Zur Laufzeit wird die angegebene Datenbank ausgelesen und die Nodes der Seitenquelle \$MT_DBSTRUCTURE werden mit Daten aus der Datenbank befüllt. Die Daten auf dieser Seitenquelle können nun im Design verwendet werden.

Simulationen

Wenn Sie den Server für Simulationen verwenden, vergewissern Sie sich, dass die Servereinstellungen in MobileTogether Designer korrekt sind und die Datenbank im serverseitigen Arbeitsverzeichnis der Lösung vorhanden ist. Nähere Informationen dazu finden Sie im Abschnitt Simulation auf dem Server.

Wenn Sie eine Simulation direkt in MobileTogether Designer ausführen, stammen die in der Simulation verwendeten Daten aus der Datenbank, die (auf dem Register "Simulation 2 des Dialogfelds "Optionen") in der Einstellung DB-Struktur-lesen-Simulation definiert wurde.

MobileTogether-Erweiterungsfunktionen

MobileTogether enthält eine Reihe von XPath-Erweiterungsfunktionen, die speziell für die Verwendung in MobileTogether-Designs erstellt wurden. Einige davon können bei bestimmten Aktionen sehr nützlich sein. So erhalten Sie etwa mit mt-available-languages() die Sprachen, in denen die Lösung zur Verfügung steht. Diese Funktion könnte z.B. mit der Aktion Meldungsfeld verwendet werden. Wenn eine Funktion für diese Aktion besonders relevant ist, ist sie unten aufgelistet. Eine vollständige Liste aller Erweiterungsfunktionen und mit Beschreibungen finden Sie im Kapitel MobileTogether-Erweiterungsfunktionen.

mt-available-db-connection-names()

mt-db-any-changed-fields()

mt-db-any-changed-rows()

mt-db-deleted-original-fields()

mt-db-deleted-original-rows()

mt-db-file-path()

mt-db-modified-fields()

mt-db-modified-rows()

mt-db-new-fields()

mt-db-new-rows()

mt-db-original row()

mt-external-error-code()

mt-external-error-text()