Vimos en la entrada anterior las alternativas para almacenar información confidencial en Salesforce y vimos que el mecanismo preferido inicialmente, era la creación y despliegue de un Protected Custom Metadata Type.

En este artículo veremos paso a paso y en detalle:

  • La arquitectura recomendada por Salesforce para el Managed Package y asegurar la confidencialidad de la información (y alguna variante que propongo).
  • Cómo construir y configurar el Custom Metadata Type que albergue esa información.
  • Cómo desplegar el paquete en la ORG destino.

Durante estas fechas (Navidades),  es fundamental saber guardar ciertos secretos 😉 .

Saber qué secretos ocultar, a quién y a quién no ocultarlos, y cuanto esfuerzo nos a va suponer ocultarlo. Aparecen varias opciones y así no romper la magia de los más pequeños demasiado pronto.

Sucede de igual manera en Salesforce cuando deseamos almacenar secretos o información confidencial.

Desde hace ya mucho, para los lenguajes de programación más comunes, disponemos de analizadores de código estático.

Existen varias herramientas en el mercado, para el análisis de código Apex (Checkmarx utilizada por Salesforce, Sonarqube, Cosechan, Codacy, etc.) pero desde abril de 2016, Robert Sösemann portó Apex a PMD, una de las herramientas más conocidas de análisis de código y con licencia Open Source (Hiper-Kudos para Robert), con años de experiencia como una de las soluciones líderes en Java.

PMD para Apex y Visualforce (aún incipiente) no requiere de ninguna infraestructura adicional, solo descargar los binarios y ejecutarlos, en nuestro ordenador, en el servidor, con la JDK instalada etc.

Las capacidades de PMD, su licenciamiento, versatilidad, extensibilidad, integración con los IDEs y con  herramientas de CI habituales (Maven, Ant, Gradle, etc.), y comunidad facilita enormemente su adopción.

Por ello, si no lo conoces, creo que puede ser muy útil, y es una herramienta muy a tener en cuenta para utilizar en nuestros proyectos. Te animo a leer el artículo por si te puede ayudar.

El proceso

Veamos cual es el proceso para desplegar en una ORG.

Despliegue por diferencias

El proceso de despliegue en Salesforce, a diferencia de, por ejemplo, en el mundo Java, no se realiza desplegando un fichero .ear/.war que contiene todos los componentes y sustituye de forma completa al anterior , sinó que se realiza mediante el despliegue de los componentes añadidos/modificados y listando aquellos que queremos eliminar, lo que se suele llamar incremental, por diferencias (en adelante usaré este último término).