Accepting Nominations for BizTalk Server 2006 R2 Technolgy Adoption Program (TAP)

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

BizTalk Server 2006 R2 will add several new features to the BizTalk product such as native EDI B2B services and RFID Framework plus it will include enhancements to improve compatibility with Windows Vista and Microsoft Office 2007 products.


Summary of new features include:


%u00b7         Microsoft’s B2B EDI/HIPAA Solution


%u00b7         Microsoft’s RFID Framework


%u00b7         BizTalk Adapter for Windows Communication Foundation (formerly called Indigo)


%u00b7         .Net Adapter Framework


%u00b7         .Net Line-of-Business (LOB) Adapters (formerly BizTalk LOB Adapters)


%u00b7         BizTalk Dev Environment Compatibility with Windows Vista


%u00b7         BizTalk WSS Sharepoint Adapter Compatibility with MS Office 2007


BizTalk Server 2006 R2 TAP nominations are open through July 31, 2006 and space is limited.  This program is filling up quickly so if you would like to participate we would encourage to submit a Nomination form now.  Nomination forms and additional program details are available from BizTalk Server 2006 R2 TAP website.


To access this website please follow these instructions:




  1. Go to http://connect.microsoft.com


  2. Sign in using a valid passport account


  3. Select  Available Connections


  4. Look for  BizTalk Server 2006 R2 and select the Apply link on the right hand site


  5. Note: The BizTalk Server 2006 R2 program will not appear unless you are signed in with a valid passport account.


  6. Select I Agree


  7. Complete the Registration form


  8. Once logged on to the BTS 2006 R2 Site select Downloads


  9. Select the BizTalk 2006 R2 TAP Nomination Form link

Please mail your questions to btsr2tap@microsoft.com


 


Best Regards and we look forward to hearing from you,


The BTS 2006 R2 TAP Team!



 


 


BizTalk Blogging Year In Review

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

Just a bit over a year since I started BizTalk blogging, so I thought I’d take 5 minutes and review the posts of the last year (126!?!)
and try to find some highlights.

It’s been a fun year, and I greatly appreciate the feedback and suggestions the community has provided.

Technorati Tags: BizTalk

Generated C# code in BizTalk 2006…

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

In my last
post I indicated there was a better story in BizTalk 2006 for working with the
C# code that is generated as an intermediate when compiling ODX (orchestration)
files – that is, better than having to deal with temporary files and the BizTalk
2004 File Dump utility. 
I

If you’ve worked with BizTalk 2006, you might have already stumbled across this. 
The xlang compiler for BizTalk 2006 is kind enough to place the intermediate C# file
for your ODX directly in the project directory.  If you have multiple orchestrations
in an assembly, you will find a C# file for each orchestration – but only one of
those files will actually have content (all the generated C# code is consolidated
into one file.)

What this means is that you can do symblic debugging of orchestrations in a fashion
far easier than what I
described for BizTalk 2004.  The Edit/Debug cycle might look like this:

  1. Build your orchestration project.
  2. Open the associated (generated) C# file – perhaps make it a solution item
    for convenience.
  3. Search for something in one of your expression shapes (say “MyClass.Execute”), and
    set a breakpoint.
  4. From the Debug menu, choose Processes and attach to BTSNTSvc.exe. (Have more
    than one?) Choose CLR debugging only – not native. The symbols should be loaded
    automatically – no need to copy PDBs to the GAC for this case.
  5. Trigger your orchestration however you normally would.
  6. Find your problem, Debug-Detach All, and fix the problem in the orchestration.
  7. Decide that you really want Gilles’
    MessageContext Debugger Visualizer

There is another benefit to having the generated C# files for orchestrations be more
accessible…If you deploy your PDBs
to the GAC, either using either my upcoming deployment work for BizTalk 2006 or
just the GetGacPath2 utility that I made available here,
you will find that stack traces that are recorded in the event log actually reference
line numbers within the generated C# code.

As I said in an earlier post, if you are responsible for troubleshooting BizTalk applications
in production, you are likely hungry for all the information you can get about why
something is failing.  Since all BizTalk project assemblies are in
the GAC, the stack traces you get (either from your own logging, or the event logs
BizTalk generates for unhandled exceptions) do not contain file and line number information
by default.  This makes post-mortem analysis a lot harder…

When a BizTalk 2006 application is deployed to production, you might consider archiving
the generated C# code for production support.  If you use GetGacPath2 to
put PDBs in the GAC, you will have file and line number information within captured
stack traces to aid in troubleshooting. (Note that GetGacPath2 supports MSIL,
32 bit, and 64 bit assembly caches.  MSIL is the right choice for BizTalk 2006
projects.)

Generated C# code in BizTalk 2006…

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

In my last
post I indicated there was a better story in BizTalk 2006 for working with the
C# code that is generated as an intermediate when compiling ODX (orchestration)
files – that is, better than having to deal with temporary files and the BizTalk
2004 File Dump utility. 
I

If you’ve worked with BizTalk 2006, you might have already stumbled across this. 
The xlang compiler for BizTalk 2006 is kind enough to place the intermediate C# file
for your ODX directly in the project directory.  If you have multiple orchestrations
in an assembly, you will find a C# file for each orchestration – but only one of
those files will actually have content (all the generated C# code is consolidated
into one file.)

What this means is that you can do symblic debugging of orchestrations in a fashion
far easier than what I
described for BizTalk 2004.  The Edit/Debug cycle might look like this:

  1. Build your orchestration project.
  2. Open the associated (generated) C# file – perhaps make it a solution item
    for convenience.
  3. Search for something in one of your expression shapes (say “MyClass.Execute”), and
    set a breakpoint.
  4. From the Debug menu, choose Processes and attach to BTSNTSvc.exe. (Have more
    than one?) Choose CLR debugging only – not native. The symbols should be loaded
    automatically – no need to copy PDBs to the GAC for this case.
  5. Trigger your orchestration however you normally would.
  6. Find your problem, Debug-Detach All, and fix the problem in the orchestration.
  7. Decide that you really want Gilles’
    MessageContext Debugger Visualizer

There is another benefit to having the generated C# files for orchestrations be more
accessible…If you deploy your PDBs
to the GAC, either using either my upcoming deployment work for BizTalk 2006 or
just the GetGacPath2 utility that I made available here,
you will find that stack traces that are recorded in the event log actually reference
line numbers within the generated C# code.

As I said in an earlier post, if you are responsible for troubleshooting BizTalk applications
in production, you are likely hungry for all the information you can get about why
something is failing.  Since all BizTalk project assemblies are in
the GAC, the stack traces you get (either from your own logging, or the event logs
BizTalk generates for unhandled exceptions) do not contain file and line number information
by default.  This makes post-mortem analysis a lot harder…

When a BizTalk 2006 application is deployed to production, you might consider archiving
the generated C# code for production support.  If you use GetGacPath2 to
put PDBs in the GAC, you will have file and line number information within captured
stack traces to aid in troubleshooting. (Note that GetGacPath2 supports MSIL,
32 bit, and 64 bit assembly caches.  MSIL is the right choice for BizTalk 2006
projects.)

2006 Business Process Management and Integration Conference in Redmond (Oct 3-6, 2006)!!

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

Awesome, Rob Bannerman (Product Management Team) emailed me to day to let me know that the registration site is open for the 2006 Business Process Management and Integration Conference in Redmond! You NEED to get to this conference. It will rock (it did last year!). His email reads:

 

Everyone, the registration site (http://www.impactevents.com/biztalkconference/) for the Business Process Management and Integration Conference is now live. Please invite your colleagues to register by July 21st to qualify for the early bird rate of $149.

Overview
Microsoft’s Business Process Management and Integration Conference is the event for our partners, customers and field personnel to get up to speed on new and updated solutions for Business Process Management (BPM), SOA and Workflow. Over 4 days, attendees will learn about the strategies and technologies that Microsoft is delivering over the next year, such as BizTalk Server, WinFX, and Office 2007. Three technical tracks will provide depth and detail into best practices for building BPM solutions, SOA guidance, and implementing BizTalk Server. A business development track will focus on the business value of BPM for both customers looking to optimize their processes and for partners looking to expand their practices. Whether you need to get up to speed, or are ready to dive deep, this is the event for technical training, networking, and business development for partners and customers interested in BPM, SOA, and Workflow.

Registration
Join Microsoft staff, valued partners, customers and industry thought leaders at the Microsoft Conference Center from October 3-6, 2006. Registration is $199.00, with an early bird discount price of $149.00 if you register by July 21st.

Please let me know if you have any questions or concerns

Thoughts on Testing a candidate on the BRE-Exam Aid -1

by | Jun 23, 2006 | BizTalk Community Blogs via Syndication

The Business Rule Engine.


If you are a BizTalk enthusiasts, hobbyist, developer, architect, or  implementer, the BRE is definitely something that you are going to come across.  I’m not going to explain what the BRE is, there are many resources on the web, just google away for this topic. However, if you claim to know about the BRE, how does one test this knowledge?


Naturally, one could sit down at a developer configured system, and you can say, “Build me a BizTalk app that uses the BRE, you have an hour to do so.” This would test knowledge of implementation.  If the candidate performs the task, then we exclaim, they know BRE.


But how do you put the literal simulation into words without writing a book? Then how does one give an answer without the same?


Well one thought pattern was to build a quick scenario such as:


Company X is currently running version 1.0 of a policy. A new rule is implemented and saved to version 1.1 of the policy. You need to implement an orchestration that can call version 1.1 of the policy while version 1.0 of a policy must continue to be supported by other orchestrations.


The next thing would be to compare the answer. A question of this nature places many things into the mix. This was a scenario that really occurred, I was put to the test to see if I really understood the BRE.


At first thought, I took the scripted answer from Scott Woodgate’s book and said, orchestrations use the call rules shape to call into the BRE. The Call rules shape can only call into deployed business rules. So the answer to this question is it can’t be done.  As I was getting ready to say this, I remember Kunta Kente from roots where he said the in his native language, “Can’t” does not exist, which led me back to being a developer for a second instead of just an ordinary trainer or consultant.


I envisioned, I’m a developer I can do anything with enough thought and a little design.  After all, isn’t that OOP, reusability, software design at its best???


Do I really know the BRE?  The BRE can be called from any host, not just BizTalk. Why not use the same method of thought to call into the BRE that another engine such as a Windows desktop app? BINGO!!!!


The answer became simple, use an orchestration to manually call into the BRE using RuleEngineComponentConfiguration class, a factretriever.  Next, use the PolicyTester class to tell the RuleEngine which version of the policy to call into. I created a proof of concept, and it was done.


Here’s some sample code detailing the Proof of Concept:


using msre=Microsoft.RuleEngine;
using Microsoft.BizTalk;
using Microsoft.BizTalk.RuleEngineExtensions;
…


            try
            {
                msre.RuleSetInfo rsi = new msre.RuleSetInfo(msg.policyTesterName, msg.policyVersionMajor, msg.policyVersionMinor);
                RuleSetDeploymentDriver dd = new RuleSetDeploymentDriver();
                msre.RuleStore sqlrs = dd.GetRuleStore();
                msre.RuleSet rfpRules = sqlrs.GetRuleSet(rsi);
                msre.RuleSetExecutionConfiguration exConfig = new msre.RuleSetExecutionConfiguration();
                msre.RuleEngineComponentConfiguration dbConfig = new msre.RuleEngineComponentConfiguration(msg.policyFactDisplayName, msg.policyFactRetrieverFQN);
                exConfig.FactRetriever = dbConfig;
                rfpRules.ExecutionConfiguration = exConfig;
                XmlDocument doc = new XmlDocument();
                doc.Load(xmlFile);
                msre.TypedXmlDocument rfpDoc = new msre.TypedXmlDocument(msg.documentTypeName, doc);
                msre.PolicyTester host = new msre.PolicyTester(rfpRules);
               
               
                //Create thread to run engine
                host.Execute(rfpDoc);


               …..


The above may seem like a lot of code, however, there are less coding efforts possible using these classes.


                When showing knowledge on a particular topic, don’t just give the scripted answer, know the essentials, and use them.



 


Downloading and installing .NET 3.0 (previously WinFX)

by | Jun 22, 2006 | BizTalk Community Blogs via Syndication

I’ve received numerous questions recently about where to find the latest and greatest WCF build, especially since the name change from WinFX to .NET 3.0. One way to find the bits is to browse to Microsoft’s new .NET 3.0 portal site at http://netfx3.com and follow the link to downloads. However, I promised folks that I’d post the actual download links here:
If you’re looking to get a WCF development environment up and running, all you need is VS.NET 2005 and the first link (runtime components) above. The rest of the downloads give you some extra development tools but you don’t absolutely need them to write/run WCF code. The last link is only required if you’re planning to do some Workflow development.