Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : SAP A.G. -- Ignore unavailable to you. Want to Upgrade?

To: bigredfreak who wrote (2861)	12/22/1998 3:40:00 PM
From: Lizzie Tudor	Read Replies (3) \| Respond to of 3424

Thank you bigredfreak! What a great article... I have needed to be able to refer people to something like that for a long time. Im going to bookmark the page. Typically, current tools extract data directly from the physical database management system (DBMS). As such they bypass the R/3 application layer, which contains valuable information. In so doing there is a real risk that not all the information contained in R/3 is extracted to the data warehouse. That really says it all. Just to reiterate though I dont think these technical issues are really relevant to Sap stock at this point. Michelle

To: bigredfreak who wrote (2861)	12/22/1998 11:13:00 PM
From: jon iliz	Respond to of 3424

Hi ya bigred, I also thank you for that article. My comments: Michelle was trying to point out how products could not be integrated next to an R/3 system without having to use the R/3 ABAP programming layer. The article tells that this is exactly what IBM is doing. Yes, the article does support some of Michelle's arguments about integration complexity, but as they state, many of those biggest headaches went away after R/3 version 3.0D with an expanded ALE capability. At the same time some of those issues still remain, but the bottom line is its workable. Here is the excerpt supporting my argument against Michelle's main concern: Application integration with middleware Speaking of other applications, our approach of using Mercator and Rendezvous can also be \used to integrate different applications. For example, you could put a Human Resources (HR) system onto the network. Suppose you need Accounts Payable data (which is found in your financial applications) but you also need to access HR data to know who you are paying. You might set up a process flow where — when the R/3 system is ready to pay a certain employee for so many hours — your process will access the HR system in order to find out the employee's name/details and send that name back to R/3. This is possible by publishing information to a subject name and, because you have created business objects, you subscribe to them. . . The beauty of our architecture is that you can set up a system using middleware. With tools like Mercator, Rendezvous and MQSeries you can both transform and transport data ‘on the fly'. . . The IBM experience indicates that multiple concepts appear to work well together. Moreover, the ‘products' involved — ALE IDocs, Rendezvous, Mercator and MQSeries — already fit well together in the IBM implementation, although (given the early state of this project) only time will prove the ultimate effectiveness. At the same time, Mr. Slater conceptually separates the ‘offloading' of data and events from their ‘dissemination'. His argument — that once the business event data can be found, users will find more and more ways to exploit it — seems wholly plausible. Now I am not trying to hide the fact that R/3 is complex to figure out. It sure is and I will write that 100 times on the black board if you want me to. But at the same time it is the most powerful system a company can get their hands on. I also admit it may cost an awful lot to tweak it the way you want it. But the companies doing this know the cost/return benefits and elect to go about it. A major selling point it is since other vendors cant come as close to implementing the same kinds of things. J