Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Création d'un OData job SAP Reportez-vous à la section [Création de tâches ETL visuelles avec AWS Glue Studio](https://docs.aws.amazon.com/glue/latest/dg/author-job-glue.html) # Sources ODP (Operational Data Provisioning) L’ODP (Operational Data Provisioning) fournit une infrastructure technique que vous pouvez utiliser pour prendre en charge l’extraction et la réplication des données pour diverses applications cible et prend en charge les mécanismes Delta dans ces scénarios. Dans le cas d’une procédure Delta, les données d’une source (fournisseur ODP) sont automatiquement écrites dans une file d’attente Delta (Operational Delta Queue, ODQ) à l’aide d’un processus de mise à jour ou transmises à la file d’attente Delta à l’aide d’une interface d’extracteur. Un fournisseur ODP peut être un DataSource (extracteurs), des vues ABAP Core Data Services (vues ABAP CDS), SAP BW ou SAP BW/4HANA, un serveur SAP Landscape Transformation Replication (SLT) et des vues d'informations SAP HANA (vues de calcul). Les applications cible (appelées « abonnés » ODQ ou plus généralement « consommateurs ODP ») extraient les données de la file d’attente Delta et continuent à les traiter. ## Chargement complet Dans le contexte des entités SAP OData et ODP, un **chargement complet** fait référence au processus d'extraction de toutes les données disponibles d'une entité ODP en une seule opération. Cette opération extrait l'ensemble de données complet du système source, garantissant ainsi que le système cible dispose d'une up-to-date copie complète des données de l'entité. Les chargements complets sont généralement utilisés pour les sources qui ne prennent pas en charge les chargements incrémentiels ou lorsqu’une actualisation du système cible est requise. **Exemple** Vous pouvez définir explicitement l'`ENABLE_CDC`indicateur sur false lors de la création du DynamicFrame. Remarque : `ENABLE_CDC` est false par défaut, si vous ne souhaitez pas initialiser la file d’attente Delta, vous n’avez pas besoin d’envoyer cet indicateur ou de le définir sur true. Le fait de ne pas définir cet indicateur sur true entraînera une extraction de chargement complet. ``` sapodata_df = glueContext.create_dynamic_frame.from_options( connection_type="SAPOData", connection_options={ "connectionName": "connectionName", "ENTITY_NAME": "entityName", "ENABLE_CDC": "false" }, transformation_ctx=key) ``` ## Chargement incrémentiel Un **chargement incrémentiel** dans le contexte des entités ODP (Operational Data Provisioning) implique d’extraire uniquement les données nouvelles ou modifiées (deltas) du système source depuis la dernière extraction des données, en évitant ainsi de prétraiter les enregistrements déjà traités. Cette approche améliore considérablement l’efficacité, réduit les volumes de transfert de données, améliore les performances, garantit une synchronisation efficace entre les systèmes et minimise le temps de traitement, en particulier pour les grands jeux de données qui changent fréquemment. # Transferts incrémentiels basés sur des jetons Delta Pour activer le transfert incrémentiel à l’aide de la capture des données de modification (CDC) pour les entités compatibles ODP qui le prennent en charge, procédez comme suit : 1. Créez la tâche de transfert incrémentiel en mode script. 1. Lorsque vous créez le DataFrame or Glue DynamicFrame, vous devez passer l'option`"ENABLE_CDC": "True"`. Cette option garantit que vous recevrez un jeton Delta de la part de SAP, qui pourra être utilisé pour extraire ultérieurement les données modifiées. Le jeton Delta sera présent dans la dernière ligne du dataframe, dans la colonne DELTA\$1TOKEN. Ce jeton peut être utilisé comme option de connecteur lors des appels suivants pour récupérer de manière incrémentielle le prochain jeu de données. **Exemple** + Nous avons défini le `ENABLE_CDC` drapeau sur`true`, lors de la création du DynamicFrame. Remarque : `ENABLE_CDC` est `false` par défaut, si vous ne souhaitez pas initialiser la file d’attente Delta, vous n’avez pas besoin d’envoyer cet indicateur ou de le définir sur true. Le fait de ne pas définir cet indicateur sur true entraînera une extraction de chargement complet. ``` sapodata_df = glueContext.create_dynamic_frame.from_options( connection_type="SAPOData", connection_options={ "connectionName": "connectionName", "ENTITY_NAME": "entityName", "ENABLE_CDC": "true" }, transformation_ctx=key) # Extract the delta token from the last row of the DELTA_TOKEN column delta_token_1 = your_logic_to_extract_delta_token(sapodata_df) # e.g., D20241029164449_000370000 ``` + Le jeton Delta extrait peut être transmis en option pour extraire de nouveaux événements. ``` sapodata_df_2 = glueContext.create_dynamic_frame.from_options( connection_type="SAPOData", connection_options={ "connectionName": "connectionName", "ENTITY_NAME": "entityName", // passing the delta token retrieved in the last run "DELTA_TOKEN": delta_token_1 } , transformation_ctx=key) # Extract the new delta token for the next run delta_token_2 = your_logic_to_extract_delta_token(sapodata_df_2) ``` Notez que le dernier enregistrement, dans lequel le `DELTA_TOKEN` est présent, n’est pas un enregistrement transactionnel provenant de la source et n’est là que dans le but de transmettre la valeur du jeton Delta. Outre `DELTA_TOKEN`, les champs suivants sont renvoyés dans chaque ligne du dataframe. + **GLUE\$1FETCH\$1SQ** : il s’agit d’un champ de séquence, généré à partir de l’horodatage EPOC dans l’ordre dans lequel l’enregistrement a été reçu, et qui est unique pour chaque enregistrement. Il peut être utilisé si vous avez besoin de connaître ou d’établir l’ordre des modifications dans le système source. Ce champ ne sera présent que pour les entités compatibles ODP. + **DML\$1STATUS** : cela affichera `UPDATED` pour tous les enregistrements récemment insérés et mis à jour à partir de la source, ainsi que `DELETED` pour les enregistrements supprimés de la source. Pour plus de détails sur la façon de gérer l’état et de réutiliser le jeton Delta pour extraire les enregistrements modifiés à l’aide d’un exemple, reportez-vous à la section [Utilisation du script de gestion OData d'état SAP](sap-odata-state-management-script.md). ## Invalidation de jeton Delta Un jeton Delta est associé à la collection de services et à un utilisateur. Si un nouveau pull with initial `“ENABLE_CDC” : “true”` est lancé pour la même collection de services et pour le même utilisateur, tous les jetons delta émis à la suite d'une initialisation précédente seront invalidés par le service SAP OData . L’invocation du connecteur avec un jeton Delta expiré entraînera une exception : `Could not open data access via extraction API RODPS_REPL_ODP_OPEN` # OData Services (sources autres que le PDO) ## Chargement complet Pour les systèmes non ODP (Operational Data Provisioning), un **chargement complet** consiste à extraire le jeu de données du système source et à le charger dans le système cible. Étant donné que les systèmes non ODP ne prennent pas en charge par nature les mécanismes avancés d’extraction de données tels que les deltas, le processus est simple, mais peut nécessiter beaucoup de ressources en fonction de la taille des données. ## Chargement incrémentiel Pour les systèmes ou les entités qui ne prennent pas en charge **ODP (Operational Data Provisioning)**, le transfert de données incrémentiel peut être géré manuellement en mettant en œuvre un mécanisme basé sur l’horodatage pour suivre et extraire les modifications. **Transferts incrémentiels basés sur l’horodatage** Pour les entités non compatibles ODP (ou pour les entités compatibles ODP qui n’utilisent pas l’indicateur ENABLE\$1CDC), nous pouvons utiliser une option `filteringExpression` dans le connecteur pour indiquer l’intervalle `datetime` pendant lequel nous voulons extraire les données. Cette méthode repose sur un champ d’horodatage dans vos données qui représente la date à laquelle chaque enregistrement a été créé/modifié pour la dernière fois. **Exemple** Récupération des enregistrements modifiés après 2024-01-01T 00:00:00.000 ``` sapodata_df = glueContext.create_dynamic_frame.from_options( connection_type="SAPOData", connection_options={ "connectionName": "connectionName", "ENTITY_NAME": "entityName", "filteringExpression": "LastChangeDateTime >= 2024-01-01T00:00:00.000" }, transformation_ctx=key) ``` Remarque : Dans cet exemple, `LastChangeDateTime` est le champ qui représente la date de dernière modification de chaque enregistrement. Le nom du champ réel peut varier en fonction de votre OData entité SAP spécifique. Pour obtenir un nouveau sous-ensemble de données lors des exécutions suivantes, vous devez mettre à jour la valeur `filteringExpression` avec un nouvel horodatage. Il s’agit généralement de la valeur d’horodatage maximale des données précédemment extraites. **Exemple** ``` max_timestamp = get_max_timestamp(sapodata_df) # Function to get the max timestamp from the previous run next_filtering_expression = f"LastChangeDateTime > {max_timestamp}" # Use this next_filtering_expression in your next run ``` Dans la section suivante, nous proposerons une approche automatisée pour gérer ces transferts incrémentiels basés sur l’horodatage, ce qui évite ainsi de devoir mettre à jour manuellement l’expression de filtrage entre les exécutions.