Error Calling BizTalk WCF-WSHttp Endpoint

Error Calling BizTalk WCF-WSHttp Endpoint

After exposing an external XML schema as a BizTalk WCF-WSHttp end point using the BizTalk WCF Service Publishing Wizard I fired up SOAPUI and attempted to call my web service using a test SOAP message… However I was baffled by this obscure response: <s:Envelope xmlns:s=”” xmlns:a=””>  <s:Header>   <a:Action s:mustUnderstand=”1″></a:Action>  </s:Header>  <s:Body>   <s:Fault>    <s:Code>     <s:Value>s:Sender</s:Value>     <s:Subcode> […]
Blog Post by: James Corbould

BizTalk Server and BizTalk360 at TechEd, Europe 2013

This week we are present at TechEd, Europe which is happening in the sunny city of Madrid, Spain. We had the opportunity to co-present in two sessions. The sessions were primarily focused on Microsoft BizTalk Server, during the session we also presented BizTalk360 showcasing how partner eco-system is adding value to the already powerful BizTalk […]

The post BizTalk Server and BizTalk360 at TechEd, Europe 2013 appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

How to create a Maintenance Plan to delete BizTalk Database Backups files

How to create a Maintenance Plan to delete BizTalk Database Backups files

BizTalk Server database databases and their health are very important for a successful BizTalk Server database messaging environment. This is nothing new and everybody knows! Although there can be many settings that we can configure, like auto-growth settings for BizTalk Databases (you can learn more here), there are two main things that we must understand […]
Blog Post by: Sandro Pereira

Windows Azure BizTalk Services – The “Dedicated” Model

The recently released Windows Azure BizTalk Services is described as a dedicated service. In this post, we’ll cover what dedicated means, and what all can be achieved in a dedicated service, which otherwise would have been difficult to do so in a multi-tenant service.

Windows Azure BizTalk Services is an Enterprise Application Integration platform running in Windows Azure. It enables (with its current feature set and the additional features which we plan to light up shortly) running integration workloads end-to-end in Azure. Integration workloads are subject to certain requirements and constraints – things such as predictable performance, compliance criteria, etc. We’ll now see how this is achieved in Windows Azure BizTalk Services.

Dedicated Compute

When you sign up for BizTalk Services, no matter what SKU you choose, you get your own Virtual Machine(s). The amount we provision for you depends on what SKU you choose and how many units you scale out to. But essentially, the processing power of the VM is entirely yours. Depending on whether you need to validate-transform 100 messages a second or a 1000 messages a second, whether your messages are 10kb in size or a 100kb in size – once you determine how much compute power is needed to process a specific workload size, it is very easy to calculate how much you need to scale up or scale down as your workload requirements change.

This is a clear advantage over a multi-tenant service, where processing power and memory are shared amongst workloads (belonging to different customers) which happen to be running on the same virtual machine. An increase in compute cycles used by the workload of one customer can result in reduced available resources for the workloads of other customers on that same machine.

User Code Execution

Since we provide you with your own set of dedicated virtual machines, this gives you the advantage of being able to have your custom code execute on that machine. Custom code written by other customers’ will not execute on your virtual machine (just as your custom code will not execute on theirs’). A poorly written .NET function by some other customer that hogs the CPU and RAM will only affect that customer’s machine – not yours; your code and processing will continue unhindered.

Additionally, your custom code is your Intellectual Property. Since it only executes on your machine, no other customer has access to it.

Message Processing Security

Having your own dedicated virtual machine again helps here. Your messages are only processed on your machine, and only through code which either you (your custom code) or we (Microsoft – Windows Azure BizTalk Services) have authored. Rogue code cannot get access to your messages.

Additionally, since we set up a dedicated endpoint for you, you can provide your custom SSL certificate which will be used to authenticate your endpoint to the clients sending Messages to your bridge endpoint.

Configuration Security

When you configure a Bridge and its associated Artifacts, there may be various pieces of data which need to be kept confidential. In your Bridge you may be routing to an external Web Service, whose credentials are part of the configuration. The Maps which you use in the Bridge may be your Intellectual Property which you need to protect.

Every customer using BizTalk Services gets a separate dedicated database (we provision this internally) in which your configuration is stored. This includes your Bridge configuration, your artifacts such as schemas and transforms, your custom code assemblies, your partners and agreement configuration – basically everything. Even the certificates that you upload for communication with your external partners.

All this configuration data is encrypted, and the encryption keys and certificates are unique per customer. Thus, even if the encryption key of one customer gets lost, it doesn’t compromise your configuration data. We also have the ability to roll over the encryption keys for each customer independently.

Better Monitoring and Diagnostics

With a dedicated service, it becomes much easier to diagnose production issues. For example – if you see the message processing throughput is lower than what you expected, you can quickly navigate to the Azure Portal, select your BizTalk Service deployment, and take a look at the performance counters for your service. We can easily collect this data and display it to you since only your code and your messages are processed on your dedicated virtual machines.

Control over hotfixes / service updates

With BizTalk Server, we’ve generally released newer versions every 2 years. With BizTalk Services, we plan to have much shorter release cycles – a roll out of new features keeping with the cadence of other Azure Services, and an even shorter release cycle for rolling out hotfixes.

We understand that for enterprise customers, picking up every latest release is at times not possible. Testing and upgrading takes time when mission critical applications are being run. With BizTalk Services, we give you the flexibility to choose when you want to accept a hotfix release / feature release. You are free to continue using the release which you are on for as long as it’s supported, while you test out the newer release in a separate staging deployment. And when you’re ready, with a single click, your deployment can be upgraded to the new version where newer features will light up and annoying bugs have been fixed.

This is again something possible only in a dedicated service – since we can have different product versions deployed for different customers depending on which version each customer has tested and needs.


It should be clear the advantages of the dedicated model that has been adopted for Windows Azure BizTalk Services. It is truly a Managed Enterprise Service – you get a Service managed by Microsoft in terms of infrastructure, installation, configuration, updates; while you yet have all the requirements of an enterprise application solved – data isolation and security, decide when to upgrade versus not, predictable performance, etc.

Blog Post by: BizTalk Blog

Summary of what we have learned from TechEd, Madrid-Keynote

This week I’m at Madrid attending TechEd, Europe. I’ll try to blog the important content I’ve learned this week to keep as a record for myself and to show to the outside world, what’s happening here in Madrid. Keynote: First day of the TechEd, Europe keynote is kick started by Brad Anderson, Corporate vice president. […]

The post Summary of what we have learned from TechEd, Madrid–Keynote appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

Windows Azure BizTalk Service Powershell Cmdlets

Windows Azure BizTalk Service provides a rich set of scripting and automation tools. Chief among them is the Powershell Cmdlets. These cmdlets enable the user to write long running scripts, for eg., get notified via email in case any of the FTP sources are down, clear the tracking DB at regular intervals, etc.

While a start, we will be constantly enhancing the capabilities of these cmdlets including their ease of use.


  1. Install the Windows Azure BizTalk Services SDK. See Installing the Windows Azure BizTalk Services SDK – June 2013 Preview for instructions.
  2. Open a PowerShell window with administrator privileges.
  3. Run import-module to import the BizTalk Services module to the current session.

Import-module “C:\Program Files\Windows Azure BizTalk Services SDK\Microsoft.BizTalk.Services.Powershell.dll

NOTE: You need powershell 3.0 installed to use the Windows Azure BizTalk Services Powershell cmdlets.


Following are the cmdlets that are made available as part of the BizTalk SDK.

Cmdlet Name




Lists bridges deployed



Deletes bridge deployed



Adds an XML schema artifact



Adds a transform artifact



Adds an assembly artifact




Adds a certificate artifact




List artifacts deployed




Save artifacts locally




Removes artifact deployed




Starts Bridge source




Stops Bridge source




Get source status



Restarts BizTalk Service



Clear tracking store


For a detailed description/usage of the above powershell cmdlets, please refer to our documentation here.


Let’s look at how these powershell cmdlets may be used to address some complex user scenarios.

$a = ‘myAcsNamespace’




Remove all bridges under Samples

To remove all bridges under a folder say Samples, you would have to get all the bridges under samples, which can be done using Get-AzureBizTalkBridge, and then pipe the list of bridges you get to Remove-AzureBizTalkBridge which removes each of those bridges.

Get-AzureBizTalkBridge –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d –BridgePath Samples -Recurse | %{Remove-AzureBizTalkBridge –AcsNamespace $a –IssuerName $b -IssuerKey $c –DeploymentUri $d -BridgePath $_.Path -NoPrompt}

Start all sources that are stopped for bridges under Samples

Here, first you have to get all bridges under Samples folder. This can be done using the Get-AzureBizTalkBridge cmdlet. Once you get this list, you can pipe the output to Get-AzureBizTalkBridgeSource which will return you all the sources for each bridge. You filter that list by only getting the ones that are Stopped. Once you have this list of sources that are stopped, you can pass it along to Start-AzureBizTalkBridgeSource to start them all.


Get-AzureBizTalkBridge –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d -BridgePath Samples –Recurse | %{Get-AzureBizTalkBridgeSource –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d -BridgePath $_.Path} | where {$_.Status –ieq ‘Stopped’} | %{Start-AzureBizTalkBridgeSource –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d –BridgePath $_.BridgePath}

Download all artifacts under Samples

To download all the artifacts under Samples, you use the Get-AzureBizTalkArtifact to get all artifacts and pipe them to Save-AzureBizTalkArtifact which saves the artifacts locally.


Get-AzureBizTalkArtifact –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d -ArtifactPath ‘Artifact1’ –Recurse | %{ Save-AzureBizTalkArtifact –AcsNamespace $a –IssuerName $b –IssuerKey $c  DeploymentUri $d -ArtifactPath $_.ArtifactPath –SavePath ([string]::Format(‘{0}{1}’, ‘E:\TestFolder\’, $_.ArtifactName)) -Overwrite }

Remove all XML schemas

To remove all XML schemas, you first Get-AzureBizTalkArtifact for all artifacts and filter them down to those of type XMLSchemaDefinition. You then pipe this list to Remove-AzureBizTalkArtifact and remove each one of them.


Get-AzureBizTalkArtifact –AcsNamespace $a –IssuerName $b –IssuerKey $c –DeploymentUri $d –Recurse | where { $_.ArtifactType.ToString() –eq ‘XmlSchemaDefinition’} | %{ Remove-AzureBizTalkArtifact –AcsNamespace $a IssuerName $b –IssuerKey $c –DeploymentUri $d –ArtifactPath $_.ArtifactPath -NoPrompt }


Blog Post by: BizTalk Blog

BizTalk: The Difference Between Group Max Occurs and Max Occurs

Published By: Bill Chesnut

I have always wondered what Group Max Occurs did, recently doing a code review I ran into a case where they were using Group Max Occurs, so it was now time for me to determine exactly what it does.

I have always used Max Occurs on a node that I wanted to repeat, as below:

The sample XML produced by this schema is below with 3 Details nodes:

So know we now what Max Occurs does, what does Group Max Occurs?

I have changed the schema to use Group Max Occurs.

The first thing I noticed was that the maxOccurs was moved from the element definition for Details to the sequence definition under the Details node.

I tried to validate the same XML document as above and I got the following error.

So I decided to generate a document with the Group Max Occurs, this is the resulting document.

You will notice that the Details node does not repeat but the nodes inside of the Details nodes do.

I now understand the difference between Group Max Occurs and Max Occurs, Group Max Occurs repeats the nodes inside of the element that has Group Max Occurs set, the Max Occurs repeats the element and it contents.

Also, remember that if you do not validate the resulting document from a mapping operation it will not catch the difference, because BizTalk does not do full XML validation unless you have a pipeline component with the XMLValidator included.

More …

BRE Pipeline Framework now compatible with BizTalk Server 2013 – updated installer v1.3.1 now available

BRE Pipeline Framework now compatible with BizTalk Server 2013 – updated installer v1.3.1 now available

The BRE Pipeline Framework has now been tested against BizTalk Server 2013 and an installer has been created to ensure the pipeline component gets copied to the correct program files folder. Download the updated installer v1.3.1 from the codeplex project page if you are interested in using the framework with BizTalk 2013. This installer works […]
Blog Post by: Johann