Microsoft has released the much talked about version of BizTalk Server 2009 (previously known as BizTalk Server 2006 R3) for MSDN subscribers on friday.
The following are the different versions available on MSDN:
BizTalk Server 2009 Branch Edition (x86) – DVD (English)
BizTalk Server 2009 Developer Edition (x86) – DVD (English)
BizTalk Server 2009 Enterprise Edition (x86) – DVD […]
I ran into an issue working with the AWESOME MUrl sample trying to reach Twitter from inside Intellipad (running in “MUrl mode”). I’m doing this post for the benefit of others that may run also into this, there are actually two solutions
If you haven’t seen MUrl in action, please see my previous post about it and do check it out. Bottom line is that the sample is a DSL (written in “M” of course) for doing REST client requests, and “MUrl mode” lets you do those requests right from inside Intellipad. Super cool
Where I ran into an issue was that although I was able to query Twitter no problem with MUrl from Intellipad, when I tried posting I would get an “Expectation Failed” error message. I was somewhat amused that somehow it seemed that I was not living up to some service’s expectations 🙂 but mostly I was annoyed that I could not do this. After a bit of looking around, I found this post that explained what was going on.
I made the code change to the MUrlRuntime.cs file as shown below:
Alternatively, you could make the equivalent change by adding this to the ipad.exe.config:
<system.net>
<settings>
<servicePointManager expect100Continue=”false” />
</settings>
</system.net>
(for the benefit of people using search engines, other text in the error message was “Expect: 100-continue”, and some text from Twitter saying “we only allow the 100-continue expectation”)
The pre-requisites CAB files available at the moment for BizTalk 2009 on Windows Server 2008 are:
32bit: http://go.microsoft.com/fwlink/?LinkId=81432
64bit: http://go.microsoft.com/fwlink/?LinkId=81423
These CAB files have version 8.0 of ADOMD.NET in them. If you run into a problem with the RTM version of BizTalk 09 asking for version 10 of ADOMD.NET, you can download […]
This week I spend some time on writing a functoid that retrieves the value of a variable in an orchestration. Lets take a look on the functoid’s usage first.
Usage
This is the declaration of a string variable ‘lastName’ in a very simple test orchestration:
This is the expression shape where the value of that variable is set […]
[Source: http://geekswithblogs.net/EltonStoneman]
The WCF message formatter interfaces IClientMessageFormatter and IDispatchMessageFormatter let you intercept WCF messages on the client or service side at the point of serialization and deserialization. They’re useful injection points as they give you access to the input or output parameter values of the service call, and to the incoming or outgoing WCF Message object. The formatters allow you to inspect or modify the message content or headers, using the call parameters to drive your logic.
Formatters need to be applied as operation behaviors, so there’s no direct way to add them via binding configurations – typically they’re added programmatically to the client channel, or to the service as attributes on the operation contract. But if your requirements are to add the same formatter to every operation and you want the flexibility of the configuration model, you can add formatters by piggybacking onto other behaviors which can be specified in configuration – IEndpointBehavior on the client and IServiceBehavior on the service:
(more detail on the data signature project in a future post).
Client Side
DataSignatureOperationBehavior.ApplyClientBehavior adds a DataSignatureClientFormatter to a single client operation:
public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
{
DataSignatureClientFormatter formatter = new DataSignatureClientFormatter();
formatter.OrginalFormatter = clientOperation.Formatter;
clientOperation.Formatter = formatter;
}
Adding the formatter to one operation cannot be specified in client-side configuration. However the DataSignatureOperationBehavior can be added to every client operation in an endpoint using IEndpointBehavior.ApplyClientBehavior. DataSignatureEndpointBehavior adds the client formatter to every operation, by using the existing operation behavior:
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
foreach (OperationDescription operation in endpoint.Contract.Operations)
{
operation.Behaviors.Add(new DataSignatureOperationBehavior());
}
}
The endpoint behavior is exposed in the client configuration mode by extending BehaviorExtensionElement, so the DataSignatureFormatter can be added to every operation in an endpoint by configuring the DataSignatureEndpointBehavior:
<client>
<endpoint address=“http://localhost/x.y.z.svc”
binding=“basicHttpBinding“ bindingConfiguration=“BasicHttpBinding_ICustomerService“
behaviorConfiguration=“dataSignatureBehavior“
contract=“CustomerService.ICustomerService“ name=“BasicHttpBinding_ICustomerService“ />
</client>
<behaviors>
<endpointBehaviors>
<behavior name=“dataSignatureBehavior“>
<dataSignatureBehavior />
</behavior>
</endpointBehaviors>
</behaviors>
<extensions>
<behaviorExtensions>
<add
name=“dataSignatureBehavior”
type=“Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureEndpointBehavior/>
</behaviorExtensions>
</extensions>
Service Side
The service stack is the parallel of the client side – DataSignatureDispatchFormatter is added via an operation behavior using DataSignatureOperationBehavior.ApplyDispatchBehavior:
public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
{
DataSignatureDispatchFormatter formatter = new DataSignatureDispatchFormatter();
formatter.OrginalFormatter = dispatchOperation.Formatter;
dispatchOperation.Formatter = formatter;
}
Again this behavior is not available in the service configuration model, but it can be added to every operation in the service using IServiceBehavior.ApplyDispatchBehavior, as is done in DataSignatureServiceBehavior:
public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
{
foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
{
foreach (OperationDescription operation in endpoint.Contract.Operations)
{
operation.Behaviors.Add(new DataSignatureOperationBehavior());
}
}
}
This behavior also extends BehaviorExtensionElement so it can be configured, adding the dispatch formatter will be added to every operation in the service:
<services>
<service behaviorConfiguration=“dataSignatureBehavior”
name=“Sixeyed.OptimisticLockingSample.Services.CustomerService“>
<endpoint address=“” binding=“basicHttpBinding“ contract=“Sixeyed.OptimisticLockingSample.Services.ICustomerService”
bindingNamespace=“http://Sixeyed.OptimisticLockingSample/2009“/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name=“ dataSignatureBehavior “>
<serviceMetadata httpGetEnabled=“true“/>
<serviceDebug includeExceptionDetailInFaults=“true“/>
<dataSignatureBehavior/>>
</behavior>
</serviceBehaviors>
</behaviors>
<extensions>
<behaviorExtensions>
<add
name=“dataSignatureBehavior”
type=“Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureServiceBehavior/>
</behaviorExtensions>
</extensions>
Additionally, the DataSignatureOperationBehavior extends Attribute, so for finer-grained control the declarative approach is available using the same stack.
It’s been an insider’s knowledge that BizTalk 2009 RTM has been released a few days ago (March 28 2009). It is now official and available for download on MSDN downloads! Not only the core BizTalk has been deployed, but RFID, accelerators, LOB adapters, host system adapters, and host integration server 2009 are now available. […]
I had a chance to do a talk on profiling code for Microsoft’s “Build
Your Skills” event on March 24th in St. Louis (and March 31st in Minneapolis).
I mentioned a utility I’d written for cleaning up performance session files that are
generated from URLs (so that only DLL/EXE remain.) You can find that here.
In addition, you can find the slides here.
All sorts of fun details on profiling terminology, types of profiles, resigning assemblies
(or turning off assembly verification), etc. I’m hoping to record a screen cast
of the talk soon…
Fantastic turnout at both locations, and really great questions – thanks to those
who attended!
The latest edition of BizTalk Server is now available on MSDN.
The following editions are available for download (this may vary based on your MSDN subscription):
I only see the x86 version of each product available for download right now.
BizTalk Server 2009 has the following enhancements and improvements over the past version of BizTalk:
Important Notes:
In addition to BizTalk Server 2009, the 2009 Accelerators, 2009 Adapters for Host Systems, 2009 Line of Business Adapters, 2009 RFID, and 2009 Host Integration Server are also available. These are all under the BizTalk Server 2009 section under Servers.
Thanks Stephen Alderman 🙂 …
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42
[Source: http://geekswithblogs.net/EltonStoneman]
DataContract classes in WCF can be declared as implementing IExtensibleDataObject to provide in-built support for schema versioning. Any data contracts created through svcutil or Add Service Reference implement the interface, and it’s good practice to implement it for any custom DataContract classes you write. On deserializing, elements which are not declared in the data contract are extracted by the DataContractSerializer and added to the ExtensionDataObject property, so unexpected data is not lost (see Vagif Abilov’s blog post on backwards compatibility with IExtensibleDataObject).
Internally, the ExtensionDataMember holds a convoluted key-value collection of the unrecognised data members. If you want to inspect the contents of the collection it’s a fiddly process as the members are non-public, and the types and interfaces of the members (ExtensionDataMember and IDataNode) are also non-public. The code below allows you to extract the value of an ExtensionDataMember given its name:
private object GetExtensionDataMemberValue(IExtensibleDataObject extensibleObject, string dataMemberName)
{
object innerValue = null;
PropertyInfo membersProperty = typeof(ExtensionDataObject).GetProperty(“Members”, BindingFlags.NonPublic | BindingFlags.Instance);
IList members = (IList)membersProperty.GetValue(extensibleObject.ExtensionData, null);
foreach (object member in members)
{
PropertyInfo nameProperty = member.GetType().GetProperty(“Name”, BindingFlags.NonPublic | BindingFlags.Instance);
string name = (string) nameProperty.GetValue(member, null);
if (name == dataMemberName)
{
PropertyInfo valueProperty = member.GetType().GetProperty(“Value”, BindingFlags.NonPublic | BindingFlags.Instance);
object value = valueProperty.GetValue(member, null);
PropertyInfo innerValueProperty = value.GetType().GetProperty(“Value”, BindingFlags.Public | BindingFlags.Instance);
innerValue = innerValueProperty.GetValue(value, null);
break;
}
}
return innerValue;
}
Obviously this is fragile and isn’t appropriate for production solutions, but it can be useful for unit testing or debugging WCF calls, or when you want to confirm the effects of having data contracts which are out of sync between the service and the consumer. Similar code could be used to get the count of extended data members to identify if the DataContract schema is not the correct version, and interestingly, the value and innerValue properties are writeable, so you could update the contents of the unrecognised members.