More Cookbooks: Microsoft Windows Server AppFabric Cookbook

by community-syndication | Apr 7, 2012 | BizTalk Community Blogs via Syndication

I myself have written a cookbook on BizTalk Server called: BizTalk Server Cookbook 2010 for Packt Publishing. Yet there is another cookbook heading our way from this publisher. Fellow MVP from the “Connected Systems” discipline Rick G. Garibay and Microsoft Architect Hammad Rajjoub have written a cookbook on Windows Server AppFabric.

This book will:

• Download, install, configure and get up and running with Windows Server AppFabric quickly
• Learn how to take advantage of distributed caching for providing high performance and elastic scale on-premise today
• Take advantage of the enhanced hosting capabilities that Windows Server AppFabric has to offer including Auto-Start and a greatly simplified configuration experience
• Enable support for long-running composite applications that are resilient and fault-tolerant while maximizing computing resources
• Gain insight into the health of your composite applications seamlessly, both proactively and when something goes wrong
• Learn how to scale Windows Server AppFabric by leveraging farm deployments

I know both Rick and Hammad, who are both very active community leaders and long time MVP’s, have done a great job. Windows Server AppFabric can be viewed as a part of the Microsoft Integration Stack together with BizTalk, SQL Server and Azure ServiceBus. Basically Windows Server AppFabric, BizTalk and SQL Server are a part of the On-premise integration middleware (see whitepaper by Gijs in ’t Veld).

For lightweight integration Windows Server AppFabric together with WF (Windows Workflow) and WCF (Windows Communication Foundation) can be a right fit within your enterprise without using the more scalable, robust BizTalk Server. I believe this book will tell you the complete story on how to use Windows Server AppFabric, how to set it up and how to create robust, and state-of-the-art solutions on it.

To conclude I think the content of this book will be very valuable for WF/WCF developer and also for us BizTalk guys. I am looking forward to this book and have pre-ordered it, so now go and you pre-order it!

Three Software Updates to be Aware Of

by community-syndication | Apr 6, 2012 | BizTalk Community Blogs via Syndication

In the past few days, there have been three sizable product announcements that should be of interest to the cloud/integration community. Specifically, there are noticeable improvements to Microsoft’s CEP engine StreamInsight, Windows Azure’s integration services, and Tier 3’s Iron Foundry PaaS. First off, the Microsoft StreamInsight team recently outlined changes that are coming in their […]
Blog Post by: Richard Seroter

Review of Steef-Jan’s BizTalk Server 2010 Cookbook

by community-syndication | Apr 6, 2012 | BizTalk Community Blogs via Syndication

At BizTalkAdminsBlogging I’ve written a review about Steef-Jan’s first book.

You can find it here.

BizTalk Server 2010 Cookbook Released

by community-syndication | Apr 5, 2012 | BizTalk Community Blogs via Syndication

Finally my book with recipes for BizTalk Server 2010 is officially released. After a year of hard work it is available now. You can find the complete table of contents on Packt Website for this book.

Before starting this endeavor I asked Richard Seroter for guidance and discussed the opportunity with fellow MVP Randal van Splunteren during MVP Summit 2011. Both motivated me to go for it. So I did and I signed a book contract with Packt.

I did not want to write a straight forward book with recipes only targeted on the out-of-box capabilities of BizTalk Server 2010. So I decided to do it differently.

This book will provide material on community tooling available on CodePlex like BizTalk BenchMark Wizard and many other BizTalk related tooling. Also Microsoft has built tooling for BizTalk like BizTalk Best Practice Analyzer, which can be very valuable in validating your BizTalk environment. The book provides a couple recipes on topics that you would not find in other BizTalk (recipe) books and some that you are familiar with. With all the recipes combined I wanted to draw a contrast of what BizTalk offers out-of-box versus the alternatives offered through the community and 3rd parties.
 
During the course of the book I have had support from fellow MVP’s Saravana Kumar, who contributed a recipe on alternative monitoring with BizTalk360, Mikael H%u00e5kansson who helped on the recipe concerning BizTalk BenchMark Wizard (BBW), and my colleague Douglas Skirving on Security.

It was lots of fun to write this book, and I hope many of you will order the book and enjoy reading it. I would like to thank both my official technical reviewers Randal van Splunteren, Rene Brauwers, Abdul Rafay and Sandro Pereira and others Tord G. Nordahl, Richard Seroter, and Paul Gielens for their insight, hints, tips and keeping me on the right path. Finally I like to thank Packt Publishing for giving me this opportunity. Finally I like to thank the team behind the scene at Packt Publishing that I worked with: Dhwani, Chris, Prasad, Laxmi, Vishal, Rekha, Prachali and Alwin.

If you do have any feedback on my work in this book, don’t hesitate to drop me a line.

Azure AppFabric cache with EPiServer CMS

by community-syndication | Apr 5, 2012 | BizTalk Community Blogs via Syndication

This blog post is about using Windows Azure AppFabric cache service together with EPiServer CMS. EPiServer CMS supports pluggable cache, replacing the standard EPiServer CMS cache component. …

Daniel Berg’s blog about ASP.NET, EPiServer, SharePoint, BizTalk

BizTalk 2010 XML Polling with WCF-SQL Adapter

by community-syndication | Apr 5, 2012 | BizTalk Community Blogs via Syndication

One of the feature that came with the WCF-SQL Adapter was the ability to XML polling from SQL. Anyone that remembers the original SQL adapter from BizTalk remembers the requirement for all the data returned from SQL to have the FOR XML AUTO added to the end of the query and the XMDATA added to add the Store Procedure call to your BizTalk project.

Typically when you poll data out of SQL it is a single table or the output of a stored procedure, this limited the type of data that could be returned, the example is that it was difficult to return the order header and all the detail lines with a single polling statement. The XML polling feature of the WCF-SQL adapter allow you to create your own XML document in SQL and return it to BizTalk via a polling statement.

In this blog post I am going to show how to do this.

Background

I will be using the Sample AdventureWorks database and returning and Order XML document.

Install the AdventureWorks SQL sample database from http://sqlserversamples.codeplex.com/

Install the BizTalk 2010 LOB Adapter SDK and the LOB Adapter Pack (in not already installed)

In SQL

Create a SQL Stored Procedure to return the desired data, using the xmlnamespaces and for xml path. You will need to decide when you create your stored procedure whether it will be returning a single Order or a batch of Orders, there will be not difference to the XML generated in the stored procedure just a difference in how you select the records to return. The stored procedure that I have created returns up to 5 Orders per call.

(complete SQL Stored Procedure available in download below)

Grant the BizTalk Application User group access to the AdventureWorks database and execute privileges to the GetSalesOrdersToProcess stored procedure.

Execute the stored procedure to create a sample XML document and save it to order.xml

In Visual Studio

Create a BizTalk Project (I am using Demo.WCFSQL.Polling for the solution name and AdventureWorks.Schemas for the project name)

In the BizTalk project add a generated item and select generated schema, in the generated schema dialog select Well-Formed XML, then select the order.xml file saved above. This will create an order.xsd in your BizTalk project. You may also need to update any numeric fields to the correct data types, the generated schema wizard sets number to the smallest data type that fits the sample data.

If you decide when creating your stored procedure to return multiple orders per execution, you will need to create and orders.xsd envelope schema, like this:

And set the Body XPath to the root node Orders.

Strong name your BizTalk project and set the deployment application name (I am using Demo.WCFSQL.Polling)

This is the complete Solution

Build and deploy your solution.

In BizTalk Administration Console

Expand the application that you deployed your solution into (I am using Demo.WCFSQL.Polling)

Create Receive Port and Receive Location

You now need to create the one-way WCF-SQL receive port and receive location (I am using AdventureWorks.Orders.Polling as the receive port name and AdventureWorks.Orders.Polling.WCFSQL as the receive location name)

The receive location can either be created as a WCF-Custom with the sqlBinding or as a WCF-SQL adapter (I am using the WCF-Custom with the sqlBinding)

After selecting WCF-Custom, click Configure.

On the General Tab type in the Address (URI), this consist of the protocol, server name, database name and Inbound Id like below:

mssql:////?InboundId=Orders (my example looks like: http://biztalkbill.commssql://.//AdventureWorks?InboundId=Orders)

On the Binding Tab, select sqlBinding in the Binding Type drop down list

Set the following setting

Note: useAmbientTransaction defaults to True, if MSDTC is not configured between BizTalk and the source SQL Server you will have to set this to false

Click Ok, to close the WCF-Custom Transport Properties dialog

Select the appropriate Receive handler and set the Receive Pipeline to XMLReceive, then click OK to close the Receive Location Properties

Create Send Port

For this example we are just going to send the XML message directly out to a file location

You now need to create a one-way send port (I am using AdventureWorks.Orders.Send.FILE for the send port name)

Select a file location for the output XML messages (I am using C:\Working\Demo.WCFSQL.Polling\Out\%MessageID%.xml)

On the Filters tab, set the following filter: (this is for my example, yours may differ)

BTS.ReceivePortName == AdventureWorks.Orders.Polling

Click Ok to close the Send Port Properties dialog

Start the application

Right click on the Application and select start

Check the Output directory

You will notice with my example, 5 files are create at a each polling interval in the directory and that each file represents an order.

Note: there are over 31,000 orders in the AdventureWorks database.

Summary

I hope this example give you the information that you need to get started with XmlPolling with BizTalk and the WCF-SQL Adapter.

Code for this Sample

BizTalk Server: Basics principles of Maps – Testing and Validation of maps (at design time) (Part 6)

by community-syndication | Apr 4, 2012 | BizTalk Community Blogs via Syndication

At design time we have, included in Visual Studio, 3 features that allow us to test and validate the maps: Test Map: Tests the selected map. Validate Map: Validates the map Debug Map: If a map is compiled successfully, Debug Map launches the XSLT debugger. It allows you to step through the generated XLST, just […]
Blog Post by: Sandro Pereira

Awarded BizTalk MVP, 2012

by community-syndication | Apr 3, 2012 | BizTalk Community Blogs via Syndication

I’m very pleased to have been awarded a Microsoft MVP for the third year in a row.

With new versions of SQL, VS and Windows shipping in 2012, and a bunch of very interesting things happening in Azure, it’s set to be a good year.

Using Node.js as an accelerator for WCF REST services

by community-syndication | Apr 3, 2012 | BizTalk Community Blogs via Syndication

Node.js is a server-side JavaScript platform “for easily building fast, scalable network applications”. It’s built on Google’s V8 JavaScript engine and uses an (almost) entirely async event-driven processing model, running in a single thread. If you’re new to Node and your reaction is “why would I want to run JavaScript on the server side?”, this is the headline answer: in 150 lines of JavaScript you can build a Node.js app which works as an accelerator for WCF REST services*. It can double your messages-per-second throughput, halve your CPU workload and use one-fifth of the memory footprint, compared to the WCF services direct.

Well, it can if: 1) your WCF services are first-class HTTP citizens, honouring client cache ETag headers in request and response; 2) your services do a reasonable amount of work to build a response; 3) your data is read more often than it’s written. In one of my projects I have a set of REST services in WCF which deal with data that only gets updated weekly, but which can be read hundreds of times an hour. The services issue ETags and will return a 304 if the client sends a request with the current ETag, which means in the most common scenario the client uses its local cached copy. But when the weekly update happens, then all the client caches are invalidated and they all need the same new data. Then the service will get hundreds of requests with old ETags, and they go through the full service stack to build the same response for each, taking up threads and processing time. Part of that processing means going off to a database on a separate cloud, which introduces more latency and downtime potential.

We can use ASP.NET output caching with WCF to solve the repeated processing problem, but the server will still be thread-bound on incoming requests, and to get the current ETags reliably needs a database call per request. The accelerator solves that by running as a proxy – all client calls come into the proxy, and the proxy routes calls to the underlying REST service. We could use Node as a straight passthrough proxy and expect some benefit, as the server would be less thread-bound, but we would still have one WCF and one database call per proxy call. But add some smart caching logic to the proxy, and share ETags between Node and WCF (so the proxy doesn’t even need to call the servcie to get the current ETag), and the underlying service will only be invoked when data has changed, and then only once – all subsequent client requests will be served from the proxy cache.

I’ve built this as a sample up on GitHub: NodeWcfAccelerator on sixeyed.codegallery. Here’s how the architecture looks:

The code is very simple. The Node proxy runs on port 8010 and all client requests target the proxy. If the client request has an ETag header then the proxy looks up the ETag in the tag cache to see if it is current – the sample uses memcached to share ETags between .NET and Node. If the ETag from the client matches the current server tag, the proxy sends a 304 response with an empty body to the client, telling it to use its own cached version of the data. If the ETag from the client is stale, the proxy looks for a local cached version of the response, checking for a file named after the current ETag. If that file exists, its contents are returned to the client as the body in a 200 response, which includes the current ETag in the header. If the proxy does not have a local cached file for the service response, it calls the service, and writes the WCF response to the local cache file, and to the body of a 200 response for the client. So the WCF service is only troubled if both client and proxy have stale (or no) caches.

The only (vaguely) clever bit in the sample is using the ETag cache, so the proxy can serve cached requests without any communication with the underlying service, which it does completely generically, so the proxy has no notion of what it is serving or what the services it proxies are doing. The relative path from the URL is used as the lookup key, so there’s no shared key-generation logic between .NET and Node, and when WCF stores a tag it also stores the “read” URL against the ETag so it can be used for a reverse lookup, e.g:

In Node we read the cache using the incoming URL path as the key and we know that “28cd4796-76b8-451b-adfd-75cb50a50fa6” is the current ETag; we look for a local cached response in /caches/28cd4796-76b8-451b-adfd-75cb50a50fa6.body (and the corresponding .header file which contains the original service response headers, so the proxy response is exactly the same as the underlying service). When the data is updated, we need to invalidate the ETag cache – which is why we need the reverse lookup in the cache. In the WCF update service, we don’t need to know the URL of the related read service – we fetch the entity from the database, do a reverse lookup on the tag cache using the old ETag to get the read URL, update the new ETag against the URL, store the new reverse lookup and delete the old one.

Running Apache Bench against the two endpoints gives the headline performance comparison. Making 1000 requests with concurrency of 100, and not sending any ETag headers in the requests, with the Node proxy I get 102 requests handled per second, average response time of 975 milliseconds with 90% of responses served within 850 milliseconds; going direct to WCF with the same parameters, I get 53 requests handled per second, mean response time of 1853 milliseconds, with 90% of response served within 3260 milliseconds. Informally monitoring server usage during the tests, Node maxed at 20% CPU and 20Mb memory; IIS maxed at 60% CPU and 100Mb memory.

Note that the sample WCF service does a database read and sleeps for 250 milliseconds to simulate a moderate processing load, so this is *not* a baseline Node-vs-WCF comparison, but for similar scenarios where the service call is expensive but applicable to numerous clients for a long timespan, the performance boost from the accelerator is considerable.

* – actually, the accelerator will work nicely for any HTTP request, where the URL (path + querystring) uniquely identifies a resource. In the sample, there is an assumption that the ETag is a GUID wrapped in double-quotes (e.g. “28cd4796-76b8-451b-adfd-75cb50a50fa6”) – which is the default for WCF services. I use that assumption to name the cache files uniquely, but it is a trivial change to adapt to other ETag formats.

BizTalk Server: Basics principles of Maps – Organizing Maps (Part 5)

by community-syndication | Apr 3, 2012 | BizTalk Community Blogs via Syndication

If you are dealing with large maps, they can become very complex and therefore very difficult to maintain and read. To minimize this problem, BizTalk server provides two main features to aid in the readability and maintainability of maps: Grid Pages Link Labels Grid Pages You can segment groups of links in to different grid […]
Blog Post by: Sandro Pereira