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


HTML Source EditorWord wrap


BizTalk Server 2006 LifeCycle
Demos description


V1.0


 






 


Introduction


Sample ConfirmationApp application


High Availability Execution Platform


Demos


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)


 


Introduction


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.


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 http://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


 

Comments (4)

  1. Marshal says:

    The download size of .wmv files are in bytes… and its not opening in windows media player !!

  2. The videos are meant to be streamed, not downloaded. Save target as might not work