Skip to Content

* *

SAP
products viz. Business Intelligence (SAP BW), Customer Relationship Management
(SAP CRM), Supplier Relationship Management (SAP SRM), Business Objects (SAP BO),
SAP Portal (ESS/MSS) and others were either already web based or later made web
enabled. Many times, ECC customers are faced with a common question – How to
access SAP anytime anywhere from a browser, without installing anything on the
workstation?  ITS, BSP, Webdynpros, Web
service etc are some of the options SAP Netweaver provides as a development
technology and runtime environment for SAP applications, either standard or
custom, so that they can be accessed via a browser.

 

In this
blog, I provide the basic understanding on the various options available for
web enabling SAP i.e. how to work in SAP using a browser, instead of
conventional SAPGUI. The contents of this blog are based upon my understanding
and experience, and are written keeping in mind web enabling the classic R/3
package of SAP, better known as SAP ECC.

 

Options for
web enabling are:

—-


1. ITS – Internet Transaction Server

2. BSP – Business Server Pages

3. ABAP Webdynpro

4. Java Webdynpro

*5. ASP/JSP/.NET /Pearl/Other Web development
technology*

6. Creating a web service inside SAP

—-


 

Let us
briefly try to understand the six options:

 

—-


1. ITS:

—-


</p>


<p> </p>


<ul>
<li>Internet Transaction Server (ITS) is a standard
     feature available in SAP ECC where we can login to SAP using a browser,
     instead of SAPGUI. The look and feel of the screens is almost the same as
     in SAPGUI, the only difference is that the screen contents are visible in
     a browser. There is no additional development required for this. There are
     few basis settings to be done in transaction SICF which will enable this
     functionality.</li>
</ul>


<p> </p>


<ul>
<li>*<Pros>
     *</li>
<li>No additional development is required. Almost all
     standard transactions and reports can be displayed in a browser.</li>
</ul>


<p> </p>


<ul>
<li><Cons>

    • The look of the screens is same as SAPGUI,
      however the feel is different; the ease of operations is more in SAPGUI as
      compared to working in the browser.

 

 

—-


2. BSP:

—-


</p>


<ul>
<li>Just like one can develop web pages in ASP, JSP,
     .NET etc, similarly SAP has provided its own technology called Business Server
     Pages (BSP). This technology is already contained in standard ECC server.
     We can develop web pages containing HTML tags and ABAP syntax inside it,
     much similar to the server page technology. These pages can be then
     accessed using a browser. However for standard transactions like creating
     purchase order, creating goods receipt, posting FI document etc, there are
     no standard BSPs available. Hence new BSP pages need to be developed for
     those transactions and any business functionality which is required to be
     web enabled. We can develop BSP using transaction code SE80. </li>
</ul>


<p>* *</p>


<ul>
<li>*<Pros>
     *</li>
<li>BSP is very much similar to the conventional
     server page technology, so anybody familiar with little ABAP and
     HTML/ASP/JSP can quickly develop BSP applications.</li>
<li>As compared to screens rendered via ITS, BSP
     screen elements are more user friendly and have the standard web look and
     feel.</li>
<li>It is light weight and consumes less network
     bandwidth as compared to ITS technology.</li>
</ul>


<p> </p>


<ul>
<li><Cons>

    1. There are no BSP pages/applications available for
      SAP standard functionality. So, additional development and testing efforts
      are required for each functionality we require to web enable.

 

—-


3. ABAP Webdynpro:

—-


</p>


<p> </p>


<ul>
<li>This is SAP’s proprietary technology and is
     contained in standard ECC server. Applications and web pages can be built
     using ABAP webdynpro. It is based on MVC framework (Model View
     Controller). We can develop ABAP Webdynpros using transaction code SE80.
     We can use standard ABAP syntax inside the logic of webdynpro. As compared
     to screens rendered via ITS, Abap Webdynpro screen elements are more user
     friendly and have the standard web look and feel. Except for standard
     SAPGUI, no separate installation is required on front-end for development.
     * *</li>
</ul>


<p>* *</p>


<ul>
<li>*<Pros>
     *</li>
<li>Since ABAP Webdynpro is MVC based, they are more
     preferred and recommended over BSP.</li>
</ul>


<p> </p>


<ul>
<li><Cons>

    1. There are no standard ABAP Webdynpros available
      for SAP standard functionality. So, additional development and testing
      efforts are required for each functionality we require to web enable.
    2. Comparatively BSPs are light weight when it comes
      to network traffic and performance.

 

—-


4. Java Webdynpro:

—-


</p>


<p> </p>


<ul>
<li>This is the JAVA flavor of the MVC based
     webdynpro technology. For this there are two things which are a must. The
     SAP server should have JAVA stack and the front-end workstation should have
     installation of NWDS (Netweaver Developer Studio) for development
     purpose.  Compared to ABAP
     webydnpro, we cannot use any abap coding inside java webdynpro. It means
     that we cannot fetch data from a database table using a simple select
     query. So we need to use / create a function module in SAP which is RFC
     enabled. So for every small functionality which may involve either getting
     information from SAP tables or storing some information in SAP tables, we
     need to have a RFC enabled function module, either standard of a custom
     developed. For calling this function module from Java we need to write
     special syntax. Another option is using web service. We can use / create a
     web service in ECC (web service wrapper over RFC enabled function module)
     and the web service can be called from Java webdynpro. Calling a web
     service has different syntax in Java. Here again additional development
     efforts are required for any functionality which we need to web enable.</li>
</ul>


<p>* *</p>


<ul>
<li>*<Pros>
     *</li>
<li>This technology is Java based, and hence the
     preferred choice of many.</li>
<li>Webdynpro for Java is a better choice as compared
     to Abap Webdynpro when it comes to robust and scalable applications.</li>
</ul>


<p> </p>


<ul>
<li><Cons>

    1. Compared to BSP and Abap Webdynpro, separate
      installation of NWDS is required on the front-end to develop JAVA
      Webdynpro.
    2. Since we cannot use ABAP syntax/logic inside the
      Java Webdynpro, we necessarily have to create or use a RFC enabled
      function module in SAP, and call it from inside the Java Webdynpro. Hence
      this adds to the development efforts.
    3. The Java team and ABAP team need to fix on the
      design/interface/RFCs and may need to frequently co-ordinate in case there
      are any changes.
    4. Promote to Production is integrated with SAP’s
      transport management system in case of BSP and ABAP Webdynpro. However for
      JAVA Webdynpro a separate installation and setup of NWDI (Netweaver
      Development Infrastructure) is required.
    5. There are no standard JAVA Webdynpro applications
      available, hence development efforts are required for any standard
      functionality which we require to web enable.

 

—-


*5. ASP/JSP/.NET /Pearl/Other Web development
technology*

—-


</p>


<ul>
<li>We also have the option of using ASP/JSP and
     other web development technology. However in such cases efforts are
     required on both the sides i.e. Non-SAP and SAP. If we are developing a
     web page in ASP, then the screen elements would be developed in ASP but
     the actual functionality of getting data from SAP or saving data in SAP
     needs to be developed inside SAP in the form of RFC enabled function
     module or a web service. This function module or web service would then be
     called from inside the ASP page.</li>
</ul>


<p>* *</p>


<ul>
<li>*<Pros>
     *</li>
<li>In terms of performance, technologies viz.
     ASP/JSP/Pearl are faster and consume less network bandwidth.</li>
<li>Skillset for these technologies is comparatively
     easily available hence the cost of development is also lowered.</li>
<li>The look and feel of the web screens is more
     simpler, light weight and user friendly, as compared to the sophisticated
     screen elements of ABAP and Java Webdynpro.</li>
</ul>


<p> </p>


<ul>
<li><Cons>

    1. Since we cannot use ABAP syntax/logic inside the
      Java Webdynpro, we necessarily have to create or use a RFC enabled
      function module in SAP, and call it from inside the Java Webdynpro. Hence
      this adds to the development efforts.
    2. The ASP/JSP team and ABAP team need to fix on the
      design/interface/RFCs and may need to frequently co-ordinate in case there
      are any changes.
    3. Promote to Production for the front-end i.e.
      ASP/JSP is not integrated with SAP, and hence needs to be separately taken
      care of, in synchronization with the transport of ABAP objects.

 

—-


6. Creating a web service inside SAP:

—-


</p>


<p> </p>


<ul>
<li>The last option is where there is no user screen
     but some legacy application needs to connect to SAP and get some
     information e.g. Accounts Payable – List of Invoices due for payment. In
     such cases we can use/develop a web service inside SAP so that the legacy
     application can call this web service and get the required information. </li>
</ul>


<p>* *</p>


<ul>
<li>*<Pros>
     *</li>
<li>This is the de-facto standard for interfacing
     technology over the web.</li>
<li>The connecting application can be built on any
     technology – .Net/Java/etc. Since the interfacing is via a Web Service,
     the technology does not matter.</li>
</ul>


<p> </p>


<p>* *</p>


<p>So far we
have discussed in brief all the available six choices. Knowing all this a
question comes to our mind – which option should be used? Well this depends
upon the requirement. In my next blog we would consider a practical scenario
and evaluate the pros and cons of the above six options and be able to come to
a conclusion. Thanks in advance.</p>


<p>* *</p>


<p> </p>


<p>Regards,</p>


<p>Amit
Mittal.</p>

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

    1. Gregory Misiorek
      what’s wrong with ITS? it may not generate additional licensing revenue to SAP, but some customers may want to use it for limited functionality to increase their ECC user base, even beyond 2011. are there plans to discontinue webgui support?
      (0) 
      1. Michael Nicholls
        I think you’re confusing ITS the technology with webgui the ICF application.

        ITS is the original web enablement technology that SAP provided, based on the WGate/AGate applications and a proprietary markup language.

        There was one well known ITS application that has been very neatly ported to the ICF framework. That is webgui. I personally expect it to be around for many years, but I’d very very surprised if someone decided to write a new ITS application from scratch nowadays.

        (0) 
        1. Gregory Misiorek
          i don’t know what the original author meant as he didn’t mention WGate/AGate anywhere, but this is the ITS i was referring to:

          ..sap/bc/gui/sap/its/webgui..

          and i’m glad to hear that it’s going to be here for the years to come, but you never know how far back into the past developers want to go to write applications. c is not the latest technology around, but some may not want to try any other language.

          (0) 

Leave a Reply