# Creación de un trabajo de SAP OData Consulte [Creación de trabajos de Visual ETL con AWS Glue Studio](https://docs.aws.amazon.com/glue/latest/dg/author-job-glue.html) # Orígenes de aprovisionamiento de datos operativos (ODP) El aprovisionamiento de datos operativos (ODP) proporciona una infraestructura técnica que puede utilizar para respaldar la extracción y replicación de datos para diversas aplicaciones de destino y admite mecanismos delta en estos escenarios. En el caso de un procedimiento delta, los datos de un origen (proveedor de ODP) se escriben automáticamente en una cola delta (cola delta operativa, ODQ) mediante un proceso de actualización, o se pasan a la cola delta mediante una interfaz de extracción. Un proveedor de ODP puede ser un DataSource (extractores), vistas de ABAP Core Data Services (vistas de ABAP CDS), SAP BW o SAP BW/4HANA, SAP Landscape Transformation Replication Server (SLT) y vistas de información de SAP HANA (vistas de cálculo). Las aplicaciones de destino (denominadas “suscriptores” de ODQ o, más generalmente, “consumidores de ODP”) recuperan los datos de la cola delta y continúan procesándolos. ## Carga completa En el contexto de las entidades OData y ODP de SAP, una **carga completa** se refiere al proceso de extraer todos los datos disponibles de una entidad ODP en una sola operación. Esta operación recupera el conjunto de datos completo del sistema de origen, lo que garantiza que el sistema de destino tenga una copia completa y actualizada de los datos de la entidad. Las cargas completas se suelen utilizar para orígenes que no admiten cargas incrementales o cuando es necesario actualizar el sistema de destino. **Ejemplo** Puede establecer la marca `ENABLE_CDC` de forma explícita en false al crear el DynamicFrame. Nota: `ENABLE_CDC` es false de forma predeterminada. Si no quiere inicializar la cola delta, no tiene que enviar esta marca ni establecerla en true. Si no se establece esta marca en true, se realizará una extracción de carga completa. ``` sapodata_df = glueContext.create_dynamic_frame.from_options( connection_type="SAPOData", connection_options={ "connectionName": "connectionName", "ENTITY_NAME": "entityName", "ENABLE_CDC": "false" }, transformation_ctx=key) ``` ## Carga incremental Una **carga incremental** en el contexto de las entidades ODP (Aprovisionamiento de datos operativos) implica extraer solo los datos nuevos o modificados (deltas) del sistema de origen desde la última extracción de datos, evitando el reprocesamiento de los registros ya procesados. Este enfoque mejora considerablemente la eficiencia, reduce los volúmenes de transferencia de datos, mejora el rendimiento, garantiza la sincronización efectiva entre sistemas y minimiza el tiempo de procesamiento, especialmente en el caso de conjuntos de datos grandes que cambian con frecuencia. # Transferencias incrementales basadas en tokens Delta Para habilitar la transferencia incremental mediante la Captura de datos de cambios (CDC) para las entidades habilitadas para ODP que la admiten, siga estos pasos: 1. Cree el trabajo de transferencia incremental en modo script. 1. Al crear el marco de datos o el DynamicFrame de Glue, debe pasar la opción `"ENABLE_CDC": "True"`. Esta opción garantiza que recibirá un token Delta de SAP, que podrá utilizar para recuperar posteriormente los datos modificados. El token Delta estará presente en la última fila del marco de datos, en la columna DELTA\$1TOKEN. Este token puede utilizarse como opción de conexión en llamadas posteriores para recuperar de forma incremental el siguiente conjunto de datos. **Ejemplo** + Establecemos la marca `ENABLE_CDC` en `true` al crear el DynamicFrame. Nota: `ENABLE_CDC` es `false` de forma predeterminada. Si no quiere inicializar la cola delta, no necesita enviar esta marca ni establecerla como verdadera. No establecer esta marca como verdadera resultará en una extracción de carga completa. ``` 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 ``` + El token delta extraído puede pasarse como opción para recuperar nuevos eventos. ``` 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) ``` Tenga en cuenta que el último registro, en el que `DELTA_TOKEN` está presente, no es un registro transaccional del origen y solo existe con la finalidad de pasar el valor del token delta. Además de `DELTA_TOKEN`, se devuelven los siguientes campos en cada fila del marco de datos. + **GLUE\$1FETCH\$1SQ**: se trata de un campo de secuencia, generado a partir de la marca de tiempo de EPOC en el orden en que se recibió el registro, y es único para cada registro. Se puede utilizar si necesita conocer o establecer el orden de los cambios en el sistema de origen. Este campo solo estará presente para las entidades habilitadas para ODP. + **DML\$1STATUS**: esto mostrará `UPDATED` para todos los registros recién insertados y actualizados a partir del origen y `DELETED` para los registros que se hayan eliminado del origen. Para obtener más información sobre cómo gestionar el estado y reutilizar el token delta para recuperar los registros modificados a través de un ejemplo, consulte la sección [Uso del script de administración de estado de SAP OData](sap-odata-state-management-script.md). ## Invalidación del token Delta Un token delta está asociado a la colección de servicios y a un usuario. Si se inicia una nueva extracción inicial con `“ENABLE_CDC” : “true”` para la misma colección de servicios y para el mismo usuario, el servicio OData de SAP invalidará todos los tokens delta anteriores emitidos como resultado de una inicialización anterior. Invocar el conector con un token delta caducado provocará una excepción: `Could not open data access via extraction API RODPS_REPL_ODP_OPEN` # Servicios OData (orígenes que no son ODP) ## Carga completa Para los sistemas que no son ODP (Aprovisionamiento de datos operativos), una **carga completa** implica extraer todo el conjunto de datos del sistema de origen y cargarlo en el sistema de destino. Dado que los sistemas que no son ODP no son compatibles de por sí con mecanismos avanzados de extracción de datos, como los deltas, el proceso es sencillo, pero puede requerir muchos recursos en función del tamaño de los datos. ## Carga incremental Para los sistemas o entidades que no admiten el **ODP (Aprovisionamiento de datos operativos)**, la transferencia incremental de datos se puede gestionar manualmente mediante la implementación de un mecanismo basado en marcas de tiempo para seguir y extraer los cambios. **Transferencias incrementales basadas en marca temporal** Para las entidades no habilitadas para ODP (o para las entidades habilitadas para ODP que no usan la marca ENABLE\$1CDC), puede usar una opción `filteringExpression` en el conector para indicar el intervalo de `datetime` para el que se quiere recuperar los datos. Este método se basa en un campo de fecha y hora en los datos que representa cuándo se creó o modificó cada registro por última vez. **Ejemplo** Recuperar registros que se modificaron después de 2024-01-01T00: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) ``` Nota: En este ejemplo, `LastChangeDateTime` es el campo que representa cuándo se modificó por última vez cada registro. El nombre real del campo puede variar en función de la entidad específica de SAP OData. Para obtener un nuevo subconjunto de datos en las siguientes ejecuciones, debe actualizar la opción `filteringExpression` con una nueva marca de tiempo. Normalmente, sería el valor máximo de la marca de tiempo de los datos recuperados anteriormente. **Ejemplo** ``` 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 ``` En la siguiente sección, proporcionaremos un enfoque automatizado para gestionar estas transferencias incrementales basadas en marcas de tiempo, lo que elimina la necesidad de actualizar manualmente la expresión de filtrado entre ejecuciones.