Questions & Answers

[graulich]

Sehr geehrtes eSpirit Team,

wir entwickeln aktuell ein FS-Modul zum automatisierten Transportieren von FS-Release-Bundles (Templates, Medien, Globale Inhalte, etc.) von Entwicklung über Test zu Produktion.

Die service.importStoreElements-Methode gibt uns die Möglichkeit einen "EventListener" den ImportHandler mitzugeben, dessen Methoden zu diversen Zeitpunkten des Imports aufgerufen werden.

Jedoch kommen wir bei keiner dieser ImportHandler-Methoden an das durch den Import angelegte Element, bzw. die tatsächlich angelegte UID heran.

Könnt ihr uns diesbezüglich weiterhelfen?

Beste Grüße

Dominic Graulich

[boesebeck · Accepted solution]

Hallo Herr Graulich,

wir entwickeln aktuell ein FS-Modul zum automatisierten Transportieren von FS-Release-Bundles (Templates, Medien, Globale Inhalte, etc.) von Entwicklung über Test zu Produktion.

in FIrstSpirit 5 wird es mit dem FeatureTransport einen Mechanismus für solche Fälle geben. Ist das Modul nur für 4.2.x geplant?

Die service.importStoreElements-Methode gibt uns die Möglichkeit einen "EventListener" den ImportHandler mitzugeben, dessen Methoden zu diversen Zeitpunkten des Imports aufgerufen werden.

Jedoch kommen wir bei keiner dieser ImportHandler-Methoden an das durch den Import angelegte Element, bzw. die tatsächlich angelegte UID heran.

die Methode StoreElement.importStoreElement() liefert aber ein StoreElement zurück, was auch eine UID hat.Von welchen Typ ist der Service?

[graulich]

Hallo Herr Bösebeck,

danke für die schnelle Antwort.

Das Objekt service ist vom Typ "UserService".

Wir geben aktuell in jeder Callback-Methode des ImportHandlers einen Debug-Output aus:

((IDProvider)arg0).getUid()

Und bekommen somit folgende Debug-Outputs wenn wir importieren:

setImportElementCount: 1

afterStoreElementImport (dontwash)

afterExternalAttributeImport: (dontwash)

afterImportData: (dontwash)

afterAdjustAttributes: (dontwash)

Das Medium mit der UID dontwash existiert jedoch bereits im Zielsystem und wird natürlich auch nicht überschrieben. Deswegen würden wir erwarten, dass wir "dontwash_1" zurück bekommen, so wie es ja auch angelegt wird.

Beste Grüße

Dominic

[boesebeck]

Leider wird die UID erst nach dem Callback unifiziert. Ggf. das Element über die ID im richtigen Store suchen oder das Element über StoreElement.importStoreElement() importieren.

[graulich]

Über welches StoreElement-Objekt soll ich den Import denn ausführen? Über das bereits vorhandene StoreElement mit der "selben" UID oder über das Parent-StoreElement des zu überschreibenden StoreElements?

Es gibt noch eine weitere Frage die damit zusammenhängt.

Wir haben in einem 4.2.453.46978 Projekt ohne aktivierte Freigabe ein Medium über den FS-Client gelöscht, es dann auf dem MediaStoreRoot nochmals via Script importiert (über UserService.importStoreElements).

Das neue Medium ist auf erster Ebene des MediaStores vorhanden, hat jedoch nicht wie erwartet die UID "handwash" sondern "handwash_1".

Versuchen wir das Medium umzubenennen (sowohl über FirstSpirit-Client als auch via Script) bekommen wir eine Fehlermeldung, dass diese UID bereits von einem anderen Element genutzt wird. Es ist das Element mit LongID welches wir zuvor über den FirstSpirit-Client gelöscht hatten.

Gibt es da nach dem Löschen irgendwas, was man beachten muss, damit die UID des gelöschten Objektes im jeweiligen Store wieder freigegeben wird? Wie gesagt, die Freigabe ist nicht aktiviert...

Beste Grüße

Dominic Graulich

Hab das Problem schon selbst rausgefunden.

Das Problem liegt (wieder einmal) in im Hintergrund geführten Freigabeständen nachdem die Freigabe auf einem Projekt einmal aktiv war und danach wieder deaktiviert wurde.

Gibt es eine Möglichkeit diese Freigabestände - die ja eigentlich sinnlos sind, wenn die Freigabe deaktiviert ist - zu "resetten"?

Das wäre mal ein Hilfreiches Skript. Dieses Problem hatten wir schon unzählige Male bei unseren Kunden, die irgendwann mal zum "Spielen" die Freigabe aktiviert hatten.

Liebe Grüße
Dominic