Phidget provider released
Thanks Irving! – http://blogs.msdn.com/irvingd/pages/biztalk-rfid-device-provider-dspi-for-phidget-devices.aspx
So when will Microsoft.com start using Silverlight?
When talking to people about Silverlight over the last week the #1 question I kept getting was….
“So when will microsoft.com start using Silverlight?”
Well if you go to http://microsoft.com this morning you will see a an ad for the sleek black, 120GB, HDMI, XBOX 360 Elite running inside the Silverlight 1.0 beta plugin. Hmmm now does that one come with Guitar Hero II?
WCF Message validation (1) – WCF samples to the rescue
Recently, I needed to validatie messages going into a WCF service. It turned out the WCF samples are a rich source of knowledge and I found a sample which performs XMLSchema-based validation in \TechnologySamples\Extensibility\MessageInspectors. The sample contains a few classes: The sample uses a property called Schemas within it’s configuration, allowing us to define which schemas should be taken into account when validating. <schemaValidator validateRequest=“True“ validateReply=“True“> <schemas> <add location=“messages.xsd“ /> </schemas> </schemaValidator> That’s great, but as you all probably know, WCF services have the ABC’s: Address, Binding and Contract. What I actually wanted the behavior to do was validate my message against the actual Contract of the endpoint the validator was working on. In order for this to work, I did two thing: 1. I removed all “Schemas” configuration and arguments from the code. 2. I modified the SchemaValidationBehavior class to validate the actual contract. The first steps should be self-explanatory, but the second I want to elaborate on. What I actually did was modify the methods ApplyClientBehavior and ApplyDispatchBehavior. The sample took the configured Schemas property to create the actual SchemaValidationMessageInspector: SchemaValidationMessageInspector inspector = new SchemaValidationMessageInspector( schemaSet, validateRequest, validateReply, false); I wanted to dynamically use the endpoint contract: WsdlExporter exporter = new WsdlExporter(); exporter.ExportContract(endpoint.Contract); SchemaValidationMessageInspector inspector = new SchemaValidationMessageInspector( exporter.GeneratedXmlSchemas, validateRequest, validateReply, false); After modifying both methods to perform this kind of setup, it was easy to configure validation based on the endpoint contract (some elements abbreviated for clarity): <system.serviceModel> <services> <service name=“SomeService“> <endpoint address=“SomeAddress“ binding=“wsHttpBinding“ contract=“ ISomeService“ behaviorConfiguration=“SomeServiceEndpointBehavior“ /> </service> </services> <behaviors> <endpointBehaviors> <behavior name=“SomeServiceEndpointBehavior“> <SchemaValidator validateRequest=“True“ validateReply=“True” /> </behavior> </endpointBehaviors> </behaviors> <extensions> <behaviorExtensions> <add name=“SchemaValidator“ type=“SchemaValidationBehaviorExtensionElement, …“/> </behaviorExtensions> </extensions> </system.serviceModel> That’s it, now we have a service endpoint validated based on it’s WSDL contract. The sample code is attached for your enjoyment.
San Diego .NET UG
Thanks to my friend and fellow BizTalk MVP Brian
Loesgen – I’ll be speaking May 22nd at the San
Diego .NET User Group on two of my favorite technologies – WF and WCF and how
to use them together successfully today – even without Orcas! Come out
if you are in the SD area.
WCF Message validation (1) – WCF samples to the rescue
Recently, I needed to validatie messages going into a WCF service. It turned out the WCF samples are a rich source of knowledge and I found a sample which performs XMLSchema-based validation in \TechnologySamples\Extensibility\MessageInspectors. The sample contains a few classes: The sample uses a property called Schemas within it’s configuration, allowing us to define which schemas should be taken into account when validating. <schemaValidator validateRequest=“True“ validateReply=“True“> <schemas> <add location=“messages.xsd“ /> </schemas> </schemaValidator> That’s great, but as you all probably know, WCF services have the ABC’s: Address, Binding and Contract. What I actually wanted the behavior to do was validate my message against the actual Contract of the endpoint the validator was working on. In order for this to work, I did two thing: 1. I removed all “Schemas” configuration and arguments from the code. 2. I modified the SchemaValidationBehavior class to validate the actual contract. The first steps should be self-explanatory, but the second I want to elaborate on. What I actually did was modify the methods ApplyClientBehavior and ApplyDispatchBehavior. The sample took the configured Schemas property to create the actual SchemaValidationMessageInspector: SchemaValidationMessageInspector inspector = new SchemaValidationMessageInspector( schemaSet, validateRequest, validateReply, false); I wanted to dynamically use the endpoint contract: WsdlExporter exporter = new WsdlExporter(); exporter.ExportContract(endpoint.Contract); SchemaValidationMessageInspector inspector = new SchemaValidationMessageInspector( exporter.GeneratedXmlSchemas, validateRequest, validateReply, false); After modifying both methods to perform this kind of setup, it was easy to configure validation based on the endpoint contract (some elements abbreviated for clarity): <system.serviceModel> <services> <service name=“SomeService“> <endpoint address=“SomeAddress“ binding=“wsHttpBinding“ contract=“ ISomeService“ behaviorConfiguration=“SomeServiceEndpointBehavior“ /> </service> </services> <behaviors> <endpointBehaviors> <behavior name=“SomeServiceEndpointBehavior“> <SchemaValidator validateRequest=“True“ validateReply=“True” /> </behavior> </endpointBehaviors> </behaviors> <extensions> <behaviorExtensions> <add name=“SchemaValidator“ type=“SchemaValidationBehaviorExtensionElement, …“/> </behaviorExtensions> </extensions> </system.serviceModel> That’s it, now we have a service endpoint validated based on it’s WSDL contract. The sample code is attached for your enjoyment.
Windows Desktop Search V3.01
After being directed by a TechNet article to get the latest version of WDS – I was
ready for the install.
Double clicked on wdssetup.exe – ready to roll.
A big error message says “Please remove previous versions….then upgrade”
After scouring add/remove programs and the updates, there was not ‘apparent’ entry
called ‘Windows Desktop Search’ (I was directed to another article that mentioned
if I checked the ‘MSN Apps’ registry to see if there was a WDS Version registered
there…..I had a version number 3.0.0.000x but not much more as in a productID)
I finally resorted to a registry hack – searched for all key/values that had ‘Windows
Desktop Search” somewhere (as this was the path under c:\program files\…” – and
I hacked away.
(this was a VPC image with undo disks turned on – so dont try this
at home boys and girls 🙂
After completing that….I thought I’d re-run WDS 3.01 setup again…….and I
got further than before – in fact the furthest I’d gotten.
I arrived at a welcome screen with a ‘Next’ button….guess what the first thing it
did after I hit next……….
“…..Upgrading previous versions……“
……now where’s that number to book myself in!!! 
Uploading/Downloading/Checking in + Out – Using Lists.asmx and Copy.asmx
Well after battling the Bondi beach Christmas swells in at times what felt like a
canoe…..I’ve come out the other side with a working ‘Offline Client’ for one of
my demos at the upcoming Sharepoint Conference.
A couple of things upfront:
WebServices are found at
http://server/<site>/<supersubsite>/_vti_bin/Lists.asmx (+
copy.asmx)
We make the initial reference inclusive of our Site Hierarchy so the Sharepoint HTTP
handlers know what site we’re hooking into.
* 1-Gotcha * Lists.GetListCollection(….) – only returns (a chunk
of XML) lists that are for the RootWeb and not your subsite/web *even
though you specified the direct Url*
(now having said that….my machine might mysteriously get an update overnight from
‘those’ who are watching and be good again in the morning…….I find that with Vista
sometimes 
)
So check back at the end of the up and coming week for the demos…..maybe
I might post my demo code up the night before……
Commerce Server 2007: Mapping the OrderGroupCollection Schema (Series Post #3)
This is the third post in my Commerce Server 2007 B2B Solution Development series and if you've been following the first two posts (1, 2), you'll remember that I like to "begin with the end in mind". In Commerce Server 2007 terms, this means figuring out how to map the XML produced by the Orders Receive Adapter (OrderGroupCollection schema) to something a little easier to work with as you integrate your Commerce Server orders into your ERP system.
BTW, this is one of the most widely asked questions I've seen in the past year and there's nothing in the Commerce Server docs to suggest how to use the XML produced by the Orders adapter.
The new Orders Receive Adapter produces a single message type which is used to periodically export order information from the Commerce Server Orders subsystem. This adapter is unique among the four new adapters in that it performs everything within a transaction, which allows roll-back in case of an error. The Orders adapter produces an XML document which conforms to the OrderGroupCollection schema as shown below from the BizTalk Schema Editor.
Since this schema was developed to match the Commerce Server Orders subsystem it’s unlikely that you’ll be able to use the XML produced by it “as is.” This is where the BizTalk Map comes in to play. In most cases, you’ll want to “normalize” the XML documents received from the Orders Adapter by mapping to some standard XML schema used by your organization. In our case, we normalize all inbound purchase orders (whether from an external trading partner or from Commerce Server) to an internal format that’s easier to work with and one which “fits” better into our existing BizTalk applications. This normalized XML sales order schema is shown below.
One of the challenges in mapping from the OrderGroupCollection schema is how to map weakly-typed (indexer) properties found in the various elements within the schema. Luckily, the BizTalk Mapper tool includes several functoids that make this process pretty simple. In the example below, the Equal functoid returns true if it finds a certain string in the WeaklyTypedProperty element’s Name attribute and the Value Mapping (Flattening) functoid will then map the Value attribute to the shipping_method_name attribute in the outbound schema. Using these two functoids, you can “look up” all the weakly-typed properties used in your Commerce Server application by their name and map them as needed.
Another challenge in mapping from the OrderGroupCollection schema is how to map the correct OrderAddress attributes, since the OrderAddress elements are located on the same level as the OrderForm they correspond to in the schema. This makes mapping using standard techniques very difficult but thankfully, BizTalk Server includes some advanced functoids created for just this kind of mapping challenge.
In the sample shown below, I’ve used the Database Lookup and Value Extractor functoids linked to the ShippingAddressId attribute to lookup all the required address information directly from the Commerce Server “transactions” database. Since the ShippingAddressID property is set in the Commerce Server web application and persisted to the “transactions” database, it should be present in all saved orders. A word of caution should be noted however. The Database Lookup and Value Extractor functoids call the database directly from the BizTalk map and as such, they could cause performance issues when used in a high volume scenario. Always test your BizTalk applications thoroughly before deploying into your production environment.
Obviously, mapping from the Commerce Server OrderGroupCollection schema directly to the schema used by your ERP system is "possible" but in my experience, mapping to a simpler XML schema (normalizing) and then to your final schema is much more effective. Remember, in BizTalk Server you can map on a Receive Port, a Send Port, in an Orchestration or in any combination of the three. This flexibility makes it possible to map from the OrderGroupCollection schema to just about any schema you require.
Commerce Server 2007: Mapping the OrderGroupCollection Schema (Series Post #3)
This is the third post in my Commerce Server 2007 B2B Solution Development series and if you've been following the first two posts (1, 2), you'll remember that I like to "begin with the end in mind". In Commerce Server 2007 terms, this means figuring out how to map the XML produced by the Orders Receive Adapter (OrderGroupCollection schema) to something a little easier to work with as you integrate your Commerce Server orders into your ERP system.
BTW, this is one of the most widely asked questions I've seen in the past year and there's nothing in the Commerce Server docs to suggest how to use the XML produced by the Orders adapter.
The new Orders Receive Adapter produces a single message type which is used to periodically export order information from the Commerce Server Orders subsystem. This adapter is unique among the four new adapters in that it performs everything within a transaction, which allows roll-back in case of an error. The Orders adapter produces an XML document which conforms to the OrderGroupCollection schema as shown below from the BizTalk Schema Editor.
Since this schema was developed to match the Commerce Server Orders subsystem it’s unlikely that you’ll be able to use the XML produced by it “as is.” This is where the BizTalk Map comes in to play. In most cases, you’ll want to “normalize” the XML documents received from the Orders Adapter by mapping to some standard XML schema used by your organization. In our case, we normalize all inbound purchase orders (whether from an external trading partner or from Commerce Server) to an internal format that’s easier to work with and one which “fits” better into our existing BizTalk applications. This normalized XML sales order schema is shown below.
One of the challenges in mapping from the OrderGroupCollection schema is how to map weakly-typed (indexer) properties found in the various elements within the schema. Luckily, the BizTalk Mapper tool includes several functoids that make this process pretty simple. In the example below, the Equal functoid returns true if it finds a certain string in the WeaklyTypedProperty element’s Name attribute and the Value Mapping (Flattening) functoid will then map the Value attribute to the shipping_method_name attribute in the outbound schema. Using these two functoids, you can “look up” all the weakly-typed properties used in your Commerce Server application by their name and map them as needed.
Another challenge in mapping from the OrderGroupCollection schema is how to map the correct OrderAddress attributes, since the OrderAddress elements are located on the same level as the OrderForm they correspond to in the schema. This makes mapping using standard techniques very difficult but thankfully, BizTalk Server includes some advanced functoids created for just this kind of mapping challenge.
In the sample shown below, I’ve used the Database Lookup and Value Extractor functoids linked to the ShippingAddressId attribute to lookup all the required address information directly from the Commerce Server “transactions” database. Since the ShippingAddressID property is set in the Commerce Server web application and persisted to the “transactions” database, it should be present in all saved orders. A word of caution should be noted however. The Database Lookup and Value Extractor functoids call the database directly from the BizTalk map and as such, they could cause performance issues when used in a high volume scenario. Always test your BizTalk applications thoroughly before deploying into your production environment.
Obviously, mapping from the Commerce Server OrderGroupCollection schema directly to the schema used by your ERP system is "possible" but in my experience, mapping to a simpler XML schema (normalizing) and then to your final schema is much more effective. Remember, in BizTalk Server you can map on a Receive Port, a Send Port, in an Orchestration or in any combination of the three. This flexibility makes it possible to map from the OrderGroupCollection schema to just about any schema you require.
Detect CLR version under which your BizTalk service is running.
It’s becoming more and more eminent to understand under which CLR version (1.0, 1.1 or 2.0) the BizTalk runtime, In-Process host is running. I’ve explained in my previous post the various factors that influence loading appropriate CLR versions and also how you can make use of the config file to force a specific version of CLR is always loaded.
There is one more query raised, what happens if you install .NET Framework 3.0 on your BizTalk server (both 2004 and 2006)? The effect of installing .NET 3.0 doesn’t introduce that much behavior difference when compared to installing .NET 2.0 on a BizTalk 2004 machine (built using .NET 1.1 with CLR 1.0). Because .NET 3.0 is still based on .NET 2.0 and shares the same compilers and Common Language Runtime (CLR 2.0). See the following posts from Somasegar and Jason Zanders (comments are more interesting on the both the posts)to see the effect of .NET 3.0.
With all this confusions around different versions of .NET and different versions of BizTalk and different Service Packs, there will certainly be a situation where developers and administrators need to figure out the version of CLR under which the BizTalk Runtime is running. This is where Process Explorer comes to our rescue.
Process explorer’s top window shows a list of currently active processes, and the bottom windows shows either the handles opened by the selected process or it shows the DLL’s and memory mapped files that the selected process has loaded. You need to set the appropriate mode from the menu item “View-> Lower Pane View”. In our case we need to figure out the version of Common Language Runtime core dll (mscorwks.dll) loaded into the BizTalk runtime process (BtsNtSvc.exe). So, we’ll set the “Lower Pane View” to DLL’s (or Ctrl + D).
Also, make sure the following columns are visible Description, Image Path, and Version. To do so, click on “View” menu and select “Select Columns” and in the “Process Image” tab select appropriate columns.
The following screen shot is taken from a machine running BizTalk 2006. You can see clearly from the bottom pane the version of CLR running is 2.0 and physical dll is loaded from the location “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll”. BTW, .NET 3.0 is installed in this particular machine, which also proves .NET 3.0 still uses CLR 2.0. In BizTalk 2006 box its quite straight forward it’s all .NET 2.0. Things will become more interesting in BizTalk 2004 scenario.
Nandri!
Saravana