Mark Wiggins

Over the years debugging XSLT has gotten better and better but one thing continues to be lacking. XSLT debugging with .NET component references in the XSLT. I know there are some tools that do a decent job but something is always lacking.

Well I decided to write an XSLT debugger that uses Visual Studio. It is fairly easy to use and is very robust. I will put pictures and such up later but for now I just wanted to get the app out. So if you are like me and are looking for a debugger that includes .NET capabilities then here it is. If you have questions feel free to ask.

So here it is... (Drum Roll)

The XSLT Debugger for .NET.

http://cid-f797155a9bd4a824.skydrive.live.com/self.aspx/XSLTDebugger/XSLTDebugger.msi

 So I added an example application that is located in the install directory

C:\Program Files\XSLTDebugger\ExampleApplication

Here are the instructions:
1. Start application - XSLTDebugger.exe located C:\Program Files\XSLTDebugger\ by default.
2. Follow instructions on the screen, adding input, xslt, and output files.
3. The Arguments are the most important part. The arguments represent the .NET component itself. So reference your .NET component and then choose the appropriate "type" or method call. Make sure that the assembly you reference is in the GAC and is strong named.
4. The namespace field is what is referenced in the XSLT. An example is: xmlns:inputHelperObj=http://DebuggerExample/inputHelperObj

Enjoy.

5. The Type field and the Namespace field basically coorelate to each other thus providing the reference.
6. Make sure you add the arguments to the list and repeat for each argument you need to add.
7. Once done click debug, you will get the screen that says which environment do you want to open. This is normal and is how you debug in visual studio so if you have Visual Studio 2005 choose the Visual Studio 2005 environment.
8. Any questions just ask. I will try to respond quickly.

  We have had a challenge to get TFS to record a test and replay it multiple times. I think the basics are easy but let me add a few more kinks.

1.  Session variable in the URL
2. A variable that is returned in the response query that changes at each post
3. A SessionID for database connectivity, this variable is good throughout the entire session
4. https/SSL

The 4th kink was easy enough we turned https off during the recording process. The session variable and SessionID were fairly easy. Create a class and write enough code to substring the variable out of the URL. Something like this:

string url = e.Response.ResponseUri.AbsoluteUri;

      int startwith = url.IndexOf("S(");

      int endwith = url.LastIndexOf("))");

      string formFieldValue = url.Substring(startwith + 2, endwith - startwith - 2);

      string val = e.Response.ResponseUri.Query.ToString();

Assign val to the property in the class that you will use and you are good to go. We were able to do that with both the SessionID and the Session variable. Now for the fun part. #2 – we call the variable “tm”. This system has a ASP.NET front end with middle tier logic that calls into Business Rules and the database and the back to the UI. Easy enough except a few things the “tm” controls which ruleset to call. The ruleset is unique to the dataset that the UI sent so each tm for each request will be different. The good thing is we found it in the “Last Response”.

this.LastResponse.ResponseUri.Query.Substring

We had to substring it out as well but that was easy.  Alright looks like we had the class built and we knew where to find our “tm” value. We are good to go.

A couple of problems exist using straight TFS recordings.  TFS does not record every GET and every POST, which means some of the details are left out. TFS does not record viewstate, so unless you have a pretty stateless environment without any post backs TFS will not handle the recording for you.

MS has a tool called Fiddler. Every developer should have this tool. I am not sure why Fiddler is a separate tool from TFS but it is nice. It records every POST and every GET. MS just released(about to – Beta is out) Fiddler 2 which records viewstate. The good thing about this tool is that you can save the test in many formats, one of them being a TFS test. So there you have it. We had a challenge and found ways to work through them. We did have to open a case with MS but they helped us a lot and we learned a bunch too.

Oh yea…

One last thing. If your site uses hidden fields, you will fail every time until you take the web.config and add this line.

<pages enableEventValidation="false" viewStateEncryptionMode ="Never" />

Now there are security risks so only use this in a test environment and not an environment exposed by the DMZ.

You can find more on this topic at

http://aspadvice.com/blogs/joteke/archive/2006/02/02/15011.aspx

So that is all for now. Have fun with your TFS testing.

This is in the instructions but I missed it...

Make sure that if the BizTalk EDI Base Service is disabled make it manual.

If you do not there will be issues.

Another item is we use Covast. Covast has an adapter and if you have set it up you must take it out of the adapters list or the new EDI adapter will fail.

This took me about 5 times of configuring to get it right.

So make sure 1. EDI base service is manual and 2. Remove the Covast adapter from the list of configured adpaters in BizTalk administration.

Other than that the install was seemless.

For a 32-bit adapter, the BizTalk Server Administration Console uses the HKEY_CLASSES_ROOT branch in the registry to obtain custom adapter configuration. If a 32-bit adapter is installed on a 64-bit server, the BizTalk Serve Administration Console instead uses the HKEY_CLASSES_ROOT\Wow6432Node\ branch for adapter configuration data.

http://msdn2.microsoft.com/en-us/library/aa561871.aspx

I found a great article on performance testing. The test consists of BTS 2004, BTS 2006 w SQL 2000, and BTS 2006 w/ SQL 2005. This article is a great read. Enjoy.

Well it seems that infosys now requires you to request a copy. I guess to many of you went and downloaded it directly.

The link to request the copy is:
http://www.infosys.com/microsoft/resource-center/technology-showcase.asp

There are a few other papers as well that may be of interest so tak a look at all of them. The one I used was
"BizTalk Server 2006 with SQL Server 2005 takes performance to a new high."

Perhaps I will just post the highlights here and forget about the entire article.

Sorry about the confusion.

This is the 3rd time they moved the resource.

The first thing I learned about TFS is that if you have source safe installed and install TFS then you must go to Tools>Options>SourceControl and change the provider to Visual Studio Team Foundation Server.

The good thing about TFS is that it does allow you to make mistakes while adding source files and you can delete the project the bad thing is you must delete a project to rename it.

Well it has been a while since my last post and I thought I would just write and say hello to those that view my blog. I am beginning work with TFS and I will let you know my opinion on that shortly. I have learned a lot in the past few months working with Biztalk 2006. I really like the product and like the new innovations that Microsoft has done. I am, like others, awaiting the release of R2 and look forward to its capabilities. A book I would recommend reading is the "Pro Biztalk 2006" book by Apress. There are 3 in the series but I have only looked at the one.

I have been working on conversions from 2004 to 2006 for a while and have seen good results. I have seen some issues with custom adapters and pipelines but overall most things are converting seemlessly.

Well that is all for now. Enjoy and feel free to ask questions.

Sometimes it is useful to create an XSLT template for use in a map using the mapper. Creating a template for reuse during the map is not as hard as it may seem.

First, Drag 2 scripting functoids to the map canvas.

The first scripting functoid needs to be setup as an XSLT Template.  Here is some sample code to put in the template.

<xsl:template name="to-numeric">
  <xsl:param name="input"/>
  <xsl:choose>
   </xsl:when>
   <xsl:when test="contains($input, '%')">
    <xsl:value-of select="substring-before($input, '%') div 100"/>
   </xsl:when>
   <xsl:when test="string(number($input)) = 'NaN'">0</xsl:when>
   <xsl:otherwise>
    <xsl:value-of select="number($input)"/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>

The second step is to go to the other scripting functoid that you have on the canvas and change it to be inline XSLT.

Here is some sample code to add to the scripting functoid.

<xsl:attribute name="SomeAttrib">
<xsl:call-template name="to-numeric">
<xsl:with-param name="input" select="normalize-space(@someValue)"/>
</xsl:call-template></xsl:attribute>

As you can see the inline XSLT actually creates the attribute, calls the template, and passes the parameter.

I hope you find this helpful.

Error: "exhausted the network retry attempts"

Do you have over 50 receive locations that you use for Biztalk 2004/2006. Have you ever found them disabled because of Exhausted Network Retries? The problem is not Biztalk but Windows Server 2003 and NetBIOS. Basically it comes down to a default value of connections to a particular server. The default value is 50. You can set this value up to 65000. We used 100 as the value and run at 91 connections constantly. This article will help: http://support.microsoft.com/default.aspx?scid=kb;en-us;810886

Here is the basics of what you need to do:

I did all of these things on an install of BizTalk 2006 running on Windows Server 2003 and I have not had another receive location disable because of exhausted network retries.