Configuración del motor de orquestaciones
El motor de orquestación utiliza un archivo XML denominado BTSNTSvc.exe.config para determinar determinados comportamientos. Por ejemplo, las propiedades de deshidratación y los valores predeterminados están configurados como XML en el archivo BTSNTSvc.exe.config y se leen cuando se inician todas las instancias de host que contienen una orquestación. Para obtener más información, consulte Rehidratación y rehidratación de orquestación.
Un servicio lee esta información de configuración una vez que se ha iniciado. No se recogerá ningún cambio realizado a menos que se detenga y se reinicie el servicio.
Consulte los ejemplos que se muestran a continuación para los diferentes nodos y los posibles valores.
Ejemplo: todas las validaciones en
<?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>
Ejemplo: solo validación de ensamblados
<?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>
Ejemplo: depuración remota habilitada
<?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>
Ejemplo: Configuración de AppDomain
Los ensamblados se asignan a dominios con nombres utilizando reglas de asignación (consulte más detalles abajo). Si no se especifica ninguna regla para algunos ensamblados, estos se asignarán a un dominio ad hoc. El número de dichos ensamblados asignados por dominio ad hoc viene determinado por el valor de 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>
Modificar otras secciones del archivo BTSNTSvc.exe.config
Para obtener información sobre cómo modificar los valores de deshidratación en BTSNTSvc.exe.config, vea Propiedades predeterminadas de deshidratación.
El archivo de configuración BTSNTSvc.exe contiene otras secciones documentadas en la referencia general de .NET Framework. Para obtener más información sobre la modificación de estas secciones, vea el esquema de archivo de configuración de la referencia general de .NET Framework en .https://go.microsoft.com/FWLink/?LinkID=52964
Además de la información de configuración específica de BizTalk, el archivo BTSNTSvc.exe.config también es donde los componentes de la aplicación .NET que se ejecutan en el contexto de una orquestación, adaptador o canalización obtienen su información de configuración en tiempo de ejecución mediante la etiqueta estándar appSettings> de .NET< en la etiqueta de< configuración>. Dado que BizTalk ya proporciona un mecanismo para que los adaptadores personalizados y los componentes de canalización obtengan información de configuración, la <etiqueta appSettings> del archivo BTSNTSvc.exe.config normalmente la usarían los componentes personalizados de .NET llamados desde una orquestación. Por ejemplo:
<appSettings>
<add key="configParamName" value="configParamValue" />
</appSettings>
Limitar mensajes por orquestación
Esta propiedad, que se especifica en el archivo btsntsvc.exe.config, evitará que una orquestación consuma demasiada memoria. Para ello, limitará el número de mensajes pendientes que puede tener. Todos los mensajes seguirán siendo entregados al Cuadro de mensajes; sin embargo, los mensajes en cola no se entregarán a la orquestación hasta que procese algunos de sus mensajes pendientes.
Para especificar esta propiedad en el archivo btsntsvc.exe.config (ubicado en el directorio raíz BizTalk Server), agregue el siguiente parámetro en nodo Aplicación:
<configuration>
<application>
<Throttling PauseAt="100" ResumeAt="50" />
</application>
</configuration>
En este ejemplo, cuando la orquestación alcanza los 100 mensajes pendientes, el cuadro de mensajes dejará de enviar más mensajes. Cuando el número de mensajes pendientes de la orquestación desciende a 50, especificará que el cuadro de mensajes puede retomar el envío de mensajes. Puede especificar otros valores.
Asimismo, debe habilitar esta característica, por host, en la base de datos. Para habilitar la limitación de mensajes para un host, debe editar la tabla dbo.Applications de la base de datos BizTalkMsgBoxDb. Para cada host que quiera habilitar la limitación de mensajes por orquestación, establezca el bit de marca fAttributes en 1. Solo los hosts con fAttribute establecido en 1 permitirán la limitación de mensajes por orquestación.
Consulte también
Depuración dellenguaje XLANG-s de orquestaciones
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de