5
AN INTRODUCTION TO SURROGATE KEY REPLACEMENT IN MICROSOFT DYNAMICS AX 2012
Note that the creation of a surrogate foreign key relationship automatically adds a field to the foreign
key table for you.
What problems do surrogate keys present to the UI?
Displaying surrogate keys
Unsuitability of displaying surrogate keys in the UI
Surrogate keys—and, in turn, surrogate foreign keys—are represented by RecIds (64-bit integers)
in Microsoft Dynamics AX 2012. In standard application scenarios, RecIds should not be displayed
to the user, because a RecId by itself does not provide useful or easily understandable
information. An alternative set of fields must be displayed in place of the surrogate foreign key.
Explicit and implicit surrogate key UI replacement
The general surrogate foreign replacement problem can be broken into two more specific
scenarios:
Explicit replacement (by the developer at design time)
Implicit replacement (by the kernel at run time)
Explicit replacement occurs during Form design, when the developer explicitly models a surrogate
key—or surrogate foreign key—to be replaced with a specified set of fields in the UI. Note that this
doesn’t preclude the kernel from assisting with the design-time experience. For example, dragging
a surrogate foreign key field onto a Form design will result in the appropriate default control being
used.
Implicit replacement occurs when the kernel is internally generating a non-modeled form (such as
a lookup), or when it is rendering pieces of the UI that are modeled by the developer to use
surrogate keys, but expose no metadata for picking replacement metadata (such as a Form
caption or Field Groups). In these cases, the kernel considers the context of the UI element and
automatically replaces it with the “best” set of replacement fields.
Editing surrogate foreign keys
Resolving a user-entered value into a related record
The user will not only see the surrogate foreign key replaced by a set of replacement fields, but
will also enter the surrogate key through the replacement fields. From the user’s perspective, he
or she is just entering values as though they exist on the foreign key table—however, what’s
actually happening is that the user is indirectly entering a surrogate foreign key by selecting a
record from the related table.
The kernel handles resolution of the user’s entered values into the appropriate related record and
then, in turn, sets the surrogate foreign key that the user is editing.
The uniqueness problem
Most of the time, a surrogate key will be replaced by the primary key table’s natural key (which
must be unique; see the definition in terms table). However, there are currently areas of the
application where a natural key that could be used to replace the surrogate foreign key either does
not exist, or would be inappropriate to display to the user (for example, too many fields). In this
scenario, if the user enters values that are not unique in the context of the replacement fields, it
will not be possible to automatically determine which record the user was referring to.
This issue is addressed by providing both the X++ developer and the end user a means of
disambiguating the entered data. In the case of the X++ developer, there is an X++ override
(more about this later) that lets the developer consider Form and control state to determine which
record the user was referring to. If the X++ developer doesn’t intervene, and if the user’s entered
评论0
最新资源