BizTalk Server 2006 Lifecycle short video demos with description(no sound)

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.

Sample ConfirmationApp application

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 https://www.sysinternals.com as shown here:

High Availability Execution Platform

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).

Demos

Deploy application with MSI

Time Code	Description
00:00	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.
01:00	Run MSI on BTS1
01:28	Run MSI on BTS2
01:53	Run MSI on CBTS1
02:01	Run MSI on CBTS2
02:34	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.
03:05	MSI did not contain bindings. Start configuration newly deployed application…

Application's bindings

This video shows how application is bound.

Time Code	Description
00:02	All host instances are running except InProcHostB on CBTS1 because CBST2 is currently the active node
00:10	Both orchestrations are started
00:24	Main orchestration's bindings: runs in InProcHostA. This means in can run on BTS1, BTS2, CBTS1, CBTS2 ReceiveQuestionPort orchestration port is bound to QuestionReceivePort messaging port ReceiveAnswerPort orchestration port is bound to AnswerReceivePort messaging port SendConfirmationRequestPort orchestration port is bound to ConfirmationSendPort messaging port
00:34	SubOrchestration's bindings: runs in InProcHostB. This means it can only run on the active BizTalk cluster node (CBTS1 or CBTS2)
00:44	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))
01:04	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
01:26	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.
01:54	overview of the receive locations
01:58	overview of the schemas
02:11	Overview of the resources (BizTalk and C# assemblies)
02:20	BTS1 implementation in IIS of HTTP receive location
03:07	BTS2 implementation in IIS of HTTP receive location
03:33	CBTS* implementation of MSMQ receive location
04:13	CSQL* implementation of clustered file share where confirmation messages are posted

Application's execution on different servers

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.

Time Code	Description
00:00	MOM1 sends a msgQuestion (this will become process with ID yarl)
00:17	orchestration instance can be seen in BizTalk Server 2006 administration console.
00:21	Execution of the first part of this instance took place on BTS1 (process ID yarl)
00:41	Stop InProcHostA on BTS1 so that yarl instance must continue on another other server
00:53	Send answer to yarl
01:02	yarl execution continues on BTS2 (one of the remaining servers having a running InProcHostA host instance)
01:12	Send a new msgQuestion (this will create wipk)
01:16	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).
01:21	wipk starts its execution on CBTS2
01:41	Stop CBTS1 InProcHostA host instance
01:46	Send answer to wipk
01:51	wipk continues on CBTS2
02:09	Send a new msgQuestion (will become waem)
02:22	waem starts on CBTS2, sub orchestration still executes on CBTS1
02:26	note that waem confirmation file can be seen in the confirmation folder
02:32	Stop InProcHostA CBTS2 host instance so that waem can only continue on BTS2 (only remaining running instance of InProcHostA)
02:44	Send waem answer
02:46	Execution of waem continued on BTS2 as expected
03:31	Send a new msgQuestion (will become process instance lint)
03:41	lint starts on BTS2 (there was no choice)
03:43	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.
03:48	Send lint answer
04:14	See that lint instance is dehydrated (cannot run anywhere)
04:29	Start an InProcHostA host instance: BTS1's one
04:44	lint instance finishes on BTS1
05:05	Move CBTS0BTS group from CBTS1 node to CBTS2. CBTS2 will be the active node for InProcHostB.
05:23	cluster has failed over to other node
05:39	refresh BizTalk administration console to see that InProcHostB is now active in CBTS2 (instead of CBST1).
05:49	Start all stopped InProcHostA host instances at once
06:19	Send a new msgQuestion (will be hlvg)
06:44	hlvg instance started on BTS1
06:49	hlvg sub orchestration executed on CBTS2 (all sub orchestration used to execute on CBTS1 but is no longer the active node on BizTalk Cluster)
06:57	Send hlvg answer

MOM 2005 Administration Console overview

This video shows an overview of a MOM administration console, and the BizTalk Server 2006 management pack

MOM 2005 Operator console overview

This video shows an overview of a MOM operator console, and the BizTalk Server 2006 management pack

Creation of a new Host

Time Code	Description
00:00	Create a new Host named SampleInProcHost
00:15	need an Windows group
00:19	Go to Active Directory (BTS6DC) and create a new group, a new service account that will be a member of that group
01:28	come back to host definition and give BTS6\Sample Host Group as the Windows group
01:55	Create a host instance
02:10	a combo box shows the new host instance can be created on any BizTalk server in the group
02:16	Choose BTS1 and configure by adding service account and password
02:48	Host instance is available
02:52	start host instance. This will start the newly created Windows Service on BTS1 server.
03:08	Create a new host instance on another server
03:18	Choose SampleInProcHost and CBTS1 server
03:22	provide service account and password
03:45	host instance is available
03:48	Start it
04:06	Try to cluster SampleInProcHost
04:12	This is not possible because all host instances are not cluster nodes (BTS1 is not)

Send Handler and Send Port binding

Time Code	Description
00:00	Show available Host and Host instances
00:16	Go to FILE Adapter. It has one send handler bound to InProcHostA
00:21	Open that send handler properties
00:27	This FILE send handler can be bound to other in proc hosts (not the isolated host)
00:37	Create a new FILE Send Handler
00:43	Bind it to SampleInProcHost
00:53	A warning states that host instance should be restarted for the changes to take effect
01:22	Create a new FILE SendPort
01:32	It can be bound to all hosts that have a corresponding send handler for that FILE adapter: InProcHostA and SampleInProcHost

Deploy application Vn+1 while Vn instances continue to run

This demonstration is executed on a single server development platform. The principle would be exactly the same in a multi-server platform.

Vn = V1.0.0.0

Vn+1 = V1.1.0.0

Time Code	Description
00:00	Show existing started V1 orchestrations
00:07	show subscriptions. V1.0 orchestration has a subscription on activation because it is started.
00:18	Send an msgQuestion to V1.0. This will be process zwkh
00:24	Send an msgQuestion to V1.0. This will be process sbmx
00:26	traces show zwkh started
00:33	Subscriptions for V1.0: activation (orchestration is started) and one instance (zwkh)
00:35	traces show sbmx started
00:46	Stop traces (deployment generated traces we don't need here)
00:56	take zwkh confirmation in client application, don't send answer yet
01:02	Go to development in order to create V1.1. Here, it is already developed. Just see that traces include "(V1.1)" string.
01:09	Build
01:24	GAC only has AskForConfirmation* V1.0.0.0 assemblies
01:49	In BizTalk Administration console, manually deploy new BizTalk assembly by adding the resource in ConfirmationApp
02:00	AskForConfirmation.dll is shown as V1.0.0.0 because File version was kept as V1.0.0.0. Assembly version is V1.1.0.0. Only this one was changed here in order to show that this is the important one.
02:32	Check check box so that assembly is added to the GAC while we are adding it in BizTalk application
02:53	V1.1.0.0 assembly is available in BizTalk application, side by side with V1.0.0.0 one
02:57	V1.1.0.0 assembly was also deployed to the GAC side by side with V1.0.0.0 one
03:06	V1.1 orchestrations are now available
03:12	unenlist V1.0 orchestrations
03:23	V1.0 subscription for activation is now grayed instance subscriptions (zwkh and sbmx) are still active
03:37	V1.1 has no subscription
03:44	Bind V1.1 orchestrations. They will have the same bindings as V1.0 orchestrations.
04:20	Start V1.1 orchestrations so that new V1.1 instances can be created on msgQuestion receptions.
04:39	Change msgQuestion parameters (question and default answer will contain V1.1 in lieu of V1.0)
05:04	V1.1 orchestrations are started. See V1.1 subscriptions. There is an activation subscription for V1.1 main orchestration.
05:17	See V1.0 subscriptions in details. Details show process IDs sbmx and zwkh.
05:53	Check instances
05:58	Restart traces listening
06:00	Send a msgQuestion messages (will become fojc)
06:15	Send zwkh answer
06:20	fojc orchestration started with V1.1 orchestration
06:25	Take fojc confirmation and send answer
06:37	Take sbmx confirmation and send answer
06:40	sbmx orchestration continues with V1.0 bits
06:50	There are no remaining instances
07:00	Stop trace listening
07:07	Check that there are no V1.0 instances
07:21	Go to resources and remove V1.0 orchestrations assembly
07:49	Check that V1.0 orchestrations were removed
07:58	Send a new msgQuestion that will become mact (to check that V1.1 alone still runs OK)
08:07	mact started in V.1
08:09	Send mact answer
08:12	mact ends OK in V1.1