Configuration du moteur d’orchestration
Le moteur d'orchestration se sert du fichier XML BTSNTSvc.exe.config pour déterminer certains comportements. Par exemple, les propriétés de mise en attente et leurs valeurs par défaut sont configurées au format XML dans le fichier BTSNTSvc.exe.config et sont lues lorsque toutes les instances d'hôte contenant une orchestration sont démarrées. Pour plus d’informations, consultez Déshydratation et réhydratation d’orchestration.
Un service lit ces informations de configuration une fois, au moment où il est démarré. Aucune modification apportée à ces informations n'est prise en compte, à moins d'arrêter le service, puis de le redémarrer.
Vous trouverez ci-dessous des exemples pour des nœuds et des valeurs possibles.
Exemple : toutes les validations sur
<?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>
Exemple : validation d’assembly uniquement
<?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>
Exemple : débogage à distance activé
<?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>
Exemple : configuration AppDomain
Les assemblys sont assignés à des domaines nommés à l'aide de règles d'assignation (voir plus bas). Si aucune règle n'est spécifiée pour certains assemblys, ces derniers se voient assignés à un domaine ad hoc. Le nombre des assemblys ainsi assignés par domaine ad hoc est déterminé par la valeur du paramètre 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>
Modification d'autres sections du fichier BTSNTSvc.exe.config
Pour plus d’informations sur la modification des valeurs de déshydratation dans BTSNTSvc.exe.config, consultez Propriétés par défaut de déshydratation.
Le fichier de configuration BTSNTSvc.exe contient plusieurs autres sections décrites dans les références générales de .NET Framework. Pour plus d’informations sur la modification de ces sections, consultez le schéma de fichier de configuration de la référence générale .NET Framework à l’adresse .https://go.microsoft.com/FWLink/?LinkID=52964
En plus des informations de configuration spécifiques à BizTalk, le fichier BTSNTSvc.exe.config est également l’endroit où les composants d’application .NET qui s’exécutent dans le contexte d’une orchestration, d’un adaptateur ou d’un pipeline obtiennent leurs informations de configuration au moment de l’exécution à l’aide de la balise .NET <appSettings> standard sous la balise de <configuration> . Étant donné que BizTalk fournit déjà un mécanisme permettant aux adaptateurs personnalisés et aux composants de pipeline d’obtenir des informations de configuration, la <balise appSettings> dans le fichier BTSNTSvc.exe.config est généralement utilisée par les composants .NET personnalisés appelés à partir d’une orchestration. Par exemple :
<appSettings>
<add key="configParamName" value="configParamValue" />
</appSettings>
Limitation des messages par orchestration
Cette propriété, spécifiée dans le fichier btsntsvc.exe.config, empêche une orchestration d'utiliser trop de mémoire en limitant le nombre de messages en attente qu'elle peut avoir. Tous les messages continuent d'être envoyés vers la base de données MessageBox. Toutefois, les messages en file d'attente ne sont envoyés à l'orchestration qu'une fois certains de ses messages en attente traités.
Pour spécifier cette propriété dans le fichier btsntsvc.exe.config (situé dans le répertoire racine BizTalk Server), ajoutez le paramètre suivant sous Nœud d’application :
<configuration>
<application>
<Throttling PauseAt="100" ResumeAt="50" />
</application>
</configuration>
Dans cet exemple, une fois qu'une orchestration possède 100 messages en attente, la base de données MessageBox arrête l'envoi des messages. Lorsque le nombre des messages en attente descend à 50, la base de données MessageBox reprend l'envoi. Vous pouvez spécifier d'autres valeurs.
Vous devez également activer cette fonction, par hôte, dans la base de données. Pour activer la limitation des messages pour un hôte, modifiez la table dbo.Applications dans la base de données BizTalkMsgBoxDb. Pour chaque hôte que vous souhaitez activer la limitation des messages par orchestration, définissez le bit d’indicateur fAttributes sur 1. Seuls les hôtes dont l’attribut fAttribute est défini sur 1 autorisent la limitation des messages par orchestration.