Migration Guidance for the WF Developer (Beta 1 – Part 2)

About six weeks ago, the WF team published up the first four WF3->WF4 migration guidance documents, aimed at helping WF developers prepare and think about the new WF object model runtime.

Today, we published the next three documents in the series to the WF4 Migration Guidance document set. With today’s release, we begin moving from the general guidance and start to present cookbook material, addressing more specific scenarios and presenting code.

  • WF Migration Overview (Already Live)
    Overview of the document collection and an initial starting place for the WF3 developer
  • WF Migration: Best Practices for WF3 Development (Already Live)
    How to design WF3 artifacts so they are more easily migratable to WF4
  • WF Guidance: Rules (Already Live)
    Discussion of how to bring rules-related investments forward into .NET 4
  • WF Guidance: State Machine (Already Live)
    Discussion of WF4 control flow modeling in the absence of a StateMachine activity
  • WF Migration Cookbook: Custom Activities (Now Live!)
    Examples and instructions for redesigning WF3 custom activities on WF4
  • WF Migration Cookbook: Workflows (Now Live!)
    Examples and instructions for redesigning WF3 workflows on WF4
  • WF Migration Cookbook: Workflow Services (Now Live!)
    Examples and instructions for redesigning WF3 workflow services on WF4
  • WF Migration Cookbook: Advanced Custom Activities (Coming Soon)
    Examples and instructions for redesigning advanced WF3 custom activities on WF4

As I mentioned in the last post about the documents, these documents are initial draft releases that the team is releasing to you. For these, they are all written for the object model and features that are part of Beta 1. We will be updating the documents as additional releases of .NET 4 are publicly released, and the documents will address further scenarios with each release.

Also – again – the team will be supporting feedback and requests for the documents and accompanying sample code in the WF 4 forum on MSDN.

Happy reading!
Cliff

Issues with BizTalk 2009 on VS.NET 2008

Hi all

I have been running into too many issues with BizTalk 2009 on VS.NET 2008 lately.
This post is just to mention them and let everyone else know that they are not the
only one – and that they will be reported to MS and hopefully fixed quickly.

Build action of schemas

Some times the “build action” of a schema in your BizTalk project is set
to “None” instead of “BtsCompile”. When this happens, the schema is not compiled into
the assembly and can therefore not be used for pipeline components, maps, orchestration
messages, and so on. It happens if you drag a schema from your explorer into your
project, but it also happens sometimes when you drag a schema between two projects
inside VS.NET.

More build action of schemas

The above error could be more easy to live with, if it weren’t absolutely
impossible to know when the “Build action” property of the schema in visible in VS.NET
– some times the property is visible and you can change the value. Other times it
is not. Quite confusing. I have found that if I add a schema to a project, then the
property is suddenly visible for all schemas in the project. Change the ones that
need changing and delete the schema you added.

Auto save a map before schemas are chosen

When you add a new map then at some point VS.NET auto saves the map, but
if this happens before you have chosen both the source and destination schema you
suddenly get an error, which you really do not expect, because you weren’t doing anything
at the time of the error. This also occurred in previous versions of BizTalk.

Map looses information about schemas

I have seen several times, that even after choosing source- and destination
schema for a map and dragging a couple of links in the map and saving it, then at
compile time, I get an error about the map not having source- and destination schemas.
So I need to choose them again, and redo all the links, because they have magically
disappeared. This happens for maps that uses both schemas from the same project as
schemas from referenced projects.

Output window

The output window seems to not always show all information when compiling/deploying.
Some times the information comes all at the end instead of being written to the output
windows as it happens. Other times, I can rebuild my entire solution and the output
windows will only show me the one warning that occurred during compilation.

Dragging elements in Schema Editor

Dragging elements inside the schema editor has had me baffled since BizTalk
2002. Some times, I need more than 20 tries to get an element to be dragged – and
sometimes it just works. Annoying? Indeed it is!

Copy local fails

If I have a project (P2) that references another project (P1), then after
I have added an item to P1 and recompiled it, everything seems OK. BUT, if I then
deploy from within V.NET, things start to go wrong. From then on, it seems that the
“Copy local” property of the project reference is ignored. Whenever I recompile P2,
I do NOT get the P1.dll copied to the local folder of P2. This causes all sorts of
stuff as also explained here by Ryan: http://dotnet.org.za/ryancrawcour/archive/2009/07/17/biztalk-2009-amp-visual-studio-2008-annoyance-2.aspx

Setting properties for more than one project at the same time

See here: http://dotnet.org.za/ryancrawcour/archive/2009/07/15/biztalk-2009-feature-missing.aspx for
Ryans thoughts on this.



eliasen

WSE, DIME; WCF, MTOM; OH My!

I was recently working on a proof of concept where we needed to interface to a repository that returned the documents using DIME attachments.  I don’t know if you have had the ‘opportunity’ to work with DIME attachments before but there isn’t much that still supports that format.  Since the manufacturer of the repository wasn’t upgrading their software to take advantage of the new MTOM format we needed to consume the DIME attachments and convert them to MTOM attachments through an exposed WCF end point.

 


My client was putting this service on their ESB, which was built using BizTalk, and we utilized the WSE 2.0 extensions (yes, you can still download them) for the DIME support.


 


To do this we downloaded the WSE extensions and created a class that we would call from within our Orchestration.  We added a Web Reference to point to the web service of the repository.  We then replaced the default inherited class in the proxy with the WSE class, Microsoft.Web.Services2.WebServicesClientProtocol.  At this point we were ready to start writing code to consume the attachments.


In the code below, we loop through the attachments in the ResponseSoapContext and then load them into a stream object.  We then used the Convert class to convert the byte array to the properly converted Base64String and placed that as the value of the Attachment node.  The schema node’s data type in the schema in BizTalk for the attachment is set to Base64Binary.  The best part about this whole POC is that by putting our attachment in the Base64Binary data type, all that we need to do is set the encoding on the WCF adapter to MTOM and BizTalk will do all the MTOM work for us.  Also in the code below, you will notice that we used Linq to XML.  The great part of POC’s is that you can play with the new technology and in this case see just how easy it is to put together the XML message.  Even though we were playing with Linq, I still needed to pass back an XML Document for the Orchestration to consume.


 


using System;
using
System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Drawing;
using System.Xml.Linq;
using Microsoft.Web.Services2.Dime;
using System.IO;
using
System.Xml.Serialization;
using System.Xml;

namespace OrchestrationHelper
{
   
[Serializable]
    public class OrchestrationHelperWrapper
    {
        MyService.Service svc = new MyService.Service();

       
public XmlDocument RetrieveAttachment(int token, string name)
        {
            XElement xmlTree = null;

           
int iResult = svc.RetrieveFile(token, name);
           
XElement myNode;

            if (iResult == 0)  //0 = successful retrieve

                {
                    if (svc.ResponseSoapContext.Attachments.Count > 0)
                    {
                        XNamespace ns = “http://POC.DimeReturnSchema”;
                        xmlTree = new XElement(ns + “ReturnedAttachments”);
                        XElement xmlAttachments = new XElement(“Attachments”);
                        xmlTree.Add(xmlAttachments);
                        for (int index = 0; index < svc.ResponseSoapContext.Attachments.Count; index++)
                        {
                            Stream myStream = svc.ResponseSoapContext.Attachments[index].Stream;
                            int length = (int)myStream.Length;
                            
                            byte[] bytes = new byte[length];
                            myStream.Read(bytes, 0, length);
 
                            myNode = new XElement(“Attachment”, Convert.ToBase64String(bytes));
                            xmlAttachments.Add(myNode);
                        }
                    }
                }
 
                XmlDocument xdoc = new XmlDocument();
                xdoc.LoadXml(xmlTree.ToString());

                return xdoc;
        }
    }
}


Back in BizTalk, in our Orchestration, we called the OrchestrationHelper through the ConstructMessage shape and assigned the returned Xml Document to the Orchestration Message.  We created a WCF endpoint and selected Mtom encoding on the Binding tab of the WCF Transport Properties dialog.


 


The best part is that BizTalk automatically encoded anything that was set to Base64Binary to the MTOM format and it can all be done through configuration in the WCF adapter settings.  All that we needed to do was to consume the DIME attachment and place it in an element with the right data type.

ESB Toolkit How To Video #5: Including Custom Orchestrations in Itineraries

Update: Sorry folks, the first link I posted for the video was incorrect. I have updated it now:

Welcome to #5 in my series of ESB Toolkit How To Videos. If you have not seen the previous videos, I encourage you to do so. The previous ones can be found here

1) Basic Itinerary Routing and UDDI Integration

2) Composite Itinerary and Dynamic Mapping

3) Itinerary Resolution in the Bus

4) Dynamic Itinerary Resolution in the Bus

One of the great things about the ESB Toolkit is that it can be extended in a large number of ways. One of the common ways that developers will want to extend it, is to create custom BizTalk orchestrations that can be included within an ESB itinerary. With the default install of the Toolkit, you have access to two orchestration. The generic routing orch and the generic mapping orch. In this video, I’ll show you how to create a new orchestration and then register it with the ESB so that you can access it from the itinerary designer and create an itinerary that will route messages to it.

The video can be accessed here

Cheers and keep on BizTalking…

Peter

Litware Training sample Mashup app

We’ve all heard of a "mashup" because its one of those buzz words, like "Web 2.0", that is picked up and repeated over and over again by the journalists and analysts.  But have you actually seen one up close in the wild?  Or do you have suspicions that its an elusive beast or a myth like Big Foot or Nessie?  Well, we’ve got one of these critters in captivity for you to take home as a pet.  Play with it.  Get comfortable.  See what makes it tick.  See what tools from Microsoft are useful in building a mashup. And see if this programming style applies to something you want to do with your next application.

Litware Training is a sample "mashup" app built using ASP.NET and the WCF REST Starter Kit Preview 2. It demonstrates how to build a Web 2.0 application, tapping into popular search, geographic information, and social networking APIs on the internet. It shows how to consume and expose RESTful services.

Thanks to Ben Dewey of twentysix New York who built the sample.