by community-syndication | Mar 24, 2010 | BizTalk Community Blogs via Syndication
News is that BizTalk Server 2009 R2 is rebranded to BizTalk Server 2010. I immediately thought well Windows 2008 R2 Operating System could as well be rebranded to 2010 as SQL Server 2008 R2 that is due this year as well. BizTalk Server 2010 was designed mainly to bring to the table support for the company’s latest technologies, including previously mentioned and Visual Studio 2010. This BizTalk Server version now is aligned with latest and greatest, which wasn’t the case in the past.
Now with BizTalk Server 2010 we will face a situation as depicted in the picture below, where customers will have one of the BizTalk Server environments and may want to migrate to the next, which will mean also migration to higher version of VS, OS and SQL Server.
Factors to consider are:
- Move from x86 to x64, since Windows Server 2008 R2 is only available in x64 does support x86 applications, but needs to run on x64 supported hardware;
- Adapter choice, since WCF will become more dominant and older (non-WCF) adapters will become deprecated in either this (2010) version or future releases;
- Visual Studio is an important factor, what do customer have currently that staff is familiar with and how many solutions have been developed with a certain version;
- Support towards ERP systems, what versions of for instance SAP or Oracle are running and which adapters do you require;
- Will BizTalk become a strategy platform for the future; many customers I faced see it as strategic.
Some more capabilities have been added to this release of BizTalk Server:
- Enhanced trading partner management that will enable our customers to manage complex B2B relationships with ease (this will be welcomed in industries, where EDI is predominant)
- Increase productivity through enhanced BizTalk Mapper. These enhancements are critical in increasing productivity in both EAI and B2B solutions; and a favorite feature of our customers.
- Enable secure data transfer across business partners with FTPS adapter.
- Updated adapters for SAP 7, Oracle eBusiness Suite 12.1, SharePoint 2010 and SQL Server 2008 R2 (obvious to align to most current technologies of MS and others!)
- Improved and simplified management with updated System Center management pack.
Simplified management through single dashboard which enables IT Pros to backup and restore BizTalk configuration (I sure like to setup an environment with BizTalk 2010, Windows Server 2008 R2, SQL Server 2008 R2, all x64 and SCOM 2007 R2 to evaluate management packs)
- Enhanced performance tuning capabilities at Host and Host Instance level.
- Continued innovation in RFID Space with out of box event filtering and delivery of RFID events.
BizTalk future release after 2010 will be vNext and this will be built on top of Microsoft’s Windows AppFabric platform (Dublin app server plus Velocity caching technology). I myself have some experience around AppFabric and definitely something to explore and try out yourself (as Brian and Richard done as well). Keep an eye on progress in future on AppFabric.
Technorati: biztalk server
by community-syndication | Mar 24, 2010 | BizTalk Community Blogs via Syndication
Note: This blog post is written using the .NET framework 4.0 RC 1
Using the ReceiveAndSendReply activity template and the WorkflowServiceHost it is easy to create a workflow service. Other applications can communicate with the workflow just as if it is a regular WCF service, they never need to know the difference. Most of the configuration is quite straightforward. Select the Receive activity and configure it and do the same with the SendReply activity. Most the settings normally done using a ServiceContract or an OperationContract are there.
But what about faults?
Turns out there is no property anywhere to specify anything about a possible fault being returned.
Throwing a FaultException
When a FaultException is thrown in a workflow service pretty much the expected thing is done. The exception is send to the client as a soap fault and the client, assuming .NET here, can catch it as a FaultException. No big deal so far.
How about a FaultException<T>?
Normally when you want to add extra information with a fault you create an extra class and decorate the service contract with a FaultContract attribute specifying the fault returned. This gets added to the service metadata and doing an Add Service Reference creates the required type on the client. But with a workflow service there is no service contract class we can add the attribute to. And there is no property we can use for this purpose either. So how do we specify the fault contract with a workflow service?
The trick is to add a second SendReply to the workflow associated with the same Receive activity. The second SendReply activity returns the fault contract and this is how it gets into the workflow service metadata. Adding the second SendReply is easy, just right click the Receive activity and select Create SendReply and the activity is there. Next create a variable to hold the fault information.
The FaultDetail I am using is real simple, all it does is send the data received back to the client.
using System.Runtime.Serialization;
namespace ServicesAndFaults
{
[DataContract]
public class FaultDetail
{
[DataMember]
public int Data { get; set; }
}
}
With this second SendReply activity, creating and throwing a FaultException the workflow looks like this:
With the following expression used to initialize the fault
The SendReply activity that is returning the error is configured like this:
With this setup adding a Service Reference from a client application and using the following code has the expected result
static void Main(string[] args)
{
var proxy = new ServiceClient();
try
{
Console.WriteLine(proxy.GetData(42));
}
catch (FaultException<FaultDetail> ex)
{
Console.WriteLine("FaultException<FaultDetail> with {0}", ex.Detail.Data);
}
catch (FaultException ex)
{
Console.WriteLine(ex);
}
Console.ReadLine();
}
The output from the workflow in the service console application look like this. Note that the last message, of the workflow finishing, never appears. Not really surprising as we throw an error that is never caught and terminates the workflow.
But I want to keep my workflow alive!
Sometimes the behavior above is just fine but at other times it is not. Suppose you have been working on an order for months do you really want to terminate all that work just because of a single exception? Probably not.
The second way to return a fault to the calling client is just to return the FaultException or FaultException<T> from the SendReply activity used to define it. The client will never know the difference but the workflow will keep on running perfectly happy. So all I needed to do is remove the Throw activity and let the second SendReply do its work.
This time the service console application output look like this:
Nice to know but this feature of Windows Workflow Foundation 4 does leave something to be desired in the discoverability department. Here is another document describing how to use this feature.
Download the source code ServicesAndFaults.zip
Enjoy!
www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu
by community-syndication | Mar 24, 2010 | BizTalk Community Blogs via Syndication
Hi all,
Many of you love the extensibility of the channel model but have commented that writing custom channels is not for the faint hearted! :-). Here is your chance to feed us the problems you faced/ recommendations you offer and also, what additional channels would you like to see in the framework.
Please take a few minutes to fill this online survey – https://live.datstat.com/MSCSD-Collector/Survey.ashx?Name=Custom-Channels-Survey
Thank you!
by community-syndication | Mar 23, 2010 | BizTalk Community Blogs via Syndication
This post is about how you can take advantage of the underlying transaction created by the Endpoint Manager on receive ports. This is pretty useful when you only want to commit certain changes in your receive custom pipeline component if the entire pipeline is successful. One obvious application for this is if you want to […]
by community-syndication | Mar 23, 2010 | BizTalk Community Blogs via Syndication
I had some fun in converting my build/deploy scripts. These scripts are made to build and deploy a BizTalk project with one click on your local development machine to avoid to much clicking. The scripts are making use of MSBuild.
On my current project, the development BizTalk Servers are remote machines, the scripts were still working fine, except adding an assembly to the GAC on the remote machine caused some problems.
The first step to add an assembly is finding the right MSBuild task to do this. I’m using the MSBuild extension pack, this extension pack contains a GAC task (makes use of Gacutil.exe). The task is used as follows:
<MSBuild.ExtensionPack.Framework.Gac TaskAction=“AddAssembly“ AssemblyPath=“$(asseblyPath)“ RemoteAssemblyPath=“$(remoteAssemblyPath)“ MachineName=“$(Server)“ Force=“true“ />
As taskaction, I choose ‘AddAssembly’, specify a local and remote assembly path and a machine name (the remote server). If your user account does not have the necessary privileges to add the assembly to the remote GAC, you can specify a remote user/password combination.
Although this looks ok, this is not enough…
The remote machine is a server, without the .NET 2.0 SDK installed. The gacutil.exe tool is shipped with the .NET 2.0 SDK. We could install the .NET 2.0 SDK but it is enough to deploy gacutil.exe on the remote server.
This still did not work…
One final thing should be done! The GAC MSBuild task does not know where to find gacutil.exe. To fix this, we must add the path to gacutil.exe to the PATH environment variable.
If these three steps are done, we can GAC our assembly on the remote machine….
Peter Borremans
by community-syndication | Mar 22, 2010 | BizTalk Community Blogs via Syndication
I’ll say up front that this post is more of just thoughts in my head vs. any deep insight.
It hit me on Friday (as a result of a discussion list I’m on) that many of the recent additions to Microsoft’s application platform portfolio are first released as frameworks, and only later are afforded a proper […]
by community-syndication | Mar 22, 2010 | BizTalk Community Blogs via Syndication
I once found this document via google. It covers how to create a custom installer that will install stuff in the BizTalk Installation Folder. it explains how to read some registry setting (the installation folder of BizTalk) and how to incoperate that…(read more)
by community-syndication | Mar 22, 2010 | BizTalk Community Blogs via Syndication
One of the things developers often have to do is replace a single activity with multiple ones. This requires replacing the original activity with a Sequence and then adding the original activity to the sequence. When developing UI in Blend the same kind of operation is often required to wrap an element inside of a StackPanel, Border or something similar. In Blend this is very easy to do as there is a context menu for just this action. So all that is needed is right click and wrap something in the container of choice.
I would like to see the same functionality in the workflow designer where the user can select an activity and wrap it in a Sequence, TryCatch, TransactionScope and other relevant activities. I would also like to see the opposite where a developer can remove a wrapping Sequence is there are no other child activities.
Do you think this would be a useful feature to have? Then please go here and vote for it!
Enjoy!
www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu
