netweaver coding standards

8/13/2019 NetWeaver Coding Standards

http://slidepdf.com/reader/full/netweaver-coding-standards 1/10

1

Table of Contents

A. WebDynpro Programming Standards and Guidelines

1. Programming model

1.1 Naming Conventions ------------------------------------------------------------------- 2

1.2 WebDynpro Controllers ---------------------------------------------------------------- 3

1.3 Development Component (DC) based development --------------------------- 4

1.4 Context ------------------------------------------------------------------------------------- 4

1.5 WebDynpro Runtime API -------------------------------------------------------------- 5

2. User Interface ------------------------------------------------------------------------------------ 5

3. WebDynpro Colour scheme ----------------------------------------------------------------- 6

4. Performance Monitoring ---------------------------------------------------------------------- 7

5. General Tips ------------------------------------------------------------------------------------- 7

B. Portal Naming Guidelines ----------------------------------------------------------------- 8



2

WebDynpro Programming Standards and Guidelines

1. Programming model

1.1 Naming Conventions

General rules for Naming: Since the WebDynpro standards are based on the Java standards, the naming rules that applyfor Java, also apply for WebDynpro.

• Each coding entity name should start with an uppercase letter, and try to use assimple and concise terminology as possible.

• Each coding entity can consist of one or more nouns with first letter Capitalized.• Context name should use only the characters A..Z .a..z, 0..9 or _ , Use the digits only

form the second position• Application Name should reflect the business process name followed by App. The

initial letter should start with Upper case. Eg PackageSummary• Component name should start with uppercase and with suffix Comp or Component

(but avoid the suffix ‘_comp’).•

All Package names should be in lower case.• Methods should be verbs, in mixed case with the first letter lowercase, with the first

letter of each internal word capitalized Eg: addIntegers()• Variable name should be in upper case separated by underscore• Statements like for, while, if, switch, try catch follow the coding convention :

- Only one variable should be declared per line.- Local variables should be initialized when they are declared.- Variables should be declared only at the beginning of the block and same

variable name is not used in inner block.

WebDynpro Entity Rule for Naming Example

DevelopmentComponent Prefix <module name>_ Grm_UpiSearch

Application Suffix App DonorSearchApp

Component Suffix Comp (but no ‘_comp’) DonorSearchComp

Custom Controller Suffix Cust OVSCust

Model Suffix Model CustomerModel

Inbound Plug Suffix In DisplayDetailsIn

Outbound Plug Suffix Out CompletedOrderOut

Component InterfaceDefinition Prefix I combined with suffix

Comp (again no ‘_comp’)IDataProviderComp

Component Usage name of component +purpose of usage SearchCompDetails

View Suffix View MainView



3

Viewset Suffix ViewSet ActivitiesViewSet

Window Window name, no suffix Customers

Context

Nodes (cardinality x..1) singular BookingNodes (cardinality x..n) plural Orders

Supply functions prefix supply supplyDetails

Calculated attributes suffix Calc FullNameCalc

Used WebDynproComponents

UC_<name> UC_TFSearch

Activities act_<module>_<Briefdescription>_<date, time> @Onsite/Offshore

act_GRM_Changingexecution labels _ 10Sep 07 6:15 pm @Onsite

Packages wb.org.<module>.<name> wb.org.grm.upisearch

Simple Type ST_<name> ST_UpiField

1.2 WebDynpro Controllers

Any re-usable code used across different views of a DC should be written in the ComponentController or a Custom Controller. The code written in the View Controller should be restricted tothose related with the UI. No application logic should be written in an Interface Controller; instead

it should be used ONLY as a delegator.

• Don’t implement monolithic component controllers:Component controllers are automatically launched at component creation time (normallyon application startup). Therefore, component controllers containing extensive codingand declarations in their wdDoInit() methods will require a longer creation time. Only addcoding to a controller’s wdDoinit() method if the results of its execution are actuallyrequired at the start of the controller’s lifecycle.

• Use additional custom controllers to keep the component controller as efficient aspossible. Custom controllers should be used when you have identified a specific reusecase or when a distinct unit of functionality can be identified and separated from the maincomponent controller.

• Custom controllers are created on-demand . Therefore, moving functionality into a customcontroller will delay its initialization from the start of the component controller’s lifecycle tothe point in time when it is actually needed. This can reduce the time taken for acomponent to start.

• Optimize the View Controller’s lifespan- Use lifespan == framework controlled by default- Set lifespan == when_visible to improve memory performance.



4

Example : views that both require a lot of memory (for data and layout) and are(usually) used once and then not needed anymore.

1.3 Development Component (DC) based development

• Optimize the development performance with the best deployment granularity :o Keep the development components (WebDynpro DCs) as slim as possible; but

do not make WebDynpro components too small the application might not performwell and the resulting ‘sea’ of components might reduce maintainability

o Do not make WebDynpro components too large, reusability would be reducedo Design DCs with maximum reuse in mind

• Split your WebDynpro Application into separate WebDynpro DCs :o Create a single root component which embeds and layouts separate UI

components .o Create a model component which is created by the root component and

referenced by the UI components (use component instance in referencing mode).o Create faceless (without any UI/View) WebDynpro components for exposing

libraries, images or services to other WebDynpro components.o All URLs (including server dependent ones) should be managed through a

configuration file. A separate DC should hold the configuration file and exposemethods for reading the entries.

o Place Models and Dictionaries in separate DCs. Centralize all dictionary typeswithin a WebDynpro application

• Keep UI components and faceless components independent of each other to be able toexchange the other part, if necessary

• Use the component interface controller as a delegator only. Do not implement applicationlogic within public methods of the component interface controller. Only delegate to thecorresponding methods of the component or custom controller (starting from NW2004sthe Interface controller does not provide an option to write custom code)

1.4 Context• No attribute should be declared directly under the Context. Instead create a 1..1 singleton

node and the necessary attributes should be added under that.• Do not declare mapped context elements when the target context belongs to the same

WebDynpro component and when it is used for non-visual purposes only (but not for databinding). Access the target context withwdThis.wdGet<target>Controller().wdGetContext() instead.

• Prefer defining singleton child nodes to non-singleton childnodes as singleton nodesminimize the memory footprint of a controller context at runtime.

• Do not make a context node in an interface controller a mapping origin node . Instead,map the component interface controller context to another controller within the samecomponent or use external mapping (isInputElement = true). So in the interface controllercontext:- No attributes would be directly under context- Any node accepting data from an outside DC would have the property

‘isInputElement’ set to true.- A node which has ‘isInputElement’ set to false should be mapped to the component

controller or a Custom controller.



5

1.5 WebDynpro Runtime API:The current WebDynpro API documentation for NW2004 can be accessed at the following URL:

http://help.sap.com/javadocs/NW04/current/wd/index.html

Only WebDynpro (WD) interfaces that begin with IWD and classes that begin with WD are part ofthe published WebDynpro API. Hence only use interfaces that start with IWD and classes thatstart with WD for the following reasons:

• Source-Code CompatibilityOnly for those types starting with IWD or WD the WebDynpro runtime developersguarantee that they will remain source-code compatible, meaning that older WebDynproapplications can run against a newer WebDynpro runtime after a rebuild. All otherclasses and interfaces are private and they do not belong to the API.

• Changes in Future ReleasesFurthermore, the internal interfaces and classes can and will change their semantics oreven disappear from support package to support package or release to release withoutfurther notice. There is no commitment to backward compatibility for these types in anyway. It may happen at any point in time, without prior warning, that the names, packagesor behavior of the non-public classes change. In addition, applications might no longer beable to access any other WebDynpro classes or interfaces in future releases at all!

Never ever hijack internal WebDynpro classes and interfaces

The prefixes wd, IWD or WD should not be used in application coding. The various forms of the“wd” prefix are used by the WebDynpro Tools during the generation of internal coding entities.Therefore it is very likely that a naming conflict would occur if user-defined names start with oneof the above prefixes.

2. User Interface

The UI elements should have a defined hierarchy of containers. No more than one UI elementshould be preferably added directly under the Root container. Instead have a meaningfulhierarchy of containers (Transparent Containers/Groups as applicable) and the remaining UIelements should be added under them.

• The auto-generated IDs of the UI elements should be preferably replaced bymeaningful Names. Eg: UPI_Container, Submit_Button etc.

• The hook method wdDoModifyView() should be used only for the following types ofcode:

- Adding parameters to Action Event handlers- Responding to runtime changes in the context structure

The hook method wdDoModifyView() should not be used for the following types of code:- Altering UI property values – use context binding instead- Changing the context in any way!- Creating or changing modifiable simple types- Storing UI element object references that you then attempt to- access outside this method

• The properties of dynamically created UI elements should be controlled throughcontext binding.



6

• Don’t store static references to UI elements in the View Controller• Don’t attempt to refer to static UI element references in any event handler or supply

function • Use IWDAction.setEnabled() to disable UI elements. Don’t enable/disable those UI

elements which are bound to an action, by binding their enabled property to acontext attribute of type boolean. Enable/disable the corresponding action objects

instead.

3. WebDynpro Colour scheme



7

4. Performance Monitoring

In order to determine the performance breakdown between the client and the server, add theparameter ‘sap-wdshowInfo’ to the URL and set it to any non-null value (e.g. “X” or “true”).Thebrowser then displays the following time values [ms] in the status line

Browser- parsing: time for parsing HTML- HTML: time for rendering HTML- JSBefore: time for processing JavaScript code

J2EE- Server side processing time: - Time to process and dispatch an incoming request to the WebDynpro Runtime- Time needed by the WebDynpro Runtime to process the complete phase model

Backend- Length of time for accessing the backend (executing model classes)

5. General Tips

• Deleting Cached filesAny code written to open a file on the server space should also ensure that the file is

deleted after the usage. Eg: The code currently used for Download to excel, IRISattachment functionalities

• Meaningful CommentsHave proper comments wherever necessary eg: for all the method definitions, placeswhere control flows between the different DC etc.

• Release JCO connections after a RFC callWhenever an RFC call is made, make sure to release the JCO connection after the RFCexecution (applicable for stateless RFC calls).wdContext.current<RFC_Name>_InputElement().modelObject().modelInstance().disconnectIfAlive();

• Try Catch blocksMake sure that all possible exceptions are caught & a corresponding meaningfulmessage is printed before the application is deployed to the Production box.

• Common trackAny new JDI track being created should be linked to the Common Track (WB_COMMON)and the existing DCs should be used for common functionalities (Eg: UPI Search, IRISattachment), instead of creating separate copies.



8

Portal Naming Guidelines

Ideally a single folder ‘Worldbank’ should be added at the root level of the Content Administrationtab. Any new Portal object should be created inside a hierarchical folder structure. The folderstructure should ideally be Worldbank Æ <Project Name> Æ <Module Name> Æ <Object type

folder> Æ Object. The folders created directly under the Module to hold different Object typesshould have the name as the Object type itself. A pictorial example is given in the next page.



9

Worldbank

iLAP

eTF

TFP

GRM

Pages

Worksets

Roles

iViews

TFP_TTL

TFP Approver

TFP_Summary

TFP Details

TFP_Page1

TFP Page n

TFP_iView 1

TFP iView n

Folder

Projects

Modules

netweaver coding standards

Documents