Pro BizTalk 2006 phần 10 potx

HTTP-Specific Tuning Several configuration and tuning parameters are accessible for the HTTP adapter through reg- istry key entries and through the modification of the BTSNTSvc.exe.config file that is located in the root BizTalk installation directory. Table 11-3 describes the registry settings that affect the performance of the HTTP adapter. Note that by default there are no HTTP adapter keys in the registry, so the HTTP adapter uses the default settings. To change the default settings, you need to create the following registry keys under the following locations in the registry: DisableChunkEncoding, RequestQueueSize, and HttpReceiveThreadsPerCpu must be defined in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\ HttpReceive. HttpOutTimeoutInterval, HttpOutInflightSize, and HttpOutCompleteSize must be defined in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{$HostName}. 1 4 CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION. 443 14. {$H ost N ame} is the actual host name . I n B izTalk Server 2004 or a BizTalk Server 2006 upgrade from BizTalk 2004, the key may be HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ BTSSvc{GUID}, where GUID is the ID of the host for the HTTP send handler. 15. Copyright © 2004 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. Table 11-3. HTTP Adapter Settings (Microsoft,“BizTalk Server 2006 Documentation,” 2006) 15 Key Name Type Default Value Description DisableChunkEncoding DWORD 0 Regulates whether or not the HTTP Receive Adapter uses chunked encoding when send- ing responses back to the client. Set to a nonzero value to turn off chunked encoding for HTTP Receive Adapter responses. Minimum value: 0 Maximum value: Any nonzero value RequestQueueSize DWORD 256 Defines the number of concurrent requests that the HTTP Receive Adapter processes at one time. Minimum value: 10 Maximum value: 2048 HttpReceiveThreadsPerCpu DWORD 2 Defines the number of threads per CPU that are allocated to the HTTP Receive Adapter. Minimum value: 1 Maximum value: 10 HttpOutTimeoutInterval DWORD 2,000 Defines the interval in seconds that the HTTP Send Adapter will wait before timing out. Minimum value: 500 M aximum v alue: 10,000,000 Continued 6994ch11final.qxd 10/2/06 12:20 AM Page 443 Table 11-3. Continued Key Name Type Default Value Description HttpOutInflightSize DWORD 100 This is the maximum number of concurrent HTTP requests that a BizTalk Server HTTP Send Adapter instance will handle. The recommended value for latency is between three to five times that of the max- connection configuration file entry. M inimum value: 1 Maximum value: 1024 HttpOutCompleteSize DWORD 5 This is the size of the batch of messages that is returned from the HTTP Send Adapter. If the buffer is not full and there are outstand- ing responses, the adapter will wait for 1 second until it commits the batch. For low- latency scenarios, this should be set to 1, which will allow the adapter to send response messages immediately to the Mes- sagebox for processing. This will have the greatest effect during times of low-through- put activity with varied response times from back-end systems . Minimum value: 1 Maximum value: 1024 CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION.444 The number of concurrent connections that the HTTP adapter opens for a particular des- tination server is configured by modifying the maxconnection entry in the BTSNTSvc.exe.config file that is located in the root BizTalk installation directory. ■Caution This property will be applied to both the HTTP and SOAP adapters if they send messages to the same destination HTTP server. By default the maximum connections for all URIs is 20. This configuration file entry replaces the functionality of the HttpOutMaxConnection registry key that was used in BizTalk 2004. If you have upgraded from BizTalk Server 2004 to BizTalk Server 2006 and you were using this registry key, you will need to apply this config- uration file entry instead (Microsoft, 2006). 16 CLR Tuning Bottlenecks caused by contention for resources, misuse of threads, inefficient resource cleanup, or resource leaks can be rectified by tuning the CLR thread pool or memory thresholds. The use of memor y thresholds will be discussed later in the “Throttling” section. In situations with low CPU utilization or the CPU is fully saturated and yet the solution is not meeting the required throughput, increasing the maximum number of threads in the .NET thread pool b y modifying the maxIO Thr eads and maxW or kerThr eads r egistr y keys might improve performance. Tuning the maximum number of threads in the thread pool down might 16. Copyright © 2004 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 444 come in handy if the CPU utilization is pretty high, while the solution’s overall throughput is still lower than expected. This could be because the system is spending more time context-switching between threads than processing. If the solution is expected to handle load bursts, prepping the engine to maintain a minimum number of threads active to avoid the overhead of resources and thread alloca- tion when those bursts occur is a good idea. This is done by setting the minIOThreads and minWorkerThreads registry keys to ensure that a minimum number of threads are always allocated in the thread pool. A value of the expected load during a spike + 10% is usually the recommended value for the minIOThreads and minWorkerThreads settings. To modify the hosted CLR .NET thread pool for a particular BizTalk host, you have to cre- ate the following registry keys and set their values for that particular host. • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{$HostName}\ CLR Hosting\MaxWorkerThreads (REG_DWORD) • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc {$HostName}\ CLR Hosting\MaxIOThreads (REG_DWORD) • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc {$HostName}\ CLR Hosting\MinWorkerThreads (REG_DWORD) • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc {$HostName}\ CLR Hosting\MinIOThreads (REG_DWORD) 17 File Tuning Several issues can occur with the file adapter. File adapter–related issues are usually the result of NetBIOS limitations or the polling agent. Microsoft’s support articles recommend to increase the MaxMpxCt and the MaxCmds registry keys at HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\lanmanworkstation\parameters to 2048 on the BizTalk Server as well as the file server holding the file share. 18 BizTalk Server 2006 can encounter problems when a polling notification and a file change notification occur at the same time. This problem can be avoided by disabling FRF (File R eceive Functions) polling through the File Receive Location property pages. File Tuning: Batch Files When dealing with lar ge flat files that generate thousands of subdocuments in an env elope , isolate the File Receive Adapter in a separate host. Set the batch size to 1 and the thread-pool siz e for that host to 1. This will reduce the number of files you are processing in one trans- action from 20 to 1 and single thr ead the host. The batch siz e pr operty could be set on the CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION. 445 17. The {$HostName} in BTSSvc{$HostName} should be replaced by the actual host name. In BizTalk 2004 or BizTalk 2006 installations that are an upgrade from BizTalk 2004, the {$HostName} should be replaced with the GUID for that host. To get the GUID for a particular host, open the Services Console from the Administrative Tools, locate the host that requires the tuning, and get its ServiceName including the GUID. 18. The support article “‘The Network BIOS Command Limit Has Been Reached’ Error Message in Windows Server 2003, in Windows XP, and in Windows 2000 Server” can be found at http://support. microsoft.com/?id=810886. 6994ch11final.qxd 10/2/06 12:20 AM Page 445 receive location property page. To set the thread-pool size to 1, set the MessagingThreadsPerCpu property, which defines the number of threads per CPU for the thread pool, on the host’s property pages and create the MessagingThreadPoolSize registry key, which defines the number of threads per CPU in the thread pool, under HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc {$HostName }. The respective default values for both properties are 2 and 10. Setting those two values to 1 and dedicating a single thread in the host’s thread pool to message processing ensures that multiple large flat files will not be competing for system resources within that host and that all the host’s mem- ory resources will be dedicated to processing the large message. ■Note If you have multiple receive locations receiving large flat files as well as smaller ones, group them under different receive handlers running on different hosts. This ensures that the tuning performed on the host instances running the File Receive handler for large-flat-file processing does not affect the rest of the file receive functions processing smaller files. It is recommended to partition those receive handlers on different servers within the BizTalk Server Group by interleaving host instances on the different servers to ensure they are not competing for the same system resources. When supporting large interchanges in BizTalk Server 2006, multiple smaller interchanges utilize the CPU processor more efficiently than fewer large interchanges. As a general guide- line, use the following formula to determine the maximum size of an interchange for any given deployment (number of CPU processors): Maximum number of messages per interchange <= 200,000 / (Number of CPUs ✕ BatchSize ✕ MessagingThreadPoolSize) So, for example, a BizTalk host running on a four-CPU server tuned for large-flat-file pro- cessing, having a batch size of 1 and a single thread in its messaging thread pool, would be able to process an infinite number of interchanges as long as each interchange contains a maximum of 50,000 messages (200,000 divided by 4).Thus, MessagingThreadPoolSize is set to 1. Parsing and Persistence Persistence affects the overall system performance. Message parsing affects performance due to the incurred persistence points in the process. To tune the BizTalk solution and minimize the number of persistence points, change the Large Message Threshold and Fragment Size property of the BizTalk Server Group. The default value for this property is 1MB, meaning that each 1MB r ead from the message will result in a fragment being persisted to the Messagebox. To further elaborate, as stated in the white paper “BizTalk Server 2006 Runtime Improve- ments” (Microsoft, 2005): 19 CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION.446 19. Copyright © 2005 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 446 In previous releases of BizTalk Server, mapping of documents always occurred in-mem- ory. While in-memory mapping provides the best performance, it can quickly eat up resources when large documents are mapped. For this reason, BizTalk Server 2006 intro- duced support for large message transformations. A different transformation engine is used when transforming large messages so that memory is utilized in an efficient man- ner. When dealing with large messages, the message data is buffered to the file system instead of being loaded into memory using the DOM (Document Object Model). This way the memory consumption remains flat as memory is used only to store the cashed data and indexes for the buffer. However,as the file system is used, there is expected per- formance degradation when comparing with in-memory transformation. Because of the potential performance impact, the two transformation engines will coexist in BizTalk Server 2006. When message size is smaller than a specified threshold, the in-memory transformation will be used. If message size exceeds the threshold then the large message transformation engine is used. The threshold is configurable using the registry • DWORD ‘TransformThreshold’ • ‘HKLM\\Software\\Microsoft\\BizTalk Server\\3.0\\Administration’. If the solution handles a low number of large messages, increase this value to a large value like 5MB. If the solution handles a high number of small/medium messages, set this value to 250K. You will need to experiment with this setting to find the optimum value for your solu- tion and messages. Increasing the Large Message Threshold and Fragment Size property for the BizTalk Server Group results in fewer persistence points, in turn causing fewer round-trips to the database and faster message processing. The drawback of this approach is higher mem- ory utilization, as fragments kept in memory now are much larger in size. To compensate for the expected higher memory utilization by the large message fragments, control the number of large message buffers that are created by the BizTalk host. You can do so by creating a MessagingLMBufferCacheSize (DWORD) registry key under System\CurrentControlSet\ Services\BTSSvc<HostName> and setting its value to 5. By controlling the number of large message buffers, you are hedging the risk of having the host run into low memory situations due to large message processing without incurring the penalty of constant round-trips to the Messagebox (Wasznicky, 2006). 20 Latency The time taken to process a message is dependent on how often the different BizTalk Server components pick up wor k items from the Messagebox. This interval affects the rate at which r eceiv ed messages ar e being published to the M essagebo x as well as the rate at which they are being picked up from the Messagebox for processing or delivery. To deliver enterprise capabil- ities such as fault toler ance and scalability , the distributed BizTalk Server agents have to communicate asynchr onously thr ough the M essagebo x. This asynchronous communication scheme means that the agents have to check the Messagebox for state updates to pick up new CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION. 447 20. Copyright © 2006 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 447 items for processing and update the Messagebox at appropriate points in the process. This polling process contributes to the inherent latency of BizTalk solutions. If the end-to-end pro- cessing time per business transaction under low loads is unacceptable, you might want to look into tuning the interval at which the different agents check the Messagebox. By default, the MaxReceiveInterval is set to 500 msecs. You can reset this interval to a value as low as 100 msecs by modifying it in the adm_ServiceClass table for the XLANG/s, Messaging Isolated, and Messaging In-Process hosts. If the overall environment is experiencing high loads on the database while the overall end-to-end business transaction processing speed is acceptable, you can increase the MaxReceiveInterval and check whether that improves the overall envi- ronment’s stability. Throttling Throttling is the mechanism by which the runtime engine prevents itself from thrashing and dropping dead when exposed to a high load. A properly throttled engine takes up only the amount of load that it can handle, and detects a stressed situation quickly and mitigates the situation accordingly. Before BizTalk Server 2006 In BizTalk 2004, throttling BizTalk Server includes manipulating entries in the adm_ ServiceClass table. Manipulating that table manually is now deprecated as it was troublesome and originally undocumented. Throttling BizTalk Server 2004 manually usually leads to more problems if inexperienced administrators start manipulating it, as it is mostly a trial-and-error exercise. Manipulating the adm_ServiceClass table affects the entire BizTalk Server Group, not just a specific host instance. The configuration settings are not host specific and hence are not useful in any configuration with multiple hosts. If different servers in the BizTalk Server Group have different hardware configurations, having the same settings across different hardware is not the best approach. Other problem areas in BizTalk Server 2004 are as follows: • The stress detection mechanism in BizTalk 2004 is grossly dependent on user input, namely the low and high watermark numbers in the adm_ServiceClass table. • The configuration parameters are not exposed to the user through the UI. • The inbound throttling heuristic (session count based) is not very effective because XLANG does not factor this at all, and all the sessions are shared across all the service classes. • The agent ’ s memor y -based throttling policy has two major drawbacks: • F irst, it looks into the global memor y and does not take into account the local memory usage. So if the server has more memory than 2GB, it might not be throttling properly, as the maximum amount of memory that a host instance can consume is 2GB on a W indo ws 32-bit platform. So, while the server could still have free memory that is not being consumed by other services, a particular host might be running out of the memory that it could consume without throttling. CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION.448 6994ch11final.qxd 10/2/06 12:20 AM Page 448 • Second, while enforcing throttling due to low memory condition, the agent does not do anything to improve the memory usage situation, other than elevating the stress level. Once it enters a stress mode due to high memory condition, no measure is taken for it to come out of this stage, and hence it remains in this state for a long time. As the sys- tem starts again, it reloads all dehydrated orchestrations, resulting in an elevated rate of resource consumption leading to the same situation that caused the throttle in the first place (Wasznicky, 2006). 21 Throttling Goals for BizTalk Server 2006 One of the Microsoft development team’s objectives for BizTalk Server 2006 was to get around the nuances of throttling configuration. The target was a system that avoids using user-input parameters for detecting stress condition—a system with heuristics that include monitoring of resources (e.g., memory, threads, database sessions), utilization, and progress of work items against submitted work items. This would allow the system to function automatically without the administrator having to deal with the unknowns surrounding the various control knobs for the watermark numbers and other settings in the adm_ServiceClass table. Some parameters still have to be configured manually. The bright side is that they can be set and manipulated through the administration UI, and they have out-of-box valid settings. Those parameters are now at host level rather than group level. The aim is to eventually communicate throttling actions to the system administrator through event logs and performance counters. Presently only the inbound throttling is com- municated through the event log. If the system is throttled due to lack of a particular resource, the engine proactively tries to mitigate the situation by releasing that particular resource so that it comes out of the stress situation. For example, under low memory, cache should be shrunk and MSMQT instances should be dehydrated. Unlike BizTalk Server 2004, BizTalk Server 2006 throttling takes into account process memory, in addition to global memory. All components follow uniform throttling policies to ensure a fair distribution of resources. Auto-Throttling in 2006 BizTalk Server 2006 auto-throttling consists of a set of load detection algorithms and mitiga- tion plans. Table 11-4 highlights those algorithms. CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION. 449 21. Copyright © 2006 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 449 Table 11-4. BizTalk Server 2006 Auto-Throttling Mechanisms (Wasznicky, 2006) 22 Detection Mitigation Affected Components Monitors Compare Message Throttle message delivery XLANG Need to monitor D elivery Rate with the so that the delivery rate All outbound transports Message Delivery M essage Completion comes down and becomes Rate and Message Rate. When the latter at par with the completion Completion Rate. falls short, it is an indi- rate. cation of the fact that messages are being pushed at higher rate than the service can handle Compare the Publishing Block the publishing XLANG Need to monitor R equest Rate with Pub- threads to slow down the All inbound transports entry and exit of lishing Completion Rate. publishing rate Commit Batch call. When the latter falls AND/OR short, it is an indication indicate service class to of the Messagebox being slow down publishing unable to cope with the load. Process memory exceeds Throttle publishing if XLANG Monitor Private a threshold. batch has steep memory All transports Bytes. requirement. Throttle delivery. Indicate service to dehydrate/shrink cache. System memory exceeds Throttle publishing if XLANG Monitor physical a threshold. batch has steep memory All transports memor y. requirement. Throttle delivery. Database sessions being Throttle publishing. XLANG Monitor average used by the process All inbound transports session usage per exceed a threshold count. Messagebox. Any host message queue Throttle publishing if XLANG Monitor queue size size, the spool size, or batch is going to create All inbound transports against respective the tracking data size more records in the data- threshold. exceeds a particular host- base than delete. specific threshold in database. Process thread count Throttle publishing. XLANG Monitor threads per exceeds a particular Throttle delivery. Indi- All transports CPU. threshold. cate service to reduce thread-pool size. Number of messages Throttle delivery. XLANG This is needed for deliv er ed to a ser vice All outbound tr anspor ts send port throttling class exceeds a particular where the EPM thr eshold count. expects only a limited number of messages at a time. CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION.450 To per for m this auto-thr ottling, the ser v er uses the configurable parameters detailed in Table 11-5. 22. Copyright © 2006 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 450 Table 11-5. BizTalk Server 2006 Auto-Throttling Parameters (Wasznicky, 2006) 23 Default Min Max Name Type Description Value Value Value Message Delivery Throttling Configuration Sample-space size Long Number of samples that are used for 100 0 N/A determining the rate of the message delivery to all service classes of the host. This parameter is used to determine whether the samples collected for applying rate-based throttling are valid or not. If the number of samples col- lected is lower than the sample size, the samples are discarded because the sys- tem is running under a low load and hence no throttling may be required. Thus this value should be at par with a reasonable rate at which messages can be consumed under a medium load. For example, if the system is expected to process at 100 docs per second in a medium load, then this par ameter should be set to (100 ✕ sample window duration in seconds). If the value is set too low, the system may overthrottle on low load. If the value is too high, there may not be enough samples for this technique to be effective. Zero indicates rate-based message delivery throttling is disabled . Sample-space window Long Duration of the sliding time window 15,000 1,000 N/A (in milliseconds) within which samples will be considered for calculation of rate. Zero indicates rate-based message delivery throttling is disabled . Overdriv e factor Long Percent factor by which the system will 125 100 N/A tr y to o verdrive the input. That is, if the output rate is 200 per second and the overdr ive factor is 125%, the system will allow up to 250 (200 ✕ 125%) per sec- ond to be passed as input before apply- ing rate-based throttling. A smaller value will cause a very conservative throttling and may lead to overthrottling when load is increased, whereas a higher value will try to adapt to the increase in load quickly, at the expense of slight underthrottling. Maximum delay Long Maximum delay (in milliseconds) 300,000 0 N/A imposed for message delivery throttling. The actual delay imposed is a factor of how long the throttling condition persists and the severity of the partic- ular throttling trigger. Zero indicates message delivery throttling is completely disabled . Continued CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION. 451 23. Copyright © 2006 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation. 6994ch11final.qxd 10/2/06 12:20 AM Page 451 Table 11-5. Continued Default Min Max Name Type Description Value Value Value Message Publishing Throttling Configuration Sample-space size Long Number of samples that are used for 100 0 N/A determining the rate of the message publishing by the service classes. This parameter is used to determine whether the samples collected for applying rate- based throttling are valid or not. If the number of samples collected is lower than the sample size, the samples are discarded because the system is running under a low load, and hence no throt- tling may be required. Thus this value should be at par with a reasonable rate at which messages can be consumed under a medium load. F or example, if the system is expected to publish 100 docs per second in a medium load, this parameter should be set to (100 ✕ sample window duration in seconds). If the value is set too low, then the system may overthrottle on low load. If the value is too high, there may not be enough samples for this technique to be effective. Zero indicates rate-based message publishing throttling is disabled . Sample-space window Long Duration of the sliding time window 15,000 1,000 N/A (in milliseconds) within which samples will be considered for calculation of rate. Zero indicates rate-based message publishing throttling is disabled . Overdrive factor Long Percent factor by which the system will 125 100 N/A tr y to overdrive the input. That is, if the output rate is 200 per second and the overdrive factor is 125%, the system will allow up to 250 (200 ✕ 125%) per sec- ond to be passed as input before apply- ing r ate-based thr ottling. A smaller v alue will cause a v er y conser vative throttling and may lead to overthrottling when load is increased, whereas a higher value will try to adapt to the increase in load quickly, at the expense of slight underthrottling. Maximum delay Long Maximum delay (in milliseconds) 300,000 0 N/A imposed for message publishing thr ottling. The actual delay imposed is a factor of how long the throttling condition persists and the severity of the particular throttling trigger. Zero indicates message publishing throttling is completely disabled . CHAPTER 11 ■ TO TUNE OR NOT TO TUNE? NOBODY SHOULD ASK THAT QUESTION.452 6994ch11final.qxd 10/2/06 12:20 AM Page 452 [...]... Framework BizTalk Server Configuration tool, 325 BizTalk Server Developer Edition, 13 BizTalk Server Enterprise Edition, 13 BizTalk Server Framework 2.0 see BizTalk Framework BizTalk Server Group see BizTalk Group BizTalk Server Pipeline Component wizard, 457 BizTalk servers see servers BizTalk services, 69 In-Process hosts hosting subservices, 70 BizTalk solutions see also BizTalk applications see also projects... artifacts BizTalk Assembler component interchanges, 111 sending multiple ZIP files, 174 BizTalk assembly artifact, 379 BizTalk binding file artifact, 379 BizTalk components see components BizTalk configuration backup procedures, 344 BizTalk databases see databases BizTalk engine host instances, 69 BizTalk Explorer, 38 BizTalk Explorer toolbar, 325 BizTalk File Service Receive Location, 225 BizTalk Framework... definition artifact, 379 BAS artifacts, 379 BizTalk 2004 artifact organization, 37 BizTalk 2006 artifact layout, 38 BizTalk 2006 requirement for, 379 BizTalk Administration Console, 329 BizTalk applications, 37–38, 378, 379 BizTalk artifacts, 57 BizTalk assembly artifact, 379 BizTalk binding file artifact, 379 BTAD_ChangeRequestAction, 383 BtsCatalogExplorer class, 410 business rules, 287–298 COM component... 120 BizTalk map see maps BizTalk Messagebox see Messagebox BizTalk Messagebox database see Messagebox database BizTalk Messaging Engine see Messaging Engine BizTalk Orchestration Designer see Orchestration Designer BizTalk reliable messaging configuration, 119 BizTalk runtime environment restore procedures, 360 BizTalk runtime servers disaster recovery procedures, 369–371 methods for setting up, 369 BizTalk. .. message context, 129–132 promoting properties into, 75, 129 message context properties, 73–75 context property bags, 73, 75 property schema, 73, 73–74 Message count in database threshold parameter auto-throttling in BizTalk 2006, 454 message data uses of pipelines, 105 Message Delivery throttling configuration auto-throttling in BizTalk 2006, 451 Message Details dialog box ApprovedRequest message, 242... MSBTS_TrackedMessageInstance class, 406 MSDTC security configuring BizTalk Log Shipping, 367 Msft.Samples .BizTalk. Exception project, 235 Msft.Samples .BizTalk. Exception.Schemas project, 235 Msft.Samples .BizTalk. ExceptionManagemen t solution EAIProcess orchestration, 239 MSI (Microsoft Installer) files deploying BizTalk application, 324 MSI exports BizTalk 2006, 33 typical BizTalk deployment cycle, 399 MSI packages choosing... dallas.sark.com/SarkBlog/jmsummers/archive/0001/01/01/2192.aspx Thomas, Steven W “Property Schema and Promoted Properties Inside Custom Pipelines for BizTalk 2004.” Steven W Thomas BizTalk Blog, 2004 www.geekswithblogs.net/sthomas/ archive/2004/08/27 /103 01.aspx Wasznicky, Marty BizTalk 2006 Deep Dive Workshop.” Microsoft Corporation, 2006 Woodgate, Scott, Stephen Mohr, and Brian Loesgen Microsoft BizTalk Server 2004 Unleashed Indianapolis,... 33–34 suitable project types, 18 transaction considerations, 19–20 Visual SourceSafe solution layout, 31 BizTalk streams, 147–148 BizTalk subservices, 70 BizTalk tier high availability, 334–335 scaling out BizTalk tier, 332–333 scaling up BizTalk tier, 333 BizTalk Tracking database Backup BizTalk Server job, 338 DTA Purge and Archive job, 337, 343 BizTalk Web Services Publishing wizard, 326 BizTalk WMI... messaging artifacts, 58 naming conventions, 57, 58 organizing artifacts in BizTalk 2006, 36–39 Policy or rule artifact, 379 Post-processing script artifact, 379 pre BizTalk 2006, 377 Pre-processing script artifact, 379 purpose of BizTalk applications, 377 Security certificate artifact, 379 Select Artifact Type dialog box, 101 typical BizTalk deployment cycle, 398 Virtual directory artifact, 379 ASP NET... Console, 327 Scripting and Programmability APIs, 325 SSOClient command-line tool, 326 SSOConfig command-line tool, 326 SSOManage command-line tool, 326 viewing artifacts pre BizTalk 2006, 377 adm_HostInstance_SubServices table, 70 adm_OtherBackupDatabases table, 347 adm_ServiceClass table throttling in BizTalk 2004, 448 throttling in BizTalk 2006, 449 tuning BizTalk Server 2004 /2006, 423, 424 After predicate, . http:// msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/ 1e2e50f7-6609-4eb2-a9a1-3a951700f840.asp. Microsoft. BizTalk Server 2006 Documentation .” MSDN, 2006. Downloaded from http:// msdn.microsoft.com /biztalk/ ref/default.aspx. Microsoft. BizTalk Server 2006 Runtime Improvements.” Microsoft. 379 BAS ar tifacts, 379 BizTalk 2004 artifact organization, 37 BizTalk 2006 artifact layout, 38 BizTalk 2006 requirement for, 379 BizTalk Administration Console, 329 BizTalk applications, 37–38,. 58 organizing artifacts in BizTalk 2006, 36–39 Policy or rule artifact, 379 Post-processing script artifact, 379 pre BizTalk 2006, 377 Pre-processing script artifact, 379 purpose of BizTalk applications,