Perhaps you have a rather large task of creating a complicated map with countless functioids. Or, like me, you are inheriting horrifyingly messy maps from another person. On my first ever BizTalk deployment project, I inherited this:
One page, 150+ nodes, countless functoids. Now let’s make this point clear: this is my first ever BizTalk project. Other than doing MSDN’s EAI and EDI tutorials, a few articles, and hours in a conference room doing knowledge transfer with a coworker, my knowledge is limited to my google search proficiency.
The developer before me left our company about a month ago, without much to hand off besides broken code and missing documentation. As many of you know, this is actually not very uncommon. Because of this, let’s discuss a few ways you can make your (and your replacement’s) life much more stress-free:
1: Document Everything
This should be a given. No matter how smart you are, you will make mistakes. So why take the chance? Break out Excel, go through each element, know your source system, know your destination system, and document what needs to happen in-between.
2: Use your Documentation
If you document your mappings appropriately, you will have two major advantages. You will have a consistent playbook to reference throughout your development, and you will have a binding document to assure data consistency from the source and destination systems. The latter advantage is the one most don’t think about; however, when you get accusations about incorrect data during testing, you can reference your document, and be on your way.
3: Map on Multiple Pages
See how on the bottom of the window in Visual Studio, where it says “Page 1, Page 2…”? That means you can use multiple pages for a single map. This probably sounds patronizing, but I have already seen quite a few prod maps with a large headache on one single page. Below is an image of the same map, but with one tree split out to another page.
4: Label your Functoids
Okay, at this point, you may think I am being a bit too anal. Who actually takes the time to label their functoids, anyway? To be honest, I am probably one of the most impatient developers you will meet. Documentation is painful, and writing pretty code was a forced adaptation of mine. So labeling functoids is just one extra step that can seem too meticulous. However, it is a lifesaver. When you look at a map in Visual Studio, you cannot see every bit of logic. You are missing the order of operations and the specific operations taking place.
For example, the String Concatenate Functoid:
From this menu, can you tell what is taking place? When multiple functoids lead into a string concatenate functoid, there is absolutely no way to know which input is Input, Input, or Input. However, if you label the functoids leading into the String Concatenate Functoid, you can see exactly what operations are taking place.
This very situation saved my rear when dealing with date formatting, and I have labeled my functoids ever since.
5: Don’t Rush
There is always stress to get a project done faster, but remember: a bit more time spent up front can save hours of frustration in the future. We all know that debugging is not the easiest thing to do in BizTalk, so let’s minimize those occurrences.
So grab some headphones, put on your favorite tunes, and spend some time with these maps. Use your documentation, think through the logic, and have fun!