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

Introducción

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

Errores de validación

Para nuevos proyectos, los elementos inválidos se destacan por defecto en el lienzo de diseño, con la selección predeterminada de Resaltar Elementos Inválidos. Para desactivar esta opción, desmarque esta selección:

resaltar elementos inválidos

Cuando Resaltar Elementos Inválidos está seleccionado, cualquier operación o componente inválido se contorna en color rojo y tiene un ícono de error inválido junto a su nombre en el lienzo de diseño:

operación inválida

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

operación inválida

Haga clic en el ícono inválido junto al nombre de la operación para mostrar un mensaje que enumera los errores de validación para la operación.

Las operaciones con un error implícito pueden ser inválidas por cualquiera de las razones enumeradas en Errores de operación implícitos al final de esta página.

El ícono inválido no se muestra si la razón por la cual la operación es invá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 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 un paso en la operación, como una actividad, transformación o script.
Un endpoint del cual depende una actividad utilizada en la operación.
Un componente llamado por un script en la operación.

Las reglas de validación dependen del tipo de componente y se cubren colectivamente bajo Validez del componente.

Patrones de validación

Ciertos patrones de validación deben seguirse para que las operaciones sean desplegadas en la nube de Harmony y ejecutadas en los agentes de Jitterbit. Estos patrones aseguran que todas las partes de un proyecto sean compatibles y esperadas por el agente:

Patrón de archivo
Patrón de script
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 objetivo masivo de Salesforce

La siguiente leyenda muestra la definición de las líneas de flujo mostradas en las ilustraciones de los patrones de validación:

Línea de flujo	Definición
	Un componente requerido.
	Un componente opcional.
	Cero o más script(s) o Herramientas de control de flujo tools son válidos.

Preguntas frecuentes (FAQ)

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?
Las actividades se consideran utilizadas como una fuente si proporcionan datos dentro de una operación. Las actividades se consideran utilizadas como un destino si reciben datos dentro de una operación. Para una explicación adicional sobre fuentes versus destinos y las partes de la operación, consulte Creación y configuración de operaciones.
¿Qué patrones son válidos con mi punto final?
Los patrones que se pueden utilizar con cada tipo específico de actividad están documentados en las páginas individuales de actividades bajo 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 un cierto arreglo de operación deseado no se adhiere a un patrón válido, es posible que pueda utilizar una combinación de operaciones que cada una siga un patrón válido. Para hacerlo, cree cada operación por separado y luego encadénelas utilizando acciones de operación.
¿Cómo puedo recordar estos patrones?
Las operaciones que no siguen un patrón válido se marcan como inválidas y no se pueden implementar. A medida que se familiarice con los patrones, generalizaciones como estas pueden volverse evidentes:
- Los 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, los conectores de aplicación para actividades no masivas, como los de Epicor, ServiceNow y Workday, requieren una transformación.
- Los scripts se pueden agregar casi en cualquier lugar.
¿Existen ejemplos de cómo otros han configurado operaciones?
Para ejemplos comunes que utilizan estos patrones, consulte Ejemplos de patrones de operación comunes al final de esta página, o refiérase a cada página de actividad individual bajo Conectores.

Patrón de archivo

El patrón de archivo está destinado a ser utilizado con actividades de origen y destino que interactúan con archivos. Se puede usar para almacenar datos inactivos (en su formato de archivo original) de un sistema de producción a un sistema de almacenamiento seguro para su recuperación posterior.

Script(s) o Control de Flujo tools + Actividad de Origen + Script(s) + Actividad de Destino + Script(s)

En este patrón, las actividades de origen y destino pueden asociarse con cualquiera de estos tipos de puntos finales:

^A Si una cadena de operaciones contiene una actividad de API, debe ser la única actividad de API o de solicitud API SOAP en la cadena de operaciones y debe ser la fuente de la primera operación. Es decir, ninguna otra operación puede estar llamando a esta operación desde un script o una acción de operación "en éxito" o "en fallo".

^B Solo se pueden utilizar actividades no masivas en esta ubicación.

Patrón de script

Script(s) o Control de Flujo herramientas + Actividad Objetivo

En este patrón, la actividad objetivo puede asociarse con cualquiera de estos tipos de punto final:

Patrón de transformación

Script(s) o Control de Flujo herramientas + (Grupo: Actividad Fuente + Script[s] o Control de Flujo herramientas) + Transformación + (Grupo: Script[s] o Control de Flujo herramientas + Actividad Objetivo) + Script[s] ^{E, F}

En este patrón, las actividades de origen y/o destino pueden asociarse con cualquier tipo de punto final, 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 operaciones contiene una actividad de API, debe ser la única actividad de API o de solicitud API SOAP en la cadena de operaciones y debe ser la fuente de la primera operación. Es decir, ninguna otra operación puede estar llamando a esta operación desde un script o una acción de operación "en éxito" o "en fallo".

^B Solo se pueden utilizar actividades no masivas en esta ubicación.

^C Se debe incluir al menos una actividad; una transformación no puede existir por sí sola.

^D Si se utiliza una consulta de Salesforce, Salesforce Service Cloud o ServiceMax como actividad fuente, se requiere una actividad objetivo.

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

^F Las operaciones que incluyen una actividad de Salesforce, Salesforce Service Cloud o ServiceMax no pueden contener ninguna otra actividad excepto aquellas asociadas con los API, Base de Datos, Compartición de Archivos, FTP, HTTP, Almacenamiento Local, Almacenamiento Temporal, o Variable conectores.

Patrón de archivo de dos objetivos

El patrón de archivo de dos objetivos se puede utilizar para almacenar datos inactivos (en su formato original) de un sistema de producción a un sistema de almacenamiento seguro para su recuperación posterior.

Script(s) o Control de Flujo herramientas + (Grupo: Actividad Fuente 1 + Script[s]) o Control de Flujo herramientas + Transformación + Actividad Objetivo 1 / Actividad Fuente 2 + Script(s) o Control de Flujo herramientas + Actividad Objetivo 2 + Script(s) o Control de Flujo herramientas ^{C, D}

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

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

Las actividades de origen y destino deben estar asociadas con ciertos tipos de puntos finales dependiendo de dónde se utilicen en el patrón:

Actividad de Origen 1 ^A: Si se utiliza, la primera actividad de origen puede asociarse con cualquier tipo de punto final.
Actividad de Destino 1 / Actividad de Origen 2: La primera actividad de destino (también referida como la segunda actividad de origen) puede asociarse con cualquiera de estos tipos de puntos finales:
- NetSuite
- Salesforce ^{B, D}
- Salesforce Service Cloud ^{B, D}
- SAP
- ServiceMax ^{B, D}
- SOAP
Nota

Una variación de este patrón utilizando HTTP como la actividad intermedia es el patrón de archivo HTTP de dos destinos.
Actividad de Destino 2: La segunda actividad de destino puede asociarse con cualquiera de estos tipos de puntos finales:

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o de solicitud API SOAP en la cadena de operación y debe ser la fuente de la primera operación. Es decir, ninguna otra operación puede estar llamando a esta operación desde un script o una acción de operación "en éxito" o "en fallo".

^B Solo se pueden usar actividades no masivas en esta ubicación.

^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 el API, Base de Datos, Compartición de Archivos, FTP, HTTP, Almacenamiento Local, Almacenamiento Temporal, o Variable conectores.

Patrón de archivo HTTP de dos objetivos

El patrón de archivo HTTP de dos objetivos se puede usar para almacenar datos inactivos (en su formato original) de un sistema de producción a un sistema de almacenamiento seguro para su posterior recuperación utilizando protocolos y servicios HTTP.

Script(s) o Control de Flujo herramientas + Actividad de Origen 1 + Script(s) o Control de Flujo herramientas + Transformación + Script(s) o Control de Flujo herramientas + Actividad de Destino 1 / Actividad de Origen 2 + Actividad de Destino 2 + Script(s) o Control de Flujo herramientas

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

Las actividades de origen y destino deben estar asociadas con ciertos tipos de puntos finales dependiendo de dónde se utilicen en el patrón:

Actividad de Origen 1 ^A: Si se utiliza, la primera actividad de origen puede asociarse con cualquier tipo de punto final.
Actividad de Destino 1 / Actividad de Origen 2: La primera actividad de destino (también conocida como la segunda actividad de origen) puede asociarse con cualquiera de estos tipos de puntos finales:
- HTTP ^C
Actividad de Destino 2: La segunda actividad de destino puede asociarse con cualquiera de estos tipos de puntos finales:

^A Si una cadena de operación contiene una actividad API, debe ser la única actividad API o solicitud API SOAP en la cadena de operación y debe ser la fuente de la primera operación. Es decir, ninguna otra operación puede estar llamando a esta operación desde un script o una acción de operación "en éxito" o "en fallo".

^B Solo se pueden utilizar actividades no masivas en esta ubicación.

^C 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

Script(s) o Control de Flujo tools + (Grupo: Actividad de Origen 1 + Script[s] o Control de Flujo tools) + Transformación 1 + Actividad de Destino 1 / Actividad de Origen 2 + Transformación 2 + Script(s) o Control de Flujo tools + Actividad de Destino 2 + Script(s) o Control de Flujo tools

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

Las actividades de origen y destino deben estar asociadas con ciertos tipos de puntos finales dependiendo de dónde se utilicen en el patrón:

Actividad de Origen 1 ^A: Si se utiliza, la primera actividad de origen puede estar asociada con cualquier tipo de punto final.
Actividad de Destino 1 / Actividad de Origen 2: La primera actividad de destino (también conocida como la segunda actividad de origen) puede estar asociada con cualquier tipo de punto final excepto API, Base de Datos, Compartición de Archivos, FTP, HTTP, Almacenamiento Local, Almacenamiento Temporal, o Variable.
Actividad de Destino 2 ^B: Si se utiliza, la segunda actividad de destino puede estar asociada con cualquier tipo de punto final.

^A Si una cadena de operación contiene una actividad de API, debe ser la única actividad de API o solicitud de API SOAP en la cadena de operación y debe ser la fuente de la primera operación. Es decir, ninguna otra operación puede estar llamando a esta operación desde un script o una acción de operación "en éxito" o "en fallo".

^B Solo se pueden utilizar actividades no masivas en esta ubicación.

^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 el API, Base de Datos, Compartición de Archivos, FTP, HTTP, Almacenamiento Local, Almacenamiento Temporal, o Variable conectores.

Patrón de fuente masiva de Salesforce

Script(s) o Control de Flujo herramientas + Actividad de Origen + Script(s) o Control de Flujo herramientas + Actividad de Destino + Script(s) o Control de Flujo herramientas

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 puede estar asociada con cualquiera de estos tipos de punto final:

Patrón de destino masivo de Salesforce

Script(s) o Control de Flujo herramientas + Actividad de Origen + Script(s) o Control de Flujo herramientas + Actividad de Destino + Script(s) o Control de Flujo herramientas

En este patrón, la actividad de origen puede asociarse con cualquiera de estos tipos de punto final:

La actividad de destino puede asociarse con cualquiera de estos tipos de punto final:

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 bloques de construcción básicos de las operaciones comúnmente construidas y no están destinados a cubrir todas las combinaciones posibles. Consulte los patrones de validez más arriba en esta página para todas las disposiciones posibles.

Script

Una operación puede contener simplemente un único script. En este caso, todas las acciones en la operación son realizadas por el script.

Este patrón se utiliza típicamente al comienzo de un flujo de trabajo para crear un "script de lanzamiento" que ejecuta una o más de varias operaciones de rama basadas en una variable del sistema u otro valor de datos.

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

script de inicio de operación

Archivo

Si todo lo que necesitas hacer es mover archivos de una fuente de datos a un destino, puedes usar una operación sin transformación.

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

Para archivar datos, las actividades de origen y destino están limitadas a aquellas que interactúan con archivos. En lugar de una actividad de origen, también podrías usar un script.

transferencia simple de archivos de operación

Transformación

Las operaciones que utilizan transformaciones sirven a una variedad de casos de uso. Por ejemplo, puedes crear operaciones que (1) transforman datos de una fuente a un destino, (2) transforman datos, luego escriben la respuesta a otro destino, o (3) transforman datos de una llamada a un servicio web al convertir la respuesta de la llamada de la aplicación y escribir en un destino.

La operación transforma datos de la fuente al destino

Este ejemplo extrae datos de una actividad fuente que luego se transforma y se escribe en una actividad objetivo:

operación FTP leer

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

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

Este arreglo de operación, utilizado para obtener un token REST, muestra la respuesta HTTP siendo escrita 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 llamar a un método de servicio web SOAP. La llamada a la aplicación típicamente incluye tanto una estructura de datos de solicitud como de respuesta.

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

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

Llamada a la aplicación

operación insertar Salesforce

Llamada SOAP

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

Errores de operación implícitos

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 paso 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 aseguran que la operación sea compatible y esperada por el agente. Estos patrones se cubren a continuación en Patrones de validación.
El esquema de transformación [fuente / destino] no coincide con la estructura del esquema proporcionado por la actividad ["Nombre de la Actividad"]. Abre la transformación ["Nombre de la Transformación"] en la operación ["Nombre de la Operación"] y actualiza 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 proporcionado por una actividad adyacente.
La transformación ["Nombre de la Transformación"] tiene un esquema de fuente pero no una actividad de fuente. Elimina el esquema de fuente de la transformación o agrega una actividad de fuente antes de la transformación.	Si la operación contiene una transformación con un esquema de fuente proporcionado por la actividad o proporcionado por la transformación, debe haber una actividad de fuente 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 a lo largo del proyecto. La actividad HTTP ["Nombre de la Actividad 1 de Destino"] en esta operación está enviando su respuesta a múltiples actividades de destino a lo largo del proyecto. En esta operación su destino es ["Nombre de la Actividad 2A de Destino"]. En la operación ["Operación 2"] su destino es ["Nombre de la Actividad 2B de Destino"]. Reemplaza la actividad ["Nombre de la Actividad 1 de Destino"] con una actividad duplicada en una de las operaciones. Puedes hacer esto encontrando la actividad ["Nombre de la Actividad 1 de Destino"] en la pestaña de Componentes, abriendo el menú y duplicando. Arrastra 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 que también se utiliza en otra operación de Patrón de Archivo de Dos Destinos debe escribir en la misma actividad de destino. Nota Esta regla de validación puede ser desactivada, aunque no se recomienda hacerlo. Para más información, consulte errores de 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 puede contener solo una actividad de escucha por operación.
"La operación ["Nombre de la Operación"] tiene ["Nombre de la Actividad"] como oyente o actividad basada en eventos -- tales 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 usar 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 Éxito" / "En Fallo" / "En Error SOAP"] hacia la operación de destino ["Nombre de la Operación 2"] que tiene un oyente o 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 una actividad de escucha o basada en eventos ["Nombre de la Actividad"] y no puede tener un horario adjunto."	Una operación que contiene una actividad de escucha no puede ejecutarse en un horario.
"["Nombre del Script"] script 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 una actividad de escucha o basada en eventos.	Una operación no puede usar la función `RunOperation` para invocar otra operación que contenga una actividad de escucha.

Errores de regla 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 de Objetivo 1 escribe una respuesta a una segunda actividad objetivo (Objetivo 2). En este escenario, la regla de validación requiere que una actividad HTTP de Objetivo 1 no se utilice en ninguna otra operación de patrón de archivo de dos objetivos donde la actividad HTTP de Objetivo 1 escriba a una actividad objetivo secundaria diferente.

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

Texto del diálogo

Errores de validación

operationName
Las actividades objetivo HTTP que envían su respuesta a una segunda actividad objetivo solo pueden enviar respuestas a una actividad objetivo a lo largo del proyecto. La actividad HTTP activityName en esta operación está enviando su respuesta a múltiples actividades objetivo a lo largo del proyecto.

En esta operación, su objetivo es targetName. En la operación otherOperation, su objetivo es otherTarget.

Reemplace la actividad activityName con una actividad duplicada en una de las operaciones. Puede hacer esto encontrando la actividad activityName en la pestaña de Componentes, abriendo el menú y duplicando. Arrastre la actividad duplicada a la operación.

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:

Duplicar la actividad objetivo HTTP en la posición de Objetivo 1 de una de las operaciones que utilizan el patrón de archivo HTTP de dos objetivos.
Reemplace la actividad objetivo HTTP en la posición de Objetivo 1 de la(s) operación(es) identificada(s) con la copia duplicada:
Repita para cualquier operación inválida adicional. Una vez que se resuelvan los errores de validación, vuelva a implementar las operaciones.

Desactivar la regla de validación HTTP

En ciertas situaciones, puede ser deseable desactivar esta regla de validación HTTP de la siguiente manera:

Abre la configuración del proyecto:
En la pestaña Desplegar, desactiva Regla de Validación HTTP:
Haz clic en Guardar.

Una vez desactivada y guardada la configuración, los errores de validación de operación reportados debido a este error deberían resolverse. Sin embargo, ten en cuenta que cualquier actividad de Objetivo 1 HTTP utilizada en una operación de patrón de archivo de dos objetivos escribirá en la actividad de Objetivo 2 de la última operación desplegada. Esto puede causar que se escriban datos inválidos.

Precaución

Usar esta configuración para desactivar la regla de validación HTTP no se recomienda y puede resultar en la escritura involuntaria de datos inválidos en las actividades de destino en operaciones que utilizan el patrón de archivo de dos objetivos.

Rehabilitar la regla de validación HTTP

Si has desactivado previamente la regla de validación HTTP y estás listo para volver a habilitarla, sigue estos pasos:

Abre la configuración del proyecto.
En la pestaña Desplegar, habilita Regla de Validación HTTP.
Haz clic en Guardar. Ten en cuenta que este es un cambio en el tiempo de diseño y que esta acción no despliega ningún cambio en la nube de Harmony.
Resuelve cualquier error de validación HTTP (consulta Resolver errores de validación HTTP arriba).
Vuelve a desplegar el proyecto (consulta Despliegue del proyecto).

Nota

Antes de la nueva implementación, se permite la ejecución de cualquier operación que ahora sea inválida, ya que Harmony ejecuta las operaciones actualmente desplegadas. Se requiere la nueva implementación de las operaciones afectadas para que los cambios se propaguen a Harmony.

It seems there was no Markdown content provided for translation. Please provide the text you would like me to translate into Mexican Spanish.