BizTalk Error for Schemas With Hyphenated Root Node

While building a schema that was generated from a SQL Server stored procedure, I ran into this exception:

Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier).

It turned out that the issue was the root nodes created for the typed procedure contained hyphens (because the stored procedure name contained hyphens). C# class names disallow the use of hyphens.

The solution was to open the properties dialog box for the root node (in this case there were two root nodes: one for the request and another for the response) and edit the RootNode TypeName property to remove the hyphens. This fixed the issue.

I found this solution on the MSDN forums here:

https://social.msdn.microsoft.com/Forums/en-US/04a80789-6073-453b-b531-2188416e45af/biztalk-problem-with-schema-elements-which-have-hyphens?forum=biztalkgeneral

2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 3,000 times in 2014. If it were a cable car, it would take about 50 trips to carry that many people.

Click here to see the complete report.

Changing the default sort order on the Faults page in the ESB Portal

Helpful…

Adventures inside the Message Box

A small oversight (at least in my mind) in the ESB Portal quickly proves to become a major irritant after using it for awhile.  The default sort order on the faults page is by severity, which if you’re like me, is almost never the logical choice when viewing the page.  I would much rather be seeing it sorted by the time when the fault occurred and if I want to view the data any other way I can always change the sort order or apply filters.

The ESB portal uses an ASP.Net Grid and it’s default implementation doesn’t specify a sort order, thus on page load it will always sort by it’s first column which is severity.  Thus you’ve got two choices, either change the order of the columns, or add some new behavior which defines the default sort behavior.  I’ve explored the latter path.

In order to make the changes…

View original post 191 more words

Query String Parameters in the BizTalk REST / WCF-WebHTTP Adapter

I was banging my head against my keyboard (metaphorically, but almost literally) trying to get query string parameters to work properly with the WCF-WebHTTP Adapter in BizTalk 2013 R2. I needed to call a REST service using query string parameters in the URL. Using “?param1=val&param2=val” notation when configuring the Send Port was not working.

Fortunately, our good friend in the integration community, Richard Seroter, has encountered this before and blogged about it! Here’s the link.

http://seroter.wordpress.com/2013/03/19/yes-richard-you-can-use-ampersands-on-the-biztalk-rest-adapter-and-some-asp-net-web-api-tips/

The gist is that you have to use the HTML encoded value for the ampersands such as “?param1=val&param2=val”.

Using the tips in this blog post got me up and running. Thanks Richard!

XPath to return default value if node not present

I had to put this into use today in a BizTalk map (inline XSLT). Since this is in BizTalk, I was limited to XPath 1.0 as a solution.

http://stackoverflow.com/questions/4489976/xpath-to-return-default-value-if-node-not-present

This is the problem/solution from StackOverflow:

Problem

Say I have a pair of XML documents

<Foo>
<Bar/>
<Baz>mystring</Baz>
</Foo>

and

<Foo>
<Bar/>
</Foo>

I want an XPath (Version 1.0 only) that returns “mystring” for the first document and “not-found” for the second.

Solution

In XPath 1.0, use:

concat(/Foo/Baz, substring(‘not-found’, 1 div not(/Foo/Baz)))

If you want to handle the posible empty Baz element, use:

concat(/Foo/Baz, substring(‘not-found’, 1 div not(/Foo/Baz[node()])))

With this input:

<Foo>
<Baz/>
</Foo>

Result: not-found string data type.

This worked beautifully!