Freigeben über


Bereitstellen eines benutzerdefinierten Adapters

Ein vollständiger Adapterinstallationsprozess besteht aus den folgenden Schritten:

  1. Überprüfen Sie Abhängigkeiten. Beispielsweise überprüft das MSMQ-Adapterinstallationsprogramm das Vorhandensein des lokalen MSMQ-Diensts, da die Adapterlaufzeit davon abhängt.

  2. Richten Sie das lokale Dateisystem ein. Dazu gehören das Erstellen von Installationsordnern und das Kopieren von Binär- und Supportdateien. Stellen Sie sicher, dass der Zugriff auf Ordner und Dateizugriffsberechtigungen ordnungsgemäß konfiguriert ist.

  3. Installieren Sie verwaltete Assemblys im globalen Assemblycache des Systems.

  4. Erstellen Sie Registrierungsschlüssel für den Adapter.

    Hinweis

    Bei einem 32-Bit-Adapter verwendet die BizTalk Server-Verwaltungskonsole die HKEY_CLASSES_ROOT Branch in der Registrierung, um eine benutzerdefinierte Adapterkonfiguration abzurufen. Wenn ein 32-Bit-Adapter auf einem 64-Bit-Server installiert ist, verwendet die BizTalk Serve-Verwaltungskonsole stattdessen den HKEY_CLASSES_ROOT\Wow6432Node\ Branch für Adapterkonfigurationsdaten.

  5. Fügen Sie den Adapter zu BizTalk Server hinzu. Dies bedeutet, dass neue Einträge in der BizTalk Management-Datenbank sowohl für den Adapter als auch für das Eigenschaftenschema erstellt werden, das verwendet wird, um Eigenschaften darzustellen, die der Adapter fördert. Dieser Schritt wird manchmal manuell mithilfe der BizTalk Server-Verwaltungskonsole ausgeführt.

Ausnahmen

Möglicherweise muss das Adapterinstallationsprogramm die Abhängigkeiten in teilweisen BizTalk Server-Installationen nicht überprüfen. In einer Installation nur mit Verwaltungstools muss der Adapterinstaller beispielsweise keine Laufzeitabhängigkeiten des Adapters überprüfen, da die Adapterlaufzeit nicht verwendet wird. Das gleiche gilt für die Nur-Laufzeit-Installation von BizTalk Server, bei der das Adapterinstallationsprogramm die Entwurfszeitabhängigkeiten des Adapters nicht überprüfen muss.

In mehreren BizTalk Server-Umgebungen erfolgt der letzte Schritt in der vorherigen Liste (Hinzufügen des Adapters zu BizTalk Server) nur in der Adapterinstallation auf dem ersten BizTalk Server. Dies liegt daran, dass alle BizTalk Server-Dienstinstanzen dieselbe BizTalk-Verwaltungsdatenbank verwenden (mit dem Standardnamen BizTalkMgmtDB). Wenn Adapter zu anderen BizTalk-Servern in derselben Gruppe hinzugefügt werden, schlagen die zusätzlichen Schritte fehl.

Installieren Sie die Adapterassemblys in den globalen Assemblycache.

Um mehrere BizTalk Server-Hostumgebungen mit unterschiedlichen Adapterinstallationspfaden zu unterstützen, müssen die Adapterassemblys im globalen Assemblycache des Systems installiert werden.

Während der Adapterinstallation und -konfiguration wird ein neuer Adaptereintrag in der adm_adapter Tabelle der BizTalk Management-Datenbank (mit dem Standardnamen BizTalkMgmtDB) erstellt. Dieser Eintrag enthält alle Referenzinformationen, die von BizTalk Server sowohl zur Laufzeit als auch zur Entwurfszeit verwendet werden.

Die Felder "InBoundAssemblyPath " und " OutboundAssemblyPath " werden von der BizTalk Server-Laufzeit verwendet, um herauszufinden, wo die Adapterbinärdateien geladen werden sollen. Da nur eine BizTalk-Verwaltungsdatenbank für eine BizTalk Server-Gruppe vorhanden ist, müssen alle BizTalk-Server in der Gruppe dieselben Informationen gemeinsam nutzen. Wenn Sie den Adapter auf verschiedenen BizTalk-Servern innerhalb der Gruppe installieren möchten, müssen Sie auf jedem dieser Server denselben Installationspfad verwenden. Wenn sich der lokale Installationspfad vom Pfad unterscheidet, der in der BizTalk-Verwaltungsdatenbank gespeichert ist, kann BizTalk Server die Adapter-Binärdateien nicht laden.

Signieren Sie immer die Assembly des Adapters mit einem starken Namen, und verwenden Sie Gacutil.exe, um die Adapterassembly während der Adapterinstallation in den globalen Assemblycache des Systems einzufügen. Stellen Sie sicher, dass Sie die Felder "InBoundAssemblyPath " und " OutboundAssemblyPath " null oder leer lassen.

Verwenden des Frameworks für die Adapterkonfiguration

BizTalk Server stellt einen Mechanismus zum Generieren von Eigenschaftenblättern für die Adapterkonfigurations-Benutzeroberfläche bereit. Sie basiert auf einer XML-Schemadefinitionsdefinition (XSD) der Konfigurationseigenschaften. Die Verwendung dieses Frameworks stellt erhebliche Herausforderungen für den Adapterentwickler dar. In diesem Abschnitt wird eine effektive Problemumgehung für einige dieser Probleme vorgeschlagen.

Ziehen Sie benutzerdefinierte Eigenschaften-Editoren für alle Ihre Wichtigsten Eigenschaften in Betracht

Es ist unmöglich, eine signifikante Eigenschaftenvalidierung auf Eigenschaften im Eigenschaftenblatt vorzunehmen. Das Framework versucht, simpleType-Einschränkungen (XML Schema Definition, XSD) zu verwenden, um die Gültigkeitsprüfungsregeln für die Benutzeroberfläche zu definieren. Die einfachen Regeln für den maximalen und minimalen Wert werden angewendet, die Einschränkung des regulären Ausdrucks für Zeichenfolgenfelder wird jedoch nicht unterstützt. Außerdem werden die Daten vor der Anwendung der Einschränkung in ClR-Typen (Common Language Runtime) konvertiert. Dies bedeutet, dass der Benutzer der Benutzeroberfläche manchmal einen kryptischen Typkonvertierungsfehler anstelle eines Out-of-Range-Fehlers erhält. Insgesamt ist die Validierungslogik sehr schwach.

Die Lösung, die viele Adapterentwickler übernommen haben, besteht darin, benutzerdefinierte Eigenschaften-Editoren für die Haupteigenschaften auf ihrem Eigenschaftenblatt zu schreiben. Wenn es eine Reihe von wechselseitig abhängigen Eigenschaften gibt (wie oft der Fall ist), kann der benutzerdefinierte Eigenschaften-Editor die Ergebnisse in einem einzigen Feld kombinieren, und die Laufzeitumgebung kann sie später trennen. Dies ist die einzige Möglichkeit, den erforderlichen (aber immer noch trivialen) benutzerdefinierten Code in die Schnittstelle zu übertragen.

Benutzerdefinierte Eigenschaften-Editoren sind relativ einfach zu schreiben und die Eigenschaft in der XSD kann annotiert werden, um sie zu verwenden. Die Anmerkung verweist auf eine Assembly, die den Einstiegspunkt des Eigenschaften-Editors zur Verfügung stellt, und sie ist so codiert, dass ein CLR-Formular angezeigt wird. Sie können jetzt eine normale Benutzeroberfläche schreiben und die herkömmlichen Tools für die Benutzeroberflächengenerierung verwenden, die Visual Studio bietet.

Der folgende Code zeigt, wie Sie mit dem XSD einen benutzerdefinierten Eigenschaften-Editor hinzufügen:

<xs:element name="queueDetails" type="xs:string" minOccurs="0">  
    <xs:annotation>  
        <xs:appinfo>  
           <baf:designer>  
               <baf:displayname _locID="queueName">Queue Definition</baf:displayname>  
               <baf:description _locID="receiveQueueDesc">Details of MQSeries Server, Queue Manager and Queue from where you want to receive messages.</baf:description>  
               <baf:category _locID="mqsCategory">MQSeries</baf:category>  
               <baf:editor assembly="Microsoft.BizTalk Server.Adapter.MQSAdmin.dll">Microsoft.BizTalk Server.Adapter.MQSAdmin.MQSUITypeEditor</baf:editor>  
            </baf:designer>  
        </xs:appinfo>  
    </xs:annotation>  
</xs:element>  
  

Der code, auf den verwiesen wird, sollte wie folgt aussehen:

public class MQSUITypeEditor : System.Drawing.Design.UITypeEditor  
{  
public override System.Drawing.Design.UITypeEditorEditStyle GetEditStyle  
(System.ComponentModel.ITypeDescriptorContext context)   
{  
return System.Drawing.Design.UITypeEditorEditStyle.Modal;  
}  
public override object EditValue (System.ComponentModel.ITypeDescriptorContext context,  
System.IServiceProvider provider, object value)   
{  
Form qdForm = new QueueDefinitionForm(value);  
IWindowsFormsEditorService service =   
(IWindowsFormsEditorService)provider.GetService(typeof(IWindowsFormsEditorService));  
DialogResult dialogResult = service.ShowDialog(qdForm);  
//…  
}  
}  
class QueueDefinitionForm : System.Windows.Forms.Form   
{  
//  traditional UI code goes here!  
}  
  

Die Administrationslaufzeit muss in der Lage sein, die Assembly zu finden, auf die in der XSD verwiesen wird, sodass Sie sie dem globalen Assemblycache hinzufügen sollten.