Customizing-Regeln
Allgemeine Informationen
Allgemeines zum Customizer
Information
- Der PLANTA customizer bietet die Möglichkeit, individuelle Geschäftsprozesse in PLANTA-System abzubilden, von der Anpassung der Terminologie über die Definition von Benutzerrollen bis zur Erstellung von Schnittstellen. Es wird zwischen Modul- und System-Customizing unterschieden.
- Der Modul-Customizer ermöglicht die rollen- und benutzerspezifische Erstellung und Anpassung von PLANTA-Menüs und Modulen.
- Bei System-Customizing geht es nicht um einfache Anpassungen wie beim Modul-Customizing, sondern um erhebliche Eingriffe in das PLANTA-System.
- Die wichtigsten PLANTA-Datenbanken sind:
| Systemdatenbanken |
Name |
Beschreibung |
| Anwendungsdatenbanken |
Name |
Beschreibung |
| Kundendatenbank |
Name |
Beschreibung |
| Kundendatenbank |
K[Lizenznummer] |
Enthält individuelle Datentabellen. |
| Content Management |
Q7B |
Hier sind die Content Management-Daten gespeichert |
| Request Management |
Q6B |
Hier sind die Request Management-Daten gespeichert |
| Projekt- und Portfoliomanagement |
Q5B |
Hier sind die Projekt- und Portfoliomanagementdaten gespeichert |
| Kaufmännische Funktionen |
Q4B |
Hier sind die kaufmännischen Daten gespeichert |
| Personen |
Q3B |
Hier sind die Personendaten gespeichert |
| Personen |
Q3B |
Hier sind die Personendaten gespeichert |
| Customizer |
Q2B |
Hier sind die Customizing-Daten gespeichert |
| System |
Q1B |
Hier sind die Systemdaten gespeichert |
Achtung
- Mit dem PLANTA customizer kann das gesamte PLANTA-System verändert werden.
- Falsch angewendet, kann dies zu Datenverlust oder PLANTA-Systemzerstörung führen.
- Richtig angewendet, ermöglicht die Flexibilität des Customizers eine individuell komplett angepasste Gestaltung des PLANTA-Systems.
- Es ist wichtig, immer eine Datensicherung vor dem Customizing durchzuführen.
- System-Customizing kann die Funktionalität des PLANTA-Systems grundsätzlich verändern, also auch zerstören! Sorgfältige Planung der Vorhaben und Datensicherung vor Beginn der Ausführung sind unerlässlich.
- Die gesamte PLANTA-Funktionalität ist in den Datentabellen den Datenbanken Q1B – Q3B hinterlegt. Wird an geeigneter Stelle eine funktionszerstörende Veränderung vorgenommen, kann dies im Extremfall zur Folge haben, dass PLANTA-System nicht mehr aufgerufen werden kann. Ist in einem solchen Fall keine Datensicherung verfügbar, führt das zum Verlust aller Customizing-Informationen und zur Notwendigkeit einer Neuinstallation. Die Inhalte der Datenbanken Q1B, Q2B und Q3B lassen sich nur mit PLANTA selbst verändern.
- Im Zweifelsfall ist es besser, vor einer Maßnahme Beratung von PLANTA einzuholen.
- Die Datenbanken Q1B, Q2B und Q3B sind applikationsunabhängig. Der System-Customizer benötigt diese, um die Datenbanken Q4B – Q7B zu bearbeiten. In den Datenbanken Q1B, Q2B und Q3B darf nicht gecustomized werden.
- Das bedeutet, dass es nicht zulässig ist, den Customizer zu customizen.
- Es wird empfohlen, nur geschulten Benutzern die Berechtigung für Customizing zu geben.
Gliederung des Modul-Customizers
Datenstruktur
- PLANTA project-Datensätze werden in Datenfeldern der Module bearbeitet.
- Ein Modul besteht aus Datenbereichen.
- Ein Datenbereich
- entspricht einer Datentabelle
- besteht aus Datenfeldern
- Ein Datenfeld entspricht einem Dataitem.
- Ein Dataitem gehört zu einer Datentabelle.
- Die Dataitems einer Datentabelle bilden den Datensatz.
Moduldetails
- Einem Modul
- muss mindestens ein Datenbereich zugeordnet werden.
- können beliebig viele Datenbereiche zugeordnet werden.
- Ein Datenbereich
- kann mehrfach verwendet, d.h., mehreren Modulen zugeordnet werden.
- muss mindestens ein Dataitem als Datenfeld zugeordnet bekommen.
- kann beliebig viele Dataitems als Datenfelder zugeordnet bekommen.
Widerspiegelung Datenbank im Modul
Regeln
Globale Einstellungen
Regel
- In den globalen Einstellungen müssen alle in Makros verwendete Objekte hinterlegt werden, z.B.
- Module
- Modulvarianten
- Dialogmeldungen
- OLEs
- Dies gewährleistet eine einfache Austauschbarkeit von Objekten, z.B. Modulen, ohne alle Python-Skripte durchsuchen zu müssen.
Try/Except in Python-Code
Regel
- In Python-Code darf Try/Except nur verwendet werden, wenn
- die Verwendung in einem Kommentar begründet wird oder
- ein bestimmter Fehlertyp abgefangen wird
Neustarten des Servers
Regel
- Im Falle von Änderungen am Data-Dictionary (DT412) muss der Server aufgrund des Preloadings neu gestartet werden.
- Dazu wird vom System die Python-Funktion restart_server() bereitgestellt.
- Der Administrator kann unter Linux den Server mit "/etc/init.d/planta reload" neustarten.
Session-Neustart nach Customizingänderungen
Regel
- Symbole, Farben und Formate werden gecacht, daher muss nach Änderungen an diesen die Session neugestartet werden.
Autonomer Modulaufruf
Ziel
- Beim Aufruf von Modulen darf das Untermodul vom Ausgangsmodul keine Anweisungen erhalten, die das Verhalten des Untermoduls beeinflussen.
Vereinbarungen
- Module müssen mit Hilfe von Python so gecustomized werden, dass sie die auszuführende Aktion beim Aufruf selber verwalten können.
- Nach dem Modulaufruf darf kein Menüpunktbefehl folgen.
- Als Filterkriterium werden nur noch @L-Variablen verwendet, keine @Ds.
- Modulnummern werden nicht in Python fest programmiert, sondern die Modulnummern sind in globalen Variablen zu speichern und aus diesen auszulesen.
Details
Inkarnationen
Regel
- Für jede Inkarnation, die nicht output ist, muss
- eine Listbox zugeordnet werden und
- die Checkbox Listboxzwang aktiviert werden.
Startup-Module
Regel
- Jedes Startup-Modul, das ein anderes Modul startet, muss vor dem Aufruf des Moduls prüfen, ob dieses bereits geöffnet ist,
- wenn ja, soll das bereits geöffnete Modul fokussiert werden.
- wenn nein, soll das Modul gestartet werden.
Python-IDs
Regel
- Python-IDs von Standard-DIs, -Datenbereichen, -Datenfeldern und in den globalen Einstellungen dürfen nicht geändert werden.
- Python-IDs von individuellen Dataitems in Standard-Datentabellen müssen mit L und der Lizenznummer anfangen, z.b. L111_stakeholder
- In individuellen Datentabellen kann die Lizenznummer weggelassen werden
- Vorteil: Wird für ein DI, das die Projekt-ID beinhaltet, die Python-ID pr_id hinterlegt, kann ein Standardmakro verwendet werden um ein Projekt aufzurufen.
DI-Bezeichnungen
Regel
- Sinnvolle DI-Bezeichnungen verwenden - z.B. ein Feld nicht "Apa:Name+Vorname" nennen, sondern nur "Name". Die "technischen Informationen" können im Notizfeld hinterlegt werden.
png 
