1. Day0: When you create the Database Application Tables (Oracle) orchestrated system, the initial schema.json file is created, based on the integration settings you enter. The schema file is created with details of tables and columns containing user data for Account, Entitlement, and Lookup entities. Relationship information is loaded from the configuration you supply, together with any constraints set in the database (Primary and Foreign keys). The intermediate schema JSON file will contain mapping for the following attributes by default, if they are defined. To map additional attributes you should edit the schema.json file:
   • UID: __UID__
   • Name: __NAME__
   • Status: __ENABLE__
   • Password: __PASSWORD__
2. DayN: DayN activities take place at any point after you have generated the intermediate schema JSON file. The default file created by the agent can be used for testing, but does not support full data load since it only brings UID and name attributes. For full data load you should edit the file to determine which entities and attributes get passed to Oracle Access Governance. For full details on the structure and options available when editing the schema.json, refer to Schema JSON File Reference.

   Note:

   Post-Day0 you cannot rerun schema discovery against the source database and generate a new schema file. The schema JSON file located with your agent is the source of truth for DayN activities, and any updates must be made in the file.
   DayN activities may include the following:
   1. Run dataload with the limited schema. You can run a test dataload with the limited schema generated on Day0. This will only include, where available, the attributes uid, name, status, and password.
   2. Modify schema file: You can modify the schema.json file to update Account, Entitlement, and Lookup details if required. Some reasons why you might do this are:
      • You want to onboard attributes additional to the default uid, name, status, and password ones. To do this, set the name property for any attributes you want to be included.
      • If there is a change in the source database then this should be reflected in the schema file. For example, if you add a new column into the ACCOUNT table, that would need to be added to the schema file as an attribute.
   3. You should perform a schema discovery operation which will fetch the latest custom attribute information. For details on how to perform this task, see Fetch Latest Custom Attributes.
   4. Run data load and provisioning operations: Using the discovered schema, load user data into Oracle Access Governance from the integrated database, and allow Oracle Access Governance to provision accounts and permissions in the integrated database.

The intermediate schema.json file is generated using all information available from the configuration you supply during orchestrated system creation. This serves as a template to which you can make any changes that affect the user data you can onboard. The structure of the intermediate schema.json file is as follows:

{
 "schemaTemplates":[
    {
        "type": "", // Type of entity "ACCOUNT", "ENTITLEMENT", "TARGETACCOUNT" or "LOOKUP"
        "name": "", // Name of entity
        "displayName": "", // display name of entity
        "data": {
            // Key-value pairs representing static lookup data if any, or else it will be missing from here.
        }
        "attributes": [
            {
                "name": "", // AG side Name of attribute
                "targetName": "", // Target side name of attribute
                "displayName": "" // Optional display name for the attribute which will be given priority if provided, else attribute name will be used for display name.
                "dataType": "", // Either of TEXT, DATE, NUMBER, DECIMAL_NUMBER, FLAG
                "nature": [ // One or more of "REQUIRED", "MULTIVALUED", "SENSITIVE". It can be missing from here if nothing applies.
                ],
                "usage": [ // One or more of "READ", "PROVISION". It can be missing from here if nothing applies.
                ],
                "relationship": { // Entity relationship details
                    "relatedTo": "", // Entity name in relationship with
                    "relatedBy": "", // Attribute to define the relation
                    "relationshipProperties": [ // Additional relationship properties
                        {
                            "name": "", // Name of additional attribute
                            "dataType": "", // Either of TEXT, DATE, NUMBER, DECIMAL_NUMBER, FLAG
                            "nature": [ // Only READ_ONLY is possible, or else it will be missing from here
                            ],
                            "uiProperties": { // ARMD if applicable, or it will be missing from here
                                "inputType": "" // Either of Auto, User, Admin
                                "widget": "", // Widget to use on UI i.e. Either of Text, Password, Number, Date, SelectOne, RepeatableFieldSet, CheckboxSet
                                "title": "", // Title to use on UI
                                "labelHint": "", // Labelhint to use on UI
                                "minLength": {SOME_POSITIVE_NUMBER},
                                "maxLength": {SOME_POSITIVE_NUMBER},
                                "defaultValues": [ // Default values if applicable, or it will be missing from here
                                ]
                            }
                        }
                    ]
                },
                "outboundTransformation": { // Outbound transformation script if applicable, or it will be missing from here
                    "script": "" // Script to execute for transformation
                },
                "uiProperties": { // ARMD if applicable, or it will be missing from here
                    "inputType": "" // Either of Auto, User, Admin
                    "widget": "", // Widget to use on UI i.e. Either of Text, Password, Number, Date, SelectOne, RepeatableFieldSet, CheckboxSet
                    "title": "", // Title to use on UI
                    "labelHint": "", // Labelhint to use on UI
                    "minLength": {SOME_POSITIVE_NUMBER},
                    "maxLength": {SOME_POSITIVE_NUMBER},
                    "defaultValues": [ // Default values if applicable, or it will be missing from here
                    ]
                }
            }
        ]
    }
  ]
}

The schema can contain entities from the following types:

• ACCOUNT: The ACCOUNT entity type maps to the Oracle Access Governance Identity entity. Attributes from the ACCOUNT entity type are used to populate an Identity within Oracle Access Governance.
• TARGETACCOUNT: The TARGETACCOUNT entity type maps Oracle Access Governance Account entity. When you provision an account in your database application, attributes from the ACCOUNT Oracle Access Governance entity type will be used to populate the TARGETACOUNT database entity.
• ENTITLEMENT: ENTITLEMENT maps to Oracle Access Governance Permission.
• LOOKUP: LOOKUP maps to Lookup information in Oracle Access Governance.

When the intermediate schema JSON is generated, it populates both ACCOUNT and TARGETACCOUNT for each user in the database tables. This happens regardless of whatever mode you configure the orchestrated system, authoritative source and/or managed system. However, when the dataload is run, then the following rules apply regarding which of these entities are actually created in Oracle Access Governance.

1. Mode selected is Authoritative Source only:
   • ACCOUNT and TARGETACCOUNT are generated in the schema JSON.
   • Only an Identity is created in Oracle Access Governance, based on the values of ACCOUNT.
   • TARGETACCOUNT can be ignored.
2. Mode selected is Managed System only:
   • ACCOUNT and TARGETACCOUNT are generated in the schema JSON.
   • Only an Account is created in Oracle Access Governance, based on the values of TARGETACCOUNT.
   • ACCOUNT can be ignored.
3. Mode selected is Authoritative Source and Managed System.
   • ACCOUNT and TARGETACCOUNT are generated in the schema JSON.
   • Identity is created in Oracle Access Governance, based on the values of ACCOUNT.
   • Account is created in Oracle Access Governance, based on the values of TARGETACCOUNT.

The list of core attributes that can be assigned to an Oracle Access Governance Identity are shown below. The element, "nature": ["REQUIRED"] indicates that an attribute must be NOT NULL in the source database. This does not mean that the attribute must be included in the schema discovery, you may or may not include it into the schema you want to integrate.

[
  {
    "name": "uid",
    "dataType": "TEXT",
    "nature": [
      "REQUIRED"
    ],
    "usage": [
      "READ"
    ]
  },
  {
    "name": "name",
    "dataType": "TEXT",
    "nature": [
      "REQUIRED"
    ],
    "usage": [
      "READ"
    ]
  },
  {
    "name": "email",
    "dataType": "TEXT",
    "nature": [
      "REQUIRED"
    ],
    "usage": [
      "READ"
    ]
  },
  {
    "name": "firstName",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "middleName",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "lastName",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "displayName",
    "dataType": "TEXT",
    "nature": [
      "REQUIRED"
    ],
    "usage": [
      "READ"
    ]
  },
  {
    "name": "employeeType",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "title",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "empNo",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "status",
    "dataType": "FLAG",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "jobCode",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "state",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "risk",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "location",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "department",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "managerUid",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "managerLogin",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "organizationUid",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "organizationName",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "country",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "postalCode",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  },
  {
    "name": "territory",
    "dataType": "TEXT",
    "usage": [
      "READ"
    ]
  }
]

You also configure the following boolean values for enabled/disabled status:

• User account enabled status value: This value will default to ACTIVE or can be defined as any text value from the database which maps to a status of enabled in Oracle Access Governance. Some examples include Y, Yes, true and so on.
• User account disabled status value: This value will default to INACTIVE or can be defined as any text value from the database which maps to a status of disabled in Oracle Access Governance. Some examples include N, No, false and so on.

Mapping from the database value to Oracle Access Governance enabled/disabled status uses the following logic:

• If the user has a status which equals the User account disabled status value value then the user will be marked as disabled in Oracle Access Governance.
• If the user has any other value then it is assumed that the user is enabled and the user is marked as such in Oracle Access Governance.

    "type" : "ACCOUNT",
    "name" : "ACCOUNT",
    "displayName" : "Account",
    "attributes" : [ {
      "name" : "joiningDate",
      "targetName" : "JOININGDATE",
      "displayName" : "",
      "dataType" : "DATE",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "",
      "targetName" : "LASTUPDATED",
      "displayName" : "",
      "dataType" : "DATE",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "firstName",
      "targetName" : "FIRSTNAME",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "email",
      "targetName" : "EMAIL",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "REQUIRED" ],
      "usage" : [ "READ" ]
    }, {
      "name" : "name",
      "targetName" : "__NAME__",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "REQUIRED" ],
      "usage" : [ "READ" ]
    }, {
      "name" : "uid",
      "targetName" : "__UID__",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "REQUIRED" ],
      "usage" : [ "READ" ]
    }, {
      "name" : "status",
      "targetName" : "__ENABLE__",
      "displayName" : "",
      "dataType" : "FLAG",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "salary",
      "targetName" : "SALARY",
      "displayName" : "",
      "dataType" : "DECIMAL_NUMBER",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "password",
      "targetName" : "__PASSWORD__",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "SENSITIVE" ],
      "usage" : [ ]
    }, {
      "name" : "country",
      "targetName" : "COUNTRYCODE",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ],
      "relationship" : {
        "relatedTo" : "A_COUNTRY",
        "relatedBy" : "COUNTRYCODE"
      }
    }, {
      "name" : "",
      "targetName" : "DESCRIPTION",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }, {
      "name" : "lastName",
      "targetName" : "LASTNAME",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ]
    } ]
  }, {

Note the name and targetName parameters for the attributes listed in the example. You will see that in all cases the targetName parameter is populated. This is because this parameter maps to the column name in your Oracle database which contains the user information you are integrating. So, for example, we have FIRSTNAME, LASTNAME, DESCRIPTION, and so on. The name parameter is, however, not always populated. This is because the name parameter correlates to the attribute in the schema on the Oracle Access Governance side. If name is populated, then that parameter is included in the Oracle Access Governance schema, for example:

"name" : "firstName",
"targetName" : "FIRSTNAME",

If name is not populated, then that parameter is not included in the Oracle Access Governance schema. In the example above the parameter DESCRIPTION is not included:

"name" : "",
"targetName" : "DESCRIPTION",

    "type" : "LOOKUP",
    "name" : "COUNTRY",
    "displayName" : "Country",
    "attributes" : [ {
      "name" : "uid",
      "targetName" : "__UID__",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "REQUIRED" ],
      "usage" : [ "READ" ]
    }, {
      "name" : "name",
      "targetName" : "__NAME__",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ "REQUIRED" ],
      "usage" : [ "READ" ]
    } ]
  }

Additionally, you should create a field in your main ACCOUNT table which holds the value from your lookup. In this example you might have an attribute something like account.homeCountry which holds this value. This attribute should have a foreign key relationship with your ACCOUNT table. An example might be:

    "type" : "ACCOUNT",
    "name" : "ACCOUNT",
    "displayName" : "Account",
    "attributes" : ...
{
      "name" : "country",
      "targetName" : "COUNTRYCODE",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ],
      "relationship" : {
        "relatedTo" : "COUNTRY",
        "relatedBy" : "COUNTRYCODE"
      }

You can determine if a parameter is mapped to a core attribute or a custom attribute. If you use the core attribute name in the name then the corresponding targetName value is mapped to the core attribute. If name is not the name of a core attribute, then the targetName value is mapped to a custom attribute. For example the following would map the database column FIRSTNAME to the core attribute firstName.

{
      "name" : "firstName",
      "targetName" : "FIRSTNAME",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }

while the following would map FIRSTNAME to a custom attribute called foreName

{
      "name" : "foreName",
      "targetName" : "FIRSTNAME",
      "displayName" : "",
      "dataType" : "TEXT",
      "nature" : [ ],
      "usage" : [ "READ" ]
    }

.