Hallo Jan+Michaela,
zurück aus dem Urlaub geht's wieder frisch ran an's Werk.
Mein Problem liegt bei folgendem:
Wir haben eine hinreichend notwendige Anforderung, dass 1 konkreter Schedule eine echte, parallele Ausführung durchführen muss (und dieser eine Generierung des Projektes enthält).
Nachdem nun aber alle parallel ausgeführten Schedules den selben Generierungsordner besitzen, die Generierungsdateien jedoch unterschiedlich sind (#global.time, ausführender schedule-owner, etc.).
Das hat zur Folge, dass ich mich schwer tue "works as designed" zu akzeptieren, da eine tatsächliche parallele Ausführung (insb. Generierung) nicht vorhanden ist.
Der Lösungsansatz von Walter ist:
Tipp: einem vorgelagertem Auftragsskript der Pfad des Auftrages auf einen ausführungsabhängigen eindeutigen Wert gesetzt (z.B. Datum) -> "ScheduleEntry.setFolderName(String)".
Das Ganze funktioniert jedoch leider nicht.
Offenbar ist der Wert des Generierungsordners (im fs5staging/projectID/scheduleID/) hier festgehalten:
http://localhost:8000/help/odfs/access/de/espirit/firstspirit/access/schedule/ScheduleContext.html#g...
jedoch gibt es zu diesem Attribut keinen setter...?
Die Methode genutzt wie vorgeschlagen liefert keine sichtbare Änderung, Logausgabe:
INFO 12.08.2013 08:50:37.032 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): new session (ID=929489163660900747, user=SYSTEM, userID=0, type=DUMMY) created
DEBUG 12.08.2013 08:50:37.032 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): Session with ID=929489163660900747 bound to project '20130730_095716_templatemaster_trunk' (ID=57633)
DEBUG 12.08.2013 08:50:37.032 (de.espirit.firstspirit.client.UserServiceImpl): create user service (project=57633), cache class current = 'de.espirit.firstspirit.store.access.ServerStoreElementCacheImpl', release = 'de.espirit.firstspirit.store.access.ServerStoreElementCacheImpl'
INFO 12.08.2013 08:50:37.032 (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): starting task 'setGenericScheduleFolder' - schedule entry '___mfinsterbusch deploy full' (id=61578)
INFO 12.08.2013 08:50:37.036 (de.espirit.firstspirit.impl.access.ScriptContextImpl): INFO @ setGenericScheduleFolder() | loginName: mfinsterbusch | loginUser: SYSTEM | context.getClass().toString(): class de.espirit.firstspirit.server.scheduler.DelegatingScheduleContext | context.getPath(): C:/FirstSpirit5/web/fs5staging/57633/61578/ | schedule.getName(): ___mfinsterbusch deploy full id:61578 | schedule.getFolderName() foo123
INFO 12.08.2013 08:50:37.036 (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): finished task 'setGenericScheduleFolder' - schedule entry '___mfinsterbusch deploy full' (id=61578)
Mein Schedule besteht aus dem Skript, der Vollgenerierung, sowie eine einfache Veröffentlichung in's lokale Dateisystem (neu aufgesetzter Server FS5.0.318, Projekt Mithras Energy.
Anforderung ist, dass der Schedule aus dem JAVA- oder WebClient eines "normalen" (nicht Admin oder System) Benutzers gestartet werden soll.
Hier mein kleines Skript:
import de.espirit.firstspirit.access.schedule.DeployTask;
import de.espirit.firstspirit.access.schedule.ScheduleContext;
/**
*@script setGenericScheduleFolder() mafi 2013-08-13
*
* - this script evaluates the users of the task that started this schedule.
* - the schedule needs to be started in java- or web-client, project-settings is not allowed! Admin is not allowed (no automatic checks).
* - the script also changes the folderName where the generation is done. so that the task can be runned in parallel perspective. it adds a "_<timestamp.format=yyy-mm-dd-hh-MM>_<loginName>"
* - it is important that this script will be exceuted direcly before the generation and the crc-deployment directly after the generation either.
**/
// ### CONFIG ### - constants to configure
// ### VARS ### - changed dynamicly by the script
// default value for deployment path
schedule = context.getTask().getScheduleEntry();
loginName = schedule.getRunningEntries().get(0).getUser().getLoginName();
loginUser = context.getUserService().getUser().getLoginName();
test = context.getUserService().getConnection().getUser().getLoginName();
schedule.setFolderName("foo123");
schedule.getRunningEntries().get(0).getScheduleEntry().setFolderName("blaa");
context.logInfo("INFO @ setGenericScheduleFolder() | test: "+test+" | loginName: "+loginName+" | loginUser: "+loginUser+" | context.getClass().toString(): "+context.getClass().toString()+" | context.getPath(): "+context.getPath()+" | schedule.getName(): "+schedule.getName()+" id:"+schedule.getId().toString()+" | schedule.getFolderName() "+schedule.getFolderName()+" ");
Nach einer längeren Überlegung habe ich sogar noch ein weiteres Problem:
Ich sehe derzeit keinen Weg, wie ich den konkret gestarteten Schedule des aktuellen Users bekomme.
Ich kann zwar alle Schedules auslesen und auch den User ansehen, der diesen gestartet hat, weiß aber im Skript nicht mehr, welcher User das ist.
Zusammenfassung:
Problem a)
Jede Generierung eines Schedules in "paralleler Ausführung" generiert in das selbe Verzeichnis (nicht gewollt, da nicht wirklich parallel).
Problem b) Identifizierung des Users und somit des aktuellen Schedules.
Viele Grüße & Danke,
Maik
)
