I have just encountered a very bizarre and annoying problem today and thought Id do a quick post to vent my frustration. Problem Ok so in one of the testing environments we have a BizTalk application running which had been fine. There are a combination of recieve locations from some orchestrations published as web services. 2 ports are one way recieve and the rest are 2 way recieve. As I say all had been working fine, then today the one way recieve ports started to have problems. The symptoms are ......
I have eventually got around to wiring up the BizTalk Documenter to our build process today. I did have an issue which is already logged on the codeplex site for the Documenter about problems when tracking is enabled on ports. I have worked around this problem by getting the source code for the documenter and building a local version of it with a fix until the next release where hopefully this will have been resolved. If you want more info about this please refer to: http://www.codeplex.com/Biz... ......
I recently needed to do a little analysis of some of our BizTalk implementations and needed to get some information from the IIS logs to help me. I read a little about the Log Parser tool and this post will provide a little about how it helped. Log Parser is a tool which allows you to use a SQL like syntax to parse various types of log files. This can be very useful when looking at a BizTalk environment and you want to be able to interogate a significant amount of logging information. Log Parser ......
Here are a few useful links to information about versioning in BizTalk projects and web services Description Link Web Cast which discusses Versioning http://msevents.microsoft.c... Article on Versioning Strategy for BizTalk Assemblies http://blogs.msdn.com/richa... Understanding Application Upgrade Article http://blogs.msdn.com/csdcu... ......
Following on from a recent post about 2 way recieve ports I thought i would look in a little more detail at how the different adapters return a fault to the client and what the differences are in how the client would manage the fault. The scenario for this is as follows: I have setup a simple scenario where the client will input a simple message and then an orchestration will return a fault back to the port. In this case the fault message has been typed as a string and I will always return the following ......