Feature Transport - Schema Aktualisierung

[stefan_brauneis]

Hi zusammen,

FirstSpirit-Version: 5.1.507

Wir möchten einen Schema Transport von einem Master Projekt in verschiedene abhängige Projekte realisieren und das ganze halbautomatisiert per Auftragsaktion.

Bei Änderungen am Schema im Master sollen diese also in den angebundenen Projekten per Auftrag aktualisiert werden.

Mit dem Auftragsaktionen aus dem Feature Transport scheint das auch erstmal möglich zu sein. Allerdings habe ich da jetzt zwei Einschränkungen gefunden, die mich veranlassen das ganze über die API selbst zu implementieren:

1. Wenn ich ein Feature erzeuge und in der Aktion im Auswahldialog auswähle kann ich dies nicht so einstellen, dass dort immer die aktuelle Revision bei der Ausführung ausgewählt wird. Das Feature liegt immer in der Revision, in der es angelegt wurde.

Ist das irgendwie auf einem anderen Weg über die Konfiguration im Feature Transport oder im Auftrag möglich?

2. Wenn ein Schema per Feature Transport importiert, kann man dort kein Layer-Mapping konfigurieren. D.h. es scheint das dort dann mehr oder weniger zufällig ausgewählt wird, in welchem Layer das Schema landet.

Gibt es eine Möglichkeit dies zu konfigurieren oder ist das geplant?

Beide Dinge gehen über die API:

- Ich kann im FeatureAgent.createFeature einfach die aktuellste Revision angeben

- Im FeatureInstallAgent.installFeature kann man ein LayerMapping angeben.

Danke für ein Feedback zu den beiden Fragen oben!

Schöne Grüße

Stefan Brauneis

[tenter]

Hallo Stefan,

sorry dass du so lange auf eine Antwort warten musstest, deine Fragen haben intern einige Male die Runde gemacht.

1. Die Revision wird immer beim Erstellen des Features angegeben. Wenn du über die API gehst (FeatureAgent.createFeature), dann wird ein neues Feature angelegt, daher kannst du so die Revision übergeben. Das ist etwas anderes, als wenn ein bestehdens Feature ausgewählt wird. Die Funktionalität die du wünschst, bekommst du so leider (aktuell) nicht - ob es da zukünftig Änderungen geben wird, können wir aktuell nicht sagen, das Content Transport Feature wird aber sehr aktiv weiterentwickelt und ein verwandter Vorgang ist bereits in Bearbeitung.

2. Das stimmt, da kann kein Mapping übergeben werden. Ich kann es im Augenblick nicht mit Sicherheit sagen, aber in so einem Falle wird in der Regel ein leeres Mapping übergeben.

Leider können wir dir für deine Fragen weder eine alternative Lösung noch eine Roadmap geben und sind daher froh, dass du dir über die API selbst helfen konntest.

Können wir dir sonst noch irgendwie weiterhelfen? Wenn nein, markiere bitte diese Antwort als hilfreiche Antwort.

Danke für deine Geduld und viele Grüße,

Hannes Pernpeintner

[tenter]

Hallo Stefan,

wir haben dein Problem intern nochmal diskutiert und daher nochmal einige Anmerkungen.

Erst einmal wäre es sehr hilfreich wenn du noch einmal genau Schritt für Schritt erklärst, wie du Feature-Erstellung, Im- und Export und Aufträge verwendest. Verwendest du dann das Filesystem zum Ablegen der Features?

1. Die Auswahl des Features und die dort angezeigte Revision sollte nicht verwirren - wenn der Import-Auftrag ausgeführt wird, wird die neuste Revision des Exports verwendet. Das funktioniert genauso, wie wenn du im SiteArchitect von Hand ein Feature importierst und die neuste Revision setzt. Bist du ganz sicher, dass der Import nicht wie gewünscht funktioniert und dass dich vielleicht die Revisionsangabe des Features verwirrt hat?

2. Verwendest du für jedes Projekt eigene Datenquellen, oder werden in den Slave-Projekten Datensätze aus dem Master referenziert? Wenn du erstmalig von Hand ein Feature importierst, das Schemata enthält, wirst du nach dem Layermapping gefragt. Ist dies einmal passiert, passieren weitere Imports wie gewünscht. Hast du das auf diesem Wege gemacht?

Viele Grüße,

Hannes Pernpeintner

[stefan_brauneis]

Hallo Hannes,

zu 1.:

Ich bin von der Anzeige im Auftrag ausgegangen.

zu 2.:

Es ist eine Mischung. Es existiert ein Schema, dass auf einem globalen layer existiert und eines, das projektspezifisch ist.

Insgesamt fand ich die Anzeige, bzw. die Auswahl hier sehr verwirrend. Wir haben das jetzt über einen eigenen spezifischen Scheduler-Task gelöst, da vieles was sonst konfiguriert hätte werden müssen, sich dann ebenfalls vereinfacht und weniger fehleranfällig ist.

Vielen Dank für die Rückmeldung.

Stefan Brauneis