Existen muchos artículos sobre los comandos que podemos lanzar con la linea de comandos de Salesforce, la llamada Salesforce CLI.

Pero en muchas ocasiones, me pregunto si al mostrar todos esos comandos, conseguimos realmente transmitir las capacidades y los beneficios que la CLI puede aportar a todos, sin excepción.

Por este motivo, este artículo tiene un enfoque completamente distinto.

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.

En la última entrada sobre Optimización de Queries en Salesforce, destapaba unos de los problemas más evidentes de cualquier proyecto: la degradación de rendimiento de los elementos que consultan datos en Salesforce.

Es decir, a medida que nuestra ORG crece, las consultas que inicialmente diseñamos (que quizás optimizamos o quizás no) pueden sufrir degradación. Pero no estoy hablando sólo de las Queries de los Developers con SOQL, estoy hablando de List Views, Reports y Dashboards que crean los usuarios.

Vimos en la entrada anterior que el objetivo de la optimización de consultas es conseguir:

  • Obtener el menor coste posible, es decir el mejor plan de ejecución
  • Que este coste sea inferior a 1, significando que la consulta es selectiva utilizando los índices creados

Como desarrolladores o administradores necesitamos validar si una consulta será selectiva antes de llegar a Producción, y mejorar su rendimiento.

Un tema fundamental al que nos enfrentamos es conseguir que las Queries, Reports, Dashboards, List Views que construimos tengan el mejor rendimiento posible (muchas veces fueron escritas por otros compañeros hace un tiempo).

Desde hace un tiempo quería dedicar una serie de entradas al diseño y optimización de Queries y habiendo finalizado la certificación de Data Architecture and Designer es el momento ideal.

En esta serie de entradas trataré estos 8 aspectos:

En la entrada anterior describí que era la anomalía en los datos llamada Data Skew en Salesforce. Y aunque ese es el primer paso, lo realmente útil, en nuestro día a día, es poderlo detectar con antelación.

No conozco qué Salesforce ofrezca, ninguna utilidad para la localización de Data Skew, aunque anticiparnos a qué suceda en nuestra ORG, puede suponer ahorrarnos muchos dolores de cabeza.

Por ello, he desarrollado una utilidad en APEX que permite analizar tu ORG, y encontrar todos los campos con Data Skew. Disponer de esta información puede ahorrar problemas a los usuarios de tu ORG, espero que te sea de ayuda .