Web Dynpro Component Interface Defintions in Practice

1

Web Dynpro Component Interface Defintions in Practice

SAP NetWeaver ’04s

Bertram Ganz – NW ESI F UI – WDF4J – SAP AG

2

© SAP AG 2006, NW ESI F UI – WDF4J / Bertram Ganz / 2

Learning Objectives – Web Dynpro Component Interface Definitions

Define the AnatomyAnatomy of a of a Web Dynpro ComponentWeb Dynpro Component and its interfacesDefine a ComponentComponent UsageUsage RelatRelationionEmbed a ComponentComponent Interface Interface ViewView in a ViewContainerUIElementDefine a Public PartsPublic Parts and a DC Usage DC Usage relationDeclare an External Context MappingExternal Context Mapping relationUse ComponentComponent Interface Interface DefinitionsDefinitions to configure a used UI component implementation without code-modification (context-based dependency injection pattern)Invoke the IWIWDConfigurationDConfiguration Service API in your custom codeDesign a state-of-the-art Web Dynpro Web Dynpro aapplicationpplication architecturearchitecture usingmultiple components and component interface definitions

3


“Implement a Web Dynpro application for viewing Sales

Opportunities.

The application architecture must allow the replacement of the standard viewer UI

with a custom viewer UI.

This flexible UI must be based on configuration so that no re-deployment of

the application is required”.

Web DynproApplicationDeveloper

Customer

The Customer‘s Development Task

4


VERSION_01 – The Monolithic Component Dead End

„I just develop a single Web Dynpro

Component in a single DC and put itall together there.“

„He won‘t succeedwith this approach.

A single monolithiccomponent will never

ever fulfill thecustomer

requirement; that‘s a dead end!“

5


VERSION_01The MonolithicComponent DeadEnd

My UI + Cust UIModel

Model Interface

DC 1

DC 1 = LocalDevelopment~teched~cd354~so~vers01~itelo.com

Related Local Web Dynpro DCs

LocalDevelopment~teched~cd354~so~vers01~itelo.com

Why this Version is sub-optimal

This is a “bad” application architecture based on a single monolithic Web Dynpro component and should not be replicated.

VERSION_01 represents a typical starting point when developing a new Web Dynpro application based on a single component without knowing the powerful advantages of a multi-component architecture using component interface defintions.

No Root Component exists: the application must be started with two different application URLs

No separation of model and UI in separate components, no separation of concerns on a Web Dynpro component level.

Long turnaouround times to build, deploy and run a new component version as the complete DC must be rebuild every time.

6


Web Dynpro Components versus Web Dynpro DCs

Web Dynpro Components …

are the fundamental blocks which build Web Dynpro applications.

have a specific component architecture.

are the only unit of reuse in Web Dynpro

Web Dynpro Development Components (DCs)

are units for packaging, building and transportation in SAP's infrastructure (NWDI).

can have usage dependencies to entities in other DCs

1

2

3

4

5

7


Visual Facet

Web Dynpro Component Architecture

Web Dynpro ComponentView Composition

Window

Custom ControllerCustom

Controller

Window

View LayoutView

LayoutViewViewView

ControllerView

Layout

Window

Custom ControllerCustom

ControllerInterface View

Controller

Controller FacetComponent Interface ControllerComponent Interface View(s)

Model Interface

Custom Controller

ComponentController

1

m

1

n

1

1 1

Faceless Components

Do not expose Component Interface Views as the visual component facets

Examples: Model Components, Service Component exposing a certain service like reading configuration data to other components (like the Locator Component in VERSION_06, see slide 39)

Visual Components

Expose at least one Component Interface Views as the visual component facets

Web Dynpro components can optionally expose multiple component interface views

Model Usage

Web Dynpro Models are defined on project or Web Dynpro DC level, not inside a Component

To use a model inside a Web Dynpro Component a corresponding model usage relation must be defined.

8


The Drawbacks of Monolithic Components

Correctness

Scalability

Productivity

Reusability

2

Monolithic Components are contrary to the followingdevelopment principles …

Maintainability

Flexibility

Understandability

Composability

1

4

3

6

5

8

7

The major goal of this lesson is how to become a …

Web Dynpro COP (Component-Oriented Programmer)

9


VERSION_02 – Separating Model from UI Components

„How can I create separate UIsaccessing the same model?

When splitting the UI in separate UIComponents and DCs I must also

separate the Model to avoidredundancies.“

„That‘s good. He now starts thinking

in components.“

10


VERSION_02SeparatingModel from UI Components

My UI Cust UI

ModelModel Interface

DC 1 DC 2

DC 3

DC 1 = ...~teched~cd354~so~vers02~myui~itelo.com

DC 2=...~teched~cd354~so~vers02~custui~itelo.com

DC 3 =...~teched~cd354~so~vers02~model~itelo.com

Related Web Dynpro Sample DCsDC 1 = LocalDevelopment ~teched~cd354~so~vers02~myui~itelo.com

DC 2 = LocalDevelopment ~teched~cd354~so~vers02~custui~itelo.com

DC 3 = LocalDevelopment ~teched~cd354~so~vers02~model~itelo.com

Why this Version is sub-optimalNo Root Component exists: the application must be started with two different application URLs

Every UI component declares a component usage relation to the model component

In case both UI components exist at the same time at runtime (not the case in this example but possible in many other scenarios) they must both reference the same model component instance. Consequently they must enter the model component usage in referencing mode. This can only be achieved by implementing additional custom code.

As an alternative we apply external context mapping in VERION_04

The root component uses two separate UI component implmentation -> not loosely coupled with UI components

11


Visual Facet

Web Dynpro ComponentWeb Dynpro Component

The Interfaces of a Web Dynpro Component

Controller Facet

Components are theblocks which build Web

Dynpro Applications

1

ComponentInterface View(s)

5

ComponentInterface Controller

2Web Dynpro Application

6

ProgrammaticProgrammaticFacetFacet

MethodsEvents

3

DataData Binding Binding FacetFacet

(External) ContextMapping

4

Visual Visual FacetFacetStartup PlugsInbound PlugsOutbound PlugsExit PlugsSuspend PlugResume Plug

7

12


Component Usage Relations

ChildComponent

ChildComponent

ParentComponent

Component Usage

The parent component must explicitly define a component usage relationcomponent usage relationto embed another child component

It acts like a variablevariablereferring to component or component interface definition

At runtime it is associated with a concrete component component instanceinstance

usecomponent

13


Component Usage versus Component Instance

UIComponent

ComponentUsage

ModelComponentn1 1 1

IWDComponentUsage

Instance:Model

Component

At runtime the component usagecomponent usage is represented by an object of type IWDComponentUsageIWDComponentUsage.

It acts as a component factorycomponent factory for the creation and the destruction of a single child componentcomponent instanceinstance.

Design Time

RuntimeInstance:

UI Component

Instance:IWDCom-

ponentUsage

ComponentUsage

ComponentInstance

createComponent()

IWDExternal-API

14


Managing Component Lifecycles

Lifecycle Property of a Component Usage

createOnDemandcreateOnDemand: Web Dynpro Runtime automatically createsa component instance on demand (e. g. when thecomponent gets visible on the UI)

manualmanual: component instance lifecycle must be programmaticallymanaged by the the application developer using theIWDComponentUsageIWDComponentUsage-API

A Component Usages which points to a component interface definitions automatically has the lifecycle property manual. Because the Web Dynpro Runtime does not know the component implementation to be used it cannot create it itself on demand.

15


Components and Usage Relations

requires

Controller to Component Usage

=Usage of a

Component Usage

2

• LifecycleManagement

Controller to Component

Interface Controller=

Usage of a Component Interface

Controller

3

• Context Mapping• Serverside Eventing• Method Calls

Component to Component

=Component Usage

1

• Component Reuse• Separation of

Concerns• Emebedding

Interface Views

16


Web Dynpro DCs – Allowing Reuse and Extensibility

Package Web Dynpro Components into DevelopmentDevelopment ComponentsComponentsA development component is …– unit for packaging, building and transportation in SAP's infrastructure (NWDINWDI)– mapped to a project in the NetWeaver Developer Studio

Development Components can have usageusage dependenciesdependencies, which mustbe defined explicitly.Public PartsPublic Parts of a Development Component expose visible entities insidea DC to entities outside a DC.

ModelComponent

Web Dynpro DevelopmentComponent(DC)

Web DynproComponent

Public Part

17


DC Separation of Web Dynpro Entities

UIComponent

DC Usage RelationUI DC

ModelComponent

Public Part

Model DC

add to PP

Model Interface

Web Dynpro DC

Web Dynpro DC

The Public Part of a Model Component must expose the following entities

Model entity itself

Java Package comprising the model class files– com.itelo.teched.cd354.so.vers02.model.src

– Add Entity to Public Part: as Class

Java Folder comprising the metamodel files of the model classes– com/itelo/teched/cd354/so/vers02/model/src

– Advanced Entity Properties Rules for adding entities to public part Includes: *.wdmodelclass

The source files of the model classes should not be exposed within the public part

NOTE: For VERSION_04 and higher (applying external context mapping) we define another public part which does not expose the model component itself but only the model entity, the model classes and the model metamodel files

18


VERSION_03 – Adding a Root Component

„Starting different UIs with different application URLs is not

„configurable“!

I must create a single rootcomponent to visually embed my

two UI component interface views.

This root component can then bestarted with one application URL.“

„Exactly. Web Dynpro

Components caneasily be embedded

into viewcompositions using

the specialViewContainer-

UIElement.

19


VERSION_03Adding a RootComponent

My UI Cust UI

Model

Root

DC 4

DC 1 DC 2

DC 3Model Interface


DC 2 =...~teched~cd354~so~vers02~custui~itelo.com

DC 3=...~teched~cd354~so~vers02~model~itelo.com

DC 4 =...~teched~cd354~so~vers03~root~itelo.com




DC 4 = LocalDevelopment ~teched~cd354~so~vers03~root~itelo.com

Why this Version is sub-optimalEvery UI component declares a component usage relation to the model component

In case both UI components exist at the same time at runtime (not the case in this example but possible in many other scenarios) they must both reference the same model component instance. Consequently they must enter the model component usage in referencing mode. This can only be achieved by implementing additional custom code.

As an alternative we apply external context mapping in VERION_04

The root component still uses two separate UI component implmentation -> not loosely coupled with UI components

20


What‘s a Root Component

The Root Component of a Web Dynpro Application

Single point of entry for a component-based Web Dynpro application

Exposes component interfaces view(s) to Web Dynpro application(s) to be started in a Web Dynpro Client

Embeds other components like …UI components for user interactionModel componentReusable service components

Manages manualmanuallifecycles of used components

My UI Cust UI

Model

Root

Model Interface

21


Emebdding Component Interface Views

Component Interface View

Visual interface of a Web Dynpro component which can be embedded in a Window like a conventional view.

To be embedded in a view layout using the ViewContainerUIElement.

RootView in View Designer

Window in Navigation Modeler

Web Dynpro Explorer

ComponentInteface View

ViewContainer-UIElement

22


VERSION_04 – Defining External Context Mapping

„How can I access model datain a UI component whithoutdefining a model component

usage?

I will apply external contextmapping instead to feed both UI components with model data.“

„Yes, that‘s a feasible alternative.

It is code-free and needs no model

component usage in the UI components.

But the model usageis still needed“

23


VERSION_04Defining ExternalContext Mapping

My UI Cust UI

Model

Root

Model Interface

DC 4

DC 1 DC 2

DC 3


DC 2 = ...~teched~cd354~so~vers04~custui~itelo.com



Related Web Dynpro Sample DCs

DC 1 = LocalDevelopment ~teched~cd354~so~vers04~myui~itelo.com




Why this Version is sub-optimal

The root component still uses two separate UI component implementation. Consequently it is not loosely coupled with the two UI component implementations

Controller code comprises hard-coded, fully qualified names of the UI component implementations

24


External Context Mapping

ExternalExternal ContextContext MappingMapping allows to map the interface context of a child component to the data context of the parent component.

ExternalExternal ContextContext MappingMapping PreparationPreparationThe „externally mappable“ context elements of the child component‘sinterface context must be defined as isInput=trueisInput=true elements.

ExternalExternal ContextContext MappingMapping DefinitionDefinitionThe context mapping relation is externally defined by the parentcomponent on a child component usage level.

Note

Top-level context attributes cannot be declared as input elements and arethus not externally mappable.

Define such attributes in a top-level context node with cardinality 1..1 instead.

How External Context Mapping is applied within a UI component

We apply external context mapping in VERSION_04 within the two UI components in Web Dynpro DCs …~vers04~myui~itelo.com and …~vers04~custui~itelo.com

With External Context Mapping you can skip the component usage of the model component within both UI components. The model component usage is therefor only defined within the root component.

What’s still needed in both UI components is the usage of the model entity (SalesOpportunityModel) itself. This model (with its related class and metamodel files) must be exposed in a public part of the model DC.

Why External Context Mapping is better then Referencing Mode

An alternative to external context mapping is the referencing mode of a model component usage. In this case both UI components itself declare a model component usage and then reference the singleton model component instance (managed by the root component), this means they enter the model component usage of the root component in referencing mode instead of creating their own model component instances.

As a referencing child component can mis-use the passed reference to the model component usage (e.g. destroying the related model instance again) we do not favor this approach.

25


ModelComponent

UI Component

External Context Mapping Chain in VERSION_04

RootComponent

ModelComponent Usage

UIComponent Usage

External Context Mapping

isInput=trueisInput=true

ComponentContext

ViewContext

ComponentInterface Context

ComponentContext

ComponentInterface Context

26


EXERCISE 1External Context

Mapping

VERS_0430 Minutes

Related Exercise Document

See SDN page SAP Developer Network (sdn.sap.com) Developer Areas: Web Application Server – Web Dynpro Code Samples: Sample Applications and Tutorials Web Dynpro Component Interface Definitions in Practice (42) –Exercises

Related Local Web Dynpro DCs

LocalDevelopment~teched~cd354~so~vers04~myui~itelo.com

LocalDevelopment~teched~cd354~so~vers04~root~itelo.com

What’s covered in this Exercise

Exposing a component to other Web Dynpro DCs with a Public Part definition.

Defining a Public Part Usage in a Web Dynpro DC.

Defining a component usage relation between root and UI components.

Defining an external context mapping relation from a child (UI component) to its parent component (root component).

27


VERSION_04 – Applying the Component Interface Strategy

„I must overcome the tightcoupling of the Root component

with the two UI components!

At design time I do not know thecustomer‘s UI component

implementation yet. I only knowthe contract it must fulfill.“

„Correct. WithComponent Interface

Definitionshe can apply the

Strategy Pattern in Web Dynpro.“

28


VERSION_05Applying theComponent Inter-face Strategy

My UIModel

Root <<CID>>IUI

Cust UI

DC 4 DC 5

DC 3 DC 1 DC 2

Component Interface Defition

Model Interface

DC 1=…~teched~cd354~so~vers05~myui~itelo.com



DC 5=…~teched~cd354~so~vers05~cid~itelo.com





DC 5 = LocalDevelopment ~teched~cd354~so~vers05~cid~itelo.com

Why this Version is sub-optimalAllthough the root component is now loosely coupled with the two separate UI component implementations via an abstract component interface definition (IUI), the controller code still comprises hard-coded, fully qualified names of the UI component implementations to create a UI component instance at runtime.

Stereotype <<CID>>CID = Component Interface Definition

29


Java Interfaces and the Strategy Design Pattern

Java Interfaces

In Java an interface is a type, just as a class is a type.

Like a class an interface defines methods but never implements them.

An interface is an abstraction of a class independent from its implementation.

<<interface>>IPayment

<<class>>Sale

CreditCardPayment

Cash Payment

<<class>>Sale

<<class>>CreditCard

Payment

<<class>>Sale

<<class>>Cash

Payment

Runtime

1

2

Design Time

30


Java Interfaces and the Strategy Design Pattern

The Strategy Design Pattern in Java

DefineDefine a a familyfamily of of algorithmsalgorithms, , encapsulateencapsulate eacheach oneone, and , and makemake themthem interchangeableinterchangeable. . StrategyStrategy letslets thethe algorithmalgorithm varyvaryindependentlyindependently fromfrom clientsclients thatthat useuse it.* it.*

It embodies two main OO design principles:encapsulate the concept that variesprogram to an interface, not an implementation.

GoodGood softwaresoftware = = looselyloosely coupledcoupled collectioncollection of of interchangeableinterchangeable partsparts

BadBad softwaresoftware = = monolithicmonolithic, , tightlytightly coupledcoupled systemsystem

Loose coupling makes your software much more extensible, maintainable, and reusable.

* Chapter 1 of the Gang of Four‘s (GOF) Design Patterns

31


Strategy Pattern and Component Interface Definitions

Component Interface Definitions (CIDs)

Allow decoupling Web Dynpro Components

Define a component interface without an implementationInterface can be implemented by one or more components

Benefits DecouplingComponent user can program against separately defined component interface (implementation is hidden)Component implementation can be provided (or selected) later on (plug-in concept)

<<CID>>ISalesOppUI

RootComponent

manage lifecycle

CustUIComponent

CustUIComponent

implement

MyUIComponent

MyUIComponent

ComponentComponentInterface DefinitionInterface Definition

((PrefixPrefix II))

32


Component Instance Creations at Runtime

RootComponent

ComponentUsage

<<CID>>ISalesOppUI

Design Time

Runtime

CustUIComp:Component

Instancet2

t1

RootComp:Component

Instance

IWDComp.Usg.:Component

Usage

MyUIComp:Component

Instance

implements

createComponent()

Why this slide is so important

Many Web Dynpro error scenarios a Web Dynpro application developer may encounter are based on a wrong understanding of the component usage entity

A component usage defined at designtime is not the component instance at runtime. Instead, the component usage points to the component instance.

A component usage acts as a component variable of a certain component type at design time. The component type can either be an implementing component or an abstract component interface definition.

At runtime the component usage acts as a component factory which is used to create or destroy the related component instance or to enter another component usage (of the same type) in referencing mode.

Important: Here we define a component usage of a component interface definition not a component usage of an implementing component.

A component usage of a component interface definition can at runtime point to different component instances implementing it.

33


Using Component Interface Definitions at Design Time

With a Component Interface Usage you can …

Embed component interface views

Define navigation plugs

Define context mapping relations

Subscribe to component interface events

Invoke the IExternalIExternal-API of the component interface in yourcustom code

This means, at design time you can …

work with a component interface definition in the same way like youwork with a component implementation.

34


//@@begin javadoc:wdDoInit()/** Component controller method. *///@@end

public void sortTable(){

//@@begin wdDoInit()

wdThis.wdGetITableViewer().sort();

//@@end}

Code Sample – Invoking the IExternal-API of a Used CID

Invoking the IExternal-API of a Used CID

<<CID>>ITableViewer

IExternalITableViewer

requires the definition of a component interface controller usagewithin the invoking controller

The method wdGetITableViewer() is automatically generated by the Web Dynpro Generation Framework.

It is added to the IPrivate-API (type of the shortcut variable wdThis) of a controller class as soon as a usage relation to the interface controller of a used component or a used component interface definition is defined.

In the above example the following entities are defined:– in component: usage relation to the component interface defintion with name ITableViewer

– in component controller: usage relation to the interface controller of the used component interface definition with name ITableViewer

35


CIDs and Component Lifecycle Management

Creating Component Instance for a CID Usage

Naturally a component usage which points to a CID (componentcomponentinterfaceinterface usageusage) has a manualmanual lifecycle.

To create a component instance for a component interface usageyou must pass the fully qualified component name to theIWDComponentUsageIWDComponentUsage--API:

public void createComponent(

java.lang.String componentName,

java.lang.String deployableObjectName)

36


Code Sample – Creating a Component Instance

Creating a Component Instance for a CID Usage//@@begin javadoc:createUICompInstance()/** Declared method. *///@@endpublic void createUICompInstance( ){

//@@begin createUICompInstance()IWDComponentUsage iSalesOppUICompUsg =wdThis.wdGetISalesOppUIComponentUsage();

if (iSalesOppUICompUsg.hasActiveComponent())iSalesOppUICompUsg.deleteComponent();

iSalesOppUICompUsg.createComponent("com.itelo.teched.cd354.so.vers05.comp.myui.MyUIComp","itelo.com/teched~cd354~so~vers05~myui");

//@@end}

At runtime the component usage acts as a factory for component instances

37


Fully Qualified DC Name = Deployable Object Name

The deployabledeployable objectobject namename (fully qualified DC name ) of a deployed Web Dynpro DC can be read from the telnet console:

itelo.com/teched~cd354~so~verso~custui

DC name entered in the NW Dev Studio

deployableobject name

To start the telnet console create the following shortcut:– C:\WINDOWS\system32\telnet.exe localhost <port number>

Login as an Administrator

Enter jump 0

Enter add deploy

Enter list_app to list all deployed development components

38


F. Q. Component Name = Deployable Object Part Name

The deployabledeployable objectobject partpart namename (component name ) of a Web Dynpro component can be read from the component controller‘sProperties tab: <<packagepackage name>.<componentname>.<component namename>>

com.itelo.teched.cd354.vers05.comp.custui.CustUIComp

39


VERSION_06 – Configuring UI Component Implementations

„Finally I eliminate the hard-codedcomponent instance creation.

To change the UI componentimplementation without modifying

the controller code I develop a Locator component whichdetermines the component

implementation configured by an Admin“.

„Congratu-lations, you

found the best solution:

DependencyInjection appliedto Web Dynpro Components!“

40


Model Interface My UIModel

Root <<CID>>IUI

Cust UI

DC 3 DC 5

DC 2 DC 1 DC 2

VERSION_06Configuring UI Component Im-plementations

Locator

DC 6

ComponentLocator

Related Web Dynpro Sample DCs

DC 1 = LocalDevelopment ~teched~cd354~so~vers05~myui~itelo.comDC 2 = LocalDevelopment ~teched~cd354~so~vers05~custui~itelo.comDC 3 = LocalDevelopment ~teched~cd354~so~vers02~model~itelo.comDC 4 = LocalDevelopment ~teched~cd354~so~vers06~root~itelo.comDC 5 = LocalDevelopment ~teched~cd354~so~vers05~cid~itelo.comDC 6 = LocalDevelopment ~teched~cd354~so~vers06~locator~itelo.com

Why this Version is is the best solution

Clear separation of concerns on the Web Dynpro component level.

Encapsulates model access in a separate model component

Applies component interface defintion for loosely coupling root component and UI component implementations

Applies external context mapping to access model data in the UI components

Locator Component: “out-sources” the retrieval of the fully qualified component names for the configured component implementations. Retrieves fully qualified component names from the database using the WDConfiguration service.

41


SAP J2EE Engine DB

Final Component Architecture

Model Interface

MyUICompModelComp

RootComp <<CID>>ISalesOppUI

Cust UIComp

LocatorComp

Administrator

DC 5

DC 2 DC 1 DC 2

DC 6

readconfigu-

ration

configure usedcomponent

implementation

DC 3

42


Using a Locator Component for Dependency Injection

What the Locator Component does …

Deploys the default configuration (fully qualified component name) of the component implementation to be used by the root component

Reads the configured component name from the database at runtime (IWDConfigurationIWDConfiguration-API, WDConfigurationWDConfigurationservice class)

Exposes the configuration data to the root component via itsinterface context. The root component can access this data basedon context mapping.

Context-based Dependency Injection

With this approach the root component has no designtime dependencyto the component implementation. The locator component injects thisdependency to the root component at runtime via context mapping.

43


Configuration Properties File

The configuration properties file uiCompImpl.propertiesuiCompImpl.properties isdeployed with the Web Dynpro DC comprising the LocatorComponent.

Two keyskeys--valuevalue pairspairs specify the fullyfully qualifiedqualified namename of the defaultcomponent implementation to be created at runtime.

Web Dynpro DC comprising the Locator Component

44


Code Sample – Reading Configuration Data

Reading a Configuration File with the WDConfiguration-API

LocatorComp.java

45


Code Sample – Reading Configuration Data (1)


try {// load configuration properties file.IWDConfiguration configuration =WDConfiguration.getConfigurationByName(

wdComponentAPI.getDeployableObjectPart(),"uiCompImpl");

…}

LocatorComp.java

1

Deployable Object Part: Locator component

NOTE: The configuration file is named uiCompImp.properties but the file extension is not passed to the WDConfiguration service: iCompImp

46




try {…// read configuration data.wdContext.currentConfiguredUICompImplElement()

.setDCName(configuration.getStringEntry(ConfigKey.DC_NAME));

wdContext.currentConfiguredUICompImplElement()

.setComponentName(configuration.getStringEntry(

ConfigKey.COMP_NAME));}

LocatorComp.java

2

47




…catch (WDInvalidConfigParameterException e) {

wdComponentAPI.getMessageManager().reportException(e.getLocalizedMessage(),

true);} catch (WDConfigurationNotFoundException e){

wdComponentAPI.getMessageManager().reportException(e.getLocalizedMessage(),

true);}

LocatorComp.java

3

48


Visual Admin – Configuring the Component Implmentation

The deployed configuration file can be edited in the Visual Visual AdministratorAdministrator using the ConfigurationConfiguration Adapter ServiceAdapter Service

Changing Configuration within the Visual AdministratorStart the Visual Administrator of your running SAP J2EE Engine by selecting the Windows menu item Start Programs SAP J2EE Engine – <instance number>

Visual Administrator

Login with the administrator’s user/password

Open the Configuration Adapter under the node Server Services.

In the work area open the tab Runtime Display configuration.Switch to Edit mode by pressing the edit button and confirm the next dialog.

Select the configuration property sheet uiCompImpl under the node Configurations webdynpro itelo.com teched~cd354~si~vers06~locator Components

com.itelo.teched.cd354.so.vers06.comp.exlocator.ExerciseLocatorCompPropertysheet uiCompImpl.You can edit a selected property sheet by pressing the edit button in the toolbar or via double-click.

Change the configuration properties compname and dcname from default to custom and press the button Apply custom.

The new configuration is now read after restarting the Web Dynpro application.

49


Refreshing the Configured Sales Opportunities Application

BrowserRefresh

The new configuration is read after restarting the Web Dynpro application.

Just refresh the browser and you can instantly see the result. The default UI component implementation is replaced with the custom UI component implementation.

No re-deployment or code-modification is required, just configuration.

50


EXERCISE 2Configuring the used UI

Component Implementation

VERS_0630 Minutes

Related Exercise DocumentSee SDN page SAP Developer Network (sdn.sap.com) Developer Areas: Web Application Server – Web Dynpro Code Samples: Sample Applications and Tutorials Web Dynpro Component Interface Definitions in Practice (42) – Exercises

Related Local Web Dynpro DCsLocalDevelopment~teched~cd354~so~vers06~root~itelo.com

LocalDevelopment~teched~cd354~so~vers06~locator~itelo.com

What’s covered in this ExerciseUnderstanding the component-oriented and DC-separated architecture of the SalesOpportunitessample application .

Defining a component usage relation to a Web Dynpro component interface definition.

Reading configuration data with the (I)WDConfiguration service API.

How to apply context-based dependency injection between a locator component and a CID (component interface definition) client component (here the root component).

How to create a component instance for a component usage of type ISalesOppUIComp (CID) at runtime.

Configuring the used component implementation in the Visual Administrator ( no code modification required).

51


Summary

Web Dynpro ComponentsWeb Dynpro Components are the key to extensible, reusable and manageable Web Dynpro software.

The NetWeaver Development InfrastructureNetWeaver Development Infrastructure provides functions for jointly developing professional, component-based Web Dynpro applications.

Web Dynpro Component InterfacesWeb Dynpro Component Interfaces are used to loosely couple client components with the implementing service components.

A Locator ComponentLocator Component is used to retrieve the fully qualified name of the configured component implementation at runtime (context-based dependency injection)

52


Web Dynpro DCs used for VERSION_01 to VERSION_06

A…~teched~cd354~so~vers06~root~itelo.com

…~teched~cd354~so~vers06~locator~itelo.com

…~teched~cd354~so~vers05~root~itelo.com

A…~teched~cd354~so~vers05~myui~itelo.com

…~teched~cd354~so~vers05~custui~itelo.com

…~teched~cd354~so~vers05~cid~itelo.com


…~teched~cd354~so~vers04~myui~itelo.com

…~teched~cd354~so~vers04~custui~itelo.com


A…~teched~cd354~so~vers02~myui~itelo.com

…~teched~cd354~so~vers02~model~itelo.com

A…~teched~cd354~so~vers02~custui~itelo.com

A…~teched~cd354~so~vers01~itelo.com

060504030201LocalDevelopment…

VERSIONDevelopment Component

* Those Web Dynpro DCs which are marked with A in the above table comprise Web Dynprapplications which can be started in a Web Dynpro HTML Client.

FinalFinalVersionVersion

Documents

Web Dynpro Component Interface Defintions in Practice