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
System	Q1B	Hier sind die Systemdaten gespeichert
Customizer	Q2B	Hier sind die Customizing-Daten gespeichert
Personen	Q3B	Hier sind die Personendaten gespeichert
Anwendungsdatenbanken	Name	Beschreibung
Personen	Q3B	Hier sind die Personendaten gespeichert
Kaufmännische Funktionen	Q4B	Hier sind die kaufmännischen Daten gespeichert
Projekt- und Portfoliomanagement	Q5B	Hier sind die Projekt- und Portfoliomanagementdaten gespeichert
Request Management	Q6B	Hier sind die Request Management-Daten gespeichert
Content Management	Q7B	Hier sind die Content Management-Daten gespeichert
Kundendatenbank	Name	Beschreibung
Kundendatenbank	K[Lizenznummer]	Enthält individuelle Datentabellen.

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 gecustomi­zed 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

• Weitere Informationen zum Autonomen Modulaufruf

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.