Support

Description

G-Delta will automatically prepare an Audit Report containing all detected changes between the database schema and the Project Version. Reports can also be requested ad hoc. An Org Admin or an assigned G-Delta Admin can review the report and decide which changes will be synced to the Project Version. 

This article provides detailed information on requesting an ad hoc report and making decisions for a received Audit Report. 

• Need to Create a G-Delta Configuration? Please see How to Create a G-Delta Configuration for a Project Version.
• Non-XTS Project?  Please see these articles as well: 
  • G-Delta (Non-XTS) Additional Project Setup Steps
  • G-Delta (Non-XTS) Recommended Steps for First-Time Audit

In This Article

• Audit Report Email Notification
• How to Manually Request an Audit
• How to Review and Manage an Audit Report
• Detailed Audit Report Example (Table Added)
  • Base Schema
  • Project Setup
  • Database Schema Changes
  • Step 1 - Select the G-Delta Configuration and Audit Report
  • Step 2 - Accept, Modify, or Reject Changes
  • Step 3 - Accept or Reject the Audit Report
  • Step 4 - Check the Project Version for Accuracy
• Additional Audit Examples
  • Example 1 - Table Removed
  • Example 2 - Table Renamed

Audit Report Email Notification

Org Admins and assigned G-Delta Admin(s) will receive an email notification when a new Audit Report is available.

If the report is not received or you want to check the status of the G-Delta request, you can see this information in the terminal window for the G-Repository Server. 

How to Manually Request an Audit

Only one audit request can be submitted at a time. If an audit report has already been requested, this option will not be available until the current request is processed. It takes approximately three minutes to receive an Audit Report. 

IMPORTANT: Before submitting the request, please ensure the G-Repository Server is running and that it can access the database.

To request an audit outside of the defined Time Interval, complete these steps: 

1. Click on the G-Delta icon for the Project. 
2. Select the G-Delta Configuration within the Dashboard.
3. Select Request Audit.
   
   

How to Review and Manage an Audit Report

The provided audit report lists each detected change individually. You can decide about each change and then accept the report. The following sections of this article provide a detailed example and additional examples.

RECOMMENDED: Copy the Project Version before completing the Audit to leave the original Project Version available for your reference. Project Version Copy will create a copy of the current Project Version with the G-Delta Configuration and the Audit Report that needs to be reviewed. 

To review an Audit Report, you will need to do the following: 

1. Select the G-Delta Configuration.
2. Select the Audit Report in the Audit Summary pane. 
3. Review each detected change in the Audit Summary Detail pane and make a decision (accept, modify, or reject).
4. In the Audit Summary pane, Accept or Reject the full Audit Report. 
   • When accepting a report,  you may be prompted to choose to refactor to the current or new Project Version, depending on the change.
   • Accepted changes will be synced (refactored) to the Project Version. 
   • Be sure to check the Project Version after the process has been completed.  
   • Some manual tasks are still required after the changes are synced to the Project Version (e.g., Tuning Generators, changing the order of added Attributes, etc.). 
     
     

If you have chosen not to copy the Project Version ahead of time, you may see the prompt shown below after clicking the "thumbs up" icon to accept the Audit Report (Step 4 in the above image). 

The prompt below will automatically appear in certain refactoring circumstances. For example, when deleting a Domain or Attribute that has references may result in additional deletions within the Project Version during refactoring.

It allows you to enter a new Project Version number to initiate a Project Version Copy and sync the changes to the new Project Version, ensuring that the original version remains available for your reference. Please see the examples in this article to see how Table and Columns Additions/Deletions impact the Project Version during refactoring. 

Detailed Audit Report Example (Table Added)

This example will show how to make decisions and accept an Audit Report when a new table has been added to the database schema.

Base Schema

The following database schema will be used for this example: 

Project Setup

This example uses a basic project that contains the following: 

• Domains - User and Address
• User Domain Attributes - idUser, firstName, middleInitial, and lastName
• Address Domain Attributes - idAddress, street, city, state, zipCode, and userId
• Parent/Child Relationships - User Domain is the parent of the Address Domain.
• Receiver - DelimitedFileReceiver assigned to each Domain
• Scenario - A Scenario has been created for each Domain.
• Scenario Chain - Both Scenarios have been added to a Scenario Chain. 
• G-Cases - A G-Case has been created for the Load category and contains these two Domains. 

Database Schema Changes

• New Table - department (parent of the user table)
• Table Columns - id_department, dept_name, dept_phone
• New User Table Column- dept_id column
  • references id_department in the department table

Step 1 - Select the G-Delta Configuration and Audit Report

Select the G-Delta Configuration and the Audit Report in the dashboard to view detected changes and make decisions.

Step 2 - Accept, Modify, or Reject Changes

G-Delta will provide a recommended action within the Audit Summary Detail pane for each detected change. You can see these actions and make a decision. Available choices are:

• Accept (Thumbs Up) - The change will be applied to the Project Version.
• Modify (Wrench)  - Modify the action and apply the change to the Project Version. 
• Reject (Thumbs Down) - Do NOT apply the change to the Project Version.
  

When adding Domains, an additional icon will appear to the left of the wrench to view the new Domain's Attributes.

Detected Changes in the Audit Report (All accepted in this example)

• Add Department Domain
• Add Department Domain as parent to the User Domain
• Add deptId Attribute to the User Domain (reference)

Step 3 - Accept or Reject the Audit Report

Two options are available within the Audit Summary pane for a report: 

• Accept (Thumbs Up) - Accept the Audit Report and apply accepted changes to the Project Version. 
  • Only available when decisions have been made on all detected changes. 
• Reject (Thumbs Down) - Reject all changes for that Audit Report. No changes will be made to the Project Version. 

For this example, the user does the following: 

1. Accepts the Audit Report. 
2. Clicks Yes in the prompt. 
3. Clicks OK in the last prompt. 

The status will show "Executing" when the accepted actions are being synced with the Project Version.

The user receives an email notification once the process is completed. 

Step 4 - Check the Project Version for Accuracy

Once the process has finished, check the Project Version to ensure everything looks accurate. You can click on a Domain or Attribute within the Audit Summary Detail pane to see the change in the Project Version. 

Department Table Addition

• Department Domain added to the Project Version
• DelimitedFileReceiver assigned to Department Domain
• DepartmentScenario created for the Department Domain (contains User and Address Scenarios for referential integrity)
• DepartmentScenario added to the Scenario Chain.
• Department Domain is the parent of the User Domain.

New deptId Column in User Table

• deptId Attribute added to the User Domain
• deptId references the idDepartment Attribute in the Department Domain

Scenario Level References

• userId references idUser in the Address Scenario
• deptId references idDepartment in the User Scenario

G-Case Changes

• Department Domain has been added as a selectable option for G-Cases.
  
  

Additional Audit Examples

The examples below only contain Domains, Attributes, Receivers, Scenarios, defined Relationships, and G-Cases. Please note that if additional GenRocket components (G-Rules, G-Queries, G-Families, etc.) have been set up for that Project Version, they will also be impacted.

• Example 1 - Table Removed
• Example 2 - Table Renamed

Project Details

For this example, we imported an XTS file for a simple database schema (contains a user and address table). The Project Version contains the following: 

• Domains - Department, User, and Address
• Department Domain Attributes - idDepartment, deptName, and deptPhone
• User Domain Attributes - idUser, firstName, middleInitial, and lastName
• Address Domain Attributes - idAddress, street, city, state, zipCode, and userId
• Parent/Child Relationships - Department is the parent of the User Domain. The User Domain is the parent of the Address Domain.
• Receiver - DelimitedFileReceiver is assigned to each Domain
• Scenario - A Scenario has been created for each Domain.
• Scenario Chain - All Scenarios have been added to a Scenario Chain. 
• G-Cases - A G-Case has been created for the Load category and contains all three Domains.  

Base Database Schema

The above setup was performed using XTS for the schema shown below: 

Example 1 - Table Removed

In this example, the department table has been removed from the database. The following changes have been made to the database: 

• Foreign Key Relationship Removed - fK_dept_id_idx in the user table
• Column Removed - the dept_id column has been removed from the user table
• Table Dropped - the department table dropped from the database schema

Audit Report

For this example, the user accepts the recommended action for each detected change and then accepts the report.

Project Version Changes

• deptId Attribute 
  • Removed from the User Domain and User Scenario Domain. 
  • All references for the deptID Attribute have been removed as well.
• Domain Relationship Change - The Department Domain is no longer the parent of the User Domain.
• Department Domain - Domain has been removed from the G-Case. In this example, the Domain is not referenced by any other Domain in the G-Case and can be removed from the G-Case. A different action will be taken if it is referenced by another Domain or is the only Domain in the G-Case. 
• Department Scenario - Removed from the Project Version and the Scenario Chain.

Example 2 - Table Renamed

This example uses the same database schema as Example 1 above. The department table will be renamed to 'US_Departments'.

Audit Report

The G-Delta recommended action will be to delete the current Domain and add a new one with the new name. 

For renames, it is often best to modify the recommended action for the current Domain (i.e., department).

 Complete these steps to modify the recommended action:  

• Select the Wrench for the Department Domain - Delete Domain recommendation.
  
  
  
  
• Select Change Domain Name, select Domain Name, and click Save.
  
  
  
  
• Click Yes in the prompt to confirm. 
• Additional recommended actions will be rejected based on this selection (see below).
  
  
  
  
• One additional audit will be on the report to change the new deptId Attribute data type and is used to change the reference from 'department' to 'US_Departments.' This recommended action will be accepted as well.
  
  

Refactoring Results

• The Domain and Scenario Domain will now be named USDepartments. 
• Any references to that Domain will also be refactored to show the new name.