My friend John Evdemon has been writing about the different components of a SOA Reference model. Check the first two posts here and here . Both articles emphasize in the idea of a SOA model based on capabilities that can evolve independently throughout…(read more)
All good things must come to an end, and my time on the BizTalk Server team has expired (self-inflicted of course). One of the best parts about being employed at Microsoft is the endless opportunities that can arise throughout your career. To that end,…(read more)
In
an amazingly fast paced and technical world like we live in, and having the type of
career that I have chosen for myself where I have to stay current on the latest technologies
at all times, it is very hard to find truly amazing, indispensible, sources of information. Scott
Hanselman is undoubtly such a source to me. I’m paid more today because
I read his blog, and I’ve told him so to his face.
He has faced a fight with Diabetes, Type 1, since he was 21 and obviously is passionate
about finding a cure to this prolific disease. He
recently posted this comment:
If you’ve ever thought about giving a’tip’ to this blog,here’s
your chance tomake that tip tax-deductible!(if you’re in the US)You
can also paypal your donation to the email address that is “my first name at
my last name .com” and I will personally deliver 100% of your money myself.
Well you can be sure that my donation is on it’s way, and I challenge everyone who
reads my blog to do two things, first subscribe to Scott’s blog you will not regret
it, and second to donate what you can to the effort he has underway to have Team
Hanselman raise $50,000 for the American Diabetes Association.
Marty Wasznicky (Regional Program Manager for BizTalk Server) and Scott Zimmerman (senior App Dev consultant with Microsoft) have written an interesting MSDN article with Tips for Better BizTalk Programming. This article discusses Multi-Part Messages, Direct-Bound Ports, Internal and External Schemas, Web services and Debugging XSLT. Make sure to read this article; it will help you save time when producing working solutions. Regards, Marjan
After the usual problems with local customs and DHL related to purchases outside the EU, we finally received PhidgetRFID Kit. I am interested in this because it’s a cheap and easy way of trying out BizTalk 2006 R2’s support for RFID (the BizTalk-specific adapter is not out yet, however). I downloaded and installed .Net 2.0’s class library, followed by a simple sample I got from Developer.com (“RFID Programming Made Simple and Cheap” by Bradley Jones), and got it working immediatly. Really great developer experience, out of the box!
RFID is a very interesting techology, even if it’s not mature yet as I hope it will be in the future, and the ability to easily make the bridge from the hardware to the software/applications side is very welcome for those of us working in the integration space.
As a final note, Phidgets has software to allow the integration of their products (which also include sensors, servos, LCD’s, etc.) with Microsoft’s Robotics Studio. The products this company makes, so easily integrated with current technologies, make it a perfect adult toy, in the same vein as Lego’s Mindstorms. 🙂
Just got the new MSDN Magazine in the mail, and now the issue is online. Check out a great read on 8 Tips And Tricks For Better BizTalk Programming co-written by my old pal Marty. Fairly useful stuff.
Technorati Tags: BizTalk
I’ve been interesting in using SSIS ever since I first heard about it. Since I specialize in doing integration work, primarily with BizTalk, I was curious about this new “Integration Services” component of SQL Server. I was a little bit worried that it would supplant BizTalk for a lot of integration scenarios (worried since I’ve invested so much time understanding BizTalk). Since SQL2005 was released I have had a chance to read a lot more about SSIS and also to use it in a couple of projects. I am happy to report that it does not make BizTalk obsolete. But it is important to understand whether to use BizTalk or SSIS for certain integration problems. After reading a few things and discussing this question with some Microsoft folks I believe that the following guidelines should apply:
Use SSIS For:
Use BizTalk for scenarios involving:
A combination of BizTalk and SSIS may be useful in certain circumstances. I have seen situations where an enterprise needed to process a large number of complex operations specified by a partner companies. The partner enterprises would send large files (by FTP for example) to the enterprise on a daily basis. These files contained a list of requests for particular services that involved many steps and several enterprise systems. However the first step is to parse and import the large file. SSIS is best suited to import the file. The information about the operations could be imported into SQL Server. For example, each operation record could be inserted into a “Pending Processing” table. BizTalk could then use the SQL adapter to pull each operation record from the table and begin the operation. This is very much like the classic splitter pattern.
I would suggest increasinge thread usage, this is documented here. My general guideline is the number of physical processors x100, 1 processor 100 threads, 4 processors 400 threads.
If those steps do not fix the problem, then a deeper dive into the performance needs to be considered. If you are using 2006, there are some performance counters that come installed. What I like to look at is the BizTalk:Message Agent, there I like to look at Message publishing throttling state. How do we get to there?
Bring up Performance from Adminstaive tools or c:\perfmon from a dos prompt click on System Monitor and the + sign
Let me not forget the link to Microsoft’s official performance information here, and please refer to the disclaimer on the side of my blog.
This should get you well on your way to finding out what is going on, and being able to improve performance of your BizTalk setup.
The first thing to do is if it is v 1.0 (2004) make sure that you have the latest hotfixes installed.
If this does not solve the problem, then to increase the thread usage, this is documented here. My general guideline is the number of physical processors x100, 1 processor 100 threads, 4 processors 400 threads.
If those steps do not fix the problem, then a deeper dive into the performance needs to be considered. If you are using 2006, there are some performance counters that come installed. What I like to look at is the BizTalk:Message Agent, there I like to look at Message publishing throttling state. How do we get to there?
Bring up Performance from Adminstaive tools or c:\perfmon from a dos prompt click on System Monitor and the + sign
Let me not forget the link to Microsoft’s official performance information here, and please refer to the disclaimer on the side of my blog.