SAP has added generic HTTP support to its Web Application Server (WebAS). Why? HTTP is the standard protocol in...
every modern piece of software on every modern computer. That makes HTTP support essential for any software that wants to compete in today's software landscape. It's worth noting that SAP supported HTTP before, but on an operating system level, and that was called Remote Function Call (RFC). Now there is no extra step in-between: Instead of going from SAP to RFC to HTTP, it's SAP to HTTP directly.
This makes it easier to seamlessly integrate your system with modern IT infrastructures without dealing with proprietary protocols. From a strategic point of view, SAP's HTTP support makes WebAS a serious contender as a development framework versus Microsoft's .NET and Sun's J2EE.Why should you license SAP XI when SAP R/3 Enterprise already has built-in XML functionality?
SAP XI is primarily message middleware software. Think of it as a sophisticated and powerful workflow management tool that makes use of XML, while the built-in XML functionality of R/3 Enterprise is a light version of the fire-and-forget variety. Comparatively speaking, R/3 workflow is a wooden carriage while SAP XI is a professional-grade truck. SAP XI is a full messaging application that acts as a broker between a sender and a receiver that controls and assures message delivery and triggers events.
Keep in mind that SAP XI replaced the old Business Connector, which was a PC tool running on a Windows server. SAP XI, on the other hand, was written completely in ABAP and uses SAP's own WebAS platform. Basically, it is one of the hundreds of competing middleware products, fitting in alongside players like WebSphere, BizTalk, Mercator and so forth. This makes SAP XI attractive to SAP-focused companies with lots of SAP products, as they can leverage the existing SAP know-how instead of integrating and learning something new. How do you determine which technology to use for any given transaction?
There are a few questions you have to ask in order to determine that. First off, do you need a protocol for your transaction? That's a pointer to IDocs. The second question to ask is, 'Who's going to handle the errors?' If problems are going to be dealt with by the sending system, BAPIs are sufficient. If something goes awry, the sending party will immediately know that something has failed and the problem is bounced right back. This helps keep overhead low since you don't need to worry about data storage, protocols and related issues. On the other hand, if problems are the responsibility of the receiving party and the data isn't properly received, IDocs is the way to go since the data is stored in a data storage and can be dealt with in there. I heard about a new EDI-converter written completely in ABAP. Do you have any comments about that?
Until now, EDI converters were standalone adapters with no connection to SAP. As an SAP user, this could be bothersome when exchanging information with all your vendors and clients who have different platforms. However, by integrating everything in a single package on SAP, you get just one type of environment that needs employees with only that one skill set. I have seen a lot of demand for this type of converter, so I believe it will be well received. The converter is made by Axantis and you can get information in English here.
That said, I want to remind you that a converter is only half of the EDI equation. The other half is to have clear knowledge about how the data is exchanged with each specific partner. There is no one-size-fits-all answer. All partners have their own set requirements and need minor adaptations of the conversion rules.SearchSAP.com gets a lot of user questions about BAPIs and IDocs. Could you explain the difference between the two technologies?
A BAPI exchanges information with R/3 in a similar way to IDocs, but the BAPI can call a program directly in the call system. IDocs, on the other hand, communicates asynchronously and stores the data it receives before it can process the data. This means you get an established protocol for exchanging data between R/3 and an external system, while BAPIs can't write a protocol unless the application itself does.