BizTalk Server 2006 provides a mechanism for generating property sheets for the adapter configuration user interface (UI). It is based on an XML Schema Definition (XSD) definition of the configuration properties. The use of this framework introduces significant challenges for the adapter developer. This section suggests an effective workaround for some of these issues.
It is impossible to put significant property validation on top of properties in the property sheet. The framework attempts to use XML Schema Definition (XSD) simpleType restrictions to define the validation rules for the UI. The simple rules for maximum and minimum value are applied but the regular expression restriction for string fields is not supported. Also, the data is converted into common language runtime (CLR) types before the restriction is applied. This means the user of the UI sometimes gets a cryptic type-conversion error rather than an out-of-range error. All in all, the validation logic is very weak.
The solution many adapter developers have adopted is to write custom property editors for the main properties on their property sheet. If there are a number of cross-dependent properties (as is often the case), then the custom property editor can combine the results into a single field and the runtime can later separate them. This is the only way to get the necessary (though still generally trivial) custom code into the interface.
Custom property editors are relatively straightforward to write and the property in the XSD can be annotated to use them. The annotation references an assembly that exposes the property editor entry point, and it is coded to show a CLR Form. You can now write a regular user interface and use the traditional interface-generation tools that Visual Studio offers.
The following code shows how to use the XSD to add a custom property editor:
<xs:element name="queueDetails" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<baf:designer>
<baf:displayname _locID="queueName">Queue Definition</baf:displayname>
<baf:description _locID="receiveQueueDesc">Details of MQSeries Server, Queue Manager and Queue from where you want to receive messages.</baf:description>
<baf:category _locID="mqsCategory">MQSeries</baf:category>
<baf:editor assembly="Microsoft.BizTalk Server.Adapter.MQSAdmin.dll">Microsoft.BizTalk Server.Adapter.MQSAdmin.MQSUITypeEditor</baf:editor>
</baf:designer>
</xs:appinfo>
</xs:annotation>
</xs:element>
The code that is referenced should look like this:
public class MQSUITypeEditor : System.Drawing.Design.UITypeEditor
{
public override System.Drawing.Design.UITypeEditorEditStyle GetEditStyle
(System.ComponentModel.ITypeDescriptorContext context)
{
return System.Drawing.Design.UITypeEditorEditStyle.Modal;
}
public override object EditValue (System.ComponentModel.ITypeDescriptorContext context,
System.IServiceProvider provider, object value)
{
Form qdForm = new QueueDefinitionForm(value);
IWindowsFormsEditorService service =
(IWindowsFormsEditorService)provider.GetService(typeof(IWindowsFormsEditorService));
DialogResult dialogResult = service.ShowDialog(qdForm);
//…
}
}
class QueueDefinitionForm : System.Windows.Forms.Form
{
// traditional UI code goes here!
}
The administration runtime must be able to find the assembly referenced in the XSD, so you should add it to the global assembly cache.