| Nick Malik 2004-02-08, 8:39 am |
| Biztalk is made for you.
Biztalk 2004, that is. Will be released within a few months... has been in
Beta for a long time now.
You create a "vocabulary" of messages and requests:
-- product information
-- selling price
-- purchase price
-- availability of stock in warehouse
-- purchase order (from your customer to you)
-- purchase order (from you to your supplier)
-- invoice (from your supplier to you)
-- invoice (from you to your customer)
(if you really get sophisticated, you can add it EFT messages later, to
handle the movement of cash).
etc.
You create a set of web services that you host on your web site (securely,
of course). The web services allow a customer to "ask" using your
vocabulary. The request comes with a return address (e-mail or the URL of a
response service). Biztalk receives the message and, using orchestration,
either sends the request to your local system (accounting system, warehouse
management, etc) and gets a response, or formats the request to send on to a
supplier. You have trading partner agreements with your suppliers and
either you've provided them with an application for receiving the request,
or you send EDI, or you format your request as an e-mail, or any number of
ways to forward the request. When they respond, Biztalk picks it up, formats
the response according to who asked, and sends it back to the sender using
the supplied return address.
In a fully automated system, the turnaround time could be very short (a few
seconds). However, it is likely that many interactions will have to involve
people. Not all of your customers are automated, and not all of your
suppliers are either. You can send an application to your customers that
calls the web services (very easy to write using .NET, which literally
writes the Web Service proxy code for you). You may or may not have as much
success placing an application at your supplier's location, or using their
messaging facilities, but there is always a solution.
This is not a rapid migration process, and during it, you will still have
customers and suppliers who want to do things "the old way." Nothing
changes overnight. However, you can dramatically lower the cost of
processing a request, and improve turnaround time, by rolling in this kind
of integration.
Your Access database may, eventually, fall by the wayside. In the short
term, move it's data to SQL Server and code up some very simple interface
applications in VB. I'm mostly concerned that you would start to do this,
and it would succeed, and an integration between a scalable server like
Biztalk would quickly overwhelm an office solution like Access.
If you'd like some help, drop me a line (remove the "no" "spam" components
in the following address): nickmalik.no.spam@sierrasystems.no.spam.com
--- Nick Malik
Solutions Architect
Healthcare EAI
Sierra Systems Group
"robshan" <anonymous@discussions.microsoft.com> wrote in message
news:5683696F-B3FE-4291-B95F-109E2BC33CEC@microsoft.com...
> We are a mid-sized company that manages the procurement of food and
beverage and medical products for hospitals, retirement homes and the like.
We have a large database with supplier and product infos and an ordering
program based on MS Access. We are looking for a way to automate data
communications between our db and the suppliers db's.
> At the same time we need a solution for automating the ordering process
from each customer to any number of suppliers.
> Our ordering program is an Access aplication with db installed locally on
the client's computer.
> Would BizTalk be a good all-round solution for us?
|