Come distribuire un adapter personalizzato

Articolo
05/04/2023

Un processo di installazione degli adapter completo è costituito dai passaggi seguenti:

Verifica delle dipendenze. Il programma di installazione dell'adapter MSMQ verifica ad esempio l'esistenza del servizio MSMQ locale in quanto il runtime dell'adapter dipende da tale servizio.
Impostazione del file system locale. Questa operazione prevede la creazione delle cartelle di installazione e la copia dei file binari e di supporto. Verificare che le autorizzazioni di accesso a file e cartelle siano configurate in modo corretto.
Installazione di assembly gestiti nella cache assembly globali del sistema
Creazione delle chiavi del Registro di sistema per l'adapter

Nota

Per un adapter a 32 bit, la Console di amministrazione BizTalk Server prevede l'utilizzo del ramo HKEY_CLASSES_ROOT nel Registro di sistema per ottenere la configurazione dell'adapter personalizzato. Se un adapter a 32 bit viene installato in un server a 64 bit, la Console di amministrazione BizTalk Server utilizza invece il ramo HKEY_CLASSES_ROOT\Wow6432Node\ per i dati di configurazione dell'adapter.
Aggiunta dell'adapter a BizTalk Server. Questa operazione implica l'aggiunta di nuove voci nel database di gestione BizTalk per l'adapter e per lo schema di proprietà utilizzato per riflettere le proprietà innalzate di livello dall'adapter. Questo passaggio viene talvolta eseguito manualmente tramite la Console di amministrazione BizTalk Server.

Eccezioni

In installazioni parziali di BizTalk Server potrebbe non essere necessaria la verifica delle dipendenze da parte del programma di installazione dell'adapter. Durante un'installazione specifica per gli strumenti di amministrazione ad esempio, non è necessario che il programma di installazione dell'adapter controlli le dipendenze del runtime dell'adapter in quanto quest'ultimo non viene utilizzato. Lo stesso concetto è valido per l'installazione specifica per il runtime di BizTalk Server, in cui non è necessario che il programma di installazione dell'adapter controlli le dipendenze della fase di progettazione dell'adapter.

In più ambienti BizTalk Server, l'ultimo passaggio dell'elenco precedente (aggiunta dell'adapter a BizTalk Server) viene eseguito solo durante l'installazione dell'adapter nel primo server BizTalk Server. Questo avviene perché tutte le istanze del servizio di BizTalk Server condividono lo stesso database di gestione BizTalk (con il nome predefinito BizTalkMgmtDB). Se gli adapter vengono aggiunti ad altri server BizTalk Server nello stesso gruppo, i passaggi aggiuntivi non riusciranno.

Installazione degli assembly dell'adapter nella cache assembly globali

Per supportare più ambienti host BizTalk Server con diversi percorsi di installazione dell'adapter, gli assembly dell'adapter devono essere installati nella cache assembly globali del sistema.

Durante l'installazione e la configurazione dell'adapter, una nuova voce dell'adapter viene creata nella tabella adm_adapter del database di gestione BizTalk (con il nome predefinito BizTalkMgmtDB). Questa voce contiene tutte le informazioni di riferimento utilizzate da BizTalk Server per le fasi di runtime e di progettazione.

I campi InBoundAssemblyPath e OutboundAssemblyPath vengono usati dal runtime di BizTalk Server per scoprire dove caricare i file binari della scheda. Poiché esiste un solo database di gestione BizTalk per un gruppo BizTalk Server, tutti i server BizTalk Server all'interno del gruppo devono condividere queste stesse informazioni. Se si desidera installare l'adapter in diversi server BizTalk Server all'interno del gruppo, è necessario utilizzare lo stesso percorso di installazione su ogni server. Se il percorso di installazione locale è diverso dal percorso memorizzato nel database di gestione BizTalk, BizTalk Server non sarà in grado di caricare i file binari dell'adapter.

Durante l'installazione dell'adapter, firmare sempre l'assembly dell'adapter con un nome sicuro e utilizzare Gacutil.exe per inserire l'assembly dell'adapter nella cache assembly globali del sistema. Assicurarsi di lasciare i campi InBoundAssemblyPath e OutboundAssemblyPath null o vuoti.

Utilizzo del framework per la configurazione dell'adapter

BizTalk Server fornisce un meccanismo per la generazione di fogli di proprietà per l'interfaccia utente della configurazione della scheda. Questo meccanismo è basato su una definizione XSD (XML Schema Definition) delle proprietà di configurazione. L'utilizzo di questo framework introduce una serie di problematiche significative che gli sviluppatori degli adapter devono affrontare. In questa sezione viene suggerita una soluzione efficace per alcuni di questi problemi.

Utilizzo degli editor delle proprietà personalizzati per tutte le proprietà principali

Non è possibile basare la convalida di proprietà significative sulle proprietà presenti nel foglio delle proprietà. Per definire le regole di convalida per l'interfaccia utente, il framework tenta di utilizzare le restrizioni simpleType in linguaggio XSD. Vengono applicate le semplici regole per i valori minimo e massimo, ma la restrizione relativa alle espressioni regolari per i campi stringa non è supportata. I dati vengono inoltre convertiti in tipi CLR (Common Language Runtime) prima dell'applicazione della restrizione. Ne consegue che nell'interfaccia utente si verifica talvolta un errore di conversione dei tipi di difficile interpretazione anziché un errore di superamento intervallo. Nel complesso, la logica di convalida è molto debole.

La soluzione che molti sviluppatori di adapter hanno adottato prevede la scrittura di editor di proprietà personalizzati per le proprietà principali del foglio delle proprietà. Se sono presenti proprietà interdipendenti (come accade di frequente), l'editor delle proprietà personalizzato sarà in grado di combinare i risultati in un singolo campo e il runtime potrà separarli in un secondo momento. Questo è l'unico metodo che consente di ottenere nell'interfaccia il codice personalizzato necessario (generalmente semplice).

Gli editor delle proprietà personalizzati sono relativamente semplici da scrivere e la proprietà in linguaggio XSD può essere annotata per l'utilizzo di tali editor. L'annotazione fa riferimento a un assembly che espone il punto di ingresso dell'editor delle proprietà e viene codificato per mostrare un form CLR. A questo punto, è possibile scrivere un'interfaccia utente regolare e utilizzare gli strumenti di generazione delle interfacce tradizionali offerti da Visual Studio.

Nel codice seguente viene illustrata la modalità di utilizzo del linguaggio XSD per aggiungere un editor delle proprietà personalizzato:

<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>

Il codice a cui viene fatto riferimento dovrebbe essere analogo al seguente:

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!  
}

È necessario che il runtime di amministrazione sia in grado di trovare l'assembly cui viene fatto riferimento nel linguaggio XSD in modo che possa essere aggiunto alla cache assembly globali.

Condividi tramite