Context Mapping 

Web Dynpro controllers are independent programs that never normally share information with each other. To achieve access to the context of another controller, that controller must be declared as Required Controller.

Remember the guiding principles of Model View Controller (MVC) design. Only non-visual controllers can serve as data generators. View controllers can only serve as data consumers.

More information: Controllers Having No Visual Interface

Information held in the context of a non-visual controller can be made accessible to the context of another controller (view or non-visual) by a technique known as context mapping. Using this technique, two or more controllers can access the same runtime data.

When a mapping relationship is declared the context node acting as the consumer of data is known as the Mapped Node, and the context node acting as the data source is known as the Mapping Origin.

A mapped node can only refer to a single mapping origin node; however, a node acting as a mapping origin can be referred to by many mapped nodes.

Mapping Mechanism

Before a mapping relationship can be established, the following two criteria must be met:

●      There must be a suitable node available to act as a mapping origin

●      A context node must exist in the consuming controller

All context nodes are runtime objects that contain, amongst other things, a collection. When a mapping relationship is declared, the node collection of the mapped node is replaced by a reference to the node collection in the mapping origin node. In this manner, context mapping never causes data to be duplicated. There is only one copy of the data, and it lives in the collection belonging to the mapping origin node.

Now, when the coding in a view controller accesses the data in a mapped node, it has full read/write access to the data in the mapping origin node, as if it were accessing a node in its own local context.

It is perfectly permissible to create a context node that contains a mixture of mapped and unmapped attributes. In fact, this is a good design because even though data appears to belong to a single node, the attributes that hold the business data are mapped (i.e., they function as consumers of data from a non-visual controller), and the attributes holding data only concerned with the display of the business data are not mapped.

More Information

Specifying Dataflow