10 Architecture Tips From "The Timeless Way of Building"

by community-syndication | Jul 9, 2009 | BizTalk Community Blogs via Syndication

During vacation time last week, I finally sat down to really read The Timeless Way of Building by Christopher Alexander.  I had flipped through it before, but never took the time to digest it.  This is the classic book on design pattern which applies to physical buildings and towns, but remains immensely relevant to software […]

Configuring BTARN on x64 boxes

by community-syndication | Jul 9, 2009 | BizTalk Community Blogs via Syndication

As x64 O/S’s start to become the norm documenting the additional steps required to configure BTARN to work with these may be helpful. Most of this information is documented in the troubleshooting or “known issues” section of the product documentation. The most important thing to know is BTARN is 32-bit.

The information provided here addresses Windows Server 03 x64 and 08. The changes are to IIS so these would apply to other operating systems depending on the version of IIS. BizTalk provides configuration guidance to enable x64 processing. This is not compatible with BTARN. Review these steps if 404’s or 500’s are showing up in the application log when attempting to operate BTARN.

Web Service Extensions

Windows 03 (IIS 6.0)

Open IIS manager and check the web extensions. Make sure the BizTalk externsion is not set to the x64 version. It should be “C:\Program Files (x86)\Microsoft BizTalk Server 2006\HttpReceive”. The next configuration is a couple of command lines. The first sets processing to 32-bit and the second installs .Net.

cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1

C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50215>aspnet_regiis.exe -i

This may not be necessary if the ASP .Net 2.0 32-bit entry is visible and enabled under “Web Extensions”. If this is not displayed the above code will make the extension available. Be sure to set the value to “allowed”.

Windows 08 (IIS 7.0)

Again, BTARN has to run as a 32-bit application. The bigger issue with 08 is the relocation of several configuration options. Here are the instructions to install the BizTalk ISAPI filter from the BizTalk documentation:

Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

Select the root Web server entry and in the Features View, double-click Handler Mappings and then in the Actions pane, click Add Script Map.

Note – Configuring the script mapping at the Web server level will cause this mapping to apply to all child Web sites. If you wish to restrict the mapping to a specific Web site or virtual folder, select the target site or folder instead of the Web server.

In the Add Script Map dialog box, enter BtsHttpReceive.dll in the Request path field.

In the Executable field, click the ellipsis (.) button and browse to drive:\Program Files\Microsoft BizTalk Server 2009\HttpReceive. Select BtsHttpReceive.dll, and then click OK.

Enter BizTalk HTTP Receive in the Name field, and then click Request Restrictions.

In the Request Restrictions dialog box, select the Verbs tab and then select One of the following verbs. Enter POST as the verb.

On the Access tab, select Script, and then click OK.

Click OK and when prompted to allow the ISAPI extension, click Yes.

This works up to a point. Note the location would implement the x64 version. Since BTARN only works as a 32-bit use “C:\Program Files (x86)\Microsoft BizTalk Server 2009\HttpReceive” instead.

Application Pools (app pool)

Make sure to use a custom app pool for each BTARN web virtual folder. Configure them to run under the same identity as the BizTalk service. This is the same for IIS 6.0 or 7.0. Move to the individual web folders and select the app pool for each.

That’s it for IIS 6.0. IIS 7.0 requires additional configuration under each app pool. Select the “Advanced” configuration option and look for “Enable 32-bit Applications” setting and change it to “True”. This should get BTARN working. Use the “LoopBack” tutorial to verify the configuration.

Client Authentication (ELEMICA)

Client authentication is not required to get BTARN up and running. However, in many cases this is required by partners. The existing procedures work for Windows 03 x64, but 08 is a different animal. The “ELEMICA” whitepaper (http://msdn.microsoft.com/en-us/library/cc563935.aspx) provides the bulk of configuration details. The process for 08 is easier but not unless instruction is provided. The client authentication certificate installation requires more explanation.

Open MMC and add the “Certificates” add-in. Select the machine account and open the “Personal” store. Import the private key used for client authentication.

Right click the new entry and select “All tasks”. Select “Manage Keys” and give “Everyone” read access to the key.

The whitepaper includes a link to replacement web pages required to reference the certificate used for client authentication. The documentation is not so clear on the configuration of the web page. The additional parameter in the web.config must point to the public key of the client authentication certificate. This is the unusual situation where both the public and private keys are required.

Understanding Metadata Management

by community-syndication | Jul 9, 2009 | BizTalk Community Blogs via Syndication

Metadata Management- Fun stuff, right? Depending on what your relationship to an organization’s data is, it can have many different meanings. Database developers and administrators tend to focus on technical metadata, which provides descriptive information on table structures, job streams, ETL mappings, data lineage, etc.
Business users have a need for metadata as well. Attribute definitions, […]

My blog has moved, and this is the new home.

by community-syndication | Jul 9, 2009 | BizTalk Community Blogs via Syndication

(so, if you’re reading this, you’re in the right place!)

Well it was more work than it should have been, but my blog and content has been moved to a new home. As you can see, I have some cool new capabilities that I’ve already started to take advantage of.

If you had previously subscribed to my RSS feed, I’m sorry, but you’ll need to do so again, see the link in the left margin.

My passion for technologies has not changed (BizTalk/ESB/SOA/Oslo/Dublin/Cloud/etc). I have some pent-up blog posts inside me screaming to get out, which I’ll get done in due course (how’s that for a non-committal commitment? :))

Welcome to my new home!

Geneva Framework Query String woes

by community-syndication | Jul 9, 2009 | BizTalk Community Blogs via Syndication

Auckland Connected Systems User Group – Introduction to the WCF-SQL Adapter with Thiago Almeida

by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication

In this session Thiago introduces the new WCF based SQL Server adapter that is part of the BizTalk Adapter Pack 2.0. Learn the architecture behind the adapter, and how to use the SQL Adapter from BizTalk, or directly from .NET applications via the WCF service and channel models.
Register to attend
Free drinks and pizza provided!
Where: […]

Unoffical Launch of the BizTalk 2009 Light and Easy WebCast Series

by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication

Hi folks, been a little quiet on the blogging front lately as myself and other BizTalk
Industry exerts have been busy creating a Series of Webcasts focused on BizTalk 2009
features.

I came up with this idea 3 months ago and we’re finally almost through the other side
– all the guys gave up their own spare time to share their field expertise and knowledge.

The line is great! comprising of MVPs and field experts whom have got runs on the
board.

I hope you enjoy the series, there’s a couple that are still to come, but we can’t
hold it back any further.

You can see them all here – http://cloudtv.cloudapp.net/Default.aspx?category=BizTalk (Alan
Smith has been very kind to offer hosting) – NOTE: not all the webcasts here
are part of the Series, most are 🙂 (I’m working on getting a sub-category)

>

Looping around elements of a message, followup

by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication

Hi all

2 and a half year ago, I wrote a blog post about looping around elements, which can
be found here: http://blog.eliasen.dk/2006/11/05/LoopingAroundElementsOfAMessage.aspx.
In this post, I mention two ways to do something per element in a message. One is
to use the XML (or flat file) disassembler to split the message into lots of messages
and have them handled individually, and the other is to do it inside an orchestration.

Since then, BizTalk has been updated such that you can now call a receive pipeline
from within your orchestration, which gives you the another way of looping through
elements inside an orchestration.

Often times, in the forums, users are suggested to loop through elements of a message
inside an orchestration. It is a fairly common approach if you want the subelements
of a message handled in the correct order, for instance.

This post is to make sure people know that looping around a message inside an orchestration
can have a serious performance impact.

Say you receive a large message – 100MB. You start looping around it inside an orchestration
and split it up into, say, 1000 messages of 100k each. Then, for each message you
call a web service or send out the message to some system. What will happen is, that
the orchestration will persist its state after each send shape, meaning that the 100BM
is written 1000 times to the messagebox. Persistence points are something you always
need to be aware of when designing your orchestrations, and with messages of 100MB,
even more so.

SO, don’t just loop around a message inside an orchestration because you can do it
when you absolutely have to.

Thanks

—

eliasen

Custom XSLT, Scripting functoid, or built-in functoids – a question about religion?

by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication

Hi all

Upon reading a forum post today, I stopped to think about the usage of custom XSLT
to completely replace the mapper, custom scripting functoids and the built-in functoids.

Some people can’t be bothered using the mapper and go straight to custom xslt whenever
a mapping is to be created. Others use the built-in functoids whenever possible. And
the rest go for some path in the middle, with functoids and the occasional scripting
functoid whenever the built-in functoids either can’t get the job done or seem to
be too troublesome to use.

The advantages of custom XSLT

1. Performance. It seems rather obvious that automatically generated
   XSLT can’t perform as well as custom XSLT. So if you really need high performance,
   use your own XSLT.
2. Maintainability. I will be using this argument against custom XSLT
   as well 🙂 but in essence, some people think that having a map with perhaps 200 functoids
   is too difficult to maintain. Sometimes you need lots of functoids in order to complete
   some mapping task that can be easily done in XSLT. In that case, the XSLT can be more
   readable and hence maintainable than using functoids.

The advantages of using the built-in functoids

1. Overview. Using the functoids can give a developer an overview of
   what functionality a map provides, whereas custom xslt needs to be gone through and
   “parsed” by a developer before he can understand what is happening.
2. Maintainability. (See, there it is again – in the opposite direction).
   A BizTalk developer knows about maps and functoids. He does snot necessarily know
   about xslt – and even if he does, he is not guaranteed to very proficient in it. By
   staying with the functoids you give a BizTalk developer the best possible opportunity
   to understand a new map he is going to maintain.

The advantages of using functoids and the scripting functoids

1. Everything is possible 🙂. Basically you can do what you want. Use
   built-in functoids as much as you prefer and throw in scripting functoids if you think
   the solution either can’t be done with the built-in functoids or is too troublesome
   to do.

My preference

Well, those that read my blog regularly wont be surprised when I say that my preference
is to use the built-in functoids whenever possible. I turn to XSLT only when I cannot
solve my problem with the built-in functoids. And when I need XSLT, I always use custom
scripting functoids to supplement the other functoids, so I let as much of the job
as possible be handles by built-in functoids. I never use custom XSLT to replace the
map. My main reasons for this are:

1. Maintainability. I truly believe that it is easier for a new BizTalk
   developer to troubleshoot and/or change an existing map if only built-in functoids
   are used.
2. Overview. If a BizTalk developer opens up a map and sees lots of
   scripting functoids, he needs to open them all up and examine the code inside it in
   order to know what the map does. And after looking at 5 different scripting functoids,
   he needs to go back and look at the first again. Really annoying!

If I am doing a rally complex map where the number of custom scripting functoids is
larger than the number of built-in functoids, I might consider using a custom XSLT
script but this haven’t happened yet 🙂 And also, if i run into really serious performance
issues, I will consider it as well, off course.

Just my thoughts.

—

eliasen

Why use distinguished fields?

by community-syndication | Jul 7, 2009 | BizTalk Community Blogs via Syndication

Hi all

When trying to help the guy I wrote about in http://blog.eliasen.dk/2009/07/07/DistinguishedFieldNotWorking.aspx getting
his distinguished field working, another guy suggested that he just used he xpath
function instead of trying to get the distinguished field working. Now, he actually
ended up using the xpath function because he had a reserved word in the xpath statement
to the field he needed to access the field, but I thought I’d just write a post about
why the xpath function should be avoided and perhaps generalize the post to the usage
of promoted properties, distinguished fields and the xpath function. When to use what
and why

Why use distinguished fields over the xpath function

1. Readability. Inside an expression shape, it is much easier for a
   BizTalk developer to look at “Message.MyElement.MyField” than it is to look at “xpath(Message,
   “string(/*[local-name()=’MyElement’ and namespace-uri()=’http://mynamespace.com/something/somethingmore’]/*[local-name()=’Myfield’
   and namespace-uri()=’’])”)”
2. Maintainability. If you need to change a schema at some point, the
   distinguished field is automatically updated to correspond to the new xpath expression
   that points to the relevant field (if you are using the BizTalk Editor, that is).
   If you use the xpath function, you need to find ALL occurrences of the xpath function
   in your entire solution that has an xpath expression that needs to be updated.
3. Performance. If you use the xpath expression to get values form a
   message, then the entire message needs to be loaded from the database and the xpath
   expression is then evaluated. Distinguished fields, on the other hand, are kept in
   the context of the message and is therefore loaded quickly at runtime.

Why use promoted properties over distinguished fields

1. Routing. Only promoted properties can be used for routing in the
   internal publish/subscribe engine if you need to route based on the content of a message.
2. Correlation. If you need to correlate a received message into a specific
   instance of your orchestrations, then you need to do this using promoted properties,
   as these are the only properties that can be added to a correlation type. This makes
   sense when you think of it, because correlation is really just runtime routing – setting
   up the correct subscriptions at runtime that will make the message hit the correct
   orchestration instance. And routing can only be done with promoted properties, hence
   these are needed for correlation.
3. Tracking. You cannot track distinguished fields – for tracking, you
   need promoted properties.

Why use the xpath function

1. Distinguished fields cannot be used because there is a reserved word in the path of
   the xpath expression
2. Distinguished fields cannot be used because you need to set or read a value from a
   reoccurring element

Why use distinguished fields over promoted properties

1. Performance. You want to keep the number of promoted properties as
   low as possible, since the messaging engine really needs as few promoted properties
   as possible to evaluate when finding out which subscriptions match an incoming message
   that is published to the MessageBox.

So, to sum up: Use distinguished fields whenever possible, switching only to xpath
function or promoted properties if really needed.

—

eliasen