|
Home > Archive > BizTalk Server General > February 2004 > BizTalk Capability Question?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BizTalk Capability Question?
|
|
|
| Dear All,
We have started to review BizTalk with a view to implementing it within our
business as an "off the shelf" replacement for our current system, which I
have described below. I know (by reading the basic information on the MS
website) that in the main BizTalk has most of the capability that I will
require, but I need to consider the true pros/cons of where we are going to
have difficulty.
I came here, because I am sure that there are people here that may be able
to offer me the information I need, with a few minutes deliberation, which
is considerably quicker than I can achieve, but trial and error, so here
goes...
The main functions within the business is the movement and manipulation of
data files, which constitute the content of books and magazines and as such
there are many thousands of files travelling around our company. We need to
be able to trace the location files accurately and need to know at what
stage they are within the business.
We have two offices, one in the UK and one in India, so the ideal solution
would see both offices as one, but we could implement a duplicate soltion in
each office. We currently have a bespoke automation system which consists of
many stand alone VB programs. Each program has a single function and is
assigned a pair of I/O folder in which we store an XML configuration file,
thereby allowing us to plug together a set of applications chaining the I/O
folders into a complete process.
Individual applications perform routine tasks like collection data from FTP
sites, ZIPping data, sending FTP, sending Emails, passing data to/from SQL.
An example would be where our customer places a document on their FTP site.
One application will collect this and store it in our business; another will
unZIP it; another will record an entry for it in SQL (assigning a job
reference); another will collate check for the presence of certain files,
post them to a watched folder; another ZIPs the set of files; another FTP's
them out to our Indian office and finally another would send an email to
confirm delivery to India. All along this process we would be entering data
into SQL to keep a track of when a process is started and completed, so that
we can (at any time) enter a job reference number and find out exactly where
in the process a job is.
Thinking forward we need to be able to confgure any single process (change
an FTP site, for example) ro to build a completely new chain of processes.
Please bear in mind that part of the consideration we will making is that if
we were to opt for a bespoke system that we write, we'd gain (through the
developers) experience of the best practices, whereas with BizTalk we have
very minimal knowledge of how it works. A good example is that it took me
several days just to install BizTalk and MSMQ in a manner where I could
(from my development PC) get anything to work, at all.
Hopefully, I have given enough information, but not in so as to cause too
much confusion. Thank you very much in advance for anything you may be able
to offer.
Regards
Sean
| |
| Nick Malik 2004-02-11, 3:37 pm |
| Hi Sean,
Biztalk is a better system, and a more robust one, and probably a more
expensive one, and it could take longer to implement given your team's known
expertise. It is a better solution in the long run, but you have to decide
if you have the patience to implement it.
1) Training is essential. No one (and I mean, literally, no one that I
know) picks up Biztalk from a book. Your developers will need to know .NET
(VB.NET or C#). Experience with another EAI tool would be helpful.
Unfortunately, training right now is light since it is only available for
BTS2002 (see below). BTS2004 training has not been released yet. I do not
know if MSFT has announced a date for availability of training.
2) Biztalk will help you to coordinate much more than a single flow of
information as you describe below. I'm assuming that you were just giving
an example. Biztalk can handle are large number of data paths.
3) Through the use of orchestration, Biztalk will allow you use a component
model that is essentially similar to the system you describe, only it will
do it with much higher speed and reliability. In other words, you place a
component in Biztalk to detect the file in your customer's FTP site, and
Biztalk runs through the workflow, quickly calling each component, to unzip,
record, zip, and transmit (in this example). You can also map, translate,
and interpret.
4) I'm glad you got Biztalk 2002 installed. Congrats. Now, erase it.
Install Biztalk 2004 (available as a beta). It is far superior, has a more
resilient model, a lower memory footprint, and is completely integrated with
..NET (unlike Biztalk 2002 which is based on COM). BTS2004 will be released
to market soon. Once it goes RTM, the beta will be pulled back and you
won't be able to install anything except the released version, and only when
it is available. This "dark" period could last a month or two (shorter if
you have MSDN Enterprise). So don't delay.
Hope this helps,
--- Nick Malik
Biztalk Bum
"SA" <reply@group.com> wrote in message
news:4028f866$0$7060$ed9e5944@reading.news.pipex.net...
> Dear All,
>
> We have started to review BizTalk with a view to implementing it within
our
> business as an "off the shelf" replacement for our current system, which I
> have described below. I know (by reading the basic information on the MS
> website) that in the main BizTalk has most of the capability that I will
> require, but I need to consider the true pros/cons of where we are going
to
> have difficulty.
>
> I came here, because I am sure that there are people here that may be able
> to offer me the information I need, with a few minutes deliberation, which
> is considerably quicker than I can achieve, but trial and error, so here
> goes...
>
> The main functions within the business is the movement and manipulation of
> data files, which constitute the content of books and magazines and as
such
> there are many thousands of files travelling around our company. We need
to
> be able to trace the location files accurately and need to know at what
> stage they are within the business.
>
> We have two offices, one in the UK and one in India, so the ideal solution
> would see both offices as one, but we could implement a duplicate soltion
in
> each office. We currently have a bespoke automation system which consists
of
> many stand alone VB programs. Each program has a single function and is
> assigned a pair of I/O folder in which we store an XML configuration file,
> thereby allowing us to plug together a set of applications chaining the
I/O
> folders into a complete process.
>
> Individual applications perform routine tasks like collection data from
FTP
> sites, ZIPping data, sending FTP, sending Emails, passing data to/from
SQL.
> An example would be where our customer places a document on their FTP
site.
> One application will collect this and store it in our business; another
will
> unZIP it; another will record an entry for it in SQL (assigning a job
> reference); another will collate check for the presence of certain files,
> post them to a watched folder; another ZIPs the set of files; another
FTP's
> them out to our Indian office and finally another would send an email to
> confirm delivery to India. All along this process we would be entering
data
> into SQL to keep a track of when a process is started and completed, so
that
> we can (at any time) enter a job reference number and find out exactly
where
> in the process a job is.
>
> Thinking forward we need to be able to confgure any single process (change
> an FTP site, for example) ro to build a completely new chain of processes.
>
> Please bear in mind that part of the consideration we will making is that
if
> we were to opt for a bespoke system that we write, we'd gain (through the
> developers) experience of the best practices, whereas with BizTalk we have
> very minimal knowledge of how it works. A good example is that it took me
> several days just to install BizTalk and MSMQ in a manner where I could
> (from my development PC) get anything to work, at all.
>
> Hopefully, I have given enough information, but not in so as to cause too
> much confusion. Thank you very much in advance for anything you may be
able
> to offer.
>
> Regards
>
> Sean
>
>
| |
|
| Nick,
Thank you very much for your contribution to my question, all sounds very
good (thankfully much is the same as my own thoughts) but you've certainly
thrown in a few new things for me to consider.
Sean
|
|
|
|
|