Documentation Oracle Cloud Infrastructure

Référence d'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 de composant Composant
Exigences spécifiques à Oracle
Système Le système cible peut être une table de base de données à partir de l'un des SGBDR suivants :
  • Oracle Autonomous Database
  • Oracle Database 23ai, 19c, 18c ou 12c en tant que base de données unique, base de données pluggable ou implémentation Oracle RAC
  • Oracle Database 10g et 11g en tant qu'implémentation de base de données unique ou 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
Conditions générales
Format dans lequel les données utilisateur sont stockées dans le système

Vous ne pouvez utiliser un connecteur Database Application Tables 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 enfant. Ce système cible peut être configuré uniquement en tant que système géré et non en tant que source faisant autorité.
  • Toutes les données utilisateur se trouvent dans une vue unique pouvant être mise à jour (basée sur une ou plusieurs tables).
  • Les données utilisateur sont réparties entre une vue pouvant être mise à jour (qui repose sur une ou plusieurs tables) et une ou plusieurs vues enfant (qui sont basées sur une ou plusieurs tables). Ce type de système peut être configuré uniquement 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 enfant.
Autres exigences du système

Le système doit répondre 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, d'habilitation et de recherche. Les clés primaires composites ne sont prises en charge que pour les tables liant les tables d'habilitation et d'identité/de compte.

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

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

Modes pris en charge

Le système orchestré de tables d'application de base de données prend en charge les modes suivants :

  • Source faisant autorité
    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 dans les cas suivants :
    • Toutes les données utilisateur se trouvent dans une seule table ou vue OU
    • Toutes les données utilisateur se trouvent dans une vue unique pouvant être mise à jour (basée sur une ou plusieurs tables).
    .
  • Système géré
    Vous pouvez gérer les droits d'accès Database Application Tables dans les cas suivants :
    • Toutes les données utilisateur se trouvent dans une seule table ou vue OU
    • Toutes les données utilisateur se trouvent dans une vue unique 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 enfant. OU
    • Les données utilisateur sont réparties entre une vue pouvant être mise à jour (qui repose sur une ou plusieurs tables) et une ou plusieurs vues enfant (qui sont basées sur une ou plusieurs tables).

Configuration d'un utilisateur de service avec privilèges minimum

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 Oracle Access Governance et la base de données Database Application Tables (Oracle), vous pouvez créer un utilisateur de service disposant des privilèges minimum requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez votre système orchestré Database Application Tables (Oracle) en mode faisant autorité, vous devez accorder des droits d'accès en lecture à votre utilisateur de service sur la table contenant vos identités, afin qu'ils puissent être chargés dans Oracle Access Governance. Dans ce cas, l'ensemble minimal de droits d'accès requis est le droit d'accès SELECT sur la table contenant les informations d'identité ou de personne.

Par exemple :
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
où :
  • MYDBAT_PERSON : table de la base de données Oracle Database Application Tables contenant les informations d'identité.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis pour le mode Système géré

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

Par 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 Oracle Database Application Tables contenant les informations de compte.
  • MYDBAT_ROLES : table de la base de données Oracle Database Application Tables contenant les informations sur les rôles.
  • MYDBAT_GROUPS : table de la base de données Oracle Database Application Tables contenant les informations de groupe.
  • MYDBAT_PERSON_ROLE : table de la base de données Oracle Database Application Tables contenant des informations sur les rôles de personnes.
  • MYDBAT_PERSON_GROUP : table de la base de données Oracle Database Application Tables contenant des informations sur les rôles de groupe.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis 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 dans Développement de scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devez ajouter des droits d'accès aux procédures stockées ou aux 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 de service, vous ne devez pas exiger de droits d'accès. 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 droits d'accès appropriés.

Par 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 minimaux 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 (Database Application Tables), vous pouvez créer un utilisateur de service disposant des privilèges minimum requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez votre système orchestré Database Application Tables (MSSQL) en mode faisant autorité, vous devez accorder des droits d'accès en lecture à l'utilisateur de service sur la table contenant vos identités, afin qu'ils puissent être chargés dans Oracle Access Governance. Dans ce cas, l'ensemble minimal de droits d'accès requis est le droit d'accès SELECT sur la table contenant les informations d'identité ou de personne.

Par exemple :
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
où :
  • MYDBAT_PERSON : table de la base de données MSSQL (Database Application Tables) contenant les informations d'identité.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis pour le mode Système géré

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

Par 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 MSSQL (Database Application Tables) contenant les informations de compte.
  • MYDBAT_ROLES : table de la base de données MSSQL (Database Application Tables) contenant des informations sur les rôles.
  • MYDBAT_GROUPS : table de la base de données MSSQL (Database Application Tables) contenant les informations de groupe.
  • MYDBAT_PERSON_ROLE : table de la base de données MSSQL (Database Application Tables) contenant des informations sur les rôles de personnes.
  • MYDBAT_PERSON_GROUP : table de la base de données MSSQL (Database Application Tables) contenant des informations sur les rôles de groupe.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis pour les scripts personnalisés

Si vous souhaitez développer des scripts personnalisés pour les opérations sur l'intégration MSSQL (Database Application Tables) comme décrit dans Développement de scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devez ajouter des droits d'accès 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 de service, vous ne devez pas exiger de droits d'accès. 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 droits d'accès appropriés.

Par exemple :
GRANT EXECUTE ON OBJECT::dbo.GET_USERROLE TO SERVICEUSER;
où :
  • OBJECT::dbo : objet de base de données Microsoft MSSQL.
  • GET_USERROLE est le nom de la procédure stockée.
  • SERVICEUSER : utilisateur du compte de service.

Configuration d'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 Oracle Access Governance et la base de données Database Application Tables (MySQL), vous pouvez créer un utilisateur de service disposant des privilèges minimum requis pour configurer l'intégration.

Autorisations requises pour le mode source faisant autorité

Si vous configurez le système orchestré Database Application Tables (MySQL) en mode faisant autorité, vous devez accorder des droits d'accès en lecture à l'utilisateur de service sur la table contenant vos identités, afin qu'ils puissent être chargés dans Oracle Access Governance. Dans ce cas, l'ensemble minimal de droits d'accès requis est le droit d'accès SELECT sur la table contenant les informations d'identité ou de personne.

Par exemple :
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
où :
  • MYDBAT_PERSON : table de la base de données Database Application Tables (MySQL) contenant les informations d'identité.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis pour le mode Système géré

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

Par 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 Database Application Tables (MySQL) contenant les informations de compte.
  • MYDBAT_ROLES : table de la base de données Database Application Tables (MySQL) contenant des informations sur les rôles.
  • MYDBAT_GROUPS : table de la base de données Database Application Tables (MySQL) contenant les informations de groupe.
  • MYDBAT_PERSON_ROLE : table de la base de données Database Application Tables (MySQL) contenant des informations sur les rôles de personnes.
  • MYDBAT_PERSON_GROUP : table de la base de données Database Application Tables (MySQL) contenant des informations sur les rôles de groupe.
  • SERVICEUSER : utilisateur du compte de service.

Droits d'accès requis 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 (MySQL), comme décrit dans Développement de scripts personnalisés pour les tables d'application de base de données (Oracle) à l'aide de Groovy, vous devez ajouter des droits d'accès 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 de service, vous ne devez pas exiger de droits d'accès. 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 droits d'accès appropriés.

Par 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 des tables d'application de base de données

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

Le système orchestré de tables d'application de base de données 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
  • Révoquer le compte
  • Affecter un droit d'accès
  • Retirer 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
  • Déc.
  • REAL
  • DATE
  • TIMESTAMP

Pour Microsoft SQL Server

Les types de données pris en charge pour les opérations de rapprochement et de provisionnement d'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 d'un système orchestré de base de données MySQL sont les suivants :

  • BOOL
  • SMALLINT
  • MEDIUMINT
  • INT
  • BIGINT
  • FLOAT
  • DOUBLE
  • DECIMAL
  • CHAR
  • VARCHAR
  • TINYTEXT
  • DATE
  • DATETIME
  • TIMESTAMP

Attributs pris en charge par défaut

Etant donné que l'intégration des tables d'application de base de données nécessite le repérage de schéma et que le schéma repéré 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, le cas échéant. Vous devez inclure au minimum 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 mettre en correspondance des comptes avec des identités dans Oracle Access Governance, vous devez disposer d'une règle de mise en correspondance pour chaque système orchestré.

La règle de correspondance par défaut pour le système orchestré Tables d'application de base de données est la suivante :

Règles de correspondance par défaut
Mode Règle de correspondance par défaut
Source faisant autorité

Vérification de la correspondance des identités si les identités entrantes correspondent à une identité existante ou sont nouvelles

Valeur d'écran :

Employee user name = Employee user name

Nom d'attribut :

Identity.userName = Identity.userName

Système géré

La mise en correspondance des comptes vérifie si les comptes entrants correspondent aux identités existantes.

Valeur d'écran :

User login = Employee user name

Nom d'attribut :

Account.name = Identity.userName

Instructions 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.

Instructions générales

Toutes les tables d'accès à la base de données doivent respecter les règles suivantes :
  • Les colonnes Nom et Clé d'une 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 différentes colonnes si nécessaire.
  • Tout attribut de base inclus dans l'entité ACCOUNT doit respecter les règles suivantes :
    • Le type de données de 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 de 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. Pour plus d'informations, reportez-vous à la section suivante.

Relations de table

Les tables utilisateur qui sont mappées avec des entités ACCOUNT/TARGETACCOUNT peuvent avoir une relation avec les tables ENTITLEMENT et LOOKUP. Lorsque le connecteur Tables d'application de base de données effectue le repérage de schéma, il recherche d'abord les clés étrangères (FK) définies en tant que contraintes dans vos tables de base de données qui définissent la relation entre votre table utilisateur et vos tables ENTITLEMENT ou LOOKUP. L'exemple suivant illustre 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 Database Application Tables tente de faire correspondre 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 produit, 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 décrits ci-dessus pour la relation entre un utilisateur et une consultation s'appliquent lors de la définition de tables pour la relation entre un utilisateur et des habilitations.

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 d'attribut de compte.

  1. Connectez-vous à la console Oracle Access Governance et accédez à Administration des services → Systèmes orchestrés.
  2. Sélectionnez Gérer l'intégration pour le système orchestré DBAT où vous voulez associer un attribut d'identité à un attribut de compte.
  3. Sélectionnez Gérer dans la mosaïque des attributs de compte.
  4. Pour l'attribut de compte à mapper, sélectionnez Modifier l'attribut d'identité associé dans le menu d'actions.
  5. Sélectionnez l'attribut d'identité à associer à l'attribut de compte, puis cliquez sur Enregistrer. La valeur s'affiche désormais dans les colonnes Attribut d'identité associé de l'attribut de compte.

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

Les systèmes orchestrés DBAT prennent en charge les données d'affiliation via l'implémentation d'attributs à valeurs multiples (complexes) personnalisés.

L'affiliation est activée en ajoutant une table personnalisée pour l'affiliation requise et en la liant à la table des comptes. Par exemple, vous pouvez avoir une table de comptes, Users, semblable à la suivante :

Compte (par exemple, UTILISATEURS) → PK (USER_ID)
USER_ID USER_NAME FIRST_NAME LAST_NAME EMAIL Statut
1 USR001 Utilisateur Un userone@email.com ACTIVE
2 USR002 Utilisateur Two usertwo@email.com ACTIVE

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 intitulés de poste à une identité. Pour ce faire, créez une table Jobs similaire à la suivante :

Affiliation (par exemple, JOBS) → Clé primaire composite (USER_ID, JOBCODE)
CODE EMPLOI USER_ID NOM DU TRAVAIL DESCRIPTION
JB001 1 Un travail Ceci est un travail
1 Autre fonction Ceci est un autre travail
2 Un nouveau travail Ceci est un nouveau travail

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 le fragment 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 avec d'autres tables d'affiliation dans les paramètres d'intégration. Pour plus d'informations, voir Affiliations.