Saltar al contenido

Opciones de operación en Jitterbit Integration Studio

Introducción

Cada operación se puede configurar con opciones como cuándo finalizará la operación, qué se registrará y el período de tiempo para el registro de depurar de la operación. La presencia de ciertos componentes como pasos de la operación permite ver opciones adicionales sobre si se ejecuta una operación posterior y si se debe utilizar 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 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 la cantidad máxima de tiempo que durará la operación antes de cancelarse. En el primer campo, ingrese un número y en el segundo campo use 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 cuando se utilizan agentes en la nube. En los agentes privados, utilice el 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 un estado de tipo error (como Error, Error de SOAP o Éxito con error secundario). Las operaciones secundarias exitosas no se registran. Las operaciones principales (nivel raíz) siempre se registran, ya que requieren el registro para funcionar correctamente.

      Un motivo habitual para limitar los registros a Solo errores es si tienes problemas de latencia en las operación. De esta manera, si no tenías pensado utilizar los demás mensajes que no son de error y que normalmente se filtran en los registros de operación, puedes evitar que se generen en primer lugar.

  • 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 12:00 a. m.) utilizando la huso horario del agente.

    Al seleccionar Habilitar modo de depuración hasta, un cuadro de diálogo proporciona una casilla de verificación Aplicar también a operaciones secundarias que aplicará la configuración a cualquier operación secundaria. Esta opción también se proporciona al borrar la configuración del modo de depurar de la operación.

    habilitar registro de depurar

    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 para una operación. Esta opción se utiliza principalmente para depurar problemas durante las pruebas y no se debe activar en producción, ya que puede crear 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 de nube: Se pueden generar dos tipos de registros:

      • Datos de entrada y salida de componentes: Datos escritos en an Integration Studio 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 detalles adicionales, 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 datos de entrada y salida de componentes, todos los datos de solicitud y respuesta para 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 una carga útil de solicitud, serán visibles en texto sin formato en los datos de entrada y salida dentro de los registros de la nube de Harmony.

  • Ejecutar operación exitosa incluso si no hay archivos de origen coincidentes: Seleccione esta opción para forzar que una operación arriba en la cadena sea exitosa. 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 manera predeterminada, cualquier operación En caso de éxito se ejecuta solo 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

    La configuración 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 de fragmento: Ingrese una cantidad de registros de origen (nodos) para procesar para cada subproceso. Cuando la fragmentación de datos está habilitada para operaciones que no contienen ninguna actividad basada en Salesforce, el tamaño de fragmento predeterminado es 1 Cuando se agrega una actividad basada en Salesforce a una operación que no tiene 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: Ingrese el número solicitado de registros que se colocará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 ninguna actividad basada 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 la fragmentación de datos habilitada, la 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 el sistema de destino en fragmentos. 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 varios 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 la fragmentación de datos habilitada, 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 habilitada la fragmentación de datos, 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.

    En la siguiente sección, Fragmentación.#operationoptions-chunking).

  • 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 la 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 la cantidad de registros de origen (nodos) para cada fragmento. Luego, 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 producir el destino final.

La fragmentación se puede utilizar solo si los registros son independientes y provienen de una fuente que no sea LDAP. Recomendamos utilizar un tamaño de fragmento lo más grande posible, asegurándose de que los datos de un 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 acepta solo 200 registros para cada llamada. Con suficiente memoria, podría configurar una operación para utilizar un tamaño de fragmento de 200. La fuente 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 hayan procesado todos los registros. Luego, los archivos de destino resultantes se combinarían. (Tenga en cuenta que también podría utilizar actividades masivas basadas en Salesforce para evitar el uso de fragmentación de datos).

Procesamiento paralelo

Si tiene una fuente grande y una computadora con múltiples CPU, se puede usar la fragmentación de datos para dividir la fuente para el procesamiento en paralelo. Dado que cada fragmento se procesa de forma aislada, se pueden procesar varios fragmentos en paralelo. Esto se aplica solo si los registros de la fuente son independientes entre sí en el nivel del nodo del fragmento. Los servicios web se pueden llamar en paralelo mediante fragmentación de datos, lo que mejora el rendimiento.

Al utilizar 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 numerosos archivos temporales (uno para cada fragmento). Estos archivos se combinan luego en un 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 se habilita la fragmentación de datos, cada fragmento se envía a la base de datos a medida que está disponible. Esto puede mejorar el rendimiento significativamente, ya que la inserción y actualización de la base de datos se realizan en paralelo.

Usar 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, los cambios en estas variables no se conservan. Solo los cambios realizados en el hilo inicial se conservan 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 la variable global después de que finaliza la operación es el del primer subproceso. Cualquier cambio en la variable en otros subprocesos es independiente y se descarta cuando se completa 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 lo que ocurre con RunOperation función cuando está en modo asincrónico.