Notes on Running XLANG Schedules

This section contains some notes on running and designing XLANG schedules. Also see Chapter 10 for using the Orchestration Designer and Chapter 13, “Advanced BizTalk Orchestration.”

• Dehydrated schedules consume few precious system resources, such as CPU, memory, and semaphores. For an action that receives a message from an outside application, consider what wait time you want to assign. Any wait time less than 180 seconds causes the XLANG schedule to never dehydrate, unless the group manager is deliberately shut down. The default value is 0 seconds.

• Use components that can persist to disk, where possible. This allows the XLANG Scheduler Engine the flexibility to dehydrate the schedules when appropriate. If the components used by a schedule contain state and their state cannot be persisted to disk, then the schedule is unable to dehydrate.

• Consider collocating the group manager on the same server as the persistence database. Dehydration and rehydration are frequent operations, and you do not want to incur network latency for database access.

• Weigh the trade-off between running COM+ components in-process versus out-of-process. In-process gives you performance but trades it for stability.

• Don't get entangled in performance debates and optimization issues prematurely. First design and implement a process flow that incorporates the necessary business requirements while keeping the design simple. Then use the tools to evaluate the performance.

• Loosely coupled, asynchronous messaging is more scalable than synchronous calls. Use messaging where possible. Design COM components to return control quickly.

• The engine cannot dehydrate a running instance in the middle of a Distributed Transaction Controller (DTC) style transaction. However, it must persist the state before and after such a transaction. This (persistence) is an expensive operation; hence, it is beneficial to include as many actions as appropriate within a single transaction.