Si tu empresa te ha alertado sobre un inminente cambio de servidor de Salesforce por parte del proveedor de CRM, aquí tienes un proceso paso a paso para garantizar una transición sin problemas. A medida que Salesforce continúa creciendo como proveedor líder de CRM basado en la nube, las empresas están aumentando su uso de la plataforma. Con este crecimiento, la capacidad del servidor de Salesforce se ha extendido más allá de sus capacidades originales, lo que ha llevado a la empresa a adquirir más servidores en todo el mundo. Como resultado, Salesforce ha comenzado a dividir servidores y trasladar algunas empresas a las nuevas casas de datos adquiridas. Esto significa que algunas empresas cambiarán de instancia para su entorno de producción, lo que cambia la URL directa de esa instancia. Si el equipo de Salesforce de una empresa utiliza las mejores prácticas y no codifica las URL, este proceso debería ser bastante fácil. Pero se requiere una evaluación exhaustiva de la instancia para garantizar que esto se ejecute sin problemas. Aquí están los pasos a seguir si te han notificado que te están trasladando a un nuevo servidor de Salesforce.
Paso 1: Alerta a los principales interesados de este cambio
Cuando una instancia se cambia a un nuevo servidor, los cambios ocurren rápidamente tanto durante como después del cambio. Es importante identificar a los principales interesados y mantenerlos actualizados sobre el proceso. Durante el cambio, cualquier usuario que intente acceder a la plataforma de Salesforce no podrá hacerlo o solo podrá acceder al servidor en modo de solo lectura. Esto podría afectar a los centros de contacto 24/7 que utilizan teléfonos suaves a través de Salesforce o registran casos dentro de Salesforce con fines de seguimiento. Estos grupos necesitan tanto tiempo como sea posible para identificar soluciones alternativas cuando el servidor de Salesforce esté inactivo, lo que podría ser hasta tres horas. Además, cualquier usuario que haya guardado el inicio de sesión en Salesforce como página de inicio, en lugar de la página login.Salesforce.com, no podrá acceder a su cuenta a pesar de haber utilizado un correo electrónico y una contraseña correctos. El departamento de TI debe ser consciente de esto al solucionar problemas potenciales una vez que se realice el cambio. Además, cualquier grupo que tenga conexiones con los puntos finales de Salesforce puede necesitar cambiar los puntos finales si hacen referencia al nombre del servidor, como las conexiones a un sistema de inicio de sesión único.
Paso 2: Identificar áreas codificadas
Se puede descargar una aplicación gratuita, Eclipse, en línea y sincronizarla con tus instancias. Todo lo que necesitas hacer es agregar el complemento de Salesforce después de la descarga. Esta debería ser la única herramienta que necesitas para identificar dónde se ha codificado tu instancia, y es probable que tus desarrolladores ya utilicen esta herramienta y puedan hacer una ejecución rápida por ti. Por ejemplo, si cuando inicias sesión en tu instancia la URL es https://na9.salesforce.com, querrás ejecutar un escaneo de la instancia en todas las referencias a “NA9”. Para organizaciones grandes, para dividir tu ejecución de Eclipse, ejecuta una búsqueda en todas las clases de Apex primero, luego en los objetos, etc. Una vez que hayas realizado todas tus búsquedas, tendrás una lista completa de todas las áreas de Salesforce donde se ha hecho referencia a la URL. Áreas a las que prestar especial atención:
- Clases de Apex
- Plantillas de correo electrónico
- Flujos de trabajo
- Botones (dentro de cada objeto)
- Configuraciones personalizadas
- Páginas de Visualforce
- S-Controls
Paso 3: Mover la mayor cantidad posible a URLs dinámicas
Si es posible, las referencias a la URL deben ser dinámicas y se debe eliminar la referencia al servidor real. Los desarrolladores deben realizar cambios en cualquier referencia dentro del código Apex o en áreas de Visualforce, y los administradores deben poder realizar cambios en cualquier botón, configuración personalizada, plantilla de correo electrónico o flujo de trabajo. Como ocurre con todo desarrollo, esto debe hacerse en un sandbox inferior, luego probarse en UAT, antes de realizar cualquier cambio en producción.
Paso 4: Cambiar
En la noche del cambio, generalmente programado durante el fin de semana por Salesforce, cualquier grupo que utilice Salesforce las 24/7 solo podrá acceder a la instancia en modo de solo lectura. Las reconexiones a cualquier fuente de terceros, como inicio de sesión único o portal que no se haya trasladado a una referencia dinámica, deberán restablecerse. Además, cualquier referencia en áreas de administración o desarrollo que no se haya vuelto dinámica deberá cambiarse. Debido a que este puede ser un movimiento bastante grande para instancias más antiguas y grandes, los equipos deben asignar tiempo para realizar pruebas de regresión completas de la funcionalidad clave una vez que se realice el cambio. Los cambios de servidor no tienen por qué ser una tarea dolorosa si hay una preparación adecuada por parte de los principales interesados. La mejor defensa es un buen ataque, por lo que crear URLs dinámicas desde el principio permite menos trabajo durante una ventana de mantenimiento de un sábado por la noche y menos probabilidades de experimentar problemas. Trabajar entre el departamento de TI y el negocio una vez que se programa dicho cambio también es importante para identificar todas las áreas que necesitan cambios y brindar soporte una vez que se realiza el cambio.
