Liza, a Technical Writer on the BizTalk Server 2006 Documentation team, is investigating updating the Operations section of the documentation. A large part of this effort is accomplished through customer feedback and in finding out what is missing, incorrect,…(read more)
I am investigating updating the BizTalk Server 2006 Operations section of the documentation. A large part of my job is to improve our documentation by gathering customer feedback. Specifically I want to know what is missing, incorrect, unclear, or just needs work in any of the Operations topics.
I’m thinking this is a bad thing if you want dynamic resolution.
I’ve experienced this with both the XMLReceive and a Custom Flat File Receive Pipeline
(I built).
1. Both worked a treat – ‘5 minutes ago’ as I’ve been working away.
2. Went into the BizTalk Admin console and ‘adjusted’ a property on the pipeline at
the receive location ->clicked on the ‘…’ button next to the pipeline.
3. Even if you dont change anything and hit OK…you’re affected.
4. XMLReceive + FlatFile both complain about ‘blank document
schema‘ which must be specified.
(as in this case I’d changed a few things coding….it took me AGES to come back to
here)
I even explicitly supplied the correct schema as a property on the FFDASM component
I was using and no go!
5. Resolution: go back to the pipeline within the receive location (or send
port) and select another pipeline from the list. Click OK to close the property window,
then repeat and add your original pipeline but dont go into the pipeline per instance
properties pages
Why does this happen??? (yeah good question 🙂
Basically both the XMLDASM and the FFDASM take precedence with Per instance pipeline
config properties than *anything* else you provide.
e.g. Dynamically processing a flat file – check the SDK example, but here’s a pseduo
version.
…..
//Flatfile schema resolver – normal technique.
DocumentSchema docSpec = ……determine which deployed schema to use.
//this line basically tells the Disassemblers which schema to apply.
msg.Context.write(“DocumentSpecName”,”<system namespace xml-norm>”,docSpec.DocSpecStrongName);
_myFFDasm.Disassemble(msg); // line – *
These above lines will work for a year and a day (I’ve tested this) and in both 2004
+ 2006, but NOT when you add perinstance pipeline configs – it seems all ‘dynamic-ness’
has gone out the window.
When per instance pipeline config is specified, this config data is provided as
a Message Context Property (ReceivePipelineConfig) and XMLDasm + FFDasm only look
at this for their values – painful.
So as in my case, I hadnt specified a Document Schema within the pipeline config as
this pipeline was dynamic (c.f. like the xmlReceive).
I explicitly assigned a Schema to the FFDasm.DocumentSchema property and still
got the same error as before.
Removing the Config Data did the trick 🙂
Given that this is the case – I think when you hit ‘OK’ to save the pipeline config
data a warning/message of some description should come up as you may be wanting to
modify ‘one’ value – ‘omit xml declaration’ for example. The rest of the properties
are written in as blanks.
Hopefully I’ve saved you a bit of pain from mine.
Today we ran into some problems when making a call to a web service that took more than 90 seconds via the SOAP adapter. After 90 seconds we got a “System.Net.WebException: The operation has timed-out” error in return. It turned out that we had to set the SOAP.ClientConnectionTimeOut context property for the request message. We did this in the message construction using the following code.
<div><span style="color: #000000; ">MyRequestMessage(SOAP.ClientConnectionTimeout) = 200000;</span></div>
I found this post by Thomas Restrepo useful for understanding both the problem and solution. Apparently the default value is 90000 (90 seconds) before the adapter times out. This article on MSDN is also an excellent read when working with web services and BizTalk server.
Today we ran into some problems when making a call to a web service that took more than 90 seconds via the SOAP adapter. After 90 seconds we got a ”System.Net.WebException: The operation has timed-out” error in return. It turned out that we had to set the SOAP.ClientConnectionTimeOut context property for the request message. We did this in the […]
This sample shows a basic WCF Service using Basic HTTP Binding. This service is hosted inside IIS and uses a WCF Receive Location to process WCF messages inside BizTalk.
This code was built using a beta version of BizTalk 206 R2. The concepts are the same in the RTM release of BizTalk 2006 R2 but this code may not work.
Watch the video related to this sample here: https://www.biztalkgurus.com/biztalk_server/biztalk_2006_r2/m/biztalk_2006_r2_samples/32391.aspx
Note: This video is based on BizTalk Server 2006 R2 BETA
This nearly 13 minute video gives a quick, high level First Look at BizTalk Server 2006 R2 WCF Adapter using the Basic HTTP Binding. This is intended to show how easy it is to use BizTalk 2006 R2 and WCF to build applications.
Note that this is based on Beta code and is subject to change in future releases.
This content should be current for the RTM release of BizTalk 2006 R2 and beyond.
https://www.biztalkgurus.com/blogs/biztalksyn/archive/2006/12/17/Sharepoint-_2D00_-internal_2F00_external-sharepoint-site-reference-for-indexing.aspx
Making some headway with this issue I’m experiencing.
I can now go into the BizTalk Application and configure most of the resources found
within the Application. I’ve ventured into Microsoft.BizTalk.ApplicationDeployment.Engine.dll (found
in the GAC) and was able to enumerate all the resources etc.
The only thing I havent been able to do is ‘an update’ to the resource properties
(metadata).
I can re-add the resource and overwrite the existing ones, this time with the correct
settings, but the problem here is that resources that have dependenies fail. e.g.
schemas, maps….
For better of for worse right now I’ve located the two tables in the BizTalkMgmtDB
and modified those directly – all looks good.
The interesting thing is I used %BTAD_InstallDir% extensively throughout the DestinationLocation.
Setting that at deploy time use:
msiexec /i <package.msi> /quiet /log <logfile> TARGETDIR=<your location>
Somewhere within the MSI Installer component within the Package – TARGETDIR=%BTAD_InstallDir%
(Even though all the documentation talks about %BTAD_InstallDir% being an environment
variable)
How often have you seen error messages like this
There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Receive Port: “ReceivePort3” URI: “C:\BTSSamples\SOAPMessagingOnly\FileDrops\MSG_IN\ *.xml” Reason: Cannot locate document specification because multiple schemas matched the message type “http://Microsoft.Samples.BizTalk.WebServices.Consuming.SampleWebService/ Customers.xsd#CustomerInfo”.
If you are working with multiple applications in Biztalk at the same time, its quite often you’ll end up in situation like this in your development machine. In situations like this I used to open Biztalk Applications one by one inside the Biztalk Administration console (2006), navigate to Schema node and look for any matching schemas with same RootName and TargetNamespace, after a while it became so annoying, so I build this small application called “Schema Detector”, its a .NET winforms application which utilizes Biztalk ExplorerOM to loop through each deployed schemas in the management database, if a specified schema with RootName and TargetNamespaces matches, it then list the schema as shown in the below figure.
You can now easily detect the duplicate deployment of the schemas in the Applications, as highlighed in the above picture.
Download the source code for the tool here. Open it in visual studio and compile it. Didn’t provide the exe for security reasons.