Profil als Unterknoten einhängen in Quellstruktur
Über das Kontextmenü auf einem Knoten oder Feld der Zielstruktur können Sie ein bestehendes Profil (seine Zielstruktur) als Unterknoten in der Quellstruktur einhängen.
Voraussetzungen für ein einzuhängendes Profil
Ein Profil kann eingehängt werden, wenn
es aktiv und nicht suspendiert ist,
es den normalen Daten-Mapper (nicht den einfachen) verwendet.
(Die Optionen Pro Datenblatt Antwortwege ausführen und IU miteinbeziehen dürfen nicht gesetzt sein.)
Voraussetzungen für ein einhängendes Profil
Ein Profil kann ein anderes Profil einhängen, wenn
Profil einhängen
Ein Profil kann in der Zielstruktur über das Kontextmenü jedes beliebigen Feldes und Knotens eingefügt werden.
Es erscheint ein weiterer Dialog.
(1) Wählen Sie das einzuhängende Profil aus.
(2) Geben Sie einen eindeutigen Präfix und einen eindeutigen Knotennamen für die Quellstruktur an. Hinweis: Der Präfix sorgt dafür, dass alle Feldnamen in der Quellstruktur eindeutig bleiben, da ja z. B. zwei eingebundene Profile einen gleichen Feldnamen verwenden könnten. Durch den Präfix unterscheiden sie sich dann hier in der Quellstruktur wieder, weil man einmal prefix1.fieldname und zum anderen prefix2.fieldname bekommt. Das erlaubt also unter anderem auch das selbe Profil zweimal einzufügen, wenn man jeweils einen unterschiedlichen Präfix verwendet. Der Knotenname kann dann gleich sein. Siehe (6).
(3) Hiermit wird das Profil eingefügt.
Als Ergebnis wird einerseits auf Ihrem Knoten/Feld in der Zielstruktur die Funktion call sub profile for source tree (a,b,c,d,e,f,g,h) platziert. Die Parameter a, b und h werden automatisch gesetzt (siehe dort).
Zum anderen sehen Sie dann in der Quellstruktur folgende Teilstruktur. Werden weitere Profile eingehängt, landen auch diese unterhalb des blauen Knotens _IncludedSubProfiles_.
(4) Die Eigenschaften der Knoten und Felder des eingehängten Profils sind gesperrt. Sie können diese aber manuell ändern, wenn Sie auf das Schloss klicken, falls sich nur Kleinigkeiten am eingehängten Profil geändert haben. Ansonsten ist sowieso die Synchronisierung zu verwenden (folgend beschrieben).
(5) Wurden am eingehängten Profil Änderungen vorgenommen, dann können Sie diese automatisch synchronisieren.
(6) Siehe Hinweis zu (2).
Aufruf des Profils und Datenfluss
Sie können Felder und Knoten in der Teilstruktur löschen, wenn Sie nur eine Teilsicht der Daten benötigen, geliefert werden aber immer alle Daten.
Sie können mit dieser Teilstruktur mappen, wie Sie es gewohnt sind. Gefüllt mit Daten wird die Teilstruktur immer über die Funktion call sub profile for source tree (a,b,c,d,e,f,g,h). Die Daten kommen immer nur aus der Zielstruktur des eingehängten Profils und nicht aus der Integration Unit, etc.
Hinweis: Im Mapping-Test wird die Teilstruktur _IncludedSubProfiles_ nicht dargestellt, allerdings werden die an diese übermittelten Daten dort in einem eigenen Tab angezeigt.
Sie können die Teilstruktur beliebig oft mit Daten füllen durch mehrfachen Aufruf der oben genannten Funktion. Die Funktion kann an beliebiger Stelle (auch mehrfach) eingefügt werden. Die Ergebnis-Daten (Resultset) des jeweils letzten Aufrufs können über den Parameter g der Funktion wieder entfernt werden. Als Ergebnis erhalten Sie dann schlicht Mehrfachheiten der Teilstruktur, oder um es hier konkreter auszudrücken mehrere Vorkommen des Knotens prefix.Node_from_profile. In der Zielstruktur verwenden Sie dann einen Pfad auf prefix.Node_from_profile, um diese Daten auszulesen, ganz wie Sie das in "normalen" Mappings kennen. Legen Sie den Pfad bitte nicht auf prefix.nodename.
Der Ablauf, in dem die inkludierten Teilstrukturen befüllt werden ist so, wie die zugehörigen Funktionen aufgerufen werden. Wurde eine Funktion in der Zielstruktur noch nicht aufgerufen, dann hat die inkludierte Teilstruktur in der Quellstruktur auch noch keine Daten. In diesem Fall würde es dann auch keinen Sinn mache, wenn Sie einen Pfad auf einem Knoten legen (hier z. B. prefix.Node_from_profile) dessen Teilstruktur (hier z. B. prefix.nodename) noch gar nicht befüllt wurde.
Wichtiger Hinweis: Es liegt in der Verantwortung des Anwenders/Entwicklers, dass über den hier beschriebenen Sub-Profil-Mechanismus keine Endlos-Schleifen entstehen, bzw. dass diese gehandhabt werden! Es ist z. B. möglich ein Profil 1 zu erstellen, das Profil 2 und Profil 3 einbindet. Wenn Sie dann in Profil 2 das Profil 1 einbinden, erhalten Sie eine Endlos-Schleife.
Hierarchische Strukturen
Wie Sie vielleicht schon bemerkt haben, werden die inkludierten Profile in der Quellstruktur alle "flach" eingefügt. Diese haben zwar jeweils in sich Verschachtelungen, aber Sie können nicht ein Profil 1 einfügen und dann in dieses das Profil 2. Verschachtelungen dieser Art, also der Aufbau eine hierarchischen Gesamtstruktur, wird über das Mapping und den hierarchischen Aufbau der Zielstruktur erreicht. Und diese Mittel sind Ihnen alle schon aus "normalen" Mappings bekannt. Konkret können also die Daten aus Profil 2 in der Zielstruktur unterhalb der Daten von Profil 1 eingefügt werden.
Beispiel-Profile
Importieren Sie folgende zwei Profile und setzen sie diese auf aktiv. Profile_2 inkludiert Profile_1 (die Namen gegebenenfalls anpassen). Die Profile sind relativ sinnfrei. Es geht hier lediglich um ein einfaches Beispiel des oben Beschriebenen. Hinweis: Falls Sie keinen Datenbank-Alias hub verwenden, dann müssen Sie diesen evtl. in Phase 1 der Profile anpassen.
Beispiel-Anwendung
Nehmen wir an Sie bekommen mit Ihrem Profil 2 eine Menge von Artikeln in einem Auftrag herein. Dann könnten Sie in der Zielstruktur die Artikel durchlaufen, wie Sie das bereits aus "normalen" Mappings kennen, und dann pro Artikel ein in der Quellstruktur eingebundenes Profil 1 aufrufen, das Ihnen zu dem jeweiligen Artikel Zusatzinformationen liefert (den gerade aktuellen Preis, den aktuellen Lagerbestand, usw.). Profil 1 kann also von irgendjemandem als Service-Profil aufgebaut werden und Sie können es in Ihrem Profil verwenden, um Ihre eigenen Informationen aufzubereiten. Sie geben Profil 1 z. B. lediglich eine Artikelnummer und bekommen die gewünschten Daten zurück, ohne wissen zu müssen, was im Hintergrund passiert, wie z. B. Datenbank-Abfragen oder Zugriffe auf ein ERP-System. Sie müssen sich auch keine Gedanken darüber machen, wie auf diese anderen Systeme zugegriffen wird. Ihr Profil 2 kann gleich bleiben und nur Profil 1 muss bei Bedarf gepflegt werden. Also so wie man sich das bei einer Service-orientierten Architektur wünscht.