Cross-Component Programming Web Dynpro ABAP

Web Dynpro components are reusable modules. This allows you to build Web Dynpro applications that consist of different components. From within a component, an interface enables you to use the data and functions of another component. The prerequisite for this is that the second component must be available at runtime in an active version.

Within a distributed development project, it makes sense to create generic components to be used by different developers. For more information, see Working with Component Usages.

In addition, it may be useful to create own components only as suppliers of the data required in other components. Such components are called model components; they only make sense whenever several components must access the same set of application data. Model components are components without graphical elements but with the full controller functionality.

The Web Dynpro framework additionally offers the possibility of defining component interfaces independently of concrete components. These separately defined interfaces can then be used and implemented in an application component. The advantage is that all used components have a – at least in parts – uniform interface. Developers who use such components for their applications can then rely on the existence of particular elements in the component interfaces.

For a better understanding of the use of component-internal and cross-component elements, section The Different Controllers of a Web Dynpro Component once more discusses the different controller interfaces and their naming conventions.

Controllers of a Web Dynpro Component Cross-Component Programming Web Dynpro ABAP

Component Controller

The component controller provides data and processing logic that it should be possible to display or change for all views of a component. It has three interfaces:

· Interface IF_ for coding within the controller

· Interface IG_ for cross-controller coding within the current component.

· Interface IWCI_ for cross-component coding. On the ABAP language level it represents the interface controller (see below).

Within the component, mapping is possible to any context element of the component controller. (See also Data Binding and Mapping).

The attributes of a component controller are known to all methods that are called within a component and can be used by them, provided they have the Public property. Otherwise, their visibility is restricted to the component controller. Events and methods assigned to the component controller are visible throughout the component. So, for example, any action of a view of the component can call such a method of the component controller.

The visibility of a specially marked number of methods, events and context nodes of a component controller can be extended beyond the borders of one’s own component. They then form the interface controller of the component.

Interface Controller

The interface controller is used for cross-component communication. It defines the controller part of the interface of a Web Dynpro component. The interface controller itself does not contain any implementation.

· For the interface controller of a Web Dynpro controller, the methods are implemented in the related component controller.

· For the interface controller of a component interface definition, the implementation is performed in the component controller of the embedding component.

For every interface controller there is a related ABAP interface IWCI_ or IWCI_. For information on how to use component interface definitions in programming, see Working with Component Interface Definitions.

Interface Controller of a Component

Events, methods and context nodes of the component controller can be made visible for other components; mark the Interface checkbox to assign them to the component interface. They are then included into the related ABAP interface IWCI_.

In the object list of the ABAP Workbench, these special component controller elements are displayed additionally in the Interface Controller node, but they cannot be changed there.

For elements of the context of a controller from another component a mapping can be defined to the elements of the component controller context assigned to the component interface.

In the object list of the ABAP Workbench, the interface controller is displayed as a separate object of the related Web Dynpro component. In spite of this fact, the interface controller of a component is implemented and edited as part of the component controller (see above).

Interface Controller of a Component Interface

Only if an interface controller is part of a component interface, the controller editor is in change mode and the context, the events and the methods can be implemented and edited directly.

The global interface IWCI_ is stored in the class library and can be displayed using SE24.

Custom Controller

The properties and use of the custom controller that can be added optionally correspond exactly to those of the component controller. This means that it is visible to all elements of the component and the lifetime of the elements is the lifetime of the component. The custom controller gives you the option of structuring functions and data within a component. It makes sense to create and maintain a custom controller if a certain subset of views of a component should be equipped with a special function or with a special set of data.

View Controller

Layout and flow logic are very closely connected to each other in a view. As part of a view, the view controller – unlike other controllers – is therefore not edited in the Controller Editor. Instead, the necessary tools have been integrated into the View Editor, which can be used to edit the view as a whole.

Just like the component controller, the view controller contains data and functions. Furthermore, the view controller also has

· An IF_ interface, which means that these data and functions are visible within the same view only.

The lifetime of the controller element of a view is restricted to the lifetime of the view. To create simple Web Dynpro applications, it is sufficient if you maintain the component controller and the view controller of a view. The two controllers described below are optional and help you to structure complicated components and applications, thereby increasing their reusability.

Window Controller

For every window created in a Web Dynpro component, a window controller is generated. Such a window controller is visible throughout the component – it behaves like a component or custom controller.

As part of a Web Dynpro window the window controller – just like the view controller – is not edited in the Controller Editor but in the Window Editor instead.

Component Usages Web Dynpro ABAP

Embedding a Used Component

To be able to use an external component (regardless of whether it is a faceless component or a complete component), you must first define a component usage. Follow the steps described below:

Procedure

Select the component that you want to process by double-clicking on it in the object list. The Component Editor is displayed.

1. Select a name for the new component usage and enter it in the first column in the table.

2. Select the component to be used (F4 help).

3. You should now consider the following:

· If the external component should be used by a single view of your component, it makes sense to create the instance of the external component in a controller method of this view.

· If the external component should be accessible for several views, however, the instance of the external component should be created at a central location. The wdDoInit method of the component controller is available for this.

(For general information about controllers, see Controller Editor).Regardless of whether you have selected the controller of a view or a cross-view controller as the instantiation point for the external component, the external component must now also be entered on the Properties tab page for this controller. To do this, proceed as follows:

4. Double-click the required object in the object list (that is, on a view or a controller entry). These are listed by object in the Controller Editor or the View Editor.

5. Switch to the Properties tab.

6. To create a new usage in the Used Controller/Components table, choose Create. Make sure that the Editor is in change mode.

7. The following dialog window lists all components and controllers that are available for use. Besides all global controllers of your own component, this list also includes the external component and its interface controller.

Whether you now select only the external component or both the external component and its interface controller depends on how you want to proceed

● If you merely want to display the used component – that is, call it from your current component – continue with

Component Usage Without Controller Access

● If you want to enable the current component to access the interface controller of the used component, continue with

Component Usage with Controller Access

Component Usage without Controller Access Component Usages Web Dynpro ABAP

You can use an external component in two ways: If you only want to display the external component, but not change the data of its interface controller or use its functions, you can omit the explicit usage declaration of the external interface controller in the current controller. In this case, simply declare the usage of the external component in the currently edited controller (see figure).

To do this, choose Sample Usage®Foreign_Component. This merely enters the usage of the component in the table, and you can call the component for display purposes from the current component.

The usage was added to the metadata again.

Instantiating the Used Component

Regardless of whether you decided on a component usage with or without controller access, you now have to instantiate the used component in a method that you have selected:

Procedure

...

1. Select a method of your controller that you are currently processing. This may be the predefined method WDDOINIT, for example, which is called automatically each time the controller is called. If the jump to the external component should not be connected to an event, you can select an event handler method instead.

2. Double-click on the method selected in step 1 to open an ABAP Editor, where you can insert the necessary method. The Web Dynpro Code Wizard provides support:

3. Click on the Web Dynpro Code Wizard in the Editor’s toolbar. A list of the frequently used Web Dynpro statement structures are listed in a separate window.

4. Select Instantiate Used Component.

5. Display the F4 help for the Comp. usage line. All of the component usages that are available in the table of the Properties tab for the controller are displayed. Select the usage you require and confirm the dialog. The required source code is automatically inserted into the current method. Once you save the method, the external component is available to your own component at runtime.

Example: For a component, the usage of another component has been declared. This usage is called MY_COMP_USAGE.

method MY_CONTROLLER_METHOD . data: L_REF_CMP_USAGE type ref to IF_WD_COMPONENT_USAGE. L_REF_CMP_USAGE = WD_THIS->WD_CPUSE_MY_COMP_USAGE( ). if L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) is initial. L_REF_CMP_USAGE->CREATE_COMPONENT( ). endif. endmethod.

Method WD_CPUSE_

This method contains the local interface of each controller as soon as you have declared the usage of an external component for (the entire component at first and then for) the current controller. The method returns a reference variable of type IF_WD_COMPONENT_USAGE. (See also Predefined Methods of the Local Controller Interface in Part 1 of the programming manual).

In the first step, method WD_CPUSE_ was used to generate an object for the used component. In the second step, the object was instantiated provided that no instance existed.

You can now access the used component, but you cannot use the methods of its interface controller, because you need to declare an additional usage for the respective controllers (see Component Usage with Controller Access).

Calling the Used Component

To display the external component, you can now embed an interface view of any window of this component in a window of your current component. This procedure corresponds exactly to embedding a view of one’s own component. By setting up navigation from one outbound plug of a view of your current component to an inbound plug of the interface view of a window of the external component, you enable the external component to be displayed.

An example of how you set up a navigation is described in Part 5: Setting Up Navigation of the Creating a Simple Flight Info Application tutorial.

Every interface view of a used component can be embedded exactly once into a window of an outer component. If you want to embed a particular interface view of a component more than once in an outer window, you must first declare the respective number of component usages. Usually you do not know this number during design time, because it depends on factors that are determined only at runtime. For more information, refer to Dynamically Creating a Component Usage under Dynamic Programming in this documentation.

If you also want to access the content of the external controller context, or if you want to use methods of this controller, see Component Usage with Controller Access.

Component Usage with Controller Access

If you want to enable access to the interface controller of the external component from the current component – that is, if you want to change this controller’s data or use its functions – you must choose on the Properties tab page of the selected controller Sample Usage ® Foreign_component ® Interface Controller. In this case, both the component and the interface controller are explicitly included into the table.

The usage was added to the metadata again.

Instantiating the Used Component

In accordance with the procedure described in the section above, the used component must be instantiated in an appropriate method of the component (see Component Usage without Controller Access).

Implementing Access to Methods of the Controller of a Used Component

If you now want to access the content of the used controller context or if you want to use methods of this controller, you have to expand the instantiation of the used component that is described above. To be able to do this, you must have entered the interface controller of the used component on the Properties tab page of the current controller (as described above). The usage declaration of the component is not enough in this case.

Procedure

...

1. Select another method on the Methods tab page. This can be – but does not have to be – the same method as in step 1. For example, you can instantiate the used component in a method of the component controller, so that you can then access its data or functions from different view controllers. However, you must ensure that the external component has been instantiated before the interface controller is accessed (see also The Phase Model in Part 1 of the programming manual).

2. Open the ABAP Editor by double-clicking on the name of the selected method.

3. Click again on the Web Dynpro Code Wizard button.

4. Select Method Call in the Used Controller.

5. Use the F4 help to open the Component Name row. All available components and their controllers are listed in a separate window.

6. Select the controller you require and confirm the dialog.

7. In the next step, display the F4 help for the Methods row and select the required controller method on the subsequent dialog.

8. Confirm the Wizard dialog.

The method of the controller for the used component that you selected was added to the coding of the method that you are currently editing. You can now use this function according to ABAP Objects programming.

Method WD_CPIFC_

If in addition to the component usage the usage of the related interface controller has been entered, the list of the local controller methods is extended by the method WD_CPIFC_. This method returns a reference variable of type IWCI_, that is of the type of the ABAP-global interface of the used component.

Example: The entered component usage MY_COMP_USAGEincludes the component MY_USABLE_COMPONENT into the current component. Method WD_CPIFC_MY_COMP_USAGE of the local controller interface enables you to access the methods of the interface controller of the used component MY_USABLE_COMPONENT. For example, you can then use its method WD_GET_API to access the methods of the runtime API (see above) of the used interface controllers.

method MY_CONTROLLER_METHOD .

data: L_REF_INTERFACECONTROLLER type ref to IWCI_MY_USABLE_COMPONENT,

L_API_INTERFACECONTROLLER type ref to IF_WD_CONTROLLER.

L_REF_INTERFACECONTROLLER = WD_THIS->WD_CPIFC_MY_COMP_USAGE( ).

L_API_INTERFACECONTROLLER = L_REF_INTERFACECONTROLLER->WD_GET_API( ).

endmethod.

Navigation Through Window Plugs Component Usages Web Dynpro ABAP

You can vary – at runtime – which link that was set up at design time you wish to follow. You can do this through navigation control with the help of event handlers from window plugs. In this manner you can control at runtime – within navigation in a window of an embedded component – which view of this embedded window is to be displayed first.

Including the Window Plugs into Navigation

An additional step in navigation is necessary to include a parameter for navigation control. Instead of linking the outbound plug of a view in the window editor with the inbound plug of a subsequent view, the outbound plug of the view is linked with an inbound plug of the embedded window.

Each window automatically has the inbound plug Default. However, you can create any number of your own inbound and outbound plugs for each window. The plugs of a window are displayed as its elements in the tree structure in the window editor and can be processed there as well.

In addition, an outbound plug is created for the window for each required navigation option. The corresponding navigation link is set up in the window editor. In this way, all possible navigations are planned ahead of time.

So that navigation can be controlled at runtime, the outbound plug of the starting view must pass a parameter to the inbound plug of the window.

In the event handler method of the inbound plug of the window, the system controls which outbound plug of the window is called at runtime with the help of a suitable implementation – depending on the value of the passed parameter. This means that the navigation path to be executed is controlled.

Cross-Component Context Mapping Component Usages Web Dynpro ABAP

A third way of using the content of the interface controller of a used component is the cross-component context mapping.

As soon as you have declared the usage of the interface controller and instantiated the external component as described in the procedure of the section above, the context of the external interface controller is available for mappings. On the Context tab page of a controller for which a usage of the external interface controller has been declared, you see the context of this interface controller on the right side of the editor and you can define a mapping for a node of your current controller context to a node of the interface controller context.

External Context Mapping Component Usages Web Dynpro ABAP

Cross-Component Context Mapping described the mechanism of a mapping across the borders of a Web Dynpro component. In the example, component A used a component B and for Node 1 of the component controller context of A a mapping was defined to the node of the same name of the interface controller context of component B. Both components are known at design time. For a better understanding, the figure below again shows the simple context mapping as explained in the section above:

The mapping definition at runtime provides component A with the value for its component controller context from the interface controller of component B – with other words:

The node of the interface controller context is the “source” node in this mapping relationship.

One example of this type of mapping is the use of a dark component. Such a component does not have its own UI but is used solely for providing for a used component in which a layout is defined.

In case of the external context mapping the flow of information is vice versa:

The used component B defines in its interface controller context a node that is released for an external context mapping. In the controller editor, this is described with the attribute Input Element (Ext). when you create a node for the interface controller. This attribute is available explicitly only to context nodes of the component controller that are marked as interface nodes.

A node of the interface controller context marked in such a way can be linked with a context node of a used component and then receives the relevant values from the context node of the using component A only at runtime.

In this case, Node 1 of the component controller of component A is the “source“ node and at runtime determines the values also for the node with the same name of the interface controller context of component B.

A simple context mapping is always defined in the context of the relevant controller. The relevant controller always belongs to the component you currently edit. The mapping path is always directed from the currently edited controller context to the controller node of the used interface controller.

Contrarily, an external context mapping is always defined in the controller context of the respective component usage. You always define an external mapping for an appropriate node of an “external” interface controller you use. The mapping path in this case always points from the context of the used interface controller to a node in the currently edited controller context.

An external context mapping to a context of a used component makes sense whenever the used component is intended to provide a frequently used UI schema for various other components.

Usually, the node to be mapped externally is fully typed during creation. You already determine at design time which nodes and attributes the externally mappable node contains. This is of advantage because it allows you to program references to this node statically within the relevant controller. These references include linking a UI element to the node.

Example

Within a large application a component is designed for address display. The context from which the address will be selected is completely open at design time, the content of a model belonging to the address display is unknown. However, since the address component is intended to display only addresses from one country, the view layout can be created. Thus you are able to construct a component for the display of country-specific addresses and bind the UI elements to externally mappable nodes. This component may now be used by all kinds of other components; by setting up an external mapping, the address display is supplied with the relevant data.

You are not allowed to set up both a normal and an external mapping for the same controller usage. The resulting mapping would be cyclic and cause runtime errors.

Difference Between Normal and External Context Mapping

The question of whether or not to use an external context mapping cannot always be answered uniquely. From the technical point of view, the desired result can frequently be reached via a normal mapping, provided that the application is redesigned accordingly. However, there is a fundamental difference:

· As soon as you set up an external mapping for an externally mappable node, the runtime call of a supply function you may have explicitly coded is skipped. From this moment on the node is supplied with attribute values exclusively via the node of the using component.

Advanced Concepts

When you create the node to be mapped externally, you can leave open the type. In this case, the node receives its complete typing from the context node for which a mapping is defined to external nodes. Against such a node, you can program only dynamically in the related controller, because its structure is unknown at design time (see Part 3: Dynamic Programming).

If the node to be mapped externally of the used component requires a particular structure, this structure must be contained in the context node of the using component (A in our example). In addition, this node can contain other attributes, which are not known to the interface controller of component B at design time. In this case, the interface controller of component B can be coded

· statically against the given structure, and additionally

· dynamically in view of attributes that may be added via a mapping.

A node, for which an external mapping has been defined, can no longer use the dispose method.

Working with Web Dynpro Component Interfaces Component Usages Web Dynpro ABAP

In every Web Dynpro component, the creation procedure implements an interface. This component interface contains exactly one interface controller and at least one interface view (for more information, see Interfaces of aWeb Dynpro Component in the Architecture manual). The interface controller contains a context, events and methods.

The interface views of the component interface have no direct connection to the interface controller; they are generated automatically for every window that is created within the component.

The component interface is implemented exclusively in its related component; it cannot be implemented in other components.

The programming environment of Web Dynpros now allows you to enhance this pre-implemented interface by implementing additional interfaces, which have been defined independent of a component.

Component Interface Definitions

Component interface definitions allow you to generically define a uniform interface structure and later use it in a variety of application components. The advantage of this procedure lies in the fact that in a distributed development the interfaces of all components that use the interface definition reliably contain a particular set of controller elements (methods, context elements, etc.) and interface views, which can be addressed by the developers of using components. The developer of a using component does not need to know which actual implementation of the interface is used – this can be determined dynamically at runtime.

You use the Object Navigator to create and edit component interface definitions analogous to components.

The interface controller of a component interface definition and the interface controller of a component differ in two items:

Interface Controller of a Component Interface Definition	Interface Controller of a Component
The controller can be edited	The controller can be displayed but not edited. To edit its elements, you must call the related component controller and mark the Interface checkbox for all elements intended for the interface controller (see The Different Controllers of a Web Dynpro Component)
Methods can be defined in the editor, but they cannot be programmed there. The methods are programmed only after the implementation of the component interface definition in a Web Dynpro component.	The methods can be created in the editor of the related component controller (see above) and then be programmed in the ABAP editor.

In addition to the mandatory interface controller you can add any number of interface views to a component interface definition.

Implementing Component Interface Definitions

These separately defined component interfaces can now be added to the implemented interface of a component. With the implementation of a component interface definition in a component, the elements of the separately defined interface controller are added to the component controller of the implemented component. Within this implemented component, the methods of the interface controller that have only been defined so far can be programmed component-specifically. For large programming projects, this results in a higher reusability of the interface structures.

Besides the interface controller a component interface definition can contain interface views.

When implementing a component interface definition, these interface views are added to the existing views in the interface folder of the implemented component. The related windows are generated and stored in the respective folder of the object list. They are empty and can now be laid out especially for the embedding component.

For a better understanding, the next section illustrates this concept by means of an application example.

Creating a Web Dynpro Component Interface Definition Component Usages Web Dynpro ABAP

Procedure

1. Start the Object Navigator and in the object list selection choose Web Dynpro Comp./Interf.

2. Enter a new name for your component interface definition and choose Display.

3. Confirm the Create Object dialog.

4. In the next dialog window enter a description of your component interface definition and in the list below mark the type Web Dynpro Component Interface. Confirm this dialog as well.

5. Create an object catalog entry by assigning the new object to the desired package and by choosing Save.

You can now create methods and interface views for this interface definition.

Implementing a Web Dynpro Interface Definition Component Usages Web Dynpro ABAP

To implement a Web Dynpro interface definition in a component, enter it into the Implemented Interfaces table of the component editor of the component:

...

1. Select the component that you want to process by double-clicking on it in the object list. You are now in the Component Editor and can switch to the Implemented Interfaces tab page.

2. Enter the name of the desired interface definition in the first column of the table and save it.

3. In the third column of the table, Implementation State, a traffic light symbol appears.. As long as this traffic light shows red, the interface definition is not or not completely implemented. Choose New Implementation to trigger the implementation; the traffic light switches to green.

If changes are made to the interface definition after the implementation, then the traffic light in the table of the implementing component switches back to red; the changed interface definition must be re-implemented.

Result

After the implementation, the implementing component now contains the elements of the interface definition.

· The methods of the interface definition have been added to the component controller and can now be edited there. You can mark the Interface checkbox for each of them to make them visible as elements of the interface controller.

· The same applies for the context nodes of the interface definition.

· The interface views of the interface definition have been implemented in the component interface and are listed in the object list underneath the Component Interface node. In addition, all related Web Dynpro windows have been generated. They are also displayed in the object list and can now be edited.

Example for the Implementation of an Interface Definition Component Usages Web Dynpro ABAP

The example below illustrates the principle of the interface definition and implementation by means of an actual development situation.

The static case described here is basically designed to demonstrate the principle; in the practice, it will be of limited use, because it requires all involved components of the using component to be known already at design time. And certainly, the implementation of interface definitions is most advantageous when this knowledge is missing at design time and the desired implementation of the interface is selected only at runtime. For more information on interface implementations, see the third part of this documentation: Dynamic Programming.

A central Web Dynpro component for travel expense management uses different components with related detail information, among them the components for flights, hotels and rented cars. In an interface definition IF_TRAVEL_COSTS a node is defined, which contains two attributes for open and paid costs.

After the interface definition IF_TRAVEL_COSTS has been implemented in all three detail components, their component controllers now have a context node Costs. Each of these components can include this node into its own controller implementation and fill it individually.

After all detail components of our example now have a separate interface, you can declare a usage of exactly this interface for the superior Travel Costs component.

As with a normal component usage an instantiation of the involved components is programmed in an appropriate method of this component (for example, the method WDDOINIT of the component controller after a usage has been declared for this controller as well).

method WDDOINIT. data: L_REF_CMP_USAGE type ref to IF_WD_COMPONENT_USAGE. L_REF_CMP_USAGE = WD_THIS->WD_CPUSE_USAGE_HOTELS( ). if L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) is initial. L_REF_CMP_USAGE->CREATE_COMPONENT( COMPONENT_NAME = 'HOTELS' ). endif. data: L_REF_CMP_USAGE2 type ref to IF_WD_COMPONENT_USAGE. L_REF_CMP_USAGE2 = WD_THIS->WD_CPUSE_ USAGE_FLIGHTS( ). if L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) is initial. L_REF_CMP_USAGE2->CREATE_COMPONENT( COMPONENT_NAME = 'FLIGHTS' ). endif. data: L_REF_CMP_USAGE3 type ref to IF_WD_COMPONENT_USAGE. L_REF_CMP_USAGE3 = WD_THIS->WD_CPUSE_ USAGE_CAR_RENTAL( ). if L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) is initial. L_REF_CMP_USAGE3->CREATE_COMPONENT( COMPONENT_NAME = 'CAR_RENTAL' ). endif. endmethod.

For each of these three instances, the content of the interface implementation is now available to the using component.

Example Context Mapping:

For the context of the component controller this means that a mapping can be defined to each of the three different implementations of the interface context node Costs. In the context of the component controller an appropriate node must be created for each mapping.

posts Working With Faceless Components Component Usages Web Dynpro ABAP

Features of Faceless Components

Faceless components are Web Dynpro components without graphical elements – that is, without windows or views. They only include a component controller; optionally, custom controllers can be added. You use faceless components to separate the data used in the framework of a large-scale programming project. They are designed exclusively for receiving and structuring data. By declaring a component usage you embed them into other components; they then supply the embedding component with the required data.

To create a faceless component, you create a new Web Dynpro component and delete the two visible elements – that is, the view and the window – from the object list.

Using Faceless Components Correctly

Whether or not to use a faceless component to separate the required data depends on the structure and size of the planned application. A faceless component is only useful if several other components access the same set of data. It does not make sense to create a faceless component for every application, because in less complicated cases the performance is better if you store the required data in the component controller of a central application component.

The usage of a faceless component and the subsequent mapping to its context node by the contexts of the using components also has logical consequences. Not only every change to the values of the context attributes is automatically propagated to all contexts involved in the mapping, but also properties such as the lead selection.