Buenas prácticas para Rainbow Extensions

Puede utilizar este artículo como lista de comprobación antes de crear, probar o implementar un «custo-manifest» en producción. Úselo para que su manifiesto sea fácil de mantener, seguro y más sencillo de depurar.

Creación

• Comience a partir de una plantilla exportada por Rainbow Desktop o de un manifiesto ya validado.
• Elimine los puntos de extensión no utilizados antes de la implementación en producción.
• Mantenga la versión establecida en «2» y jsonType en «Rainbow-custo-manifest».
• No defina más de tres acciones para un mismo punto de extensión.
• Evite las rutas codificadas de forma fija desde el equipo de un desarrollador. Utilice ${custo.path} e incluya los recursos en un archivo ZIP.

Seguridad

• Declare todos los orígenes REST e iframe en los dominios de Custo-manifest antes de la implementación.
• Dé preferencia a los puntos finales HTTPS con nombres DNS estables.
• Para las API REST, configure CORS de forma explícita y compruebe las solicitudes de preflight del navegador.
• En el caso de los servidores de redes locales o privadas, compruebe el comportamiento de Rainbow Web con las reglas de acceso a la red local.
• No incluya secretos directamente en un manifiesto distribuido a sus usuarios. Prefiera tokens del lado del servidor o credenciales de corta duración siempre que sea posible.

Variables

• Utilice la variable más específica disponible para el punto de extensión.
• Pruebe las variables con llamadas, contactos y burbujas realistas; algunos valores quedan vacíos cuando falta el contexto.
• Utilice expresiones regulares solo para transformaciones sencillas. Las transformaciones complejas deben realizarse del lado del servidor.
• Compruebe los formatos de los números de teléfono en las implementaciones de Cloud PBX, OmniPCX Enterprise y OXO Connect.

Tarjetas adaptativas

• Mantenga las tarjetas breves y centradas en la acción del usuario.
• Pruebe la visualización en Rainbow Web y Rainbow Desktop.
• Evite los elementos de Adaptive Card 1.6+ que no sean compatibles, a menos que la versión del cliente Rainbow de destino los admita explícitamente.
• Para Action.Submit, haga que el punto final de destino sea idempotente y proporcione una respuesta clara al usuario.

Validación previa a la producción

• Valide la sintaxis JSON.
• Pruebe la importación local antes de la implementación centralizada.
• Pruebe el manifiesto en la web y en el escritorio cuando ambos clientes sean el objetivo.
• Compruebe todos los dominios de confianza, los encabezados CORS y los encabezados de iframe.
• Implemente primero en un usuario o perfil piloto antes de proceder a un despliegue más amplio.
• Conserve una copia del manifiesto anterior para que la reversión sea inmediata.