by community-syndication | Mar 6, 2009 | BizTalk Community Blogs via Syndication
I recently published a free video on Ajax-enabling your WCF services.
This screencast guides the viewer through the process of Ajax-enabling your WCF services, allowing you to easily consume them from within your Ajax client pages.
Check out our growing collection of free .NET screencasts and videos. Subscribe to the Pluralsight feed to be notified when new screencasts are published. Also, check out our growing library of online .NET training courses — see what you can learn with Pluralsight On-Demand!
by community-syndication | Mar 6, 2009 | BizTalk Community Blogs via Syndication
I recently published a new screencast on calling RESTful services with WCF.
This screencast introduces the client-side experience for using WCF to consume RESTful services. You'll see how to use the new WebChannelFactory class to create channels that know how to map method calls into traditional HTTP verbs (GET, POST, PUT, and DELETE).
Check out our growing collection of free screencasts. Subscribe to the Pluralsight feed to be notified when new screencasts are published. Also, check out our growing library of online .NET training courses — see what you can learn with Pluralsight On-Demand!
by community-syndication | Mar 6, 2009 | BizTalk Community Blogs via Syndication
[Source: http://geekswithblogs.net/EltonStoneman]
BizTalk 2006 R2 ships with WCF adapters and pre-configured settings for common bindings – basicHttp and wsHttp being typically used for SOAP messaging. With a static port you can use the WCF-Custom adapter, select an existing binding and configure it further in the UI, with the full set of binding options available to you:
Here I’m using basicHttp, but I’ve configured the maxReceivedMessageSize, sendTimeout and transferMode settings to allow us to call long-running WCF services which return large responses.
In a dynamic port, you’re limited to the settings you can configure, as the WCF Adapter Property Schema doesn’t contain the full set of binding properties. You can set the sendTimeout and maxReceivedMessageSize on an outgoing message using code:
port(Microsoft.XLANGs.BaseTypes.TransportType) = “WCF-BasicHttp”;
requestMessage(WCF.MaxReceivedMessageSize) = 104857600;
requestMessage(WCF.SendTimeout) = “00:10:00”;
– but there’s no way to access less common properties like transferMode if you’re using this approach. Originally this is how we were configuring our outgoing messages, using SSO to store the values used for the binding properties (see Receiving large WCF response messages in ESB Guidance), but we soon ran into an issue with one of the BizTalk servers running out of memory when attempting to process a large WCF response message:
System.InsufficientMemoryException: Failed to allocate a managed memory buffer of 104857600 bytes. The amount of available memory may be low. —> System.OutOfMemoryException: Exception of type ‘System.OutOfMemoryException’ was thrown.
at System.ServiceModel.Diagnostics.Utility.AllocateByteArray(Int32 size)
For basicHttp, the transferMode setting allows you to specify that messages should be streamed (one way or both ways), or buffered – the default is buffered, so when we receive the response message, although it will be streamed in the BizTalk stack, it is completely loaded into memory by the WCF stack. Note that WCF is trying to allocate the full value specified in maxReceivedMessageSize – 100 Mb – even though we’ve set this as a practical maximum, and the actual incoming message was half that size.
To remedy it, I’ve switched to using the WCF-Custom transport, and specifying basicHttp with my additional settings in the BindingConfiguration property:
port(Microsoft.XLANGs.BaseTypes.TransportType) = “WCF-Custom”;
requestMessage(WCF.BindingType) = “basicHttpBinding”;
requestMessage(WCF.BindingConfiguration) = “<binding name=\”basicHttpBinding\” sendTimeout=\”00:10:00\” maxReceivedMessageSize=\”104857600\” />”;
The BindingType needs to be specified in addition to the configuration. For the BindingConfiguration value, the Properties page for a static WCF-Custom port allows you to export the settings, so you can configure it in the UI and then save the XML representation, rather than coding it all by hand.
By shifting the BindingConfiguration value to the SSO config store, we’ll have the full range of WCF configuration available to change at run-time, so a switch to using wsHttp or netTcp bindings is just a setting change using the SSO Config Tool, and a change to the endpoint address (which we configure in UDDI in this case). Originally I wanted finer control over what could be configured, so we could limit changes to a known set of properties. But having tried this approach I prefer it – it means switching bindings and adding or changing any settings can easily be done without modifying the solution – and I’ll be recommending it as best practice.
by community-syndication | Mar 6, 2009 | BizTalk Community Blogs via Syndication
Just returned from the Summit, and had a really great time meeting colleagues and seeing interesting content. Without breaking any NDAs, I thought I’d share some thoughts on what I saw this past week.
The CSD/BizTalk MVP group remains a smart bunch of guys with a diverse set of backgrounds. I shared a hotel room with […]
by community-syndication | Mar 5, 2009 | BizTalk Community Blogs via Syndication
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/03/05/using-contextwrite-to-update-a-context-property-value/
This one has been done to death, but I am writing a moniker replacement pipeline component and noticed some interesting behaviour when looking to update Context Properties.
If you need to update an existing Context Property value, there is no Update() method defined in the IBaseMessageContext interface. However it is […]
by community-syndication | Mar 5, 2009 | BizTalk Community Blogs via Syndication
I took a hiatus last month with the interview, but we’re back now. We are continuing my series of interviews with CSD thought leaders and this month we are having a little chat with Jesus Rodriguez. Jesus is a Microsoft MVP, blogger, Oracle ACE, chief architect at Tellago, and a prolific speaker. If you follow […]
by community-syndication | Mar 4, 2009 | BizTalk Community Blogs via Syndication
[Source: http://geekswithblogs.net/EltonStoneman]
Following on from my post on Using the WCF SQL Adapter in .NET: Calling Stored Procedures (see that post for download and installation instructions for the WCF LOB adapter pack), this one looks at using the adapter to execute SQL statements on database objects.
Walkthrough: Executing SQL Statements
Add Adapter Service Reference generates separate entity and client classes for each table you select, and separate request and response classes for each table operation. To generate proxies for executing SQL statements against a table, choose the operations from the Tables view of the hierarchy:
Selecting the Insert and Select operations against the BikeTypes table will generate the following class structure:
The client for connecting to SQL Server is a standard WCF client class, inheriting from ClientBase and specifying the ServiceContract as its channel – in this case the interface is TableOp_dbo_BikeTypes which has operation contracts representing the Insert and Select statements. The entity representing the database table implements IExtensibleDataObject and provides DataMember-flagged properties for each table column; an array of entities is used as the input for the Insert operation, and the return for the Select operation (wrapping the underlying use of generated Request and Response classes).
The Request and Response classes are flagged with MessageContract attributes. Message contracts are less commonly seen than DataContract and ServiceContract, but they allow you finer control over the messages sent and received by the adapter, including the ability to specify whether data is to be serialized in the header or body of the message (see Using Message Contracts). In the generated classes, MessageContract is used to specify the wrapper name and namespace, which puts the message payload within a defined element in the SOAP body. The following attribute:
[System.ServiceModel.MessageContractAttribute(WrapperName=“Select”, WrapperNamespace=“http://schemas.microsoft.com/Sql/2008/05/TableOp/dbo/BikeTypes”, IsWrapped=true)]
– generates a SOAP message for the SelectRequest class which looks like this:
<s:Envelope xmlns:a=”http://www.w3.org/2005/08/addressing” xmlns:s=”http://www.w3.org/2003/05/soap-envelope“>
<s:Header>
<a:Action s:mustUnderstand=”1“>TableOp/Select/dbo/BikeTypes</a:Action>
<a:MessageID>urn:uuid:9a5fe359-e988-4504-96a9-b9b721d00502</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
</s:Header>
<s:Body>
<Select xmlns=”http://schemas.microsoft.com/Sql/2008/05/TableOp/dbo/BikeTypes“>
<Columns>*</Columns>
<Query>WHERE BikeTypeCode LIKE ‘%R%’</Query>
</Select>
</s:Body>
</s:Envelope>
Note that the SOAP action is the Node Id for the operation from Add Adapter Service Reference. The request message contains Columns and Query elements, which are used in the call to refine the size and content of the resultset. In code you specify the Columns property with “*” to return all, or a comma-separated list of column names (which should be listed in the same order as defined in the table). Query can be null, empty or contain a WHERE clause to restrict the results:
TableOp_dbo_BikeTypesClient client = new TableOp_dbo_BikeTypesClient();
client.Open();
BikeTypes[] allBikeTypes = client.Select(“*”, null);
BikeTypes[] bikeTypeDescriptions = client.Select(“BikeTypeDescription”, string.Empty);
BikeTypes[] likeRBikeTypes = client.Select(“*”, “WHERE BikeTypeCode LIKE ‘%R%'”);
A populated Query property will limit the number of items returned. A populated Columns property will limit the number of populated elements in the response, so the typed object will have null values for any unmapped columns.
For the insert, you pass an array of populated entities to the call:
List<BikeTypes> bikeTypes = new List<BikeTypes>();
bikeTypes.Add(new BikeTypes());
bikeTypes[0].BikeTypeCode = “NEW”;
bikeTypes[0].BikeTypeDescription = “New Type”;
TableOp_dbo_BikeTypesClient client = new TableOp_dbo_BikeTypesClient();
client.Open();
client.Insert(bikeTypes.ToArray());
If you want to write identity values for tables which have an identity column, you can specify AllowIdentityInsert in the binding configuration. Otherwise, any specified columns have the value from the entity inserted; null values have NULL inserted. The return contains an array of long values containing the identity of the inserted rows – unless the table does not have an identity column, in which case the return is null.
Similarly the adapter can generate request and response classes for Update and Delete statements, which follow the same pattern. The generated stack has the same benefits as with the stored procedure calls – the code is very light and it uses the standard WCF stack, so if you’d rather generate or hand-craft your own connections, that’s a definite option. I’ll explore it in a later post.
by community-syndication | Mar 4, 2009 | BizTalk Community Blogs via Syndication
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/03/04/ftp-adapter-context-property-oddities/
Interesting to see that the FTP adapter doesn’t capture the full Uri of the file in its ReceivedFileName context property – instead it simply gives us the filename:
Compare this with the FILE adapter where the full name (incl. the path) of the file is provided:
So, if you need to […]
by community-syndication | Mar 4, 2009 | BizTalk Community Blogs via Syndication
Trying to invoke a method when the powershell host is exiting…
How to register an event to make the final callback
till so far I discovered that (get-host)Runspace | get-member
does have an event “StateChanged” that I can maybe use.
To be continued
by community-syndication | Mar 3, 2009 | BizTalk Community Blogs via Syndication
Since PDC I’ve been working on and off on an “Oslo” based solution for deploying a BizTalk application; unfortunately I couldn’t get a good chunk of time to play with this, so it’s been dragging a bit, but I’m getting close, so here are some details –
I’m a big advocate of automated builds; it’s a topic that probably deserves a post of its own, so I won’t get started on this here, but the idea is that one must have a way to be confident that, when its time to [re-]deploy the app, it will get deployed successfully time after time, without a hitch;
From my experience, deploying a BizTalk application of a decent size is often not trivial, and often it does not go smoothly if done manually (things are being missed, done out of order, wrong versions being picked up, etc), which does not help to boost the confidence in the solution (or BizTalk as a whole) in the organisation; automating the process can save a lot of time (can be done unattended, while in a meeting, out for lunch or overnight), save a lot of head scratching, boost the confidence in the solution and set the ground for proper automated builds, auto testing etc.
To that extent, I have previously built an MSBuild based framework for deploying BizTalk applications.
While I’m sure it does not suit all purposes as it was developed to support those scenarios I had, I think it’s quite comprehensive and had served me well over the past couple of years.
It allows one to provide an MSBuild-formatted file with some parameters and lists and, using the pre-created framework, would do things like remove the existing application (after terminating current instances and un-enlisting services), build the new solution(s), deploy assemblies to BizTalk, add/import binding files, start ports etc.
This is working great for us, and we’ve been using it extensively for quite a while now, but there’s one major downside – it requires one to maintain those MSBuild scripts.
Now – MSBuild is cool, I do like it very much, but as it’s generic – it does not speak in BizTalk terms, and as it’s XML – it’s quite verbose, and I wanted an easier format for all of us to work with.
So – inspired after seeing Oslo and even more driven after visiting PDC – I’ve decided to come up with an MGrammar based language for describing a BizTalk application to be deployed.
So far I’ve come up with “version 1.0” of my grammar that allows to describe the major artifacts in a BizTalk application and a basic runtime to process source files written in this language, the language allows you to describe things like –
- References to other applications
- Solutions and projects to build
- BizTalk assemblies to deploy
- Orchestrations contained in those (these can then be terminated before attempting to remove the application prior to deployment)
- .net assemblies to deploy
- Binding file to import
- Binding files to add (and the name of the environment to attach to those)
As Oslo hasn’t RTM-ed yet, I can’t quite rely on it yet, and so I cannot use it in production in any shape or form, or can I?
I found a good middle ground for us which allows us to gain from the benefits I’m hoping to get by using my language, while not exposing ourselves too much to the risks of using early technology –
At the moment the runtime I’ve built for this is used to generate the MSBuild scripts we’re already using out of the source files; in this way – if Oslo disappears tomorrow, or significantly changes (not that I think that’s going to be the case), we’re safe – we still have the MSBuild scripts as “checked-in artifacts” and so we have lost nothing.
So – how does an instance of my language looks like? here’s an example:
Application MyApp
{
//add references to other applications
add reference SomeOtherApp;
add reference AndAnother,andAThird;
//build the solution
build "SomeFolder\SomeOtherFolder\SomeSolution.sln";
build "SomeFolder\SomeOtherFolder\SomeProject.btproj";
//add required biztalk assemblies
add biztalk assembly "SomeFolder\SomeOtherFolder\bin\deployment\Schemas.dll"
version=1.0.0.0
culture=neutral
publicKeyToken=314bd7037656ea65;
add biztalk assembly "SomeFolder\SomeOtherFolder\bin\deployment\Maps.dll"
version=1.0.0.0
culture=neutral
publicKeyToken=314bd7037656ea65;
add biztalk assembly "SomeFolder\SomeOtherFolder\bin\deployment\Orchestrations.dll"
with orchestrations
{
MyApp.SomeOrchestration,
MyApp.AnottherOrchestration,
MyApp.AndAnotherOrchestration
}
version=1.0.0.0
culture=neutral
publicKeyToken=314bd7037656ea65;
//and .net helpers assembly
add assembly "SomeFolder\SomeOtherFolder\bin\release\HRG.FareWatch.Hotel.Helpers.dll"
version=1.0.0.0
culture=neutral
publicKeyToken=314bd7037656ea65;
//import dev bindings
import binding "SomeFolder\SomeOtherFolder\Bindings.xml";
//add various environment's bindings.
add binding "SomeFolder\SomeOtherFolder\Bindings.Dev.xml" "development";
add binding "SomeFolder\SomeOtherFolder\Bindings.Stage.xml" "stage";
add binding "SomeFolder\SomeOtherFolder\Bindings.Prod.xml" "production";
}
as I’ve said – I already have a runtime that generates the MSBuild scripts required to deploy these – the runtime outputs several files to the temp folder –
- The “framework” MSBuild script that contains all the targets I’m using
- The Microsoft.Sdc.Tasks.BizTalk.dll and the Microsoft.Sdc.Tasks.dll which contains many useful custom tasks.
- The relevant import file for the SDC tasks
- The generated MSBuild file that contains all the various artifacts based on the source code
That latter file, which is the equivalent of my source code, and what we had to maintain so far, looks like –
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="DeployAll">
<Import Project="Deploy.Framework" />
<ItemGroup>
<MyApp Include="SomeOtherApp" />
<MyApp Include="AndAnother" />
<MyApp Include="andAThird" />
</ItemGroup>
<ItemGroup>
<Bindings Include="General">
<path>SomeFolder\SomeOtherFolder\Bindings.xml</path>
</Bindings>
</ItemGroup>
<ItemGroup>
<EnvironmentBindings Include="General">
<path>"SomeFolder\SomeOtherFolder\Bindings.Dev.xml"</path>
<environment>development</environment>
</EnvironmentBindings>
<EnvironmentBindings Include="General">
<path>"SomeFolder\SomeOtherFolder\Bindings.Stage.xml"</path>
<environment>stage</environment>
</EnvironmentBindings>
<EnvironmentBindings Include="General">
<path>"SomeFolder\SomeOtherFolder\Bindings.Prod.xml"</path>
<environment>production</environment>
</EnvironmentBindings>
</ItemGroup>
<ItemGroup>
<ExternNetAssembly Include="HRG.FareWatch.Hotel.Helpers">
<Version>1.0.0.0</Version>
<Culture>neutral</Culture>
<PublicKeyToken>314bd7037656ea65</PublicKeyToken>
<ProcessorArchitecture>MSIL</ProcessorArchitecture>
<path>SomeFolder\SomeOtherFolder\bin\release</path>
</ExternNetAssembly>
</ItemGroup>
<ItemGroup>
<Solution Include="SomeSolution">
<path>SomeFolder\SomeOtherFolder</path>
</Solution>
<Solution Include="SomeProject">
<path>SomeFolder\SomeOtherFolder</path>
</Solution>
</ItemGroup>
<ItemGroup>
<BTSProject Include="Schemas">
<Version>1.0.0.0</Version>
<Culture>neutral</Culture>
<PublicKeyToken>314bd7037656ea65</PublicKeyToken>
<ProcessorArchitecture>MSIL</ProcessorArchitecture>
<path>SomeFolder\SomeOtherFolder\bin\deployment</path>
</BTSProject>
<BTSProject Include="Maps">
<Version>1.0.0.0</Version>
<Culture>neutral</Culture>
<PublicKeyToken>314bd7037656ea65</PublicKeyToken>
<ProcessorArchitecture>MSIL</ProcessorArchitecture>
<path>SomeFolder\SomeOtherFolder\bin\deployment</path>
</BTSProject>
<BTSProject Include="Orchestrations">
<Version>1.0.0.0</Version>
<Culture>neutral</Culture>
<PublicKeyToken>314bd7037656ea65</PublicKeyToken>
<ProcessorArchitecture>MSIL</ProcessorArchitecture>
<path>SomeFolder\SomeOtherFolder\bin\deployment</path>
</BTSProject>
</ItemGroup>
<PropertyGroup>
<BTApplicationName>MyApp</BTApplicationName>
<!-- Set for a remote deployment -->
<!-- Deploying BizTalk Server name - leave blank if local-->
<!-- not currently supported by runtime-->
<BTServerName>
</BTServerName>
<!-- Deploying BizTalk Server database - leave blank if BizTalkMsgBoxDb-->
<BTServerDatabase>
</BTServerDatabase>
<!-- Deploying BizTalk Server SQL user name - leave blank if local-->
<BTServerUserName>
</BTServerUserName>
<!-- Deploying BizTalk Server SQL password - leave blank if local-->
<BTServerPassword>
</BTServerPassword>
</PropertyGroup>
</Project>
Would you agree that the former source code is easier to maintain?
note: one thing you would notice is that none of the paths contains a root; I assume that this would be used by different developers/IT pros which may have the code in a different path; however, as the assumption is that the code will come from source control, my framework script expects you to provide the root path to your source code and assumes the specified paths start there.
So – what’s next?
From a coding perspective – I plan to add support in my runtime to perform the actual deployment; this is I would like it to do once Oslo is in production so I’ll add it as an option through a command line switch.
This option would tell the runtime to deploy the artifacts to a specified BizTalk server using BTSTask or the Object model instead of generated the MSBuild script.
I also want to make some modification to my language definition to make the MGraph produced cleaner (and better geared towards using the repository and Quadrant at a later stage) as well as, obviously, add support for more features, after which I plan to publish both my language and the runtime somewhere (here, codeplex, DevCente..we’ll see)
I’ll post some more notes on all of these here in the near future hopefully
