BizTalk Server 2006 LifeCycleDemos description
Sample ConfirmationApp application
High Availability Execution Platform
Deploy application with MSI (InstallConfirmApp_3min21.wmv)
Application's bindings (ConfirmApp_1_bindings_4min24.wmv)
Application's execution on different servers (ConfirmApp_2_scale_and_availability_7min11.wmv)
MOM 2005 Administration Console overview (ConfirmApp_MOM_Admin_2min02.wmv)
MOM 2005 Operator console overview (ConfirmApp_MOM_Operator_3min25.wmv)
Creation of a new Host (NewSampleInProcHost_4min24.wmv)
Send Handler and Send Port binding (AdaptersBindings_1min41.wmv)
Deploy application Vn+1 while Vn instances continue to run (InstallConfirmAppVn+1_8min14.wmv)
This paper describes BizTalk Server 2006 short video demonstrations.
A sample application is used for those scenarios. It is first described.
The pllatform on which most scenarios are executed is also described.
Then, demos are described. They have no sound, so you should read their description to understand what they are about.
These demonstrations show the deployment and the execution of an application on a highly available platform. It also shows Microsoft Operations Manager 2005 in action with BizTalk Server 2006's management pack.
Demonstrations use an application called confirmationApp which basically receives a question message (msgQuestion) via MSMQ, creates a process ID that is integrated in question to create the Confirmation message (msgConfirmation) that is sent as a file. That file is taken by a client application and send as an answer (msgAnswer) thru HTTP. Between confirmation and andswer, there is a timeout provided as a parameter in msgQuestion.
A sample client application (SendQuestionThruMSMQ) is provided. It sends msgQuestion to MSMQ Question queue.
Another sample client application (SendAnswerToHttpFromFileConfirmation) gets msgConfirmation from FILE Folder in order to show it, have user edit it if needed and send msgAnswer to HTTP receive location.
The client applications, receive locations, send port, BizTalk message box and orchestrations all fit together as shown here:
Orchestration write traces that can be seen thru dbgView.exe from http://www.sysinternals.com as shown here:
Most demos are executed on the following platform
The following Hosts and Host Instances are created
InProcHostA is an in process host that have instances on the four BizTalk servers in the group (BTS1, BTS2, CBTS1 and CBTS2).
InProcHostB is a clustered in process host that have instances on the clustered BizTalk servers (CBTS1 and CBTS2).
IsolatedHostA is an isolated Host that has an instance on the BizTalk servers that could receive NLB traffic (BTS1 and BTS2).
from MOM1, which as administrative tools, but no BizTalk engine, import MSI. This will configure group and must be done just once in the group.
Run MSI on BTS1
Run MSI on BTS2
Run MSI on CBTS1
Run MSI on CBTS2
On BTS2 (for instance) check that assemblys were deployed to the GAC and that assemblys were also deployed to the folder specified in MSI execution.
MSI did not contain bindings. Start configuration newly deployed application…
This video shows how application is bound.
All host instances are running except InProcHostB on CBTS1 because CBST2 is currently the active node
Both orchestrations are started
Main orchestration's bindings:
ConfirmationSendPort is bound to InProcHostA (can run on any of the 4 BizTalk Servers) and sends files to \\CSQL0SQL\SampleFileShare\Confirmation (this is a clustered file share hosted by SQL Cluster (CSQL1 and CSQL2))
AnswerReceivePort has AnswerReceiveLocation receivelocation which is bound to IsolatedHostA (can run on BTS1 or BTS2). It is an HTTP receive location that receives on /BizTalkReceiveA/BTSHTTPReceive.dll?rl=Answer
QuestionReceivePort has QuestionReceiveLocation receive location which is bound to InProcHostB (executed on BizTalk cluster only) and receives MSMQ messages from CBTS0BTS\privates$\question transactional queue.
overview of the receive locations
overview of the schemas
Overview of the resources (BizTalk and C# assemblies)
BTS1 implementation in IIS of HTTP receive location
BTS2 implementation in IIS of HTTP receive location
CBTS* implementation of MSMQ receive location
CSQL* implementation of clustered file share where confirmation messages are posted
In this scenario, MOM1 server is used as a client machine that sends MSMQ messages, gets FILE messages and sends back HTTP messages.
The 4 BizTalk Servers run dbgView in order to show what orchestration traces they execute.
MOM1 sends a msgQuestion (this will become process with ID yarl)
orchestration instance can be seen in BizTalk Server 2006 administration console.
Execution of the first part of this instance took place on BTS1 (process ID yarl)
Stop InProcHostA on BTS1 so that yarl instance must continue on another other server
Send answer to yarl
yarl execution continues on BTS2 (one of the remaining servers having a running InProcHostA host instance)
Send a new msgQuestion (this will create wipk)
see that yarl sub orchestration was executed on CBTS1 (there was no choice because the only InProcHostB running host instance is on CBTS0BTS active node which is CBTS1).
wipk starts its execution on CBTS2
Stop CBTS1 InProcHostA host instance
Send answer to wipk
wipk continues on CBTS2
Send a new msgQuestion (will become waem)
waem starts on CBTS2, sub orchestration still executes on CBTS1
note that waem confirmation file can be seen in the confirmation folder
Stop InProcHostA CBTS2 host instance so that waem can only continue on BTS2 (only remaining running instance of InProcHostA)
Send waem answer
Execution of waem continued on BTS2 as expected
Send a new msgQuestion (will become process instance lint)
lint starts on BTS2 (there was no choice)
stop InProcHostA host instance on BTS2 so that there is no remaining running host instance. Note that lint instance still subscribes to its answer but it cannot run anywhere for now.
Send lint answer
See that lint instance is dehydrated (cannot run anywhere)
Start an InProcHostA host instance: BTS1's one
lint instance finishes on BTS1
Move CBTS0BTS group from CBTS1 node to CBTS2. CBTS2 will be the active node for InProcHostB.
cluster has failed over to other node
refresh BizTalk administration console to see that InProcHostB is now active in CBTS2 (instead of CBST1).
Start all stopped InProcHostA host instances at once
Send a new msgQuestion (will be hlvg)
hlvg instance started on BTS1
hlvg sub orchestration executed on CBTS2 (all sub orchestration used to execute on CBTS1 but is no longer the active node on BizTalk Cluster)
Send hlvg answer
This video shows an overview of a MOM administration console, and the BizTalk Server 2006 management pack
This video shows an overview of a MOM operator console, and the BizTalk Server 2006 management pack
Create a new Host named SampleInProcHost
need an Windows group
Go to Active Directory (BTS6DC) and create a new group, a new service account that will be a member of that group
come back to host definition and give BTS6\Sample Host Group as the Windows group
Create a host instance
a combo box shows the new host instance can be created on any BizTalk server in the group
Choose BTS1 and configure by adding service account and password
Host instance is available
start host instance. This will start the newly created Windows Service on BTS1 server.
Create a new host instance on another server
Choose SampleInProcHost and CBTS1 server
provide service account and password
host instance is available
Try to cluster SampleInProcHost
This is not possible because all host instances are not cluster nodes (BTS1 is not)
Show available Host and Host instances
Go to FILE Adapter. It has one send handler bound to InProcHostA
Open that send handler properties
This FILE send handler can be bound to other in proc hosts (not the isolated host)
Create a new FILE Send Handler
Bind it to SampleInProcHost
A warning states that host instance should be restarted for the changes to take effect
Create a new FILE SendPort
It can be bound to all hosts that have a corresponding send handler for that FILE adapter: InProcHostA and SampleInProcHost
This demonstration is executed on a single server development platform. The principle would be exactly the same in a multi-server platform.
Vn = V184.108.40.206
Vn+1 = V220.127.116.11
Show existing started V1 orchestrations
show subscriptions. V1.0 orchestration has a subscription on activation because it is started.
Send an msgQuestion to V1.0. This will be process zwkh
Send an msgQuestion to V1.0. This will be process sbmx
traces show zwkh started
Subscriptions for V1.0: activation (orchestration is started) and one instance (zwkh)
traces show sbmx started
Stop traces (deployment generated traces we don't need here)
take zwkh confirmation in client application, don't send answer yet
Go to development in order to create V1.1. Here, it is already developed. Just see that traces include "(V1.1)" string.
GAC only has AskForConfirmation* V18.104.22.168 assemblies
In BizTalk Administration console, manually deploy new BizTalk assembly by adding the resource in ConfirmationApp
AskForConfirmation.dll is shown as V22.214.171.124 because File version was kept as V126.96.36.199. Assembly version is V188.8.131.52. Only this one was changed here in order to show that this is the important one.
Check check box so that assembly is added to the GAC while we are adding it in BizTalk application
V184.108.40.206 assembly is available in BizTalk application, side by side with V220.127.116.11 one
V18.104.22.168 assembly was also deployed to the GAC side by side with V22.214.171.124 one
V1.1 orchestrations are now available
unenlist V1.0 orchestrations
V1.0 subscription for activation is now grayed
instance subscriptions (zwkh and sbmx) are still active
V1.1 has no subscription
Bind V1.1 orchestrations. They will have the same bindings as V1.0 orchestrations.
Start V1.1 orchestrations so that new V1.1 instances can be created on msgQuestion receptions.
Change msgQuestion parameters (question and default answer will contain V1.1 in lieu of V1.0)
V1.1 orchestrations are started. See V1.1 subscriptions. There is an activation subscription for V1.1 main orchestration.
See V1.0 subscriptions in details. Details show process IDs sbmx and zwkh.
Restart traces listening
Send a msgQuestion messages (will become fojc)
Send zwkh answer
fojc orchestration started with V1.1 orchestration
Take fojc confirmation and send answer
Take sbmx confirmation and send answer
sbmx orchestration continues with V1.0 bits
There are no remaining instances
Stop trace listening
Check that there are no V1.0 instances
Go to resources and remove V1.0 orchestrations assembly
Check that V1.0 orchestrations were removed
Send a new msgQuestion that will become mact (to check that V1.1 alone still runs OK)
mact started in V.1
Send mact answer
mact ends OK in V1.1