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

Customizer.png

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.
Topic attachments
I Attachment History Size Date Comment
Pngpng Customizer.png r1 22.5 K 2012-09-19 - 09:51  

         PLANTA project









 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl