Upgrading from BT’04 GotDotNet WSS Adapter 1.0 to BT’06 native WSS Adapter

by community-syndication | Mar 28, 2006 | BizTalk Community Blogs via Syndication

I finally found some time and tried upgrading from BizTalk 2004 and GotDotNet WSS adapter to BizTalk 2006 and the native BT’06 adapter for Windows SharePoint Services. The idea was to start from a BizTalk 2004 installation with version 1.0 of Steve Resnick & Co. WSS Adapter (http://www.gotdotnet.com/workspaces/workspace.aspx?id=0d1aa85c-cf8d-497e-84f4-3ffec8db115f) , setup a simple messaging scenario using SharePoint, upgrade to BizTalk 2006, verify that messaging still works, upgrade to the native BizTalk 2006 WSS Adapter and then verify that messaging works with the new adapter.

I followed the steps below, in order to create a sample messaging test for SharePoint:

1. Created Source document library, then renamed it SourceDocLib (this trick causes the document library URL and the document library name to be different and this way I can see if WSSLib adapter really expects the URL or the display name of the document library). Created a View named ’UpgradeDocuments’ that shows only those documents with ID >= 0 (probably all docs).
   
   
2. Created document library named ‘Destination’, then renamed it to ‘DestinationDocLib’. Created folder ’Dest Folder’. Added columns SharePointColumn1, and SharePointColumn2.
   
   
3. Created document library named ‘Archive’, then renamed it to ‘ArchiveDocLib’. Created ’My Folder’ folder in the library just created.
   
   
4. Created receive port and receive location for WSSLib adapter. Used all the fields available in order to make sure that similar field exists in native BT’06 adapter.
   
   
5. Created send port for WSSLib adapter, used all the fields.
   (See the exported bindings or the UI captures below to see how the ports were configured. If you want to repro my test, after importing the bindings, you will have to update the filter on the send port to process messages received from the receive location by adding BTS.ReceivePortName == WSSLib-Receive condition. Only then start the send port.)
   
   
6. Sent test messages (see attached).
   
   
7. Exported all bindings.

See images below for the receive location and send port settings:

Once I configured the messaging I’ve sent a couple of messages through (see attached) to make sure that everything is working fine.

UPGRADE

I followed these steps http://geekswithblogs.net/darko/archive/2006/01/24/66866.aspx in order to upgrade to BizTalk 2006. The upgrade went through without problems. Another place where you can find upgrade information is this blog http://blogs.msdn.com/biztalk_upgrade/default.aspx Because my BizTalk 2004 installation had the BAS feature installed, after upgrade, both BAS and Windows SharePoint Services Adapter Web Service features were installed on the machine (even though the latter does not show up as enabled in setup, it’s there because BAS requires it). If your BizTalk 2004 installation didn’t have BAS, after upgrading your SharePoint box, you will have to start setup, add Windows SharePoint Services Adapter Web Service feature, and configure it. That’s easy and straight forward so I won’t go into details.

After upgrade, I browsed to the BAS site (SharePoint site) to see if SharePoint was still working fine and it didn’t. I received the following error:
This Windows SharePoint Services virtual server has not been configured for use with ASP.NET 2.0.50727.42. For more information, please refer to Knowledge Base article 894903 at http://go.microsoft.com/fwlink/?LinkId=42660.

Troubleshoot issues with Windows SharePoint Services

The KB article just tells you to run one command. I run the command below:

stsadm.exe -o upgrade -forceupgrade -url http://demoappserver/sites/BASSite

restarted IIS and after that the BAS site shown up without problems. I started the BizTalk services that I stopped during upgrade, sent a few SharePoint messages through and everything worked fine.

Updating the ports

So I proceeded to update the receive location and send port in order to change from WSSLib adapter to ‘Windows SharePoint Services’ adapter. First thing I did, was to stop the BizTalk Host Instances that were used by the WSSLib adapter. This is probably not necessary, but in a couple of cases I noticed that the WSSLib ports don’t shutdown appropriately and I didn’t want to run into issues. After that, for each of the receive location or send port I changed the ‘Transport Type’ property from ‘WSSLib’ to ‘Windows SharePoint Services’ and then re-configured the send port/receive location like below.

Once I updated all the send ports and receive locations, I re-started the host instances, and sent a few messages through. All the messages were processed correctly in the same manner as before and this concluded my upgrade experience. Please notice that my upgrade test was done using version 1.0 of the WSSLib adapter. On GotDotNet there is an RC for the WSSLib adapter version 2.0. A comparision of that WSSLib2 adapter and BizTalk 2006 native ‘Windows SharePoint Services’ adapter can be found here http://blogs.msdn.com/ahamza/archive/2005/07/27/BizTalk2006WSSAdapters.aspx The only feature supported by WSSLib2 that is not available in the native BT’06 adapter is storing the Username/Password in SSO per send port/receive location. The native BT’06 adapter uses the identity of the host instance to connect and authenticate with SharePoint. Upgrade from WSSLib2 to BT’06 native WSS Adapter should be just as straight forward.

Regardless of the adapter version from which you are upgrading, if you are using some of the adapter context properties in your orchestrations you will have to update your orchestrations to use the WSS.* context properties and that will require you to recompile and redeploy your orchestrations.

BizTalk Server 2006 Installation Guides and Tutorials

by community-syndication | Mar 28, 2006 | BizTalk Community Blogs via Syndication

BizTalk Server 2006 RTM Now Available on MSDN

by community-syndication | Mar 28, 2006 | BizTalk Community Blogs via Syndication

Very good news !!!

BizTalk Server 2006 is now available for download on the MSDN Subscribers Download site!

Also available are the SWIFT, RosettaNet, HL7, and HIPPA Accelerators as well as the Enterprise Application Adapters.

Flat File Debatching in BTS 2006 – Part II

by community-syndication | Mar 28, 2006 | BizTalk Community Blogs via Syndication

In earlier part I, we checked out the Customers Record and child elements creation.Lets see how we can create Items and Item fields in the purchaseorder.xsd using Flat File schema wizard.
Lets continue with the wizard:
1. Now we can see the schema with fields under Customers record as below:
                                        
2. Now select Items and click Next.
3. […]

BisTalk Server 2006 Released Today!

by community-syndication | Mar 27, 2006 | BizTalk Community Blogs via Syndication

You probably know this already. You can find an overview of BizTalk Server 2006 features here . Now that BizTalk 2006 is released, I can speak a little more freely about the product. You can use the “Contact” link to suggest topics you’d like me to shed…(read more)

Performance Testing at MS DAY 1

by community-syndication | Mar 27, 2006 | BizTalk Community Blogs via Syndication

During the afternoon we tested each of the 3 designs against a standard “out of the box” config – this ran on a single 4-way biztalk box and a super fast sql box. As a recap, the following are the designs

Async Design – designed to return processing to the payment flow asap, by launching the final accounting writes and summarisation as an async orchestration.

All in one – this design complete the entire process in a single synchronous orchestration – all processing is completed before returning to the payment flow.

Dispatch Message – this design completes the final accounting in a similar way to the Async design, but rather than call the orchestration using a “start”, a message is dispatched as a trigger.

Our initial tests were all based around 10,000 payments in a single file, on a single biztalk box. A harness was built around BAM to extract timings based on the number of accounting message posted between the first payment BAM activity and the last accounting BAM activity being written. This benchmark takes out the “loading” of the messagebox with the payment messages and so gives us a purer “throughput” figure (it also took account of the buffered BAM writing)

During the day we saw a number of problems with rules engines timeouts. Config changes were made to increase translation timeouts and also increase the rules policy cache. We also made some changes to the code that instantiates and executes the policy to improve its use of the cache – this improved performance. We saw significant troughs of performance during what looked like the rules loading. Darren took a number of dumps and these were sent to the US to review.

Our day 1 tests started on 1 box showed performance ranging from 28 to 120 accounting entries per second. The best performing design was the “all in one” at this point, with 120 aeps (accounting entries per second) on a singe box and 169 on a two box config.

Overview of deliverables for ESB project

by community-syndication | Mar 27, 2006 | BizTalk Community Blogs via Syndication

When I first arrived onsite, I was coming in cold. I knew what the consensus opinion was of what an ESB is, but I knew nothing about what the actual requirements were, nor functionality or delivery plans. I stepped into a large project, however my part of it was a blank slate. The infrastructure was being laid down (a very lengthy process as it is a complex environment, both technically and from an organizational perspective), but beyond what was done in the Proof of Concept that turned this into a BizTalk project, there was no code or finalized designs.

Perfect: just the way I like it!

So, the first thing we needed to do was explore requirements and define the scope.  I’m a firm believer in iterative development with phased deliverables, as are the client’s personnel, so that’s the approach we are taking for what will likely be a very long-term project.

After discovery, our list of deliverables breaks down as shown below.

What we are calling the “ESB Core Engine” will provide:

• Dynamic routing – the ability for a message entering the ESB to be routed to an endpoint. This could be a protocol hop, or to an application


• Dynamic transformation – the ability to dynamically transform a document from one type to another (think BizTalk mapper, but dynamic application of maps)


• Exception management – a standardized and common way to surface and handle exceptions

Beyond the core functionality, additional capabilities will be:

• JMS pipeline component (for JMS header promotion and full fidelity preservation of JMS headers as a message passes through BizTalk)


• “Heartbeat” service that can be used for interop testing

This is not a case of “if you build it they will come”, so to accelerate getting developers up to speed, we will include an SDK, which will contain:

• Code samples (for consistency, these will look and feel like the BizTalk SDK samples)


• Documentation, “A Developer’s Guide to the ESB Core Engine”

From an admin/operations perspective, we will have two additional pieces (after Iteration 1):

• Provisioning tool – defines the “on-ramps” and “off-ramps” into the ESB, the message receipt points


• Engine Central (still looking for a better name here J) – a portal that allows ESB administrators to see metrics about engine performance and ESB usage patterns. We may (or may not) also opt to include some kind of self-provisioning here. This piece is a bit fuzzy at the time this was written, as we have a few possible approaches, and just need some time to think it through further. I will elaborate later, but this could become a core piece of the puzzle.

There will be phased deliveries within each of those areas. There will almost certainly be additional areas in the future, but for now, I’m happy with the mix and feel it will provide the infrastructure we need to facilitate interop between the 1,700 applications running in this enterprise.

On a side note: I recently saw an “ESB vendor” (remember, so companies would have you believe that an ESB is a product) proudly proclaiming that their ESB consists of 144 “pieces”. As impressive as that number sounds (no doubt one of the competing vendors will come out with one that has 150 pieces!), I’m a minimalist and prefer the “keep it simple” approach. The technology stack that we will be using is:

• BizTalk Server 2004 (switching to 2006 as soon as we can)


• SQL Server 2000

<LI class=MsoNormal style="MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo2; tab-stops: l

BizTalk Server 2006 has RTM’d

by community-syndication | Mar 27, 2006 | BizTalk Community Blogs via Syndication

BizTalk Server 2006 has RTM’d today … best BizTalk ever, shipped on time and a very high quality server product. See the announcement here.

http://www.computerworld.com/softwaretopics/software/story/0,10801,109944,00.html

Of course, my favorite BT’06 features are are WSS Adapter, BAS and BAM … because my colleagues and I worked on many of these features … 😉

I’ve been working in BizTalk team for 4 years now, this is my second BizTalk release, and I really like the things that I do here. The product and the people are great, there are MANY great opportunities, the mix of technologies that we use or develop is exciting and challenging. This is one of the best places to be at Microsoft. If you are interested, check this post on how to get your resume posted and join the team http://blogs.msdn.com/biztalk_server_team_blog/archive/2006/03/21/556067.aspx
Normally, I would get borred working on the same product for 4 years, but that was not the case with this product. I decided to stay with the BizTalk team and work on the next version of BizTalk that should be even better. However, I will change teams inside BizTalk, I am moving to the engine/message box team. I have admired the work they’ve done for quite a while now and that seems to be the right place for me going forward.

If you haven’t done this already, take a look at the latest BizTalk release here http://www.microsoft.com/biztalk/default.mspx

BizTalk 2006 RTM ready for Download

by community-syndication | Mar 27, 2006 | BizTalk Community Blogs via Syndication

The RTM version of BizTalk 2006 is now available for download on MSDN.
Read more about the RTM version Here and Here.