Biztalk ESB Toolkit - Itinerary Designer Model Importer

If you are already using the Biztalk ESB Toolkit and have version 1 (V1) itineraries (xml file) and want to create designer models from them, you may use this console application that will import your V1 itineraries and create the model file (.itinerary) along with the designer file (.itinerary.designer).

The usage is very straightforward. Just simple type in a command prompt:

ItineraryImporter.exe /i=someItinerary.xml

Notice that running the .exe without parameters will show up the help notes.

Here some implementation Notes:

1) This version only supports V1 itineraries (As you can see from the tests included in the source)

2) The model file (.itinerary) and diagram file (.diagram) are generated.

3) The Biztalk Application and Port settings in the On/Off ramps will be missing (not included in the itinerary xml file) so they will require manual setting after opening the generated model into the designer in VS.

    After settings these values the model should validate successfully.

Import considerations:

Since both OnRamp and OffRamp information and Send/Receive handlers are not persisted in the itinerary file, then some assumptions were made like the following:

1)      All messaging services will be set as “receiveInbound” (OnRamp – Receive Handlers) whenever they are located before an OffRamp Extender service.

            Otherwise they will be set as “sendTransmit” (OffRamp – Send Handlers).

2)      The criteria for creating an OffRamp extender service was to detect if the service name was included in one of the defined names in the ESB config file. (see “IsOffRampExtenderService” funtion in “Extenders.Importers.Common\ItineraryModelImporter.cs” file. So a message service with a name like “Microsoft.Practices.ESB.Services.Transform” or “Microsoft.Practices.ESB.Services.Routing” will be created as a Messaging service and another with a name like “DynamicTest” will be an OffRamp extender service.

3)      Any service created after an OffRamp extender will be placed between the OffRamp extender service and the OffRamp ESB service element.

In case of a Request/Response itinerary, the OffRamp service will be connected to the OnRamp service.

Notice that this strategy may not reflect in some scenarios the actual design of the itinerary because the services after OffRamp extender may be located after the OffRamp service as a “sendInbound” (OffRamp – Receive Handlers).

In this case a manual update may be required after model creation. 

However, if this is not done, the same itinerary as the original will be exported back from VS so a safe round tripping will be honored. 

You can download it from here (Binary and Source included): Download.