Node Cardinality 

At design time, you create the metadata structure within which the runtime data will live. All context nodes are collections, so there could potentially be multiple instances of each child node and attribute within a node’s collection at runtime.

The configuration of a node’s properties at design time critically affects the behavior of the node at runtime. If you do not really understand how a node’s design time properties can affect its runtime behavior, this can lead to the false impression that data is missing, or has somehow become lost, from the context node.

The number of elements in a node collection can be controlled using the cardinality property. This property defines how often a node is to be instantiated at runtime, i.e. how many elements of this node are available at runtime.

This property is actually the combination of the minimum and maximum number of elements the node collection may contain at runtime.

Cardinality	Description
0..1	No more than one element is instantiated. Zero elements are also permitted.
0..n	Any number of elements of the context node can be instantiated.
1..1	The node contains exactly one element instance; this instance is instantiated automatically.
1..n	At least one element must be instantiated, but beyond this, any number of elements can be instantiated.

Minimum Number of Elements

For those nodes that have their cardinality minimum set to 1, the node collection will be instantiated such that it already contains a single, empty element. This element is known as the default element.

For those nodes however, that have their cardinality minimum set to 0, then the node will be instantiated with an empty collection. The Web Dynpro developer must write the code first to create and then insert the first element into the collection.

Maximum Number of Elements

For those nodes that have their cardinality maximum set to 1, the node collection will be instantiated only once.

If the cardinality maximum is set to n, the node collections may contain any number of elements starting from the value specified by the cardinality minimum.

Example

The context node Vehicle is used to describe the fleet of a car rental company. It has the cardinality 1..n and is filled from a database table. A number of attributes of this node have a specific value for each vehicle.

The database table indicates that the company owns three vehicles, each with a unique registration date and unique license plate number. Thus, to display this table in the Web Dynpro application, three elements of the Vehicle context node must be instantiated.

The cardinality of the node Vehicle must be 0..n or 1..n.

If the Vehicle node is to be filled with values in the context of another function – for example, from a table of all currently available cars – the cardinality 0..n should be used since this table could be empty – that is, if all cars are rented out.

Violating the Cardinality Constraints

A node’s cardinality defines the minimum and maximum number of elements its collection may contain at runtime. It is most important that you do not write coding that attempts to violate these constraints. If you do, then a runtime exception will be raised that will probably abort your entire Web Dynpro application. Your Web Dynpro coding should anticipate and then avoid the following situations:

●      Delete the default element from a node whose minimum cardinality is 1

It does not matter explicitly which element is left in the node collection, as long as at least one element remains.

●      Add a second element to a node whose maximum cardinality is 1