TechNotes

Das Attribut Sprache (Addr.LangNo) ist in der Datenbank als numerisch definiert. Über die Business-Logik ist festgelegt, dass im BC 87751nur Sprachnummern von 1 – 9 erfasst werden können.

Wird im WS 11000 nun etwas anderes als eine gültige Sprachnummer eingegeben, so erscheint die gewohnte Fehlermeldung.

Nun verändern wir via BO-Modell Redefinition das Attribut Addr.LangNo so, dass wir im User Interface etwas ganz anderes eingeben können. z.B. Die Sprache im Klartext. Wir ändern also die Eigenschaft auf alphanumerisch, 10-stellig.

Im User Interface (WS 11000) kann nun die Sprache im Klartext eingegeben werden.

Aber der Business-Server lässt sich dadurch nicht überlisten. Die Fehlermeldung beim Speichern ist klar.

Das System weist uns hier darauf hin, dass ein numerischer Wert in der Form N2.0 erwartet wird. (Was durch den Business-Server noch weiter eingeschränkt ist, da nur einstellige Sprachnummern erlaubt sind.)

Nun schränken wir die Eingabemöglichkeit auf Numerisch einstellig ein.

Damit kann nun im User Interface schon gar kein zweistelliger Wert mehr eingegeben werden. Also schon eine weitere Eingabehilfe für den User.

Vorgabewerte sind ein beliebtes Hilfsmittel um den User beim Erstellen von neuen Datensätzen (z.B. Adressen) zu unterstützen. In diesem Zusammenhang ist es wichtig zu wissen, dass die Vorgabewerte nur in denjenigen Kontexten zum tragen kommen, die beim Neuerstellen eines Datensatzes auch aktiv sind.

Ein schönes Beispiel um dieses Verhalten aufzuzeigen ist das Neuerstellen einer Adresse.

Vorgabewerte kommen nur zum Tragen, wenn sie Attribute betreffen die in diesem BC vorhanden sind. Man kann also keinen Vorgabewert beispielsweise für Addr.Phone1 erfassen, weil dieses Attribut hier nicht vorhanden ist. Warum ist das so? Das hat mit dem Kontext zu tun. Beim neu Erfassen einer Adresse besteht der Record in der Datenbank noch nicht. Unser Business Server kann also einen Vorgabewert nirgends ablegen. Nur für Attributwerte die im Neuerfassungs-BC vorhanden sind, kann der Vorgabewert aus der BO-Modell Redefinition gelesen und in obigem BC verwendet werden.

Diese Einschränkung kann jedoch folgendermassen umgangen werden:

Es wird ein DIY-BC erstellt mit dem man eine neue Adresse erfasst. Für alle dort verwendeten Attribute können jetzt Vorgabewerte definiert werden und diese werden dann auch korrekt vorgeschlagen.

Die Telefonnummer1 (Addr.Phone1) wird folgendermassen redefiniert:

Dann wird ein DIY-BC erstellt mit welchem man eine Adresse neu erstellen kann. Dort muss nun auch die Telefonnummer1 eingetragen sein. Der in der BO-Modell Redefinition eingetragene Wert wird jetzt korrekt vorgeschlagen.

Auch bei den Verknüpfungen mit Textblöcken gibt es Einschränkungen. So ist es beispielsweise nicht möglich sich eine Textblock-Nr. in einem freien Feld eines Adress-Pools anzeigen zu lassen.

Die BO-Modell Redefinition sähe so aus:

Beim Verwenden dieses Attributs wird nun aber folgende Fehlermeldung angezeigt:

Grund: Pro Adresse können mehrere Textblöcke aktiv sein. Das lässt sich in einem freien Feld nicht abbilden. Ausserdem kann es noch einen Textblock pro Sprache geben, was die Anzahl der Beziehungen zusätzlich erweitert.

Bei der BO-Modell Redefinition können wir auch eine Bereichs-Beziehung eingeben. Das bedeutet, dass der auf diesem Attribut eingegebene Wert mit dem hier definierten Bereich verglichen wird. Befindet sich der eingegebene Wert ausserhalb des Bereiches, bleibt die rote Markierung im User Interface bestehen und weist den User darauf hin, dass hier etwas nicht stimmt.

Um das zu demonstrieren, wird wieder die Sprachnummer (Addr.LangNo) herangezogen. In unserer Beispiel-Installation, haben wir folgende Sprachnummern erfasst: 1 Deutsch, 2 Français, 3 English, 4 Italiano, 9 Suaheli. Die Sprachnummer wird nun via BO-Modell Redefinition so angepasst, dass nur noch Sprachnummern von 2 bis 4 gültig sind.

Wird nun eine Sprachnummer eingetragen die nicht dem definierten Bereich entspricht, wird dies wie oben beschrieben mit einer roten Markierung dargestellt.

Wird eine Sprachnummer eingegeben die im Bereich liegt, so verschwindet die Markierung.

Ist die Checkbox Eingabe von Werten ausserhalb der Beziehung möglich auf obiger Redefinition passiv, so lassen sich beispielsweise im WS 11000 keine falschen Werte speichern.

Diese Funktionalität ist jedoch nicht durchgängig verfügbar. Gerade wenn Attributwerte über Drittprogramme gespeichert werden, dann ist es möglich "falsche" Werte zu speichern.

Grund: Diese Werte sind gem. Business Server plausibel und können vom System gespeichert werden. Ein Fehler würde erst auftreten, wenn z.B. die Sprachnummer 2 im System nicht erfasst ist.

Es ist Aufgabe des Programmierers, hier allenfalls eine Fehlermeldung auszugeben.

Mit dem Service GetInfoBoAttr lässt sich die BO-Modell Redefinition auslesen. Anschliessend kann auf die Eingabe von "falschen" Werten entsprechend reagiert werden. (Infos zu GetInfoBoAttr siehe separates Kapitel.)

Eine weitere sicher in div. Projekten vorkommende Anforderung wird das Sperren von Attributen sein. Ziel ist es damit beispielsweise das Verändern von durch Abläufe vorgegebenen Werten zu verhindern. Wie weiter oben beschrieben, sind die Redefinitionen immer abhängig vom Kontext. Somit ergeben sich auch hier wieder Grenzen die nicht alles ermöglichen was man in einem Projekt gerne umsetzen möchte. Aufgezeigt wird es am Beispiel des Netto-Preises auf der Verkaufsposition. (SalDocItem.NetSP)

Es soll erreicht werden, dass dieses Attribut beim Erfassen einer neuen Position nicht beschrieben werden kann.

Es ist nun zu beachten, dass beim Neuerstellen einer Position ja grundsätzlich dieselben Umstände herrschen wie sie im Beispiel mit dem Neuerstellen einer Adresse beschrieben worden sind. d.h. Was zu diesem Zeitpunkt nicht im Kontext steht, kann auch nicht berücksichtigt werden.

BO-Modell Redefinition:

Aus dem eingangs erwähnten Grund, ist nun aber im WS 51000 das Attribut beim Neuerstellen einer Position nicht gesperrt. Zu diesem Zeitpunkt gibt es keinen Kontext der das ermöglichen würde. (Technische Umsetzung im WS 51000. Also das Konzept dieses WS)

Erst wenn die Position gespeichert wurde, kann ein Kontext hergestellt werden und das Attribut ist für die weitere Bearbeitung gesperrt.

Wird nun aber ein DIY-BC erstellt mit dem man eine Position neu erfassen kann und ist das Attribut SalDocItem.NetSP in diesem DIY-BC vorhanden, so kann der Kontext sofort hergestellt werden. Das Attribut ist von Beginn an für die Eingabe gesperrt.