Tim Rayburn's Blog - BizTalk Server - Connected People make Connected Systems

Service Oriented Architectures (SOAs) have been all the rage in the world of computing for quite a while now, and many companies have had great success while others have had failures.  As with all things in life, planning is key when approaching a SOA, and also like so many things, planning must be taken in moderation.

Frequent readers have likely picked up on my love of games, board games, console games, PC games, even Tabletop RPGs.  I am in love with the dynamic of engaging with a group of people in a fictional model of something. While attending a recent event put on by Sogeti about realizing success with SOA several corollaries clicked into focus for me between SOA and the type of games called Real Time Strategy (RTS) games.  This article is the result, I hope you at least get a laugh.

I'm sure more than one of you is now saying: "Real Time Strategy games are like an SOA?  Tim's popped a gasket."  But let me make my case.  In an RTS is a simulation of a struggle between two or more people to achieve dominance in a environment with limited resource availability. Most businesses (not all) are attempting to achieve dominance in a market with limited funds and other resources.  As such, since an SOA is supposed to digitally represent the core competencies of a business, it is reasonable to say that SOAs likewise are trying to move a business towards dominance in a market with limited funds and resources.

Now when planning a SOA, before you've implemented your first service even, you are much like a player who has just started a match in an RTS game.  You've likely got a small amount of funding (likely peeled away from one project or another) and one or two developers that you can have begin to work on things.  Ah, and you have your first complication as well.  The staple of the RTS genre known as the "Fog of War".

The "Fog of War" in an RTS game is a sheet of black or gray that covers any area you've not explored or cannot see currently because you have no units there.  In our comparison, this is the uncertainty of where to begin.  Somewhere out there in the fog are high value resources that will move you towards your goal, such as Gold Mines in an RTS or key areas of flexibility which open new markets in a SOA.  The problem is you don't know where.

Hence we come to the first and most important step of an SOA, planning. Different ideas have been espoused for dealing with this dilemma, we will look at those now and their RTS comparisons to see which we think we actually let us win the game best.

• "The Big Plan" - Perhaps the most popular with large corporations, this plan states that the most important thing to know about a SOA is exactly how to build it right the first time.  In RTS terms, these people want to spend a lot of time exploring the entire map so they know where all the key resources and pitfalls are before they begin to build out their game.  The problem with this is cost, not necessarily in dollars/gold (though it can cost that as well) but instead the cost of opportunity. This plan spends so much time planning that it is possible that by the time they've decided to start playing, someone else has already one.
• "Just Get Started" - In opposition to this idea, many shops (often smaller ones) try to simply start building.  They will not explore the unknown areas around them, they'll simply start building services without ever getting a lay of the land.  Those builders are your developers/IT and they are well meaning, but they are not spending enough time interfacing with business, who cares about the big picture and clearing our fog.  The results of this effort may be highly technically competent and well architected, but may be providing the entirely wrong type of resources to drive the business because they are not aligned with business.  Nothing ruins a beautiful SOA more than a sudden and unexpected attack from a horde of Zerglings.
• "Just Enough Planning" - Obviously the key to finding middle ground between these two extremes is moderation.  We must gather resources and begin to build, but we also must explore the fog and find new opportunities.  What is needed to make both these things possible is a high level understanding of where we want to go.  In real world terms, this takes the form of a document which specifies the core competencies of the business.  These are the silos that constrain IT's development, directing in the way that victory is being pursued.

In RTS terms, we're trying to make sure we're gathering the right resources, so the right types of things can be built and areas explored. As you build to the high level plan, you'll be exploring new areas, clearing away the fog and providing details.  Will this mean that you might stumble upon problems or unforeseen opportunities? Yup!  But that just means you need to plan for change ... but that's another post.

Great news!  When I attended and spoke at the Microsoft SOA & Business Process Conference I was informed that they were recording all sessions to be included in a DVD of the event which would be sent out to those who had attended.  Great, wonderful, but not a lot of use to my blog readers.  Well shortly there after I received a request from the TechNet team to include my presentation as part of the "Best Of" from event online.  I happily agreed, and am happy to report that the best of the Microsoft SOA & Business Process Conference can now be found on TechNet, and that my presentation on Building HIPAA solutions with BizTalk Server 2006 R2 is amongst them.  Incidentally apparently I received a 5 of 5 rating during the conference, I thank the attendees for being so easy on me.

This talk is actually very relevant to anyone interested in EDI for BizTalk Server 2006 R2 as the HIPAA specific pieces are few.  It is a good introductory talk, it is not a deep internals talk but it does cover the configuration and setup of EDI/HIPAA in R2 in some depth.  If you're interested in this topic and can't get to an event where I'm speaking, this is a nice alternative.

In recent weeks all of the buzz in the world of BizTalk has been about Oslo, the project which encompasses updates to many products, but specifically to BizTalk Server.  As you can imagine there is a great deal Microsoft is not talking about in regards to Oslo, but today I'm lucky enough to be the first person to announce that the details of one sub-project of Oslo, code named Fjord.

Fjord is the code name for the Microsoft Surface integration pieces to the Modeling commitments of Oslo.  As you know, Oslo has two key components, Services and Modeling.  Microsoft Surface, the revolutionary multi-touch display and device integration platform demonstrated by Bill Gates at CES several years ago.  Obviously the enterprise of the future will need a robust manipulation environment for the complex models that Oslo will host, and the Oslo team is looking to Surface for those answers.  As you can see above in this as yet unreleased publicity shot, BizTalk Mapper is the first piece of Oslo to be integrated with Surface, because unlike many other pieces the code base for the Mapper is already complete.

I can't disclose any of my sources, here are some of the things I've heard will be included in this update:

• BizTalk Mapper will now require a multi-touch interface and as such will require a Microsoft Surface table.
• Mapping from one field to another will be accomplished by "touch and hold" on each field, then the link will be automatically created.
• Scripting Functoids will now be editable in a full screen editor with intellisense.
• Multiple fields can be touched per side of the schema, and when a destination is touched an analysis engine will suggest possible functoid combinations.  For instance, touch "FirstName" and "LastName" from the source, then touch "Name" on the left and the Mapper will suggest the use of a Concatenation functoid.

Further details are sketchy, and as I'm under an NDA with Microsoft there is little more I can say at this time, but needless to say I think we can expect a lot more from Project Fjord in the future.  I'll post more details in the future as I can.

My friend Chris Koenig recently put up a post called "Microsoft Central Region - Who (and where) are you?" in which he shared the above image which I thought was worth re-sharing here.  So what does this image show?  It shows the "sub areas" within Microsoft's Central Region where the Evangelism teams focus.  Chris, our Developer Evangelist from Dallas, covers Texas, Oklahoma, Arkansas, and Louisiana.  Recently they've added some help for him in the geographically vast area via J Sawyer based in Houston.  Both Houston and Dallas are huge markets for Microsoft and as such having a DE based in each of these cities will help run Chris a little less ragged.

Now, many of my readers are based in the Dallas/Fort Worth area, and we're spoiled because we see Chris on a regular basis because he is based here.  But it is important to remember that he's just as responsible for the Little Rock, or Northwest Arkansas groups (not to mention Lubbock group) as he is for those in D/FW.

I was reviewing this map and realized that in the last several week's I've hit most of these areas, in fact all but the "Midwest Area".  I've covered:

• North Central
• Minneapolis BizTalk 2006 R2 Launch
• Heartland Developer Conference
• Heartland Area
• Memphis Day of .NET
• South Central
• Little Rock .NET User Group
• VSLive! Austin
• Houston BizTalk 2006 R2 Launch

Here is what I can tell you after all traveling:

• My favorite Marriott hotel chain is the Fairfield Inn chain.  Good breakfast (unlike Courtyards) and bright, happy rooms.
• My wife believes I've forgotten how to get home.
• My boss believes I've forgotten I'm a billable consultant.
• I believe that I'm seriously looking forward to vacation next week.

So the keynote at the SOA & BP Conference did a slightly better job of setting down exactly what the tenets of Project Oslo are than the material I had previously received.  Basically there are two "big bets":

• Services - The phrase "Doubling down on services" was the catch phrase, but in short the innovation level that drove the creation of WCF will not be slackening, but instead it will not begin to roll across the whole server line.  This is how server products will expose themselves is the message.  Good to hear, but slow in the coming.  You're going to be a rev or two for many of these server products before they have WCF hooks built in.
• Model - Microsoft will ship a unified modelling tool which will cut the vertical slice from development to management.  The demos were incredible, the visualizations sharp, and it will all be stored in a single common repository.  Out-stand-ing.  If they can deliver on this, it will change the game.

Obviously this will engage a large number of teams at Microsoft, and as such there is risk involved in their delivery of it.  Further a slick demo is easy, and I look forward to playing with the actual CTPs which have been promised "next year" to be able to actually work with this myself.

Today is the first day of the Microsoft SOA & Business Process Conference 2007 and they have decided to start it with a bang.  This morning Microsoft has come clean with a great deal of detail regarding a new project code-named Oslo.  Oslo is not a product, but rather an over-arching project which will contain within it updates to many products and services including BizTalk Server, Visual Studio, and more. 

What does Oslo contain?

Oslo is going to invest heavily into 5 major areas, specifically:

• .NET Framework : Major investments into Model-Driven Development surfaced through WCF and WF.  These changes will manifest in the .NET Framework vNext (presumably the .NET Framework 4.0 but we all know about Microsoft's marketing division and .NET Framework versioning).
• BizTalk Services : These services currently available in a test form will reach full commercial implementation.  If you've not had a chance yet to look at these previews, now is the time because they are definitely a major part of the future vision.
• Visual Studio : Two things, one great, another I could live without, are going to happen to Visual Studio.  The great part is that Model-Driven Development will get "deep support", and will focus on delivering composite applications.  The part I could live without is that there is talk about Rosario (vNext of Team System) supporting "greater roles" ... and as we all know, more roles means yet more sub-divided SKUs for Visual Studio.
• Repository : Incredible as it may seem, Microsoft has caught onto the clue-train of Metadata repositories and will be investing in System Center, Visual Studio and BizTalk Server to make them all talk to a common repository.  This is great news, and will help close some of the overall SOA gaps.
• BizTalk Server "6" : The vNext of BizTalk Server will expand the integration with both WCF and WF.  What does that mean?  Details are few right now, but it will probably mean two things. 
  • First the XLANG/s Orchestration engine is going to be deprecated and a new Windows Workflow Foundation engine will be introduced.
  • Second the existing adapter framework will also be deprecated (which it essentially is in R2) and Windows Communication Foundation will be used for all future adapter development.
    • An interesting part of this is the word that BizTalk will likely support the WS-Eventing protocol and a full Publish-Subscribe routing model.  As I'm sure I'd be reminded by Sam Gentile, Neudesic already has a publish-subscribe product today.

Sounds cool ... when can I get some?

Short answer is 2009 or later.  As with most Microsoft dates this far out I'd bet on later.  There is nothing here which is remotely CTP or Alpha yet, this is a lot of vision from the Connected Systems Division about where they are headed.  Key thing to remember is we are talking about technology built on a version of the .NET Framework after 3.5, which won't release for a few weeks yet itself.  Still it is good to know where Microsoft's head is at officially on these things.

Bottom Line

Taken as a whole, there is only one part of this which is really huge, and that is the Repository announcement.  That Microsoft is investing in a solid metadata repository, that they get the reasons for this, and that they are attacking a complete vertical slices in System Center (runtime management), Visual Studio (design time), and BizTalk Server (runtime environment/host).

The other thing we should be ready for is that "BizTalk" is now a generic term like "SQL Server".  Just like how "SQL Server" is slapped on everything (Reporting Services, Service Broker, Notification Services, Express editions, etc) we can expect that the "BizTalk" brand will start appearing on more and more things.  There were signs of this already with the "BizTalk Adapter Pack" which in fact have no BizTalk dependency and are in fact simply WCF adapters.

Takeaways

• If you are a BizTalk developer and you don't know WCF and WF well already, go learn them right away and in that order.
• Spend some time learning about metadata repositories from the competitors in the market (IBM for instance) so you'll understand what the fuss is about here.
• Software + Services : Microsoft has been promising this is their direction for some time now, and it appears BizTalk Services may be one of the first actual set of services to reach a full commercial release.

The official announcement session is about to start here at the conference, I'll follow up with more posts if they hit on anything not covered here already.

I'm quite certain I won't be the only person who tries this, I had a need to send an encoded EDI message to a Web Service, so I was like "No problem, we're in the high tech land of BizTalk 2006 R2 now, I'll just call a Pipeline directly from an Orchestration, get the results and send that along."

Not so quick, buck-o replied BizTalk, and after some Googleing I came up with this link to a post on the Microsoft forums which informed me that you can't do that.  Specifically, to quote it here in case that forum thread disappears, the question was "Steven G." and asked (in part) :

I have an orchestration which is trying to send EDI files using a dynamic send port.

I have been trying, with no success, to call the "Microsoft.BizTalk.Edi.DefaultPipelines.EdiSend" from within my orchestration, as follows:

And the response can back from Tony Bernard of Microsoft:

Running the EDISend pipeline from an orchestration is not supported in R2.  We are tracking this for the future, but had higher priority items to address for this release.

I would suggest one of two approaches:

• a post-processing pipeline component which performs the manipulation that you need to occur after serialization

• using a loopback port. Basically, use a send port with that pipeline into an MSMQ or file location and a receive location with a pass through pipeline back into the orchestration

So no love there.  I ended up working around the problem, but know I will have to solve this again in a few days, so be looking for a post from me on how to implement the Loopback port which Tony suggested.

Today I was taught an immensely important lesson by WCF.  It actually has nothing to do with WCF except that because of the size of the schema I'm working with that is where I encountered it.

I do a lot of work in the healthcare industry, and that industry, by government mandate, works with a message format called the 837 (properly the X12 4010A1 837 either I, P or D).  The 837 has three flavors, and is absolutely huge.  I was crafting a service which had to accept an XML representation of this data. How did I create the XML?  BizTalk Server 2006 R2's new HIPAA support of course.  When I made the call to service from my unit tests I first received a Fault indicating that exception details could not be returned because of configuration.  No problem, obviously I've seen this before and so I added the following to my app.Config for the Host executable:

<behaviors>

  <serviceBehaviors>

    <behavior name="EnableDebugging">

      <serviceDebug includeExceptionDetailInFaults="true"/>

    </behavior>

  </serviceBehaviors>

</behaviors>

Now that I've enabled debugging, surely now I'll see some sort of clear reason by this occurred. Nope!  I was presented with the following:

TheCompany.Services.Tests.ClaimsService.GetListOfClaimsByStatus : System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail] : Error in deserializing body of request message for operation 'GetClaimListByStatus'.

Well isn't that terribly useful.  Fortunately, this did give me the single most important piece of information "deserializing".  So off I go to Google my brain, because I'd written a post before on how to debug the XmlSerializer (and I was using the XmlSerializer in this case because the DataContractSerializer could not work with my schema).  As that post will tell you, there is a switch that can be set in the app.Config which will enable you to debug the code generated by the XmlSerializer.  So now we add the following to my app.Config:

<system.diagnostics>

  <switches>

    <add name="XmlSerialization.Compilation" value="1" />

  </switches>

</system.diagnostics>

And we follow that by running the unit tests again, that results in something that is actively useful:

For those reading along at home and wanting the full text that says:

The maximum nametable character count quota (10000) has been exceeded while reading XML data. The nametable is a data structure used to store strings encountered during XML processing - long XML documents with non-repeating element names, attribute names and attribute values may trigger this quota. This quota may be increased by changing the MaxNameTableCharCount property on the XmlDictionaryReaderQuotas object used when creating the XML reader.

Now that is useful, it tells me exactly how to correct the problem and the size of the quota currently.  The only problem is that I didn't create this XmlReader object, I didn't even create the XmlSerializer which created this XmlReader.  The only thing which I create was a ServiceHost, how can I change that setting?  Enter Google again.

As it happens, Windows Communication Foundation does include an ability to override that value, it is stored in the Binding Configuration in your ... you guessed it ... app.Config!  Add the following snippet (assuming you're using Basic Http Binding (it exists for all bindings though) and you'll be good to go:

<bindings>

  <basicHttpBinding>

    <binding name="BasicHttpBinding">

      <readerQuotas maxNameTableCharCount="100000"/>

    </binding>

  </basicHttpBinding>

</bindings>

Now, surely I'm done, and things will work.  Actually, no it took me a few times to find a value that would work for that quota.  Once I did though I finally hit my breakpoint inside the service and was able to send back a response, where upon I got this message:

TheCompany.Services.Tests.ClaimsService.GetListOfClaimsByStatus : System.ServiceModel.CommunicationException : Error in deserializing body of reply message for operation 'GetClaimListByStatus'.
  ----> System.InvalidOperationException : There is an error in XML document (1, 252).
  ----> System.Xml.XmlException : The maximum nametable character count quota (10000) has been exceeded while reading XML data. The nametable is a data structure used to store strings encountered during XML processing - long XML documents with non-repeating element names, attribute names and attribute values may trigger this quota. This quota may be increased by changing the MaxNameTableCharCount property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 252.

At least when the error occurs on the client side you get the full details to start with!  Make the same modification above to your configuration on the client side and you're good to go.

Thanks to Tomas Restrepo for pointing out that the Developer Edition of BizTalk 2006 R2 is now up on MSDN.  If you're working with EDI and BizTalk server you seriously need to check this out and realize what is coming your way.

I've been visiting Arkansas this weekend, but while reviewing my spam folder I noticed something got caught that shouldn't have.  Specifically the email that informed me I've been selected as an MVP for BizTalk Server.  I'm honored, and appreciate the support of everyone who has made this possible by opening their groups to me to speak.

Sonu Arora, who I had the pleasure of meeting at TechEd this year, has just posted on her blog that her team has released an RC (Release Candidate) of the WCF Line of Business Adapter SDK to Microsoft Connect.  In case you don't know, this is the framework upon which Microsoft is building their next generation adapters to systems such as Siebel, SAP, and Oracle Financials.  It is based around extracting meta-data from the LOB application, and works entirely consistently with the WCF channel extensibility model.

If you read my blog and do BizTalk, and even more relevantly do BizTalk and SAP, Siebel, Oracle Financials or other LOB applications, then you'll want to look at this.  Post R2 this would be the recommended route to take if you had a LOB application you needed to integrate with, rather than writing a Custom Adapter.  You'd simply write an LOB Adapter in .NET using this SDK, and then implement with the WCF Adapter for BizTalk.  The benefit there is that the work in the Adapter would be re-usable to other WCF .NET applications and not tied exclusively to the BizTalk object model.

With my current client I've had a chance to work with the SAP adapter for the first time, which is a treat since most of my work with BizTalk has revolved around HIPAA and EDI.  So I've been working with it for several weeks, and I very much like the delivery of the adapter with one, glaring gotcha which I'll discuss.

The way the adapter works is that you can access any iDoc or RFC from SAP by creating a port configured with identity you will connect with, and then selecting to add items to your solution and select Add Generated Items... and finally select "Add Adapter Metadata".  You can then walk through the process of selecting your port and searching for your RFC or iDoc.  When you've completed the wizard you will have a newly generated XSD schema added to your project.  Happy days, and off you go, until deployment time.

You see, when the wizard walked through that process, for an RFC, it generated an assembly, quietly, in a directory which on most boxes will be : C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\Bin.  That assembly is required for the Adapter to work at runtime, and as such must be included in your deployments.  Add to this pickle that the assembly is not strongly named, so you can't put it in the GAC like everything else and life get's really interesting. 

This one caught me completely off guard, and personally I consider this a major flaw in the design of the adapter.  I've now added two new items to my "To Do" list.  First, implement Scott Colestock's deployment framework on my project so I don't have to deal with external resources and the BizTalk "Export MSI" functionality.  Second, learn more about the Line of Business Adapter SDK and the new WCF adapters to systems like SAP that I attended a talk about at TechEd this year.

I've never been able to get myself motivated to pursue the Microsoft certifications in the past, the value proposition for me as a BizTalk Server developer was never there.  First, for a long time there were no BizTalk certifications, and even once they created such certifications I was never asked about them when pursuing positions.

But some of that has changed, first I now work for a Microsoft Gold Partner and the more certified people they have on staff, the easier it is for them to maintain that status.  Secondly I'm currently engaged in some internal planning and as part of that it was going to be very helpful if I knew just exactly what was required to achieve the BizTalk certification.  Enter TechEd and PearsonVue...

On Monday and Tuesday at TechEd 2007 I had some free-time, some by choice because none of the tracks interested me, some because the sessions I wanted to attend were canceled.  PearsonVue had a testing center setup at TechEd and had lowered the exam cost to $50 per test.  That was well within the area at which I could "risk" the money on not passing, so I decided to take 70-235 “Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2006”.  I've been working with BizTalk Server since 1999 when I was part of an organization doing Alpha and Beta adoption of BizTalk Server 2000.  I know the product very well, but I still expected to fail because I have always had the impression that the certification exams covered minutia that you would not encounter in your day to day work with the product.  Apparently I was wrong, I passed the exam and in so doing earned the "MCTS: BizTalk Server 2006" certification.

So since I was pleasantly surprised by what was expected for that exam, I decided to take TS: Microsoft .NET Framework 2.0 – Application Development Foundation, which I also passed.  That exam had allot of asynchronous questions on it, but I did well enough.  So since I was now officially on a streak I went and took TS: Microsoft .NET Framework 2.0 – Distributed Application Development, which I also passed.  That means I've also met the qualifications for "MCTS: .NET Framework 2.0 Distributed Applications".

Finally I did take, but not pass, the Web exam as well.  It contains two question areas that I was weak on, and that was my undoing.  Specifically it contains questions on Mobile web development, and "Deployment Scenarios" which are all about which Wizard/Tool you would use.  Since almost all my deployment scenarios for Web are done manually because I understand what each of the files in the solutions do, I was weak on the tools which publish/copy your site for you.

All in all, it was a good week, and I'm pleased with the quality of the certifications from Microsoft.  It's not going to guarantee you an guru, but it will ensure you've got someone competent at the technologies.

So I'm wiped.... my first day of TechEd behind me and Party with Palermo complete.

It was a great day, particularly the Pre-Conference training I attended by Jon Flanders of Pluralsight and Richard B. of DevelopMentor.

I learned quite a bit, I already had alot of the basics down, but the more advanced look into what WF could do was great.  In particular I hadn't learned anything about Dynamic Change or custom services prior to this class.

Jon and Richard did a great job, and I'm glad I've planned to attend most of Jon's session for the rest of the week.

Alright, I'm in final preparations mode for TechEd 2007, if you're looking  to chat or just want to tell me that I'm all wrong about something, then you should be able to find me at one of the following locals/events:

• Saturday
• (tentative) INETA Leadership Summit (Only third and fourth sessions due to flight times)
• Sunday
• Jon Flanders' Pre-Conf training on WCF and WF
• Party with Palermo
• Monday
• Lots of Connected Systems track classes
• Moderating the Birds of a Feather : "BizTalk, WCF and WF" at 3pm
• Tuesday - Friday
• Lots of Connected Systems track classes

I may also make appearances at other less publicized events ... if you've got a party going on ... let me know.  If you've got a party going on and some good vodka? Definitely let me know.

As usual, Tim@TimRayburn.net will buzz my blackberry throughout TechEd.  Or you can send me a Direct Message via Twitter.

So unless you don't read any of the "big" .NET bloggers (like Scott Hanselman's Blog or Podcast, Phil Haack, Jeff Attwood, etc) then you're likely familiar with the "FizzBuzz" problem described in those various posts.  In case you missed it, the idea of FizzBuzz is a super simple coding exercise which can be completed during the course of an interview to prove that the candidate can at least write a program.  FizzBuzz in particular is an example of that as follows:

Write a program that prints the numbers 1 to 100.  But for multiples of three print "Fizz" instead of the number and for multiples of five print "Buzz".  For numbers which are multiples of both three and five print "FizzBuzz".

It's simple, elegant, and proves that the candidate can at least write simple code.  As many people have pointed out, it will not highlight great developers, but it will knock out bad ones.

My question to the assembled audience here is, what is a good FizzBuzz problem for BizTalk?  Obviously asking you to write a custom Adapter or Pipeline component is just right out.  They are to complex to be accomplished during the time of an interview.  But what is a fair example of this type of problem for BizTalk?

How about sometime like this:

Write, deploy and start a BizTalk solution which will accept an XML file containing a root node named "Root" and a potentially unlimited number of child nodes of the root called "Data" from the path "C:\Test\In" and will output the same structure with to "C:\Test\Out" with the value of every "Data" node multiplied times 100.

Sample Input:

<Root>

    <Data>1</Data><Data>2</Data>

    <Data>1</Data><Data>2</Data>

</Root>

Sample Output:

<Root>

    <Data>100</Data><Data>200</Data>

    <Data>100</Data><Data>200</Data>

</Root>

The problem here is there isn't such a thing as the "5 minute" BizTalk Solution.  I think I could do this solution in 5 minutes, but I wrote the thing.  What do you think?  Is this unreasonable to expect during an interview? Again, the point is not to prove you know BizTalk Server inside out and backwards, it's to prove that you don't know it at all through failure.  Thoughts?

As you likely know if you read this blog, I'm employed by Sogeti as a Principal Consultant.  I'm part of the Microsoft Practice and focus on BizTalk and overall "Connected Systems" architecture.  Living in the Dallas area, the name I most often hear after "BizTalk" from a clients mouth is "SARK".

"SARK" or Software Architects as they are properly named is a 500+ employee consulting firm with a large Dallas area contingent.  They have alot of BizTalk brain-trust working for them.  I've worked with some of their consultants for a short time at CitiFinancial Auto when I was an independent and was impressed.  I've said before that if I ever were to leave Sogeti that SARK would be high on my list of companies I'd like to work for.

Well I was thrilled the other day to hear the announcement that Sogeti has purchased Software Architects!  This is nothing but incredible for everyone involved, it brings the Microsoft Practice in Texas alone to over 300 consultants.  I'm thrilled to have the guys I know from SARK join the Sogeti family. 

So Mike, Jonathan, and Ben welcome!

It's been a crazy weekend, worked a ton of hours already.  That said, I thought I would archive here some information that can be found other places, but I wanted at hand when next I needed it.

The following table contains the macro replacements that work within the File Adapter for BizTalk Server.