BizTalk Server General - If I have the possibility to go back in time, 3 months ago, what will I do?

Author

If I have the possibility to go back in time, 3 months ago, what will I do?

Unknown

2004-05-25, 11:38 pm

Now it is too late, but if I had the chance to go back in time and to change something, the first thing that I would have done is not to use Microsoft BizTalk Server 2004 in that project.

I am sorry Microsoft, but that bloody product was never designed to be used in a real development environment.

Did you ever tried to have 5 developers in 5 different computers developing for the same BizTalk project? And I don’t mean check in, check out, I mean real time development, installation, debugging, etc.

To make it harder, try to use InfoPath and BizTalk ports published as web services for the input, output.

I know, the Microsoft folks love to talk about in the web casts, but did any of them ever used it in a real world scenario?

Not to talk about the database system, why there is an SQL adapter in BizTalk, what is it for? If I can’t use it for any real world solution?

And what about the speed? It is killing me, the system is designed to run as slow as possible, the database adapter is designed to consume the CPU speed, the orchestration and messages are designed to consume the CPU speed, …. Etc.

If I don’t like it, I can buy more processors, then instead of paying 7 or 8$ for a license, I must pay 25K$ for each CPU, about 200K$ for 2 servers, these server will be powerful as a laptop running as a server, with normal web services (with no BizTal
k).

In the real tests the normal web services are running way faster than the BizTalk web services (that if you find a way to publish them either), and when I say faster I don’t mean 1 to 3, I mean 1 to 100, or even 100000000000000000000000 :-(

The web publishing wizard is broken, and publishing a complicated orchestration require tons of scripts to make it work correctly :-(

The bloody SSO service keeps losing its master secret key, and I must call the guy in infrastructure once weekly to fix those BizTalk problems.

I tried so many different installations, more than 20 in 3 month period, and each of them had it’s own unique problems.

Congratulations Microsoft, BizTalk 2004, is the most broken, nonsense, #$@%#$%#$% software you ever designed, the most complicated from a dev point of view too, for no reason, like it could been done way simpler, and way more easy to use.

And that bloody service keeps crashing (yes the BizTalk one).

If I can only go back in time, just 3 month back, if I can send a warning letter to my self, I would never had used it, ever, at least until BizTalk 2010

I also realized that the best way to use BizTalk is not to user BizTalk, starting from tomorrow morning I will stop creating any new orchestrations, I am moving to components, and when I have all the components, I will just link them manually, and uninsta
ll BizTalk before the project goes live.

Don’t understand me wrong, Microsoft VS.NET 2003 is the best development environments, Microsoft SQL Server 2000 is the best database ever designed, .NET and C# itself are the best development platforms ever, InfoPath 2003, and SharePoint v2 are good bu
t need more improvements; but Microsoft BizTalk 2004 does not deserve to use the name Microsoft in front of it.

Don’t believe me, simple, hire 5 developers, give them the software, computers, network, and ask them to develop a software with InfoPath, SharePoint, BizTalk, SQL Server (for data store), give them a complicate task, not a simple one, a real world one,
and record their actions for 3 months, imagine they are a dev group not from Microsoft. You will be surprised!

Nick Malik

2004-06-05, 4:55 pm

hmmm... is this advice? Complaint, perhaps, but constructive?

BTS2004 is fairly stable and is being used to solve real world problems.
It's a darn site more stable than earlier versions of BTS, although it is
still the most difficult installation of any MS product.

Perhaps the problem is that you had 5 developers working on it... Maybe if
you'd had one person develop the proof-of-concept, and learn the "gotchas",
you would have saved a lot of expense and wouldn't have a project that is
destined for replacement.

Maybe if you'd asked for help instead of assuming that you and five others
can just "figure it out." Biztalk is +not+ the most complicated EAI tool.
(IMHO, IBM WebSphere BI is much more complicated). But, honestly, ALL EAI
TOOLS ARE COMPLICATED. That's the nature of the space. There are excellent
BTS Architects and Developers running around. If one of your five guys was
a Biztalk expert, you wouldn't be complaining on this newsgroup... you'd be
boasting.

Perhaps MSFT has done a good job of taking "hard" technology and making it
accessable. SQL Server is fairly easy to administer, compared to Oracle.
Visual Studio comes with so many nice features, it makes development of web
services, and deployment of assemblies, pretty easy. But have you confused
the word "Microsoft" with "all software will be easy to use"? Is Microsoft
responsible for that confusion? (Perhaps in general, but I've seen no BTS
marketing that pretends that "real world" projects are easy, in any tool).

Biztalk is very rough around the edges. BTS2004 is like Windows 3.0... the
first architecture in it's family that is likely to actually succeed as a
product. And just like Windows 3.0 was immediately followed by WFW3.11,
Biztalk has a follow-on release that will be out in something like a year.
With additional features, and many of the rough edges smoothed out. But the
model will survive, completely intact. We have a platform (finally) upon
which to build EAI applications.

As a rough-around-the-edges tool, it doesn't yet have all the features that
scream at you when you abuse it. It just slows down when you use
orchestrations in a twisted way, and it just leaks memory if you call COM
components poorly, and it just fails to work when you ask it to do things
that it wasn't designed to do... Biztalk 2010 may do a better job of
complaining until you change your design to use the tool better. BTS 2004
isn't there yet. But any tool can be mis-used. How's that the fault of the
tool?

As for replacing the orchestrations with components... sure. Go ahead. The
value of orchestrations comes in the ability to change them without calling
a team of developers. If your orchestrations can't be changed without
massive infusions of expert help, then perhaps you +should+ recode them as
components. On the other hand, if you've extracted out the complexities of
your processes into adapters and pipeline components, as Biztalk is designed
to let you do, then the orchestrations provide an excellent visual interface
for business processes to be modified and manipulated (as is wont to happen
in business). The payoff is downstream. If you don't believe in that, or
your customers don't, then orchestrations will not help you.

Orchestrations compile to IL. Replacing them with components may not speed
things up if you are not extracting the complexity out before-hand.

Good luck with your project. I do wish you the best. However, in your
anger and frustration, it may not be terribly effective to blame the tools
for your project failings. (Useful, perhaps, inside your organization, to
take heat off of your project delays... but not meaningful to anyone else).

I am listening, and I am interested in your response,
-- Nick
Biztalk bum
MCSD + Biztalk
Biztalk architect for 3 years

"Unknown" <anonymous@discussions.microsoft.com> wrote in message
news:C5BE2235-AE1D-4D2E-985E-06DE17598C52@microsoft.com...
> Now it is too late, but if I had the chance to go back in time and to
change something, the first thing that I would have done is not to use
Microsoft BizTalk Server 2004 in that project.
>
> I am sorry Microsoft, but that bloody product was never designed to be
used in a real development environment.
>
> Did you ever tried to have 5 developers in 5 different computers
developing for the same BizTalk project? And I don't mean check in, check
out, I mean real time development, installation, debugging, etc.
>
> To make it harder, try to use InfoPath and BizTalk ports published as web
services for the input, output.
>
> I know, the Microsoft folks love to talk about in the web casts, but did
any of them ever used it in a real world scenario?
>
> Not to talk about the database system, why there is an SQL adapter in
BizTalk, what is it for? If I can't use it for any real world solution?
>
> And what about the speed? It is killing me, the system is designed to run
as slow as possible, the database adapter is designed to consume the CPU
speed, the orchestration and messages are designed to consume the CPU
speed, .. Etc.
>
> If I don't like it, I can buy more processors, then instead of paying 7 or
8$ for a license, I must pay 25K$ for each CPU, about 200K$ for 2 servers,
these server will be powerful as a laptop running as a server, with normal
web services (with no BizTalk).
>
> In the real tests the normal web services are running way faster than the
BizTalk web services (that if you find a way to publish them either), and
when I say faster I don't mean 1 to 3, I mean 1 to 100, or even
100000000000000000000000 :-(
>
> The web publishing wizard is broken, and publishing a complicated
orchestration require tons of scripts to make it work correctly :-(
>
> The bloody SSO service keeps losing its master secret key, and I must call
the guy in infrastructure once weekly to fix those BizTalk problems.
>
> I tried so many different installations, more than 20 in 3 month period,
and each of them had it's own unique problems.
>
> Congratulations Microsoft, BizTalk 2004, is the most broken, nonsense,
#$@%#$%#$% software you ever designed, the most complicated from a dev point
of view too, for no reason, like it could been done way simpler, and way
more easy to use.
>
> And that bloody service keeps crashing (yes the BizTalk one).
>
>
> If I can only go back in time, just 3 month back, if I can send a warning
letter to my self, I would never had used it, ever, at least until BizTalk
2010
>
> I also realized that the best way to use BizTalk is not to user BizTalk,
starting from tomorrow morning I will stop creating any new orchestrations,
I am moving to components, and when I have all the components, I will just
link them manually, and uninstall BizTalk before the project goes live.
>
> Don't understand me wrong, Microsoft VS.NET 2003 is the best development
environments, Microsoft SQL Server 2000 is the best database ever designed,
..NET and C# itself are the best development platforms ever, InfoPath 2003,
and SharePoint v2 are good but need more improvements; but Microsoft BizTalk
2004 does not deserve to use the name Microsoft in front of it.
>
>
> Don't believe me, simple, hire 5 developers, give them the software,
computers, network, and ask them to develop a software with InfoPath,
SharePoint, BizTalk, SQL Server (for data store), give them a complicate
task, not a simple one, a real world one, and record their actions for 3
months, imagine they are a dev group not from Microsoft. You will be
surprised!

Matt Milner

2004-06-05, 4:55 pm

I agree whole heartedly with you. Thanks for taking the time to post a
literate and well thought out response.

The original poster said:

> Don't believe me, simple, hire 5 developers, give them the software,
> computers, network, and ask them to develop a software with InfoPath,
> SharePoint, BizTalk, SQL Server (for data store), give them a complicate
> task, not a simple one, a real world one, and record their actions for 3
> months, imagine they are a dev group not from Microsoft. You will be
> surprised!
>

I would say that if you took a group of five developers with no experience
with several new products and put them down in front of the software with no
training, you'll likely either get crap, or get nothing out of them.
BizTalk is not the problem here. All tools can't be simple and may require
you to put forth some effort to learn them. If you are not willing to
invest time in the tools, don't be surprised when you are not able to
appropriately install and apply them to your project. If you expect that
you and your team can just sit down and start coding with tools with no
experience or training, then you are looking for software development to be
far easier than it is.

My $.02

Matt

"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:Oinwc.46613$3x.28637@attbi_s54...
> hmmm... is this advice? Complaint, perhaps, but constructive?
>
> BTS2004 is fairly stable and is being used to solve real world problems.
> It's a darn site more stable than earlier versions of BTS, although it is
> still the most difficult installation of any MS product.
>
> Perhaps the problem is that you had 5 developers working on it... Maybe
if
> you'd had one person develop the proof-of-concept, and learn the
"gotchas",
> you would have saved a lot of expense and wouldn't have a project that is
> destined for replacement.
>
> Maybe if you'd asked for help instead of assuming that you and five others
> can just "figure it out." Biztalk is +not+ the most complicated EAI tool.
> (IMHO, IBM WebSphere BI is much more complicated). But, honestly, ALL EAI
> TOOLS ARE COMPLICATED. That's the nature of the space. There are
excellent
> BTS Architects and Developers running around. If one of your five guys
was
> a Biztalk expert, you wouldn't be complaining on this newsgroup... you'd
be
> boasting.
>
> Perhaps MSFT has done a good job of taking "hard" technology and making it
> accessable. SQL Server is fairly easy to administer, compared to Oracle.
> Visual Studio comes with so many nice features, it makes development of
web
> services, and deployment of assemblies, pretty easy. But have you
confused
> the word "Microsoft" with "all software will be easy to use"? Is
Microsoft
> responsible for that confusion? (Perhaps in general, but I've seen no BTS
> marketing that pretends that "real world" projects are easy, in any tool).
>
> Biztalk is very rough around the edges. BTS2004 is like Windows 3.0...
the
> first architecture in it's family that is likely to actually succeed as a
> product. And just like Windows 3.0 was immediately followed by WFW3.11,
> Biztalk has a follow-on release that will be out in something like a year.
> With additional features, and many of the rough edges smoothed out. But
the
> model will survive, completely intact. We have a platform (finally) upon
> which to build EAI applications.
>
> As a rough-around-the-edges tool, it doesn't yet have all the features
that
> scream at you when you abuse it. It just slows down when you use
> orchestrations in a twisted way, and it just leaks memory if you call COM
> components poorly, and it just fails to work when you ask it to do things
> that it wasn't designed to do... Biztalk 2010 may do a better job of
> complaining until you change your design to use the tool better. BTS 2004
> isn't there yet. But any tool can be mis-used. How's that the fault of
the
> tool?
>
> As for replacing the orchestrations with components... sure. Go ahead.
The
> value of orchestrations comes in the ability to change them without
calling
> a team of developers. If your orchestrations can't be changed without
> massive infusions of expert help, then perhaps you +should+ recode them as
> components. On the other hand, if you've extracted out the complexities
of
> your processes into adapters and pipeline components, as Biztalk is
designed
> to let you do, then the orchestrations provide an excellent visual
interface
> for business processes to be modified and manipulated (as is wont to
happen
> in business). The payoff is downstream. If you don't believe in that, or
> your customers don't, then orchestrations will not help you.
>
> Orchestrations compile to IL. Replacing them with components may not
speed
> things up if you are not extracting the complexity out before-hand.
>
> Good luck with your project. I do wish you the best. However, in your
> anger and frustration, it may not be terribly effective to blame the tools
> for your project failings. (Useful, perhaps, inside your organization, to
> take heat off of your project delays... but not meaningful to anyone
else).
>
> I am listening, and I am interested in your response,
> -- Nick
> Biztalk bum
> MCSD + Biztalk
> Biztalk architect for 3 years
>
>
> "Unknown" <anonymous@discussions.microsoft.com> wrote in message
> news:C5BE2235-AE1D-4D2E-985E-06DE17598C52@microsoft.com...
> change something, the first thing that I would have done is not to use
> Microsoft BizTalk Server 2004 in that project.
> used in a real development environment.
> developing for the same BizTalk project? And I don't mean check in, check
> out, I mean real time development, installation, debugging, etc.
web[vbcol=seagreen]
> services for the input, output.
> any of them ever used it in a real world scenario?
> BizTalk, what is it for? If I can't use it for any real world solution?
run[vbcol=seagreen]
> as slow as possible, the database adapter is designed to consume the CPU
> speed, the orchestration and messages are designed to consume the CPU
> speed, .. Etc.
or[vbcol=seagreen]
> 8$ for a license, I must pay 25K$ for each CPU, about 200K$ for 2 servers,
> these server will be powerful as a laptop running as a server, with normal
> web services (with no BizTalk).
the[vbcol=seagreen]
> BizTalk web services (that if you find a way to publish them either), and
> when I say faster I don't mean 1 to 3, I mean 1 to 100, or even
> 100000000000000000000000 :-(
> orchestration require tons of scripts to make it work correctly :-(
call[vbcol=seagreen]
> the guy in infrastructure once weekly to fix those BizTalk problems.
> and each of them had it's own unique problems.
> #$@%#$%#$% software you ever designed, the most complicated from a dev
point
> of view too, for no reason, like it could been done way simpler, and way
> more easy to use.
warning[vbcol=seagreen]
> letter to my self, I would never had used it, ever, at least until BizTalk

> 2010
> starting from tomorrow morning I will stop creating any new
orchestrations,
> I am moving to components, and when I have all the components, I will just
> link them manually, and uninstall BizTalk before the project goes live.
> environments, Microsoft SQL Server 2000 is the best database ever
designed,
> .NET and C# itself are the best development platforms ever, InfoPath 2003,
> and SharePoint v2 are good but need more improvements; but Microsoft
BizTalk
> 2004 does not deserve to use the name Microsoft in front of it.
> computers, network, and ask them to develop a software with InfoPath,
> SharePoint, BizTalk, SQL Server (for data store), give them a complicate
> task, not a simple one, a real world one, and record their actions for 3
> months, imagine they are a dev group not from Microsoft. You will be
> surprised!
>
>

G. Tarazi

2004-06-09, 8:31 am

> BTS2004 is fairly stable and is being used to solve real world problems.

Yes, right, maybe BizTalk 2000 or 2002, and it is used to do nothing, most
of the people that I have seen used it to pick files from a folder to
another folder, and then components to process them, 2004 will not be more
different, the only adapter that really works is the file adapter :-) the
rest are broken.

I can copy files from place A to place B with a simple script!

Have you tried to the web service-publishing wizard?

Have you tried the Sql-Adapter?

Have you tried the deployment wizard (with multiple assemblies)?

Have you tried debugging? (Imaging, it happens outside VS.NET :-), come-on,
even SQL Server can be debugged inside VS.NET)

Have you tried them during development? When the orchestration changes
multiple times a day, and getting it to work requires at least half an hour?

Even and business analyst who has no development experience can change an
orchestration, total nonsense, this is true lye, and one of the biggest that
Microsoft ever told.

This is a scenario:

Imaging 6 brilliant developers in 2 teams, team "a" without BizTalk 2004,
and team "b" with BizTalk 2004, developing a small software with InfoPath,
SharePoint, and SQL Server.

Results:

Both teams will use VS.NET to create the InfoPath schemas.

Team "a": will open VS.NET, will create a simple web service to communicate
with the InfoPath document, couple of lines of code.

Team "b": will open VS.NET, will create an orchestration, and will try to
publish it as a web service (for 3 days), will try to use the SharePoint
adapter (for another week) will fail, will go back to orchestrations
published as web services (why? Because BizTalk 2004 is BizTalk 2004 beta 4)

Team "a": will create the tables in the database, will link the tables with
the web service, will publish the InfoPath form on SharePoint (for easy
access) and the job at this point is done.

Team "b": will try to use the SQL adapter, for ever, the updatagrams will be
limited, the stored procedures will not work as expected, the adapter will
not let you know what is going on, at the end team b will give up and use
the code of team a + additional code to make it work with BizTalk.

Team "a": will create an xslt to render some data on sharepoint directly
from the database.

Team "b": they are still trying to get the SharePoint adapter to work, will
give up eventually, and use the code of team "a".

Debugging:

Team "a": every one can debug instantly.

Team "b": debugging requires a separate day the debugging day.

Experience:

Team "a": regular developers.

Team "b": gods (must me no mistakes), super developers, very expensive.

Achievements:

Team "a": the project done in a week.

Team "b": the project done in a week (copy and paste from team a) + 3 month
trying to get BizTalk to work.

Then for what BizTalk is used for in team "b"? it is just there, just not to
anger the management, after spending all those money :-)

"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:Oinwc.46613$3x.28637@attbi_s54...
> hmmm... is this advice? Complaint, perhaps, but constructive?
>
> BTS2004 is fairly stable and is being used to solve real world problems.
> It's a darn site more stable than earlier versions of BTS, although it is
> still the most difficult installation of any MS product.
>
> Perhaps the problem is that you had 5 developers working on it... Maybe
if
> you'd had one person develop the proof-of-concept, and learn the
"gotchas",
> you would have saved a lot of expense and wouldn't have a project that is
> destined for replacement.
>
> Maybe if you'd asked for help instead of assuming that you and five others
> can just "figure it out." Biztalk is +not+ the most complicated EAI tool.
> (IMHO, IBM WebSphere BI is much more complicated). But, honestly, ALL EAI
> TOOLS ARE COMPLICATED. That's the nature of the space. There are
excellent
> BTS Architects and Developers running around. If one of your five guys
was
> a Biztalk expert, you wouldn't be complaining on this newsgroup... you'd
be
> boasting.
>
> Perhaps MSFT has done a good job of taking "hard" technology and making it
> accessable. SQL Server is fairly easy to administer, compared to Oracle.
> Visual Studio comes with so many nice features, it makes development of
web
> services, and deployment of assemblies, pretty easy. But have you
confused
> the word "Microsoft" with "all software will be easy to use"? Is
Microsoft
> responsible for that confusion? (Perhaps in general, but I've seen no BTS
> marketing that pretends that "real world" projects are easy, in any tool).
>
> Biztalk is very rough around the edges. BTS2004 is like Windows 3.0...
the
> first architecture in it's family that is likely to actually succeed as a
> product. And just like Windows 3.0 was immediately followed by WFW3.11,
> Biztalk has a follow-on release that will be out in something like a year.
> With additional features, and many of the rough edges smoothed out. But
the
> model will survive, completely intact. We have a platform (finally) upon
> which to build EAI applications.
>
> As a rough-around-the-edges tool, it doesn't yet have all the features
that
> scream at you when you abuse it. It just slows down when you use
> orchestrations in a twisted way, and it just leaks memory if you call COM
> components poorly, and it just fails to work when you ask it to do things
> that it wasn't designed to do... Biztalk 2010 may do a better job of
> complaining until you change your design to use the tool better. BTS 2004
> isn't there yet. But any tool can be mis-used. How's that the fault of
the
> tool?
>
> As for replacing the orchestrations with components... sure. Go ahead.
The
> value of orchestrations comes in the ability to change them without
calling
> a team of developers. If your orchestrations can't be changed without
> massive infusions of expert help, then perhaps you +should+ recode them as
> components. On the other hand, if you've extracted out the complexities
of
> your processes into adapters and pipeline components, as Biztalk is
designed
> to let you do, then the orchestrations provide an excellent visual
interface
> for business processes to be modified and manipulated (as is wont to
happen
> in business). The payoff is downstream. If you don't believe in that, or
> your customers don't, then orchestrations will not help you.
>
> Orchestrations compile to IL. Replacing them with components may not
speed
> things up if you are not extracting the complexity out before-hand.
>
> Good luck with your project. I do wish you the best. However, in your
> anger and frustration, it may not be terribly effective to blame the tools
> for your project failings. (Useful, perhaps, inside your organization, to
> take heat off of your project delays... but not meaningful to anyone
else).
>
> I am listening, and I am interested in your response,
> -- Nick
> Biztalk bum
> MCSD + Biztalk
> Biztalk architect for 3 years
>
>
> "Unknown" <anonymous@discussions.microsoft.com> wrote in message
> news:C5BE2235-AE1D-4D2E-985E-06DE17598C52@microsoft.com...
> change something, the first thing that I would have done is not to use
> Microsoft BizTalk Server 2004 in that project.
> used in a real development environment.
> developing for the same BizTalk project? And I don't mean check in, check
> out, I mean real time development, installation, debugging, etc.
web[vbcol=seagreen]
> services for the input, output.
> any of them ever used it in a real world scenario?
> BizTalk, what is it for? If I can't use it for any real world solution?
run[vbcol=seagreen]
> as slow as possible, the database adapter is designed to consume the CPU
> speed, the orchestration and messages are designed to consume the CPU
> speed, .. Etc.
or[vbcol=seagreen]
> 8$ for a license, I must pay 25K$ for each CPU, about 200K$ for 2 servers,
> these server will be powerful as a laptop running as a server, with normal
> web services (with no BizTalk).
the[vbcol=seagreen]
> BizTalk web services (that if you find a way to publish them either), and
> when I say faster I don't mean 1 to 3, I mean 1 to 100, or even
> 100000000000000000000000 :-(
> orchestration require tons of scripts to make it work correctly :-(
call[vbcol=seagreen]
> the guy in infrastructure once weekly to fix those BizTalk problems.
> and each of them had it's own unique problems.
> #$@%#$%#$% software you ever designed, the most complicated from a dev
point
> of view too, for no reason, like it could been done way simpler, and way
> more easy to use.
warning[vbcol=seagreen]
> letter to my self, I would never had used it, ever, at least until BizTalk
> 2010
> starting from tomorrow morning I will stop creating any new
orchestrations,
> I am moving to components, and when I have all the components, I will just
> link them manually, and uninstall BizTalk before the project goes live.
> environments, Microsoft SQL Server 2000 is the best database ever
designed,
> .NET and C# itself are the best development platforms ever, InfoPath 2003,
> and SharePoint v2 are good but need more improvements; but Microsoft
BizTalk
> 2004 does not deserve to use the name Microsoft in front of it.
> computers, network, and ask them to develop a software with InfoPath,
> SharePoint, BizTalk, SQL Server (for data store), give them a complicate
> task, not a simple one, a real world one, and record their actions for 3
> months, imagine they are a dev group not from Microsoft. You will be
> surprised!
>
>

Nick Malik

2004-06-09, 11:00 am

thank you for your excellent description, and your sense of humor. While
I'm sure that you have suffered at the hands of finicky tool bits, you have
expressed your discomfort in a very lively manner. You made my morning.

I don't want to argue with you. I can say that Biztalk is being used for
much more than moving files (the scenario that bears the least fruit).
Microsoft does business using some very expensive internal systems, like any
multinational corporation. Microsoft moves data between applications using
Biztalk 2004. This is not a light use. Millions of mission-critical,
dollars-on-the-line, auditors-are-watching messages, every month, through
Biztalk.

I'm not sure I understand the kind of application you are putting together.
It sounds a bit like a Human Workflow app... Am I right? Did you use
Biztalk 2004 Human Workflow Services?

Regardless, your application used a lot of technologies. They may or may
not have each been appropriate in their intended use. It sounds like your
app was supposed to be a Proof Of Concept, and that it did not succeed in
using the technology effectively. I can say, from what I can see, that it
may not have been the best or most appropriate use of Biztalk. Like using
SQL Server to store a list of images, you can use Biztalk for simple
workflow, but it isn't always easy to do, and it may not be the "right"
tool, depending on the situation.

I wish you luck. If I can help, in any way, to explain Biztalk or to help
your team pick a project that is a bit more likely to highlight the
strengths of the tool, let me know.
--- Nick

"G. Tarazi" <Tarazi (at) LiveTechnologies.ca> wrote in message
news:%23c9jL4VTEHA.1472@TK2MSFTNGP12.phx.gbl...
>
> Yes, right, maybe BizTalk 2000 or 2002, and it is used to do nothing, most
> of the people that I have seen used it to pick files from a folder to
> another folder, and then components to process them, 2004 will not be more
> different, the only adapter that really works is the file adapter :-) the
> rest are broken.
>
>
>
> I can copy files from place A to place B with a simple script!
>
>
>
> Have you tried to the web service-publishing wizard?
>
> Have you tried the Sql-Adapter?
>
> Have you tried the deployment wizard (with multiple assemblies)?
>
> Have you tried debugging? (Imaging, it happens outside VS.NET :-),
come-on,
> even SQL Server can be debugged inside VS.NET)
>
> Have you tried them during development? When the orchestration changes
> multiple times a day, and getting it to work requires at least half an
hour?
>
>
>
> Even and business analyst who has no development experience can change an
> orchestration, total nonsense, this is true lye, and one of the biggest
that
> Microsoft ever told.
>
>
>
> This is a scenario:
>
>
>
> Imaging 6 brilliant developers in 2 teams, team "a" without BizTalk 2004,
> and team "b" with BizTalk 2004, developing a small software with InfoPath,
> SharePoint, and SQL Server.
>
>
>
> Results:
>
>
>
> Both teams will use VS.NET to create the InfoPath schemas.
>
>
>
> Team "a": will open VS.NET, will create a simple web service to
communicate
> with the InfoPath document, couple of lines of code.
>
> Team "b": will open VS.NET, will create an orchestration, and will try to
> publish it as a web service (for 3 days), will try to use the SharePoint
> adapter (for another week) will fail, will go back to orchestrations
> published as web services (why? Because BizTalk 2004 is BizTalk 2004 beta
4)
>
>
>
> Team "a": will create the tables in the database, will link the tables
with
> the web service, will publish the InfoPath form on SharePoint (for easy
> access) and the job at this point is done.
>
> Team "b": will try to use the SQL adapter, for ever, the updatagrams will
be
> limited, the stored procedures will not work as expected, the adapter will
> not let you know what is going on, at the end team b will give up and use
> the code of team a + additional code to make it work with BizTalk.
>
>
>
> Team "a": will create an xslt to render some data on sharepoint directly
> from the database.
>
> Team "b": they are still trying to get the SharePoint adapter to work,
will
> give up eventually, and use the code of team "a".
>
>
>
> Debugging:
>
> Team "a": every one can debug instantly.
>
> Team "b": debugging requires a separate day the debugging day.
>
>
>
> Experience:
>
> Team "a": regular developers.
>
> Team "b": gods (must me no mistakes), super developers, very expensive.
>
>
>
> Achievements:
>
> Team "a": the project done in a week.
>
> Team "b": the project done in a week (copy and paste from team a) + 3
month
> trying to get BizTalk to work.
>
>
>
> Then for what BizTalk is used for in team "b"? it is just there, just not
to
> anger the management, after spending all those money :-)
>
>
>
> "Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
> news:Oinwc.46613$3x.28637@attbi_s54...
is[vbcol=seagreen]
> if
> "gotchas",
is[vbcol=seagreen]
others[vbcol=seagreen]
tool.[vbcol=seagreen]
EAI[vbcol=seagreen]
> excellent
> was
> be
it[vbcol=seagreen]
Oracle.[vbcol=seagreen]
> web
> confused
> Microsoft
BTS[vbcol=seagreen]
tool).[vbcol=seagreen]
> the
a[vbcol=seagreen]
year.[vbcol=seagreen]
> the
upon[vbcol=seagreen]
> that
COM[vbcol=seagreen]
things[vbcol=seagreen]
2004[vbcol=seagreen]
> the
> The
> calling
as[vbcol=seagreen]
> of
> designed
> interface
> happen
or[vbcol=seagreen]
> speed
tools[vbcol=seagreen]
to[vbcol=seagreen]
> else).
check[vbcol=seagreen]
> web
did[vbcol=seagreen]
> run
7[vbcol=seagreen]
> or
servers,[vbcol=seagreen]
normal[vbcol=seagreen]
> the
and[vbcol=seagreen]
> call
period,[vbcol=seagreen]
> point
> warning
BizTalk[vbcol=seagreen]
BizTalk,[vbcol=seagreen]
> orchestrations,
just[vbcol=seagreen]
development[vbcol=seagreen]
> designed,
2003,[vbcol=seagreen]
> BizTalk
>
>

G. Tarazi

2004-06-10, 8:00 am

Thanks for the help offer, the software that we are building is a financial
software that uses InfoPath, BizTalk, and C#.

Yesterday I disconnected the "Client Profile" form, from the 3 BizTalk
orchestrations responsible of managing it, and connected it to simple web
services, and we wrote the code necessary to process the attachments in the
form using pure C# instead of the orchestration + the sql stored procedures
of course, all that in one day (me and 2 other developers) , after
struggling for 2 weeks with BizTalk about the same thing. And it was such a
relief.

Debugging was instant, there was no need to stop and start anything
(comparing to the time of stopping and starting the orchestrations, + the
manual port mapping if the schemas changes, +....)

I am planning to disconnect the rest of the orchestrations from the InfoPath
forms soon (if my manager likes the idea); the only think that I am missing
is the maps, then I discovered that XMLSPY can help me write and debug an
XSLTs and that was it, then running the XSLT's inside C# is just 2 lines of
code. Simpleeeeeee!!!!!!!!!!

I realized what is Microsoft BizTalk 2004, is "Microsoft Data Transfer and
Modification Services (the over priced, over complicated release)", it is
not what Microsoft told us in the beginning of our project.

I thing that there is a simple release called C# and VS.NET; for example, a
file adapter that receive files in BizTalk, can be replaced by 2 lines of
code in C#, the code can go up to 100 lines to do some very advance
filtering (that I don't need in my project), and that's it, then I can use
that code any ware I want :-) and it will work exactly as I want.

The BizTalk ports can be easily replaced by C# web services (which is what I
was looking for), and they always work, even during development, and this is
a big defiance from the orchestrations, that need to be stopped, un
enlisted, deleted from the BizTalk server, deleted from the IIS, the iis
must restart, the BizTalk must restart, then the web publishing wizard must
republish them, then I must do the mappings manually if there are small
changes, than I must modify the newly created ports to finish the job not
finished by the wizard, then they must be enlisted, and then started; a set
of procedure designed to waste your time, all that + the fact that the
process may not go well, because the tools that are doing that are broken
(not developed correctly "the web publishing wizard for example"), or the
tools are not doing it the right way (try to deploy and re-deploy and
orchestration that depends on a dll file from inside VS.NET)

So paying 25,000$ USD / CPU (We have 2 servers, 4 processors in each server,
to server 300 connected users at the same time, 500 total), for a software
that will only move data from point A to point B!!!!, and process it using
an XSLT, that can be used only from a small group of elite developers (best
of the best, and they will still have problems using it, because it was
designed to be as over complicated an possible), half documented, that is
using a new language named XLANG that is unknown (instead of C# that every
one knows), works much slower than the regular code, have visible bugs that
can be seen immediately by anyone (and that means Microsoft did not invest
much in it, and not serious about it) all that sounds very stupid to me.

"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:SlFxc.4979$jw.3306@attbi_s04...
> thank you for your excellent description, and your sense of humor. While
> I'm sure that you have suffered at the hands of finicky tool bits, you
have
> expressed your discomfort in a very lively manner. You made my morning.
>
> I don't want to argue with you. I can say that Biztalk is being used for
> much more than moving files (the scenario that bears the least fruit).
> Microsoft does business using some very expensive internal systems, like
any
> multinational corporation. Microsoft moves data between applications
using
> Biztalk 2004. This is not a light use. Millions of mission-critical,
> dollars-on-the-line, auditors-are-watching messages, every month, through
> Biztalk.
>
> I'm not sure I understand the kind of application you are putting
together.
> It sounds a bit like a Human Workflow app... Am I right? Did you use
> Biztalk 2004 Human Workflow Services?
>
> Regardless, your application used a lot of technologies. They may or may
> not have each been appropriate in their intended use. It sounds like your
> app was supposed to be a Proof Of Concept, and that it did not succeed in
> using the technology effectively. I can say, from what I can see, that it
> may not have been the best or most appropriate use of Biztalk. Like using
> SQL Server to store a list of images, you can use Biztalk for simple
> workflow, but it isn't always easy to do, and it may not be the "right"
> tool, depending on the situation.
>
> I wish you luck. If I can help, in any way, to explain Biztalk or to help
> your team pick a project that is a bit more likely to highlight the
> strengths of the tool, let me know.
> --- Nick
>
>
> "G. Tarazi" <Tarazi (at) LiveTechnologies.ca> wrote in message
> news:%23c9jL4VTEHA.1472@TK2MSFTNGP12.phx.gbl...
problems.[vbcol=seagreen]
most[vbcol=seagreen]
more[vbcol=seagreen]
the[vbcol=seagreen]
> come-on,
> hour?
an[vbcol=seagreen]
> that
2004,[vbcol=seagreen]
InfoPath,[vbcol=seagreen]
> communicate
to[vbcol=seagreen]
beta[vbcol=seagreen]
> 4)
> with
will[vbcol=seagreen]
> be
will[vbcol=seagreen]
use[vbcol=seagreen]
> will
> month
not[vbcol=seagreen]
> to
problems.[vbcol=seagreen]
> is
Maybe[vbcol=seagreen]
> is
> others
> tool.
> EAI
guys[vbcol=seagreen]
you'd[vbcol=seagreen]
making[vbcol=seagreen]
> it
> Oracle.
of[vbcol=seagreen]
> BTS
> tool).
3.0...[vbcol=seagreen]
as[vbcol=seagreen]
> a
WFW3.11,[vbcol=seagreen]
> year.
But[vbcol=seagreen]
> upon
> COM
> things
> 2004
of[vbcol=seagreen]
ahead.[vbcol=seagreen]
them[vbcol=seagreen]
> as
complexities[vbcol=seagreen]
that,[vbcol=seagreen]
> or
your[vbcol=seagreen]
> tools
organization,[vbcol=seagreen]
> to
to[vbcol=seagreen]
be[vbcol=seagreen]
> check
as[vbcol=seagreen]
> did
in[vbcol=seagreen]
solution?[vbcol=seagreen]
to[vbcol=seagreen]
CPU[vbcol=seagreen]
paying[vbcol=seagreen]
> 7
> servers,
> normal
than[vbcol=seagreen]
> and
must[vbcol=seagreen]
> period,
nonsense,[vbcol=seagreen]
way[vbcol=seagreen]
> BizTalk
> BizTalk,
> just
live.[vbcol=seagreen]
> development
> 2003,
complicate[vbcol=seagreen]
3[vbcol=seagreen]
>
>

Nick Malik

2004-06-11, 5:43 pm

It looks like you've found your path to success.

I know your road was frustrating. I found BTS to be frustrating when I
first ran across it, too. It's a mental mind shift that takes a good deal
of effort to "jump in." However, where the tool shines is not really how
the solution is implemented... it's all the "other stuff" that you DON'T
have to do when you need to scale up.

In other words, your solution may be great for 100 transactions an hour, (I
assume that it is). Would it be great for 10,000 transactions per hour?
Without modifying the code? Are you sure?

That's what Biztalk buys you.

See
http://www.microsoft.com/biztalk/ev...seStudyID=15096

Good luck in your endeavors, Mr. Tarazi. If you ever do find a way to fit
BTS into your plans, and the fit is a good one, I hope you will find that
the tool is not as bad as you remember.

By the way, you never did tell me if you were using Human Workflow Services.
It's fairly clear to me that you should have been.
Anyway, good luck.

--- Nick
Biztalk Bum

"G. Tarazi" <Tarazi (at) LiveTechnologies.ca> wrote in message
news:ee$DFPuTEHA.3660@tk2msftngp13.phx.gbl...
> Thanks for the help offer, the software that we are building is a
financial
> software that uses InfoPath, BizTalk, and C#.
>
>
>
> Yesterday I disconnected the "Client Profile" form, from the 3 BizTalk
> orchestrations responsible of managing it, and connected it to simple web
> services, and we wrote the code necessary to process the attachments in
the
> form using pure C# instead of the orchestration + the sql stored
procedures
> of course, all that in one day (me and 2 other developers) , after
> struggling for 2 weeks with BizTalk about the same thing. And it was such
a
> relief.
>
>
>
> Debugging was instant, there was no need to stop and start anything
> (comparing to the time of stopping and starting the orchestrations, + the
> manual port mapping if the schemas changes, +....)
>
>
>
> I am planning to disconnect the rest of the orchestrations from the
InfoPath
> forms soon (if my manager likes the idea); the only think that I am
missing
> is the maps, then I discovered that XMLSPY can help me write and debug an
> XSLTs and that was it, then running the XSLT's inside C# is just 2 lines
of
> code. Simpleeeeeee!!!!!!!!!!
>
>
>
> I realized what is Microsoft BizTalk 2004, is "Microsoft Data Transfer and
> Modification Services (the over priced, over complicated release)", it is
> not what Microsoft told us in the beginning of our project.
>
>
>
> I thing that there is a simple release called C# and VS.NET; for example,
a
> file adapter that receive files in BizTalk, can be replaced by 2 lines of
> code in C#, the code can go up to 100 lines to do some very advance
> filtering (that I don't need in my project), and that's it, then I can use
> that code any ware I want :-) and it will work exactly as I want.
>
>
>
> The BizTalk ports can be easily replaced by C# web services (which is what
I
> was looking for), and they always work, even during development, and this
is
> a big defiance from the orchestrations, that need to be stopped, un
> enlisted, deleted from the BizTalk server, deleted from the IIS, the iis
> must restart, the BizTalk must restart, then the web publishing wizard
must
> republish them, then I must do the mappings manually if there are small
> changes, than I must modify the newly created ports to finish the job not
> finished by the wizard, then they must be enlisted, and then started; a
set
> of procedure designed to waste your time, all that + the fact that the
> process may not go well, because the tools that are doing that are broken
> (not developed correctly "the web publishing wizard for example"), or the
> tools are not doing it the right way (try to deploy and re-deploy and
> orchestration that depends on a dll file from inside VS.NET)
>
>
>
> So paying 25,000$ USD / CPU (We have 2 servers, 4 processors in each
server,
> to server 300 connected users at the same time, 500 total), for a software
> that will only move data from point A to point B!!!!, and process it using
> an XSLT, that can be used only from a small group of elite developers
(best
> of the best, and they will still have problems using it, because it was
> designed to be as over complicated an possible), half documented, that is
> using a new language named XLANG that is unknown (instead of C# that every
> one knows), works much slower than the regular code, have visible bugs
that
> can be seen immediately by anyone (and that means Microsoft did not
invest
> much in it, and not serious about it) all that sounds very stupid to me.
>
>
>
>
>
> "Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
> news:SlFxc.4979$jw.3306@attbi_s04...
While[vbcol=seagreen]
> have
for[vbcol=seagreen]
> any
> using
through[vbcol=seagreen]
> together.
may[vbcol=seagreen]
your[vbcol=seagreen]
in[vbcol=seagreen]
it[vbcol=seagreen]
using[vbcol=seagreen]
help[vbcol=seagreen]
> problems.
> most
> more
> the
> an
biggest[vbcol=seagreen]
> 2004,
> InfoPath,
> to
SharePoint[vbcol=seagreen]
> beta
easy[vbcol=seagreen]
> will
> will
> use
directly[vbcol=seagreen]
expensive.[vbcol=seagreen]
> not
> problems.
it[vbcol=seagreen]
> Maybe
that[vbcol=seagreen]
ALL[vbcol=seagreen]
> guys
> you'd
> making
> of
no[vbcol=seagreen]
> 3.0...
> as
> WFW3.11,
> But
features[vbcol=seagreen]
call[vbcol=seagreen]
BTS[vbcol=seagreen]
fault[vbcol=seagreen]
> of
> ahead.
without[vbcol=seagreen]
> them
> complexities
> that,
not[vbcol=seagreen]
> your
> organization,
> to
use[vbcol=seagreen]
to[vbcol=seagreen]
> be
> as
but[vbcol=seagreen]
> in
> solution?
> to
> CPU
CPU[vbcol=seagreen]
> paying
> than
either),[vbcol=seagreen]
> must
> nonsense,
dev[vbcol=seagreen]
> way
will[vbcol=seagreen]
> live.
software,[vbcol=seagreen]
InfoPath,[vbcol=seagreen]
> complicate
for[vbcol=seagreen]
> 3
>
>

Gil

2004-07-09, 3:31 pm

"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message news:<JCiyc.27707$HG.14654@attbi_s53>...[vbcol=seagreen]
> It looks like you've found your path to success.
>
> I know your road was frustrating. I found BTS to be frustrating when I
> first ran across it, too. It's a mental mind shift that takes a good deal
> of effort to "jump in." However, where the tool shines is not really how
> the solution is implemented... it's all the "other stuff" that you DON'T
> have to do when you need to scale up.
>
> In other words, your solution may be great for 100 transactions an hour, (I
> assume that it is). Would it be great for 10,000 transactions per hour?
> Without modifying the code? Are you sure?
>
> That's what Biztalk buys you.
>
> See
> http://www.microsoft.com/biztalk/ev...seStudyID=15096
>
> Good luck in your endeavors, Mr. Tarazi. If you ever do find a way to fit
> BTS into your plans, and the fit is a good one, I hope you will find that
> the tool is not as bad as you remember.
>
> By the way, you never did tell me if you were using Human Workflow Services.
> It's fairly clear to me that you should have been.
> Anyway, good luck.
>
> --- Nick
> Biztalk Bum
>
> "G. Tarazi" <Tarazi (at) LiveTechnologies.ca> wrote in message
> news:ee$DFPuTEHA.3660@tk2msftngp13.phx.gbl...
> financial
> the
> procedures
> a
> InfoPath
> missing
> of
> a
> I
> is
> must
> set
> server,
> (best
> that
> invest
> While
> have
> for
> any
> using
> through
> together.
> may
> your
> in
> it
> using
> help
> problems.
> most
> more
> the
> come-on,
> hour?
> an
> biggest
> that
> 2004,
> InfoPath,
> communicate
> to
> SharePoint
> beta
> 4)
> with
> easy
> will
> be
> will
> use
> directly
> will
> expensive.
> month
> not
> to
> problems.
> it
> is
> Maybe
> if
> "gotchas",
> that
> is
> others
> tool.
> ALL
> EAI
> excellent
> guys
> was
> you'd
> be
> making
> it
> Oracle.
> of
> web
> confused
> Microsoft
> no
> BTS
> tool).
> 3.0...
> the
> as
> a
> WFW3.11,
> year.
> But
> the
> upon
> features
> that
> call
> COM
> things
> BTS
> 2004
> fault
> of
> the
> ahead.
> The
> calling
> without
> them
> as
> complexities
> of
> designed
> interface
> happen
> that,
> or
> not
> speed
> your
> tools
> organization,
> to
> else).
> to
> use
> to
> be
> used in a real development environment.
> check
> as
> web
> services for the input, output.
> but
> did
> any of them ever used it in a real world scenario?
> in
> solution?
> to
> run
> CPU
> CPU
> paying
> 7
> or
> servers,
> normal
> than
> the
> either),
> and
> orchestration require tons of scripts to make it work correctly :-(
> must
> call
> the guy in infrastructure once weekly to fix those BizTalk problems.
> period,
> and each of them had it's own unique problems.
> nonsense,
> dev
> point
> way
> warning
> BizTalk
> BizTalk,
> orchestrations,
> will
> just
> live.
> development
> designed,
> 2003,
> BizTalk
> software,
> InfoPath,
> complicate
> for
> 3
This scenario plays out over and over with developers not provided any
help or guidance with Biztalk this includes the 2004 edition. They
have a hard time understanding that they don't have to code FTP, SMTP
or File "watchers" and that its built in. They don't understand that
instead of coding ton's of validation in code, they can simply declare
it in the Schema, and change it with relative ease. I put together a
Biztalk 2004 application, deployed it in production and turned it over
to a couple of developers to support. I spent several weeks working
with them, however I couldn't spend all my time. Within a month they
were rewriting the entire application in Visual Basic.
Unfortunately BTS 2004 has only been out a relativly short amount of
time and it is hard to find trainning, or even Books on it.