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:

resaltar elementos no válidos

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:

operación no válida

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

operación inválida

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:

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 patrones de operación establecidos que garanticen que la operación sea respaldada y esperada por el agente. 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 actividad"]. Abra la transformación ["Transformación Name"] en la operación ["Operation Name"] y actualice el esquema de destino.	En una operación que contiene una transformación con un esquema proporcionado por 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 tiene 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 durante todo el proyecto. La actividad HTTP ["Nombre de actividad de destino 1"] en esta operación envía su respuesta a múltiples actividades de destino a lo largo del proyecto. En esta operación su objetivo es ["Nombre de actividad del objetivo 2A"]. En la operación ["Operación 2"] su objetivo es ["Nombre de actividad del objetivo 2B"]. Reemplace la actividad ["Nombre de actividad objetivo 1"] con una actividad duplicada en una de las operaciones. Puede hacer esto buscando la actividad ["Nombre de 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 objetivos y contiene una actividad de destino HTTP que escribe una respuesta a una segunda actividad de destino, y la actividad de destino HTTP también se utiliza en otro Patrón de archivo de dos objetivos la operación debe escribir en la misma actividad de destino. Nota Esta regla de validación se puede deshabilitar, aunque no se recomienda hacerlo. Para obtener más información, consulte Errores de reglas 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 actividad"]".	Una operación puede contener sólo una actividad de escucha por operación.
"La operación ["Nombre de la operación"] tiene ["Nombre de la actividad"] como escucha o 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 el actividad de escuchar. 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 como resultado ["En caso de éxito" / "En caso de error" / "En caso de error SOAP "] a la operación de destino ["Nombre de la operación 2"] que tiene un oyente o basada en eventos como primera actividad."	Una operación no puede utilizar 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 una programación adjunta".	Una operación que contiene una actividad de escucha no se puede ejecutar según una programación.
La secuencia de comandos "[" Secuencia de Comandos Name"] en la operación ["Operation Name"] no puede utilizar RunOperation() para invocar la operación ["Operation Name 2"] que tiene una actividad de escucha o basada en eventos.	Una operación no puedo usar el `RunOperation` función para invocar otra operación que contiene una actividad de escucha.

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

archivo de patrón de operación anotado 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 de 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 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 de patrón de operación 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 anotada pp

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

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

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 destino deben estar asociadas con ciertos tipos de extremo dependiendo de dónde se usan 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 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

patrón de operación dos archivos HTTP de destino anotados pp

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:

^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

patrón de operación dos transformación anotada pp

Secuencia de Comandos(es) + (Grupo: Actividad fuente 1 + Secuencia de Comandos[s]) + Transformación 1 + Actividad objetivo 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 destino deben estar asociadas con ciertos tipos de extremo dependiendo de dónde se usan 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

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

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 objetivo masivo de Salesforce pp anotadas

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

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 elementos 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.

secuencia de comandos de inicio de 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, 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.

operación simple transferencia 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 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 los datos de 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:

operación lectura FTP

La Operación Transforma los 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:

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

operación inserción de Salesforce

Llamada de SOAP

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

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 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 de 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 Destino 1 de una de las operaciones utilizando el patrón de archivo de dos objetivos:
Reemplace la actividad de destino HTTP en la posición Destino 1 de las operación identificadas con la copia duplicada:
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:

Abra la configuración del proyecto:
En la pestaña Desplegar, deshabilite la Regla de validación HTTP:
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.

Precaución

No se recomienda el uso de esta configuración para deshabilitar la regla de validación HTTP y puede resultar en la escritura involuntaria de datos no válidos para apuntar a actividades en operaciones que utilizan el patrón de archivo de dos objetivos.

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:

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