New WSS Adapter videos are available on the Microsoft Beta site, BizTalk Server 2006 program

Hi folks,
Sorry for the long delay since my last post, I just got back from a 3 weeks vacation. My parents visited US for the first time and I took some time off to show them how wonderful Puget Sound is. Originally, I am from Romania but I moved here 5 years ago and this was their first visit.


When I got back from vacation I had the surprise to see that the new WSS Adapter demos that I recorded before going on vacation have been approved and posted online on the BizTalk Beta Place, so here they are …



  1. WSSAdapter-SetupAndConfig-Short.wmv (9.58 MB) – Windows SharePoint Services 2003 with SP2 and BizTalk Server 2006 Beta 1 setup and configuration
  2. WSSAdapter-SendReceiveCBR.wmv (10.25 MB) – basic send and receive scenario using Content Based Routing feature in BizTalk
  3. WSSAdapter-InfoPathIntegration.wmv (15.11 MB) – using InfoPath integration feature of the adapter
  4. WSSAdapter-PropsInOrchestration.wmv (28.58 MB) – tutorial for BizTalk developers showing how to access SharePoint properties from BizTalk orchestrations, how to configure SharePoint adapter dynamic send ports and how to send messages to SharePoint lists like the Tasks list

The demos included in these videos build one on top of each-other so it makes sense to view them in the order I listed above.


The previous webcast “BTS 2006 Windows SharePoint Services (WSS) Adapter Deep Dive” is also available.


Videos are shared on this SharePoint site
http://wssadapter.members.winisp.net/default.aspx, in the Shared Documents document library, WSS Adapter Webcasts folder.


This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included videos are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Some of the content was developed for the BizTalk Beta builds, but it is still generally applicable to the RTM version.

BizTalk 2006 CTP Installation


Well, after about 10 tries on a freshly built Windows XP SP2 laptop I was finally able to get the CTP build of BizTalk Server 2006 installed and configured.  I had installed it before with no problems.  For some reason, this new image of Windows just did not want to cooperate.



The problem I ran into was with the configuration of the user groups.  I received this error:


Failed to check if BizTalk Application Users is a valid domain group.



This seemed odd, since this is a stand alone laptop.  It is not a member of any domain.  I was putting my user name for the Biztalk configuration as “biztalkuser”.  I noticed in SQL 2005, the user name was listed as ComputerName\biztalkuser.  I tired that and it worked.  So, keep this in mind that you might have to use your computer name with your user name for configuring Biztalk 2006 even if you are not on a domain.



Don’t get me wrong, the overall installation process is orders of magnitude better in BizTalk 2006 then is was in 2004.  


 


Also, the CTP release of the Oracle Data Base Adapter, Oracle Apps Adapter, PeopleSoft Adapter, and Siebel Adapter are included with the download.  They are NOT installed automatically.  You need to run the Microsoft BizTalk Adapters.MSI located in the LOBAdapters folder.  Then, you need to register each adapter inside Biztalk Admin.



Oh, one more thing.  If you download the installation guide for the CTP build, the default path is \Program Files\BizTalk Server 2006.  This is not the same location as the server program files.



Best of luck.


 


Update:  Well, after getting some great feedback from Microsoft directly on my installation problem it looks as though the problem was a full event log?  Yep, that’s what the logs said. 



So, if you have this type of issue with the CTP build try clearing your event log and trying again.



On a side note, it is STRONGLY recommended NOT to prefix your user name with the computer name for a single computer installation.


Sweden BizTalk Users Group

Hi,


I’m thinking of seeing if there is enough interest to start a BizTalk User Group in Sweden. The plan is to meet in Stockholm, in the city, after work hours, maybe 5pm. You will have to put up with me talking the first time, but I plan to involve other speakers to talk about Windows Workflow, SOA, and other BizTalk related stuff.


If you are interested, hit the “Contact” link and I will get back to you with further details. I am aiming for late November, early December for the first meeitng.


Cheers,


Alan

BizTalk 2006 Launch yesterday and new packaging announced

Yesterday was a big day for Microsoft and ofcourse also for us developers. Im happy with the next release of Microsoft BizTalk Server.

Microsoft announced yesterday that BizTalk Server 2006 packaging has undergone some significant changes, namely all adapters in the box, and inclusion of functionality previous found in Host Integration Server 2004 Enterprise edition.

The news about adapters is very significant for our customers. All of the new adapters we’ve purchased from iWay will be included in the box with ALL editions of BizTalk Server, and, require no additional licensing. Also, the SAP adapter will now also be included in the packaging!

While we are discontinuing Host Integration Server Enterprise Edition (but keeping Standard edition), we are rolling the Transaction Integrator function into BizTalk Server 2006. This means that host communication to IBM mainframes, AS/400s and the like will be native BizTalk data sources/destinations. Also, a DB2 adapter is provided in the BizTalk box.

While we are incrementally raising the price for BizTalk Server 2006, it’s hard not to admit that we are adding SIGNIFICANT functionality into the product by not requiring the purchase of additional licensing for complementary components. If you’re a prospective SoCal BizTalk customer, I’m going to work with you to see the definitive value of purchasing BizTalk Server 2004 + SA NOW in order to get the BizTalk Server 2006 product at BizTalk 2004 prices. Great stuff. I’m jazzed about giving our customers the capability to do more robust EAI/B2B/BPM as soon as they install the bits.

The CTP we released today (on Microsoft BetaPlace) also has a portion of the new adapters provided (namely, Peoplesoft). To sign up for the CTP, go the the BizTalk Evaluation Page.

Read the full BizTalk Pricing FAQ on the Microsoft.com site for all the details. Also, the BizTalk Server page at Microsoft.com has undergone a BizTalk 2006 transformation today!

 

Biztalk 2006 Officially Launched

Today marked the official launch of Biztalk Server 2006, SQL Server 2005, and Visual Studios 2005.



On top of getting free version of SQL 2005 and Visual Studios 2005 at the launch event, Microsoft has posted a new Biztalk 2006 version to Beta Place. 



The new version is the CTP Build with the Beta 2 release to hopefully follow later on.


                            


From what I hear, the CTP build includes the new Line of Business (LOB) adapters.



A few points:


– This release works on the RTM of SQL 2005 and Visual Studios 2005


– I was not able to find the CAB file included with the download.  So, internet access might be required to download it.


– I needed to restart the computer after the CAB download.  I selected “I’ll restart later” but I do not think the installer liked that choice.  I had to re-download the CAB file again after I rebooted.



Enjoy!

Launch, Launch, Launch

In my 5 years in the business, today is the today I’m most proud of.  Not because we are finished with BizTalk Server 2006 – we are not – but we are making lots of progress having released our second CTP build that works on the RTM versions of SQL and VS.NET.  Incidentally the quality of this build is pretty good, and beta 2 is currently in release candidate mode so we aren’t too far away from another release which is a true beta.  With beta 2 our early adopter customers will have the option to go into production – so we are at a more scalable, more stable, more feature complete point than we ever has been at this time in the cycle.


No – today it is all about visibility.  As a BizTalk guy I’ve longed for BizTalk Server to be part of the Microsoft Application Platform so that all those developers who really need BizTalk Server but weren’t aware of it could finally take advantage of it.  Well the time is right, the product is right, the need is right and we are going out super loud.  You can bet that with BizTalk Server 2006 your skills will be in demand more than ever before.


Having said that we thought we could accelerate things from a pricing and licensing perspective – which we also announced today.  When I started in this business 5 years ago we introduced a price-point that while high from a Microsoft software perspective was dramatically lower than our competitors.  Today, we do it again.  As part of the pricing for BizTalk Server 2006 we have bundled ALL of the adapters your need to connect systems together.  Yep, one price, one SKU, for all the adapters you need.  No other competititor does this – each charging between 10-30k per adapter.  I love this because it means I don’t have to remember 16 different SKU names – I’m sure you’ll love this from a price perspective.  After a bunch of research we discontinued Partner edition – look for us to reinvent that as a much more targetted Express Edition in the next product cycle.  Another thing I like about our new licensing is that for standard edition the connection limit is gone and we support 2 CPUs; the key differentiator has always been failover in Enterprise edition so let’s keep it simple and just use that.  All those folks who have provided me with suggestions on pricing and licensing on my travels – I hope you are happy because this matches a lot of what you have been asking for!


If like me, you have been installing lots of different builds of SQL and VS.NET on your machine over the last year or two today is a great day.  Those products are done.  With BizTalk Server we are marching to Beta 2, RC, and RTM.  BizTalk Server 2006 will be the strongest quality release in our history and both SQL and VS.NET are better because of the joint work we did in terms of perf and stress testing the products.


P.S. If you attend a launch event (like the one I’m keynoting here in Detroit tommorrow) you get a free copy of BizTalk Server Developer Edition.

Transport-Level Correlation in BizTalk 2004/2006

This great post from Tomas on
receiving ack/nack notifications from the MSMQ[C] adapter prompted me to write up
something I had researched a few weeks back…

But first, a bit of background…

When doing work with message queueing systems, a very common (and well supported)
convention exists when two systems are exchanging messages: System ‘A’ sends a message
to System ‘B’.  When System ‘B’ wishes to reply, it uses the message identifier of
the ‘request’ message as the correlation identifier of the ‘reply’ message. 
The reply queue used is either well known by both parties, or is communicated
as a property on the request message.  For purposes of discussion, let’s call
this the “queueing contract”. 

Both MSMQ and MQSeries have MessageId and CorrelationId properties on messages. 
When looking at messages in a reply queue, System ‘A’ can peek at the messages, looking
for a particular CorrelationId prior to issuing a receive.  Alternatively, it
might use the CorrelationId as a look-up into working state of some sort. 
To facilitate request-response interactions, MQSeries has had a ReceiveByCorrelationId
API for a long while, whereas MSMQ added this in 3.0 (that is, on Windows XP and Windows
2003.) (Actual property and method names may vary in real life…)

There are, of course, many deployed systems in the wild that implement the queueing
contract – using both MSMQ and MQSeries.  You may find yourself needing to integrate
with these.  At first blush, it seems that consuming a service such as this should
be a breeze from within BizTalk orchestrations – after all, accomplishing
correlation is a first-class-citizen feature for BizTalk, so how tough can this
be?

Correlation in BizTalk is indeed a first-class citizen…for data within your
documents (or promoted message context.)  The classic example is to define
a property schema that embodies a business identifier like “PONumber”, and then visit
all schemas that will be used across a set of message interactions – promoting
the appropriate field in each as a “PONumber”.  Then, a correlation type
and correlation set are defined which reference that property, and Send
and Receive shapes are set to either initialize or follow the correlation as
appropriate.

The problem with an orchestration consuming the queuing contract we described
earlier is that this contract occurs at the transport layer.  To
be a consumer of the queueing contract, an orchestration would like to send a message,
and initialize a correlation based on the MessageId…but the MessageId is produced
further downstream, at the point an actual MSMQ or MQSeries message is generated by
an adapter.  Moreover, an orchestration would subsequently like to receive a
message, following an initialized correlation – but the CorrelationId isn’t promoted by
the MSMQ adapter (though it is for the MQSeries adapter…)

Solving for the MSMQ Adapter

The MSMQ Adapter gives us a small amount of help to get past this…We can
in fact do our initial send operation through a solicit-response port (rather than
a one-way port) and get back the MessageId that was generated by the adapter — it
actually comes back in a single-element document with a tag named “MSMQMsgId”. 
Starting here, the approach I took to solving the whole of the problem looked like
this:

  1. Send a message through a MSMQ solicit-response port.  The response operation
    in the orchestration designer can be of type “String”.

  2. On the response half of the solicit-response port, execute a pipeline & pipeline-component
    that extracts the returned MessageId and promotes it as the CorrelationId (using
    the standard MSMQ adapter namespace for that property.)  (For tracing purposes
    & useability, the MessageId is also returned in a <string> wrapper by the
    pipeline component rather than the native <MSMQMsgId> wrapper.)

  3. When the initial message (containing the correlation id in both content and context!)
    is received back into the orchestration, it is sent back out to initialize
    a correlation set (typed as MSMQ.CorrelationId.)  This Send shape is just a “dummy
    send”…it exists just to initialize the correlation, because that is the only means
    given to us in the orchestration world.  I used Patrick
    Wellink’s “NOPE” Adapter for this purpose, but there would be other
    options as well (including Tomas’
    Null Send Adapter
    , which I just recently rediscovered and which apparently performs
    better under load.)

  4. Next, we receive the “real” response message – following the correlation that was
    just initialized.  Because MSMQ.CorrelationId is not promoted by default,
    the response is brought through a second pipeline component that performs that service
    for us.

See the diagram below (and the downloadable
sample) for more detail. 

(click)

What can go wrong with this approach?  Well…there is race condition that can
occur if the “real” response message (step 4 above) arrives before steps 2 and 3 can
execute and establish the correlation (and associated instance subscription.) 
In other words, if the “real” response message comes back before the orchestration
has had a chance to express interest in that particular message, a routing failure
will occur.  This might be highly unlikely for your scenario (given response
times of the service you are interacting with) but it is something to test for, nonetheless. 
(With BizTalk 2006’s ability to route failed messages, you could potentially catch
and retry in this scenario…)

(Note – if you are going to rely on the technique in the sample, consider asking Microsoft
support for BizTalk 2004 QFE 1647, which addresses an issue with truncated correlation
identifiers being returned to BizTalk…)

Solving for the MQSeries Adapter

Consuming the queueing contract with the MQSeries adapter for BizTalk can be done
with a technique quite close to the one just discussed – but with a little less work.  The
response to the initial solicit-response interaction returns with MQMD_MsgID already
copied to a  MQSeries.BizTalk_CorrelationId property.  Likewise, the when
receiving the “real” response message, MQMD_CorrelationId is copied to the
MQSeries.BizTalk_CorrelationId property.  This means all correlation can be done
with this one property – no pipelines/pipeline-components are needed!

From the documentation:

(click)

(The “dummy send” – though not pictured – would be required here as well to initialize
the correlation set.)

In addition, there is a much cleaner solution that the BizTalk 2004
MQSeries adapter provides.  It turns out that MQSeries allows the “caller”
to assign the message ID (unlike MSMQ), so within BizTalk, you can in fact set
MQMD_MsgID and MQMD_CorrelationId to the same value prior to doing
your initial send.  Now, you can initialize a correlation set based on MQMD_CorrelationId
with the first outgoing message, and follow the correlation for the “real”
response message.  Slick!

From the documentation:

(click)

Solving for the MQSeries Adapter in BizTalk 2006

Ahhhh, here we have what looks like real simplicity…There is a new feature in the
BizTalk 2006 MQSeries adapter termed “Dynamic Receive” (referenced in the BizTalk
2006 Adapter Enhancements document.)  For a solicit-response port, Dynamic
Receive allows context properties on the outbound message to determine which server,
queue manager, and queue should be “watched” for the response message. 
This is used in conjunction with a “match” option – which allows you to wait for a
particular message based on CorrelationID (or any of several other properties, such
as MessageID, GroupID, SequenceNumber, Offset, or MsgToken…)

Not only does this give us quite a bit of flexiblity for where response messages
should be found (we don’t need a fixed receive location anymore) but it also elminates
the whole of the problem of implementing the “queueing” contract within orchestrations. 
With this feature in place, an orchestration simply uses one solicit-response
port, and the work is done.

Needless to say, it would be fantastic to get similar support from the MSMQ Adapter
(at least the ability to have a single solicit-response port with a similar “match”
criteria option, even without the dynamic receive location.)  But I don’t think
that is in the cards for BizTalk 2006…

Notes on the download:

  • See the BTMSMQCorrelation.PortBindings.xml file for the names of the two queues and
    two file directories that must be created for this sample.

  • Install Patrick
    Wellink’s “NOPE” Adapter or choose a different strategy for dummy sends
    (like Tomas’ Null Send
    Adapter.
    )

  • Use the included Deployment
    Framework-based deployment, or deploy manually.

  • To run, launch the “TestQueueServer” console app that will implement the queueing
    contract (request/response)

  • The sample will import and run just fine in BizTalk 2006, though you will have to
    deploy manually.  (Still working on the 2006 version of the deployment framework
    – more later…)

Hopefully this is helpful to those doing queueing work with BizTalk – enjoy!

>

Transport-Level Correlation in BizTalk 2004/2006

This great post from Tomas on
receiving ack/nack notifications from the MSMQ[C] adapter prompted me to write up
something I had researched a few weeks back…

But first, a bit of background…

When doing work with message queueing systems, a very common (and well supported)
convention exists when two systems are exchanging messages: System ‘A’ sends a message
to System ‘B’.  When System ‘B’ wishes to reply, it uses the message identifier of
the ‘request’ message as the correlation identifier of the ‘reply’ message. 
The reply queue used is either well known by both parties, or is communicated
as a property on the request message.  For purposes of discussion, let’s call
this the “queueing contract”. 

Both MSMQ and MQSeries have MessageId and CorrelationId properties on messages. 
When looking at messages in a reply queue, System ‘A’ can peek at the messages, looking
for a particular CorrelationId prior to issuing a receive.  Alternatively, it
might use the CorrelationId as a look-up into working state of some sort. 
To facilitate request-response interactions, MQSeries has had a ReceiveByCorrelationId
API for a long while, whereas MSMQ added this in 3.0 (that is, on Windows XP and Windows
2003.) (Actual property and method names may vary in real life…)

There are, of course, many deployed systems in the wild that implement the queueing
contract – using both MSMQ and MQSeries.  You may find yourself needing to integrate
with these.  At first blush, it seems that consuming a service such as this should
be a breeze from within BizTalk orchestrations – after all, accomplishing
correlation is a first-class-citizen feature for BizTalk, so how tough can this
be?

Correlation in BizTalk is indeed a first-class citizen…for data within your
documents (or promoted message context.)  The classic example is to define
a property schema that embodies a business identifier like “PONumber”, and then visit
all schemas that will be used across a set of message interactions – promoting
the appropriate field in each as a “PONumber”.  Then, a correlation type
and correlation set are defined which reference that property, and Send
and Receive shapes are set to either initialize or follow the correlation as
appropriate.

The problem with an orchestration consuming the queuing contract we described
earlier is that this contract occurs at the transport layer.  To
be a consumer of the queueing contract, an orchestration would like to send a message,
and initialize a correlation based on the MessageId…but the MessageId is produced
further downstream, at the point an actual MSMQ or MQSeries message is generated by
an adapter.  Moreover, an orchestration would subsequently like to receive a
message, following an initialized correlation – but the CorrelationId isn’t promoted by
the MSMQ adapter (though it is for the MQSeries adapter…)

Solving for the MSMQ Adapter

The MSMQ Adapter gives us a small amount of help to get past this…We can
in fact do our initial send operation through a solicit-response port (rather than
a one-way port) and get back the MessageId that was generated by the adapter — it
actually comes back in a single-element document with a tag named “MSMQMsgId”. 
Starting here, the approach I took to solving the whole of the problem looked like
this:

  1. Send a message through a MSMQ solicit-response port.  The response operation
    in the orchestration designer can be of type “String”.

  2. On the response half of the solicit-response port, execute a pipeline & pipeline-component
    that extracts the returned MessageId and promotes it as the CorrelationId (using
    the standard MSMQ adapter namespace for that property.)  (For tracing purposes
    & useability, the MessageId is also returned in a <string> wrapper by the
    pipeline component rather than the native <MSMQMsgId> wrapper.)

  3. When the initial message (containing the correlation id in both content and context!)
    is received back into the orchestration, it is sent back out to initialize
    a correlation set (typed as MSMQ.CorrelationId.)  This Send shape is just a “dummy
    send”…it exists just to initialize the correlation, because that is the only means
    given to us in the orchestration world.  I used Patrick
    Wellink’s “NOPE” Adapter for this purpose, but there would be other
    options as well (including Tomas’
    Null Send Adapter
    , which I just recently rediscovered and which apparently performs
    better under load.)

  4. Next, we receive the “real” response message – following the correlation that was
    just initialized.  Because MSMQ.CorrelationId is not promoted by default,
    the response is brought through a second pipeline component that performs that service
    for us.

See the diagram below (and the downloadable
sample) for more detail. 

(click)

What can go wrong with this approach?  Well…there is race condition that can
occur if the “real” response message (step 4 above) arrives before steps 2 and 3 can
execute and establish the correlation (and associated instance subscription.) 
In other words, if the “real” response message comes back before the orchestration
has had a chance to express interest in that particular message, a routing failure
will occur.  This might be highly unlikely for your scenario (given response
times of the service you are interacting with) but it is something to test for, nonetheless. 
(With BizTalk 2006’s ability to route failed messages, you could potentially catch
and retry in this scenario…)

(Note – if you are going to rely on the technique in the sample, consider asking Microsoft
support for BizTalk 2004 QFE 1647, which addresses an issue with truncated correlation
identifiers being returned to BizTalk…)

Solving for the MQSeries Adapter

Consuming the queueing contract with the MQSeries adapter for BizTalk can be done
with a technique quite close to the one just discussed – but with a little less work.  The
response to the initial solicit-response interaction returns with MQMD_MsgID already
copied to a  MQSeries.BizTalk_CorrelationId property.  Likewise, the when
receiving the “real” response message, MQMD_CorrelationId is copied to the
MQSeries.BizTalk_CorrelationId property.  This means all correlation can be done
with this one property – no pipelines/pipeline-components are needed!

From the documentation:

(click)

(The “dummy send” – though not pictured – would be required here as well to initialize
the correlation set.)

In addition, there is a much cleaner solution that the BizTalk 2004
MQSeries adapter provides.  It turns out that MQSeries allows the “caller”
to assign the message ID (unlike MSMQ), so within BizTalk, you can in fact set
MQMD_MsgID and MQMD_CorrelationId to the same value prior to doing
your initial send.  Now, you can initialize a correlation set based on MQMD_CorrelationId
with the first outgoing message, and follow the correlation for the “real”
response message.  Slick!

From the documentation:

(click)

Solving for the MQSeries Adapter in BizTalk 2006

Ahhhh, here we have what looks like real simplicity…There is a new feature in the
BizTalk 2006 MQSeries adapter termed “Dynamic Receive” (referenced in the BizTalk
2006 Adapter Enhancements document.)  For a solicit-response port, Dynamic
Receive allows context properties on the outbound message to determine which server,
queue manager, and queue should be “watched” for the response message. 
This is used in conjunction with a “match” option – which allows you to wait for a
particular message based on CorrelationID (or any of several other properties, such
as MessageID, GroupID, SequenceNumber, Offset, or MsgToken…)

Not only does this give us quite a bit of flexiblity for where response messages
should be found (we don’t need a fixed receive location anymore) but it also elminates
the whole of the problem of implementing the “queueing” contract within orchestrations. 
With this feature in place, an orchestration simply uses one solicit-response
port, and the work is done.

Needless to say, it would be fantastic to get similar support from the MSMQ Adapter
(at least the ability to have a single solicit-response port with a similar “match”
criteria option, even without the dynamic receive location.)  But I don’t think
that is in the cards for BizTalk 2006…

Notes on the download:

  • See the BTMSMQCorrelation.PortBindings.xml file for the names of the two queues and
    two file directories that must be created for this sample.

  • Install Patrick
    Wellink’s “NOPE” Adapter or choose a different strategy for dummy sends
    (like Tomas’ Null Send
    Adapter.
    )

  • Use the included Deployment
    Framework-based deployment, or deploy manually.

  • To run, launch the “TestQueueServer” console app that will implement the queueing
    contract (request/response)

  • The sample will import and run just fine in BizTalk 2006, though you will have to
    deploy manually.  (Still working on the 2006 version of the deployment framework
    – more later…)

Hopefully this is helpful to those doing queueing work with BizTalk – enjoy!

>

Connected Systems User Group Inaugural Meeting

Connected Systems Inaugural Meeting Date:   Tuesday November 15th, 2005 Time:   6:00 p.m. %u00e2%u0080%u0093 9:00 p.m. Place:  Microsoft Redmond Campus (Building:35, Room: Kalalach) Cost:    Free   Register for this event here!   The inaugural user group meeting will occur on Tuesday, November 15th, 2005 with Brennan and Brandon presenting on the purpose of the user group, meeting logistics, and schedule.  After the initial presentation, Scott Woodgate will present a technical overview of Microsoft BizTalk 2006.   Agenda 6:00 p.m.         Mixer. Time for food and refreshments. 6:30 p.m.         Welcome and announcements. 6:45 p.m.         Presentation: User group logistics 7:15 p.m.         Break 7:30 p.m.         Presentation: BizTalk 2006 Overview 8:45 p.m.         Closing Thoughts Presentations Meeting Part 1: NW Connected Systems User Group Introduction Since this is inaugural meeting for the user group, we would like to spend some time discussing the purpose of the user group, the schedule of events for the next few months, meeting logistics, and how user group participants can contribute.   Meeting Part 2: Microsoft BizTalk Server 2006 %u00e2%u0080%u0093 An Overview Microsoft BizTalk Server is an enterprise-level software offering that facilitates integration and automation of key systems with a business%u00e2%u0080%u0099 enterprise.  This presentation will introduce the BizTalk 2006 product, providing an overview of its many features, and detail how it fits within an organization%u00e2%u0080%u0099s existing architectural landscape.  This presentation will also touch on Microsoft%u00e2%u0080%u0099s Integration Technologies and what technologies to use when. Speakers Scott WoodgateGroup Product Manager, Connected System Division Marketing at Microsoft Corp         Scott Woodgate is a Group Product Manager in the Connected Systems Division. Over the last 5 years at Microsoft Scott has been deeply involved with BizTalk Server across many roles including technical product management, competitive analysis, and product planning. Today, he manages the technical product management team for the business process, integration and workflow technologies.  Scott has authored several books on BizTalk Server. Brennan O’ReillyEnterprise Architect/Managing Consultant, Interlink Group (ILG) Brennan O%u00e2%u0080%u0099Reilly is an Enterprise Architect with Interlink (www.ilg.com), where he’s fortunate enough to work with the finest delivery resources to ensure client satisfaction and engagement success. Brennan has extensive real-world experience architecting, developing and deploying Integration based solutions and has been working with BizTalk since its inception. Brennan is the co-founder of the NW Connected Services User Group and heads the Northwest chapter. Brennan can be contacted at Brennan.oreilly@ilg.com Brandon GrossEnterprise Architect/Managing Consultant, Interlink Group (ILG) Brandon Gross is also an Enterprise Architect with Interlink (www.ilg.com), where he too works with the finest delivery resources to ensure client satisfaction and engagement success.  Brandon has worked extensively with BizTalk 2000, 2002, and 2004, and other Microsoft integration technologies. Brandon is the co-founder of the NW Connected Services User Group, and may be contacted at Brandon@grosshousehold.com…