May 21, 2013 at 4:00 PM

At a certain point in time when installing BizTalk, you will need to install some extra “components”. In the BizTalk installation wizard this is referred to as a prerequisite file.

This file can be downloaded automatically from within the wizard, but most likely you have some good reasons not to do that:

  • You’re installing more than 1 BizTalk server and/or environment at the same time
  • You do not want to wait for downloads to finish
  • Internet access is not available on BizTalk servers
  • etc …

There are a bunch of reasons why a seasoned BizTalk professional/administrator needs to have a backup copy of these files available just in case you might ever need them…

Below you can find a list of all BizTalk prerequisite files I have come across and where to find any further localized versions in case you might need them.

 

BizTalk 2013

The following list is taken from a blog post I came across here.

Platform Localization Link
Windows Server 2008 R2 (64 bit) EN Download
Windows Server 2012 (64 bit) EN Download
Windows 7 (32 bit) EN Download
Windows 8 (32 bit) EN Download
Windows 8 (64 bit) EN Download

 

BizTalk 2010

The following list is taken from the installation document for BizTalk 2010 found here.

Platform Localization Link
Windows Server 2008 (32 bit) EN Download
Windows Server 2008 (64 bit) EN Download
Windows Server 2008 R2 EN Download
Windows Vista (32 bit) EN Download
Windows Vista (64 bit) EN Download
Windows 7 (32 bit) EN Download
Windows 7 (64 bit) EN Download

 

BizTalk 2009

The following list is taken from the installation document for BizTalk 2009 found here.

Platform Localization Link
Windows XP (32 bit) EN Download
Windows XP (64 bit) EN Download
Windows Server 2003 (32 bit) EN Download
Windows Server 2003 (64 bit) EN Download
Windows Vista (32 bit) EN Download
Windows Vista (64 bit) EN Download
Windows Server 2008 (32 bit) EN Download
Windows Server 2008 (64 bit) EN Download

 

BizTalk 2006 R2

The following list is taken from the installation document for BizTalk 2006 found here.

Platform Localization Link
Windows XP (32 bit) EN Download
Windows XP (64 bit) EN Download
Windows Server 2003 (32 bit) EN Download
Windows Server 2003 (64 bit) EN Download
Windows Vista (32 bit) EN Download
Windows Vista (64 bit) EN Download

 

I hope this helps someone who needs the quick download!

 

[Updated 2013-05-21]: Added the BizTalk 2013 links to this post.

Posted in: BizTalk

Tags: ,


May 17, 2013 at 4:05 PM

 

BizTalk2013 logo

BizTalk 2013 is out, but this is obviously old news for most of you. With a lot of new features and support for on premises, or in the cloud, this new version seems exciting and maybe challenging…

To help you overcome any potential issues and to make sure you are ready for the new version, Codit (partner of the global Microsoft Integration Alliance "IMPACK") organizes the European edition of the global BizTalk 2013 launch in Belgium - preceded by Breeze in Australia and in parallel with Matricis in North-America.

What will I learn?

  • What is new in Microsoft BizTalk Server 2013? New features!
  • The new cloud capabilities of BizTalk 2013
  • BizTalk 2013 & its new adapters
  • Demonstration of the Nevatech SOA governance tool called Sentinet - a flexible and scalable solution for the SOA governance of your BizTalk (or Azure) integration environment
  • Exclusively discover Windows Azure BizTalk Services (WABS) - Hear from the experts: Codit is selected Microsoft launch partner of WABS and is one of the first partners worldwide to incorporate these innovative services as a core component in its solution.

Practical details

  • Date: Wednesday May 29th, from 8:30 AM to 16:30 PM (including lunch)
  • Location: Communicatieloft in Ghent, easy accessible via R4 (large parking) & walking distance from railway station Gent Sint-Pieters
  • Participation is free, but open for pre-registrants only
  • Language: English
  • Bring your business cards!

Speakers & Sessions

  • Keynote: Microsoft Cloud OS as the Foundation for your Hybrid Cloud
    • Rudy Van Hoe, Business Manager, Server and Cloud Platform at Microsoft
  • Windows Azure BizTalk Services; notes from the field
    • Sam Vanhoutte, CTO Codit
  • SOA Governance and Runtime Capabilities Enablement for BizTalk Server 2013
    • Andrew Slivker, CTO Nevatech
  • BizTalk Server 2013 in Windows Azure IaaS
    • Peter Borremans
  • Maintaining chain integrity after a system or disaster recovery
    • Jasper Defesche, Axon Olympus
  • New adapters in BizTalk 2013
    • Toon Vanhoutte

 

For more information and registration, visit this page on our website.

Hope to see you there!

Posted in: BizTalk | Events

Tags: ,


April 30, 2013 at 4:30 PM

On the latest version of BizTalk (2013): a new adapter was introduced for natively working with REST endpoints, using WCF technology: the WCF-WebHttp Adapter. 

After the beta version was released we could find some very good articles about this adapter, but since it is a new adapter there's a lot of ground to cover.
At the moment of my writing, the  MSDN website has very few information about it, so time to give something to the community... 

 


On this small article I will focus on using HTTP headers with the new adapter.

In this scenario I wanted to set HTTP content type at the header level. This could be done in two ways: using the adapter properties or writing in the message context. 

 

Adapter properties 

Using the adapter properties is a fairly simple task, we just need to go to our port properties and then adapter properties. On the last tab "Messages" we have a text area destined to Outbound HTTP Headers. Every HTTP header that we place here will be included on the message that will be sent (I'm using a send port for this example).

 

 

By default, WCF-WebHttp sends your message with as "Content-Type: application/xml; charset=utf-8", if you want to invoke a REST service with a GET request, for instance, you will have to insert the following code in the HTTP Outbound Headers:

Content-Type: application/http

And use a PassThruTransmit pipeline component, or another component that doesn't validate XML.


Message Context

If we need to set the HTTP headers at runtime we could do this mainly on orchestrations or pipeline components by writing the property on context.

 

We have two properties available to set in the headers: 

Property Name

Property Schema

Adapter

UserHttpHeaders

http://schemas.microsoft.com/BizTalk/2003/http-properties

HTTP

OutboundCustomHeaders

http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties

WCF-*


Both options will not raise any error if you try to write/promote them, but it won't work!
UserHttpHeaders is for HTTP adapter only, if you use it you will send the message as application/xml since the property isn't read by the adapter and since we are assuming that there is no HTTP header configured on the adapter properties.
The same goes for the OutboundCustomHeaders, it's for SOAP messages only (and using an XML structure), if you try to use it you will have the following error:
 

System.InvalidOperationException: Envelope Version 'EnvelopeNone (http://schemas.microsoft.com/ws/2005/05/envelope/none)' does not support adding Message Headers. 

If you happen to have an XML error it's probably because OutboundCustomHeaders is expecting an XML structure and you are not passing one.

 

So after dwelling on this issue for some time I inspected the new Biztalk 2013 property schema for WCF, and we can clearly  see some new properties related to the WCF-WebHttp adapter: 
 

Name

Type

Description

InboundHttpHeaders

xs:string

The HTTP headers present in the inbound message received over a HTTP transport

InboundHttpStatusCode

xs:string

The HTTP status code of the response message

InboundHttpStatusDescription

xs:string

The HTTP status description of the response message

InboundHttpMethod

xs:string

The HTTP Verb of the request message

OutboundHttpStatusCode

xs:string

The HTTP status code of the response message

OutboundHttpStatusDescription

xs:string

The HTTP status description of the response message

SuppressMessageBodyForHttpVerbs

xs:string

Removes the Message Body from the outbound request message, for the specified HTTP Verbs

HttpHeaders

xs:string

Sets HTTP headers for the outbound message

VariablePropertyMapping

xs:string

Provides the URL Template Variables and Message Context Properties mapping configuration

HttpMethodAndUrl

xs:string

Provides the HTTP Method and URL mapping configuration

 

In my scenario I wanted to use a send port, so the property that suits my purpose was HttpHeaders
All I had to do was write the content type into the property, without the need of promoting it. 

Here's part of my Execute() method of the custom pipeline component, where I set the message content type to application/atom+xml.


public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, Microsoft.BizTalk.Message.Interop.IBaseMessage pInMsg)
{
    // Some non important logic here

    pInMsg.Context.Write("HttpHeaders", "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties","content-type: application/atom+xml");

    return pInMsg;
}


Another important note that I should add, is about the adapter HTTP header limitations:
If you are planning to change the HttpHeader per message it won't work with a standard port, since by "design" the adapter uses the properties by port and not by message. If you need to change the header at runtime (per message) you will need to use a dynamic port instead.


And that’s it Smile

Ricardo Marques

 

 

 

Posted in: BizTalk | REST | WCF

Tags: , ,


April 26, 2013 at 3:34 PM

Hello,

One of our Managed Services customers had a problem where a message got suspended with the following error:

They already looked into the issue, tested the username and password for the share, etc ...
The platform is a multi-server platform with 2 BizTalk servers within the same BizTalk group.

 

Troubleshooting

I was digging into the issue and saw that it was very likely that only one of the servers had the issue (the server where the message got suspended was always the same). 

So during the retry within BizTalk, some messages got processed by the other server as BizTalk chooses the processing server depending on load...
Sometimes though, a message got only processed through the first server, leading to a suspended message eventually.

 

I was digging into the eventlog and stumbled into this (system eventlog):

 

I checked and there was indeed a stored username/password on the first server for connecting to the server hosting the file-share:

(This were credentials of a BizTalk operator and his password had changed recently).

When I removed the stored credentials the issue was resolved. (Also when you define the credentials in the send port configuration).

So stored credentials were used instead of the credentials defined in the BizTalk host to connect to the fileshare!

 

For more information on stored passwords, please see MSDN: http://technet.microsoft.com/en-us/library/cc733968(v=ws.10).aspx

 

Hope this helps,

Brecht


April 10, 2013 at 4:08 PM

In an XSLT mapping I wanted to convert the node with its child nodes to a node with attributes. 
I noticed that the source schema contained more than 60 child nodes and most of them could be optional. The transform of this mapping would result in a big piece of code for some logic that perhaps could be made in a better way.

This process could be optimized by creating the attributes in a dynamic way. 

For illustration, I am using this small piece of XML:

<Contact>
	<Name>Reception</Name>
	<Phone>+32 9 247 32 65</Phone>
	<Mobile>+32 475 36 45 78</Mobile>
	<Fax>+32 9 247 32 66</Fax>
	<Email>reception@company.be</Email>
</Contact>

This is the desired output:

<Contact Name='Reception' Phone='+32 9 247 32 65' Mobile='+32 475 36 45 78' Fax='+32 9 247 32 66' Email='reception@company.be' />

The Problem

I am looping through each child node with the query Contact/* (there is no namespace for simplicity reasons). The function name() is able to give the name of the node. I store this name in the variable $attributeName, for later usage.  When we know the name of the current node, this should be easy to create an attribute dynamically:

<Contact>
    <xsl:for-each select="Contact/*">
            <xsl:variable name="attributeName" select="name(.)" />
            <xsl:attribute name="$attributeName">
              <xsl:value-of select="'value'"/>
            </xsl:attribute>
         </xsl:for-each>
     </xsl:for-each>
</Contact>


Although, it is impossible to define special characters in the name parameter of the attribute definition.
Visual studio gave me the error “the ‘$’ character, hexadecimal value 0x24, cannot be included in a name.”  

 

The Solution

The name argument is not able to perform a query or do some piece of logic. This problem can be solved by working with attribute value templates. Attribute value templates will evaluate the expression and convert the resulting object to a string.

I replaced $attributeName with {$attributeName}

This is the final result:

<Contact>
    <xsl:for-each select="Contact/*">
            <xsl:variable name="attributeName" select="name(.)" />
            <xsl:attribute name="{$attributeName}">
              <xsl:value-of select="'value'"/>
            </xsl:attribute>
         </xsl:for-each>
     </xsl:for-each>
</Contact>

 More information about attribute value templates can be found on the website of W3C.

Additional Notes

The same trick can be used to create elements in a dynamic way in XSLT or for using variables in arguments.
Note that when the source schema will be changed and some child nodes are added, this mapping will also add those attributes, even if this is unknown by the destination schema. This can be positive or negative.

Posted in: Schemas | XML | XSLT

Tags: , ,


March 29, 2013 at 3:26 PM

Today I was deploying a new release for one of my BizTalk applications. I updated logic on several places in two assemblies containing orchestrations.

I decided to deploy to the testing server manually: the first assembly was no problem to deploy, however the second assembly gave me the following error:

 

Failed to update binding information. (mscorlib)

Party 'PartyName' enlisted under role 'Provider(Codit.MyRoleLinkType)' has not bound all the operations of role link port types. (Microsoft.BizTalk.ExplorerOM)

 

You do not find a lot of information on the above error online, so I tried to check where the problem lied myself to no avail.

I found one similar blog post from Steve Harclerode which claims that there is no other way than to delete the entire BizTalk application and then recreate it.

However, I found that if I delete this particular resource and then add it again, I have no issues.
Off course, by removing the resource and thus also removing the artifacts and bindings, you also lose your role link setup. In my case however, this is easily put back by importing the bindings I exported before removing the assembly.

Hope this helps someone, please feel free to comment if you have any cause or solution.


March 13, 2013 at 4:10 PM

Often we find ourselves at a customer or project explaining why it is better to have a dedicated SQL server or cluster for your BizTalk platform.

One can easily come up with the most obvious reason as to why this is important:

BizTalk is designed and optimized for parallel processing and throughput and the BizTalk databases are resource intensive: it is the heart of your BizTalk environment.
If you are sharing a SQL server between BizTalk and any of your other applications, you are pulling away those resources from BizTalk. This is in regard to memory, threads, CPU cycles, etc…

However I find that customers are hard to persuade with that argument and I cannot blame them:

  • If they look at the resource usage of their SQL server that is currently hosting their BizTalk platform, it is hardly doing anything. Memory usage is high off course (it is quite normal behavior for SQL to take up all memory for caching purposes), but the load on CPU and disk is mostly quite low.
  • They have other applications (either old or new) that need a SQL server environment. Most of the times the SQL database they need hosting is nothing more then a few dozen MB, so the tendency is there to say: what harm can it bring to host it on the BizTalk SQL?
  • They paid good money for the SQL server license(s) and BizTalk license(s) they are running their BizTalk platform on. They do not want to ask their manager for extra money again (cost of hardware/storage/licenses) because of budget limits or any other reason for that matter.

So in the end, what often happens at some projects is that the SQL server or SQL cluster hosting your BizTalk platform becomes a shared server or cluster hosting the BizTalk environment as well as several other databases.

 

Why is a shared SQL a bad thing?

Like I mentioned above, any resources you’re taking away from your SQL server, you are effectively taking away from your BizTalk platform.

Additionally, there is something on SQL called the “Max DOP” parameter or the parameter for the “maximum Degree Of Parallelism”. Learn more about max DOP on MSDN.

In short, it is the number of processors used by SQL server on a SQL Server instance to execute queries in parallel to each other in order to give the results as fast as possible.
If your Max DOP parameter is set to something higher than 1, SQL will try to process queries in parts by spreading them over a number of processors. All done by the SQL engine without you having to care about it much.

The reason why I talk about this here is that BizTalk, during configuration, will actually set this max DOP parameter to one (1) on the SQL server instance where your Message Box database is located. This is due to the fact that the BizTalk Message Box database is highly optimized and works quite differently from other "normal" databases. Other databases are just data stores where SQL needs to retrieve data from and store data to. BizTalk is built quite different in many ways while it stays in essence a data store off course. The BizTalk databases are that optimized that setting Max DOP to something higher than one (1), it will actually hurt BizTalk throughput and performance.

Having said this, your “other” non-BizTalk databases will actually perform worse in 99,9% of the cases having Max DOP set to 1.

 

So there it is, another reason to have a dedicated SQL server/cluster for your BizTalk platform.

Do you know any other reasons why sharing your BizTalk SQL environment is a bad idea? Feel free to put them in the comments.


March 6, 2013 at 4:05 PM

In many scenarios, it could be required to have a send port with a dynamic behavior:

  • Send messages to a FILE location, containing the date of today
  • Send a notification mail to many different recipients
  • Dynamically change the URL of the backend web service, depending on the incoming request

 

Many developers would solve this by using dynamic send ports.  These ports allow you to configure all adapter properties, even the adapter type, at runtime.  I’m not a big fan of dynamic send ports, because it introduces some drawbacks:

  • Dynamic send ports are very difficult to troubleshoot (a hell for your operations team)
  • Dynamic send ports require your port configuration to be stored in a secure way (custom SSO application)
  • Dynamic send ports have a bigger performance hit (solved in BTS 2013)
  • Dynamic send ports don’t allow to specify an adapter handler (solved in BTS 2013)

 

That’s why I prefer using static send ports.  With a very easy trick, you can make static send ports partially dynamic.  Mostly it’s only the connectionstring, URI, path that must be changed at runtime.  This can be achieved in a custom pipeline component in the send pipeline:

 

 

This dynamic behavior works smooth for FILE and FTP adapters.  However, when using this mechanism on WCF send ports, there’s a caveat.  You will find out that the BTS.OutboundTransportLocation of the first message will be cached on the WCF send port.  So all subsequent messages will be sent to the same location.  This port configuration is cached until your send port configuration is modified or until your adapter send handler is restarted.  Luckily: there’s a way to disable this caching:

 

 

By setting the BTS.IsDynamicSend property to true, you force the WCF send adapter not to use the cache, but the runtime value instead.  More information on this setting can be found on MSDN.

Posted in: BizTalk | General | WCF

Tags: ,


January 14, 2013 at 3:16 PM

Lately I came across a weird exception while building a BizTalk project with Team Foundation Server.  Let’s have a look.

 

The error

Although the build succeeded locally, we got this error while building our BizTalk project with TFS:

FlatFileSchema.xsd.cs: The type or namespace name '<ContextPropertyName>' could not be found in the global namespace (are you missing an assembly reference?)

 

The troubleshooting

After some try/error, we discovered that the error only occurred when building a BizTalk project in TFS that contains a flat file schema, using property promotion.   The first reflex was to compare the installed software on our local development machine and the Team Foundation Server.

  • Local machine: Full BizTalk 2010 Installation
  • TFS server: BizTalk 2010 Build Component

 

 

The solution

The solution was to install also the Developer Tools and SDK on the TFS server.  Although MSDN states that the Build Component should be sufficient.  This extra installation adds “Developer Tools\Schema Editor Extensions” to the BizTalk folder.  This is apparently needed for building flat files schemas that use property promotion.

Posted in: BizTalk | General | Schemas | TFS

Tags: ,


January 9, 2013 at 2:34 PM

Today I've encountered a problem with the party configuration, specifically while reconfiguring send ports from a party. An error occurred when I removed a send port from a party and saved my settings.

 

The error

The error occurred during the removing of a send port from a party: Sendport Reference [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference] cannot be deleted as it is use by agreement [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference]. (Microsoft.BizTalk.B2B.PartnerManagement)

 

The troubleshooting

Based on a forum thread on MSDN, this seems to be a bug in the BizTalk console, but has never been officially announced or patched. The forum thread suggests waiting for the next cumulative update for BizTalk server [link: cumulative updates Biztalk]. But even when I applied an update for BizTalk to the next version, the problem didn't got solved.

Based on the error message, a constraint prohibits removing the send port record assigned to this party. The OnewayAgreementSendPortReference table contains all send port records for each party. A foreign key is present between OnewayAgreementSendPortReference.SendPortReferenceId and the SendPortReference.Id colomn.

The solution

I had to manually remove the Foreign key record from the SendPortReference table.

Connect to the BizTalk SQL database instance of the BizTalkMgmtDb catalog.
Change the @Name variable to the name of the send port you would like to remove from the party.

DECLARE @NAME varchar(100)
SET @NAME = 'spo_3025816970108_3014683300200_INVRPT_EDI_FTP_PRD'

DECLARE @ID int
SELECT @ID = id
  FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME  
  
DELETE FROM [BizTalkMgmtDb].[tpm].[OnewayAgreementSendPortReference]
  WHERE SendPortReferenceId = @ID

  DELETE FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME

After running this query, refresh your BizTalk administration console and the send port is now removed from the party.

Important note:
Be aware that fiddling with the BizTalk internal databases is not a recommended approach and is not supported by Microsoft.
Any support case dealing with issues after manually changing the BizTalk internal databases will have to be paid fully or result in a re-installation!