Sie befinden sich hier: Referenzleitfäden > Fehlerbehebungstipps für Composer Formulare > Verbessern der Formularleistung

Verbessern der Composer Formularleistung

Verwandte Themen

Die folgenden Empfehlungen werden Ihnen bei der Fehlerbehebung und der Leistungsverbesserung von Lösungen helfen.

Viele dieser Fehlerbehebungsoption treffen auch auf Designer basierte Lösungen zu, aber in diesem Abschnitt wird auf Composer als das Lösungsdesigntool verwiesen.

Auf dieser Seite

Verbessern von Formularladezeiten

Datenverbindungen begrenzen

Zurück zum Anfang

Bildschirm: Winshuttle Composer Datenverbindungen

Winshuttle Composer Datenverbindungen (SharePoint-Listen, eine SQL-Datenbank, Excel-Dateien usw.) können als Quelle für (oder Ziel von) Prozessdaten verwendet werden. Zum Beispiel können Sie Datenverbindungen verwenden, um unter anderem Dropdownfelder zu befüllen oder eine Datenbank zu durchsuchen.

Jede Datenverbindung kann in unterschiedlichem Ausmaß eine Auswirkung auf die Leistung der Lösung haben.

Beim Hinzufügen einer neuen Datenverbindung zur Lösung gibt es ein kleines Kontrollkästchen mit der Bezeichnung Beim Öffnen des Formulars Daten automatisch abrufen.

Wenn dieses Kästchen aktiviert ist, öffnet das Formular die Datenverbindung selbst dann, wenn beim Öffnen des Formulars die Daten nicht benötigt werden.

Diese Einstellung kann einen großen Leistungsunterschied beim Öffnen eines Formulars ausmachen.

Wenn zum Beispiel eine Datenverbindung die Quelle einer Abfragesteuerung ist, die bei Änderung eines Felds ausgeführt wird, werden die Daten nicht benötigt, bis die Abfragesteuerung ausgelöst wird, d. h. der Benutzer aktiv mit dem Formular interagiert, sodass die Datenverbindung nicht geladen werden muss, wenn das Formular geöffnet wird.

Ein Öffnen der Datenverbindung nur zu genehmigen, wenn sie benötigt wird, kann die anfängliche Ladezeiten von Formularen drastisch verbessern.

Empfehlungen

  • In den meisten Fällen sollte dieses Kontrollkästchen aktiviert sein, wenn es als Datenquelle für ein auf einem Dropdownmenü-basierten Feld dient. (Anderenfalls werden die Daten niemals in das Dropdownmenü geladen und der Benutzer sieht keine Auswahl.)
  • Wenn viele Datenverbindungen als Quelle für viele Dropdownfelder dienen, sollten Sie in Betracht ziehen, den Feldtyp von Dropdown zu Textfeld mit einer Suche-Steuerung zu ändern. Das Wählen einer Suche-Steuerung ruft die Datenverbindung zum Zeitpunkt der Verwendung auf, sodass Daten beim Laden des Formulars nicht abgerufen werden müssen.
  • Es ist ratsam, die Anzahl der in die Datenverbindung übertragenen Spalten auf nur die benötigten Felder zu reduzieren. Dies kann dabei helfen, die Zeit zu minimieren, die zum Abrufen der Daten aus der Datenquelle benötigt wird.

XML- und HTML-Größe verringern

Zurück zum Anfang

Die einzigartige Kombination aus XML und HTML hilft Designern dabei, Formulardaten zu sammeln, jedoch verstehen viele Designer die Beziehung zwischen XML und HTML in einer Lösung und ihre Auswirkung auf die Leistung nicht vollständig.

Anzeigen der Formular-XML für ein Winshuttle Formular

  1. Öffnen Sie die (SharePoint-) Liste des Winshuttle Formulars.
  2. Zeigen Sie in der SharePoint-Liste mit dem Mauszeiger auf die Spalte Titel.
  3. Klicken Sie auf Element anzeigen.

Wenn ein Formular geöffnet wird, wird dabei die gesamte XML des Formulars geöffnet. Auf Grundlage der Felder, die für diese Ansicht des Formulars entworfen wurden, wird diese XML in HTML dargestellt, damit sie dem Benutzer angezeigt werden kann.

Je mehr XML ein Formular beinhaltet, desto länger ist die Ladezeit des Formulars, da mehr XML in HTML dargestellt werden muss.

Es ist häufig der Fall, wenn Lösungen entworfen werden, dass Felder und/oder Regeln verwendet werden, die in Tests nicht funktionieren, oder dass ein Prozess verwendet wird, der mehrere Felder und/oder Regeln ersetzt. Werden diese nicht verwendeten Felder jedoch nicht aus der Lösung entfernt, braucht das Formular eine längere Zeit zum Laden.

Das teilweise oder vollständige Entfernen dieses „Abfalls“ aus einer Lösung hilft dabei, die Leistung zu verbessern.

Das Ein- und Ausblenden von Feldern und Gruppen ist eine nützliche Composer Funktion, jedoch kann sich das Ausblenden von nicht benötigten Feldern, anstatt sie komplett zu entfernen, negativ auf die Leistung des Formulars auswirken. Das Entfernen von nicht verwendeten Felder mag die Ladezeit vielleicht nicht grundlegend verbessern, aber jede Sekunde (oder Millisekunde) zählt.

Swimlanes verkleinern und Teilnehmer-Konfliktlöser-Leistung verbessern

Zurück zum Anfang

Winshuttle Prozesse versuchen jedes Mal, alle Swimlanes in einem Workflow aufzulösen, wenn ein Formular gestartet wird. Die Zeit, die ein Konfliktlöser für das Auflösen benötigt, kann auch davon abhängen, was er tut- Dies kann zum Beispiel das Abfragen von SharePoint oder Active Directory sein. Bedenken Sie Folgendes:

  • Das Hinzufügen von weiteren Swimlanes zu einem Workflow erhöht die Ladezeit des Formulars.
  • Das Erhöhen der Benutzeranzahl in einer Swimlane kann die Leistung verringern.
  • Das Verringern der Datenmenge, die ein Formular verarbeiten muss, um eine Swimlane aufzulösen, verbessert die Formularverarbeitungsleistung.
  • Das Entfernen von nicht benötigten Swimlanes aus einem Prozess oder das Verwenden von anderen Methoden, um Swimlanes aufzulösen, kann die Ladedauer des Formulars verbessern (verringern).

Wenn Sie zum Beispiel „SiteGroupDriven“ mit der Systemsteuerungsoption „SelectFromRole“ verwenden, benötigt die Swimlane zum Auflösen mehr Zeit, da die Anzahl an Personen in dieser SharePoint-Gruppe sich erhöht.

Tipp: Versuchen Sie ebenfalls zu vermeiden, auf Listen zu verweisen, die alle Angestellten beinhalten. Ziehen Sie stattdessen in Betracht, eine SharePoint-Abfrage mit einer Teilnehmer-Konfliktlöser-Steuerung in der Formularansicht zu verwenden.

Verarbeitung im Formular minimieren

Zurück zum Anfang

Wenn ein Formular schnell lädt, es aber 60 Sekunden dauert, bis eine Abfrage Daten ausgibt, ist dies noch immer eine mangelhafte Benutzererfahrung, unabhängig davon, wie viel Zeit der Benutzer insgesamt spart. In den folgenden Abschnitten wird beschrieben, wie die Verarbeitung im Formular verbessert werden kann, um eine schnellere, bessere Benutzererfahrung zu erzielen.

Paginierung in großen Datensätzen verwenden

Zurück zum Anfang

Mit Composer 11.0.1 wurde eine Paginierungsoption für Suchergebnisse eingeführt. Das Paginieren von Datensuchergebnissen ermöglicht es einem Formular, gleichzeitig nur eine begrenzte Anzahl an Datensätzen anzuzeigen, wodurch die Zeit verringert wird, die benötigt wird, um nach Ergebnissen zu suchen und sie dem Formularbenutzer anzuzeigen.

Das bedeutet, dass, obwohl es einen großen Datensatz gibt (und daher auch eine große XML-Größe), das Formular nur einen Teil dieser XML darstellt und nur der nächste Zeilensatz dargestellt wird, wenn der Benutzer durch die Ergebnissätze blättert. Dies kann eine große Auswirkung auf die Leistung in einem Formular mit größeren Datenmengen haben.

Wenn größere Datensätze in einem Formular angezeigt werden müssen, sollten Sie Paginierung in Betracht ziehen.

Verwenden alternativer Datenquellen in Betracht ziehen

Zurück zum Anfang

Die Quelle einer Abfrage kann ebenfalls eine Rolle bei in Bezug auf die Verarbeitungszeit in einem Formular spielen. Nicht alle Datenquellen sind gleich performant.

Unter Umständen sollte keine SAP-F4-Suche-Steuerung bei einem Feld verwendet werden, da die Optionen, die ein Benutzer auf Grundlage des Buchungskreises wählen kann, eingeschränkt sein sollten. Die SAP-F4-Suche-Steuerung bietet alle verfügbaren Optionen, jedoch können sie nicht modifiziert werden. Stattdessen können Sie eine Winshuttle Abfrage erstellen, die nachts ausgeführt wird und den Datensatz in einer SharePoint-Liste bereitstellt, in der Sie einen Filter nach Buchungskreis anwenden können.

Andere Optionen erkunden

Query ist außerdem in der Lage, denselben Datensatz in einer SQL-Datenbank bereitzustellen, und es wurde von Datenbankexperten nachgewiesen, dass SQL-Abfragen schneller sind als SharePoint-Abfragen (CAML).

Der Wechsel von SharePoint zu SQL kann nur eine kleine bis keine Auswirkung auf kleine Datensätze oder Datensätze mit Rohdaten haben, jedoch kann er sehr wohl eine Auswirkung auf größere Datensätze oder Datensätze haben, auf die vor dem Ausgeben von Daten eine Vielzahl an Filtern angewendet werden.

Ein weiterer Vorteil von SQL (oder anderer Datenbanken wie Oracle) gegenüber SharePoint ist die Möglichkeit, Ansichten zu erstellen: ein vordefinierter Datensatz, der durch eine Abfrage auf dem Server erstellt wurde und wie jede andere Tabelle als Datenquelle verwendet werden kann.

Das Verwenden von Ansichten kann die Abfragezeit verkürzen, da sie Daten aus mehreren Tabellen beinhalten können. Sie können außerdem Daten beinhalten, auf die die notwendigen Filter bereits angewendet werden.

Ziehen Sie in Betracht, Ansichten der SQL-Datenbank zu erstellen, um die Verarbeitungszeit im Formular zu verkürzen. Wenn eine SQL-Quelltabelle 100.000 Datensätze beinhaltet und Ihr Vorgang nur einen Teil davon benötigt, muss Ihre Abfrage all diese Datensätze analysieren, bevor sie Daten ausgibt. Wenn Sie eine Ansicht in der SQL-Datenbank erstellen, die nur diesen Teil enthält, muss die Abfrage weniger Daten analysieren, wodurch sich die Verarbeitungszeit verringert.

Winshuttle Query optimieren

Zurück zum Anfang

Häufig kann eine Abfrage dazu verwendet werden, nur einen Datensatz zu extrahieren, der in einem Formular verwendet wird, zum Beispiel Informationen eines Materials in einer bestimmten Anlage. Wie kann dies optimiert werden?

Überprüfen Sie das Abfragendesign, um zu bestimmen, ob es möglich ist, anhand von indizierten Feldern anstatt von nicht indizierten Feldern zu suchen. Die Suche anhand von indizierten Feldern verbessert die Leistung.

Wenn darüber hinaus mehrere Abfragen verwendet werden, um mehrere Tabellen zu verbinden, sollten Sie versuchen, einzelne Abfrageskripte für jede Tabelle zu verwenden, anstatt ein Skript, das viele Tabellen verbindet. Dies kann insbesondere dann von Vorteil sein, wenn das Join zwischen SAP-Tabelle A und Tabelle B ein nicht übereinstimmendes Join verwendet, zum Beispiel ein Join, bei dem die Felder nicht dieselbe Definition besitzen.

Ein gutes Beispiel hierfür ist das Abfragen von SAP-Klassifizierungsdaten. Die Klassifizierungsdaten für viele SAP-Objekte (Materialien, Lieferanten usw.) werden in denselben Tabellen gespeichert, und die Felder, die für die Verbindung der Klassifizierungsdaten verwendet werden, sind unterschiedlich.

Einige SAP-Setups setzen den Gebrauch der internen Objektnummerntabelle (INOB) voraus, um Klassifizierungsdaten für ein Material zu finden. Die korrekten Joins sind MARA.MATNR => INOB.CUOBJ => AUSP.OBJEK. Das Feld „INOB.CUOBJ“ verfügt über 18 Zeichen, während der Join zu „AUSP.OBJEK 40“ Zeichen lang ist. Diese Diskrepanz wirkt sich stark auf die Verarbeitungsleistung im Formular aus.

In diesem Fall hat die Erfahrung gezeigt, dass es schneller ist, zuerst „MARA“ und „INOB“ abzufragen um den CUOBJ-Wert zu erhalten, und dann diesen Wert in einer zweiten Abfrage zu benutzen, um Daten von „AUSP“ zu erhalten. Das Aufteilen der Abfrage in mehrere Abfragen führt nicht immer zu schnelleren Ergebnissen, ist aber eine Möglichkeit unter vielen.

Konfigurationsschlüssel aktualisieren

Zurück zum Anfang

Häufig führt ein Formular mit einem Tastendruck mehrere Webdienste nacheinander aus. Dies kann das Ansprechen der Seite verringern und letztendlich zu Zeitüberschreitungen des Webdienstes führen.

Der Standardwert für die Zeitüberschreitung eines Webdiensts ist 500 Sekunden. Obwohl dieser Wert geändert werden kann, ist dies keine echte Lösung für das Ansprechproblem. Jedoch bietet Winshuttle viele Konfigurationsschlüssel, die ein Lösungsentwickler verwenden kann, um die Art und Weise zu ändern, wie ein Prozess oder System ausgeführt wird.

Einer dieser Schlüssel, „WebServiceProgressiveResponse“, ermöglicht es Ihnen anzugeben, wie eine Seite aktualisiert wird, wenn mehrere Webdienste mit einem einzigen Tastendruck ausgeführt werden. Das Festlegen von „WebServiceProgressiveResponse“ auf „True“ zwingt die Seite dazu, mit ihrer Aktualisierung zu warten, bis alle Webdienste abgeschlossen wurden.

Das Festlegen von „WebServiceProgressiveResponse“ zu „False“ ermöglicht es der Seite, sich zu aktualisieren, während die einzelnen Webdienste abgeschlossen werden, wodurch die Ansprechzeit und die Benutzererfahrung verbessert werden können.

Regeln optimieren

Zurück zum Anfang

Formularregeln und ihre verschiedenen Funktionen können sehr unterschiedlich sein. Einige sind reine JavaScript-Regeln, die Formularfeldwerte auf Grundlage anderer Formularfeldwerte oder auf Grundlage von Parametern aktualisieren. Diese grundlegenden JavaScript-Regeln werden im Allgemeinen (nicht immer) Client-seitig ausgeführt. Das bedeutet, dass die Aktion lokale Systemressourcen verwendet (d. h. den PC des Benutzers). Da Client-seitige Regeln nicht mit anderen Servern kommunizieren, reagieren sie für gewöhnlich schnell.

Der Fokus auf Regeln, die nur Client-seitig ausgeführt werden, wird nicht zu großen Verbesserungen führen (wenn überhaupt), außer es liegen Fehler im benutzerdefinierten Code vor.

Regeln, die auf eine Interaktion mit dem Server angewiesen sind, zum Beispiel externe Abfragen und Daten-Suchen, können einzeln auf Leistung optimiert werden.

Es ist ratsam, Regeln zu untersuchen, die auf eine Interaktion mit dem Server angewiesen sind, um zu verstehen, wann jeder dieser Prozesse ausgeführt werden kann. Zum Beispiel: Kann die Regel am Ende des Formulars ausgeführt werden, wenn der Benutzer es einreicht, oder kann sie im Hintergrund durch den Workflow ausgeführt werden?

Wenn ein Formular Abfragen beinhaltet, die beim Laden des Formulars ausgeführt werden, und die Ladezeit des Formulars beträgt 10 Sekunden, wird der Benutzer angeben, eine bessere Erfahrung gemacht zu haben, als wenn es 5 Sekunden dauert, das Formular zu laden, und weitere 5 Sekunden, um es einzureichen, selbst wenn die Wartezeiten identisch sind.

Die Gesamtwartezeit beträgt noch immer 10 Sekunden, jedoch in zwei kürzeren Einheiten. Das Ausführen von Regeln am Ende verbessert vielleicht nicht die Gesamtwartezeit, aber es kann die Benutzererfahrung verbessern.