Cross-company behavior of data entities
This topic provides information about how data entities interact with the cross-company concept. To understand this aspect of data entities, you must understand how tables and views apply the cross-company concept. Therefore, this topic begins with a brief review of tables and views, and then explains how data entities are related.
Review of tables and views for cross-company
Each table has a SaveDataPerCompany property, and each view has a AllowCrossCompany property. The following table describes these two properties.
Comparisons within AllowCrossCompany = No
In the following screenshot, the CustomerList view has two data sources:
- Root – CustTable, which has its SaveDataPerCompany property set to Yes.
- Non-root – DirPartyTable, which has its SaveDataPerCompany property set to No.
The CustomerList view has its AllowCrossCompany property set to No, as shown in the following screenshot.
Given the preceding information about the CustomerList view, the system creates the view in the underlying SQL Server system by generating and then running the following SQL Create View statement.
CREATE VIEW [dbo].[CUSTOMERLIST]
AS
SELECT T1.accountnum AS ACCOUNTNUM,
T1.dataareaid AS DATAAREAID, -- AllowCrossCompany =No caused this line.
T1.partition AS PARTITION,
T1.recid AS RECID,
T2.partition AS PARTITION#2,
T2.name AS NAME
FROM custtable T1
CROSS JOIN dirpartytable T2
WHERE ( T1.party = T2.recid
AND ( T1.partition = T2.partition ) )
Making DirPartyTable the root data source
By swapping the positions of the two data source tables in the CustomerList view, you make the DirPartyTable table the root data source.
CREATE VIEW [dbo].[CUSTOMERLISTPARTY]
AS
SELECT T1.name AS NAME,
T1.partition AS PARTITION,
T1.recid AS RECID,
T2.partition AS PARTITION#2,
T2.accountnum AS ACCOUNTNUM
FROM dirpartytable T1
CROSS JOIN custtable T2
WHERE ( T2.party = T1.recid
AND ( T2.partition = T1.partition ) )
go
In this case, the SQL Create View statement is the same, except for the following two differences:
- The FROM clause mentions DirPartyTable first and CustTable second.
- The SELECT column list does not include the line for dataAreaId (because DirPartyTable has its SaveDataPerCompany property set to No.)
Limitations of tables and views
In some cases, the cross-company control features of tables and views aren't as granular control as you might require. Here are the limitations:
- Company or legal entity fields other than the system dataAreaId field can’t be recognized or treated automatically in the that way dataAreaId can.
- The cross-company behavior for views is too restricted to the properties of the root data source, even when non-root data sources have a dataAreaId field.
For example, this might happen if the legal entity information is in LegalEntityRecId, or if shared tables don't have a dataAreaId column.
Design time: Setting the PrimaryCompanyContext property
Data entities help you overcome the limitations of tables and view where cross-company functionality is concerned. Data entities have a PrimaryCompanyContext property, where you can specify the entity field to use for company identification. This property provides flexibility and granular control in the following ways:
- The field can be from any data source of the entity and isn't limited to fields of the root data source.
- The field can be any field that is extended from the DataAreaId extended data type (EDT), and isn't limited to an underlying system dataAreaId field.
- You can use the PrimaryCompanyContext property even when the entity has only shared tables as its data sources, if this makes sense for your specific situation.
The following screenshot shows the value set for the PrimaryCompanyContext property on the FMCustGroupEntity entity.
When the PrimaryCompanyContext value is set to a non-empty value, the entity can't behave as a shared entity. The dataAreaId field is added to the SQL Create View statement.
CREATE VIEW [dbo].[FMCUSTGROUPENTITY]
AS
SELECT T1.custgroup AS GROUPNAME,
T1.description AS DESCRIPTION,
T1.dataareaid AS DATAAREAID, -- dataAreaId is added.
T1.recversion AS RECVERSION,
T1.partition AS PARTITION,
T1.recid AS RECID
FROM fmcustgroup T1
Run time: The behavior of data entities for cross company
In the context of X++ code, the cross-company behavior of data entities resembles the behavior of tables. If the PrimaryCompanyContext property for an entity has no value and is empty, the entity behaves like a shared table.
X++ when PrimaryCompanyContext is set
The following table describes the behavior of a data entity under CRUD access when the PrimaryCompanyContext property is set to a field value. Both X++ and OData accesses are described.
The following X++ code example accesses FMCustGroupEntity, which has its PrimaryCompanyContext property set to dataAreaId.
X++ when PrimaryCompanyContext is empty
When the PrimaryCompanyContext property is set on the data entity, a dataAreaId field is created in the view schema and mapped to the PrimaryCompanyContext field. The following table describes the behavior of a data entity under CRUD access when the PrimaryCompanyContext property is empty. Both X++ and OData accesses are described.
In the current example, the FMCustomerGroupGlobalEntity entity has no value assigned to its PrimaryCompanyContext property.
However, a dataAreaId field from the FMCustGroup table is mapped to the FMCustomerGroupGlobalEntity entity as a regular field that is named LegalEntity. In this example, the FMCustGroup table is the root data source for FMCustomerGroupGlobalEntity. However, we are using this dataAreaId field in an informal way that bypasses the automatic mechanisms of the system. All these details are shown in the following screenshot of the LegalEntity field.
Note
Although the terms legal entity and data entity both use the word entity, don't confuse them. Legal entities and data entities are two entirely different concepts. When the PrimaryCompanyContext property is empty, the SQL Create View statement usually contains no mention of a system dataAreaId column. However, in the current example, dataAreaId is "half-mentioned" because of the LegalEntity regular field on the data entity. This field is shown in the following SQL statement.
CREATE VIEW [dbo].[FMCUSTOMERGROUPGLOBALENTITY]
AS
SELECT T1.custgroup AS NAME,
T1.description AS DESCRIPTION,
T1.dataareaid AS LEGALENTITY, -- dataAreadId is named LegalEntity.
T1.recversion AS RECVERSION,
T1.partition AS PARTITION,
T1.recid AS RECID
FROM fmcustgroup T1
Purpose of this example
This example has two purposes:
- Show shared data by default, even though the backing table might be company-specific.
- Enable the consumer of the data entity to filter on or apply dataAreaId if this is required, by using the regular field that is named LegalEntity.
Test data
The following screenshot of the Table browser page shows the test data that is in the FMCustomerGroupGlobalEntity entity before the X++ test code is run.
X++ code
Here's how the X++ test code works with the shared entity:
- It accesses the data entity in shared mode for reads.
- It accesses the data entity with one specific company when a new record is created.
No comments:
Post a Comment