Référence de fichier JSON de schéma

1. Day0 : lorsque vous créez le système orchestré Tables d'application de base de données, le fichier schema.json initial est créé en fonction des paramètres d'intégration que vous entrez. Le fichier de schéma est créé avec les détails des tables et des colonnes contenant les données utilisateur pour les entités Compte, Habilitation et Recherche. Les informations sur la relation sont chargées à partir de la configuration que vous fournissez, ainsi que toutes les contraintes définies dans la base de données (clés primaires et étrangères). Par défaut, le fichier JSON de schéma intermédiaire contiendra un mapping pour les attributs suivants, s'ils sont définis. Pour mettre en correspondance des attributs supplémentaires, vous devez modifier le fichier schema.json :
   • UID : __UID__
   • Nom : __NAME__
   • Status : __ENABLE__
   • Password : __PASSWORD__
2. DayN : les activités DayN ont lieu à tout moment après la génération du fichier JSON de schéma intermédiaire. Le fichier par défaut créé par l'agent peut être utilisé pour le test, mais ne prend pas en charge le chargement complet des données car il n'apporte que des attributs d'UID et de nom. Pour un chargement complet des données, vous devez modifier le fichier afin de déterminer les entités et les attributs qui sont transmis à Oracle Access Governance. Pour obtenir des détails complets sur la structure et les options disponibles lors de la modification de schema.json, reportez-vous à Référence de fichier JSON de schéma.
   Remarque
   
   Après Day0, vous ne pouvez pas réexécuter le repérage de schéma sur la base de données source et générer un nouveau fichier de schéma. Le fichier JSON de schéma situé avec votre agent est la source d'informations fiables pour les activités DayN. Toutes les mises à jour doivent être effectuées dans le fichier.
   Les activités DayN peuvent inclure ce qui suit :
   1. Exécutez le chargement de données avec le schéma limité. Vous pouvez exécuter un chargement de données de test avec le schéma limité généré sur Day0. Cela inclut uniquement, le cas échéant, l'UID, le nom, le statut et le mot de passe des attributs.
   2. Modifier le fichier de schéma : vous pouvez modifier le fichier schema.json pour mettre à jour les détails de compte, d'habilitation et de recherche, le cas échéant. Voici quelques raisons pour lesquelles vous pouvez effectuer cette opération :
      • Vous souhaitez intégrer des attributs supplémentaires aux attributs uid, nom, statut et mot de passe par défaut. Pour ce faire, définissez la propriété name pour tous les attributs à inclure.
      • Si une modification est apportée à la base de données source, elle doit être reflétée dans le fichier de schéma. Par exemple, si vous ajoutez une nouvelle colonne dans la table ACCOUNT, elle doit être ajoutée au fichier de schéma en tant qu'attribut.
   3. Vous devez effectuer une opération de repérage de schéma pour extraire les dernières informations d'attribut personnalisé. Pour plus d'informations sur l'exécution de cette tâche, reportez-vous à Extraction des derniers attributs personnalisés.
   4. Pour appliquer une transformation sortante, vous devez la mettre à jour à partir de la console Oracle Access Governance. Aucune règle de transformation appliquée dans Schema.json ne sera prise en compte. Pour appliquer une règle de transformation, reportez-vous à Application de transformations sortantes pour les attributs d'identité. Toutefois, si vous modifiez l'attribut ou supprimez un attribut dans Schema.json, les règles de transformation, associées à cet attribut de compte particulier, sont supprimées lors de l'opération de repérage de schéma.
   5. Exécuter des opérations de chargement et de provisionnement des données : à l'aide du schéma repéré, chargez les données utilisateur dans Oracle Access Governance à partir de la base de données intégrée et autorisez Oracle Access Governance à provisionner des comptes et des droits d'accès dans la base de données intégrée.

Le fichier schema.json intermédiaire est généré à l'aide de toutes les informations disponibles dans la configuration que vous fournissez lors de la création du système orchestré. Il s'agit d'un modèle dans lequel vous pouvez apporter toutes les modifications qui affectent les données utilisateur que vous pouvez intégrer. La structure du fichier schema.json intermédiaire est la suivante :

{
 "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
                    ]
                }
            }
        ]
    }
  ]
}

Le schéma peut contenir des entités des types suivants :

• ACCOUNT : le type d'entité ACCOUNT est mis en correspondance avec l'entité Identité d'Oracle Access Governance. Les attributs du type d'entité ACCOUNT sont utilisés pour remplir une identité dans Oracle Access Governance.
• TARGETACCOUNT : le type d'entité TARGETACCOUNT mappe l'entité Compte Oracle Access Governance. Lorsque vous provisionnez un compte dans votre application de base de données, les attributs du type d'entité ACCOUNT Oracle Access Governance sont utilisés pour renseigner l'entité de base de données TARGETACOUNT.
• ENTITLEMENT : ENTITLEMENT est mis en correspondance avec Permission Oracle Access Governance.
• LOOKUP : LOOKUP met en correspondance les informations de consultation dans Oracle Access Governance.

Lorsque le fichier JSON de schéma intermédiaire est généré, il renseigne à la fois ACCOUNT et TARGETACCOUNT pour chaque utilisateur des tables de base de données. Cela se produit quel que soit le mode de configuration du système orchestré, de la source faisant autorité et/ou du système géré. Toutefois, lorsque le chargement de données est exécuté, les règles suivantes s'appliquent pour déterminer lesquelles de ces entités sont réellement créées dans Oracle Access Governance.

1. Le mode sélectionné est Source faisant autorité uniquement :
   • ACCOUNT et TARGETACCOUNT sont générés dans le fichier JSON de schéma.
   • Seule une identité est créée dans Oracle Access Governance, en fonction des valeurs de ACCOUNT.
   • TARGETACCOUNT peut être ignoré.
2. Le mode sélectionné est Système géré uniquement :
   • ACCOUNT et TARGETACCOUNT sont générés dans le fichier JSON de schéma.
   • Seul un compte est créé dans Oracle Access Governance, en fonction des valeurs de TARGETACCOUNT.
   • ACCOUNT peut être ignoré.
3. Le mode sélectionné est Source faisant autorité et Système géré.
   • ACCOUNT et TARGETACCOUNT sont générés dans le fichier JSON de schéma.
   • L'identité est créée dans Oracle Access Governance, en fonction des valeurs de ACCOUNT.
   • Le compte est créé dans Oracle Access Governance, en fonction des valeurs de TARGETACCOUNT.

La liste des attributs de base pouvant être affectés à une identité Oracle Access Governance est présentée ci-dessous. L'élément "nature": ["REQUIRED"] indique qu'un attribut doit avoir la valeur NOT NULL dans la base de données source. Cela ne signifie pas que l'attribut doit être inclus dans le repérage de schéma. Vous pouvez ou non l'inclure dans le schéma à intégrer.

[
  {
    "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"
    ]
  }
]

Vous configurez également les valeurs booléennes suivantes pour le statut Activé/Désactivé :

• Valeur de statut du compte utilisateur activé : cette valeur est définie par défaut sur ACTIVE ou peut être définie comme n'importe quelle valeur de texte de la base de données qui correspond au statut Activé dans Oracle Access Governance. Par exemple, Y, Yes, true, etc.
• Valeur de statut de compte utilisateur désactivé : cette valeur est définie par défaut sur INACTIVE ou peut être définie comme n'importe quelle valeur de texte de la base de données qui correspond au statut Désactivé dans Oracle Access Governance. Par exemple, N, No, false, etc.

La mise en correspondance de la valeur de base de données avec le statut Activé/Désactivé d'Oracle Access Governance utilise la logique suivante :

• Si l'utilisateur a un statut qui est égal à la valeur de statut de compte utilisateur désactivé, il est marqué comme désactivé dans Oracle Access Governance.
• Si l'utilisateur a une autre valeur, il est supposé que l'utilisateur est activé et qu'il est marqué comme tel dans 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" ]
    } ]
  }, {

Notez les paramètres name et targetName pour les attributs répertoriés dans l'exemple. Dans tous les cas, le paramètre targetName est renseigné. En effet, ce paramètre est mis en correspondance avec le nom de colonne dans la base de données Oracle qui contient les informations utilisateur que vous intégrez. Ainsi, par exemple, nous avons FIRSTNAME, LASTNAME, DESCRIPTION, etc. Toutefois, le paramètre name n'est pas toujours renseigné. En effet, le paramètre name est corrélé à l'attribut du schéma du côté d'Oracle Access Governance. Si name est renseigné, ce paramètre est inclus dans le schéma Oracle Access Governance, par exemple :

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

Si name n'est pas renseigné, ce paramètre n'est pas inclus dans le schéma Oracle Access Governance. Dans l'exemple ci-dessus, le paramètre DESCRIPTION n'est pas inclus :

"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" ]
    } ]
  }

En outre, vous devez créer dans votre table principale ACCOUNT un champ contenant la valeur de votre code express. Dans cet exemple, vous pouvez avoir un attribut tel que account.homeCountry qui contient cette valeur. Cet attribut doit avoir une relation de clé étrangère avec votre table ACCOUNT. Par exemple :

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

Vous pouvez déterminer si un paramètre est mis en correspondance avec un attribut principal ou un attribut personnalisé. Si vous utilisez le nom d'attribut de base dans name, la valeur targetName correspondante est mise en correspondance avec l'attribut de base. Si name n'est pas le nom d'un attribut de base, la valeur targetName est mise en correspondance avec un attribut personnalisé. Par exemple, la colonne de base de données FIRSTNAME est mise en correspondance avec l'attribut de base firstName.

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

alors que la commande suivante met en correspondance FIRSTNAME avec un attribut personnalisé appelé foreName

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

.