Suggerimenti per la progettazione dell'adapter

In questa sezione vengono forniti consigli e suggerimenti appresi dagli sviluppatori durante la fase di progettazione degli adapter.

Le proprietà del gestore devono essere stringhe se utilizzate come configurazioni predefinite

Sembra interessante usare le proprietà nel foglio delle proprietà del gestore generato da XSD come impostazione predefinita per le proprietà Location perché se il valore non è impostato in Location il runtime usa automaticamente il valore impostato nel gestore. Vi sono tuttavia alcuni problemi che rendono questa configurazione poco utile.

Il problema sorge dal non sapere se il valore presentato deve essere ignorato o meno. In genere, è consigliabile procedere se si ha qualche nozione sul valore NULL definito per i valori, quindi eseguire un test a fronte di tale valore. Il problema quando si utilizzano i fogli delle proprietà basate su XSD in BizTalk Server consiste nel fatto che il valore NULL è supportato solo per le stringhe. Anche se si desidera che l'adapter abbia impostazioni predefinite mediante l'utilizzo di questo test NULL e si desidera restringere l'adapter a tipi di stringhe, questo continua ad essere esposto a un'interfaccia utente di tipo particolare.

I fogli delle proprietà generati da XSD supportano solo l'impostazione di una proprietà su NULL facendo clic con il pulsante destro del mouse sulla proprietà, a quale punto viene visualizzato un menu di scelta rapida nullify? e la proprietà può essere impostata su NULL. Non vi è alcun feedback visivo che la proprietà sia NULL.

Considerazioni relative all'utilizzo delle procedure per l'implementazione guidata per la generazione degli schemi

I programmatori adorano creare codice a fronte di modelli oggetto fortemente tipizzati. La manipolazione XML a livello di codice può sembrare contorta e soggetta a errori. Tuttavia, grazie ad alcuni suggerimenti e a un uso intelligente del supporto offerto da .NET Framework è possibile semplificare enormemente la questione.

Non creare documenti XML con concatenazione di stringhe

Uno degli errori peggiori che si possono commettere con XML è quello di generarlo da una concatenazione di stringhe e di istruzioni Print in memoria. Ciò provoca un elevatissimo consumo in termini di memoria e di tempo della CPU. Anche per il più semplice frammento XML, è più facile utilizzare uno strumento come ad esempio XmlWriter o un modello DOM (Document Object Model). Se si utilizza XmlWriter, non usare la funzionalità di scrittura non elaborata in quanto il writer perde lo stato di documento.

In fase di esecuzione, XmlWriter è preferibile rispetto a XML DOM a causa dei problemi di elevato consumo di memoria associati al DOM. Tuttavia, in fase di progettazione e configurazione questo in genere non costituisce un problema. L'utilizzo di DOM facilita l'uso di query XPATH, che può rivelarsi un utile strumento aggiuntivo.

Considerare la definizione dello scheletro del documento XML come risorsa

Se si genera un documento XML di grandi dimensioni con uno strumento di progettazione e il documento generato segue sempre la stessa struttura di base, considerare di posizionare l'intero file XML di base come risorsa del progetto per consentire l'apportazione di modifiche quando necessario.

Caricare il codice in un modello DOM, quindi aggiungere quanto necessario al documento utilizzando XPATH per selezionare il nodo che si desidera aggiungere ad esso. In questo caso, si crea un file WSDL (Web Service Description Language). La procedura guidata memorizza il file WSDL di base in una risorsa e aggiunge le parti secondarie XSD (XML Schema Definition) generate. Utilizza selectNode con un xpath per individuare la parte principale corretta. Si tratta di codice dell'interfaccia utente, di conseguenza le prestazioni non costituiscono un problema e l'implementazione risultante è pulita, affidabile e gestibile.

Considerare il posizionamento delle fasi di elaborazione nella pipeline di BizTalk

In generale gli adapter creati da Microsoft spostano l'elaborazione di messaggi basata sul formato all'esterno dell'adapter e all'interno di una pipeline di BizTalk. Un buon esempio è costituito da un adapter a un'origine dati strutturata ma non XML.

In tal caso, l'adapter ottiene solo i dati e la pipeline di BizTalk viene utilizzata per analizzarlo e convertirlo in un XML equivalente. Il vantaggio è che il componente pipeline in sé diventa una parte riutilizzabile dell'architettura.

Configurabilità del comportamento dell'adapter

Una delle lezioni apprese dal programma beta di adapter MQSeries è stata che non tutti i clienti erano soddisfatti di un medesimo comportamento. Questo valeva soprattutto al momento della gestione degli errori e dell'ordinamento. La soluzione era quello di rendere tale comportamento configurabile. È possibile specificare se l'adapter deve supportare l'ordinamento, se gli errori vengono spostati nella coda degli elementi sospesi o se provocano l'interruzione e la disattivazione dell'adapter. Rendendo configurabili tali comportamenti è possibile semplificare enormemente il lavoro dei clienti quando desiderano scrivere orchestrazioni complesse o script esterni a BizTalk Server per ottenere lo stesso risultato.

Supporto della correlazione con le code di messaggi

Molte piattaforme di messaggistica supportano la nozione di un ID di correlazione nell'intestazione del messaggio per supportare uno scenario di richiesta-risposta a livello di applicazione. Esempi al riguardo sono MQSeries, MSMQ e SQL Service Broker. Potrebbe sembrare interessante eseguire il mapping del modello richiesta-risposta del sistema di messaggistica esterno a un adapter trasmissione-risposta in BizTalk Server. Tuttavia ciò non ha senso a causa di dove risiedono le transazioni. Nello specifico, una trasmissione a un sistema di messaggistica esterno richiede l'esecuzione di un commit transazionale prima che la coda veda i dati. Anche la ricezione deve essere una transazione separata.

La soluzione in BizTalk Server è di:

• Utilizzare set correlazioni nelle orchestrazioni

• Configurare due porte separate: una per l'invio e una per la ricezione

  In un caso semplice l'orchestrazione specifica l'ID di correlazione associato al messaggio dall'adapter. Questo viene passato all'adapter come proprietà di contesto del messaggio. In un caso più complesso, lo scenario chiama il sistema di messaggistica esterna per allocare l'ID. In questo caso può essere passato dalla porta di invio all'orchestrazione con un messaggio di risposta. Tale messaggio ha semplicemente lo scopo di restituire l'ID. Non si tratta di un vero e proprio messaggio di risposta.

Nota

Vi è una race condition nel motore di orchestrazione tale che la risposta vera e propria al messaggio potrebbe avere la priorità sulla risposta ID dalla trasmissione. Tale race condition deve essere gestita nell'ambito dell'orchestrazione stessa.