by community-syndication | Sep 15, 2012 | BizTalk Community Blogs via Syndication
Just a little note for myself this one.
At one of my customers where it is still BizTalk 2006 one of the build servers is intermittently getting issues so I wanted to run a script periodically to clean things up a little. The below script is an example of how you can stop cruise control and all of the biztalk services, then clean the biztalk databases and reset the backup process and then click everything off again.
This should keep the server a little cleaner and reduce the number of builds that occasionally fail for adhoc environmental issues.
REM Server Clean Script
REM ===================
REM This script is ran to move the build server back to a clean state
echo Stop Cruise Control
net stop CCService
echo Stop IIS
iisreset /stop
echo Stop BizTalk Services
net stop BTSSvc$<Name of BizTalk Host>
<Repeat for other BizTalk services>
echo Stop SSO
net stop ENTSSO
echo Stop SQL Job Agent
net stop SQLSERVERAGENT
echo Clean Message Box
sqlcmd -E -d BizTalkMsgBoxDB -Q “Exec bts_CleanupMsgbox”
sqlcmd -E -d BizTalkMsgBoxDB -Q “Exec bts_PurgeSubscriptions”
echo Clean Tracking Database
sqlcmd -E -d BizTalkDTADb -Q “Exec dtasp_CleanHMData”
echo Reset TDDS Stream Status
sqlcmd -E -d BizTalkDTADb -Q “Update TDDS_StreamStatus Set lastSeqNum = 0”
echo Force Full Backup
sqlcmd -E -d BizTalkMgmtDB -Q “Exec sp_ForceFullBackup”
echo Clean Backup Directory
del E:\BtsBackups\*.* /q
echo Start SSO
net start ENTSSO
echo Start SQL Job Agent
net start SQLSERVERAGENT
echo Start BizTalk Services
net start BTSSvc$<Name of BizTalk Host>
<Repeat for other BizTalk services>
echo Start IIS
iisreset /start
echo Start Cruise Control
net start CCService
by community-syndication | Sep 15, 2012 | BizTalk Community Blogs via Syndication
Back in June 2012, I had the opportunity to attend TechEd North America. At this event the BizTalk team gave us a glimpse into the next version of BizTalk and went over the Product Road map. You can read more about this Roadmap session here.
One of the areas that Microsoft wanted to address was better/seamless integration with Azure and more specifically with Service Bus Queues and Topics. The BizTalk team released a feature pack back in October 2010 that better enabled BizTalk to leverage the Service Bus Relay capabilities. This feature pack does work well but did not allow for connectivity to Service Bus Queues and Topics since they weren’t even available back then.
In the fall of 2011, the talented Paolo Salvatori wrote a very detailed article on how you can integrate BizTalk 2010 with Service Bus Queues and Topics. While Paolo’s solution does work it does require some additional effort and some people may be a little overwhelmed by the solution. But I do give credit to Microsoft and Paolo for coming up with a solution considering BizTalk 2010 was released much before Service Bus Queues and Topics were commercially available. Their solution just validates why BizTalk leveraging WCF is a good idea. When investments are made to WCF, BizTalk usually benefits. All in all, it was a good stop-gap for anyone desperate to integration BizTalk 2010 with Azure.
Fast forward to July 2012 when Microsoft released this BizTalk 2010 R2 CTP. Microsoft has delivered on making integration with Service Bus Queues and Topics very simple. The BizTalk team recently released a blog post which provides an overview of some of these new features. I thought it would be beneficial to provide a walk through for anyone interested in more details than what Microsoft included in that post.
Scenario
The scenario that we are about to explore includes a client application that will publish a typed Brokered message from a Console application to a Service Bus Queue. BizTalk will then use the new SB-Messaging adapter to retrieve the message and simply write it to the file system. As an experienced BizTalk guy, I like strongly typed messages and I am not afraid to admit it. So as part of this solution I am going to include a strongly typed BizTalk schema that I am going to deploy. For this walkthrough I am not going to transform this message but for anyone familiar with BizTalk they will be able to take this solution adapt it for their needs.
Client Application
- Launch Visual Studio 2012 and create a C# Console application. I called my application BrokeredMessageToBizTalk

- Next I will use the Nuget Package manager and installing the Windows Azure Service Bus package. You can access Nuget by clicking the following within Visual Studio: Tools – Library Package Manager – Manage Nuget Packages for Solution.

- Since I want deal with typed messages I am going to create a class called PowerOut. Since I work in the Power Industry I will over-simplify a use case that involves a customer whose power is out. They will send a message from a client application (it could be a web page, mobile phone app etc) to a Service Bus Queue.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace BrokeredMessageToBizTalk
{
public class PowerOut
{
public string CustomerName;
public string PhoneNumber;
public string Address;
}
}
- Within our Program.cs file we want to include the following code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using System.Runtime.Serialization;
using System.IO;
namespace BrokeredMessageToBizTalk
{
class Sender
{
const string QueueName = “PowerOutageQueue”;
static string ServiceNamespace = “YOUR_NAMESPACE”;
static string IssuerName =”owner”;
static string IssuerKey = “YOUR_KEY”;
static void Main(string[] args)
{
//*****************************************************************************************************
// Get Credentials
//*****************************************************************************************************
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(Sender.IssuerName, Sender.IssuerKey);
Uri serviceUri = ServiceBusEnvironment.CreateServiceUri(“sb”, Sender.ServiceNamespace, string.Empty);
MessagingFactory factory = null;
try
{
//***************************************************************************************************
// Management Operations
//***************************************************************************************************
NamespaceManager namespaceClient = new NamespaceManager(serviceUri, credentials);
if (namespaceClient == null)
{
Console.WriteLine(“\nUnexpected Error: NamespaceManager is NULL”);
return;
}
Console.WriteLine(“\nCreating Queue ‘{0}’…”, Sender.QueueName);
// Delete if exists
if (namespaceClient.QueueExists(Sender.QueueName))
{
namespaceClient.DeleteQueue(Sender.QueueName);
}
namespaceClient.CreateQueue(Sender.QueueName);
//***************************************************************************************************
// Runtime Operations
//***************************************************************************************************
factory = MessagingFactory.Create(serviceUri, credentials);
QueueClient myQueueClient = factory.CreateQueueClient(Sender.QueueName);
//***************************************************************************************************
// Sending messages to a Queue
//***************************************************************************************************
Console.WriteLine(“\nSending messages to Queue…”);
//Create new instance of PowerOut object
PowerOut po = new PowerOut();
po.CustomerName = “Stephen Harper”;
po.PhoneNumber = “613-123-4567”;
po.Address = “24 Sussex Drive”;
BrokeredMessage message = new BrokeredMessage(po, new DataContractSerializer(typeof(PowerOut)));
myQueueClient.Send(message);
//Uncomment this code if you want to write a sample file to disk
//using (FileStream writer = new FileStream(“c:/temp/file.xml”,FileMode.Create, FileAccess.Write))
//{
// DataContractSerializer ser = new DataContractSerializer(typeof(PowerOut));
// ser.WriteObject(writer, po);
//}
Console.WriteLine(“\nAfter running the entire sample, press ENTER to exit.”);
Console.ReadLine();
}
catch (Exception e)
{
Console.WriteLine(“Unexpected exception {0}”, e.ToString());
throw;
}
finally
{
// Closing factory close all entities created from the factory.
if(factory != null)
factory.Close();
}
}
}
}
Of the code above I want to highlight a couple different lines:
- The first one deals with the DataContractSerializer as seen below.
BrokeredMessage message = new BrokeredMessage(po, new DataContractSerializer(typeof(PowerOut)));
If you do not use a DataContractSerializer you can expect undesirable results when BizTalk retrieves the message from the queue. As mentioned in the recent BizTalk team blog post: “Brokered Message .NET API uses Binary encoding. To avoid this issue, you will need to use Text by explicitly provide your own serializer, instead of the default serializer.”
- The next deals with the few lines that have been commented out. Since I want to use typed messages within BizTalk, I can generate a sample XML message using the code below. This will allow me to generate a BizTalk schema using tools provided within Visual Studio.
//using (FileStream writer = new FileStream(“c:/temp/file.xml”,FileMode.Create, FileAccess.Write))
//{
// DataContractSerializer ser = new DataContractSerializer(typeof(PowerOut));
// ser.WriteObject(writer, po);
//}
*As a side note – wouldn’t it be nice if BizTalk supported native .Net Classes (from a messaging perspective) – hint, hint *
BizTalk Application
We can now create a BizTalk application. Since we are using the new BizTalk 2010 R2 CTP we can also use the latest version of Visual Studio 2012. As I mentioned earlier I want to process typed messages so our BizTalk solution will be very simple. It will only include a Schema. We will deploy this message to BizTalk so that when an instance of this message is published to the MessageBox that we will have a known schema deployed that will match this message type.
- We can now create a new BizTalk application. I have called mine PowerOutage and I have also added a Strong Name Key called PowerOutage.snk.

- Next I want to create a new Schema based upon the sample file that we previously generated. I can create this new schema by right mouse clicking on BizTalk project (PowerOutage) – Add – Add Generated Items.
- When prompted, click on the Generate Schemas label and then click the Add button.

- Select Well-Formed XML from the Document type dropdown and then we need to provide the name of our sample file. Click OK to proceed.

- We will now have a schema added to our solution that represents our PowerOutage class.

- Deploy our BizTalk Application
- When we launch the BizTalk Admin Console we will discover our PowerOutage application.
- We now need to create a Receive Port and corresponding Receive Location. In this situation we are going to use the SB-Messaging Adapter.

- When we click the Configure button we will have a few more properties to fill out including our URL. Our URL is going to include our Namespace (highlighted in Green) and our QueueName (highlighted in Orange)

- Next we need to click on the Authentication tab. Within this tab we will provide our Namespace as it relates to the Access Control Servers (ACS), an our Issuer Name and Key.

- The Properties tab is not used in this example. I will further examine it in a later post.
- With our Receive Port and Receive Location created we can no move on to our Send Port. For this example we are simply going to create a File Drop where we can write out the file that we have received from the Service Bus Queue.

- Since we do not have any Orchestrations we do need to wire up a subscription for our inbound message. In order to do this we will simply create a “Send Port Subscription” by setting filter.

- We can now Start our BizTalk application and bounce our Host Instance(if applicable)
Testing our scenario
- Next, launch our Console Application and we will discover that our message has been sent to our Queue.

- If we check the File Drop that was specified in our Send Port we should see a newly created file. When we open this file we should recognize the content that we populated in our Console application. Since we now have typed data within BizTalk it will be easy to transform it into other message types so that we can exchange data with other systems such as Line of Business (LOB) systems.

Conclusion
Now that wasn’t so bad was it? For experienced BizTalk people this process should be a breeze. The only area that initially hung me up was the DataContractSerialzer that is specified in our console application. The other good news is that we are just scratching the surface in this blog post. Look for more posts related to BizTalk and Service Bus integration using the new BizTalk 2010 R2 CTP.
by community-syndication | Sep 14, 2012 | BizTalk Community Blogs via Syndication
I have got stung by this one again. I have created a WCF-netTCP service and tried to exposed its metadata. I tried all the usual solutions; http://rohitbiztalk.blogspot.co.nz/2011/01/exception-root-element-is-missing-for.html http://www.dotnetbase.co.uk/post/2012/01/21/Root-element-is-missing-error-when-browsing-WCF-Mex-Endpoint-in-BizTalk.aspx http://go4answers.webhost4life.com/Example/exception-root-element-missing-48916.aspx but nothing worked this time. This is very frustrating because last week on the same server one of my colleagues had deployed meta data service and […]
Blog Post by: mbrimble
by community-syndication | Sep 14, 2012 | BizTalk Community Blogs via Syndication
One of the great new features included in Visual Studio 2012 is the ability to create professional looking storyboards using Microsoft PowerPoint. Storyboards allow you to create very realistic mock-ups of an application using shape libraries designed for the particular type of application you are proposing. Examples include Windows application, Web application, Windows Phone 7 applications and more.
Microsoft has released a number of new storyboarding shapes for people wanting to create Storyboards for iOS, iPad or iPhone applications.
NOTE: To get the Storyboarding feature in PowerPoint, you must have one of the following products installed.
- Visual Studio Premium 2012 with MSDN
- Visual Studio Ultimate 2012 with MSDN
- Visual Studio Test Professional 2012 with MSDN
How to get the new shapes
- Download the Storyboard shapes you want from the Visual Studio Gallery
- Open Microsoft PowerPoint and select the Storyboarding tab
- Select Import Shapes
- Locate the “*.SBSX” file you downloaded in step 1 and click Open.
Your new storyboard shapes will appear in the Storyboard Shapes toolbox.
If you want to learn more about how to use the Storyboarding features, consider taking our Managing Projects with Team Foundation Server 2012course. We have an entire module devoted to getting up to speed quickly.
by community-syndication | Sep 14, 2012 | BizTalk Community Blogs via Syndication
It’s hard to write technical books nowadays. First off, technology changes so fast that there’s nearly a 100% chance that by the time a book is published, its subject has undergone some sort of update. Secondly, there is so much technical content available online that it makes books themselves feel downright stodgy and out-dated. So […]
Blog Post by: Richard Seroter
by community-syndication | Sep 14, 2012 | BizTalk Community Blogs via Syndication
A few days ago I received an error while restarting the BizTalk host instances on one of the BizTalk servers here after an update. Seems like changes to BizTalk config file were to blame and this article shows how to fix this error.
by community-syndication | Sep 14, 2012 | BizTalk Community Blogs via Syndication
As preparation for our 5.0 release in October we are presenting BizTalk360 in various live user group presentations this month. Here are the list of event during the month of September. Norwegian user group (NoBug), September 18th, Gothenburg, Sweden Norwegian BizTalk User group (NoBug): NoBug is community for BizTalk users and developers in the Nordic […]
The post BizTalk360 at Norwegian user group and BizTalk Innovation day appeared first on BizTalk360 Blog.
Blog Post by: Saravana Kumar
by community-syndication | Sep 13, 2012 | BizTalk Community Blogs via Syndication
As an BizTalk Administrator/Technical Application Engineer, I regularly need to fix problems with BizTalk that I am not able to fix easily with the out-of-the-box tools. For example, at the moment we experience an issue which leads to suspended messages on a particular receive location. To fix that issue I need easy access to these suspended messages and their content. Off course I can get to the content with the BizTalk Administration Console, but because I need to fix about 50 of those messages per day (awaiting a structural solution), I need easier access to the MessageBoxDb to save time and to prevent myself from RSI, due to so many mouse clicks.
Since a couple of years I maintain BTSDecompress on CodePlex. This tool enables me to query the BizTalk databases and retrieve message content and context. Although this tool works fine for me, the main disadvantage is that, until now, it only supported BizTalk 2006. Therefore only a limited group of BizTalk users could potentially benefit of this software.
Because of the issue I mentioned in the first paragraph, lately I’ve been working a lot on that tool. It has reached version 1.5 and in this version a number of important improvements have been applied. Here follows a list of the most important changes:
Support of BizTalk releases
– BizTalk 2006
– BizTalk 2010
– BizTalk 2010 R2 CTP
I expect BTSDecompress to work with the other major BizTalk releases as well (2004, 2006 R2, 2009), but I did not (yet) test it, so I don’t mention these versions here.
Support of Windows versions
– Windows Server 2003
– Windows Server 2008 R2
– Windows 7
I expect BTSDecompress to work with the other major Windows versions as well (XP, Vista, 2008), but I did not (yet) test it, so I don’t mention these versions here.
Query maintenance
It is now possible to Create, Open, Save and Save As queries. This makes it a lot easier to maintain multiple queries.
ebXML support
It was already possible to fire XPath queries on the message content, but you can now do that as wel upon ebXML headers and envelopes.
Where to find
BTSDecompress is Open Source software and can be found here:
btsdecompress.codeplex.com
by community-syndication | Sep 13, 2012 | BizTalk Community Blogs via Syndication
We recently announced the availability of BizTalk Server 2010 R2 CTP. BizTalk Server 2010 R2 comes with a lot of features to take advantage of the whole cloud push. In the last post, we have shown how you could leverage the power of the Azure IaaS cloud to get your BizTalk deployments up and running in no time. In this post, we will talk another feature which will help you take advantage of the cloud – the Service Bus Messaging adapter. The Service Bus Messaging adapter, in a nutshell, allows BizTalk Server to read and send messages to Azure Service Bus Queues and Topics/Subscriptions.
The presence of a messaging infrastructure on the cloud has many advantages – which is not the subject of this blog, but is well documented elsewhere. Let us take a simple scenario: Our customer is an insurance company and it deals with multiple partners who help in administering insurances to the end customers. An on-premise BizTalk Server would handle insurance claims coming from multiple partners. Each of the partners submits these claims to an incoming Service Bus queue. BizTalk Server picks up these claims from the incoming queue and processes them. Once it is done, BizTalk Server would publish the status of the claims to an outgoing topic. The partners could create a subscription on the topic to receive the claim status. Such a scenario that leverages Azure Service Bus can now be easily integrated with BizTalk Server with the new Service Bus Messaging adapter. Let us have a quick walk through of this adapter.
Getting Started
In order to get started, you will need two things: A Windows Azure Service Bus namespace and BizTalk Server 2010 R2 CTP. You can get both of these on Windows Azure – sign up for a free trial here if you do not have one. Now, as outlined in this article, you can create your queue/topic. And as outlined here you can quickly create an instance of BizTalk Server 2010 R2 CTP running in a Windows Azure Virtual Machine.
Receiving messages from a Queue or a Subscription
BizTalk Server 2010 R2 provides a receive adapter to fetch messages from a Windows Azure Service Bus queue or a subscription. The receive adapter is one-way and will work with messages that you post on the queue. The adapter is simple to set up and configure. You just need to provide the URL of the Service Bus queue or subscription from where you need to pick the messages from and the credentials for authenticating with Service Bus. To set up a receive adapter for Service Bus Queue:
(1) Create a one-way receive port in your BizTalk application.
(2) Create a new receive location and select “SB-Messaging” as the Transport Type as shown below.
(3) Click on “Configure” to configure the properties of the receive location. In the transport properties General Tab, specify the URL for the queue or subscription from where BizTalk Server needs to fetch message from. You could also configure connection properties like open/close/receive timeout as well as the prefetch count. The Prefetch Count specifies the number of messages that BizTalk Server will fetch at a time. This can help increase the throughput of the adapter as well.
(4) On the Authentication Tab, you need to specify how BizTalk Server will fetch the required ACS Token for authenticating with Service Bus. You can read on how Service Bus uses Access Control Service for authentication here. In a nutshell, you will need to specify the Access Control Service URL for the service namespace. It is usually derived from the service bus namespace (suffixed with “-sb”) and you will only need to update the service namespace in the default template. You can find this in the Azure management portal as well. You also need to specify an issuer name and issuer key. You will need to ensure that the service identity has a Listen claim. If you are using the default service identity (“owner”), it will have the necessary claims.
(5) Click on “OK” or “Apply” to create the Receive Location.
You can then start your Receive Location and BizTalk Server will now start to fetch messages from the Queue or subscription. Easy!
Handling Brokered Message Properties in Receive Adapter
The SB-Messaging receive adapter understands BrokeredMessage properties. This means two things. First, BizTalk Sever 2010 R2 comes with a predefined property schema for all the standard properties of a BrokeredMessage. The adapter will also promote these properties automatically for you. Second, the adapter can write custom user-defined Brokered Message properties in the BizTalk message context. And, if you desire, you could also promote them. Promoting them will allow you to use them in your routing filters. For example, for our insurance claims applications, different applications could be routed based on who the type of insurance, the partner, the claim amount, etc. These properties could be defined as Brokered Message properties and passed on with the incoming message. These properties could be used to route the message to different backend systems or workflows/orchestrations in BizTalk Server. To promote the properties though, you need to create and add a property schema in your BizTalk application. Then, on the properties Tab of the adapter, you could specify the namespace for your schema and check the option to promote the property.
Sending messages to a Queue or a Topic
BizTalk Server 2010 R2 also provides a send side adapter for posting messages to a Service Bus Queue or Topic. This is a one-way send adapter. To set up a send port for posting messages to a Service Bus Queue or a Topic:
(1) Create a Send Port and select SB-Messaging as the Transport Type. Click Configure to configure the properties of the adapter.
(2) Click “Configure” to configure the transport properties of the send adapter. You need to specify the URL of the Service Bus Queue or Topic where the message should be posted.
(3) On the Authentication Tab, you enter the credentials for authenticating with Service Bus. This is the same as you see on the receive adapter.
(4) Click on “OK” to save the transport properties of the adapter.
(5) Specify the other properties of your Send port like pipeline, handler, Filters, etc.
(6) Click “OK” to finish creating your Send port.
Now, you can enlist and start the send port. The adapter will now post outgoing BizTalk message to the Service Bus queue or topic.
Handling Brokered Message Properties in Send Adapter
As in the case of receive adapter, the send adapter is aware of Brokered Message properties. If the outgoing BizTalk message has any of the standard Brokered Message in its context, the adapter will automatically set them as Brokered Message property. In addition, you could also specify defaults as part of the Send port properties. For custom user defined Brokered Message, you could specify a namespace as part of the adapter configuration. The adapter will take any property in that namespace and set them as Brokered Message Properties.
Finally, a note on serialization
When you start using the adapter, you may find that the message you receive in BizTalk Server is garbled – especially if you are using the Service Bus .NET API. Let me explain why this happens and what the adapter expects.
The Service Bus messaging adapter just fetches the stream in the incoming message and submits it to BizTalk Server. While sending out a BizTalk message, it simply uses the content as a stream. We preserve the message format on the wire. So, if you write or read the stream directly in your code, say using the Service Bus REST API, you would see the same data in the payload as you would expect. However, if you are using the Service Bus .NET API, you may find that there is a serialization issue if you use the default serializer (DataContractSerializer with binary XmlDictionaryWriter). This is because the default serializer in the Brokered Message .NET API uses Binary encoding. To avoid this issue, you will need to use Text by explicitly provide your own serializer, instead of the default serializer.
For sending message:
// For sending message using DataContractSerializer with Text encoding
var message = new BrokeredMessage(data, new DataContractSerializer(typeof(MyDataType)));
While reading the message:
// For receiving message using a DataContractSerializer with Text encoding
var data = message.GetBody<MyDataType>(new DataContractSerializer(typeof(MyDataType)));
You could, of course, directly read the stream as well. For a detailed write-up on the content serialization of Service Bus messages, you can refer to this blog post.
Next Steps
This post provides an overview of the new Service Bus messaging adapter in BizTalk Server 2010 R2. This is one of the new features that we have enabled with BizTalk Server 2010 R2. With this adapter, BizTalk Server can seamlessly integrate with your applications that leverage the Windows Azure Service Bus Queues and Topics. We encourage you to try out this feature and provide your comments and feedback. You can use the BizTalk forum to post your questions/queries as well.
Thanks
BizTalk Server Team
Blog Post by: BizTalk Blog
by community-syndication | Sep 13, 2012 | BizTalk Community Blogs via Syndication
Often ignored, but a really important, persistence points in Biztalk are the key issue in dealing with Orchestration Performance. Many applicative problem come from a misunderstanding of this concept. Sandro perreira (a great biztalk MVP) wrote a great article about it :http://sandroaspbiztalkblog.wordpress.com/2009/10/23/biztalk-orchestration-%E2%80%93-understanding-persistence-points/ You should read it, All BizTalk developper must be careful to those concepts […]
Blog Post by: Jeremy Ronk