BizTalk Adapter Pack V2.0 – x86 or x64 Versions supported

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

Hi – today I came across a handy Matrix that describes the supported versions for
the Biztalk Adapter Pack v2.0

Handy reference I reckon 🙂

—snip—

Compatibility
Matrix Between 32 and 64-bit Versions of the Adapter, BizTalk Server, and Operating
System

The
following table presents a compatibility matrix between the 32-bit and 64-bit versions
of the operating system, adapter, and .

Oracle
Database Adapter + BizTalk Server

SAP
Adapter + BizTalk Server

Siebel
Adapter + BizTalk Server

Oracle
E-Business Adapter + BizTalk Server

SQL
Adapter + BizTalk Server

Operating
System

32-bit

64-bit

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

No

Yes

No

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

N/A

Yes

Yes

Legend

%u00b7         Yes =
Supported.

%u00b7         No =
Not supported.

%u00b7         N/A =
Not Applicable.

First Stab at Using New Tool to Migrate SQL Server Adapter Solutions

First Stab at Using New Tool to Migrate SQL Server Adapter Solutions

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

If you saw the recent announcement about the Adapter Pack 2.0 release, you may have seen the short reference to a tool that migrates “classic” SQL Adapter solutions to the new WCF SQL Adapter.  This tool claims to:

Works on the source project files
Generates equivalent schema definitions for the operations used in the existing project
Generates new […]

Receiving large WCF response messages in ESB Guidance

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

[Source: http://geekswithblogs.net/EltonStoneman]

WCF bindings provide the MaxReceivedMessageSize property, which lets you block any incoming messages on the client side over a given size (defaulting to 64Kb). If you’re using message-based itinerary processing with ESB Guidance, when a WCF service returns a message larger than this default, you’ll get a System.ServiceModel.QuotaExceededException and the response message will be suspended:

System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. —> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Setting the MaxReceivedMessageSize property is straightforward in a configured WCF port, but in ESB Guidance the port is configured dynamically and there’s no straightforward way to interrupt it and add your own WCF bindings. To give us access to the message and the port, we replaced the “DynamicSendResponse” port used in the GlobalBank.ESB sample with a simple orchestration.

The orchestration has a direct-bound receive port filtering on the usual properties:

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == “DynamicResolutionSolicitResp”) &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == “Pending”) &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == “Messaging”)

– it then builds the outgoing message for the service, and configures the dynamic send/receive port. At this point the message has all the properties you need configured by ESB (via the resolver pipeline component in the previous itinerary steps), so you can extract them to configure the port, and add any WCF binding configuration you need.

We store the configuration in the Enterprise Single Sign-On application config store using SSO Config Tool, so the expression to build the outgoing message and increase the received message size looks like this –

//setup port from context properties:

sptServiceProvider(Microsoft.XLANGs.BaseTypes.Address) = ServiceProviderRequest(BTS.OutboundTransportLocation);

sptServiceProvider(Microsoft.XLANGs.BaseTypes.TransportType) = ServiceProviderRequest(BTS.OutboundTransportType);

//set message size from config:

maxReceivedMessageSize = x.y.z.Configuration.X_Y_Z_Config.WCFMaxReceivedMessageSize;

ServiceProviderRequest(WCF.MaxReceivedMessageSize) = maxReceivedMessageSize;

Microsoft.Practices.ESB.Adapter.AdapterMgr.SetMsgProperty(ServiceProviderRequest, typeof(WCF.MaxReceivedMessageSize), maxReceivedMessageSize);

//set timeout from config:

sendTimeout = x.y.z.Configuration.X_Y_Z_Config.WCFSendTimeout;

ServiceProviderRequest(WCF.SendTimeout) = sendTimeout;

Note that the WCF config is set on the message, not on the port. We’re also setting timeout values here. When you’re dealing with large messages, you may get operation timeouts as the default binding config from BizTalk is set to a pessimistic 1 minute. Value WCF.SendTimeout specifies how long the BizTalk client waits for a response, and WCF.ReceiveTimeout how long the BizTalk client allows for the reception of a request. If your WCF service is hosted in IIS and is long-running, you may also have an issue with IIS controlling execution times. See: Why changing SendTimeout does not help for hosted WCF services.

Einstein Puzzle in Microsoft Solver Foundation

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

As promised in my last post (http://geekswithblogs.net/cyoung/archive/2009/02/24/129639.aspx), I had a look at the Express edition of Microsoft Solver Framework (http://code.msdn.microsoft.com/solverfoundation), and used it to implement the Einstein puzzle using the built-in CSP solver and C#. Creating the solution proved particularly easyfor the simple reason that Microsoft provides a worked example of a politically corrected ’Zebra’ variant in their documentation (no tobacco or beer in sight). You will find this as Sample 8 in the SFS Programming Primer document that comes with the download.

To read more and see the code, visit http://geekswithblogs.net/cyoung/archive/2009/02/25/129672.aspx

Alternative SOAP Transport for LoadGen

by | Feb 24, 2009 | BizTalk Community Blogs via Syndication

[Source: http://geekswithblogs.net/EltonStoneman]

Using LoadGen 2007 to submit messages with a complex SOAP header, I had a strange issue with the standard SOAP transport. The SOAP transport has two parameters for wrapping the input file into a SOAP envelope:

<Parameters>

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: “http://microsoft.practices.esb/Process/SubmitRequestResponse”</SOAPHeader>

<SOAPPrefixEnv>&lt;?xml version=&quot;1.0&quot; </SOAPPrefixEnv>

<SOAPPostfixEnv>&lt;/Root&gt;&lt;/SubmitRequestResponse&gt</SOAPPostfixEnv>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

<LatencyFileName></LatencyFileName>

<ResponseMsgPath></ResponseMsgPath>

<DstEncoding>utf-8</DstEncoding>

</Parameters>

– note the ellipses above are for brevity and are not in the actual LoadGen config file.

When the transport gets called, it opens an HTTP request and sends the SOAP envelope by writing three sets of byte arrays to the request stream: the value of SOAPEnvPrefix, the contents of the input file, then the value of SOAPEnvPostfix. All the byte arrays are encoded to the value specified by DstEncoding. When I used this configuration to send a message it was being rejected by the endpoint as a bad request. Trapping the request with Wireshark, it looked like this:

It looks as though LoadGen has injected an ellipsis before each part of the message it built – the envelope prefix, the input file contents and the envelope postfix all start with an ellipsis in which is not in the original. The request is malformed and rejected by the service.

Initially I thought this was something strange in how Wireshark was showing the results and wasn’t actually part of the message, so I checked further and found that the XML escapes weren’t set correctly. The SOAP header is an ESB Guidance itinerary which contains escaped XML for CDATA sections – to enter it as the SOAPEnvPrefix parameter meant escaping the escapes, so &lt;!CDATA[]&gt; becomes &amp;lt;!CDATA[]&amp;gt; in the parameter and is rendered correctly. But the issue remained, and so did the ellipses. Copying the full request into Web Service Studio produced the same result, but cutting out the ellipses meant it processed correctly.

With time accumulating on what should have been a simple task, I checked out the SOAPTransport code and could see nothing that was causing this. Debugging the call didn’t show any ellipsis characters being written, and modifying it to produce a single string of the header, body and footer before encoding made no difference. In the end I created a modified transport which takes a full SOAP envelope as the input file, doing away with the envelope parameters altogether.

This worked fine, didn’t render any ellipses – although the code is very similar to LoadGen’s SOAPTransport class – and was happily processed. It has the advantage that you can capture a full message with Wireshark, save it and use it in LoadGen without having to extract the header. It’s on the MSDN Code Gallery here: Sixeyed.Samples (Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport).

Configuration is very similar to the standard transport, just specify the assembly and remove the SOAP envelope parameters:

<Transport Name=”SOAP”>

<Assembly>Sixeyed.Samples.dll/Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport</Assembly>

</Transport>

<Parameters>

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: “http://microsoft.practices.esb/Process/SubmitRequestResponse”</SOAPHeader>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

<LatencyFileName></LatencyFileName>

<ResponseMsgPath></ResponseMsgPath>

<DstEncoding>utf-8</DstEncoding>

</Parameters>

But I’m still puzzled about those ellipses from the standard SOAP transport.