Blog

Dejaré esta entrada como recordatorio y como evidencia de como se comporta el límite de 50,000 eventos diarios de Salesforce, con suscripciones mediante componentes Lightning.

Primero que nada, para saber cuantos eventos has consumido diariamente, solo se puede hacer mediante la API REST de Salesforce, si aún existe la herramienta workbench de salesforce gratuita, la cual tiene acceso a esta API, lo puedes hacer de la siguiente manera:

Tienes que ir al menú Utilities, REST Explorer y seleccionar lo que muestro en la siguiente imagen para ver los límites de Salesforce.

Luego damos clic en DailyStandardVolumePlatformEvents, con esto podremos ver la cantidad máxima de eventos estándar por día, en este caso el límite es de 50,000 y la otra cantidad son los eventos que quedan disponibles.

El problema o detalle, como lo quieras ver, es que esa cantidad restante NO SE RESTABLECE a medianoche o luego de transcurrir 24 horas, entonces, ¿cómo funciona el límite diario de los eventos estándar?, ¿cuándo se restablece el valor?

Aquí mis conclusiones: conforme se crean eventos en Salesforce, el “restante” va disminuyendo, y esa es la cantidad que de eventos que te quedan para crear. Según la documentación de Salesforce, según la licencia de tu organización tienes un límite por día y por hora.

Esperaba que luego de 24 horas esa cantidad se restableciera de un solo golpe, pero no ocurre así, sino que el “restante” se va incrementando según pasan las horas. Lo que me hace suponer que al crear un evento, éste tiene una vida de 24 horas, con lo cual el restablecimiento sucede conforme esa vida del evento.

¿Qué se toma en consideración para disminuir la cantidad restante?

Suponía que al momento de crear un evento en Salesforce, como se muestra en las siguientes imágenes, el contador (Remaining) empezaba a disminuir:

---

La forma en que Salesforce empieza a disminuir la cantidad restante de eventos (por lo menos en las suscripciones mediante componente Lightning), es mediante el atributo empApi, que se implementa en el componente de lightning que hayas creado.

Cada vez que se publica (publish) un evento, la función callback es invocada y allí es donde realmente empieza a disminuir el contador de los eventos.

Ahora, imagina que tienes a dos usuarios cada uno en un navegador diferente, en la misma página en donde se realiza la suscripción y ambos clientes están “escuchando”, a la espera de eventos, bueno pues una vez que se hace la publicación (publish) del evento, en ambos navegadores se despliega el evento, con lo cual en lugar de que se haya descontado un solo evento, se disminuyen dos. Con cada navegador abierto, en la página donde se usa el componente para “escuchar” los eventos, se consume un evento.

Un ejemplo más sencillo, supongamos que ahora son 10 usuarios cada uno en su navegador, en la misma página de Salesforce en donde se tiene el componente que se suscribe a la espera de algún evento, se hace un EventBus.publish, (imagen 2) y luego el componente que esta “escuchando” gracias a que ya esta “suscrito” (imagen 3), detecta que se publicó un evento y lo “muestra” o “ejecuta” en cada uno de los navegadores, con lo cual la cantidad restante (Remaining) de DailyStandardVolumePlatformEvents , se disminuye en 10.

En Salesforce es posible subir archivos (imágenes, documentos, etc.) y compartirlos con los mismos usuarios del CRM o con grupos públicos.

En el caso de que quieras compartir archivos, lo recomendable es crear una biblioteca, que viene a ser una carpeta, en donde colocarías los archivos que quieras compartir.

A continuación te describo los pasos para crear una biblioteca de archivos y como administrar sus permisos.

Crear una nueva biblioteca

Seleccionamos el objeto Archivo o Files y se mostrará la siguiente pantalla, en donde crearemos una nueva biblioteca.

A continuación proporcionamos Nombre, Descripción y una imagen que representará dicha carpeta/biblioteca.

Gestionando los usuarios

Una vez creada la biblioteca, ya podemos cargar archivos, pero si queremos compartir el contenido de esa carpeta, damos clic en Gestionar miembros

Veremos que hay dos tipos de miembros, los grupos públicos y personas. Y en el lado derecho tenemos los accesos, los cuales por default solo se tiene disponible Administrador de biblioteca, que tiene privilegios de Crear, Editar y Eliminar.

Habilitando más accesos a la biblioteca

Si queremos dar permisos o acceso de solo lectura, tendremos que habilitar dicha configuración de archivos mediante los siguientes pasos:

1. Ir a Configuración
2. Configuración de funciones
3. Salesforce Files
4. Salesforce CRM Content
5. Habilitar la casilla “Activar Salesforce CRM Content“

Con el paso anterior, ahora tendremos habilitado más opciones en la sección de Acceso, como se muestra en la siguiente imagen:

En el mundo de los componentes lightning nos encontraremos con los archivos controller.js y helper.js, si quieres hacer el mejor uso o mejor dicho las mejores practicas, aquí te detallo brevemente cual es la diferencia entre uno y otro y en donde deberías colocar tus funciones.

Supongamos que contamos un componente AccountList, el cual contiene a su vez el componente AccountCmp dos veces.

<c:AccountList>
   <c:AccountCmp id="1" />
   <c:AccountCmp id="2" />
</c:AccountList>

De manera visual el componente AccountList, se mostraría como en la imagen de la izquierda, pero mientras se ejecuta, se visualiza como en la imagen de la derecha.

Cada componente (paquete) esta compuesto por un marco (color amarillo), un archivo controller.js (verde), un helper.js (rojo), un renderer.js (morado) y otros.

Pero al momento de “estar corriendo”, el framework crea una instancia del controller, una instancia del renderer para cada componente, pero crea una sola copia del helper, y pasa la referencia del helper a cada instancia del controller y renderer.

Nota importante:
En caso de que tuviésemos diferentes componentes, por ejemplo, AccountItem.cmp y AccountDetails.cmp, cada tipo de componente tendrá su propio Helper, es decir, no se comparte como en el ejemplo anterior.

Ventajas

• Dado que en Helper es compartido a traves de todos los componentes, nos permite compartir y mantener la lógica de Controllers y Renderers en un solo lugar.
• También nos ayuda a mantener la lógica dentro de Controllers y Renderers “delgados”

Por lo tanto, debemos intentar delegar la lógica empresarial a los Helpers siempre que sea posible.

Por ejemplo, en lugar de tener lo siguiente:

// controller.js
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   var action = cmp.get("c.getAccounts"); 
   $A.enqueueAction(action); 
}

Deberíamos hacer lo siguiente:

// controller.js
callServer: function(cmp, helper) {
  helper.callServer();
}

//helper.js (compartido a traves de toda las instancias de controllers y renderers)
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   helper.callServer();
}

¿Cuándo usar Controller vs Helper?

• Usa los Controllers para escuchar eventos de usuario y otros eventos como componentes, eventos de aplicaciones. Pero delega la lógica de negocio al Helper.
• Delegar de manera similar en todas las funciones de Renderer (render, rerender, etc.).
• Cuando necesites llamar a una función de controlador desde otra función de controlador, mueve esa lógica al Helper.

Anti-patrón

Demasiadas funciones en el Helper: si llegas a tener esta situación, lo más conveniente será refactorizar o descomponer el componente en subcomponentes más pequeños.

No es posible declarar una variable global en los componentes lightning, específicamente en los archivos controller.js y helper.js, pero podemos crear un atributo ( aura:attribute ) en el componente que puede ser usado para almacenar información y puede ser usado en el controller o en el helper de manera global.