Informations de référence sur l'intégration des tables d'application de base de données

Composants de tables d'application de base de données certifiés pour l'intégration à Oracle Access Governance

Les composants Database Application Tables que vous pouvez intégrer sont répertoriés ci-dessous.

Composants certifiés

Composants certifiés
Type du composant	Composant
Exigences particulières à Oracle
Système	Le système cible peut être des tables de base de données provenant de l'un des SGBDR suivants : Oracle Autonomous Database Mise en oeuvre d'Oracle Database 23ai, 19c, 18c ou 12c en tant que base de données unique, base de données enfichable ou Oracle RAC Oracle Database 10g et 11g en tant que base de données unique ou mise en oeuvre d'Oracle RAC
JDK	JDK 1.6 ou version ultérieure
Exigences spécifiques à Microsoft SQL Server
Système	Microsoft SQL Server 2016, 2017
Pilotes JDBC	Pour Microsoft SQL Server 2014 : sqljdbc4 version 4.0
Exigences spécifiques de Microsoft MySQL
Système	MySQL 5.x, MySQL 8.x
Pilotes JDBC	mysql-connector-java-5.1.12-bin
Exigences générales
Format dans lequel les données d'utilisateur sont stockées dans le système	Vous ne pouvez utiliser un connecteur de tables d'application de base de données que si les données utilisateur sont stockées dans le système cible dans l'un des formats suivants : Toutes les données utilisateur se trouvent dans une seule table ou vue. Les données utilisateur sont réparties entre une table parent et une ou plusieurs tables enfants. Ce système cible ne peut être configuré qu'en tant que système géré et non en tant que source faisant autorité. Toutes les données utilisateur se trouvent dans une seule vue pouvant être mise à jour (basée sur une ou plusieurs tables). Les données utilisateur sont réparties entre une vue modifiable (basée sur une ou plusieurs tables) et une ou plusieurs vues enfants (basées sur une ou plusieurs tables). Ce type de système ne peut être configuré qu'en tant que système géré et non en tant que source faisant autorité avec ce connecteur. En d'autres termes, une source faisant autorité ne peut pas stocker de données enfants.
Autres exigences du système	Le système doit satisfaire aux exigences suivantes : Si les tables parent et enfant ne sont pas jointes par une clé étrangère (par exemple, si vous utilisez des vues), les noms des colonnes de clé étrangère dans les deux tables doivent être identiques. La clé primaire de toutes les tables utilisées dans le système cible doit être fournie par une seule colonne pour les tables d'identité, de compte, de réserve et de consultation. Les clés primaires composites ne sont prises en charge que pour les tables reliant les tables de droits et d'identité/compte.

Modes de configuration pris en charge pour les intégrations de tables d'application de base de données

Les intégrations d'Oracle Access Governance peuvent être configurées selon différents modes de configuration selon vos besoins en matière d'intégration de données d'identité et de provisionnement de comptes.

Modes pris en charge

Database Application Tables Orchestrated System prend en charge les modes suivants :

Source de l'autorité source
Vous pouvez utiliser les tables d'application de base de données comme source d'informations d'identité faisant autorité (de confiance) pour Oracle Access Governance, où :
- Toutes les données d'utilisateur se trouvent dans une seule table ou vue OU
- Toutes les données utilisateur se trouvent dans une seule vue pouvant être mise à jour (basée sur une ou plusieurs tables).
.
Système géré
Vous pouvez gérer les autorisations Database Application Tables dans les cas suivants :
- Toutes les données d'utilisateur se trouvent dans une seule table ou vue OU
- Toutes les données utilisateur se trouvent dans une seule vue pouvant être mise à jour (basée sur une ou plusieurs tables) OU
- Les données utilisateur sont réparties entre une table parent et une ou plusieurs tables enfants. OR
- Les données utilisateur sont réparties entre une vue modifiable (basée sur une ou plusieurs tables) et une ou plusieurs vues enfants (basées sur une ou plusieurs tables).

Configurer un minimum d'utilisateurs de service privilégiés

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (Oracle)

Pour activer une connexion sécurisée entre la base de données Oracle Access Governance et les tables d'application de base de données (Oracle), vous pouvez créer un utilisateur de service avec les privilèges minimaux requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez votre système orchestré de tables d'application de base de données (Oracle) en mode faisant autorité, vous devez accorder des autorisations de lecture à votre utilisateur de service sur la table contenant vos identités, afin qu'elles puissent être chargées dans Oracle Access Governance. Le jeu minimal d'autorisations requis dans ce cas est l'autorisation SELECT sur la table contenant les informations d'identité ou de personne.

Voici un exemple :

GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;

où :

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations d'identité.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour le mode système géré

Si vous configurez votre système orchestré de tables d'application de base de données (Oracle) en mode système géré, vous devez accorder des autorisations de lecture et d'écriture pour les tables de comptes et les tables d'autorisations, afin de permettre le rapprochement, la création, la mise à jour et la suppression de comptes et d'autorisations de compte. Le jeu minimal d'autorisations requis dans ce cas est les autorisations SELECT, INSERT, UPDATE et DELETE sur les tables d'autorisations de compte et de compte.

Voici un exemple :

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;

où

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations sur le compte.
MYDBAT_ROLES : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations sur les rôles.
MYDBAT_GROUPS : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations sur le groupe.
MYDBAT_PERSON_ROLE : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations sur le rôle humain.
MYDBAT_PERSON_GROUP : Table de la base de données des tables d'application de base de données (Oracle) contenant les informations sur le rôle de groupe.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour les scripts personnalisés

Pour développer des scripts personnalisés pour les opérations sur l'intégration des tables d'application de base de données (Oracle), comme décrit sous Développer des scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devez ajouter des autorisations aux procédures stockées ou à d'autres objets de base de données référencés dans les scripts personnalisés. Si vous créez les procédures stockées à l'aide de l'utilisateur du service, aucune autorisation n'est requise. Si des procédures stockées ou d'autres objets de base de données sont créés dans un autre utilisateur, vous devez accorder les autorisations appropriées.

Voici un exemple :

GRANT EXECUTE ON MYDBAT_CUSTOMDEV.GET_USERROLE TO SERVICEUSER;

où :

MYDBAT_CUSTOMDEV : Utilisateur que vous avez utilisé pour créer la procédure stockée.
GET_USERROLE est le nom de la procédure stockée.
SERVICEUSER : Utilisateur du compte de service.

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (MSSQL)

Pour activer une connexion sécurisée entre Oracle Access Governance et la base de données MSSQL, vous pouvez créer un utilisateur de service avec les privilèges minimaux requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez le système orchestré des tables d'application de base de données (MSSQL) en mode faisant autorité, vous devez accorder des autorisations de lecture à l'utilisateur du service sur la table contenant vos identités afin qu'elles puissent être chargées dans Oracle Access Governance. Le jeu minimal d'autorisations requis dans ce cas est l'autorisation SELECT sur la table contenant les informations d'identité ou de personne.

Voici un exemple :

GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;

où :

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (MSSQL) contenant des informations d'identité.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour le mode système géré

Si vous configurez le système orchestré MSSQL (Database Application Tables) en mode système géré, vous devez accorder des autorisations de lecture et d'écriture pour les tables de comptes et les tables d'autorisations, afin de permettre le rapprochement, la création, la mise à jour et la suppression des comptes et des autorisations de compte. Le jeu minimal d'autorisations requis dans ce cas est les autorisations SELECT, INSERT, UPDATE et DELETE sur les tables d'autorisations de compte et de compte.

Voici un exemple :

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;

où

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (MSSQL) contenant les informations sur le compte.
MYDBAT_ROLES : Table de la base de données des tables d'application de base de données (MSSQL) contenant des informations sur les rôles.
MYDBAT_GROUPS : Table de la base de données MSSQL contenant des informations sur le groupe.
MYDBAT_PERSON_ROLE : Table de la base de données des tables d'application de base de données (MSSQL) contenant les informations de rôle humain.
MYDBAT_PERSON_GROUP : Table de la base de données des tables d'application de base de données (MSSQL) contenant des informations sur le rôle de groupe.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour les scripts personnalisés

Si vous voulez développer des scripts personnalisés pour les opérations sur l'intégration des tables d'application de base de données (MSSQL), comme décrit sous Développer des scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devez ajouter des autorisations aux procédures stockées ou à d'autres objets de base de données référencés dans vos scripts personnalisés. Si vous créez les procédures stockées à l'aide de l'utilisateur du service, aucune autorisation n'est requise. Si des procédures stockées ou d'autres objets de base de données sont créés dans un autre utilisateur, vous devez accorder les autorisations appropriées.

Voici un exemple :

GRANT EXECUTE ON OBJECT::dbo.GET_USERROLE TO SERVICEUSER;

où :

OBJECT::dbo : Objet de base de données MSSQL de Microsoft.
GET_USERROLE est le nom de la procédure stockée.
SERVICEUSER : Utilisateur du compte de service.

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (MySQL)

Pour activer une connexion sécurisée entre la base de données Oracle Access Governance et les tables d'application de base de données (MySQL), vous pouvez créer un utilisateur de service avec les privilèges minimaux requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez votre système orchestré de tables d'application de base de données (MySQL) en mode faisant autorité, vous devez accorder des autorisations de lecture à votre utilisateur de service sur la table contenant vos identités, afin qu'elles puissent être chargées dans Oracle Access Governance. Le jeu minimal d'autorisations requis dans ce cas est l'autorisation SELECT sur la table contenant les informations d'identité ou de personne.

Voici un exemple :

GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;

où :

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations d'identité.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour le mode système géré

Si vous configurez votre système orchestré de tables d'application de base de données (MySQL) en mode système géré, vous devez accorder des autorisations de lecture et d'écriture pour les tables de comptes et les tables d'autorisations, afin de permettre le rapprochement, la création, la mise à jour et la suppression de comptes et d'autorisations de compte. Le jeu minimal d'autorisations requis dans ce cas est les autorisations SELECT, INSERT, UPDATE et DELETE sur les tables d'autorisations de compte et de compte.

Voici un exemple :

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;

GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;

où

MYDBAT_PERSON : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations sur le compte.
MYDBAT_ROLES : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations sur le rôle.
MYDBAT_GROUPS : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations sur le groupe.
MYDBAT_PERSON_ROLE : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations sur le rôle de personnes.
MYDBAT_PERSON_GROUP : Table de la base de données des tables d'application de base de données (MySQL) contenant les informations sur le rôle de groupe.
SERVICEUSER : Utilisateur du compte de service.

Autorisations requises pour les scripts personnalisés

Si vous voulez développer des scripts personnalisés pour les opérations sur l'intégration des tables d'application de base de données (MySQL), comme décrit sous Développer des scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devrez ajouter des autorisations aux procédures stockées ou aux autres objets de base de données référencés dans vos scripts personnalisés. Si vous créez les procédures stockées à l'aide de l'utilisateur du service, aucune autorisation n'est requise. Si des procédures stockées ou d'autres objets de base de données sont créés dans un autre utilisateur, vous devez accorder les autorisations appropriées.

Voici un exemple :

GRANT EXECUTE ON MYSQLDB.GET_USERROLE TO 'SERVICEUSER';

où :

MYSQLDB : Base de données MySQL dans laquelle vous avez créé la procédure stockée.
GET_USERROLE est le nom de la procédure stockée.
SERVICEUSER : Utilisateur du compte de service.

Opérations prises en charge lors du provisionnement vers les tables d'application de base de données

Lorsque vous provisionnez un compte d'Oracle Access Governance vers les tables d'application de base de données, certaines opérations sont prises en charge.

Le système Database Application Tables Orchestrated System prend en charge les opérations de compte suivantes lors du provisionnement d'un utilisateur :

Créer un compte
Activer le compte
Désactiver le compte
Annuler le compte
Affecter une autorisation
Supprimer l'autorisation

Types de données pris en charge

Les types de données pris en charge pour les opérations de rapprochement et de provisionnement sont répertoriés dans la section suivante :

Pour Oracle Database

Les types de données pris en charge pour les opérations de rapprochement et de provisionnement d'un système orchestré Oracle Database sont les suivants :

VARCHAR2
CHAR
NUMBER
NUMERIC
INTEGER
INT
SMALLINT
DOUBLE
FLOAT
DECIMAL
DEC
REAL
DATE
TIMESTAMP

Pour Microsoft SQL Server

Les types de données pris en charge pour les opérations de rapprochement et de provisionnement pour un système orchestré de base de données Microsoft SQL Server sont les suivants :

CHAR
VARCHAR
SMALLINT
INT
BIGINT
DECIMAL
NUMERIC
NVARCHAR
FLOAT
REAL
SMALLDATETIME
DATETIME

Pour MySQL

Les types de données pris en charge pour les opérations de rapprochement et de provisionnement pour un système orchestré de base de données MySQL sont les suivants :

BOÎTE
SMALLINT
MEDIUMINT
INT
BIGINT
FLOAT
DOUBLE
DECIMAL
CHAR
VARCHAR
TINYTEXT
DATE
DATETIME
TIMESTAMP

Attributs pris en charge par défaut

Comme l'intégration des tables d'application de base de données nécessite la détection de schéma et que le schéma détecté n'est pas corrigé, il n'existe aucun attribut pris en charge par défaut spécifique en tant que tel. Vous pouvez modifier schema.json pour ajouter des attributs de base et personnalisés, au besoin. Au minimum, vous devez inclure les attributs uid et name requis pour une identité Oracle Access Governance telle que définie dans Attributs d'identité de base.

Règles de correspondance par défaut

Pour mapper des comptes à des identités dans Oracle Access Governance, vous devez disposer d'une règle de correspondance pour chaque système orchestré.

La règle de correspondance par défaut pour le système orchestré Database Application Tables est la suivante :

Règles de correspondance par défaut
Mode	Règle de correspondance par défaut
Source faisant autorité La correspondance d'identité vérifie si les identités entrantes correspondent à une identité existante ou sont nouvelles	Valeur d'écran : `Employee user name = Employee user name` Nom de l'attribut : `Identity.userName = Identity.userName`
Système géré La correspondance de compte vérifie si les comptes entrants correspondent aux identités existantes.	Valeur d'écran : `User login = Employee user name` Nom de l'attribut : `Account.name = Identity.userName`

Directives relatives aux tables d'application de base de données

Lorsque vous utilisez des tables d'accès à la base de données avec Oracle Access Governance, vous devez tenir compte des directives suivantes dans la conception et la structure de vos tables.

Directives générales

Toutes les tables d'accès à la base de données doivent respecter les directives suivantes :

Les colonnes Nom et Clé de toute entité doivent être configurées avec la valeur NOT NULL.
Pour une entité spécifique, la même colonne de base de données peut être configurée en tant que nom et clé. Vous pouvez également utiliser des colonnes différentes si nécessaire.
Tout attribut de base inclus dans l'entité ACCOUNT doit respecter les règles suivantes :
- Le type de données de la colonne doit être compatible avec le type de données côté gouvernance d'Oracle Access.
- Tout attribut configuré en tant que "nature":["REQUIRED"] dans le fichier JSON du schéma doit correspondre à un champ de base de données NOT NULL.
Les tables ENTITLEMENT et LOOKUP doivent avoir une contrainte de clé primaire sur les colonnes de clé.
Si les colonnes associées des tables ENTITLEMENT et LOOKUP correspondent, il n'est pas nécessaire de définir une relation de clé étrangère entre vos tables ACCOUNT/TARGETACCOUNT et les tables ENTITLEMENT et LOOKUP. Voir la section suivante pour plus de détails.

Relations de table

Les tables d'utilisateurs qui sont mappées aux entités ACCOUNT/TARGETACCOUNT peuvent avoir une relation avec les tables ENTITLEMENT et LOOKUP. Lorsque le connecteur Database Application Tables effectue la détection de schéma, il recherche initialement les clés étrangères (FK) définies en tant que contraintes dans les tables de base de données qui définissent la relation entre votre table utilisateur et vos tables ENTITLEMENT ou LOOKUP. Cela ressemble à l'exemple suivant pour la relation entre une table utilisateur et une table de consultation pour le pays de l'utilisateur :

CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   HOMECOUNTRY VARCHAR2,
   FOREIGN KEY (HOMECOUNTRY) REFERENCES MYDBAT_COUNTRY(COUNTRYCODE));

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)

Si aucune clé étrangère n'est définie, le connecteur des tables d'application de base de données tentera de mettre en correspondance les noms de colonne. Si les noms de colonne correspondent, la relation est mise en correspondance. Par exemple :

CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   COUNTRYCODE VARCHAR2);

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)

Toutefois, si aucune relation de clé étrangère n'est définie entre les tables et que les noms de colonne ne correspondent pas, une erreur est générée. Cela se produirait, par exemple, si vous définissez les colonnes comme suit :

CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   HOMECOUNTRY VARCHAR2);

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)

Les mêmes principes que ceux expliqués ci-dessus pour la relation entre un utilisateur et une consultation s'appliqueraient lors de la définition de tables pour la relation entre un utilisateur et des droits.

Associer un attribut d'identité à un attribut de compte

Vous pouvez associer un attribut d'identité à un attribut de compte en modifiant les paramètres de l'attribut de compte.

Connectez-vous à la console Oracle Access Governance et naviguez jusqu'à Administration du service → Systèmes orchestrés.
Sélectionnez Gérer l'intégration pour le système orchestré DBAT dans lequel vous souhaitez associer un attribut d'identité à un attribut de compte.
Sélectionnez Gérer dans la vignette des attributs de compte.
Pour l'attribut de compte à mapper, sélectionnez Modifier l'attribut d'identité associé dans le menu d'actions.
Sélectionnez l'attribut d'identité à associer à l'attribut de compte, puis cliquez sur Enregistrer. La valeur s'affichera désormais dans les colonnes Attribut d'identité associé pour votre attribut de compte.

Prise en charge de l'affiliation DBAT pour les attributs d'identité multivaleurs personnalisés

Les systèmes orchestrés par DBAT prennent en charge les données d'affiliation grâce à la mise en oeuvre d'attributs multivaleurs personnalisés (complexes).

L'affiliation est activée en ajoutant une table personnalisée pour l'affiliation requise et en la liant à la table de comptes. Par exemple, vous pouvez avoir une table de comptes, Utilisateurs, similaire à celle-ci :

Compte (par exemple UTILISATEURS) → PK (USER_ID)
USER_ID	USER_NAME	FIRST_NAME	LAST_NAME	COURRIEL	STATUT
1	USR001	Utilisateur	Un	userone@email.com	ACTIF
2	USR002	Utilisateur	Deux	usertwo@email.com	ACTIF

Ensuite, vous devez créer une table personnalisée pour l'affiliation que vous souhaitez représenter. Par exemple, vous pouvez avoir une affiliation qui vous permet d'affecter plusieurs titres d'emploi à une identité. Pour ce faire, créez une table Tâches similaire à celle-ci :

Affiliation (par ex. JOBS) → PK composite (USER_ID, JOBCODE)
CODE D'EMPLOI	USER_ID	NOM DE LA TÂCHE	DESCRIPTION
JB001	1	Un emploi	Il s'agit d'un travail
	1	Autre emploi	Ceci est un autre travail
	2	Un nouvel emploi	Il s'agit d'un nouvel emploi

La table Compte est directement liée à la table Affiliation par la clé primaire composite (USER_ID, JOBCODE).

Enfin, vous devez ajouter l'affilation au remplissage schema.json comme indiqué dans l'extrait de code suivant.

[
  {
    "type": "ACCOUNT",
    "name": "ACCOUNT",
    "displayName": "Account",
    "attributes": [
      {
        "name": "JOBS",
        "targetName": "JOBS",
        "displayName": "",
        "dataType": "",
        "nature": ["MULTIVALUED"],
        "usage": [
          "READ"
        ],
        "relationship": {
          "relatedTo": "__CUSTOM_COMPLEX__", // Indicates the custom relationship 
          "relatedBy": "", 
          "relationshipProperties": [
            {
              "name": "JOBCODE",
              "dataType": "TEXT",
              "nature": ["REQUIRED"] 
            },
            {
              "name": "JOBNAME",
              "dataType": "TEXT",
              "nature": ["REQUIRED"]
            },
            {
              "name": "DESCRIPTION",
              "dataType": "TEXT",
              "nature": []
            }
          ]
        }
      }
    ]
  }
]

Incluez ce nom de table ainsi que d'autres tables d'affiliation dans les paramètres d'intégration. Pour plus d'informations, voir Sociétés affiliées.

Documentation sur Oracle Cloud Infrastructure

Informations de référence sur l'intégration des tables d'application de base de données

Composants de tables d'application de base de données certifiés pour l'intégration à Oracle Access Governance

Composants certifiés

Modes de configuration pris en charge pour les intégrations de tables d'application de base de données

Modes pris en charge

Configurer un minimum d'utilisateurs de service privilégiés

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (Oracle)

Autorisations requises pour le mode source faisant autorité

Autorisations requises pour le mode système géré

Autorisations requises pour les scripts personnalisés

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (MSSQL)

Autorisations requises pour le mode source faisant autorité

Autorisations requises pour le mode système géré

Autorisations requises pour les scripts personnalisés

Configurer un utilisateur de service avec privilèges minimum pour les tables d'application de base de données (MySQL)

Autorisations requises pour le mode source faisant autorité

Autorisations requises pour le mode système géré

Autorisations requises pour les scripts personnalisés

Opérations prises en charge lors du provisionnement vers les tables d'application de base de données

Types de données pris en charge

Pour Oracle Database

Pour Microsoft SQL Server

Pour MySQL

Attributs pris en charge par défaut

Règles de correspondance par défaut

Directives relatives aux tables d'application de base de données

Directives générales

Relations de table

Associer un attribut d'identité à un attribut de compte

Prise en charge de l'affiliation DBAT pour les attributs d'identité multivaleurs personnalisés