Instance Management

To understand how the XLANG Scheduler Engine performs instance management, you must be aware of the distinction between an abstract definition of a business process, and multiple running instances of a business process definition. In BizTalk Orchestration Designer, you design a business process definition and save it as an XLANG schedule drawing (an .skv file). After you have created an XLANG schedule drawing, you compile it into an XLANG schedule (an .skx file). After you deploy the XLANG schedule, there are likely to be several instances of the schedule running simultaneously. Each XLANG schedule instance can have a life span that is independent of the life span of any of the other instances. When you design an application to support multiple XLANG schedule instances, you should be aware of the following issues:

  • Activating new instances of XLANG schedules when messages are received. You can design your application to activate a new XLANG schedule instance by using the COM function GetObject every time a message is received. For example, if you use an Active Server Page (ASP) to receive a message containing a purchase order or a customer support request, the ASP must use the COM function GetObject to activate an XLANG schedule.

You can also use the BizTalk Messaging Binding Wizard to create a port binding that can serve as a named location to which messages are sent. BizTalk Server 2000 provides an automated mechanism to activate an instance of an XLANG schedule when a port that is bound to BizTalk Messaging receives a message. On the XLANG Schedule Activation Information page of the BizTalk Messaging Binding Wizard, you are prompted to confirm whether the channel has been configured in BizTalk Messaging Services to send a message to this port after the activation of a new instance of this XLANG schedule. To complete this process, you will have to run the New Messaging Port Wizard in BizTalk Messaging Manager. On the Destination Application page of the New Messaging Port Wizard, specify the name of the port and the name and location of the XLANG schedule.

  • Correlating the exchange of messages to XLANG schedule instances. Every instance of an XLANG schedule is assigned a globally unique identifier (GUID) by the XLANG Scheduler Engine. Therefore, every port on every running instance of an XLANG schedule can be uniquely addressable. This enables direct communication to specific ports on specific XLANG schedule instances. By enabling direct communication through uniquely addressable port locations, the difficulty of using a single location to distribute messages to instances is avoided. The first message sent by a schedule instance will likely be to a static port (a named location). When the XLANG schedule is activated, this instance will send the locations of its dynamic ports (per-instance, unique locations) to recipients who will be responsible for communicating back to the ports. This corresponds to e-mail messages that are sent out with unique reply-to addresses. The following list describes dynamic binding support in each of the BizTalk Server binding technologies:
    • On the Static or Dynamic Communication page of either the COM Component or Script Component Binding Wizard, if you choose Static, the XLANG Scheduler Engine will create the XLANG schedule instance of the component. If you choose Dynamic, another application must send an interface pointer or moniker (as a field in a message) prior to the instantiation of the component.

      You also have the option of choosing No instantiation. For more information about component instantiation, see Static and Dynamic Ports.

    • On the Static or Dynamic Communication page of the Message Queuing Binding Wizard, if you choose Static queue and click Next, you will invoke the Queue Information page. On the Queue Information page you can specify the creation of a separate, per-instance queue for every XLANG schedule instance, or you can specify the use of a single queue for all running instances. To enable correlation, you must specify the creation of a separate, per-instance queue for every XLANG schedule instance.

    • On the Static or Dynamic Communication page of the Message Queuing Binding Wizard, if you choose Dynamic Queue, another application must send the name of the queue (as a field in a message) prior to sending or receiving messages through the port.

    • On the Static or Dynamic Channel Information page of the BizTalk Messaging Binding Wizard, you can choose to provide a specific channel name, or indicate that port configuration information will be used by BizTalk Messaging Services to identify the correct channel at run time. For more information about message exchange, see Integrating BizTalk Services.

    Ee264400.important(en-US,BTS.10).gif Important

    • You must make sure that a message correlates to the same XLANG schedule instance that participated in an earlier communication with a trading partner.
  • Scaling the application. Any XLANG schedule instances that do not need to be in memory should be dehydrated. An XLANG schedule instance might not need to be in memory when an XLANG schedule instance is waiting for the arrival of a message.

Ee264400.note(en-US,BTS.10).gif Note

  • All implementation shapes display a shadow to indicate that the location will be bound dynamically and defined at run time.

Related Topics