If you are not at TechEd this week and you are in the Central Ohio area, check out MOCSDUG’S (Mid-Ohio Connected Systems Developers User Group) meeting this Thursday, June 5th at 6PM. Richard Broida from Bennett Adelson will be presenting on Microsoft’s ESB Guidance.
See the link below for all the details:
Introduction to ESB Guidance by Richard Broida
I recently downloaded Windows 2008 and I ended up with 1.76 GB worth of files you would typically see when you load the ISO or CD. See screenshot below. Unfortunately, burning a CD or ISO from the files shown below will not result in a bootable OS media.
I needed to convert this folder with files into a bootable ISO so that I can easily boot from it when installing Windows. After some searching, I found that this can easily be done with CDImage. I used the following command:
Command
D:\Downloads>CDIMAGE.EXE -m -u2 -b”d:\Downloads\X86 VL\boot\etfsboot.com” “d:\Do
wnloads\X86 VL” d:\Downloads\Windows2008_X68_VL.iso
Options
-u2 encode “UDF” file system without a mirror ISO-9660 file system
(requires a UDF capable operating system to read the files)
-m ignore maximum image size of 681,984,000 bytes
-b “El Torito” boot sector file, no spaces
(e.g. -bc:\location\cdboot.bin)
If you have specified the correct set of options, then you should see a ISO file generated in about 30 minutes.
Now off to configure my shiny new Win2k8 VPC….
I recently wrote an article for ASPAlliance on Using BTSTask to Create MSI Deployment Packages. Check it out!
Update (4/7/2008):
Please note that this pipeline component is not a substitute for the Message Tracking feature in BizTalk which can track messages at the port and orchestration level. Message Tracking is a built-in feature within BizTalk and has all of these advantages:
It is important to note however that the Message Tracking feature is a system level tracking which tracks messages at an artifact level (Orchestrations and Ports). If you need message tracking that has more context within a business process then you should consider using BAM with message body tracking. My PC below is an alternative to the BAM solution since I provide hooks for tying the tracked message to other business level tracking data.
Thanks to Michael Stephenson for his valueable feedback regarding this topic.
Original Post (4/6/2008):
If you ever had any requirements to archive or log a BizTalk message then you have probably looked into handling this within a pipeline component (PC). I had a similar requirement but I wanted to be able to log the message into a database table. There is a pretty decent example of a PC that can log messages to file on Gille’s WebLog. The sample code may be a little outdated though.
So I set out to build a PC that can log BizTalk message parts on receive or send sides and also be able to abort gracefully in the event of a failure. Since logging is a non-critical operation, I do not want a failure during this operation to disrupt the entire process. My primary goal for this PC was to read the message data in a streaming fashion and then save it to the database in chunks. This design allows the PC to be scalable when dealing with large messages.
Let’s start by looking at the database tables necessary for storing the messages.
The first table is named IntegrationMessages and it has only one column named PayloadMessageId. This table has one record for every interchange that arrives into BizTalk via receive pipelines or leaves BizTalk via send pipelines.
The second table is named IntegrationMessageParts and it is used to store the actual message parts in binary format. Note that we are storing all message parts and not just the body part of a message.
Now let’s take a look at the design time properties available within this pipeline component.
Design time properties:
Enabled: This property enables or disables the logging capability of this pipeline component. If Enabled is false, then the pipeline component simply passes on the message down the pipeline without any processing.
LogContext: This property specifies whether this pipeline component is being used in a receive pipeline or a send pipeline.
MsgReadChunkSizeInBytes: This property is used to specify the size of the buffer used to temporarily store the message contents while reading from the stream.
ReceiveContextPropName: This property is only applicable when the LogContext is set to Receive. It is used to specify the property name when writing the PayloadMessageId (from the IntegrationMessages table) to the context.
ReceiveContextPropNamespace: This property is only applicable when the LogContext is set to Receive. It is used to specify the property namespace when writing the PayloadMessageId (from the IntegrationMessages table) to the context.
SendContextPropName: This property is only applicable when the LogContext is set to Send. It is used to specify the name of the property that allows
SendContextPropNamespace: This property is only applicable when the LogContext is set to Send.
Download BTSMessageLogger Solution. It includes the pipeline component project, a sample BizTalk project that uses the component and a Windows application to view the logged messages in the DB.
Instructions
1) Extract the contents of the BTSMessageLogger.zip to C:\
2) Deploy the CustomerProcess project from within Visual Studio
3) Run the .\SQL\BTSMessageLogging_CREATE.sql on the local SQL instance to create the logger database
4) Import the bindings from the binding folder
5) Start the application
6) Drop the .\Sample Data\Customer3Rows.txt into C:\BTSMessageLogger\File Drops\In
7) Three (3) xml files should appear in C:\BTSMessageLogger\File Drops\Out
Use the MessageViewer application to view the logged messages
I ran into the error below when configuring BizTalk in a multi-server environment (1 SQL Server + 1 BizTalk Server). It turns out that both servers were members of a NT4 domain. I discovered that BizTalk does not support NT4 domains. As stated in the installation document, only Active Directory (AD) domains are supported.
TITLE: Microsoft BizTalk Server 2006 Configuration Wizard
——————————
CORP\QABTSServerAdmins is not an valid domain group. (ConfigHelper)
——————————
ADDITIONAL INFORMATION:
The specified domain either does not exist or could not be contacted. (ConfigHelper)
Have you ever seen the error below? The error tells you that it cannot find a file but it does not mention the name of the file! In my case, I had a map with a script functoid that referenced an external assembly. It turns out that I copied this map from another project and the assembly reference was no longer valid. I should have encountered build errors but instead I had to deal with this issue at runtime.
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5753
Date: 2/8/2008
Time: 2:24:53 PM
User: N/A
Computer: QSI-BTS06R201
Description:
A message received by adapter “FILE” on receive location “RCV.CUST.DATA.FROM.SYSTEM.A” with URI “C:\BTSMessageLogger\File Drops\In\copy*.txt” is suspended.
Error details: The system cannot find the file specified. (Exception from HRESULT: 0×80070002)
MessageId: {A916E973-85FB-42B0-83CB-84670D0DDAFF}
InstanceID: {62D1A2A0-9D45-447C-ACD0-17F273E21762}
Have you ever seen VS2005 freeze when building BizTalk projects? I have and it was not a pleasant experience. In search for a solution back in October last year, I meticulously collected info about my environment and posted it on MSDN Forums. I just ran into this problem again today and I saw that someone responded to my post with a solution that actually works! Even though the solution is ridiculous it worked for me. Thank you Hema!
Check out the BizTalk Assembly Checker tool out on codeplex. I wish I had known about this tool before because it would have saved me some time when doing production deployments with multiple servers. This tool allows you to verify that your BizTalk assemblies are present on all of your BizTalk servers. Once you run the verification, you can also copy the assemblies from one BizTalk server to the GAC of all the other BizTalk servers. This means you only need to login to one of the BizTalk servers when deploying.
Drum roll…
I’ve been given the exciting opportunity to start a subgroup under CONDG (Central Ohio .NET Developers Group). You can read more about the recent updates at CONDG on Steve Harmans’ blog post. The sub group is named MOCSDUG (pronounced mocks-dug) which stands for Mid-Ohio Connected Systems Developers User Group. You may wonder why the sub group does not use “Central” for the first word within the acronym. I will leave that your imagination.
The motivation behind starting MOCSDUG is to raise awareness about specific type of challenges we face today in the Enterprise (note the big E). Most of members of CONDG are already familiar with the challenges they face when building client/server, smart client, and web applications. The challenges are not new and we can build manageable solutions using different frameworks and patterns (EntLib, NHibernate, Active Record, Monorail, etc) in our enterprise.
So where does this brings us? We now have 5 or more custom applications each possibly using a different database, framework and language in our Enterprise. Pretty soon someone will ask you how we can make App A to talk to App B, App C to App A, App D to App A and so on. One of the first approaches to this problem is to write custom code to integrate each application with another application. This is called point-to-point integration. Although this is a reasonable approach within an enterprise that has a handful of apps, it quickly becomes complex and unmanageable. If you have 5 applications and they all need to talk to each other, the number of points of integration (custom code in each app) will equal to 10. The formula for this is n*(n-1)/2 where n is the number of apps. There are multiple solutions available to address the point-to-point problem and you can read all about them at your leisure.
The Integration Problem is central to the challenge I was referring to earlier and our approach to connecting systems will address this problem. Enter ESB, SOA, BPA, BPI, and Click here to generate another acronym. Also enter BizTalk, WCF, and WF. The goal of MOCSDUG is to focus on these technologies and approaches to understand how we can better solve the integration problem.
I am currently still working to get a site setup for MOCSDUG so please be patient. In the meantime, do not hesitate to contact me (mnagisetty at gmail.com) if you would like to be added to the mailing list.
It looks like some of you are already excited and blogging about MOCSDUG. That’s great! Spread the word!
http://condg.org/archive/2008/01/25/Sub-Group-Formed-MOCSDG.aspx
What is codemash you say? It is a very exciting event where we mash up every technology you can think of within a 2-day conference. Just to name a few of those technologies: Ruby, Rails, Groovy (whaaat?), .Net, Java, Python. I am really excited to step out of my BizTalk mapper and Orchestration designer comfort zone to learn some new technologies and concepts.
I am looking forward to some of the testing sessions to see how I can better implement testing strategies within the integration space. In my opinion, I just don’t think there is a good way to write unit tests for my BizTalk projects. I will admit that we have tools like nUnit and BizUnit but they just don’t cut it. Integration is more complex than just dropping a file and checking for the existence of that file a few minutes later. I feel that the unit within the unit test is too large. We need better ways to unit test individual BizTalk artifacts such as orchestrations, maps, pipelines, schemas, etc.
We do have some tools and functionality but we need a unit test framework that stitches them all together. The tools and functionality I am referring to are:
