Webdynpro Interview Questions
Web Dynpro Applications are built on Which Programming Technique and What Pattern are followed?
- Web Dynpro framework uses declarative programming techniques to create a meta-model of the application which is free from back-end and front-end programming languages. Rather the metadata is programming language-neutral and has information stored in XML format. It's only during run-time that the rendering engine generates the code in html and java script from this meta model of the application. So the design part - which defines the UI and data flow between UI elements - is completely abstracted minimizing the coding (which is required only for implementing business logic).
- The model-driven approach helps developer to focus less on coding and technology part and more on the design part of the application - "minimizing coding and maximizing design". Naturally, the primary focus of business application developer should be the business logic and the technological implementation should not distract him.
- MVC pattern is followed in Webdynpro abap.
What is View Assembly ?
- A window defines the super set of all possible views that a Web Dynpro application could require whilst running a particular component. The number of views visible at any one time however, will typically be only a subset of the number of views embedded within the window.
- The subset of views rendered at any one time is known as the View Assembly. User interaction followed by subsequent navigation processing will frequently cause this subset of views to change with every server round-trip. The view assembly represents those views seen by the user on their client device after the completion of a particular server round trip.
What is Face Less component ?
It is a component with zero views and zero windows. Such a component is known as a "faceless" component and is useful when a complex unit of functionality requiring no direct user interaction needs to be encapsulated. A good example of a faceless component is the creation of something called a model component. This is not actually a specific Web Dynpro component type; rather it is a standard Web Dynpro component that has been written specifically for the task of interacting with a model object.
What are the types of Controller ? Describe ?
- In broad terms, SAP has defined two categories of Web Dynpro controller. The difference between them is simply this: A controller either
- Has a visual interface, or
- Does not have a visual interface.
- SAP has introduced this difference in order to maintain a strict separation between those parts of the business application that display data (typically data consumers), and those parts of the business application that process data (typically data generators).
What are Recursion Nodes ?
The recursion node is a special type of node used when a node hierarchy with a recursive structure needs to be created. This is needed when, for instance, the depth of the node hierarchy is not known until runtime. Using a recursion node, you can declare that a particular node structure be replicated as a child of itself. A good example here is if your context needs to hold information in the same structure as a file system, containing directories and sub directories.
What is an Empty View ?
There is a special type of view known as the empty view. This view requires no manual implementation, neither is it possible to interact with it in any way other than invoking its default inbound plug - show Empty View. If you require one particular area of a view set to be empty, then you should embed the empty view into the view area. You can then treat this view just like any other view you have written, except that calling its inbound plug will cause the corresponding view area to be blanked out. If a view set has had no views manually embedded into one of its view areas, then the empty view will be substituted automatically.
How does the Web Dynpro framework decide which particular views make up the current view assembly ?
- When an application is executed for the first time, only those views which have their default flag set to true will belong to the first view assembly.
- Thereafter, user navigation will occur and the view assembly will be composed of those views that have been newly instantiated (on account of their inbound plugs being fired), and those views that persist from the previous view assembly (because no outbound navigation took place from them).
- Define WebDynpro Controller.
- Controllers are the active parts of a Web Dynpro component. In the design of Web Dynpro controllers, SAP has made a significant modification to the original MVC concept of a controller.
Main advantages of the original MVC design ?
- One of the main advantages of the original MVC design was its focus on the re usability of models, views, and controllers as individual coding units. However, Web Dynpro is focused on more than just the technical reuse of coding entities. Instead, Web Dynpro has been designed to be the foundation for implementing business solutions. Therefore, one of the key elements in its design was the need to provide a reusable unit of code that corresponded to an atomic step within a business process, rather than trying to build business solutions from reusable units of low level code that, in themselves, were not directly related to the business process.
- In other words, the Web Dynpro component is a reusable unit of code at the business process level, rather than the technical coding level. The resulting change in the nature of code reuse produces a shift in the developer's focus of attention during coding. No longer are they concerned so much with the reuse of technical coding units; instead, the design of a Web Dynpro component focuses on the reuse of atomic units of business processing. A component can be thought of as a set of controllers, views, and model usage declarations that have been aggregated for the specific purpose of reuse.
If the view set concept is not implemented in Web Dynpro for ABAP, what options are there for reusing views ?
- In both Web Dynpro for ABAP and Java, there is a specific UI Element called the View Container. This UI element, when added to a view layout, acts as a container for any other view. View Containers can be arranged in large variety of ways in order to achieve the desired layout on the screen.
- The views that can be embedded into a View Container UI element are the following:
- Any view from the current component
- Any visual interface from a child Web Dynpro component
- An empty view (supplied automatically by the Web Dynpro runtime)
What is a View Set ?
- A view set is a visual framework that subdivides the window into predefined areas. Each subdivision of a view set is known as a view area, and multiple views can be embedded into a single View Area.
- The following preconfigured view sets are available:
- T layout T layout 90o T layout 180o T layout 270o Grid layout Tab strip
- Each subdivision within the view set layout is known as a view area.
How is model-driven architecture implemented in Web Dynpro framework ?
- Web dynpro framework uses declarative programming techniques to create a meta-model of the application which is free from back-end and front-end programming languages. Rather the metadata is programming language-neutral and has information stored in XML format. It's only during run-time that the rendering engine generates the code in html and java script from this meta model of the application. So the design part - which defines the UI and data flow between UI elements - is completely abstracted minimizing the coding (which is required only for implementing business logic).
- The model-driven approach helps developer to focus less on coding and technology part and more on the design part of the application - "minimizing coding and maximizing design". Naturally, the primary focus of business application developer should be the business logic and the technological implementation should not distract him.
What is Meta Model Concept ?
- Since SAP uses both ABAP and Java as languages for the delivery of its application software, any development framework used by SAP must be able to accommodate both the requirements and the idiosyncrasies of these languages. It made little sense to have one design methodology for ABAP based applications and another for Java; therefore, a common structural concept was developed to lie at the heart of all Web Dynpro development. This common structural foundation is known as the "Web Dynpro Meta model", and acts a language neutral specification for both the visual appearance and development structure of a Web Dynpro program.
- Since SAP uses both ABAP and Java as languages for the delivery of its application software, any development framework used by SAP must be able to accommodate both the requirements and the idiosyncrasies of these languages. It made little sense to have one design methodology for ABAP based applications and another for Java; therefore, a common structural concept was developed to lie at the heart of all Web Dynpro development. This common structural foundation is known as the "Web Dynpro Meta model", and acts a language neutral specification for both the visual appearance and development structure of a Web Dynpro program.
What do you mean by Lifespan of a Web Dynpro Application ?
- The lifespan of a Web Dynpro application is determined by, and equal to, the lifespan of the application's root component.
- Lifespan of the application's root component
- The component chosen to act as the application's entry point is known as the root component. When a user invokes the associated URL, the WebDynpro framework creates an instance of the application's root component. This component instance will persist until such time as the user formally terminates the application, or closes their client (e.g. the browser), enters a new URL, or remains inactive for the configured time out period.
- Lifespan of a child component
- Any Web Dynpro component may act as the child of any other Web Dynpro component. In such cases, the lifespan of the child component may either be controlled automatically by the Web Dynpro framework, or it may be controlled by coding written by the application developer in the parent component.
How can you determine Lifespan of custom controllers ?
- The lifespan of a custom controller is determined by a parameter setting made during the design time declaration. It can be either "Framework Controlled" or "On demand". If you choose "Framework Controlled", then the Web Dynpro framework will instantiate the custom controller when the component is instantiated. If however, you choose "On demand", then the Web Dynpro developer must write the coding necessary to instantiate the custom controller.
- Each child component usage is instantiated with a unique name that must be defined at design time. During the lifespan of the parent component, a child component may only ever be instantiated once under a given name; however, should it be necessary, you may declare multiple usages of the same child component as long as you specify different usage names.
Why would a component need multiple windows ?
- A good example of where a Web Dynpro component would need multiple windows is where a single business application needs to be accessible on variety of client devices. For example, a particular application needs to be written that can be executed from both desktop based browsers and handheld devices.
- In order to avoid having to write the same business logic twice, you can write a single Web Dynpro component but within it, you define two sets of views. The first set of views has been laid out with a desktop browser in mind (I.E. there will be a lower number of views because a larger quantity of data can be presented on each view).
- The second set of views however, is laid out with a handheld device in mind (I.E. the restricted space on the handheld device will mean that more views will be needed in order to present the same quantity of information).
- The two sets of views are then grouped together into different windows; one for the desktop based browser, and the other for the handheld device. Couple this design together with the principle that view controllers are not responsible for generating the data they display, and you should quickly be able to see that all the business logic need only be written once and placed within the component controller and custom controllers. The view controllers then simply display (consume) the data supplied to them by the non-visual controllers.
- The last step is to define two different Web Dynpro applications. Both applications will use the same Web Dynpro component, but since two windows have been defined, there will be two Interface view controllers - one for each window. These interface view controllers are then used to define the visual interface of each application.
- A second example for a component with more than one window is the use of popup windows. A popup window will always be implemented by a separate window which may be defined in the same component, but processed as an independent window.
The Web Dynpro framework has been built to follow the principle of Lazy Data Access. This means that the processing required to generate data will not be invoked until the data is actually needed. When this principle is applied to the architecture of the context, it means that unless there is an attempt to access the data in a singleton child node, then even though the lead selection in the parent node has changed, the child node's supply function will not be called.
Before a mapping relationship can be established, what criteria must be met?
There must be a suitable node available to act as a mapping origin
No comments:
Post a Comment