Tech Notes

Grundlagen

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
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.
Praxis-BO_Redef_01a.jpg
Die BO-Modell Redefinitionen werden pro Mandant erfasst und verwaltet.