Patrones de operación válidos y errores de validación

Introducción

Las operaciones deben ser válidas para poder desplegarse. En esta página se explica cómo identificar operaciones no válidas y ver los errores de validación asociados a ellas, así como también cómo resolver errores de validación mediante un patrón de operación válido. También se proporcionan ejemplos de disposiciones de 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 los 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, desmarque esta opción:

resaltar elementos no válidos

Cuando se selecciona Resaltar elementos no válidos, las operaciones o componentes no válidos se resaltan en color rojo y tienen un Icono no válido junto a su nombre en el tela de diseño:

operación no válida

En el panel del proyecto, los nombres de los flujos de trabajo y componentes no válidos se enumeran en cursiva roja y se muestran con un icono inválido:

operación no válida

Haga clic en el icono no válido 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 ser inválidas por cualquiera de las siguientes razones:

Error	Información adicional
La operación está vacía.	La operación debe tener al menos un etapa de operación.
La operación no se ajusta a ningún patrón válido. Las reglas y patrones de operación se pueden encontrar aquí.	La operación debe cumplir con los patrones de operación establecidos que garantizan que el agente la respalde y la espere. Estos patrones se tratan a continuación en Patrones de validación.
El esquema de transformación [origen/destino] no coincide con la estructura de esquema proporcionada por la actividad ["Nombre de la actividad"]. Abra la transformación ["Nombre de la Transformación "] en la operación ["Nombre de la operación"] y actualice el esquema de destino.	En una operación que contiene una transformación con un esquema proporcionado por la actividad, el esquema proporcionado por la actividad debe coincidir con la estructura del esquema proporcionada por una actividad adyacente.
La Transformación ["Nombre de la Transformación "] tiene un esquema de origen pero no una actividad de origen. Elimine el esquema de origen de la transformación o agregue una actividad de origen antes de la transformación.	Si la operación contiene una transformación con una actividad proporcionada o transformación proporcionada esquema de origen, debe haber una actividad de origen que preceda a la transformación.
Las actividades de destino HTTP que envían su respuesta a una segunda actividad de destino solo pueden enviar respuestas a una actividad de destino en todo el proyecto. La actividad HTTP ["Nombre de la actividad de destino 1"] en esta operación envía su respuesta a varias actividades de destino en todo el proyecto. En esta operación, su destino es ["Nombre de la actividad de destino 2A"]. En la operación ["Operación 2"], su destino es ["Nombre de la actividad de destino 2B"]. Reemplace la actividad ["Nombre de la actividad de destino 1"] con una actividad duplicada en una de las operaciones. Puede hacerlo buscando la actividad ["Nombre de la actividad de destino 1"] en la pestaña Componentes, abra el menú y duplíquela. Arrastre la actividad duplicada a la operación.	En una operación que utiliza el Patrón de archivo de dos destinos y contiene una actividad de destino HTTP que escribe una respuesta a una segunda actividad de destino, la actividad de destino HTTP también se utiliza en otro Patrón de archivo de dos destinos la operación debe escribir en la misma actividad de destino. Nota Esta regla de validación se puede desactivar, aunque no se recomienda hacerlo. Para obtener más información, consulte Errores de la regla de validación HTTP al final de esta página.
"La operación ["Nombre de la operación"] no puede tener más de un oyente o actividad basada en eventos: ["Nombres de actividades"]."	Una operación solo puede contener una actividad de escucha por operación.
"La operación ["Nombre de la operación"] tiene ["Nombre de la actividad"] como un oyente o una actividad basada en eventos; dichas actividades deben ser las primeras en la operación.	La operación debe cumplir con los patrones de operación establecidos para la actividad de escucha. Los patrones de operación con los que se puede utilizar cada actividad de escucha se enumeran en la documentación de cada actividad.
"La operación ["Nombre de la operación"] no puede tener un resultado ["En caso de éxito" / "En caso de error" / "En caso de error de SOAP "] en la operación de destino ["Nombre de la operación 2"] que tiene un receptor o una actividad basada en eventos como primera actividad".	Una operación no puede usar acciones de operación para invocar otra operación que contenga una actividad de escucha.
"La operación ["Nombre de la operación"] comienza con un oyente o una actividad basada en eventos ["Nombre de la actividad"] y no puede tener una programación adjunta".	Una operación que contiene una actividad de escucha no se puede ejecutar según un cronograma.
El secuencia de comandos "["Nombre del Secuencia de comandos "] en la operación ["Nombre de la operación"] no puede usar RunOperation() para invocar la operación ["Nombre de la operación 2"] que tiene un detector o una actividad basada en eventos.	Una operación no puede usar el `RunOperation` función para invocar otra operación que contiene una actividad de escucha.

El El icono de no válido no se muestra si el motivo por el que la operación no es válida es que 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 los 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, una transformación o un 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 están cubiertas colectivamente bajo 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 agentes de Jitterbit. Estos patrones garantizan que el agente respalde 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 destinos
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 obligatorios 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 de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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 una consulta de Salesforce, Salesforce Service Cloud o ServiceMax como actividad de origen, entonces 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 también ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Compartir archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

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

^F La actividad HTTP debe recibir un cuerpo de solicitud y generar un cuerpo de respuesta. Una actividad HTTP GET devuelve un mensaje que indica que la operación se realizó correctamente. {"success": true}o fracaso {"success": false}en lugar de la respuesta real.

Preguntas frecuentes (preguntas frecuentes)

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

¿Cuál es la diferencia entre una fuente y un destino?
Se considera que las actividades se utilizan como fuente si proporcionan datos dentro de una operación. Se considera que las actividades se utilizan como destino si reciben datos dentro de una operación. Para obtener una explicación adicional sobre las fuentes frente a los 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 dentro de las páginas de actividad individuales en Conectores. En cada página de actividad, los patrones específicos que se pueden utilizar se incluyen dentro de la sección "Próximos pasos", que normalmente es 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 se ajusta a un patrón válido, es posible que pueda utilizar una combinación de operaciones que sigan un patrón válido. Para ello, cree cada operación por separado y luego encadenelas mediante 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 una transformación.
- En la mayoría de los casos, conectores de aplicación para actividades que no son masivas, como las de Epicor, ServiceNow y Workday, requieren una transformación.
- Se pueden agregar Secuencias de comandos prácticamente en cualquier lugar.
¿Existen ejemplos de cómo otros han establecido 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 cada página de actividad individual en Conectores.

Patrón de archivo

archivo de patrones de operación anotados pp

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 destino se pueden asociar con cualquiera de estos tipos de extremo:

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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

patrón de operación secuencia de comandos anotado pp

Secuencia de comandos(es) + Actividad objetivo

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

Patrón de Transformación

transformación del patrón de operación anotado pp

Secuencia de comandos(s) + (Grupo: Actividad de origen + Secuencia de comandos[s]) + Transformación + (Grupo: Secuencia de comandos(s) + Actividad de destino) + Secuencia de comandos[s])

En este patrón, las actividades de origen y/o destino pueden asociarse 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 una actividad.

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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 una consulta de Salesforce, Salesforce Service Cloud o ServiceMax como actividad de origen, entonces 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 también ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Compartir archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

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

Patrón de archivo de dos objetivos

patrón de operación dos archivo de destino anotado pp

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

En este patrón, la segunda actividad de destino se utiliza para archivar una respuesta de la actividad intermedia, que funciona tanto como primer destino 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 transformarlos. Esto puede considerarse como un archivo o como un paso a través de datos (a veces denominado paso a través).

Las actividades de origen y destino deben estar asociadas con ciertos 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:

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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 también ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Compartir archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

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

Patrón de archivo HTTP de dos destinos

patrón de operación dos archivo HTTP de destino anotado pp

Secuencia de comandos(es) + Actividad de origen 1 + Secuencia de comandos(es) + Transformación + Secuencia de comandos(es) + Actividad de destino 1 / Actividad de origen 2 + Actividad de destino 2 + Secuencia de comandos(es)

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

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

Las actividades de origen y destino deben estar asociadas con ciertos 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:

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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 que la operación se realizó correctamente. {"success": true}o fracaso {"success": false}en lugar de la respuesta real.

Patrón de dos transformaciones

Patrón de operación dos transformación anotado pp

Secuencia de comandos(es) + (Grupo: Actividad de origen 1 + Secuencia de comandos[s]) + Transformación 1 + Actividad de destino 1 / Actividad de origen 2 + Transformación 2 + Secuencia de comandos(es) + Actividad de destino 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 tanto como primer objetivo como segunda fuente), transformarla y luego, opcionalmente, escribirla en un segundo objetivo.

Las actividades de origen y destino deben estar asociadas con ciertos 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 cualquier tipo de extremo excepto API, Base de datos, Compartir 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 de solicitud SOAP de API en la cadena de operación y debe ser la fuente 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 también ninguna otra actividad excepto aquellas asociadas con la API, Base de datos, Compartir archivos, FTP, HTTP, Almacenamiento local, Almacenamiento temporal, o Variable conectores.

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

Patrón de fuente masiva de Salesforce

patrón de operación de Salesforce fuente masiva anotada pp

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:

Patrón de destino masivo de Salesforce

patrón de operación Salesforce bulk target annotated pp

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:

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

Ejemplos de patrones de operación comunes

En esta sección se proporcionan varios ejemplos comunes de operaciones configuradas utilizando un patrón de operación válido. Estos ejemplos se simplifican para demostrar los componentes básicos de las operaciones comúnmente creadas y no pretenden cubrir todas las combinaciones posibles. Consulte Patrones de validación más arriba en esta página para conocer todos los arreglos posibles.

Secuencia de comandos

Una operación puede contener simplemente un solo 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 en función de una variable del sistema u otro valor de datos.

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

secuencia de comandos de inicio de la operación

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 y proporciona datos dentro de la operación. La segunda actividad se utiliza como destino y recibe 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 de origen, también puede utilizar un secuencia de comandos.

operación de transferencia simple de archivos

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 una fuente 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 respuesta de la llamada de aplicación y escribiéndola en un destino.

La operación transforma los datos del origen al destino

Este ejemplo extrae datos de una actividad de origen que luego se transforman y se escriben en una actividad de destino:

operación lectura FTP

La operación transforma los datos y luego escribe la respuesta en otro destino

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 otro destino.

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

cadena de operación obtener token

La 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 un SOAP método de servicio web. La llamada de la aplicación normalmente incluye una estructura de datos de solicitud y respuesta.

En esta disposición la operación tiene tres partes:

La primera actividad de origen y transformación para construir la estructura de datos de la solicitud.
La aplicación se llama a sí misma, que funciona como primera actividad de destino y segunda actividad de origen.
Una segunda transformación y objetivo para convertir la respuesta de la llamada de la aplicación y escribir los datos o el archivo en un objetivo.

Convocatoria de solicitud

operación inserción de Salesforce

Llamada SOAP

operación comprobar información de tarjeta de crédito

Errores en las 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 destinos donde una actividad HTTP en la posición Target 1 escribe una respuesta a una segunda actividad de destino (Target 2). En este escenario, la regla de validación requiere que una actividad HTTP Target 1 no se utilice en ningún otro patrón de archivo de dos destinos 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:

errores de validación actividades de destino HTTP

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:

Duplique la actividad de destino HTTP en la posición Target 1 de una de las operaciones utilizando el Patrón de archivo de dos destinos:
Reemplace la actividad de destino HTTP en la posición Target 1 de las operación identificadas con la copia duplicada:
Repita el procedimiento para cualquier operación no válida adicional. 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 ser conveniente desactivar esta regla de validación HTTP de la siguiente manera:

Abra la configuración del proyecto:
En la pestaña Desplegar, deshabilite la Regla de validación HTTP:
Haga clic en Guardar.

Una vez que se deshabilite y guarde la configuración, los errores de validación de operación informados 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.

Precaución

No se recomienda usar esta configuración para deshabilitar la regla de validación HTTP y puede provocar la escritura involuntaria de datos no válidos en actividades de destino en operaciones que utilizan el Patrón de archivo de dos destinos.

Vuelva a habilitar la regla de validación HTTP

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

Abra la configuración del proyecto.
En la pestaña Desplegar, habilite Regla de validación HTTP.
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.
Resuelva cualquier error de validación HTTP (consulte Resolver errores de validación HTTP arriba).
Vuelva a desplegar el proyecto (consulte Despliegue del proyecto).

Nota

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