Configurer une connexion multicloud pour le lac de données Workday

Une connexion multicloud à Workday Data Lake vous permet d'interroger vos données Workday directement dans Google Cloud. Vous pouvez ensuite utiliser Lakehouse pour gérer l'accès à vos données fédérées et les analyser sans les copier ni les déplacer.

Cas d'utilisation

La connexion de Lakehouse au lac de données Workday permet de répondre à plusieurs cas d'utilisation clés :

  • Unifiez les données analytiques : mettez en corrélation les données Workday sur les ressources humaines et les rémunérations avec les donnéesGoogle Cloud , par exemple pour fournir du contexte aux ventes et aux quotas.
  • Exploitez l'écosystème Google Cloud : par exemple, utilisez le framework d'agent de Google avec BigQuery ML et les données RH Workday pour prédire la fidélisation des employés.
  • Diffusez des données en temps réel sans les copier : analysez les données Workday sur les achats et les comptes fournisseurs, ainsi que les données logistiques et d'inventaire stockées dansGoogle Cloud pour identifier les inefficacités de la chaîne d'approvisionnement et optimiser les coûts des fournisseurs.

Avant de commencer

  1. Consultez la présentation de Lakehouse pour comprendre comment Lakehouse gère l'accès aux données.
  2. Pour en savoir plus, consultez Accéder aux données multicloud.
  3. Consultez les catalogues compatibles pour vérifier la compatibilité.
  4. Découvrez comment utiliser les secrets Secret Manager régionaux pour vous authentifier auprès du lac de données Workday.
  5. Contactez vos administrateurs Workday Data Lake pour configurer l'authentification comme décrit dans ce document. Les administrateurs devront peut-être contacter l'assistance Workday pour activer l'accès au lac de données, ce qui peut prendre du temps.
  6. Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  7. Verify that billing is enabled for your Google Cloud project.

  8. Enable the BigLake, Secret Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the BigLake, Secret Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    11.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer l'accès multicloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Détails du catalogue acceptés

Ce document fournit des instructions pour configurer un lakehouse avec Workday Data Lake. Pour accéder à d'autres catalogues, consultez Catalogues compatibles.

Limites et points à noter

Tenez compte des points suivants lorsque vous accédez à un lac de données Workday :

  • Lecture seule : les catalogues fédérés dans Lakehouse sont des vues en lecture seule du catalogue distant. Pour créer, modifier ou supprimer des ressources, vous devez utiliser Workday directement.
  • Routage réseau : les connexions et les requêtes sont acheminées de manière sécurisée sur l'Internet public.
  • Fraîcheur des données : l'indicateur --refresh-interval détermine la fréquence à laquelle le lakehouse synchronise les métadonnées. La valeur doit être 0s (désactivée) ou au moins 300s (5 minutes). À mesure que le nombre d'espaces de noms et de tables dans un catalogue augmente, l'actualisation des métadonnées en arrière-plan prend plus de temps. Si l'actualisation précédente dépasse son intervalle planifié, le système ignore le cycle actuel et reprend à l'intervalle planifié suivant.
  • Colocation : pour éviter les problèmes de connectivité et minimiser la latence et les coûts de transfert de données, créez le catalogue fédéré et le secret régional dans la régionGoogle Cloud la plus proche de celle où réside votre instance Workday.

Workflow général

Pour accéder aux données multicloud dans Workday Data Lake, suivez ces étapes générales :

  1. Configurer la fédération : configurez l'authentification basée sur un secret et créez un catalogue fédéré dans Lakehouse.
    1. Dans Workday, créez un utilisateur du système d'intégration (ISU) et un client API pour les intégrations.
    2. Créez un secret dans Secret Manager avec vos identifiants d'API Workday.
    3. Créez un catalogue fédéré dans Lakehouse et accordez au compte de service du catalogue l'accès au secret.
  2. Vérifiez la connexion : assurez-vous que Lakehouse peut se connecter à votre catalogue distant et synchroniser les métadonnées.
  3. Interroger les données : exécutez des requêtes sur vos données fédérées à l'aide de BigQuery ou de Managed Service pour Apache Spark. Pour en savoir plus, consultez Interroger des données à distance.
  4. Configurer les autorisations : utilisez Identity and Access Management (IAM) pour gérer les utilisateurs autorisés à afficher et interroger les données fédérées.

Configurer la fédération

Pour interroger vos données, vous devez configurer un catalogue fédéré Lakehouse qui se connecte à votre lac de données Workday à distance.

Configurer l'authentification

La fédération nécessite une authentification auprès du lac de données Workday distant à l'aide d'identifiants stockés de manière sécurisée dans des secrets Secret Manager régionaux.

  1. Dans Workday, effectuez la configuration suivante :

    1. Créez un utilisateur système d'intégration (ISU) : exécutez la tâche Create Integration System User (Créer un utilisateur système d'intégration) pour créer un compte dédié que Lakehouse utilise pour synchroniser les ressources.
    2. Activez l'accès au lac de données Workday pour l'équipe d'assistance ISU : accordez-lui l'accès au lac de données Workday. Contactez l'assistance Workday pour activer cet accès. Vous ne pouvez pas effectuer cette étape vous-même. Attendez que Workday configure l'accès dans votre locataire Workday avant de continuer.
    3. Enregistrer le client API pour les intégrations : exécutez la tâche Enregistrer le client API pour les intégrations.
    4. Enregistrez l'ID client et le code secret : enregistrez l'ID client et le code secret OAuth pour l'étape suivante.
    5. Générez un jeton d'actualisation sans date d'expiration : dans le client API pour les intégrations, utilisez Gérer les jetons d'actualisation pour les intégrations afin de générer un jeton d'actualisation sans date d'expiration pour l'ISU.
    6. Enregistrez le jeton d'actualisation : enregistrez le jeton d'actualisation généré pour l'étape suivante.

  2. Créez un fichier JSON nommé credentials.json avec les données enregistrées à l'étape précédente :

    {
  "client_id": "CLIENT_ID",
  "client_secret": "CLIENT_SECRET",
  "refresh_token": "REFRESH_TOKEN"
}

    Remplacez les éléments suivants :

    • CLIENT_ID : ID client OAuth de votre client API Workday pour les intégrations.
    • CLIENT_SECRET : code secret du client OAuth de votre client API Workday pour les intégrations.
    • REFRESH_TOKEN : jeton d'actualisation sans expiration généré pour votre ISU Workday.

  3. Configurez le point de terminaison régional pour Secret Manager :

    Par défaut, Secret Manager utilise un point de terminaison mondial. Pour éviter les problèmes de connectivité et minimiser la latence et les coûts de transfert de données, créez votre secret et votre catalogue dans la même région. Pour remplacer le point de terminaison global par défaut par un secret régional, exécutez la commande suivante :

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/

    Remplacez les éléments suivants :

    • REGION : région Google Cloud où vous stockez votre secret Secret Manager. Exemple : us-east4.

  4. Importez la charge utile dans Secret Manager :

    gcloud secrets create WORKDAY_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json

  5. Supprimez le fichier credentials.json de manière sécurisée pour éviter toute fuite d'identifiants.

    Remplacez les éléments suivants :

    • WORKDAY_SECRET_NAME : nom unique de votre secret Workday dans Secret Manager, par exemple workday-api-credentials ou workday-data-lake-secret.
    • REGION : région Google Cloud dans laquelle vous créez le secret, par exemple us-east4.
    • PROJECT_ID : ID de votre projet Google Cloud .

Créer un catalogue fédéré

Pour créer un catalogue fédéré à l'aide de la CLI gcloud, exécutez la commande suivante :

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="workday" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME" \
    --workday-base-url="WORKDAY_BASE_URL" \
    --workday-tenant="WORKDAY_TENANT" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Remplacez les éléments suivants :

  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • REGION : région Lakehouse dans laquelle vous créez le catalogue fédéré, par exemple us-east4. Pour minimiser la latence et les coûts de transfert de données, sélectionnez la région Google Cloudla plus proche de votre instance Workday. Cette région doit être la même que celle où vous avez stocké votre secret.
  • WORKDAY_SECRET_NAME : nom de votre secret Workday dans Secret Manager.
  • WORKDAY_BASE_URL : URL de base de votre instance Workday. Par exemple, impl-services1.wd12.myworkday.com ou wd501.myworkday.com.
  • WORKDAY_TENANT : nom du locataire Workday.
  • REFRESH_INTERVAL : (facultatif) spécifie la fréquence de mise à jour des informations du catalogue. Définissez cette valeur comme une durée, par exemple 300s ou 5m. Les intervalles plus courts permettent de mettre à jour les données plus souvent, mais peuvent entraîner des coûts plus élevés en appels d'API. Des intervalles plus longs peuvent coûter moins cher, mais les données interrogées peuvent ne pas refléter votre ensemble de données le plus récent. Si elle est omise, l'intervalle d'actualisation est défini par défaut sur cinq minutes (300s). Si vous définissez la valeur sur 0s, l'actualisation des métadonnées en arrière-plan est désactivée.
  • NAMESPACE_FILTERS : facultatif : liste d'espaces de noms à fédérer, séparés par une virgule, par exemple finance,hr. Si elle est omise, Lakehouse inclut tous les espaces de noms.

Terminer la configuration de l'authentification

Une fois le catalogue créé, Lakehouse provisionne un compte de service unique pour celui-ci, identifié par biglake-service-account dans la description de la ressource.

Vous devez attribuer à ce compte de service le rôle Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) sur le secret que vous avez créé précédemment. L'application des nouvelles règles IAM peut prendre quelques minutes.

Console

  1. Dans la console Google Cloud , accédez à Lakehouse.

    [Accéder à Lakehouse][5]

  2. Cliquez sur le nom du catalogue fédéré que vous avez créé pour Workday.

  3. Sur la page Détails du catalogue, dans la bannière d'alerte, cliquez sur Accorder des autorisations pour le secret.

    Lakehouse attribue le rôle roles/secretmanager.secretAccessor sur le secret au compte de service provisionné.

CLI gcloud

  1. Accordez au compte de service du catalogue l'autorisation d'accéder au secret :

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding WORKDAY_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
      --role="roles/secretmanager.secretAccessor"

  2. Pour vérifier que le compte de service du catalogue fédéré a accès au secret, exécutez la commande suivante :

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy WORKDAY_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION"

    Dans le résultat, vérifiez que le compte de service biglake-service-account dispose du rôle roles/secretmanager.secretAccessor.

Remplacez les éléments suivants :

  • REGION : région Google Cloud dans laquelle vous stockez votre secret Secret Manager et avez créé le catalogue fédéré, par exemple us-east4.
  • WORKDAY_SECRET_NAME : nom de votre secret Workday dans Secret Manager.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.

Vérifier la connexion

Vérifiez que l'actualisation des métadonnées en arrière-plan s'est bien déroulée et que vos espaces de noms et vos tables ont été synchronisés.

  1. Vérifiez que l'état de l'actualisation indique que l'opération a réussi :

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

  2. Vérifiez que les espaces de noms sont synchronisés :

    gcloud alpha biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud .
  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.

Étapes suivantes