Über den Portal-Designer lassen sich benutzerspezifische Masken erstellen, die nicht mit internen Geschäftsobjekten arbeiten, sondern hauptsächlich zum Laden und Manipulieren externer Daten mit Hilfe von Lobster_data Profilen dienen.

Zentrales Werkzeug des Portal-Designers ist der Formulardesigner, der auch für die Erstellung von Geschäftsobjekt-Masken verwendet wird.

Portal-Übersicht

Über den Menüpunkt "Portale" (Verwaltung - Konfigurationen) gelangt man auf die Übersichtsseite der für den eingeloggten Benutzer sichtbaren Portale:

images/download/attachments/177913635/image2019-4-1_16-10-58-version-1-modificationdate-1727247899296-api-v2.png

Die Ribbon-Buttons in der Hauptkategorie 'Allgemein' der Übersicht haben folgende Funktion:

Unterkategorie	Schaltfläche	Effekt	erforderliche Auswahl
Details	Neu	Öffnet des Formulardesigner mit einem neuen Portal	keine
	Löschen	Löscht den/die ausgewählte/n Portale	einzeln / mehrere
	Bearbeiten	Öffnet das ausgewählte Portal im Formulardesigner	einzeln
	Abbrechen	Setzt die Auswahl in der Übersicht zurück	einzeln
Zuordnung	Zuweisen	Über die Anwendung bestehender Zuordnungskriterien kann ein Portal für bestimmte Benutzergruppen freigeschaltet werden.	einzeln
Liste	Zurücksetzen / Suchen	Siehe Arbeiten in Übersichten	keine
Änderungsverlauf	Liste	Öffnet die Änderungshistorie für das ausgewählte Portal, über das jeder enthaltene Versionsstand wiederhergestellt werden kann. Das ist nützlich, falls man versehentlich etwas aus dem Portal gelöscht hat oder die letzten Änderungen in eine Sackgasse geführt haben und rückgängig gemacht werden sollen. Siehe auch Änderungsverlauf (Konfigurationen)	einzeln

Portal-Erfassungsmaske

Die Portal-Erfassungsmaske erlaubt das Anlegen und Ändern von Portalen. Über die Ribbonknöpfe werden die allgemeinen Funktionen gesteuert.

Details zum Portal sind über vier Tab-Reiter verteilt.

Aufbau des Ribbons

images/download/attachments/177913635/image-2024-2-21_9-9-8-version-1-modificationdate-1727247899255-api-v2.png

Unterkategorie	Schaltfläche	Effekt
Details	Neu	Wechselt im Editor zu einem neuen Portal. Liegen für das aktuelle Portal ungespeicherte Änderungen vor, wird eine Bestätigung für das Verwerfen abgefragt.
	Löschen	Löscht das aktuelle Portal, sofern der Benutzer diese Aktion bestätigt.
	Abbrechen	Wechselt im Editor zu einer Ansicht ohne Portal, in der nur die Neu Schaltfläche zur Verfügung steht. Liegen für das aktuelle Portal ungespeicherte Änderungen vor, wird eine Bestätigung für das Verwerfen abgefragt.
	Kopieren	Übernimmt den aktuellen Stand des Designs inklusive ggf. enthaltener ungespeicherter Änderungen in ein neues Portal. Nur wenn dieses neue Portal gespeichert wird, bleibt das Design erhalten.
	Speichern	Speichert den aktuellen des Designs. Das Portal bleibt im Editor geöffnet und kann weiter bearbeitet werden. Um den aktuellen Stand auch zu veröffentlichen, kann die entsprechende Schaltfläche in der Kategorie "Editor" verwendet werden
Zuordnung	Zuweisen	Über die Anwendung bestehender Zuordnungskriterien kann das Portal für bestimmte Benutzergruppen freigeschaltet werden.
Tags	Tags verwalten	Verwaltet die dem Portal zugewiesenen Tags. Diese können zum Gruppieren von Portalen oder auch zum Exportieren von Konfigurationen verwendet werden.
Editor	Sprache	Hier kann die Sprache der lokalisierbaren Beschriftungen und Texte umgeschaltet werden. Steht die Sprache beispielsweise auf Englisch und es wird ein solcher Text im Editor bearbeitet, dann passiert dies auch nur im Kontext dieser Sprache. Dies hat jedoch keinerlei Auswirkungen auf die Einträge in der Sprachverwaltung des Systems. Die Änderungen gelten ausschließlich für das aktuelle Formular.
	Struktur Export	Exportiert die Datenstruktur des konfigurierten Portals und zeigt diese in einem Editor an. Diese Struktur kann dann als Datei heruntergeladen und direkt via Drag&Drop als Struktur in den Lobster_data importiert werden. ►HINWEIS◄ Wenn der Testmodus (s. u.) aktiv ist, werden nur 'ausgefüllte' Felder exportiert. Dies entspricht beispielsweise der Eingangsdatei beim Rufen eines Lobster_data Profils
	Testmodus	Schaltet in den Testmodus für das Formular. Im Testmodus wechselt das Icon der Schaltfläche von 'Play' (►) auf Stop (■) und das Portal kann noch vor dem Speichern oder Veröffentlichen getestet werden. Auch im Testmodus werden alle Verhalten und Aktionen innerhalb des Formulars uneingeschränkt ausgeführt. Dies entspricht also keineswegs einem "geschützten" Testmodus.
	Übersetzen	Öffnet einen Dialog zum Übersetzen sämtlicher lokalisierbarer Werte innerhalb des Portals (z.B. Beschriftungen, Tooltips, Hinweistexte, etc.)
	Veröffentlichen	Speichert und veröffentlicht die aktuellen Änderungen. Benutzer sehen beim Laden des Portals immer nur den zuletzt veröffentlichten Stand. Über die "Speichern" Schaltfläche kann der Zwischenstand auch ohne Veröffentlichung gespeichert werden.
Änderungsverlauf	Liste	Öffnet die Änderungshistorie für das ausgewählte Portal, über das jeder enthaltene Versionsstand wiederhergestellt werden kann. Das ist nützlich, falls man versehentlich etwas aus dem Portal gelöscht hat oder die letzten Änderungen in eine Sackgasse geführt haben und rückgängig gemacht werden sollen. Siehe auch Änderungsverlauf (Konfigurationen)

Tab-Reiter "Portal"

Der Tab-Reiter "Portal" enthält allgemeine Parameter des Portals:

images/download/attachments/177913635/image-2024-9-25_9-5-8-version-1-modificationdate-1727247908002-api-v2.png

Der Portalname kann frei gewählt werden. Er muss allerdings innerhalb des Systems eindeutig sein. Der Name kann später über die Sprachverwaltung lokalisiert werden. In der Sprachverwaltung muss dazu der Eintrag zum Resource Name "Portal$<NAME>" im Resource Bundle "scm.portal" bearbeitet werden.
Per Icon URI kann über den standardisierten Icon-Browser (Schaltfläche Auswählen) ein Icon ausgewählt werden, das in der Titelleiste des Portals und ggf. für den Menüeintrag des Portals verwendet werden soll. Der Icon-Pfad kann aber auch direkt eingegeben oder eidtiert werden.
Die Option Im Menü anzeigen legt fest, ob das Portal über das Hauptmenü aufrufbar sein soll. Lediglich für Portale, die ausschließlich als modale Dialoge durch andere Portale oder Erfassungsmasken aufgerufen werden sollen, wird man dieses Häkchen nicht setzen.
Wenn die Option Im Menü anzeigen gesetzt ist, erscheint ein Eingabefeld für den Menü-Eintrag. Hier kann angegeben werden, an welcher Position im Hauptmenü-Baum der Eintrag für das Portal erscheinen soll.
- 'Root' erscheint hier als Standardwert. Mit dieser Einstellung erscheint das Portal als Eintrag der Einstiegsebene.
- Ein Klick auf das Burger-Menü-Symbol öffnet eine Auswahlliste vorhandener Menüeinträge, in der ein 'Elternelement' für das Portal ausgewählt werden kann.
- Es ist auch möglich den Menüpfad einzugeben oder zu bearbeiten, der die internen Namen von Elementen unterhalb der Einstiegsebene durch Schrägstiche verkettet.
  Für unbekannte Elementnamen in einem Pfad werden automatisch Menüebenen ergänzt, die anschließend auch lokalisiert werden könnten:

Tab "Editor"

Dieses Tab zeigt einen Formulardesigner. Die Bedienung sowie die Schaltflächen und Komponenten des Editors werden auf der verlinkten Seite beschrieben.

Tab "Form XML"

Die hier ausgegebene XML-Struktur dient in erster Linie zur Analyse des erzeugten Form-XML Formates und kann ferner auch zum Kopieren des gesamten Portals in ein anderes Lobster Data Platform / Orchestration-System verwendet werden. Details dazu werden auf der Seite Formulardesigner beschrieben.

Tab "Renderer XML"

Die hier ausgegebene XML-Struktur entspricht der Struktur, welche veröffentlicht wurde und die ein Benutzer beim Verwenden der Maske lädt. Details dazu werden auf der Seite Formulardesigner beschrieben.

Datenfelder in Portalen

Im Kontext von Portalen ist die Definition von Datenfeldern wichtig, um die gewünschte Datenstruktur zu erzeugen oder abzubilden.

Formular-Elemente ohne Angabe eines Datenfelds (ohne Text in der Datenfeld-Eigenschaft) werden ignoriert. Für ein Element, das andere Elemente enthält (siehe Element Container) bedeutet das, dass der Container nicht in der Datenstruktur erscheint, während enthaltene Elemente mit Angaben eines Datenfelds sehr wohl erscheinen können.

Anstelle den Text der Datenfeld-Eigenschaft zu entfernen, kann man auch den Wert 'Überspringen' setzen, indem man auf die Schaltfläche rechts neben der Eigenschaft klickt:

images/download/attachments/177913635/image2019-4-1_17-45-10-version-1-modificationdate-1727247899262-api-v2.png

Anstelle des Datenfelds erscheint der Text 'Überspringen', in der Eigenschaft, die schreibgeschützt ist, bis die Schaltfläche erneut gedrückt wird.
Alternativ kann man auch die Zeichenfolge $skip$ für die Datenfeld-Eingeschaft eingeben. Diese Eingabe wirkt wie ein Klick auf die Schaltfläche.
Existiert beim Umstellen auf 'Überspringen' ein Eintrag für das Datenfeld, bleibt dieser unsichtbar gespeichert. Er wird reaktiviert, wenn die Schaltfläche erneut geklickt wird.

►WICHTIG◄ Für Elemente, die keine anderen Elemente mit Datenfeld-Einträgen enthalten, wirkt die Auswahl von 'Überspringen' wie das Angaben keines Datenfelds. Ein Element Container verhält sich dagegen wesentlich anders, da das 'Überspringen' nicht nur den Container sondern auch alle darin enthaltenen Felder mit Datenfeldeinträgen aus der Datenstruktur entfernt.

Siehe auch Einblick in die Elementdatentechnik

Anwendungsbeispiele für Portale

Beispiel für Datenfelder und Datenstrukturen

Die Elementbeschriftungen entsprechen ihren Datenfeldern. Der im Baum markierte Container "Spaltenlayout"
hat kein definiertes Datenfeld und wird daher in der Datenstruktur übersprungen. Siehe resultierendes JSON.

Resultierende Datenstruktur als JSON

{
    "fahrzeugDetails": {
        "fahrzeugID": "12345",
        "fahrzeugName": "Gabelstapler UH8"
    },
    "fahrerInfo": {
        "vorname": "Max",
        "nachname": "Mustermann"
    }
}

Wie in den Zeilen 6 und 7 zu sehen, wurde das Spaltenlayout ohne Datenfeld übergangen und dient daher lediglich zu Gestaltungszwecken.

Listen mit "Wiederholenden Elementen"

Die Beschriftungen der Elemente entsprechen ihren Datenfeldern.
Listenstrukturen können mit "Wiederholenden Elementen" erzeugt, manipuliert und ausgewertet werden. Dem ausgeführten Portal (rechts) unterliegt nun folgende Datenstruktur:

Datenstruktur des oben gezeigten befüllten Portals

{
    "tasks": [
        {
            "beschreibung": "Projektplan erstellen",
            "erledigt": true
        },
        {
            "beschreibung": "Umsetzung der Meilensteine",
            "erledigt": true
        },
        {
            "beschreibung": "Testen der neuen Programmfunktionen",
            "erledigt": false
        }
    ]
}

Wieder gilt, dass Elemente ohne definiertes Datenfeld, wie hier das Spaltenlayout, einfach übersprungen werden.

Anbindung von Lobster_data-Profilen als mögliche Daten-Transaktionsschicht

Portale ansich haben – im Gegensatz zu Geschäftsobjektmasken – keine Möglichkeit, automatisch Daten in Lobster Data Platform / Orchestration zu speichern. Portale dienen lediglich dazu, eine definierte Datenstruktur zu laden, zu befüllen oder zu erzeugen. Woher diese Daten kommen oder was mit ihnen anschließend passiert, wird in der Regel über Lobster_data-Profile gesteuert. Mit einer Ausnahme: Wird ein Portal von einem anderen Dialog gerufen, werden dessen Daten weiterverarbeitet.

Die Kommunikation zwischen einem Portal und Lobster_data-Profilen wird über Verhaltensweisen und Aktionen gesteuert.
Sollen beispielsweise beim Öffnen des Portals Daten von einem Profil abgeholt werden, kann dies mit dem Verhalten "Profil aufrufen" auf Formularebene (Ereignis: "Formulardaten geladen") geschehen. Um die Daten, welche vom Profil zurückgeliefert werden, in das Portal zu laden, muss in demselben Verhalten die Aktion "Elementdaten setzen" auf das Formular angewendet werden.

Das Zurückschreiben bzw. Übergeben der Daten an ein anderes System passiert ebenfalls über den Aufruf eines Lobster_data-Profils. Dabei gilt, dass dem Profil stets die Daten eines verknüpften Elements als Eingangsdaten mitgeliefert werden. Wird kein Element verknüpft, werden die Daten des gesamten Portals (siehe oberes Beispiel für Datenstrukturen) mitgegeben.

Das nachfolgende Beispiel zeigt ein Standardszenario "Laden, Manipulieren und Zurückschreiben von Daten".

Beispiel für das Laden, Manipulieren und Zurückschreiben von Portaldaten via _data-Profile

Für dieses Beispiel wird von einem recht simplen Portal ausgegangen, dessen Aufbau und Datenstruktur bereits in einem der Datenstrukturbeispiele gezeigt wurde.

Beispiel: Lesen

Das oben beschriebene Vorgehen zum Laden von Daten wurde hier bereits auf Formularebene konfiguriert (siehe Abbildung).

Das aufgerufene Profil zum Laden der Daten heißt im Beispiel "holeFahrzeugdaten" und liefert ein JSON-Format zurück. Das nachfolgende Bild zeigt die Konfiguration des Verhaltens "Profil aufrufen":

Da das Profil ein JSON-Format zurückliefert, wird als Decoder (Eingangsformat) ebenfalls JSON gewählt. Was in diesem Fall als Encoder (Ausgangsformat) festgelegt ist, spielt hier eigentlich keine Rolle, da lediglich Daten geladen und nicht übergeben werden. Dasselbe gilt daher auch für das verknüpfte Element.

Im Profilmanager des Lobster_data wurde das entsprechende Profil namens "holeFahrzeugdaten" angelegt. Die Konfiguration wird nachfolgend grob beschrieben.

Phase 1: Manuelles hochladen
Phase 2: Dokumentenart JSON (entsprechend Encodereinstellung des Verhaltens)
Phase 3/4: Mapping

Die Struktur des Ausgangsbaums (1) entspricht der Datenstruktur des Portals (vgl. JSON des Datenstrukturbeispiels). Da dies ein extrem simples Beispiel zur Veranschaulichung ist, wurden Fixwerte (2) für die Felder vergeben.

Phase 5: Integration-Unit: com.ebd.hub.datawizard.iu.JsonCreationUnit
Phase 6: Eigene Klasse: SCM:de.lobster.scm.dw.util.CronPassBackDataResponse (Erlaubt dem Profil die Daten an das Portal zurückzugeben)
Inhalt: Ausgabe aus IU (JSON aus der Integration Unit)

Beim Ausführen des Portals werden nun wie erwartet die im Profil eingestellten Fixwerte geladen.

Beispiel: Schreiben

Analog zum Laden der Daten kann wiederum ein Profil zum Exportieren der Portaldaten aufgerufen werden. In diesem Beispiel soll dies beim Klicken auf den Speichern-Button passieren.

Beim Klicken auf den Speichern-Button sollen die Portaldaten an das Profil "schreibeFahrzeugdaten" (1) übergeben werden.
Als Encoder (Ausgangsformat 2) wird wieder JSON gewählt. Die Decodereinstellung (Eingangsformat) spielt in diesem Beispiel keine Rolle.
Die Daten des Formulars sollen an das Profil übergeben werden, daher wurde dieses über den Elementbaum (links) verknüpft (3). Im Falle der Formulardaten ist das Verknüpfen mit der Form eigentlich nicht nötig, da dies der Standardeinstellung entspricht, wurde zur besseren Veranschaulichung für dieses Beispiel dennoch getan.

Im Profilmanager des Lobster_data wurde entsprechend das Profil "schreibeFahrzeugdaten" angelegt und wie folgt konfiguriert:

Phase 1: Manuelles Hochladen
Phase 2: Dokumentenart entsprechend dem Encoder: JSON
Phase 3/4: Mapping

Die Struktur des Eingangsbaumes entspricht der Datenstruktur der übergebenen Daten (in diesem Beispiel die Daten des gesamten Portals).

Phase 5: com.ebd.hub.datawizard.iu.NoActionUnit
Phase 6: Leer

Wird in dem gestarteten Portal nun der Speichern-Button gedrückt, werden die Portaldaten an dieses Profil übergeben.

In diesem Beispiel wird dies lediglich über die Eingangsdatei im Controlcenter des Lobster_data überprüft (Datei ansehen ...). Siehe nachfolgende Abbildung.

Auf diese Weise lassen sich sämtliche von Lobster Data Platform / Orchestration unabhängige Datentransaktionen zu beliebigen Systemen und Datenbanken realisieren.

Einblick in die Elementdatentechnik