Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Extending the Itinerary Designer

The Itinerary Designer is a visual domain-specific language (DSL) for Microsoft Visual Studio that enables the graphical modeling of itineraries for use with the ​Microsoft BizTalk ESB Toolkit. The designer exposes various extension points for which developers can write custom extensions to enable new functionality and/or new configuration options.

The Itinerary Designer can be extended in the following ways:

Creating a Custom Itinerary Exporter

The architecture of the Itinerary Designer allows for the creation of custom model exporters that serialize and persist the data in an Itinerary model.

Creating a Custom Extender for a Messaging Service

The architecture of the Itinerary Designer allows you to create custom extenders for Itinerary Service model elements that can be used to add properties to the property bag for use by Messaging Services.

For a sample of how to create such an extender, see Installing and Running the Designer Extensibility Sample.

Creating a Custom Extender for an Orchestration-Based Itinerary Service

The architecture of the Itinerary Designer allows you to create custom extenders for Itinerary Service model elements that can be used to add properties to the property bag for use by orchestration-based itinerary services.

For a sample of how to create such an extender, see Installing and Running the Designer Extensibility Sample.

Creating a Custom Resolver Extender

The architecture of the Itinerary Designer allows you to create custom extenders for the configuration of custom resolvers. These extenders provide a graphical interface for configuring the name-value pairs in the resolver connection string, which map to properties in the specific resolver extender class.

For a sample of how to create such an extender, see Installing and Running the Designer Extensibility Sample.

Creating a Manifest File for Custom Adapter Properties

When creating a custom adapter provider, you must also provide designer support for the adapter provider to those resolver extenders that display an endpoint configuration property. To enable designer support, it is necessary to create an adapter provider manifest file.

The adapter provider manifest file defines the properties associated with a specific adapter provider, their types, descriptions, and the assembly in which they can be found. These manifest files should be placed in the same folder as the Itinerary Designer binaries (for example, Microsoft.Practices.Itineary.DslPackage.dll) with a unique name (for example, FTPPropertyManifest.xml).

The following is a reference instance of an adapter provider manifest file; custom manifest files should be structured likewise.

<?xml version="1.0" encoding="utf-8" ?>
<adapterPropertyManifest adapterName="FTP">
     <aliases>
          <alias name="globalPropertySchemas" value="Microsoft.BizTalk.GlobalPropertySchemas, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
     </aliases>
     <properties>
          <property name="UserName" type="FTP.UserName" description="The user name for the connection." encrypted="true" assembly="globalPropertySchemas" />
          <property name="Password" type="FTP.Password" description="The password for the conection." encrypted="true" assembly="globalPropertySchemas" />
          <property name="MaxConnections" type="FTP.MaxConnections" description="The maximun number of connections." assembly="globalPropertySchemas" />
          <property name="EventArgs" type="System.EventArgs" assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
     </properties>
</adapterPropertyManifest>

Creating a Custom Filter Extender

The architecture of the Itinerary Designer allows you to create custom extenders for the configuration of custom filters. These extenders provide a graphical interface for configuring the name-value pairs in the filter connection string, which map to properties in the specific filter extender class.

  • /Samples/Designer Extensibility Samples/Extenders.Itinerary.OrchestrationSample/Extenders.Itinerary.OrchestrationSample/Extenders.Itinerary.OrchestrationSample

  • /Samples/Designer Extensibility Samples/Extenders.Resolvers.ResolverSample/Extenders.Resolvers.ResolverSample

Creating Custom Validation Rules

The last significant extension introduced by the Itinerary Designer is a validation mechanism that allows you to externally, with respect to a domain-specific language (DSL), specify and implement the model validation rules. The mechanism "hooks into" the DSL validation framework and is activated when the user clicks Validate or Validate all on the shortcut menu of a model. This invokes the DSL framework's DslCommandSet object that, in turn, calls the validation engine in the Itinerary Designer.

The ValidationEngine class performs the model element validation using the Enterprise Library Validation Application Block and logs the validation errors to the Error List window in Microsoft Visual Studio IDE. The validation that should be performed for each type of element in a model is defined in the Enterprise Library configuration file. The file is named Ruleset.config and is located in the binary folder where all the Itinerary Designer binaries are located. The following example is a fragment of the configuration file and includes two validation rules (named validators) for the UddiResolver extender, one for the ServerUrl property and one for the ServiceKey property.

<!-- 
UddiResolver
-->
<type assemblyName="Microsoft.Practices.Services.Extenders.Resolvers.UDDI"
 name="Microsoft.Practices.Services.Extenders.Resolvers.UDDI.UddiResolver">
<ruleset name="Menu">
<properties>
<property name="ServerUrl">
<validator type="Microsoft.Practices.Modeling.Validation.NotEmptyStringValidator, Microsoft.Practices.Modeling.Validation"
          messageTemplate="The '{1}' property value should not be empty or null."
          name="UddiResolver.ServerUrl not null validator"/>
</property>
<property name="ServiceKey">
<validator type="Microsoft.Practices.Modeling.Validation.NotEmptyStringValidator, Microsoft.Practices.Modeling.Validation"
          messageTemplate="The '{1}' property value should not be empty or null."
          name="UddiResolver.ServiceKey not null validator"/>
</property>
</properties>
</ruleset>
</type>

Each rule identifies the validator that implements the rule. The Itinerary Designer comes with a large set of validator classes. They are all in the Microsoft.Practices.Modeling.Validation project in the Designer binary folder.

The final result of using this validation mechanism is that Itinerary Designer users can modify how the models are validated by changing the provided rules and validators or by adding their own rules and validators. This can be done without opening, modifying, rebuilding, and re-deploying the DSLs by performing the following two steps:

  1. Create a validator class and put it in a library inside the binary folder where the Microsoft.Practices.Modeling.Validation.dll library is located.

  2. Add entries to the Rules.config file to define what property of what model element class the validator should be applied.

© 2014 Microsoft Corporation. All rights reserved.
Show:
© 2015 Microsoft