<< Click to Display Table of Contents >> RayQC > 2026.3 > User Guide > Plug-ins > External Plug-ins > Structure of a Plug-in  Das Manifest

Aus der Perspektive eines Checklisten-Erstellers wird ein Plug-in durch seinen Namen, die verfügbaren Funktionen und deren Parameter bestimmt. Insbesondere bei internen Plug-ins ist dies alles, worauf ein Checklisten-Autor zugreifen kann. (Nun, eigentlich stehen ihm zusätzliche Informationen aus diesem Dokument zur Verfügung, aber wer stellt eine angemessene Benutzeranleitung für die Menge an benutzerdefinierten Plug-ins bereit, die in einer Unternehmens-QA-Abteilung eingerichtet wurden?)

 

Die Manifestdatei eines Plug-ins muss diesen Satz von Plug-in-Eigenschaften in einem für Menschen sowie Systeme lesbaren Format definieren. Deshalb hat Raynet beschlossen, XML als Markup-Sprache für Manifestdateien zu verwenden, da es stark strukturiert ist und eine intuitive Zugänglichkeit für Checklisten-Autoren gewährleistet.

 

Es gibt verschiedene Blickwinkel, aus denen Manifestdateien erkundet werden können: von der reinen XML-Struktur mit ihren Tags und Attributen, oder von den logischen und funktionalen Anforderungen hinsichtlich der für die Schnittstellendefinition benötigten Informationen. Der folgende Abschnitt beschreibt den Informationsumfang, während der Anhang-Abschnitt den Zugang von der anderen Seite ermöglicht.

 

Anforderungen an die Plug-in-Schnittstellendefinition

Jede Manifestdatei repräsentiert eine bestimmte Gruppe von Funktionen und Argumenten, die irgendwie miteinander verwandt sind. Aus diesem Blickwinkel ist ein Plug-in nichts anderes als ein Container für standardisierte Programmlogik.

 

Jedes Plug-in benötigt einen bestimmten Satz von Informationen, um klar identifizierbar zu sein. Diese Informationen umfassen Name, Version, Dateiname und die PowerShell-Version, die das zugehörige PowerShell-Skript unterstützt. Dieser erste Informationssatz muss im Manifest deutlich sichtbar sein.

 

 

Bei dieser Beispiel-Manifestdatei ist der Plug-in-Name PowerShellSample, die Version ist 1.2.3.4. Darüber hinaus verknüpft diese Manifestdatei auf das Skript PowerShellSample.ps1, das von PowerShell-Version 3.0 und höher unterstützt wird.

 

Gut, die Grundlage ist gelegt – RayQC kann das Plug-in erkennen. Aber wie teilt man mit, wozu das Plug-in fähig ist? Nun, was von skriptbasierter Logik typischerweise erwartet wird, ist eine klassische Sequenz aus dem Verwenden einiger Informationen, deren Verarbeitung auf irgendeine Weise und der Rückmeldung über das Ergebnis der Verarbeitung. Jede dieser Sequenzen ist also eine gekapselte und klar definierte Funktionsgruppe. Wir interpretieren Plug-ins als Container für Funktionalität, sodass ein Plug-in mit nur einer Funktion existieren kann, aber ehrlich gesagt ein schlechter Container ist. Seien wir großzügig und nehmen an, dass es mindestens eine Funktion geben muss, aber Autoren können so viele hinzufügen, wie sie möchten.

 

Wenn man diese Eigenschaften von Plug-in-Funktionen und ihren Parametern kombiniert, ist die Übersetzung in XML recht offensichtlich: Jede Funktionsbeschreibung wird von einem übergeordneten Tag umschlossen, wobei diese Teile des Plug-ins selbst sein müssen.

 

 

Im obigen Beispiel-XML fehlen scheinbar einige wichtige Fakten. Die Funktionen und ihre Parameter sind nicht benannt. Wie könnte also RayQC wissen, welchen Teilbaum es betreten soll, wenn ein Checklisten-Autor eine Plug-in-Funktion aus der Checklisten-Editor-Oberfläche auswählt? Und bis jetzt gibt es keinen Verweis auf den eigentlichen Quellcode mit der Funktionslogik (dem Teil, der die Eingabe tatsächlich verwendet, um auf irgendeine Weise eine Ausgabe zu erzeugen).

 

Nun, jede Funktion und ihr Parameter benötigen einen Bezeichner (einen eindeutigen pro Funktion, der leicht zu finden ist, wenn ein Benutzer das Manifest liest – es scheint eine gute Idee zu sein, ihn als Attribut für das Funktions-Tag festzulegen).

 

 

Das sieht schon viel besser aus, insbesondere das name- und das description-Attribut, das wir für jede Funktion und ihre Parameter hinzugefügt haben, ist sehr praktisch. Zusätzlich haben wir auch den Parametertyp definiert, der wiederum den Typ des Eingabewertes festlegt, der vom Skript erwartet wird.

 

Zusätzliche XML-Definitionen

Nun... wir sind fast fertig. Es verbleibt noch die kleine Aufgabe, die Funktionslogik zu definieren, was bisher noch nicht erfolgt ist.

 

 

Weitere Informationen zur Verwendung dieser Attribute werden später bereitgestellt.

Speichern wir nun die bisher geleistete Arbeit als Manifest.xml und fahren dann mit dem nächsten Abschnitt fort: Das Plug-in-Logikskript.