OpaccERP als Produkt verfügt über ein Business-Model/-Konzept, das
neutral ist. Bei einem Kundenprojekt wird das
OpaccERP-Business-Model/-Konzept verfeinert und/oder ergänzt. Ein Teil
dieser Arbeit spiegelt sich in den Eigenschaften von
BusinessObject-Attributen (BO-Attributen) wieder.
BO-Attribut Eigenschaften
Die
BO-Attribut Eigenschaften spielen in folgenden Bereichen eine wichtige
Rolle:
-
Business-Server
Die Prüfung des BO-Attribut-Wertes vor
dem SaveBo; d.h. diese Werte dürfen das
OpaccERP-Business-Model/-Konzept nicht verletzen.
-
UI (User Interface)
Das User Interface
(Benutzeroberfläche) soll den Anwender während der Interaktion mit dem
System dabei unterstützen, die Daten/Werte korrekt einzugeben. d.h.
diese Eingaben sollten mit möglichst grosser Wahrscheinlichkeit die
Prüfung durch den Business-Server bestehen.
Es ist nur allzu verständlich, dass bei einem Projekt ein
grosses Interesse besteht, Einfluss auf die Eigenschaften von
BO-Attributen ausüben zu können. Es ist somit wichtig, dass in einem
Projekt die BO-Attribut Eigenschaften nicht nur dem
OpaccERP-Business-Model entsprechen, sondern auch die Projekt-Konzepte
widerspiegeln. Um nun projektbezogen die Eigenschaften von BO-Attributen
zu verfeinern, wurde die Möglichkeit der BO-Modell Redefinition
geschaffen.
Grundsätze
Der wichtigste Grundsatz im
Zusammenhang mit der Redefinition von BO-Attributen ist
folgender:
BO-Modell Redefinitionen wirken nur im User
Interface!
Sie sind als Erweiterung resp. Verfeinerung der
UI-Vorlagen gedacht. Der Business-Server "weiss" nichts von diesen
Redefinitionen und arbeitet weiter auf Basis des
OpaccERP-Business-Model.
Eine logische Folge aus der
OpaccERP-Architektur ist:
Der Business-Server kennt seine Clients
nicht und es ist ihm egal wie BO-Attribute durch die Clients dargestellt
werden.
Clients können in diesem Zusammenhang sein:
-
BackOffice (Java-UI von OpaccERP)
-
FrontOffice
-
Excel AddIn
-
Groupware Integration für Exchange
-
Visual Basic Programme (Dritt-Anwendungen)
-
etc.
Was heisst das nun konkret? Nichts anderes als, dass der UI
Programmierer selber dafür verantwortlich ist, dass möglichst korrekte
Daten aus dem UI an den Business-Server übergeben werden. Im Falle eines
DIY-BC oder den BO-Modell Redefinitionen ist derjenige der
"Programmierer", der so ein BC erstellt oder die Redefinitionen
vornimmt.
Weitere Grundsätze:
-
Der Business-Server verwaltet die BO-Modell Redefinitionen,
hält sie aber von der Business-Logik separiert.
-
BO-Modell Redefinitionen verändern keine Regeln.
-
Vom Datentyp her können über die BO-Modell Redefinition nur
Verfeinerungen resp. Einschränkungen gemacht werden.
Beispiel:
Ein in der Datenbank alphanumerisch definiertes Feld kann im UI
numerisch "redefiniert" werden. Umgekehrt funktioniert es jedoch
nicht.
-
Wenn ein Attribut im DIY-Panel gezeigt und verändert werden
kann, dann ist im Business-Server keine Sperre oder Logik mit diesem
Attribut verbunden. => Wird es im normalen Kontext (damit ist ein
"Nicht-DIY-Panel-Bereich" in einem BC gemeint) nicht gezeigt, ist das
UI dafür verantwortlich resp. der Programmierer der diesen UI-Design
gemacht hat.
 |
Achtung
Freie Attribute, wie
auch alle Einstellungen bezüglich der Objektverwaltung gehören weiterhin
zum OpaccERP-Business-Model und sollten nicht mit BO-Modell Redefinition
verwechselt werden.
|
Die nachfolgende Grafik soll die obigen
Grundsätze etwas verdeutlichen.
Die BO-Modell Redefinitionen werden pro Mandant erfasst und
verwaltet.
