BPM:GUI Plugins
(Weitergeleitet von GUI Plugins)
Zur Navigation springen
Zur Suche springen
GUI Plugins
GUI Plugins sind Plugins welche speziell für die HTKServer.GUI.exe geschrieben wurden.
Beschreibung
Nachdem der Service (Core) ein neues Plugin erhalten hat, muss die möglichkeit bereitgestellt werden, dieses in Prozesse zu integrieren und konfigurieren.
An dieser Stelle kommen GUI Plugins in das Spiel. GUI Plugins werden benötigt um verschiedene Aufgabenstellungen zu meistern. Dazu zählen beispielsweise:
- Installation der Pluginvorrausetzungen (Tabellen etc.).
- Erstellen von Ribbonbuttons innerhalb der HTKServer.GUI zur Prozess-unabhängigen Konfiguration.
- Aufräumen falscher / kaputter einträge innerhalb der Prozess / Job Tabellenstrukturen.
- Löschen von Abgebrochenen (nicht gespeicherten) Jobdefinitionen.
- Konfiguration des jeweiligen Jobs.
Systemvorrausetzungen
- Visual Studio 2013.
- .NET Framework 4.0.
- Business Process Management Kompatibler SQL-Server
- Devexpress 14.2 und höher bei Verwendung von Ribbon Buttons.
- Installierte Business Process Management GUI
Downloads
- Beispielprojekt (nicht benötigt wenn man Schritt für Schritt Anleitung befolgt).
Schritt für Schritt: Erstellung eines Plugins
- Nach öffnen des Visual Studio's, wählen Sie bitte Neues Projekt und erstellen eine .NET Framework 4.0 Klassenbibliothek.
Getreu dem Motto Conversion over Configuration muss der Name HTKServer.GUI.Plugins. gefolgt von ihrem Projektnamen lauten. - Nun benötigen wir noch verschiedene Projektverweise. Die Basisvariante eines Plugins muss folgende Verweise enthalten.
System.ComponentModel.Composition, System.ComponentModel.DataAnnotations und System.Windows.Forms können aus dem .NET Framework Standardkatalog verwiesen werden. HTKLicense, HTKServer.GUI.Plugins.IPlugin und HTKServer.GUI.Shared können aus dem Installationsordner der BusinessProcessManagement GUI im Ordner Plugins verwiesen werden.
- Nun sollte die Datei
in
umbenannt werden. Sollte es zu einer Meldung kommen ob alle Projektverweise umbenannt werden sollen, so antworten Sie bitte mit JA., - Jetzt lassen wir die Klasse Plugin von der abstrakten Basisklasse PluginBase erben, sowie von den Interfaces IPlugin.IPlugin, IPartImportsSatisfiedNotification und IDisposable im Anschluss implementieren wir die Interfaces durch anklicken der zugehörigen Microsoft Visual Studio Funktion.
IPlugin.IPlugin
IPartImportsSatisfiedNotification
IDisposable
- Der Interface Member von IDisposable ist public void Dispose sollten Sie die Dispose funktion nicht benötigen, so lassen Sie diese bitte leer. Ansonsten füllen Sie den Dispose block mit den nötigen freizugebenden unmanaged Ressourcen etc. Weitere Infos zu IDisposable finden Sie unter: MSDN IDisposable Interface und Proper use of the IDisposable Interface
- Der Interface Member von IPartImportsSatisfiedNotification public void OnImportsSatisfied. Im Regelfall können Sie diese Methode leer lassen. Weitere Informationen über den Zwekc von OnImportsSatisfied finden Sie unter IPartImportsSatisfiedNotification . OnImportsSatisfied-Methode sowie unter MEF Teil 3 – Lifecycle beeinflussen und überwachen.
- OPTIONAL: Es empfiehlt sich als "Best Practice" die Interface Member von IPartImportsSatisfiedNotificationund IDisposable per Region einzuklappen wenn diese ungenutzt sind.
- Nun müssen wir noch den MEF-Export der DLL definieren. Hierzu muss das Export Attribut mit dem Entsprechenden Typ des Interfaces, sowie das ExportMetaData Attribut mit dem entsprechendenm Pluginnamen hinzugefügt werden. Bitte achten Sie darauf dass Sie dies nicht vergessen, denn ohne diese beiden Attribute kann das Plugin nicht erkannt werden.
- Das Interface IPlugin implementiert 2 Member. public bool StartupEntr y(ProcessInformation processInformation) und public bool JobEntry (ProcessInformation processInformation). Was auffällt ist das beide Funktionen den processInformation parameter übergeben bekommen. Der processInformation parameter wird innerhalb der HauptGUI gebildet und beinhaltet folgende schreibgeschützte Properties.
Die Properties sollten selbstsprechend sein, das LocalisationSystem kann durch die Übergabe im Plugin genutzt werden. Die Property ProcessType beinhaltet die Informationen um was für einen Prozess es sich handelt, also bspw. VKBeleg After Save etc. - Der Interface Member StartupEntry wird bei allen Plugins nach dem Druck auf Login / Anmelden ausgeführt. Dies kann also dazu genutzt werden, um bspw. einmalig etwas beim ersten Aufruf auszuführen, egal ob der Prozess definiert wurde oder nicht. Bspw. "Achtung, die Grundlagen für das Plugin XYZ werden nun automatisch eingerichtet, bitte haben Sie einen moment Geduld". Wichtig ist hierbei nur, dass diese Methoden immer ausgeführt werden, d.H. Sie müssen bei Verwendung des StartupEntry Einstiegspunktes aufjedenfall dafür sorgen, dass Sie per Markierung in der DB oder in einer Datei ein erneutes Aufrufen verhindern, sonst würde man in dem genannten Beispiel bei jedem Start der GUI wieder nach der Grundlageninstallation gefragt werden. Achtung Dies betrifft nur dinge welche beim aufruf der Gui gestartet werden müssen und nicht mit der Standardinstallationsroutine für Pluginvorrausetzungen abbilden werden können. Die funktion sollte true zurückgeben wenn Sie nicht genutzt wird, oder wenn es keine Probleme gab, ansonsten natürlich False.
- Der Interface Member JobEntry wird aufgerufen sobald man innerhalb der Business Process Management GUI auf Erweiterte Konfiguration eines Jobs drückt. Hier öffnet man in der Regel eine Maske welche zur erweiterten Konfiguration genutzt werden kann. Es können zusätzlich auch Prüfungen stattfinden, beispielsweise ob ein Mandant gewählt wurde oder nicht. Wenn diese Funktion False zurückgibt, wird der Job nicht gespeichert und das hinterlegte Delete Script innerhalb der Assets-Struktur wird aufgerufen, auf das Thema Assets gehen wir später ein. Hier ein Beispiel:
Die Basisklasse (base.) beinhaltet verschiedene Basisfunktionen wie beispielsweise GetLogger.
Die aufgerufene Form sollte als Best Practise immer die folgenden Konstruktor-Parameter definiert haben:
Um einen FluentLogger zu verwenden (was Sie wirklich tun sollten!), setzen Sie bitte einen Verweis auf die HTKFunctionsLibrary welche Sie auch im Plugins Ordner ihrer Installierten Business Process Management GUI finden.
Achtung: sollten Sie wie in obigem Beispiel eine XtraMessageBox verwenden (was optisch besser in das Gesamtbild passt), so benötigen Sie die DevExpress Komponenten in der jeweisl vorrausgesetzten Version (siehe Systemvorrausetzungen). Die nötigen Verweise sind
- sowie
Desweiteren empfiehlt es sich wenn Sie Devexpress Komponenten verwenden, eine XtraForm statt einer Form zu erstellen und in deren Konstruktor folgenden Codeschnipsel zu übernehmen:
Für die Bonusskins ist ein weiterer Verweis auf
erforderlich.
Nach erfolreicher erweiterten Konfiguration geben Sie bitte true zurück. - Legen Sie nun folgende Ordnerstruktur in Ihrem Projekt an. Die Dateien können je nach bedarf hinzugefügt werden. DIe Ordnerstruktur sollten Sie allerdings standardmäßig so anlegen. Bitte achten Sie auf Korrekte Benennung der Ordnerstruktur.
Achtung: Alle Assetsmüssen bei Buildvorgang Eingebettete Ressource hinterlegt haben!
- Cleanup: Der Ordner Cleanup beinhaltet Scripte welche benötigt werden um die Tabellenstrukturen "sauber" zu halten. Auch wenn Sie alles korrekt gemacht haben, sollten Sie trotzdem ein solchen Script hinterlegen. Die Scripte werden automatisch ausgeführt. Es empfiehlt sich als Best Practise den Namen der zu "cleanenden" Tabelle als Scriptname zu hinterlegen.
Script-Beispiel: - Delete: Der Ordner Delete beinhaltet Scripte, welche ausgeführt werden wenn die Methode JobEntry false zurückgibt. Auch hier empfiehlt sich als Namensgebung der Tabellenname.
Script-Beispiel:
Im speziellen Fall des Delete-Scriptes stehen folgende Platzhalter zur Verfügung. @Mandant und @JobId, bitte achten Sie bei Verwendung der Variablen auf die korrekte Bennenung. - Graphics → Icons: In diesen Ordner können Grafikdateien hinterlegt werden, welche als Grundlage für die RibbonButtons dienen. Es empfiehlt sich *.ico Dateien zu verwenden. Beispiel:
- Info: Der Ordner Info beinhaltet die Product.xml welche folgenden Aufbau hat.
* ValidationKey: Der ValidationKey der HTK Lizensierung. *- DemoSerial: Hier kann eine Standard Demoseriennummer. *
- SettingsXml: Hier kann die zu verwendende SettingsXML. *
- Features: Semikolon getrennte Liste von Features. *
- Productname: Der Produktname welcher in der Addins übersicht angezeigt wird.
- Description: Die Beschreibung welche in der Addins übersicht angezeigt wird.
- Author: Der Autor des Plugins.
- Name: Der Name des Plugins.
*: Sollten Sie nicht die HTK Lizensierung sondern Ihre eigene Verwenden, so können Sie dies leer lassen
- Install: Der Ordner Install beinhaltet Installationsscripte welche aufgerufen werden sobald man sich in die Business Process Management GUI Anmeldet (nach Login Dialog). Hier sollten Sie darauf achten, dass Sie alle Datenbankstrukturen nur anlegen wenn diese nicht existieren! Auch hier empfiehlt sich als Namensgebung der Tabellenname.
Beispielscript:
- Options: In dem Ordner Options befindet sich die Options.xml welche folgenden Aufbau hat.
- HasProperties: Gibt an ob der Job bei Doppelklick oder Klick auf Einstellungen Serviceproperties hat. Steht diese Option auf false, so öffnet sich immer die erweiterte Konfiguration
- MandantNessesary: Steltt man diese Option auf true, so kann man den Job (von Haus aus) nicht ohne Mandant hinterlegen. Wenn dies nur in bestimmten Szenarien der Fall sein sollte, so lassen die dies auf false und prüfen SIe dies im JobEntry einstiegspunkt.
- JobMatches: Hier können Sie Semikolongetrennt alle Jobbezeichnungen hinterlegen bei denen das Plugin geöffnet werden kann.
- Ribbonbuttons → Configuration: In der Configuration.xml Datei wird definiert welche RibbonButtons das Plugin erzeugt, auf welcher RibbonPage und in welcher RibbonGroup. Zusätzlich wird definiert, was bei einem Druck auf den Button passiert und ob es eine Bedingung für das erscheinen des Buttons gibt.
- In Grün markiert sieht man dass die Datei aus Zwei Bereichen besteht. Einmal BarButtonItems und einmal BarButtonLinkContainerItems.
- In Blau markiert sieht man den jeweiligen Button hier können natürlich N Buttons definiert werden. Bitte achten Sie darauf dass der aufbau eines BarButtonLinkContainer's durch die zusätzliche Buttonlist abweicht
- In Braun markiert sieht man die ID des Buttons, diese muss gesetzt werden, da diese den Button eindeutig kennzeichnet. Bitte achten Sie darauf dass die ID so eindeutig ist dass Sie nicht mit anderen Lösungen sich übershcneidet und vergeben Sie diese nicht doppelt.
- In Orange markiert die Buttonlist eines BarButtonLinkContainer's. Hier werden die ID's der Buttons hinterlegt welche unterhalb des BarButtonLinkContainer's erscheinen. Achtung: Buttons werden automatisch Visible wenn Sie "Kinder" eines BarButtonLinkContainer's sind. Die Reihenfolge ist die Reihenfolge innerhalb der XML Datei.
- In Grau markiert die Sichtbarkeit eines Buttons. Wenn der Button teil eines BarButtonLinkContainers ist, stellen Sie diesen auf Never. Der BarButtonLinkContainer stellt diesen automatisch auf Always. Sie verhindern allerdings durch die Einstellung Never, dass dieser zusätzlich im Ribbon als eigenständiger Button angezeigt wird.
- In Lila markiert sehen Sie die zuweisung eines ItemClick Events an eine Funktion namens BarButtonItem2OnItemClick. Hierbei handelt es sich um Devexpress BarButtonItem Events welche definiert werden können.
- In Pink markiert sehen Sie eine hinterlegte BarButtonItem Condition, diese Condition gibt true bzw. false zurück. Bei False würde der Button nicht angelegt werden!
Wenn also Buttons nur unter bestimmten bedingungen angezeigt werden dürfen (bspw. File XY existiert oder nicht), dann müssen Sie dies über eine condition lösen.
Achtung: Die Texte Caption, Page und Group beziehen sich immer auf eine GUI Plugin-Lokalisierungsdatei, die Anlage dieser entnehmen Sie bitte dem Beitrag GUI Plugin-Lokalisierungsdateien.
- Ribbonbuttons → 'RibbonButtonMethods.cs': In der RibbonButtonMethods Klasse müssen Sie zu den jeweils definierten RibbonButtons die jeweiligen Events hinterlegen, sowie die Conditions zu den definierten Conditions. Bitte beachten Sie das es sich bei der RibbonButtonMethods um eine statische Klasse handelt.
Beispiel:
Conditions müssen immer als public static bool XYZ ohne Parameter definiert werden. Wird hier False zurückgegeben, so wird der Button nicht angelegt.
Die Eventsignatur muss entsprechend der von Devexpress definierten Eventsignatur sein, die Signatur für den Fall ItemClick können Sie obigem Beispiel entnehmen.
Tipp: Um aus einem ButtonClick heraus die zu verwendende SQL Verbindung zu bekommen, nutzen Sie die GetSQlConnectionInfo funktion aus dem Shared Namespace, diese liefert Ihnen einen Tuple<SqlConnection, String> Item1 stellt hierbei eine geschlossene SqlConnection und Item2 den Connectionstring dar. - Nun können Sie das Plugin erstellen. Wählen Sie als Zielplattform bitte x86 aus. Zur Installation legen Sie das Plugin sowie alle Vorrausetzungen und Verweise in den Ordner Plugins Ihrer installierten Business Process Management GUI. Wenn Sie alles richtig gemacht haben, sollte ein Klick auf Addins ihr Plugin anzeigen.
Disclaimer
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen. Some pages may contain Icons by www.icons8.com.