Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo argomento sono 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 sapere come distribuire ulteriormente o annullare la distribuzione. Qualsiasi elemento non inserito in script deve essere documentato con passaggi dettagliati. Ciò dovrebbe includere la documentazione delle modifiche apportate ai sistemi esterni e la distribuzione di componenti di terze parti.
Distribuzione dell'applicazione script
Scriptare 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 di 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
Non distribuire mai un assembly da Visual Studio in un computer di produzione
Durante il processo di sviluppo, uno sviluppatore deve spesso ridistribuire gli assembly da Visual Studio. Per abilitare il ridispiegamento, Visual Studio può annullare la distribuzione, annullare l'associazione, arrestare e deregistrare gli artefatti inclusi negli assembly. Sebbene sia necessario e appropriato nell'ambiente di sviluppo, può causare 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, non fare mai riferimento a un database di produzione da un computer che esegue Visual Studio.
Aggiunta di elementi a un'applicazione BizTalk
Raggruppare gli artefatti correlati in una singola applicazione
Il più possibile, inserire gli artefatti correlati nella stessa applicazione BizTalk. In questo modo è possibile gestire e distribuire gli artefatti come singola entità, semplificando la gestione. È possibile raggruppare elementi che supportano lo stesso processo aziendale o gli stessi artefatti che eseguono funzioni simili in una singola applicazione.
Distribuire elementi condivisi in un'applicazione separata
Se gli artefatti verranno condivisi da due o più applicazioni, distribuire gli artefatti condivisi in un'applicazione separata. Ad esempio, se due applicazioni condividono uno schema, posizionare lo schema in un'applicazione separata. È consigliabile farlo 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.
Questa procedura consigliata si applica a tutti i tipi di artefatti, ad eccezione dei file Readme e degli script, che vengono aggiunti all'applicazione come tipo di elemento File. Ciò è dovuto al fatto che più di un artefatto di file con lo stesso nome può essere distribuito in un gruppo BizTalk. Pertanto, è possibile usare un file con 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.
Distribuire un sito Web condiviso in un'applicazione separata
Se un sito Web verrà condiviso da più soluzioni aziendali, distribuire il sito Web in un'applicazione separata. Ciò è dovuto al fatto che quando si disinstalla un'applicazione BizTalk, la directory virtuale di qualsiasi sito Web che fa parte dell'applicazione viene rimossa, anche se il sito Web è in esecuzione. Se il sito Web viene condiviso con un'altra soluzione aziendale, l'altra soluzione aziendale non funzionerà più correttamente di conseguenza.
Distribuire criteri condivisi in un'applicazione separata
Se un criterio viene usato da due o più applicazioni, è consigliabile distribuirlo in un'applicazione separata anziché creare un riferimento da un'applicazione a un'altra. Ciò è dovuto al fatto che quando si arresta un'applicazione, i relativi criteri non vengono distribuiti. Se si arresta un'applicazione che include un criterio usato da un'altra applicazione, i criteri non funzioneranno più in alcuna applicazione.
Distribuire i certificati condivisi in un'applicazione separata
Se un certificato viene usato da una porta di trasmissione o da un percorso di ricezione in due o più applicazioni, è necessario distribuire il certificato in un'applicazione separata e quindi fare riferimento a questa applicazione dalle applicazioni che devono usare 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 usano lo stesso certificato, la prima importazione avrà esito positivo e la seconda non verrà eseguita. In questo caso, l'uso dell'opzione di importazione Sovrascrittura non risolve il problema, perché il certificato esistente da 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 delle transazioni predefinito 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 della transazione dei componenti COM+ usati da BizTalk Server durante la distribuzione dell'applicazione. Se le transazioni associate a questi componenti COM+ vanno in timeout prima del completamento della distribuzione, la distribuzione fallirà. 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 della transazione 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 la sovrascrittura delle associazioni
Se non si desidera che le associazioni nell'applicazione esportate sovrascrivono le associazioni in un'applicazione in cui si sta importando il file .msi, non è consigliabile selezionare il file di associazione come risorsa da esportare durante l'operazione di esportazione.
Assicurarsi che il file .msi sia sicuro
Un file .msi può contenere dati sensibili. Assicurarsi di eseguire le operazioni necessarie per assicurarsi che il file sia sicuro. Per altre informazioni sulla sicurezza dei file .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 le operazioni necessarie 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. Questo 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 .msi esportato.
Importazione di un'applicazione BizTalk
Creare uno script per l'importazione di file di .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.
Annotazioni
Il white paper si applica anche a 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 (un'importazione, un'installazione o una 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 .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 .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 sottoinsieme del totale dei server
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 durante un'operazione di importazione, suddividere l'applicazione in dei file aggiuntivi .msi
Un'operazione di importazione raggiunge il timeout se supera i 3.600 secondi di durata. Se si sta tentando di importare un file .msi e si verifica il timeout dell'operazione, è necessario dividere il contenuto dell'applicazione in più di un file .msi esportando nuovamente l'applicazione e selezionando un subset di artefatti da esportare. Per altre informazioni sull'esportazione di un'applicazione in un file .msi, vedere Esportare un'applicazione BizTalk.