Procedure consigliate per la distribuzione di un'applicazione

In questo argomento vengono elencate le procedure consigliate da seguire per la distribuzione di applicazioni BizTalk.

Distribuzione di un'applicazione BizTalk

Documentare le procedure di distribuzione delle applicazioni

• Assicurarsi che tutte le procedure usate nella distribuzione dell'applicazione siano documentate in modo approfondito, in modo da avere un record di come è stata eseguita la distribuzione e come distribuire ulteriormente o annullare la distribuzione. Qualsiasi elemento non sottoposto a script deve essere documentato con i passaggi dettagliati. Ciò deve includere la documentazione delle modifiche apportate ai sistemi esterni e alla distribuzione di componenti di terze parti.

  Distribuzione di applicazioni script

• Creare uno script per il maggior numero possibile di passaggi di distribuzione dell'applicazione. Lo scripting riduce il rischio di errore umano durante il processo di distribuzione.

Creazione di un'applicazione BizTalk

Creare script per la creazione di file di applicazioni BizTalk e .msi

• BtsTask.exe può essere usato per creare script per la creazione di applicazioni BizTalk. Se la creazione delle applicazioni viene creata tramite script, i pacchetti possono essere compilati automaticamente usando un processo automatizzato in un server di compilazione. Per altre informazioni sulla creazione di script per la creazione di applicazioni, vedere Distribuzione e gestione di applicazioni BizTalk.

Distribuzione di un assembly BizTalk

Evitare di distribuire assembly di Visual Studio in un computer di produzione

• Durante il processo di sviluppo, uno sviluppatore deve spesso ridistribuire gli assembly da Visual Studio. Per poter effettuare la ridistribuzione, è possibile che Visual Studio esegua l'annullamento della distribuzione, l'annullamento del binding, l'interruzione e la rimozione di elementi contenuti negli assembly. Benché necessario e appropriato in un ambiente di sviluppo, ciò può provocare conseguenze impreviste e indesiderate in un ambiente di produzione. Per questo motivo, nonché per impedire a chiunque di distribuire un assembly da Visual Studio in un computer di produzione, è consigliabile non installare Mai Visual Studio in un computer di produzione.

• Inoltre, nei computer in cui è in esecuzione Visual Studio è opportuno evitare di creare riferimenti a un database di produzione.

Aggiunta di elementi a un'applicazione BizTalk

Raggruppare gli elementi correlati in un'unica applicazione

• È consigliabile inserire il più possibile gli elementi correlati nella stessa applicazione BizTalk. Ciò consente di gestire e distribuire gli elementi come un'unica entità, semplificandone in questo modo la gestione. È ad esempio opportuno raggruppare in un'unica applicazione gli elementi che supportano gli stessi processi aziendali o gli elementi che eseguono funzioni analoghe.

  Distribuire gli elementi condivisi in un'applicazione a parte

• Se si prevede che determinati elementi vengano condivisi fra due o più applicazioni, è utile distribuirli in un'applicazione a parte. Ad esempio, se due applicazioni condividono uno schema, è opportuno posizionarlo in un'applicazione a parte. È consigliabile perché un solo artefatto in un gruppo BizTalk può avere un singolo identificatore univoco locale (LUID). Un LUID è costituito dal nome dell'artefatto e, facoltativamente, da altri attributi. Se si include un artefatto in un'applicazione e quindi si crea un riferimento da un'altra applicazione, l'applicazione di riferimento potrebbe non funzionare correttamente quando si arresta l'applicazione contenente l'artefatto.

  Questo suggerimento è valido per tutti i tipi di elemento, eccetto per i file (ad esempio i file Leggimi e gli script) che vengono aggiunti all'applicazione come elemento di tipo file. Ciò è dovuto al fatto che più di un artefatto di file con lo stesso nome può essere distribuito in un gruppo BizTalk. Di conseguenza, è possibile utilizzare un file avente lo stesso nome in due o più applicazioni. In questo caso, l'arresto di un'applicazione non influirà sull'altra applicazione. Per altre informazioni sull'aggiunta di artefatti di file, vedere Come aggiungere un file a un'applicazione.

  Distribuzione di un sito Web condiviso in un'applicazione a parte

• Se si prevede che un sito Web venga condiviso da più di una soluzione di business è consigliabile distribuire il sito Web in un'applicazione a parte. Ciò è dovuto al fatto che quando si disinstalla un'applicazione BizTalk, la directory virtuale di ogni sito Web appartenente all'applicazione viene rimossa, anche se il sito Web è in esecuzione. Di conseguenza, se il sito Web è condiviso da un'altra soluzione di business, questa inizierà a funzionare in modo errato.

  Distribuzione di criteri condivisi in un'applicazione a parte

• Se un criterio è utilizzato da due o più applicazioni è consigliabile distribuirlo in un'applicazione a parte anziché creare un riferimento da un'applicazione all'altra. Ciò è dovuto al fatto che quando si arresta un'applicazione, la distribuzione dei relativi criteri viene annullata. Se si arresta un'applicazione contenente un criterio utilizzato da un'altra applicazione, il criterio non funzionerà più in entrambe le applicazioni.

  Distribuzione di certificati condivisi in un'applicazione a parte

• Se un certificato è utilizzato da una porta di trasmissione o da un indirizzo di ricezione in due o più applicazioni è consigliabile distribuire il certificato in un'applicazione a parte e quindi creare un riferimento a tale applicazione nelle applicazioni in cui occorre utilizzare il certificato. Ciò è dovuto al fatto che un solo elemento in un gruppo BizTalk può avere un singolo LUID, quindi non sarà possibile importare lo stesso certificato in due applicazioni diverse. Se si tenta di importare due applicazioni che utilizzano lo stesso certificato, soltanto la prima operazione di importazione avrà esito positivo. In questo caso l'opzione di importazione Sovrascrivi non consente di risolvere il problema, poiché il certificato esistente che si desidera sovrascrivere è contenuto in un'altra applicazione.

Esportazione e importazione di un'applicazione BizTalk

Quando si distribuiscono file di .msi di grandi dimensioni, potrebbe essere necessario aumentare il timeout predefinito delle transazioni dei componenti COM+ usati da BizTalk Server per distribuire le applicazioni

• Se si tenta di distribuire un file di .msi molto grande (più di 100 MB), l'applicazione potrebbe non essere distribuita entro il timeout predefinito delle transazioni dei componenti COM+ usati da BizTalk Server durante la distribuzione dell'applicazione. Se le transazioni associate a questi componenti COM+ si verifica un timeout prima del completamento della distribuzione, la distribuzione avrà esito negativo. Se si distribuiscono file di .msi di grandi dimensioni, è consigliabile adottare uno di questi approcci per attenuare questo problema:

• Distribuire diversi file di .msi più piccoli anziché un file di .msi di grandi dimensioni.

  • Aumentare il timeout predefinito delle transazioni di 3.000 secondi associato a Microsoft.BizTalk.ApplicationDeployment.Group e ai componenti Microsoft.BizTalk.Deployment.DeployerComponent nell'interfaccia di gestione di Servizi componenti. Questi componenti appartengono rispettivamente alle applicazioni COM+ Microsoft.BizTalk.ApplicationDeployment.Engine e Microsoft.Biztalk.Deployment COM+. Per altre informazioni, vedere Impostazione del timeout della transazione.

  Impedire che le associazioni vengano sovrascritte

• Se si desidera che i binding contenuti nell'applicazione in cui si sta importando il file con estensione msi non vengano sovrascritti dai binding contenuti nell'applicazione che si sta esportando, evitare di selezionare il file di associazione come risorsa da esportare durante l'operazione di esportazione.

  Assicurarsi che il file .msi sia sicuro

• Un file di .msi può contenere dati sensibili. Assicurarsi di eseguire i passaggi per assicurarsi che il file sia sicuro. Per altre informazioni sulla sicurezza dei file di .msi, vedere Sicurezza e Windows Installer.

  Assicurarsi che il file di associazione sia sicuro

• Un file di associazione può contenere dati sensibili. Assicurarsi di eseguire i passaggi per assicurarsi che il file sia sicuro.

  Pianificare le esportazioni quando nessuno apporta modifiche a un artefatto

• Pianificare le operazioni di esportazione durante le ore in cui è probabile che gli utenti non apportano modifiche agli artefatti. Ciò può essere importante perché se un utente sta modificando un artefatto basato su database, una directory virtuale, un certificato o un criterio mentre è in corso un'operazione di esportazione, le modifiche non verranno riflesse nel file di .msi esportato.

Importazione di un'applicazione BizTalk

Creare uno script per l'importazione di file .msi

• BtsTask.exe può essere usato per creare script per l'importazione di file di .msi BizTalk esistenti. Per altre informazioni sull'importazione di script .msi file, vedere Distribuzione e gestione di applicazioni BizTalk.

  Nota

  Il white paper si applica anche alle BizTalk Server.

• È possibile aggiungere script da eseguire come script di pre-elaborazione o post-elaborazione. Tuttavia, sarà necessario includere la logica negli script per controllare le variabili di ambiente per determinare il contesto in cui viene eseguito lo script (importazione, installazione o disinstallazione) ed elaborare di conseguenza. Per altre informazioni sull'uso di script di pre-elaborazione e post-elaborazione, vedere Uso di script di pre-elaborazione e post-elaborazione per personalizzare la distribuzione dell'applicazione.

  Verificare l'esistenza di artefatti a cui si fa riferimento

• Quando un'applicazione importata ha un riferimento a un'altra applicazione, BizTalk Server verifica che l'applicazione a cui si fa riferimento esista. Tuttavia, non verifica che gli artefatti in cui l'applicazione abbia dipendenze siano inclusi nell'applicazione a cui si fa riferimento. Quando si importa un'applicazione con dipendenze in artefatti in un'altra applicazione, è consigliabile verificare che l'applicazione a cui si fa riferimento contenga l'artefatto o gli artefatti necessari.

  L'importazione da un file di .msi impedisce l'archiviazione di assembly modificati nella Global Assembly Cache

• Per aggiornare gli artefatti in un'applicazione, importare gli artefatti modificati o aggiornati da un file di .msi nell'applicazione. Se non si usa un file .msi per importare gli artefatti, sarà necessario aggiornare tutti i server del gruppo archiviando gli assembly modificati nella Global Assembly Cache.

  Gruppi di elaborazione host per aggiornare un subset di server totali

• Quando si aggiornano gli artefatti in un'applicazione, è in genere necessario aggiornare tutti i server in un gruppo BizTalk. Tuttavia, se si usano gruppi di elaborazione host, è sufficiente aggiornare un subset dei server totali nel gruppo.

  Se si verifica il timeout di un'operazione di importazione, suddividere l'applicazione in file di .msi aggiuntivi

• Se supera i 3.600 secondi di durata, si verifica un timeout di un'operazione di importazione. Se si sta tentando di importare un file di .msi e il timeout dell'operazione, è necessario dividere il contenuto dell'applicazione in più di un file .msi esportando di nuovo l'applicazione e selezionando un subset di elementi da esportare. Per altre informazioni sull'esportazione di un'applicazione in un file di .msi, vedere Esportare un'applicazione BizTalk.