Saltar al contenido

¡Transforma tus conexiones en dinero para el final del año con nuestro nuevo Programa de Indicación de Clientes! Descubre más

✕

Opciones de operación en Jitterbit Integration Studio

Introducción

Cada operación se puede configurar con opciones como el tiempo de operación, el registro y el plazo para el registro de depurar. La presencia de ciertos componentes como pasos de la operación permite visualizar opciones adicionales para determinar si se ejecuta una operación posterior y si se debe usar la fragmentación de datos.

Opciones de operación de acceso

La opción Configuración para las operaciones es accesible desde estas ubicaciones:

Una vez abierta la pantalla de configuración de operación, seleccione la pestaña Opciones:

pestaña de opciones

Configurar las opciones de operación

A continuación se describe cada opción disponible dentro de la pestaña Opciones de la configuración de operación.

diálogo de opciones

  • Tiempo de espera de la operación: Especifique el tiempo máximo que durará la operación antes de cancelarse. En el primer campo, introduzca un número y, en el segundo, utilice el menú desplegable para seleccionar las unidades en Segundos, Minutos u Horas. El valor predeterminado es 2 horas.

    Las razones comunes para ajustar el valor de Tiempo de espera de operación incluyen las siguientes:

    • Aumente el valor de tiempo de espera si la operación tiene conjuntos de datos grandes que tardan mucho tiempo en ejecutarse.

    • Disminuya el valor de tiempo de espera si la operación es sensible al tiempo; es decir, no desea que la operación tenga éxito si no puede completarse dentro de un período de tiempo determinado.

    Nota

    Operaciones que se activan mediante APIs de API Manager no están sujetos a la configuración Tiempo de espera de operación al usar agentes en la nube. En agentes privados, use la EnableAPITimeout configuración en el archivo de configuración del agente privado para que la configuración Tiempo de espera de operación se aplique a las operaciones activadas por las APIs.

  • Qué registrar: Utilice el menú desplegable para seleccionar qué registrar en los registros de operación, uno de Todo (predeterminado) o Solo errores:

    • Todo: Operaciones con cualquier estado de operación se registran.

    • Solo errores: Solo se registran las operaciones con estado de error (como Error, Fallo SOAP o Éxito con error secundario). Las operaciones secundarias exitosas no se registran. Las operaciones principales (de nivel raíz) siempre se registran, ya que requieren registro para funcionar correctamente.

      Una razón común para limitar los registros a Solo Errores es si se experimentan problemas de latencia en las operación. De esta manera, si no se planeaba usar los demás mensajes que no son de error y que normalmente se filtran en los registros de operación, se puede evitar que se generen.

  • Habilitar modo de depuración hasta: Seleccione esta opción para habilitar el registro de depurar de operación y especifique una fecha en la que el modo de depurar se deshabilitará automáticamente, con un límite de dos semanas a partir de la fecha actual. El registro de depurar de operaciones se desactivará al comienzo de esa fecha (es decir, a las 00:00) según la huso horario del agente.

    Al seleccionar Habilitar modo de depuración hasta para una operación con operaciones secundarias, se muestra la casilla Aplicar también a operaciones secundarias, que aplica la configuración a cualquier operación secundaria. Esta opción también se muestra al desactivar la configuración del modo de depurar de la operación.

    Cuando el registro de depurar de operación está habilitado, se generan estos tipos de registros, según el tipo de agente:

    • Agente privado: Archivos de registro de depuración de una operación. Esta opción se utiliza principalmente para depurar problemas durante las pruebas y no debe activarse en producción, ya que puede generar archivos muy grandes. El registro de depuración también se puede habilitar para todo el proyecto desde el propio agente privado (consulte Registro de depurar de operaciones. Los archivos de registro de depurar son accesibles directamente en los agentes privados y se pueden descargar a través de la Management Console Agentes y Operaciones en tiempo de ejecución páginas.

    • Agente privado o agente en la nube: Se pueden generar dos tipos de registros:

      • Datos de entrada y salida del componente: Datos escritos en registro de operación para una operación que se ejecuta en la versión 10.48 o posterior del agente. Harmony conserva los datos durante 30 días.

      • Registros de operaciones de API: Registros de operaciones para operaciones de API exitosas (configuradas para APIs personalizadas o servicios OData). De forma predeterminada, solo las operaciones de API con errores se registran en los registros de operación.

    Para obtener más detalles, consulte Registro de depurar de operaciones para agentes de la nube o Registro de depurar de operaciones para agentes privados.

    Precaución

    La generación de datos de entrada y salida de componentes no se ve afectada por la configuración del grupo de agentes Registro en la nube habilitado. Los datos de entrada y salida de los componentes se registrarán en la nube Harmony incluso si el registro en la nube está deshabilitado.

    Para deshabilitar la generación de datos de entrada y salida de componentes en un grupo de agentes privados, en el archivo de configuración del agente privado bajo el [VerboseLogging] sección, conjunto verbose.logging.enable=false.

    Advertencia

    Cuando se generan los datos de entrada y salida de un componente, todos los datos de solicitud y respuesta de esa operación se registran en la nube de Harmony y permanecen allí durante 30 días. Tenga en cuenta que la información de identificación personal (PII) y los datos confidenciales, como las credenciales proporcionadas en la carga útil de una solicitud, serán visibles en texto sin cifrar en los datos de entrada y salida de los registros de la nube de Harmony.

  • Ejecutar operación exitosa incluso si no hay archivos fuente coincidentes: Seleccione esta opción para forzar el éxito de una operación arriba en la cadena. Esto le permite iniciar una operación con una condición En caso de éxito (configurada con una acción de operación) incluso si el disparador falló.

    Esta opción solo es aplicable si la operación contiene una API, Compartir archivos, FTP, HTTP, Almacenamiento local, SOAP, Almacenamiento temporal, o Actividad variable que se utiliza como origen en la operación y se aplica solo cuando la operación tiene configurada una condición En caso de éxito. De forma predeterminada, cualquier operación En caso de éxito solo se ejecuta si tiene un archivo de origen coincidente para procesar. Esta opción puede ser útil para configurar partes posteriores de un proyecto sin requerir el éxito de una operación dependiente.

    Nota

    El ambiente AlwaysRunSuccessOperation en el [OperationEngine] sección del archivo de configuración del agente privado anula la configuración Ejecutar operación exitosa incluso si no hay archivos de origen coincidentes.

  • Habilitar fragmentación: Seleccione para habilitar la fragmentación de datos utilizando los parámetros especificados:

    • Tamaño del fragmento: Introduzca la cantidad de registros de origen (nodos) que se procesarán en cada subproceso. Cuando la fragmentación de datos está habilitada para operaciones que no contienen actividades basadas en Salesforce, el tamaño del fragmento predeterminado es 1 Cuando se agrega una actividad basada en Salesforce a una operación que no tiene la fragmentación de datos habilitada, la fragmentación de datos se habilita automáticamente con un tamaño de fragmento predeterminado de 200 Si utiliza una actividad masiva basada en Salesforce, debe cambiar este valor predeterminado a un número mucho mayor, como 10 000.

    • Número de registros por archivo: Introduzca el número de registros que se incluirán en el archivo de destino. El valor predeterminado es 0, lo que significa que no hay límite en la cantidad de registros por archivo.

    • Número máximo de subprocesos: Ingrese el número de subprocesos simultáneos que se procesarán. Cuando la fragmentación de datos está habilitada para operaciones que no contienen actividades basadas en Salesforce, el número predeterminado de subprocesos es 1 Cuando se agrega una actividad basada en Salesforce a una operación que no tiene habilitada la fragmentación de datos, fragmentación de datos se habilita automáticamente con una cantidad predeterminada de subprocesos. 2.

    Esta opción solo está presente si la operación contiene una transformación o una base de datos, NetSuite, Salesforce, Salesforce Service Cloud, ServiceMax, o actividad SOAP y se utiliza para procesar datos en fragmentos hacia el sistema de destino. Esto permite un procesamiento más rápido de grandes conjuntos de datos y también se utiliza para abordar los límites de registros impuestos por diversos sistemas basados en servicios web al realizar una solicitud.

    Tenga en cuenta que si está utilizando un extremo basado en Salesforce (Salesforce, Salesforce Service Cloud o ServiceMax):

    • Si se agrega una actividad basada en Salesforce a una operación que no tiene habilitada la fragmentación de datos, la fragmentación de datos se habilita con la configuración predeterminada específicamente para las actividades basadas en Salesforce, como se describe anteriormente.

    • Si se agrega una actividad basada en Salesforce a una operación que ya tiene la fragmentación de datos activada, la configuración de fragmentación de datos no se modifica. Del mismo modo, si se elimina una actividad basada en Salesforce de una operación, la configuración de fragmentación de datos no se modifica.

    Se proporciona información adicional y mejores prácticas para la fragmentación de datos en la siguiente sección, Fragmentación.

  • Guardar cambios: Haga clic para guardar y cerrar la configuración de la operación.

  • Descartar cambios: Después de realizar cambios en la configuración de operación, haga clic para cerrar la configuración sin guardar.

Fragmentación

La fragmentación se utiliza para dividir los datos de origen en varios fragmentos según el tamaño de fragmento configurado. El tamaño de fragmento es el número de registros de origen (nodos) para cada fragmento. La transformación se realiza en cada fragmento por separado, y cada fragmento de origen produce un fragmento de destino. Los fragmentos de destino resultantes se combinan para generar el destino final.

La fragmentación solo se puede usar si los registros son independientes y provienen de una fuente distinta a LDAP. Recomendamos usar un tamaño de fragmento lo más grande posible, asegurándose de que los datos de cada fragmento quepan en la memoria disponible. Para conocer otros métodos para limitar la cantidad de memoria que utiliza una transformación, consulte Procesamiento de Transformación.

Advertencia

El uso de la fragmentación de datos afecta el comportamiento de las variables globales y de proyecto. Consulte Usar variables con fragmentación de datos abajo.

Limitaciones de la API

Muchas APIs de servicios web (SOAP/REST) tienen limitaciones de tamaño. Por ejemplo, una operación upsert basada en Salesforce solo acepta 200 registros por llamada. Con suficiente memoria, se podría configurar una operación para usar un tamaño de fragmento de 200. El origen se dividiría en fragmentos de 200 registros cada uno, y cada transformación llamaría al servicio web una vez con un fragmento de 200 registros. Esto se repetiría hasta que se procesaran todos los registros. Los archivos de destino resultantes se combinarían. (Tenga en cuenta que también podría usar actividades masivas basadas en Salesforce para evitar el uso de fragmentación de datos).

Procesamiento paralelo

Si tiene una fuente grande y un ordenador con varias CPU, puede usar la fragmentación de datos para dividir la fuente y procesarla en paralelo. Dado que cada fragmento se procesa de forma aislada, varios fragmentos pueden procesarse en paralelo. Esto solo aplica si los registros de la fuente son independientes entre sí a nivel de nodo del fragmento. Los servicios web pueden llamarse en paralelo mediante la fragmentación de datos, lo que mejora el rendimiento.

Al usar la fragmentación de datos en una operación cuyo destino es una base de datos, tenga en cuenta que los datos de destino se escriben primero en varios archivos temporales (uno por cada fragmento). Estos archivos se combinan en un solo archivo de destino, que se envía a la base de datos para su inserción o actualización. Si configura la variable Jitterbit jitterbit.target.db.commit_chunks a 1 o true Cuando la fragmentación de datos está habilitada, cada fragmento se confirma en la base de datos a medida que está disponible. Esto puede mejorar significativamente el rendimiento, ya que las inserciones y actualizaciones de la base de datos se realizan en paralelo.

Utilice variables con fragmentación de datos

Como la fragmentación de datos puede invocar subprocesos múltiples, su uso puede afectar el comportamiento de las variables que no se comparten entre los subprocesos.

Global y variables del proyecto se separan entre las instancias de fragmentación de datos y, aunque los datos se combinan, no se combinan los cambios en estas variables. Solo se conservan los cambios realizados en el hilo inicial al final de la transformación.

Por ejemplo, si una operación (con fragmentación de datos y múltiples subprocesos) tiene una transformación que cambia una variable global, el valor de esta al finalizar la operación será el del primer subproceso. Cualquier cambio en la variable en otros subprocesos es independiente y se descarta al finalizar la operación.

Estas variables globales se pasan a los demás subprocesos por valor, en lugar de por referencia, lo que garantiza que los cambios en las variables no se reflejen en otros subprocesos u operaciones. Esto es similar a... RunOperation Función cuando está en modo asincrónico.