Condividi tramite

Configurazione del motore di orchestrazione

  • Articolo

Il motore di orchestrazione utilizza un file XML denominato BTSNTSvc.exe.config per determinare alcuni comportamenti. Le proprietà di disidratazione e i relativi valori predefiniti, ad esempio, sono configurati come XML nel file BTSNTSvc.exe.config e vengono letti quando tutte le istanze host contenenti un'orchestrazione sono avviate. Per altre informazioni, vedere Orchestrazione di disidratazione e riattivazione.

Un servizio legge queste informazioni di configurazione una sola volta, quando viene avviato. Eventuali modifiche non saranno prelevate a meno che il servizio non venga arrestato e riavviato.

Per i diversi nodi e i valori possibili, vedere gli esempi seguenti.

Esempio: tutte le convalide in

<?xml version="1.0" ?>
<configuration>
       <configSections>
              <section
                     name="xlangs"
                     type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
       </configSections>
       <runtime>
              <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                     <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking" />
              </assemblyBinding>
       </runtime>

       <xlangs>
              <Configuration>
                     <Debugging
                            ValidateAssemblies="true"
                            ValidateSchemas="true"
                            ValidateCorrelations="true"
                            ExtendedLogging="true"
                     />
              </Configuration>
       </xlangs>
</configuration>

Esempio: solo convalida degli assembly

<?xml version="1.0" ?>
<configuration>
       <configSections>
              <section
                     name="xlangs"
                     type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess"
              />
       </configSections>
       <runtime>
              <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                     <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking" />
              </assemblyBinding>
       </runtime>

       <xlangs>
              <Configuration>
                     <Debugging
                            ValidateAssemblies="true"
                            ExtendedLogging="false"
                     />
              </Configuration>
       </xlangs>
</configuration>

Esempio: debug remoto abilitato

<?xml version="1.0" ?>
<configuration>
       <runtime>
              <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                     <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking" />
              </assemblyBinding>
       </runtime>

       <system.runtime.remoting>
              <customErrors mode="on"/>
              <channelSinkProviders>
                     <serverProviders>
                            <provider id="sspi"
                                    type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="negotiate" authenticationLevel="packetPrivacy" />
                     </serverProviders>
              </channelSinkProviders>

              <application>
                     <channels>
                            <channel ref="tcp" port="0" name="">
                                   <serverProviders>
                                          <provider ref="sspi" />
                                          <formatter ref="binary" typeFilterLevel="Full"/>
                                   </serverProviders>
                            </channel>
                     </channels>
              </application>
       </system.runtime.remoting>
</configuration>

Esempio: Configurazione di AppDomain

Gli assembly vengono assegnati ai domini denominati mediante le regole di assegnazione (vedere le ulteriori informazioni seguenti). Se per un assembly non è specificata alcuna regola, l'assembly verrà assegnato a un dominio ad hoc. Il numero di assembly assegnati in questo modo per dominio ad hoc è determinato dal valore di AssembliesPerDomain.

<?xml version="1.0" ?>
<configuration>
    <configSections>
        <section name="xlangs" type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
    </configSections>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking" />
        </assemblyBinding>
    </runtime>
    <xlangs>
        <Configuration>
            <!--
                <!--
AppDomain configuration.
                Assemblies are assigned to named domains using assignment rules (see more below). If no rule is specified for some assembly, the assembly will be assigned to an ad hoc domain. The number of such assigned assemblies per ad hoc domain is determined by the value of AssembliesPerDomain.
            -->-->
            <AppDomains AssembliesPerDomain="10">
                <!--
                    <!--
In this section the user may specify defualt configuration for any app domain created that does not have a named configuration associated with it (see AppDomainSpecs below)
                    SecondsEmptyBeforeShutdown is the number of seconds that an app domain is empty (that is, it does not contain any orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload, even when empty.
                    Similarly, SecondsIdleBeforeShutdown is the number of seconds that an app domain is idle (that is, it contains only dehydratable orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload when idle but not empty. When an idle but non-empty domain is shut down, all of the contained instances are dehydrated first.
                -->
                -->
<DefaultSpec SecondsIdleBeforeShutdown="1200" SecondsEmptyBeforeShutdown="1800">
                    <!--
                        <!--
BaseSetup is a serialized System.AppDomainSetup object. This is passed as-is to
                        AppDomain.CreateAppDomain() and can be used to influence assembly search path etc.
                    -->
                    -->
<BaseSetup>
                        <ApplicationBase>c:\myAppBase</ApplicationBase>_0</ApplicationBase>
                        <ConfigurationFile>c:\myAppBase\myConfig.config</ConfigurationFile>_0</ConfigurationFile>
                    <DynamicBase>DynamicBase_0</DynamicBase>
<DisallowPublisherPolicy>true</DisallowPublisherPolicy>
<ApplicationName>ApplicationName_0</ApplicationName>
<PrivateBinPath>PrivateBinPath_0</PrivateBinPath>
<PrivateBinPathProbe>PrivateBinPathProbe_0</PrivateBinPathProbe>
<ShadowCopyDirectories>ShadowCopyDirectories_0</ShadowCopyDirectories>
<ShadowCopyFiles>ShadowCopyFiles_0</ShadowCopyFiles>
<CachePath>CachePath_0</CachePath>
<LicenseFile>LicenseFile_0</LicenseFile>
<LoaderOptimization>NotSpecified</LoaderOptimization>
</BaseSetup>
                </DefaultSpec>
                <!--
                    - <!--
In this section the user may specify named configurations for specific app domains, identified by their "friendly name". The format of any app-domain spec is identical to that of the default app-domain spec.
                -->-->
                <AppDomainSpecs>
                    <AppDomainSpec Name="MyDomain1" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="12000">
                        <BaseSetup>
                            <PrivateBinPath>c:\PathForAppDomain1</PrivateBinPath>
                        <PrivateBinPath>PrivateBinPath_0</PrivateBinPath>
<PrivateBinPathProbe>PrivateBinPathProbe_0</PrivateBinPathProbe>
</BaseSetup>
                    </AppDomainSpec>
                    <AppDomainSpec Name="MyFrequentlyUnloadingDomainMyTrashyDomain" SecondsIdleBeforeShutdown="60" SecondsEmptyBeforeShutdown="60" />
                </AppDomainSpecs>
                <!--
                    <!--
The PatternAssignmentRules and ExactAssignmentRules control assignment of assemblies to app domains.
                    When a message arrives, the name of its corresponding orchestration's assembly is determined. Then, the assembly is assigned an app domain name. The rules guide this assignment. Exact rules are consulted first, in their order of definition, and then the pattern rules. The first match is used.
                    If no match is found, the assembly will be assigned to an ad-hoc domain. The configuration and number of assemblies per ad-hoc domain is controlled by the AssembliesPerDomain attribute and the DefaultSpec section.
                -->
               -->
- <ExactAssignmentRules>
                    <!--
                        <!--
An exact assembly rule specifies a strong assembly name and an app domain name. If the strong assembly name equals the rule's assembly name, it is assigned to the corresponding app domain.
                    -->-->
                    <ExactAssignmentRule AssemblyName="BTSAssembly1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9c7731c5584592ad"
                       AssemblyName_0" AppDomainName="MyDomain1" />AppDomainName_1" />
                    <ExactAssignmentRule AssemblyName="BTSAssembly2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9c7731c5584592ad"AssemblyName_0" AppDomainName="AppDomainName_1" />
                        AppDomainName="MyFrequentlyUnloadingDomain " />
                <ExactAssignmentRule AssemblyName="AssemblyName_0" AppDomainName="AppDomainName_1" />
</ExactAssignmentRules>
                <PatternAssignmentRules>
                    <!--
                        <!--
A pattern assignment rule specifies a regular expression and an app domain name. If the strong assembly name matches the expression, it is assigned to the corresponding app domain. This allows version independent assignment, assignment by public key token, or assignment by the custom assembly key.
                    -->-->
                    <!--
                        assign all assemblies with name BTSAssembly3, regardless of version and public key,
                        to the MyDomain1 app domain
                    -->
                    <PatternAssignmentRule AssemblyNamePattern=" BTSAssembly3, Version=\d.\d.\d.\d, Culture=neutral, PublicKeyToken=.{16}"AssemblyNamePattern_0" AppDomainName=" MyDomain1" />
                <PatternAssignmentRule AssemblyNamePattern="AssemblyNamePattern_0" AppDomainName="AppDomainName_1" />
<PatternAssignmentRule AssemblyNamePattern="AssemblyNamePattern_0" AppDomainName="AppDomainName_1" />
</PatternAssignmentRules>
            </AppDomains>
        </Configuration>
    </xlangs>
</configuration>

Modifica di altre sezioni del file BTSNTSvc.exe.config

Per informazioni sulla modifica dei valori di disidratazione in BTSNTSvc.exe.config, vedere Proprietà predefinite di disidratazione.

Il file di configurazione BTSNTSvc.exe contiene diverse altre sezioni documentate nel Riferimento generale di .NET Framework. Per altre informazioni sulla modifica di queste sezioni, vedere Schema del file di configurazione di .NET Framework General Reference all'indirizzo https://go.microsoft.com/FWLink/?LinkID=52964.

Oltre alle informazioni di configurazione specifiche di BizTalk, il file BTSNTSvc.exe.config è anche in cui i componenti dell'applicazione .NET eseguiti nel contesto di un'orchestrazione, di un adattatore o di una pipeline ottengono le informazioni di configurazione in fase di esecuzione usando il tag appSettings> .NET< standard nel tag di configurazione>.< Poiché BizTalk fornisce già un meccanismo per adattatori personalizzati e componenti della pipeline per ottenere informazioni di configurazione, il <tag appSettings> nel file BTSNTSvc.exe.config viene in genere usato dai componenti .NET personalizzati chiamati dall'interno di un'orchestrazione. Ad esempio:

<appSettings>
     <add key="configParamName" value="configParamValue" />
</appSettings>

Throttling Messages Per Orchestration

Questa proprietà specificata nel file btsntsvc.exe.config impedisce un utilizzo eccessivo della memoria da parte di un'orchestrazione limitando il numero di messaggi in sospeso che può contenere. Tutti i messaggi continueranno a essere recapitati a MessageBox; tuttavia, i messaggi in coda non verranno recapitati all'orchestrazione finché non viene completata l'elaborazione di alcuni dei messaggi in sospeso.

Per specificare questa proprietà nel file btsntsvc.exe.config (che si trova nella directory radice BizTalk Server), aggiungere il parametro seguente in Nodo applicazione:

<configuration>
            <application>
                        <Throttling PauseAt="100" ResumeAt="50" />
            </application>
</configuration>

In questo esempio, quando l'orchestrazione raggiunge i 100 messaggi in attesa, MessageBox interromperà l'invio di ulteriori messaggi. Quando il numero di messaggi in sospeso dell'orchestrazione scende al di sotto di 50, MessageBox riprenderà l'invio dei messaggi. È possibile specificare altri valori.

È inoltre necessario attivare questa funzionalità, per host, nel database. Per attivare la limitazione dei messaggi per un host, è necessario modificare la tabella dbo.Applications nel database BizTalkMsgBoxDb. Per ogni host che si vuole abilitare la limitazione dei messaggi per orchestrazione, impostare il flag fAttributes bit su 1. Solo gli host con fAttribute impostato su 1 consentiranno la limitazione dei messaggi per orchestrazione.

Vedere anche

Debug del linguaggio XLANG-sdelle orchestrazioni