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.

Ayer, 06/11 tuvimos el evento de Dreamforce Gathering 2018 en Barcelona, conjuntamente el grupo de Developers y Administradores de Salesforce.

Primero de todo agradecer a Cognizant, por ceder sus oficinas, y a los organizadores Pablo García, David Sánchez y Roger Borges, por la magnífica organización (dedicando su tiempo), lo interesante del evento y el buen rollo que uno siente en estos eventos.

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 esta entrada me centraré, en cómo diseñar la ejecución de Procesos Asíncronos Apex (en adelante Apex Async), aprovechando las capacidades de la plataforma.

Pero lo haré de manera invertida a como se hace habitualmente, donde se explica como programar los mecanismos de programación. Pero en IMMO, si los desarrolladores, arquitectos y administradores, entendemos bien como gestiona Salesforce los procesos asíncronos, sus colas de Espera y Ejecución, sus límites asociados, etc., la elección del mecanismo de programación, es muy sencilla u obvia.

Una de las novedades que quizás pasaron inadvertidas en la última release de Winter ’18, fue la nueva versión de la BULK API, denominada BULK API v2, disponible en v41.0.

Esta nueva versión, sigue siendo una API REST, que utiliza los verbos HTTP para crear Jobs, cerrar/abortar, eliminar y obtener información al respecto, aportando novedades para el programador y una mejora del rendimiento para el usuario final.

En esta entrada, se muestran las diferencias entre ambas versiones y se compara el rendimiento.

En la entrada anterior, describía el caso de uso de cómo acceder a una gran volumen de datos desde nuestra ORG via External Objects, y dejaba la puerta abierta a la alternativa a la funcionalidad nativa de Big Objects en Salesforce.

Esta entrada describe qué son, en qué casos de uso pueden aplicarse, cómo crearlos, insertar datos (con Data Loader que parece ser un caso poco documentado) y describir sus características y restricciones, que no son pocas.