sfeldman.NET

I have run into this issue trying to add custom pipeline component to toolbox. The only way (I know about) to add a custom pipeline component to a customized pipeline is using the visual designer. In order to do that you have to have components on toolbox. This was a bit frustrating. Google has brought one result which was exactly what I needed. One of the comments had another link, to the similar issue, but this time with a different title: Hotfix for BizTalk 2009 and Visual Studio 2008. I followed the link, installed hotfix, and it worked. Oh, yes, you have to reboot your machine for hotfix to work completely (this is where I spent some time pulling my hair out and asking why hotfix didn’t work?!). Once this is done, you are good to go.

Among other things, this hotfix deals with BizTalk project references to each other and items not being updated (like distinguished fields in schemas project not reflected in orchestrations project). Here’s the full list:

* The orchestrations in the referenced BizTalk project may show compiler warnings.
* The changes that are made to the referenced BizTalk project are not propagated on to the referencing project.
* When you edit the orchestrations of the referenced project, XLANG errors are thrown. These errors may disappear after the orchestrations are saved and recompiled.
* After you deploy the referencing project, the local copies of the referenced project’s binaries are deleted.
* After you deploy the referencing project, various errors or warnings occur in Orchestration Designer.

Time saving project to generate BizTalk Server Pipeline Components.

ESB Toolkit Extensions is an open-source library giving you an extended BRE/BRI provider to read and write promoted properties of a message within business rules engine. I’ve used it to achieve automated process for mapping to canonical schema and then back to destination schema based on receiver ID as a promoted property (will blog on this later). A very useful library!

Here I am shouting again about the fact that we are looking for good developers. Our team has matured, and now definition of a “good developer” is not what we used to think of it before. Don’t misunderstand me, we are looking from smart people, but also rounded people.

Our team has shrunk by one developer, whom ironically I welcomed aboard a little more than a year ago. Life is life, and things are dynamic. I wish him good luck, and hope to see the replacement coming soon.

So if you are in Calgary area and happened to be .NET / BizTalk / Agile developer – drop me a note.

A X509 Certificate is required in the model property 'EncryptionCertificate' to encrypt any sensitive property in the designer.

By design, Itinerary designer requires a certificate to save a newly created itinerary. This is required to encrypt “sensitive”  data. What if you don’t have that kind of data, or not willing to use certificate? There’s an option to disable designer from requesting the certificate described in linked post, as well as how properly to use one in case it’s needed.

Once value is switched to false, error will become a warning, allowing itinerary persistence without certificate.

I run into something really annoying this morning with Itinerary DSL in VS.NET designer. The only way to create an itinerary is to create it in a project of a library type. This is confusing, since for a simple application, I should be able to achieve the same with a plain BizTalk project. The ironic part is that within BizTalk project creation of itinerary IS an option, but when selected, add a new (standard) BizTalk item dialog shows up, with no itinerary in it. A bug?

In order for a send port to subscribe, it has to filter messages dynamically, based on several Itinerary schema properties (as described in documentation). Properties and values are:

• IsRequestResponse = False
• ServiceName = Some_Service_Name
• ServiceState = Pending
• ServiceType = Messaging

Filtering is done on promoted property from Microsoft.Practices.ESB application. In order to use those promoted properties, first Microsoft.Practices.ESB application should be referenced. Basic knowledge for an experienced BizTalk developer, but wheel spinning time for someone new.

This is history repeating itself, so I wanted to share the story in case it will help someone.

For my cell phones I use Nokia. My next phone I wanted was N900 model. I was waiting for it, but it’s coming too slow to N. American market. So about a month ago I bought one on eBay, making sure it’s not a fake (asking the seller all kind of questions). The guy was a total jerk and lied all about it. I ended up getting a fake, which I complained about and got my money back (by PayPal) as a part of buyers protection plan which is great. Either way, this is not story about how I get tricked every time I buy a Nokia on eBay (yeap, it happened with previous models as well), but more to highlight the differences in case you buying one or planning, so that you don’t have to go through the same.

Packaging – amazing. From outside it is almost identical.

The only difference is Chinese ignorance to multiple European languages Nokia traditionally supports out of box

But that’s not something a lot of people would pay attention to. Weird thing is that inside, the box says Nokia-Asia. That’s not typical for Nokia either.

But who knows, times change, things change. Once I opened it to get the phone out, it was obvious – this is a fake. The packaging was… well, sloppy and really bad.

Seriously? Do you sell a $500 phone packaged like that? I don’t think so. You thought packaging was bad? Look at the phone itself!

Something to keep in mind – Nokia phones come with dark screen protector, the one that allows to see that phone is turned on/off, but annoying to be used extensively with it. And yes, it’s done on purpose. Then you look at it and WTF?! Two speakers? Why? Later I figured out that one is actually for the phone, another one to yell annoying sounds.

The back of the phone was… funny. Quality is not something fakers think about. So what if the logo is misaligned (BTW, Nokia embeds logo within the plastic, not just prints it on it).

Anyways. Camera is suppose to be 5MP with dual flash – good luck on that. Flash was completely missing. And the stand helper (is up on the image) is not snapping to the body, but has to be forced in – horrible idea.

Oh well, I decided to see what accessories would look like. Boy there was a real surprise.

You got to be kidding me. A plastic bag chewed up and stuffed into box so that “accessories won’t move around” (I presume so)? Well, at least I know what grocery store they go to… :)

Cool. Accessories. Hmmm, wall charger, really ugly headphones, USB cable that is not wrapped, nothing for standard TV connector, nothing for non-USB charger (compliance with chargers from models like N95), and 2 batteries. Wait a second, 2 batteries?!

Yeap. Well, then you lucky then. Extra battery. Great. But which one is the right one?… The one that is made in China and further processed in China or the one that is made in Korea and further processed in China. To make it even more confusing, the are not the same size (physical size)!

Let’s see what manual says.

Thanks goodness it’s in English. Not only you’ll get start using the phone, but also will get introduced to new N900. Oh, wait, shouldn’t it be vice versa? Just lets start reading. Ops.

Ok. Lets get to table of contents, it will have English section there. Well, maybe

Hmm, I know! I come from a place where you read from right-to-left, and books are opening on the opposite side. Who knows, maybe.

Wow, surprise, surprise. How nice… environmentally friendly. Sure. I think RPC waste way more natural resources than it protects, but that’s another story.

Note that URL – it’s a real link, the only catch – N900 is not found there! Well, who needs a manual anyways, right? Lets pop the hardware!

Wow, so many stickers to show it was tested for quality, yet nothing looks quality. Memory card reader looks really outdated, and sim card compartment, well, the door doesn’t actually holds the sim (normally done on cell phones), but only covers it. Let me see where the phone is made… hmm. Nowhere. I see.

Let’s turn it on. Horrible experience. Yes, the image matches Nokia, but it is so lamely copied. Sound that came out of that “thing” was just shocking.

Alright. Lets see it in action. Wait a sec, why everything is looking wrong?

No sensor. Not that touch screen and resolution are that great.

Aha, that’s the trick. You have to open the phone, only then it rotates the content. Dumb. Really dumb. And UI/UX are HORRABLE.

Ok. So far I was making fun of it. Yet this is not funny. I wonder how many people are out there, thinking they are using real thing, but instead using a hazardous device? (I am sure this will fail any health test). And it’s not only phones these days.

This is a thought I had to a post I read this morning. Doug, who’s running a company that does software development, has published a post about Developer Computers. It is interesting to observe developers position vs. business people position. Yes, developers want the latest and the greatest, and if possible, something that will be still up-to-date tomorrow. Business people often do the opposite; especially highlighting the fact that developer’s appetite for new hardware is not justifiable. Being developer myself, I’d like to show a few things, material for a thought.

Developers are often (if not always) required to be highly efficient, productive, and make ROI as quick as possible. What developers use as a tool to create software? They use computers. Hardware it is. Now, imagine Formula 1 race driver to be expected to win a race with a “decent hardware”. Sounds ironic, doesn’t it? Well, let’s have a pick look at what (most of) developers run these days on the hardware to create software efficiently and with higher quality.

At a company where CI is practiced, running build, unit tests, and code coverage is a normal thing. So it’s no longer “a single window you should stick to”, i.e. IDE. Here a question of a single monitor is arriving – do developers really need multiple monitors? Well, context switching is proved to be counter-productive. How about context switching with windows switching? Reading failed test message AND being able to see the source code that caused the test to fail is helpful. Less switching.

How about the tools that we run? I cannot imagine developer working without tools for refactoring (Resharper or an equivalent tool). Resharper requirements, for instance, state it very clear:

Visual Studio .NET 2010 Beta 2:

If you ever played a game on PC, you know that minimum requirements are never enough. And these are not games, but tools. If you use IDE and applying good practices (like a class per file, proper projects/solution structure, etc.) then number of files is quite significant. That means a lot of work OS has to do with files being consistently moved around, updated, created, deleted. I am not saying developers should take a coffee break they rename a widely used class in solution, but I do see the frustration they experience when such a logically trivial operation takes more than just a few seconds. Would you expect business folks to patiently wait for a web site page to load within just 10 minutes? Barely can imagine that.

The bottom line is simple. If you want developers to be productive, allow them to concentrate on work by removing hardware impediments. Hardware is not as expensive as it used to be and is becoming cheaper and cheaper. Monitors, memory, hard disks, they are way cheaper than the valuable time it can save. Always consider if saving a buck today will cause you to pay ten tomorrow.

I have finished reading Pro BizTalk 2009 book from APress. This is a great book  if you’ve never dealt with BizTalk in the past and want to have a quick “on-ramp”. Although the book is very concerned about right way of building traditional BizTalk applications, it also dedicates a chapter to ESB Toolkit and does a good job in analyzing it. The fact that authors were concerned with subject such as coupling, hard-coding, automation, etc. makes it very interesting.

One warning, if you are expecting to have a book that will guide you how to apply step by step examples, forget it. Nor this book does it, neither it’s possible due to multiple erratas found in it. I really was disappointed by the number of typos, inaccuracies, and technical mistakes. These kind of things turn readers away, especially when they had no experience with BT in the past. But this is the only bad thing about it. As for the rest – great content.

Next week I am taking a deep dive course on BizTalk 2009. I really feel that this book has helped me a lot to get my feet wet. Next target will be ESB Tookit. To get to that, I will use what the book authors wrote “you have to understand how BizTalk as an engine works”.