Definition
Web Dynpro is the SAP NetWeaver programming model for user interfaces and provides support when developing the Web representation of business applications. The Web Dynpro model is based on the Model View Controller paradigm, and has the following features that build on the classic dynpro model:
· Clear separation of business logic and display logic
· Uniform metamodel for all types of user interfaces
· Execution on a number of client platforms.
· Extensive platform independence of interfaces
Structure
In Web Dynpro, each user interface is always made up of the same basic elements (such as UI elements or events triggered by the user). These basic elements are declared using Web Dynpro tools. The event handling is programmed in separate source code areas, which are executed automatically at runtime when the event is triggered.
Metamodel Concept
When creating a Web Dynpro application, you use the Web Dynpro tools to describe the properties and functions of the application. The data created in this way is stored in tables as metadata. At a later time, the necessary source code, which is executed at runtime, is created from this metadata. Therefore, the metadata itself is independent of the rendering technique used at runtime.
Graphical Development Tools
To support this declarative concept, the SAP NetWeaver Developer Studio contains a range of Web Dynpro tools. You can therefore generate a large proportion of a Web Dynpro application using the tools provided, without having to create your own source code. This applies to the following parts of the application:
· Data flow between the front end and back end
· Layout of the user interface
· Properties of user interface elements.
The Web Dynpro tools enable you to create source text areas manually within generated source texts. These areas are not changed if the source code is regenerated.
Separation of Business Logic and Display LogicWeb Dynpro enables you to clearly separate business logic and display logic. A Web Dynpro application runs on the front end and has local or remote access to the back end system via a service. This means that the display logic is contained in the Web Dynpro application, while the business logic and the persistence of the business objects run in the back end system.
The following options are currently available for connecting Web Dynpro applications and the back end system:
· An interface generated using adaptive RFC, through which BAPIs of an SAP system can be called
· An interface for calling Web services.
· A self-generated interface
The source code required for connecting the Web Dynpro application can be generated from a UML definition of the Web Dynpro interface. A UML definition can be imported into the Web Dynpro tools as an XML file.
Implementation of the Model View Controller Paradigm
Every Web Dynpro application is structured according to the Model View Controller paradigm:
· The model forms the interface to the back end system and thus enables the
· Web Dynpro application access to data.
· The view is responsible for the representation of the data in the browser.
· The controller lies between the view and the model. The controller formats the model data to be displayed in the view, processes the user entries made by the user, and returns them to the model.
Web Dynpro Application
A Web Dynpro application is an application that can be called from the user interface. As an independent program unit it connects a URL that can be accessed by the user with a window in the Web Dynpro component.
The Web Dynpro application is merely linked to an interface view of a Web Dynpro window by an inbound plug. It therefore contains no information whatsoever about the elements of the corresponding component or components behind the interface view.
Web Dynpro Component
The creation of applications using Web Dynpro is structured in Web Dynpro components
Definition
A Web Dynpro component is a reusable entity. It summarizes all components that are required as part of this programming unit for an executable Web Dynpro application.
The Web Dynpro component concept offers a number of advantages:
Structuring of the programming
Creation of easily manageable application blocks
Reusability of whole components
Decoupling of software projects in both time and space.
The creation of a Web Dynpro component is always mandatory, since the existence of the Web Dynpro window and the views and controllers that it contains is linked to the existence of the component itself. Communication between the elements of two Web Dynpro components and their call by a user is implemented using the component interfaces, so it does not make sense to consider the individual parts of the component separately.
A Web Dynpro component can embed other Web Dynpro components, and correspondingly a Web Dynpro component can be embedded in any other Web Dynpro components. This communication also takes place over the component interfaces.
Lifetime of a Web Dynpro Component
A Web Dynpro component’s lifetime begins the first time it is called at runtime, and ends with the lifetime of the Web Dynpro application that called and thereby instantiated the component.
For embedded components this means that during the lifetime of the embedded component, they are not instantiated until the moment when they are required. Their lifetime ends, however, at the same time as the embedded component when the Web Dynpro application that was originally called is ended.
It is also possible for the embedding component to create or destroy the embedded component using an appropriate API and thus control its lifetime.
Interfaces of Web Dynpro Components
Each component has an interface in order to enable communication between Web Dynpro components and to enable a component to be called up by a user.
This interface consists of two parts:
1. Interface View of a Window Contained in a Component
2. Interface Controller of a Component.
Interface View of a Window Contained in a Component
The interface view of a Web Dynpro window is used to link a window with a Web Dynpro application that can be called by the user.
An embedded component can also be integrated in one of the windows of the embedded component using inbound and outbound plugs. The window of the embedded component can behave like a view with regard to navigation
The window of the inner component does not have to have graphical elements. It can also be available for the functions contained in your component controller or for contexts for the embedding component.
Interface Controller of a Component
As well as the visual part, the interface of a Web Dynpro component also has a programmatic part, the interface controller. This is visible inside and outside of the component, and performs the program side of the exchange of business data. An embedding component can also call an embedded component using this controller.
An additional option for data exchange between the embedding and embedded component is cross-component context mapping.
The interface of a Web Dynpro component can also be defined independently without implementation. It is therefore possible to separate the development of the Web Dynpro component and the development of one use of the Web Dynpro component. You can also create multiple interface implementations for a Web Dynpro component. For each interface, the required implementation is not selected until runtime. The interface and implementation are linked by the same name.
The Web Dynpro component contains any number of
Windows
Views
Controllers
Window
DefinitionA window groups together multiple views and view sets. A view can only be displayed by the browser if it has been embedded in a window. A window always contains one or more views, which are connected by navigation links. One of these views, or a view set, is specified as the start view and is displayed the first time the window is called.
Interface View
Each window has a uniquely assigned interface view. This interface view represents the outward view of the window. The interface view is linked with a Web Dynpro application so that the window can be called using a URL.
The interface view enables windows to be reused by multiple components .
This means that in addition to all component-specific views, the interface views of windows of all components that are known by the current component (that is, for which a component use has been created) can be embedded in a window. Just like the view, the interface view has inbound plugs and outbound plugs and can be integrated in navigation structure of another window using these plugs.
Each view can be displayed only once in the current window at the same time; this also applies to an interface view of a used component. It is possible, however, to declare several uses for one and the same component. In this way, you can display an interface view multiple times.
View
Definition
A view describes the layout and behavior of a rectangular area of a user interface.
Use
Every Web Dynpro application has at least one view. The layout of a view is made up of different user interface elements, which can be nested in each other. The positioning of interface elements in one view is supported by the supplied layout variants.
In addition to the visible part, the layout, a view also contains a controller and a context.
The data to which the elements of the view can be bound are stored and managed in the view context, enabling them to be represented or used on the screen.
The view controller can contain methods for data retrieval or for processing user input.
Empty View
The empty view is a special type of view. It is always generated automatically in a window or a view set area, provided that no view has been embedded manually. It may also be preferable to embed an empty view in a non-empty window as well. Just like a normal view, the empty view occupies a certain area of a window at runtime and can be used to hide a different view, for example, using specific controls.
When you create an empty view, an inbound plug with the default name ShowEmptyView is created.
View SetA view set provides a visual frame with predefined subsections into which you can embed your views at design time.
Using view sets is particularly advantageous when you design, implement, or display the user interface of a Web Dynpro application:
· Structured option to display more than one view in a screen
· Efficient support when designing user interfaces
· Possibility of using the predefined areas to make changes to the layout at later stage
· Reuse of views within a Web Dynpro window.
The Web Dynpro framework provides the following preconfigured view sets:
T layout
T layout 90°
T layout 180°
T layout 270°
Grid layout
Tab strip
Displaying a view and its embedded view sets always occupies 100% of the screen display area.
However, you can define a view set and, at design time, embed an empty view in a selected area of a view set. This area is displayed as an empty area at runtime.
ControllersDefinition
Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application.
There are two types of controllers:
View Controller
Global Controllers.
View ControllerEach view has exactly one view controller, which processes the actions performed by the user in the view. A view also has exactly one view context, which contains the data required for the view.
A view controller and the corresponding context exist at least as long as the view is displayed in the browser; if the view is replaced by a subsequent view, the local data is no longer available. However, the lifetime can also be connected to the lifetime of the surrounding component.
Global ControllersEach Web Dynpro component has at least one global controller. Once the data for this component controller have been created the first time they are accessed, the lifetime extends to cover the whole period during which the component is in use.
You can add additional global controllers in the form of custom controllers. These also last as long as the component and the data they contain are available to all views of the component.
Communication from one controller to the next is achieved by calling methods from a different controller, or by triggering an event on which other controllers are already registered. You define these controller uses when you create a controller.
Controllers can contain their own source code in the following areas:
· Event handlers – these are executed when a view is initialized, ended, or entered, when a user interface element of a view triggers an action, or when other controllers trigger a registered event
· Methods – these can be called by other controllers
· Supply functions – these are executed when necessary to initialize elements in the context.
Context
DefinitionThe data used in the component or in the view are stored in the context. Read-write access to this data is available using the controllers as a starting point.
Structure
The data from the contexts is managed in a hierarchical structure. Each context has a root node, underneath which the individual data fields (attributes) are stored in a tree structure. You create this tree structure according to the structure of your application.
Each node contains data fields that represent one of the following:
1.An individual instance of an object type
2.A table of instances.
Cardinality of a Context NodeWhen a node is created in the context of a Web Dynpro component, the cardinality of a node is specified. The cardinality defines how often a node is to be instantiated at runtime – that is, how many elements of this node are available at runtime.
1…1 Only one element is instantiated.
0…1 At runtime, no more than one element is instantiated, but it
is also possible that no element is instantiated.
1…n n elements can be instantiated, but at least one element must be instantiated.
0…n The number of instantiated elements of the context node can vary.
Recursion Nodes
Dynamic node nesting is possible within a context, creating what is called a recursion node. The node that is used for recursion is always a predecessor of the new node. The newly created recursion node is a reference to a predecessor node and therefore cannot be processed separately. Instead it takes on the structure of the node to be repeated.
The root node of a context cannot be used for a recursion.
Data Binding and Mapping
Within the Web Dynpro architecture, the contexts of the different controllers can be linked in different ways:
· A UI element of the user interface of the view can be linked with an element of the view context.
· A mapping can be defined between two global controller contexts, or from a view context to a global controller context.
The context of a global controller can be linked to a Web Dynpro Model.
Defining Mapping Between Two Contexts
The elements of a view context can be locally defined. In this case (represented in the graphic below as a "Local Node"), all the contained attributes are only visible within the relevant view. When the view disappears, the attribute values are deleted.
A second option for defining context elements is to link a context node to a node of another context. The graphic above represents the definition of a mapping between the node "Node 1" from the context of View 1, and the node of the same name in the context of the component controller. Also displayed is a mapping from the node "Node 2" from the context of View 2, also to a node with the same name in the component controller context. The global context of the component controller is visible for both view controllers, and all the controllers involved have both read and write access to the contained attributes. The values for the attributes of the component controller context are contained here as long as the user does not exit the component. The values are retained even if the view that you used last is no longer displayed on the screen. It is therefore possible to transport data across different contexts within a component. A data value that, for example, has been read from an input field of the first view, can be forwarded to the context of the component controller using a suitable mapping. The value then still exists in the memory if the navigation has already led to the next view. If a corresponding mapping is already defined for the successive view, the view can then process this value.
If the value is then changed in the second view, any subsequent views for which a similar mapping is defined then find the current value in their context.
Note:All global controller contexts (visible component-wide) can be linked to each other. A mapping can also be defined from a view context element to an element of a global context. Conversely, however, it is not possible to define a mapping to an element of a view context: An element of a view context cannot be mapped to an element of a global context. This is because the lifespan of the view context is generally shorter than that of the global controller context.
Binding a UI Element to a Context Attribute
Properties of the user interface elements contained in the view can be bound to attributes of a view context. This enables the context data to be displayed in the browser. Any user changes to the view displayed in the browser are stored in the context. Multiple properties can be bound to one context element.
Within a context, all elementary data types are available for the definition of attributes. The information stored here is also used by a Web Dynpro application for creating value help, and for creating error messages if invalid entries are made.
Defining a Binding to a Web Dynpro Model
You can also define a binding between the context of a component controller and the data of a Web Dynpro model.
Plugs and Navigation Links
Navigation between different views is enabled by plugs. These can be divided into inbound and outbound plugs. While inbound plugs define the possible starting points of a view, the outbound plugs of a view can be used to call a subsequent view. Plugs are part of the controller of a view. They are always assigned to exactly one view.
Note:Since interface views behave exactly the same as views with regard to navigation, the properties described below also apply to interface views.
Several views are generally embedded in a Web Dynpro window. Therefore, it is necessary to qualify one view as the view that is displayed first of all when a window is called. This view is assigned the Default property. The subsequent navigation structure is then created using this view.
The entering of a view using an inbound plug always causes an event handler method to be called. This is why an event handler method (whose use is optional) is automatically generated for every inbound plug. In this case, the inbound plug itself represents the event to be handled.
Note:If a view is flagged as the default view in a window, it is not called using the inbound plug.
To navigate from one view to another, each outbound plug from the first view must be linked with an inbound plug of the second view with the help of a navigation link.Exactly one navigation link can originate from one outbound plug, although this can lead to a series of target views. The arrangement of these target views is not qualified, which means that all target views are controlled at the same time.In contrast, an inbound plug can be controlled by several outbound plugs .
Note: Information about which plugs are connected with each other is not contained in the individual views. This information is stored separately in navigation.
By implementing the navigation you create a static, potential connection between two views of a Web Dynpro application. You thus define the view sequence for when the Web Dynpro application is executed. You must define a navigation link for each possible view change.
Event
Component controllers and interface controllers enable events to be created.
Events are used to communicate between controllers and enable one controller to trigger event handlers in a different controller.
Cross-component communication can be implemented using the interface controller’s events. Events that were created in the component controller are visible within the component only.
Inbound Plugs
Inbound plugs in a view also react like an event. Therefore, when a view is called using an inbound plug, the event handler that is optionally available for the inbound plug is always called first. In this case event handling takes place within the current view controller, however.
Even the controller of an interface view reacts to the starting point in the view by calling the event handler method that belongs to the corresponding inbound plug. An event handler is therefore created and can be programmed suitably for every inbound plug in an interface view.
UI Element Events
Some UI elements, such as the button element have special events that are linked with user actions. These events are predefined and have to be linked with an action at design time.
Action
Actions for UI Element Events
Some UI elements such as the button element can react to a user’s interaction: clicking on the corresponding pushbutton can trigger a handling method to be called within the view controller. Such UI elements are equipped with one or several general events, which can be linked with a specific action at design time (switching to a subsequent view, for example). If such an action is created, an event handler method for this action is created automatically. In this way, you can equip a UI element event (which has been inserted several times into a view) with different actions as necessary. The event is then processed by the corresponding event handler depending on the action that is linked.
Actions can also be reused within a view. This means that an action can be linked to the events of several (or even different) UI elements.
Note: Unlike cross-controller events, UI element events are always handled within their own view controller; there is no cross-controller communication. UI element events themselves are predefined and cannot be changed.
Web Dynpro Model
DefinitionWeb Dynpro technology is based on the Model View Controller paradigm, to ensure a clear division between the definition of the user interface and the implementation of the application logic. Within this concept, the model retrieves the application data from the back-end system. If you want to define multiple models, the model must be bound to the relevant Web Dynpro component that the model is to use.
The data for a Web Dynpro application can originate from different sources. You can
1.Call and use SAP data from a SAP back-end system using BAPIs
2.Define new data
3.Call and use Web services
4.Combine the three above procedures
5.Import an external model using the appropriate tools.
SAP NetWeaver:WebDynpro ABAP Vs WebDynpro JAVA
Differences between two existing webdynpro techniques – SAP WebDynpro for ABAP and SAP WebDynpro for JAVA. Both have their own pros and cons. So the decision to choose one is best to leave upon the organizations depending upon the need, suitability and business circumstances.
Webdynpro is SAP’s own strategic model to create and develop web-based UI applications. Based on the foundation of MVC architecture, it separates the Model, View and Controller which means it keeps apart the backend data from user interface and processing logic. Since all the three are independent so, three developers can work together on the same application which can later be merged via interface. Webdynpro has been classified into two UI Technologies – Webdynpro ABAP and Webdynpro JAVA. Both these domains are integrated with runtime and graphical environment comprising special UI elements which help in building an attractive UI and minimize the coding effort. It cannot be decided on the basis of features and functions that one is better and should be preferred over the other. Similarity is that both can be integrated with SAP Portal and SAP Netweaver Business Client.
Difference between Webdynpro ABAP and Webdynpro JAVA
Although both technologies have same functionalities but even then they are not identical. Following are some of the differences:
Language: First difference is the programming language used as the names Webdynpro ABAP and Webdynpro JAVA reflect. In ABAP Webdynpro, along with ABAP coding, RFC’s are also supported via Service call. Unlike Webdynpro ABAP, we cannot do ABAP coding in Webdynpro JAVA. Instead RFC’s and Web services are created and used in it to serve this purpose. In addition to Web services and adaptive RFC, Java Beans is another model supported by Webdynpro JAVA.
Design Time Environment: Webdynpro ABAP requires ABAP Workbench (SE80) while SAP Netweaver Developer Studio is necessary for designing Webdynpro JAVA applications. So, additional installation is required. This studio reduces the development effort and utilizes some visual tools for creating components which can be reused.
Storage: Applications developed using Webdynpro ABAP are stored centrally in ABAP server whereas in case of Webdynpro JAVA, the code remains on the client machine that is developed using a tool called Netweaver Developer studio. So, due to the powerful version control system of Webdynpro ABAP, the load removes from the development machine which is not possible in case of Webdynpro JAVA.
Skills Required: For Webdynpro ABAP, a developer should have knowledge of ABAP programming, Development tools, Database concepts, ABAP Objects. However, Webdynpro JAVA requires skill set comprising java programming, java development tools and object-oriented concept.
Propagation Infrastructure: Since Webdynpro ABAP is integrated with ABAP development environment, therefore ABAP data, Data Dictionary Types and Search helps are directly available. Moreover, MIME Objects are directly accessible to ABAP Webdynpro applications. Also, while propagating the application to production, the correction and transport system keeps track of the version management and changes. So, no need of any additional infrastructure. But, java development environment is incomplete without NWDI (SAP Netweaver Development Infrastructure). It needs to be set up. Only then all the development objects will be directly accessible and propagation of java applications to production will be easy.
Device Recognition: In Webdynpro ABAP, it is not possible yet because of lack of support. But it is possible in Webdynpro JAVA as it adapts interface automatically. Mobile Devices are the best example for it.
Performance, Scalability and Robustness: Large scale applications that involve large number of web users can’t work well on ABAP server. So, for robust and scalable applications, Webdynpro JAVA is preferred because of powerful J2EE server as proved by Sun Microsystems. However, small-scale or applications involving small or medium users can go well with Webdynpro ABAP. Thus, performance varies depending on the number of web users and one can choose ABAP or JAVA accordingly
Web Enabling SAP: Options, Scenarios and Best Practices: SAP Webservice
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.
This blog is a part of 6 blog series and here we will discuss the 6th option for web enabling SAP.
This blog is a part of 6 blog series and here we will discuss the 6th option for web enabling SAP.
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
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 6th option:
- Creating a web service inside SAP: 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.
Pros:
a) This is the de-facto standard for interfacing technology over the web.
b) 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.
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.
a) This is the de-facto standard for interfacing technology over the web.
b) 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.
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.
Web Enabling SAP: Options, Scenarios and Best Practices: SAP ABAP Webdynpro
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.
This blog is a part of 6 blog series and here we will discuss the 3rd option for web enabling SAP.
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
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 3rd option:
- ABAP Webdynpro: 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.
Pros:
a) Since ABAP Webdynpro is MVC based, they are more preferred and recommended over BSP.
Cons:
a) 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.
b) Comparatively BSPs are light weight when it comes to network traffic and performance.
a) Since ABAP Webdynpro is MVC based, they are more preferred and recommended over BSP.
Cons:
a) 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.
b) Comparatively BSPs are light weight when it comes to network traffic and performance.
Web Enabling SAP: Options, Scenarios and Best Practices: SAP BSP
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.
This blog is a part of 6 blog series and here we will discuss the 2nd option for web enabling SAP.
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
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 2nd option:
- BSP: 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.
Pros:
a) 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.
b) As compared to screens rendered via ITS, BSP screen elements are more user friendly and have the standard web look and feel.
c) It is light weight and consumes less network bandwidth as compared to ITS technology.
Cons:
a) 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.
a) 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.
b) As compared to screens rendered via ITS, BSP screen elements are more user friendly and have the standard web look and feel.
c) It is light weight and consumes less network bandwidth as compared to ITS technology.
Cons:
a) 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.
Web Enabling SAP: Options, Scenarios and Best Practices: SAP ITS
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. This blog is a part of 6 blog series and here we will discuss the 1st option. 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
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 1st option:
- ITS: 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.
Pros:
a) No additional development is required. Almost all standard transactions and reports can be displayed in a browser.
Cons:
a) 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.
No comments:
Post a Comment