Daten getriebene Adapter (DDAs) in Unified Service Desk nutzen
Data-Driven Adapter (DDAs) sind die Adapter, die allgemein vom Hosted Application Toolkit (HAT) genutzt werden. Diese Adapter sind allgemeine Assemblys, die lediglich die Interaktion mit der Benutzeroberfläche behandeln und Geschäftsprozesse nicht enthalten. Das Unified Service Desk SDK wird mit einem DDA ausgeliefert, der einen allgemeinen Funktionssatz bereitstellt, der es Ihnen erlaubt, eine Vielzahl von Anwendungen zu hosten und darauf zuzugreifen. Möglicherweise benötigen Sie jedoch zusätzliche Funktionen, abhängig vom Typ der zu erstellenden Anwendung. Es gibt verschiedene Möglichkeiten, die vorhandenen Funktionen zu erweitern, wie das Erstellen eines neuen DDA (und dessen Verwendung in einer zusammengesetzen DDA mit äußen DDAs) und das Erweitern eines vorhandenen DDAs.
In diesem Abschnitt
Typen von datengesteuerten Adaptern (DDAs)
Erweitern eines vorhandenen DDAs
Verwenden von DDAs in benutzerdefinierten Anwendungsadaptern
Typen von datengesteuerten Adaptern (DDAs)
Vier Arten von DDAs stehen zur Verfügung:
Erstellen eines DDAs
Sie können einen neuen DDA erstellen, indem Sie einfach die DataDrivenAdapterBase-Klasse vererben.
Die Klasse hat den Konstruktor, der überladen werden kann.
Erweitern eines vorhandenen DDAs
Im vorherigen Abschnitt haben wir gesehen, wie ein DDA erstellt wird. Wenn die Anpassungen jedoch nominal ist, können Sie den vorhandenen DDA verwenden und ihn gemäß den Anforderungen erweitern.
Sie können folgende Klassen verwenden, um die vorhandenen UII DDAs zu erweitern:
WinDataDrivenAdapter: Erstellt einen Adapter basierend auf dem WinDDA.
WebDataDrivenAdapter: Erstellt einen Adapter basierend auf dem WebDDA.
JavaDataDrivenAdapter: Erstellt einen Adapter basierend auf dem JavaDDA.
UIADataDrivenAdapter: Erstellt einen Adapter basierend auf dem UIADDA.
Alle vorangehenden Klassen sind von der DataDrivenAdapterBase-Klasse abgeleitet.
Bindungen
Ein datengesteuerter Adapter verwendet Daten, Bindung en genannnt, um die Art zu definieren, in der es eine Benutzeroberflächenkomponente einer gehosteten Anwendung identifiziert. Beispielsweise können die Bindungen aus Document Object Model (DOM)-Pfaden zum Beschreiben von Elementen auf einer Webseite bestehen. Das folgende Beispiel zeigt eine Anwendungsinitialisierungszeichenfolge mit einer eingebetteten DDA-Bindungs-Teilstruktur. Dies ist ein allgemeines Beispiel, aber es gibt das Muster an, das verwendet wird, um Acc
-Steuerelemente in Windows-Bindungen zu implementieren.
Notiz
Einige der Konfigurationsparameter wurden aus Gründen der Übersichtlichkeit entfernt.
<initstring>
<interopAssembly>
<URL>path to executable</URL>
<Arguments>test argument</Arguments>
<WorkingDirectory>c:\</WorkingDirectory>
<hostInside/>
</interopAssembly>
<!—- notice there is no custom application adapter specified here-->
<displayGroup>None</displayGroup>
<optimumSize x="800" y="600"/>
<minimumSize x="640" y="480"/>
<DataDrivenAdapterBindings>
<Type>typeName, assemblyName</Type>
<Controls>
<AccControl name="combobox1">
<Path>
<FindWindow>
<ControlID>1003</ControlID>
</FindWindow>
</Path>
</AccControl>
</Controls>
</DataDrivenAdapterBindings>
</initstring>
Wenn Sie die die HAT Software Factory verwenden, erstellt sie InitString
. Die Anwendung kann dann von der Software Factory für den Server bereitgestellt werden.
Wenn Sie eine gehosteten Anwendung direkt mithilfe der Administrator-Benutzeroberfläche hinzufügen, müssen Sie nicht die vollständige InitString
erstellen. Sie müssen lediglich den Abschnitt <DataDrivenAdapterBindings
> angeben und ihn der Registerkarte Automation Xml
hinzufügen.
Verwenden von DDAs in benutzerdefinierten Anwendungsadaptern
Obwohl DDAs ursprünglich zur Unterstützung von Automatisierungen innerhalb des Hosted Application Toolkit (HAT) konzipiert wurden, können sie auch von angepassten Adaptern verwendet werden, um nützliche Ergebnisse zu erzielen. Das folgende Codebeispiel, aus einem benutzerdefinierten Adapter, zeigt, wie benutzerdefinierte Adapter DDAs verwenden können, und veranschaulicht die allgemeinen Vorteile von DDAs. Wie das Beispiel zeigt, ermöglicht die Verwendung von DDAs eine Trennung von Code und Konfigurationsinformationen.
DataDrivenAdapter Dda;
public override bool Initialize()
{
Dda=DataDrivenAdapter.CreateInstance(ApplicationInitString,ApplicationObject);
return (Dda != null);
}
public override bool DoAction(Action action, ref string data)
{
if (action.Name == "AddToHistory")
{
Dda.ExecuteControlAction("combobox1");
Dda.SetControlValue("textbox1", data);
Dda.ExecuteControlAction("button1");
}
}
Die DDA-Konfiguration, die in den InitString
der Anwendung eingebettet ist, ist XML, wie im folgenden Beispiel.
<DataDrivenAdapterBindings>
<Type> Microsoft.UII.HostedApplicationToolkit.DataDrivenAdapter.WinDataDrivenAdapter, Microsoft.UII.HostedApplicationToolkit.DataDrivenAdapter</Type>
<Controls>
<AccControl name="combobox1">
<Path>
<FindWindow>
<ControlID>1003</ControlID>
</FindWindow>
</Path>
</AccControl>
<AccControl name="textbox1">
<Path>
<FindWindow>
<ControlID>1001</ControlID>
</FindWindow>
</Path>
</AccControl>
<AccControl name="button1">
<Path>
<FindWindow>
<ControlID>1002</ControlID>
</FindWindow>
</Path>
</AccControl>
</Controls>
</DataDrivenAdapterBindings>
Das <Type/>
-Element leitet UII dazu, den Typ, der in Typ, Assemblyformat angegeben ist, dynamisch zu instantiieren, sodass benutzerdefinierte DDAs geladen und verwendet werden können. Das Element <Controls/>
enthält die Liste der konfigurierten Steuerelemente, angegeben in der von dem geladenen DDA erforderten Weise.