Sie können bestimmte Ansätze beim Implementieren Ihres Plug-Ins anwenden, z. B. Objekte zwischenspeichern, Objekte in den Hintergrund setzen, Objekte klonen usw. Durch solche Ansätze können Sie die Leistung Ihrer Plug-Ins verbessern, Parallelitätsprobleme vermeiden und die Reaktionsfähigkeit des Orchestrator-Clients erhöhen.

Cache-Objekte

Ihr Plug-In kann mit einem Remotedienst interagieren. Diese Interaktion wird von lokalen Objekten bereitgestellt, die Remoteobjekte auf der Dienstseite darstellen. Sie können die lokalen Objekte zwischenspeichern, statt sie jedes mal vom Remoteservice abzurufen, um eine gute Leistung des Plug-Ins und eine gute Reaktionsfähigkeit der Orchestrator-Benutzeroberfläche zu gewährleisten. Überlegen Sie sich den Umfang des Cache, z. B. ein Cache für alle Plug-In-Clients, ein Cache pro Benutzer des Plug-Ins oder ein Cache pro Benutzer des Drittanbieterdienstes. Wenn der Cachemechanismus implementiert ist, wird er in die Plug-In-Schnittstelle integriert und dient zum Suchen und zur Invalidierung von Objekten.

Objekte in den Hintergrund setzen

Wenn Sie eine umfangreiche Liste von Objekten in der Plug-In-Bestandsliste anzeigen müssen und keine schnelle Möglichkeit zum Abrufen dieser Objekte haben, können Sie diese Objekten in den Hintergrund setzen. Sie können Objekte in den Hintergrund setzen, z. B., indem Sie Objekte mit zwei Zuständen haben: fake und loaded. Angenommen, die fake-Objekte sind sehr einfach zu erstellen und enthalten wenig in der Bestandsliste anzuzeigende Informationen, wie z. B. Name und ID. In diesem Fall ist es möglich, immer fake-Objekte zurückzugeben, und wenn wirklich alle Informationen (das reale Objekt) erforderlich sind, kann die verwendende Einheit oder das Plug-In automatisch eine load-Methode aufrufen, um das reale Objekt abzurufen. Sie können sogar den Objektladevorgang konfigurieren, sodass dieser automatisch startet, nachdem Fake-Objekte zurückgegeben werden. So können Sie den Aktionen der verwendenden Einheit zuvorkommen.

Objekte klonen, um Parallelitätsprobleme zu vermeiden

Wenn Sie für Ihr Plug-In einen Cache verwenden, müssen Sie Objekte klonen. Das Verwenden eines Cache, der immer dieselbe Instanz eines Objekts an jede anfordernde Einheit zurückgibt, kann unerwünschte Folgen haben. Beispiel: Einheit A fordert Objekt O an, und die Einheit zeigt das Objekt in der Bestandsliste mit allen seinen Attributen an. Gleichzeitig fordert auch Einheit B das Objekt O an, und Einheit A führt einen Workflow aus, der mit dem Ändern der Attribute von Objekt O beginnt. Am Ende der Ausführung ruft der Workflow die update-Methode des Objekts auf, um das Objekt auf der Serverseite zu aktualisieren. Wenn Einheit A und Einheit B dieselbe Instanz von Objekt B erhalten, werden für Einheit A in der Bestandsliste alle Änderungen angezeigt, die Einheit B ausführt, und das bereits vor dem Festschreiben der Änderungen auf der Serverseite. Wenn alles ordnungsgemäß abläuft, ist dies kein Problem. Wenn die Ausführung aber fehlschlägt, werden die Attribute von Objekt O nicht für Objekt A wiederhergestellt. In diesem Fall verwenden, wenn der Cache (die find-Vorgänge des Plug-Ins) einen Klon des Objekts anstelle immer wieder derselben Instanz zurückgibt, beide die Einheitsansichten und ändern ihre eigene Kopie, wodurch Parallelitätsprobleme zumindest innerhalb von Orchestrator vermieden werden.

Benachrichtigen anderer Benutzer über Änderungen

Es können Probleme auftreten, wenn Sie einen Cache verwenden und gleichzeitig Objekte klonen. Das größte Problem ist, dass das Objekt, das Einheitsansichten verwendet, möglicherweise nicht die neueste Version ist, die für das Objekt verfügbar ist. Beispiel: Wenn eine Einheit die Bestandsliste anzeigt, werden die Objekte einmal geladen. Gleichzeitig zeigt aber die erste Einheit die Änderungen nicht an, wenn eine andere Einheit einige der Objekte ändert. Verwenden Sie zum Vermeiden dieses Problems die Methoden PluginWatcher und IPluginPublisher aus der Orchestrator-Plug-in-API, um andere Benutzer über die Änderungen zu benachrichtigen, damit andere Instanzen der Orchestrator-Clients die Änderungen sehen können. Dies gilt auch für eine eindeutige Instanz des Orchestrator-Clients, wenn Änderungen aus einem Objekt aus der Bestandsliste andere Objekte in der Bestandsliste beeinflussen und diese auch benachrichtigt werden müssen. Die Vorgänge, die häufig Benachrichtigungen verwenden, sind Hinzufügen, Aktualisieren und Löschen von Objekten, wenn diese Objekte, oder einige der Eigenschaften, in der Bestandsliste angezeigt werden.

Aktivieren der Suche nach Objekten jederzeit und überall

Sie müssen die find-Methode der IPluginFactory-Schnittstelle implementieren, um Objekte nur über Typ und ID zu finden. Die find-Methode kann direkt nach dem Neustart von Orchestrator und dem Fortsetzen eines Workflows aufgerufen werden.

Simulieren eines Abfragedienstes, wenn Sie keinen haben

Für den Orchestrator-Client ist es möglicherweise erforderlich, in bestimmten Fällen einige Objekte abzurufen oder sie nicht als Baumstruktur sondern beispielsweise als Liste oder Tabelle anzuzeigen. Dies bedeutet, dass Ihr Plug-In in der Lage sein muss, zu jeder Zeit Objektsätze abzufragen. Wenn die Drittanbietersoftware einen Abfragedienst anbietet, müssen Sie diesen Dienst anpassen und verwenden. Andernfalls sollte es Ihnen möglich sein, einen Abfragedienst zu simulieren, unabhängig von der höheren Komplexität oder niedrigeren Leistung der Lösung.

Suchmethoden dürfen keine Laufzeitausnahmen zurückgeben

Die Methoden der IPluginFactory-Schnittstelle, die Suchvorgänge innerhalb des Plug-Ins implementieren, dürfen keine gesteuerten oder nicht gesteuerten Laufzeitausnahmen zurückgeben. Dies kann zu unerwarteten Fehlschlägen des Typs Validierungsfehler führen, wenn ein Workflow ausgeführt wird. Beispiel: Zwischen zwei Knoten eines Workflows wird die Methode find aufgerufen, wenn eine Ausgabe aus dem ersten Knoten eine Eingabe im zweiten Knoten ist. Zu diesem Zeitpunkt erhalten Sie, falls das Objekt aufgrund einer Laufzeitausnahme nicht gefunden wird, keine weiteren Informationen als einen Validierungsfehler im Orchestrator-Client. Danach hängt es davon ab, wie das Plug-In die Ausnahmen protokolliert, ob mehr oder weniger Informationen in den Protokolldateien enthalten sind.