BizTalk Design Tools' WebLog

Hey,

First of all great idea to have a way to give feedback of the product.
My first remark is small one but certainly not less of a pain point.

One of biggest pain points I've got with the mapper concerns the scripting functoid.
Instead of just being able to doubleclick the functoid you need to go to the properties window and select the elipses. Really anoying and normally simple to implement.

Gtz,
Danny.

Hi,

just a few goodies:

- making "TAB" work in the expression editor (really sucks opening notepad, copying "TAB" and the pasting it in the expr editor just to get nicely formated code ;-))

- Comment Shapes (the last thing from keeping us throwing away visio for documentation stuff)

- BUG: (surely addressed somewhere else i guess), but if you have a "false" expression in an if clause (may happen if you just want quickly to disable a clause) and have an orchestration call in it you'll get an "System Error" on compiling

- BUG: sometimes you'll get "The expression is invalid" although it isn't invalid. Example: Assembly A contains Class1.DoSomeStuff() => use it in a expression with wrong parameters => Expression is invalid, then fix DoSomeStuff to support the parameter you use in the expression editor, recompile Assembly A and still get "Expression is invalid". You need to e.g. add an empty Comment in the expression to make the biztalk project compilable

So for that's all i can remember.

Thanks,

Christian

I agree to Christians list.

- To reproduce the "System Error" just create a decision with an unreachable path and compile. The motivation to have an unreachable path is during test or development similar to uncommenting a block or forcing a certain condition. An "unreachable code" warning is nice here (and it is there) but the "System Error" was quite hard to track.

- The second one isn't too easy to reproduce. You have to have an orchestration with a dependent assembly and expressions using that. When you know you'll change the interface of a method called in an expression and adjust the call in the expression !before! changing the method, sometimes(!) the orchestration does not get the changed interface and you have to sort of "dirty" the expression shape to compile without errors. The DevEnv seems to be caching too much here. We did not find a "reliable" way of reproducing this, though.

My additions are:

- ... throw away ;) the expression editor and let us edit expressions in a standard vs.net code editor (or some lookalike). If that goes too far, it would really help to at least be able to resize the code window (and perhaps scratch the examples (do people really need this) and add some std. editing functionality buttons (Cut, Copy, Paste...).

- ... support "using" keywords in expressions somehow. Everything else leads to an expression just containing one-liners calling a helper function. To be readable this helper should be in a really short namespace, otherwise you'll have to scroll to see what your expression does. Short namespaces may conflict with a companies namespace convention.

- When it comes to the deployment some recursive features in the tree would be nice. Why can't I just stop or unbind an assembly. Your object model contains everything necessary to easily solve everyones deployment pain. Why does the tree not make use of this?

- What's the motivation for the compiler warning when i have a mapping that uses custom xslt? In our companies policy usually a compiler warning is a stop condition in the production process. Can we get rid of this or have it optional ?

- I feel that a lot of people (I talked to) do not use the mapper at all but rely on custom xslt. It would be nice to open the vs.net xslt editor when double-clicking on such a mapping instead of having to click through the dialog, then the mapper and then the xslt.

- A really minor issue is the "Wait for a Timespan"-Shape (sorry if the name is wrong, we are using a german version). When used in certain contexts it requires a closing semicolon, in other contexts it does not. This can be confusing at first but does not really matter too much.

- Perhaps a localization issue: In the german version the "Else" path of a decision is captioned "Dann", which is just wrong. It should be "Sonst". This would not matter if one was able to rename it, but the modifing the property does not change the caption in the orchestration. It is no problem if you know it, but you can be sure that every person you present the orchestration to will mention it with that "forgiving smile" on his/her face. ;)

This should be enough for a first post.

Btw, thanks for opening a thread like this.

Cheers,
Volker

It'd be nice if property promotions didn't require modification to the schema itself. Seems like these could be captured as xpath queries. If we generate schemas outside of biztalk (e.g., from UML diagrams), we have to manually merge the changes because our generated schemas won't have the annotations.

Good points. We've incorporated all for future release planning. Thanks.

Hello,

Just started with BTS-2004, if you apply a map on a Receive Port, would it be possible to list more than just 1 map in the drop-down if there are more available. It's a bit confusing, I thought my other maps were not deployed, until I noticed the tiny scrollbar.

Patrick.Hoornaert@Capgemini.com

PingBack from http://jointpainreliefs.info/story.php?id=282