Benjamin Guinebertière

This blog is about Microsoft Azure. Older stuff include architecture, SOA, BizTalk, ...

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

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

Rate This
  • Comments 4
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

 

Page 1 of 1 (4 items)
Leave a Comment
  • Please add 6 and 4 and type the answer here:
  • Post