Condividi tramite

Come eseguire il test e il debug di un adapter

  • Articolo

Il debug di problemi di runtime richiede spesso un approccio multilaterale. Per determinare la causa dei problemi o degli errori del software, i dati devono essere raccolti da più origini, ad esempio l'analisi del software, i contatori delle prestazioni, le voci del registro eventi, gli eventi WMI (Windows Management Instrumentation) e il codice di origine di debug.

Poiché gli adapter di ricezione e di trasmissione vengono eseguiti nello spazio degli indirizzi del servizio BizTalk, per eseguire il debug di un adapter è necessario collegare il debugger al processo BtsNtSvc.exe. Per gli adapter di ricezione isolati è invece necessario collegare il debugger al processo che ospita l'adapter.

Il codice di runtime dell'adapter deve essere instrumentato con il codice di analisi per catturare le informazioni di diagnostica runtime per la risoluzione dei problemi. Questa operazione può essere eseguita utilizzando Microsoft Enterprise Instrumentation Framework (EIF). Generalmente è utile aggiungere istruzioni di analisi per diversi livelli di gravità, ad esempio l'analisi di condizioni di errore, l'analisi di errori e avvisi e l'analisi di errori, avvisi e istruzioni informative. Adapter più complessi possono inoltre comprendere sottosistemi distinti che devono essere analizzati indipendentemente gli uni dagli altri. Un adapter può comprendere ad esempio un sottosistema di reti e un sottosistema principale. In questo caso, se l'analisi viene impostata per tutti i sottosistemi, è possibile che in alcuni scenari venga generata una quantità eccessiva di dati.

Per catturare quantità e valori in fase di esecuzione e fornire così maggiori informazioni sul comportamento dell'adapter in fase di esecuzione, è necessario aggiungere contatori delle prestazioni. Un adapter può pubblicare ad esempio contatori delle prestazioni per il numero di righe dei messaggi inviati per singoli endpoint nonché la quantità di messaggi inviati al secondo.

Per alcuni scenari di errori critici possono inoltre essere utili gli eventi WMI. Ad esempio, se un adapter rileva un errore critico che determina la chiusura di un indirizzo di ricezione da parte dell'adapter, l'attivazione di un evento WMI consente a un amministratore di essere in ascolto su tale evento e intraprendere l'azione appropriata.

Test dell'adapter

Gli adapter personalizzati sviluppati per BizTalk Server devono essere di qualità software enterprise. Ciò significa che, prima del rilascio, l'adapter deve essere sottoposto a test meticolosi. Sebbene non vengano descritte procedure dettagliate per il test degli adapter, in questa sezione vengono fornite informazioni generali sulle operazioni da eseguire. In generale, i test del codice di runtime, ad esempio gli adattatori, devono coprire tre categorie generali: test funzionali, test di stress e test delle prestazioni.

Test delle funzioni

L'adapter deve essere verificato per tutte le permutazioni delle relative funzionalità, inclusi i test positivi e quelli negativi. I test positivi devono includere, ma non essere limitati a, gli scenari seguenti:

  • Ricevere messaggi

  • Trasmettere messaggi

  • Trasmettere un messaggio utilizzando una porta dinamica

  • Disattivare indirizzi di ricezione

  • Aggiornare la configurazione

  • Verificare che le finestre di servizio funzionino sia per gli adapter di ricezione che per quelli di trasmissione

  • Verificare l'integrità transazionale per gli adapter transazionali

    I test negativi devono includere, ma non essere limitati a, gli scenari seguenti:

  • Ricevere messaggi non validi

  • Ricevere un batch eterogeneo di messaggi, alcuni validi a altri non validi

  • Errore di trasmissione

  • Nuovo tentativo riuscito

  • Nuovo tentativo non riuscito, passaggio al trasporto successivo riuscito

  • Passaggio al trasporto successivo non riuscito, sospendere messaggio

  • Trasmettere un batch eterogeneo di messaggi

  • Errore del database

Test di stress

Gli adapter sono componenti di runtime e, in quanto tali, devono rispondere ai rigidi requisiti per il software di runtime. Il test di stress viene generalmente effettuato eseguendo scenari sotto carico per un determinato periodo di tempo. Devono inoltre essere eseguiti ulteriori test di tempo medio tra i guasti (MTBF) in situazioni di traffico elevato e traffico ridotto, nei quali l'adapter viene eseguito sotto carico per un determinato periodo di tempo.

Per l'esecuzione di questi test è consigliabile eseguire l'adapter a traffico elevato per circa 72 ore, durante le quali il numero di messaggi attraverso l'adapter determina un utilizzo della CPU di circa l'80-90 percento. Per i test di traffico ridotto, l'utilizzo della CPU sarà di circa il 30-40 percento per circa 120 ore.

Test delle prestazioni

Gli adapter devono essere sviluppati nell'ottica delle prestazioni. Prima che un adapter venga rilasciato, è necessario convalidarne le prestazioni. È importante verificare che le prestazioni siano scalabili verticalmente e orizzontalmente, ovvero sia l'aggiunta di altri computer che l'aggiunta di altra CPU determinano un miglioramento delle prestazioni. Definire il profilo del codice può aiutare ad eliminare colli di bottiglia delle prestazioni.