Entity modeling for virtual entities
To begin the process of using virtual entities, you first need to query them from the catalog where a user can select one or more entities. Then, the request that Dataverse generates is the corresponding virtual entities for each finance and operations apps entity that you select.
When you first create a virtual entity for a finance and operations apps entity, the system tries to create each field in finance and operations apps in the corresponding virtual entity in Dataverse. Ideally, a one-to-one relationship exists, and every field that exists in the finance and operations apps entity would exist in the Dataverse entity. Usually, this scenario is the case unless a mismatch occurs in supported data types between finance and operations apps and Dataverse. If a mismatch occurs, then the translation steps that the system performs during the integration calls match those fields.
The following table shows data types in finance and operations apps and how they're modeled in Dataverse. Each type is specific, and large or minor differences might exist depending on the type.
For example, the system generates an enumeration (enum) in finance and operations apps as a global option set in Dataverse. However, the enum integer values between the two systems aren't guaranteed to be stable, and you shouldn't rely on them. Another example would be that the fields of Real type and Long type inside of finance and operations apps are modeled as decimal data types in Dataverse. Because a mismatch exists in the precision and scale between those two data types, you need to include other behavioral considerations. You can view these considerations on the Entity modeling page along with other information about data types and the conversion that's needed for each to be modeled.
For more information, see Entity modeling.
| Data type in finance and operations apps | Modeled data type in Dataverse |
|---|---|
| Real | Decimal Possible mismatch depending on scope of precision |
| Long | Decimal, where the precision equals 0 (zero) |
| Int | Integer |
| String (non-memo), String (memo) | String – single line of text. String – multiple lines of text |
| UTCDateTime | DateTime (DateTimeFormat, DataAndTime, DateTimeBehavior, TimeZoneindependent) An empty date (January 1, 1900, in finance and operations apps displays as a null value in Dataverse) |
| Date | DateTime (DateTimeFormat, DataAndTime, DateTimeBehavior, TimeZoneindependent) An empty date (January 1, 1900, in finance and operations apps displays as a null value in Dataverse) |
| Enum | Picklist The system generates finance and operations apps enumerations (enums) as global option sets in Dataverse. You can complete matching between the systems by using the External Name property of values. Enum integer values in Dataverse aren’t guaranteed to be stable between the systems. Therefore, you shouldn’t rely on them, especially if extensible enums exist in finance and operations apps because these enums also don’t have a stable ID. The system updates OptionSet metadata when someone updates an entity that uses the OptionSet. |
In addition to data types, other pieces are available to model for the virtual entities in Dataverse. The system translates entity keys from finance and operations apps into the Data Entity ID + the RecID to create a globally unique identifier (GUID) for each entity. Each entity key in finance and operations apps can have multiple fields of various data types, where Dataverse requires a string of each field. Therefore, in the translation and modeling of a particular entity, the system formats the fields on the entity key in a string of each key, concatenated by a pipe between them to create one string in Dataverse.
This string would resemble the following example: strfmt of entitykey1|strfmt of entitykey2 |strfmt of entitykey3... (max length of 255 characters)
Dataverse requires that each entity has a primary field; this field is possible by using the entity key. This primary field must be a single field of the string type, and you can use it in Dataverse when:
Default views that you create for an entity include a primary field.
Quick views on forms for an entity include the primary field.
lookups to another entity are added to a page and show the data from the primary field.
Because Dataverse uses the primary field this way, the primary field for a virtual entity in finance and operations apps also uses the entity key of the corresponding entity in finance and operations apps.
Another concept where you need to model data entities for the virtual entities is relations, which you turn on in Dataverse. In finance and operations apps, you would model relations as one-to-many or many-to-one relationships. In Dataverse, a schema name of a relationship exists, and you would resolve them by using the GUID of the related entity. However, to convert the relations for a finance and operations relationship, the system generates the relationship as a GUID string and then uses the primary key to connect them.
The system generates relationships when it generates the virtual entity. If other relationships are needed between the virtual entities and the native entities that exist only in Dataverse, then extra X++ code on the finance and operations apps entity is necessary for you to create and maintain those connections.