“…assuming that you want interactive order functionality, not batch processing…”
This implies that the webMethods platform is geared toward batch processing rather than real-time or near real-time processing. I think many here will attest that quite the opposite is true.
Integration brokers in general are designed to move data as soon as possible. Generally speaking, they don’t handle batch processing very well.
The reason for using an integration broker (of any kind, not just wM) is to reduce the number of point-to-point interfaces, provide a layer of abstraction (and hence flexibility), provide a consistent integration approach and enourage reuse of interfaces.
I’m sure wM and SAP have several case studies available. The SAP Business Connector (BC) is wM Integration Server under the covers.
John: Here’s a high-level overview of how wM could be used for the 3 tasks you describe.
-
webMethods Integration Server is a service-based tool. It exposes services that can be easily invoked over http, ftp and other mechanisms. All wM IS services can be invoked as web services. So your web-based customers/partners can use virtually any tool to invoke the services you expose.
-
wM IS has a variety of adapters. These adapters provide the connectivity to resource they are designed for. As Sreekanth pointed out, the SAP adapter provides connectivity and mapping facilities to interact with SAP via RFC and BAPI.
-
You’ll hook up the services you expose, and the document formats you choose to expose, to the services you configure to connect to SAP.
The amount of programming you’ll need to do, using FLOW and possibly a small bit of Java, is fairly minimal and will consists primarily of controlling document flow and performing mapping as required.
HTH
#webMethods#Adapters-and-E-Standards#Integration-Server-and-ESB