Creating and Activating a DAC Domain Policy

The procedure for creating and activating a DAC policy is described in detail in the following sections. As described earlier it is a bottom-up process.

• Creating a Query Definition:The Query Definition specifies the paths from the Root item through one or more Relationships to Leaf Items. It is accessed from the TOC folder Administration/Configuration.
• Creating a Derived Relationship Family (DRF):A Derived Relationship Family is an ItemType that contains a Query Definition and one or more relationship paths derived from this query known as Derived Relationships. It can also be found in the TOC folder Administration/Configuration.
• Defining Derived Relationships:Derived Relationships are related items on the “Derived Relationships” tab on the DRF. Each has a Name identifier and start/end points of the DAC Subdomain in the columns “Departure Item Type […]” and “Destination Item Type […]”.
• Persisting DAC Access Control Table (unidr_Relationships table):Once a Derived Relationship Family and its subdomain definitions are completed, the ‘unidr_Relationships’ table is populated with data to track all instances of the specified subdomain in the database. This may take quite a bit of time for large databases.
• Creating a DAC Definition (Policy):Once the Derived Relationship Family is persisted, we create a DAC Definition that applies DAC Access Rules for each DRF subdomain conditionally based on root item permissions and leaf item life cycle states.

An active DAC Definition automatically creates DAC Domains for all instances of the root item. Access is based on the Team attached to the root item and governed by the permissions set in the DAC Definition. DAC access is calculated based on the table of unidr_Relationship items which are automatically synchronized with the results of the Derived Relationship Family’s Query Definition.

Before using Domain Access Control, you must make sure that the Agent Service is running. Ensure that the Agent Service Conversion Processing Cycles are configured in the conversion.config file, with the appropriate DB and User filled in:

 <ProcessingCycles>

 <cycle DB="{db}" User="{user}" Interval="20000" MaxBatch="5"/>

 </ProcessingCycles>

Restart the Agent Service after making changes to the config file.

The Agent Service also executes Conversion Tasks generated during the persisting process to create the initial unidr_Relationship items.

You need to create a Query Definition in order to create a Derived Relationship (DR) Family. The DR Family Definition maps DR Family elements and non-root Query Items contained in the Query Definition, which are in turn used to create DAC Subdomain Policies. For information on how to create a Query Definition, refer to the Query Builder Guide. In this guide we will use the following example Query Definition:

A Derived Relationship (DR) Family describes the derived relationships between Aras Innovator items. Each Derived Relationship in a DR Family has its own destination ItemType and name. An individual DR is referred to as a DR Family Element. All DR Family elements share the same departure ItemType as determined by the Query Definition.

Use the following procedure:

1. In the Navigation Panel, click Administration>Configuration>Derived Relationship Families. The following menu appears:



2. Click Create New Derived Relationship Family. A screen like the following appears:



3. Enter a name for the derived relationship in the Name field.
4. Click the ellipses in the Query Definition field and select the Query Definition from the dropdown list. Once you click save you may not change the assigned Query Definition.
5. Save the Derived Relationship Family. Its state is now Preliminary. The Query Definition is claimed and the Departure ItemType is updated based on the Query Definition.

Click the New Derived Relationship icon



in the Derived Relationships section to create a Derived Relationship.



The Root Item Type name (in this case Project) appears automatically. It is not editable.

6. Enter the Derived Relationship name in the Name field of the Derived Relationship tab.
7. Click the Destination Item Type field. The ItemType search dialog box appears.



The dialog displays the ItemTypes associated with the Query Definition.

8. Select the Destination ItemType. In this example we select Part.
9. Repeat this process and add all necessary Derived Relationships.



10. Click the Query Definition icon in the sidebar to view the query definition.



11. Click on a Derived Relationship cell to map the Query Item to the Derived Relationship that you created on the previous screen.
12. Select the corresponding DR from the dropdown list.



Note
You can only specify Derived Relationships which have been created on the previous screen.
13. Once all Derived Relationships are mapped click save and then unclaim the DR Family.
14. From the Actions Menu, select the Activate action to promote the DR Family to the Active state. The status of the Derived Relationship changes to Persisting and the initial persistence of the DR Family begins. Conversion Tasks are created which will persist the DRs for each QD root item in the database. By default, 10 Departure Items (Can be configured by modifying the dr_DepartureItemsPerConvTask system variable) are processed per Conversion Task. When the last Conversion Task is finished, the DR Family is activated

Information relevant to the Persistence process can be viewed in the Persistence section of the Derived Relationship Family Form. Departure Items Persisted, % displays the percent of Departure Items that have been persisted. Departure Items Total Count provides the total number of Departure Items in the system. If there are errors during the persistence process, the Errors box is populated with information pertaining to the errors.

If all the Conversion Tasks succeed, the DR Family is automatically promoted to Active. You cannot edit the Derived Relationship Family once it is Active.

Data changes in the database may create a need to recalculate the DR data to keep it up to date. This is done through observers that react to each change made to the items associated with ItemTypes participating in the DR Family. When an observer catches a change, it updates (re-calculates) the persisted DR as needed. An update impacting one DR of a DR Family may necessitate an update of other DRs within the Family.

You can only deactivate a DR Family if it is not in active use. To deactivate a DR Family, select the Deactivate action from the Actions menu. Upon deactivation of a DR Family all the persisted Family DRs are deleted. The observers that have been activated for DR Family “participating ItemTypes” are deactivated. Deactivated DR Family can be deactivated and then activated again.

DRF remediation is a process of resolving denormalized data when the denormalized data gets out of sync with the primary data. This process can be run either manually from the DRF action menu in Aras Innovator, or automatically at certain times of the day. Both manual and automatic DRF remediation assumes that the primary DRF data is not modified by end users during the duration of the DRF remediation process. (If this assumption is incorrect, DRF remediation process cannot be run.) Both manual and automatic remediation record the result of the undertaken remedial action in the Aras Innovator log files, and in the Conversion Tasks that are used to drive the DRF remediation process. How to do manual DRF Remediation?

Admin can do the Remediation for a specific DRF via

and Remediate action any time when it’s needed:

How to set up automatic DRF Remediation This functionality enables an Admin to configure the system to automatically recalculate and resolve issues with the Derived Relationship Families on a scheduled basis. Administrators should create a daemon process that will periodically check correctness of the system DRFs and perform required repairs when needed: The Agent Service should be set up as a prerequisite to this process (details are provided in 2.1 Prerequisites) Step 1 – Activate target DRF, that you need to Remediate on a regular (automatic) basis Step 2 – Install scheduler: run InstallService.bat from Scheduler folder on CD Image. For more details you can also refer to Aras Innovator 31 - Scheduler Service.pdf of the latest released build. Step 3 – Create the method with the following code where target DRF ID and departure_id is replaced with the correct values. var schedServ = this.newItem(“dr_RelationshipFamily”, “dr_RemediateDRs”); schedServ.setID(“target DRF id”); schedServ.setProperty(“departure_ids”, "*"); schedServ.setProperty(“is_auto_remediation”, “1"); return schedServ.apply();

Step 4 – Admin can change Innovator/Server/appsettings.json config file to see logs with the following information “MinimumLevel": “Fatal”, -> “MinimumLevel": “Information”.

By default, the automatic remediation process logs the fixes only, that are made in UNIDRs data. If User wants to log all UNIDRs values (even those ones that stayed the same) then dr_RemediationLoggingLevel Innovator Variable should be set to ‘verbose’. Step 5 – Information on the results of DRF remediation can be found in two places: Innovator log files Innovator\Server\logs\InnovatorServer_YYYYMMDD.log (Aras.DerivedRelationships.Loggers.RemediationProcessLogger), e.g.

Conversion Tasks used for remediation processing Open Conversion task that was created for this Remediation process and see the statistics for it in User data property, e.g.

<is_auto_remediation> - flag equals to ‘1’ that indicates the automatic run of remediation process, otherwise it does not exist <added_count> - quantity of records that was added during Conversion Task(s) execution <removed_count> - quantity of records that was deleted during Conversion Task(s) execution

When you create a DAC definition, you must specify the DAC Definition name and the Derived Relationship Family. Once you save this information, you cannot modify the definition to include a different DR Family. The DR Family defines the root ItemType of the DAC Definition. You need to create a Subdomain policy for each of the DR Family elements and the associated subdomains. The Subdomain name is the same as the corresponding Derived Family element. The ItemType for the subdomain items is the Derived Family element destination ItemType. You may then define a DAC Subdomain policy for each of the subdomains included in the DAC Domain definition. Once you create a DAC definition, you need to activate it. The following diagram shows the DAC Definition Lifecycle. When a DAC Definition is in the Preliminary state, it means that it is being created/edited. The appropriate DAC domains have not been created yet. In this state the DAC domain has no effect on access control. Once you create and validate a DAC Definition, the Administrator activates it. The corresponding DAC Domains are created dynamically using new root items. The Access Control logic takes this information into account when determining an access request. The procedure described in the following section is an example of creating a DAC Definition.

Use the following procedure to create the appropriate access permissions to be used for DAC Subdomain Policies.

1. In the Navigation Pane, click Administration>Permissions. The following menu appears:



2. Click Create New Permission. The following screen appears.



3. Enter the appropriate permission name in the Name field.

Click the Add Identities icon



on the Access tab to specify permissions for existing identities. Click the New Identities icon



to create an identity to associate with the Permission.



Note
If a Team is associated with the Domain Root ItemType (Project in our example), roles in the Subdomain permission need to match those in the team in order to take effect. Refer to the Creating Teams section in the Appendix for more information.

Click



to save and unclaim the Permission item.

1. In the Navigation pane, click Administration>Access Control>DAC Definitions from the TOC. The following menu appears:



2. Click Create New DAC Definition. The DAC Definition window appears:



3. Enter a name for the DAC Definition in the Name field.
4. Click the ellipses in the Derived Relationship Family field to select the appropriate DR Family.



Click



. The DAC Definition screen appears with links to the Derived Relationship Family and the Root ItemType defined in the DR Family.



Click the Editor icon



that appears in the left margin. A screen like the following appears. It highlights the Derived relationship associated with the DAC Definition.



5. Click the New Relationship icon to specify permissions for the DAC Definition.



6. Enter a number in the Priority field.
7. Click on the ellipses in the Subdomain Permission field and select a Permission. In Section 2.5, the example created was Part related to Project.



8. Click on the ellipses in the Root Permission field and select a Permission for the root. In this example, the Destination Life Cycle State is left empty to grant subdomain permissions to parts that have any Life Cycle state. If the Subdomain Policy should apply to a part in a specific Life Cycle State, click on the ellipses in the Destination Life Cycle State cell and select a Life Cycle State.
Note
A Subdomain Permission with an empty Destination Lifecycle State must have lower priority than a Subdomain Permission with a specified Destination Lifecycle with the same Root Permission.
9. Repeat this process for all Subdomains that should be mapped.
10. When complete, click saveand thenunclaimtheDAC Definition.

Once you have fully defined a DAC Definition and saved it, perform the following actions before activating it:

• Make sure that the underlying DR Family is active. If it isn’t you will not be able to activate the DAC Definition.
• Validate the associated Subdomain policies.

The following procedure is an example of activating a DAC Definition:

Open the DAC definition and click the Editor button



. A screen like the following appears:

1. Unclaim the DAC Definition and click the Promote Item icon. The Promote dialog box appears.



2. Select Active and click the green checkmark. The DAC Definition is now in Active state and all permissions are propagated.