By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

and WAS. Click here to read Austin's response. Chris Whealy, Principal Consultant at SAP(UK) Ltd., would like to clarify the issue. Here is his take on the matter: The question was to describe the main differences between SAP's ITS technology and the new Web AS 6.20. Mr. Sincock opened his article by saying that there is much confusion about the differences between these two products, but then unfortunately, he proceeded to only add to the confusion. Allow me to set the record straight. I have been an employee of SAP(UK) since May 1995 and have worked extensively with the ITS since its first beta release in August 1996. I have also have worked with the quality control team in Walldorf on pre-release testing of Web AS 6.20. The ITS was originally released as a mechanism for bridging the gap between the HTTP based world of the World Wide Web, and the proprietary DIAG world of SAPGUI. Therefore, the ITS was written to act as a protocol translation layer between the webserver and the R/3 system. The Websever receives an HTTP request, and via a server plugin (the WGATE), this request is rerouted to the AGATE. The AGATE then invokes the specified service that typically starts a dynpro based transaction in R/3. Mr Sincock misleadingly stated that the ITS would only run this type of transaction. However, from its earliest releases, the ITS has been able to call *any* RFC-enabled function module - BAPI or otherwise. If the ITS is instructed to execute a transaction, then R/3 and the ITS will communicate with each other by means of the proprietary SAPGUI protocol known as DIAG (Dynamic Interactive Application Gateway). This is well understood, and needs little further explanation. However the ITS can also use RFC calls to invoke R/3 functionality. Under these circumstances, you are not limited to calling only BAPI's, but you can call *any* function module that has the "RFC enabled" flag set in its attributes. I have written numerous web interfaces for customers in which I have had to write custom RFC function modules. These have typically been wrappers for BAPI's in order to add extra functionality not found in the standard BAPI. As of release 4.5 of the ITS, ITS flow logic was added. This enabled the flow of business logic to be defined in the ITS rather than in R/3, and by means of BAPI/RFC function module calls, different units of business functionality were invoked within R/3, based on the flow logic defined in the ITS. This functional addition to the ITS greatly speeded up the development of Web enabled applications, however, there were still the issues of version control and change management that were not satisfactorily addressed. The Web App Server project has been running within SAP since July 1998. Originally, the project was given the code name Oxygen (which soon after changed to RoadRunner), and the goal of the development team was to produce a C++ based, XML parser that was fully integrated into the R/3 kernel. This would ultimately provide OO ABAP programs the means to subscribe to events triggered by incoming XML documents. The RoadRunner interface (known as iXML) went live internally within SAP in March 1999, and was used originally by other kernel developers as a built in XML parser. This parser acts as the technical foundation upon which the prototype Web App Server was built. An HTTP engine (ICMAN) was added to the R/3 kernel as a separate process, and an ABAP control framework added within the Basis layer in order to process HTML based HTTP requests. This control framework now acts as the environment within which Business Server Pages exist. The ICMAN process acts also as the gateway to SAP's J2EE engine (formerly known as InQMy), and by means of shared memory areas, Java and ABAP based applications can exchange information. This is also the mechanism by which Fast RFC works. If a customer has a highly specific HTTP requirement that the standard HTML control framework does not handle correctly, it is perfectly possible for the customer to write their own. This would then allow the customer to develop their own set of tag extensions similar to the HTMLB library that SAP ships as standard. In summary, the ITS is a protocol translation layer that providied an initial bridge between the HTTP world of the World Wide Web, and the proprietary world of SAP. The Web App Server, on the other hand, is the natural evolution of the R/3 kernel to the point where a webserver and ITS are no longer needed. The R/3 kernel can communicate directly with the internet (SMTP is supported as well as HTTP), thus simplifying the customers hardware landscape by a rationalisation of core functionality. The ITS will be fully supported for the foreseeable future, though in time, its use will diminish through natural migration to Web App Server. SAP is now using the Web App Server as the platform for all future web based applications - CRM 3.0 being the earliest visible example. The ultimate aim of the Web App Server is to be able to execute ITS HTML Business templates and their corresponding flow and servce files directly. The initial release of this functionality is planned for 6.30, but as with any piece of new functionality, the delivered offering will take further time to become fully operational. I hope this has removed any confusion that existed regarding the differences between these two products.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy