Validez de la Operación¶

Introducción¶

Las operaciones deben ser válidas para poder ser implementadas. Esta página cubre cómo identificar operaciones no válidas y ver los errores de validación asociados con ellas, así como también cómo resolver errores de validación utilizando un patrón de operación válido. También se proporcionan ejemplos de disposiciones operación comunes.

Errores de Validación¶

Esta sección cubre cómo identificar operaciones no válidas y ver los errores de validación asociados con operaciones no válidas.

Para proyectos nuevos, los elementos no válidos se resaltan de forma predeterminada en el tela de diseño, con la selección predeterminada de Resaltar elementos no válidos. Para desactivar esta opción, borre esta selección:

Cuando se selecciona Resaltar elementos no válidos, los nombres de las operaciones no válidas aparecen en cursiva y en color rojo en el tela de diseño y en el panel de proyecto. Además, en el tela de diseño, los iconos de los pasos de operación no válidos están delineados con un borde rojo:

En el panel del proyecto, las operaciones no válidas que tienen un error implícito se muestran con un icono de error :

Haga clic en el icono de error junto al nombre de la operación para mostrar un mensaje que enumera los errores de validación de la operación. Las operaciones con un error implícito pueden no ser válidas por cualquiera de los siguientes motivos:

El icono de error no se muestra si el motivo por el que la operación no es válida es porque contiene otros componentes con errores implícitos. Los componentes del proyecto utilizados como parte de una operación deben ser válidos para que la operación sea válida. Esto incluye componentes utilizados como pasos de una operación, así como otros componentes utilizados en apoyo de una operación. Por ejemplo:

• Un componente utilizado directamente como paso en la operación, como una actividad, transformación o secuencia de comandos.
• Un extremo del que depende una actividad utilizada en la operación.
• Un componente llamado por un secuencia de comandos en la operación.

Las reglas de validación dependen del tipo de componente y se tratan colectivamente en Validez del componente.

patrones de Validación¶

Se deben seguir ciertos patrones de validación para que las operaciones se implementen en la nube de Harmony y se ejecuten en los agentes de Harmony. Estos patrones garantizan que el agente admita y espere todas las partes de un proyecto:

• Patrón de archivo
• Patrón de Secuencia de Comandos
• Patrón de Transformación
• Patrón de archivo de dos objetivos
• Patrón de archivo HTTP de dos objetivos
• Patrón de dos transformaciones
• Patrón de fuente masiva de Salesforce
• Patrón de destino masivo de Salesforce

El siguiente diagrama resume todos los patrones de operación válidos. Cada patrón también se presenta individualmente y se describe en el texto debajo del diagrama, donde los componentes opcionales aparecen en negrita gris y los componentes requeridos aparecen en negrita roja.

Notas a Pie de Página para Patrones de Validación¶

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^B Si se utiliza Salesforce, Salesforce Service Cloud o ServiceMax Query como actividad de origen, se requiere una actividad de destino.

^C Las operaciones no pueden incluir más de una actividad de NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax o SOAP.

^D Las operaciones que incluyen una actividad de Salesforce, Salesforce Service Cloud o ServiceMax no pueden contener ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Recurso compartido de archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

^E En esta ubicación solo se pueden utilizar actividades no masivas.

^F La actividad HTTP debe recibir un cuerpo de solicitud y producir un cuerpo de respuesta. Una actividad HTTP GET devuelve un mensaje que indica éxito {"success": true} o fracaso {"success": false} en lugar de la respuesta real.

Preguntas Frecuentes (preguntas Frecuentes)¶

Al diseñar operaciones, puede resultar útil considerar las respuestas a estas preguntas frecuentes:

• ¿Cuál es la diferencia entre un origen y un destino?
  Las actividades se consideran utilizadas como fuente si proporcionan datos dentro de una operación. Las actividades se consideran utilizadas como objetivo si reciben datos dentro de una operación. Para obtener explicaciones adicionales sobre orígenes versus destinos y las partes de la operación, consulte Creación y configuración de operaciones.
• ¿Qué patrones son válidos con mi extremo?
  Los patrones que se pueden utilizar con cada tipo específico de actividad están documentados en las páginas de actividades individuales en Conectores. En cada página de actividad, los patrones específicos que se pueden utilizar se incluyen en la sección "Próximos pasos", que suele ser la última sección de cada página de actividad.
• ¿Qué pasa si mi caso de uso no se ajusta a un patrón válido?
  Si una determinada disposición de operación deseada no sigue un patrón válido, es posible que pueda utilizar una combinación de operaciones en las que cada una siga un patrón válido. Para hacerlo, cree cada operación por separado y luego encadenelas usando acciones de operación.

• ¿Cómo puedo recordar estos patrones?
  Las operaciones que no siguen un patrón válido se marcan como no válidas y no se pueden desplegar. A medida que se familiarice con los patrones, pueden resultar evidentes generalizaciones como estas:

  • conectores genéricos basados en archivos, como FTP, HTTP y almacenamiento temporal, se pueden utilizar sin necesidad de transformación.
  • En la mayoría de los casos, conectores de aplicaciones para actividades no masivas, como las de Epicor, ServiceNow y Workday, requieren una transformación.
  • Los Secuencias de Comandos se pueden agregar casi en cualquier lugar.

• ¿Hay ejemplos de cómo otros han configurado operaciones?
  Para ver ejemplos comunes que utilizan estos patrones, consulte Ejemplos de patrones de operación comunes al final de esta página, o consulte la página de cada actividad individual en Conectores.

Patrón de Archivo¶

Secuencia de Comandos(es) + Actividad de origen + Secuencia de Comandos(es) + Actividad de destino + Secuencia de Comandos(es)

En este patrón, las actividades de origen y de destino se pueden asociar con cualquiera de estos tipos de extremo:

• API^A
• Recurso compartido de archivos
• FTP
• HTTP
• Almacenamiento local
• NetSuite
• Salesforce ^E
• Salesforce Service Cloud ^E
• ServiceMax ^E
• Almacenamiento temporal
• Variable

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^E En esta ubicación solo se pueden utilizar actividades no masivas.

Patrón de Secuencia de Comandos¶

Secuencia de Comandos(es) + Actividad objetivo

En este patrón, la actividad de destino se puede asociar con cualquiera de estos tipos de extremo:

• API
• Recurso compartido de archivos
• FTP
• HTTP
• Almacenamiento local
• Almacenamiento temporal
• Variable

Patrón de Transformación¶

Secuencia de Comandos(s) + (Grupo: Actividad de origen + Secuencia de Comandos[s]) + Transformación + (Grupo: Secuencia de Comandos(es) + Actividad objetivo) + Secuencia de Comandos[s])

En este patrón, las actividades de origen y/o destino se pueden asociar con cualquier tipo de extremo, siempre que se incluya al menos una actividad. Una transformación no puede existir por sí sola en una operación sin actividad.

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^B Si se utiliza Salesforce, Salesforce Service Cloud o ServiceMax Query como actividad de origen, se requiere una actividad de destino.

^C Las operaciones no pueden incluir más de una actividad de NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax o SOAP.

^D Las operaciones que incluyen una actividad de Salesforce, Salesforce Service Cloud o ServiceMax no pueden contener ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Recurso compartido de archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

^E En esta ubicación solo se pueden utilizar actividades no masivas.

Patrón de Archivo de Dos Objetivos¶

Secuencia de Comandos(s) + (Grupo: Actividad de origen 1 + Secuencia de Comandos[s]) + Transformación + Actividad de destino 1 / Actividad de origen 2 + Secuencia de Comandos(es) + Actividad objetivo 2 + Secuencia de Comandos(es)

En este patrón, la segunda actividad objetivo se utiliza para archivar una respuesta de la actividad intermedia, que funciona como primer objetivo y como segunda fuente.

La respuesta de la actividad intermedia pasa a través de los datos de respuesta sin procesar a un segundo objetivo sin transformarlo. Esto se puede considerar como un archivo o como un paso de datos (a veces denominado paso a través).

Las actividades de origen y de destino deben estar asociadas con determinados tipos de extremo según dónde se utilicen en el patrón:

• Actividad de origen 1 ^A: Si se utiliza, la primera actividad de origen se puede asociar con cualquier tipo de extremo.

• Actividad de destino 1/Actividad de origen 2: La primera actividad de destino (también denominada segunda actividad de origen) se puede asociar con cualquiera de estos tipos de extremo:

  • NetSuite
  • Salesforce ^{D, E}
  • Salesforce Service Cloud ^{D, E}
  • SAP
  • ServiceMax ^{D, E}
  • SOAP

  Nota

  Una variación de este patrón que utiliza HTTP como actividad intermedia es el Patrón de archivo HTTP de dos objetivos.

• Actividad de destino 2: La segunda actividad de destino se puede asociar con cualquiera de estos tipos de extremo:

  • API
  • Compartir archivo
  • FTP
  • HTTP
  • Almacenamiento local
  • Almacenamiento temporal
  • Variable

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^C Las operaciones no pueden incluir más de una actividad de NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax o SOAP.

^D Las operaciones que incluyen una actividad de Salesforce, Salesforce Service Cloud o ServiceMax no pueden contener ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Recurso compartido de archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

^E En esta ubicación solo se pueden utilizar actividades no masivas.

Patrón de Archivo HTTP de Dos Destinos¶

Secuencia de Comandos(es) + Actividad fuente 1 + Secuencia de Comandos(es) + Transformación + Secuencia de Comandos(es) + Actividad objetivo 1 / Actividad fuente 2 + Actividad objetivo 2 + Secuencia de Comandos(es)

En este patrón, la segunda actividad objetivo se utiliza para archivar una respuesta de la actividad intermedia, que funciona como primer objetivo y como segunda fuente. Este patrón es diferente del Patrón de archivo de dos objetivos en el sentido de que la actividad intermedia es una actividad HTTP.

La respuesta de la actividad HTTP intermedia pasa a través de los datos de respuesta sin procesar a un segundo destino sin transformarlo. Esto se puede considerar como un archivo o como un paso de datos (a veces denominado paso a través).

Las actividades de origen y de destino deben estar asociadas con determinados tipos de extremo según dónde se utilicen en el patrón:

• Actividad de origen 1 ^A: Si se utiliza, la primera actividad de origen se puede asociar con cualquier tipo de extremo.
• Actividad de destino 1/Actividad de origen 2: La primera actividad de destino (también denominada segunda actividad de origen) se puede asociar con cualquiera de estos tipos de extremo:
  • HTTP ^F
• Actividad de destino 2: La segunda actividad de destino se puede asociar con cualquiera de estos tipos de extremo:
  • API
  • Compartir archivo
  • FTP
  • HTTP
  • Almacenamiento local
  • Almacenamiento temporal
  • Variable

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^E En esta ubicación solo se pueden utilizar actividades no masivas.

^F La actividad HTTP debe recibir un cuerpo de solicitud y producir un cuerpo de respuesta. Una actividad HTTP GET devuelve un mensaje que indica éxito {"success": true} o fracaso {"success": false} en lugar de la respuesta real.

Patrón de Dos Transformaciones¶

Secuencia de Comandos(s) + (Grupo: Fuente Actividad 1 + Secuencia de Comandos[s]) + Transformación 1 + Objetivo Actividad 1 / Fuente Actividad 2 + Transformación 2 + Secuencia de Comandos(es) + Actividad objetivo 2 + Secuencia de Comandos(es)

En este patrón, la segunda transformación se utiliza para tomar la respuesta de la actividad intermedia (que funciona como primer objetivo y como segunda fuente), transformarla y luego, opcionalmente, escribirla en un segundo objetivo.

Las actividades de origen y de destino deben estar asociadas con determinados tipos de extremo según dónde se utilicen en el patrón:

• Actividad de origen 1 ^A: Si se utiliza, la primera actividad de origen se puede asociar con cualquier tipo de extremo.
• Actividad de destino 1/Actividad de origen 2: La primera actividad de destino (también conocida como segunda actividad de origen) se puede asociar con cualquier tipo de extremo excepto API, Base de datos, Recurso compartido de archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable.
• Actividad de destino 2 ^E: Si se utiliza, la segunda actividad de destino se puede asociar con cualquier tipo de extremo.

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud SOAP de API en la cadena de operación y debe ser el origen de la primera operación. Es decir, ninguna otra operación puede llamar a esta operación desde un secuencia de comandos o una acción de operación "en caso de éxito" o "en caso de error".

^C Las operaciones no pueden incluir más de una actividad de NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax o SOAP.

^D Las operaciones que incluyen una actividad de Salesforce, Salesforce Service Cloud o ServiceMax no pueden contener ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Recurso compartido de archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

^E En esta ubicación solo se pueden utilizar actividades no masivas.

Patrón de Fuente Masiva de Salesforce¶

Secuencia de Comandos(es) + Actividad de origen + Secuencia de Comandos(es) + Actividad de destino + Secuencia de Comandos(es)

En este patrón, la actividad de origen debe ser una actividad de consulta masiva de Salesforce, Actividad de consulta masiva de Salesforce Service Cloud, o actividad de consulta masiva de ServiceMax. La actividad de destino se puede asociar con cualquiera de estos tipos de extremo:

• Recurso compartido de archivos
• FTP
• HTTP
• Almacenamiento local
• Almacenamiento temporal
• Variable

Patrón de Destino Masivo de Salesforce¶

Secuencia de Comandos(es) + Actividad de origen + Secuencia de Comandos(es) + Actividad de destino + Secuencia de Comandos(es)

En este patrón, la actividad de origen se puede asociar con cualquiera de estos tipos de extremo:

• Recurso compartido de archivos
• FTP
• HTTP
• Almacenamiento local
• Almacenamiento temporal
• Variable

La actividad de destino se puede asociar con cualquiera de estos tipos de extremo:

• Inserción masiva de Salesforce
• Actualización masiva de Salesforce
• Inserción masiva de Salesforce
• Eliminación masiva de Salesforce
• Eliminación definitiva masiva de Salesforce
• Inserción, actualización, inserción, eliminación o eliminación masiva de Salesforce Service Cloud
• Inserción masiva ServiceMax
• Actualización masiva de ServiceMax
• Inserción masiva ServiceMax
• Eliminación masiva de ServiceMax
• Eliminación completa masiva de ServiceMax

Ejemplos de Patrones de Operación Comunes¶

Esta sección proporciona varios ejemplos comunes de operaciones configuradas utilizando un patrón de operación válido. Estos ejemplos están simplificados para demostrar los componentes básicos de las operaciones comúnmente construidas y no pretenden cubrir todas las combinaciones posibles. Consulte Patrones de validación anteriormente en esta página para conocer todos los arreglos posibles.

Secuencia de Comandos¶

Una operación puede contener simplemente un único secuencia de comandos. En este caso, todas las acciones de la operación las realiza el secuencia de comandos.

Este patrón se utiliza normalmente al comienzo de un flujo de trabajo para crear un " secuencia de comandos de inicio" que ejecuta una o más de varias operaciones de rama basadas en una variable del sistema u otro valor de datos.

Los Secuencias de Comandos también se pueden utilizar en cualquier parte de una operación para realizar cálculos complejos que requieren lógica personalizada.

Archivo¶

Si todo lo que necesita hacer es mover archivos desde una fuente de datos a un destino, puede utilizar una operación sin transformación.

La primera actividad se utiliza como fuente, proporcionando datos dentro de la operación. La segunda actividad se utiliza como objetivo, recibiendo datos dentro de la operación.

Para archivar datos, las actividades de origen y destino se limitan a aquellas que interactúan con archivos. En lugar de una actividad fuente, también puedes usar un secuencia de comandos.

Transformación¶

Operaciones que hacen uso de transformaciones sirven para una variedad de casos de uso. Por ejemplo, puede crear operaciones que (1) transformen datos de un origen a un destino, (2) transformen datos y luego escriban la respuesta en otro destino, o (3) transformen datos de una llamada de servicio web convirtiendo la llamada de la aplicación. respuesta y escritura a un objetivo.

La Operación Transforma los Datos del Origen al Destino¶

Este ejemplo extrae datos de una actividad de origen que luego se transforma y escribe en una actividad de destino:

La Operación Transforma Datos y Luego Escribe la Respuesta en Otro Objetivo¶

En este ejemplo, cuando se utiliza una actividad HTTP como destino de la transformación, como HTTP PUT o HTTP POST, se puede colocar una actividad de destino adicional directamente después de ella, o después de otra transformación, para escribir la respuesta HTTP en otra objetivo.

Esta disposición de operación, utilizada para obtener un token REST, muestra la respuesta HTTP que se escribe en una variable global para usar en la siguiente operación:

Operación Llama a un Servicio Web¶

Este ejemplo es para actualizar una aplicación como Salesforce a través de la API de la aplicación, o llamando a SOAP método de servicio web. La llamada de la aplicación normalmente incluye una estructura de datos de solicitud y respuesta.

En este arreglo, la operación tiene tres partes:

• La primera actividad fuente y transformación para construir la estructura de datos de la solicitud.

• La llamada de la aplicación a sí misma, que funciona como primera actividad de destino y segunda actividad de origen.

• Una segunda transformación y destino para convertir la respuesta de la llamada de la aplicación y escribir los datos o el archivo en un destino.

Llamada de Solicitud¶

Llamada de SOAP¶

Errores de Reglas de Validación HTTP¶

Una de las reglas de validación HTTP se aplica a las operaciones que utilizan el Patrón de archivo de dos objetivos donde una actividad HTTP en la posición Destino 1 escribe una respuesta a una segunda actividad de destino (Destino 2). En este escenario, la regla de validación requiere que una actividad HTTP Target 1 no se use en ningún otro Patrón de archivo de dos objetivos operaciones en las que la actividad HTTP Target 1 escribe en una segunda actividad de destino diferente.

Las operaciones que violan esta regla de validación se informan como no válidas con un mensaje de error similar a este:

Resolver Errores de Validación HTTP¶

Recomendamos seguir las instrucciones proporcionadas en el mensaje de error para corregir las operaciones y que sean válidas. Siguiendo esas instrucciones, recomendamos estos pasos:

1. Duplique la actividad de destino HTTP en la posición Destino 1 de una de las operaciones usando el Patrón de archivo de dos objetivos:

   

2. Reemplace la actividad de destino HTTP en la posición Destino 1 de las operación identificadas con la copia duplicada:

   

3. Repita para cualquier operación adicional no válida. Una vez que se resuelvan los errores de validación, vuelva a desplegar las operaciones.

Deshabilitar la Regla de Validación HTTP¶

En determinadas situaciones, puede resultar conveniente desactivar esta regla de validación HTTP de la siguiente manera:

1. Abra la configuración del proyecto:

   

2. En la pestaña Desplegar, deshabilite la Regla de validación HTTP:

   

3. Haga clic en Guardar.

Una vez deshabilitada y guardada la configuración, los errores de validación de operación reportados debido a este error deberían resolverse. Sin embargo, tenga en cuenta que cualquier actividad HTTP Target 1 utilizada en un Patrón de archivo de dos objetivos la operación escribirá en la actividad Target 2 de la última operación implementada. Esto puede provocar que se escriban datos no válidos.

Vuelva a Habilitar la Regla de Validación HTTP¶

Si anteriormente deshabilitó la regla de validación HTTP y está listo para volver a habilitarla, siga estos pasos:

1. Abra la configuración del proyecto.

2. En la pestaña Desplegar, habilite Regla de validación HTTP.

3. Haga clic en Guardar. Tenga en cuenta que se trata de un cambio en tiempo de diseño y que esta acción no desplegar ningún cambio en la nube de Harmony.

4. Resuelva cualquier error de validación HTTP (consulte Resolver errores de validación HTTP arriba).

5. Vuelva a desplegar el proyecto (consulte Despliegue del proyecto).

   Nota

   Antes de la redistribución, se permite la ejecución de cualquier operación que ahora no sea válida, ya que Harmony ejecuta las operaciones implementadas actualmente. Es necesaria la redistribución de las operaciones afectadas para que los cambios se propaguen a Harmony.