Das Zeitverhalten beim Lesen und Bearbeiten von Daten in Masken ist von der Komplexität der Maske abhängig. Zum einen wird für die Darstellung der Maske JavaScript Code auf dem Client ausgeführt. Zum anderen kann durch einzelne SQL Abfragen oder eine große Summe von Abfragen das Zeitverhalten negativ beeinflusst werden.
Die Verarbeitung und Bereitstellung der Maske durch den Web-Server stellt in der Regel kein nennenswertes Problem dar, falls dieser keine der schon diskutierten Probleme aufweist.
JavaScript
Für jedes konfigurierte Steuerelement wird JavaScript zur Erzeugung, Darstellung und Verwaltung ausgeführt. Umso mehr Steuerelemente in der Maske konfiguriert sind, umso mehr JavaScript Leistung wird benötigt. Dabei benötigen unterschiedliche Steuerelemente auch unterschiedliche JavaScript Leistung. Beispielsweise benötigt das „Berechnete Feld” kaum JavaScript Leistung, wohingegen der „Detailkalender” relativ viel benötigt. Daher wurde das Laden vom Detailkalender und auch der Detailansichten zeitverzögert implementiert. Das heißt, zuerst wird die Maske mit den Feldern geladen und anschließend in separaten Anfragen die Kalender und Ansichten.
Sind alle anderen mögliche Ursachen wie Netzwerk, Web-Server, SQL-Server, Client Hardware und Auslastung des Clients durch Fremdprodukte ausgeschlossen, ist nur noch die Reduzierung der Maskenkomplexität möglich.
SQL-Abfragen durch Steuerelemente
Abhängig von der Art der Steuerelemente, können diese SQL-Abfragen absetzen.
Beispielsweise muss für „Spaltenwert aus Relation” der angesprochene Datensatz geladen werden, wobei jeder Datensatz nur einmal geladen werden muss. Das heißt, das mehrfache Verwenden von „Spaltenwert aus Relation” mit Verweis auf den selben Datensatz macht nur das einmalige Laden des Datensatzes notwendig.
Die Steuerelemente sind optimal implementiert, so dass keine unnötigen oder teure Abfragen zu erwarten sind, falls die Anbindung an den SQL-Server und das Zeitverhalten des SQL-Servers selbst optimal sind.
Formeln
Durch die Formeln ist man in der Lage, eine hohe Flexibilität in den Masken zu erreichen. Durch Formeln wie BAGetPrimarySource(), BAGetPrimarySourceByRelation() und die Verwendung von Free Joins können auch SQL Abfragen erstellt werden, welche dann ein schlechtes Zeitverhalten aufweisen können und damit das Öffnen der Maske verzögern. Dies kann aber auch einfach durch eine hohe Anzahl an Formeln verursacht werden.
Formeln können in Masken an verschiedenen Stellen genutzt werden Dazu zählen:
- Steuerelement “Berechnetes Feld”
- Formeln für die Sichtbarkeitssteuerung
- Formeln für die Bearbeitbarkeit
Zurzeit ist es nicht möglich die Ergebnisse von Abfrage in Formeln mehrfach zu verwenden. Dies geht weder innerhalb einer Formel als auch nicht über Formeln hinweg. Daher muss an jeder Stelle, an der beispielsweise ein Wert des übergeordneten Datensatzes genutzt wird, die Abfrage selbst ausgeführt werden.
Beispiel (BA.CRM): “Abhängig vom Jahresumsatz der Firma, soll in den Vorgängen verschiedene Hinweise angezeigt werden”
Iif(BAGetPrimarySource('<OrmActivityBase>','RelatedParents', 'top', '<OrmCRMCompany>', [AnnualRevenue]) > 100000,
'A Kunde',
Iif(BAGetPrimarySource('<OrmActivityBase>','RelatedParents', 'top', '<OrmCRMCompany>', [AnnualRevenue]) > 50000,
'B Kunde',
Iif(BAGetPrimarySource('<OrmActivityBase>','RelatedParents', 'top', '<OrmCRMCompany>', [AnnualRevenue]) > 5000,
'C Kunde',
'D Kunde')
)
)An drei Stellen wird der Jahresumsatz der Firma benötigt. Jede dieser Stellen verursacht eine eigenständige SQL-Abfrage. Dies ist auch der Fall, wenn der Jahresumsatz der Firma in verschiedenen Formeln zur Sichtbarkeitssteuerung oder Bearbeitbarkeit eingesetzt wird.
BAGetPrimarySource() und BAGetPrimarySourceByRelation()
Abgesehen von der Problematik, dass die beiden Formeln immer wieder Abfragen generieren, ist in einer Umgebung in der die SQL-Anbindung keine Probleme aufweist, die Verwendung dieser Formeln unproblematisch. Es wird von BA darauf geachtet, das optimierte Abfragen genutzt werden.
Free Joins
Mit der Hilfe von Free Joins stehen einem ein sehr mächtiges Werkzeug zur Verfügung, welches aber auch Abfragen generieren kann, die ein schlechtes Zeitverhalten aufweisen.
Man sollte zum einen zu tiefe Verschachtelungen vermeiden und zum anderen als Schlüssel nur Spalten mit Indizes verwenden. Typischerweise sollte man die Oid von Datensätzen als Schlüssel nutzen.
Detailansicht / Detailkalender
Die beiden Steuerelemente „Detailansicht” und „Detailkalender” dienen zur Anzeige abhängiger Datensätze. Da diese selbst sehr komplexe Abfragen mit möglicherweise schlechtem Zeitverhalten ausführen, werden sie in einem zweistufigen Konzept nachträglich geladen.
Stufe 1: Alle sichtbaren Detailansichten und Kalenderansichten werden mit separaten HTTP Anfragen an den Web-Server erst dann geladen, wenn die Maske im Client aufgebaut ist.
Stufe 2: Alle nicht sichtbaren Detailansichten und Kalenderansichten werden erst dann geladen, wenn sie sichtbar werden. Beispielsweise wenn der Tab aktiv wird, in dem sie eingebettet sind.
Ansonsten ist das Zeitverhalten dieser Steuerelemente von der Komplexität der Ansichten abhängig. Dabei weisen sie aber in der Regel ein deutlich besseres Zeitverhalten als außerhalb der Maske auf, da sie durch die Filterung auf abhängige Datensätze nur einen Bruchteil der Datensätze anzeigen müssen.