Mit der Möglichkeit kaskadierende Projekte zu verwenden ist eine Systematik entstanden, den Entwicklungs-, Auslieferungs- und Hotfixprozess vollkommen neu zu gestalten.
Die Idee ist dabei, Programme nicht mehr projektindividuell zu übersetzen, auszuliefern und zu hotfixen, sondern direkt die übersetzten Programme einer HDL Freigabe zu verwenden.
Konfiguration einer Projektkaskade
Im Root-Verzeichnis eines Projektes wird nun nach einer Datei Namens "hhprojlist.txt" gesucht. Existiert diese Datei, handelt es sich um ein kaskadierendes Projekt.
In dieser Datei müssen alle Vorgängerprojekte in der gewünschten Reihenfolge festgelegt werden.
Beispiel:
In dem Beispiel wird von einer "üblichen" SOG ERP-Installation Vorort beim Anwender ausgegangen.
Inhalt der Datei s:\sogerp\hhprojlist.txt:
\\server\sog\kunde1412;\\server\sog\hdlfrg1412
Durch diese Konfiguration wird festgelegt, dass die beteiligten Projekte in der Reihenfolge s:\sogerp, \\server\sog\kunde1412 und \\server\sog\hdlfrg1412 verarbeitet werden. In dieser Reihenfolge wird also nach Einstellungen, Konfigurationsdateien, Masken-Definitionen usw. gesucht.
Alternativ kann in der hhprojlist.txt auch ein Projektkürzel (kunden1412 oder hdlfrg1412) verwendet werden. In diesem Fall muss jedoch auch das verwiesene Projekt registriert sein. Wurde auch ein "_local" Projekt zusätzlich registriert, würde dieses vorrangig verwendet.
Wird das im obigen Beispiel definierte Projekt registriert, werden folgende Umgebungsverzeichnisse (in der angegebenen Reigenfolge) verarbeitet:
\\server\sog\hdlfrg1412\env
\\server\sog\kunde1412\env
s:\sogerp\env
s:\sogerp\env\${HHENVDOMAIN}
Bitte beachten Sie, dass env\${HHENVDOMAIN} nur im Vorort-Projekt verarbeitet wird. Firmendefinitionen werden also nur aus dem Vorort-Projekt verarbeitet.
Durch die angegebene Reihenfolge ist sichergestellt, dass jede Variable im Vorort-Projekt einen endgültigen Wert bekommen kann.
Innerhalb der Registrierungsdateien stehen die beiden neuen Schlüsselwörter "envxpath" und "envxpathexp" zur Verfügung.
Mit diesen können einzelne PATH-Variablen über mehrere Konfigurationen hinweg jeweils mit Semikolon getrennt, erweitert und aufgebaut werden.
Die Einzelpfade der Vorgängerprojekte stehen außerdem in den Variablen "ProjPath3" und "ProjPath2" zur Verfügung.
Umstellung eines bestehenden Projektes
Bei Umstellung eines bestehenden Projektes auf diese neue Systematik ist folgende Vorgehensweise zu beachten:
hhproj.txt checken
hhprojlist.txt anlegen
env-Verzeichnis verändern.
regenv
sogerpconsole -casprojprep -nocobinit -usestdobfac
=> Siehe SOGERPConsole
ggf. manuelles Aufräumen
=> Dateien unter etc
=> cube ??
=> prc ??
=> scr bis auf script.proj
=> Solutions bis auf AllUser
=> sql Verzeichnisse und Einzeldateien
=> hlp Verzeichnis
=> prc Verzeichnis
=> rpt Verzeichnis
=> scr Alles außer Script.Proj
=> SQL Komplett
=> txt komplett
=> xml komplett
=> sogdbfiles genau prüfen
Laden der Masken in die Datenbank
Wird in einem kaskadierenden Projekt mit Masken in der Datenbank gearbeitet, so können die Masken der Basisprojekte mit folgendem Kommando in die Datenbank aktualisiert werden.
sogdbfile -importdisk
Bestimmung des SOG-Projektnamen
Zur Bestimmung des SOG-Projektnamen eines kaskadierenden Projektes werden alle Projektnamen nacheinander verarbeitet.
Das erste Projekt, dass entweder mit der Zeichenfolge "hdlcas" oder aber nicht mit einer der Zeichenfolgen "hdl", "sogerp" oder "vacos" beginnt, bestimmt den SOG-Projektnamen.
Endet der so bestimmte Name mit einer 4-Stelligen Ziffernfolge, wird diese entfernt.
Den nachbleibende String wird als SOG-Projektname verwendet. Dieser Projektname bestimmt über die zur Laufzeit bedingt ausgeführten Programmpassagen.
Besonderheiten bei der Installation mit SOGActiveSetup
Im Kundencenter muss im Standort im Datenfeld "SOG ERP Projekt bei der SOG" eine Liste von erlaubten Download-Projekten hinterlegt werden.
Zum Test: hdl,hdlcas,sogerp1412
Im Echtbetrieb: hdlfrg1412,kunde1412,sogerp1412
Bei der Installation mit ActiveSetup sind folgende Eingabe zu machen:
SOG Projekt: sogerp1412
Lokales VACOS Verzeichnis: sogerp
Während der Installation: In SOGERPInstall
Optionen - hhprojlist.txt
Kundenprojekt: c:\sog\hdlcas Im Echtbetrieb: c:\sog\kunde1412
HDL Freigabeprojekt: c:\sog\hdl c:\sog\hdlfrg1412
(Die Namen müssen den sogpubproj-Projekten und der kc-Freigabe entsprechen!!)
Datenbankname: sogerpdb
Aufsetzen eines Testprojektes zum Testen einer neue SOG ERP-Version:
// Einmalig/erstmalig oder bei Bedarf (Achtung, löscht alle alten Test-Änderungen!)
sogsync -src c:\sog\sogerp -dest c:\sog\sogerptest
// Löschen von Installationsmerkern (Nur bei Erstinstallation löschen)
del etc\done*
// Überarbeitung Firmensteuerdatei: Achtung: Datenbanknamen ändern.
notepad c:\sog\sogerptest\env\DOMÄNE\firm01.env => MSSDB ändern.
// Projekt registrieren
cd c:\sog\sogerptest
regenv
Aktuelle Firma (01) einstellen
// Einstellen der Basisverzeichnisse:
notepad c:\sog\sogerptest\hhprojlist.txt
// Aktualisieren Testprojekt aus SOG-Freigabe
sogsync -asetup -asproj -nodel -src sogerpJJMM -dest c:\sog\sogerptest
// Installation des Testprojektes mit "normaler" Installationsroutine.
ini sogerptest
bin\sogerpcontrol\sogerpinstall.exe -X -typ vacos -hhproj sogerptest -
Verwendung von Dateien in einem Freigabeprojekt
Um einen Dateipfad festlegen zu können, der dynamisch auf das jeweils zuletzt ausgelieferte Freigabebasisprojekt verweisst, kann die Schreibweise
${PROJ}\dateiname
verwendet werden.
An den Stellen in der SOG ERP Software, an denen dies vorgesehen wurde, wird ein solcher Pfadname so aufgelöst, dass die entsprechende Datei nacheinander in allen registrierten kaskadierenden Projekten gesucht wird.
Alternativ kann auch
#{PROJ}\dateiname
verwendet werden. Damit kann ein solcher Pfad an anderen Pfadauflösungsroutinen vorbeigetragen, und direkt dem entsprechenden Programm zugeleitet werden.