Salesforce CRM es utilizado por una variedad de empresas de todos los tamaños y en diferentes industrias. Salesforce ha estado involucrado en la administración efectiva de datos de clientes durante más de dos décadas. Tiene varios conceptos y prácticas revolucionarios, así como la capacidad de acceder a sus datos en cualquier lugar y en cualquier momento. Esta plataforma cuenta con una gran cantidad de servidores repartidos por todo el mundo, y la organización en la que trabajas también sería uno de ellos. Estos servidores tienen bases de datos y máquinas masivas, y son tan poderosos que cada servidor puede albergar muchas instancias de Salesforce de diferentes corporaciones.
Desarrolladores de Salesforce ofrecer una variedad de servicios a sus clientes que se adaptan con precisión a sus necesidades. Ayudan en el diseño, desarrollo y personalización de una variedad de productos, plataformas y aplicaciones de Salesforce para satisfacer las demandas de sus clientes. Pero siempre existen reglas donde hay recursos finitos y Salesforce no es una excepción.
Desarrollo de Salesforce y las operaciones no están exentas de restricciones y regulaciones. Los desarrolladores de Salesforce deben cumplir con varias pautas al realizar modificaciones significativas en el sistema al usar el Plataforma Salesforce CRM. Y la mayoría de estas reglas y regulaciones incluyen Límites del gobernador de Salesforce.
¿Qué es la arquitectura multiusuario?
Para entender el Límites del gobernador en Salesforce y cómo limitan las operaciones de los desarrolladores de Salesforce, primero es crucial comprender el concepto de una arquitectura multiusuario. La tenencia múltiple se refiere al método de operación del software en el que múltiples instancias independientes de uno o más programas comparten un entorno común.
Arquitectura multiusuario en palabras más simples es cuando una sola plataforma de software (o cualquier plataforma en general) es utilizada por varios usuarios. Debido a que todos los operadores utilizan la misma versión y diseño de la plataforma, Salesforce CRM entra en la categoría de arquitectura multiusuario.
Aquí hay un ejemplo para ayudarlo a entender:
Considerar Multiusuario de Salesforce simplemente como alquilar un apartamento en un edificio. La electricidad, el gas y el ancho de banda de wi-fi son recursos compartidos para cada edificio del apartamento.
Ahora si numerosos pisos empiezan a enchufar electrodomésticos pesados capaces de consumir toda la electricidad. Piensa qué pasaría si otros pisos comenzaran a descargar archivos pesados de Internet.
Incluso si pagó una prima, sería un desafío vivir en un piso donde no podría recibir la electricidad adecuada o un ancho de banda Wi-Fi confiable.
En este caso, los apartamentos son organizaciones independientes de Salesforce y el complejo de apartamentos es un servidor de Salesforce. Y esta distribución de recursos compartidos es una arquitectura multiusuario.
Hay un término más usado, es decir, Plataformas de inquilino único, y la diferencia entre las plataformas de inquilino único y multiusuario es que el inquilino único requiere que los usuarios lo actualicen periódicamente.
Las plataformas multiinquilino, por otro lado, se actualizan regularmente y distribuyen actualizaciones uniformes a todos sus usuarios. Cuando se trata de Salesforce, es un CRM basado en la nube, para que los usuarios no tengan que preocuparse por el mantenimiento del software y el hardware de Salesforce Platform.
También, lea: ¿Qué es Salesforce Health Cloud? Sus características y beneficios
¿Cuáles son los límites del gobernador de Salesforce?
Límites del gobernador de Salesforce se conocen comúnmente como Límites del gobernador de Apex porque están relacionados con las personalizaciones y modificaciones de Apex.
El motor de tiempo de ejecución de Apex hace cumplir estas limitaciones de tiempo de ejecución para desarrollar un código escalable y eficiente y evitar que los procesos monopolicen los recursos compartidos.
Límites del gobernador en Salesforce son un conjunto vital de reglas que hicieron de Salesforce la plataforma de gestión de relaciones con los clientes (CRM) más popular y autorizada del mundo.
Límites del gobernador de Salesforce, para decirlo en términos simples, son límites de uso impuestos por Salesforce para garantizar un procesamiento eficiente. Esto permite que múltiples usuarios accedan a la plataforma al mismo tiempo sin ralentizarla.
Esto es fundamental ya que cada entorno de programación tiene su propio conjunto de estructuras, capacidades y limitaciones. Todos los programas, servicios y aplicaciones de la plataforma se ejecutan en un entorno multiinquilino, lo que significa que sus recursos, como la memoria, la red y las conexiones a la base de datos, se comparten con todos los demás programas de la plataforma. Como resultado, la plataforma debe protegerse contra el rouge y las aplicaciones que abruman los recursos del sistema.
Cada desarrollador debe asegurarse de que su código sea escalable correctamente y no viole los límites. Por lo tanto, es crucial seguir las regulaciones para evitar que los desarrolladores desperdicien recursos.
Si alguno de los Límites del gobernador de Salesforce se exceden o no se cumplen, se generará un error y se notificará a los usuarios a la brevedad. Entonces, el programa del usuario se cerraría debido a este error.
También, lea: ¿Qué es la gestión de territorio empresarial de Salesforce?
Tipos de límites reguladores en Salesforce
Aquí hay una hoja para los límites del gobernador de Salesforce que resume los límites más importantes que todos deben conocer:
| General | Límite del gobernador |
|---|---|
| El número total de consultas SOSL emitidas en Salesforce | 20 |
| Límites del regulador DML en Salesforce (Número total de extractos emitidos por transacción) | 150 |
| Número total de registros recuperados por una sola consulta SOSL | 2000 |
| Número total de registros recuperados por consultas SOQL | 50000 |
| Número total de registros recuperados por Database.getQueryLocator | 10000 |
| Límites del gobernador de Salesforce para el tamaño total del almacenamiento dinámico | 6 MB / 12 MB |
Los siguientes son los límites del gobernador de Apex en Salesforce:
1) Límites de Apex por transacción:
Los límites de Apex se aplican por transacción y se cuentan para cada transacción de Apex. Estos límites específicos en el método de ejecución para ejecutar cada lote de registros se restablecerán al usar Batch Apex.
Las restricciones para la sincrónico y ápice asíncrono se resumen en la siguiente tabla:
| Factor | Límite síncrono | Límite asíncrono |
|---|---|---|
| Total de consultas SOQL emitidas | 100 | 200 |
| Total de registros recuperados por consultas SOQL | 50,000 | |
| Registros totales recuperados por Database.getQueryLocator | 10,000 | |
| Total de consultas SOSL emitidas | 20 | |
| Registros recuperados por una sola consulta SOSL | 20,000 | |
| Total de extractos DML emitidos | 150 | |
| Registros totales procesados por declaraciones DML | 10,000 | |
| Profundidad de pila para la invocación de Apex | 16 | |
| Total de llamadas en una transacción | 100 | |
| Métodos permitidos por invocación de Apex | 50 | 0 en contextos por lotes y futuros, 1 en contexto en cola |
| Número de trabajos de Apex agregados | 50 | 1 |
| Todos los métodos de envío de correo electrónico permitidos | 10 | |
| Tamaño total del almacenamiento dinámico | 6 MB | 12 MB |
| máx. Tiempo de CPU en servidores de Salesforce | Milisegundos 10,000 | Milisegundos 60,000 |
| Tiempo de ejecución para la transacción de Apex | 10 minutos | |
| máx. notificaciones push por transacción de Apex | 10 | |
| Máximo de notificaciones push enviadas a través de cada llamada de método de notificación push | 2000 |
2) Límites de paquetes administrados certificados por transacción
Estos son los límites que se imponen a los paquetes gestionados y son diferentes de los límites que se aplican al vértice que no forma parte del paquete gestionado.
Si un paquete gestionado creado por un ISV de Salesforce ha pasado una evaluación de seguridad, los límites por transacción suelen ser más altos.
| Factor | <div style="margin-top:15px">Límite</div> |
|---|---|
| Total de consultas SOQL emitidas | 1100 |
| Total de registros recuperados por Database.getQueryLocator | 110000 |
| Número de consultas SOSL emitidas | 220 |
| Total de declaraciones DML emitidas | 1650 |
| Llamadas totales en una transacción | 1100 |
| Todos los métodos de envío de correo electrónico permitidos | 110 |
Para los paquetes administrados certificados, todas las restricciones de transacciones se aplican individualmente, excepto:
- Tamaño total del almacenamiento dinámico
- Tiempo máximo de CPU
- Tiempo máximo de ejecución de transacciones
- Número máximo de espacios de nombres únicos
También, lea: Pipedrive vs Salesforce: ¿Qué CRM es mejor para tu negocio?
3) Límites de Apex de la plataforma Lightning
Estos son el Límites del gobernador establecido por Salesforce Lightning Platform. Ninguno de estos límites se aplica a las transacciones de Apex ejecutadas por los desarrolladores.
| Descripción | <div style="margin-top:15px">Límite</div> |
|---|---|
| La cantidad máxima de ejecuciones de métodos asincrónicos por día | 25,000 |
| Clases apex programadas en paralelo | 100 |
| Trabajos de Apex en cola | 5 |
| máx. lotes enviados | 5 |
| Usuario/cursores de consulta abiertos en paralelo | 50 |
| Usuario/cursores de consulta abiertos en paralelo | 15 |
4) Límites estáticos de Apex
Estos son el límites del gobernador del vértice establecido para el vértice estático, que se aplica a diferentes tipos de consultas, llamadas, registros, bucles y tamaños de lote, así como a diferentes transacciones realizadas por los usuarios.
| Descripción | Límites |
|---|---|
| El tiempo de espera predeterminado para llamadas de transacciones | 10 segundos |
| máx. tamaño de la solicitud de llamada o respuesta | 6 MB (sincrónico) 12 MB (Asíncrono) |
| Tiempo de ejecución de consultas SOQL antes de la cancelación de una transacción | 120 segundos |
| máx. número de unidades de código de clase y activación | 5000 |
| Activar tamaño de lote para Apex | 200 |
| Tamaño del lote de la lista de bucles | 200 |
| La consulta Batch Apex devolvió registros en Database.QueryLocator | 50 millones de |
5) Límites de Apex de tamaño específico
Estos límites están vinculados al tamaño y la cantidad de líneas de código en la plataforma. Estos se utilizan principalmente para garantizar que no existan elementos de gran tamaño en las clases, los disparadores o la organización.
| Descripción | <div style="margin-top:15px">Límite</div> |
|---|---|
| La cantidad máxima de caracteres/clase | mn 1 |
| La cantidad máxima de activadores/clase | 1 millones |
| Utilización máxima de código de Apex | 6 MB |
| Límite para el tamaño del método | 65,535 |
¿Por qué se aplican los límites del gobernador de Salesforce?
La plataforma de Salesforce proporciona personalización en forma de disparadores de Apex, servicios web o cambios declarativos como flujos y generadores de procesos. Cuando estas personalizaciones se ejecutan en la plataforma, consumen recursos limitados que se comparten con otros Instancias de Salesforce.
Salesforce se asegura de que su plataforma funcione sin problemas y de que sus clientes no se vean perturbados por fallas en el servidor. Como resultado, Límites del gobernador de Salesforce fueron establecidos y aplicados.
Garantizan que cualquier instancia de Salesforce que comparta recursos con otras instancias no consuma todos los recursos finitos y que los recursos se distribuyan correctamente de acuerdo con el modelo de suscripción de la instancia.
Ventajas:
- Gobernador de Salesforce Las restricciones prohíben que otras organizaciones operen y, por lo tanto, ejecuten código extenso, lo que puede consumir mucha memoria e incluso la CPU en la nube.
- Apex tiene un conjunto completamente separado de límites de codificación.
- Estos límites reguladores nos mantienen en el espacio correcto de codificación cuando trabajamos con Apex.
También, lea: Comparación de ediciones de Salesforce: características y aplicaciones
¿Cómo puede evitar alcanzar estos límites de gobernador de Salesforce?
Es nuestra responsabilidad asegurarnos de que nuestro código sea escalable y no exceda el límites del gobernador. Se pueden usar varios trucos y sugerencias para asegurarse de que cualquier código de personalización se escriba dentro de estos límites del gobernador de Salesforce. Para ello debes seguir estos pasos:
- En el bucle FOR, asegúrese de que no haya declaraciones DML o consultas SOQL.
- En el bucle, evite usar operaciones SOQL o DML.
- Establezca los límites del gobernador, marque la opción 'Enviar correos electrónicos de advertencia de Apex' en su registro de usuario para recibir advertencias por correo electrónico.
- Aumenta el código y los métodos auxiliares.
- Se pueden consultar grandes conjuntos de datos.
- Para evitar problemas de tamaño de almacenamiento dinámico en el vértice, asegúrese de que las variables sean privadas o transitorias, a menos que sea necesario acceder a ellas fuera de la clase.
- Si necesitamos procesar 50,000 XNUMX registros, debe usar Batch Apex.
- Optimice la ejecución de varios disparadores en un solo objeto.
- Para bucles, use consultas y colecciones optimizadas.
También, lea: Salesforce Customer 360: todo lo que necesita saber sobre
Conclusión
Como puede ver, hay diferentes tipos de límites de gobernador disponibles en Salesforce, y esto es por una buena razón: nos ayudan a ser administradores y desarrolladores más eficientes. Hay varios patrones generales que puede adoptar para asegurarse de mantenerse dentro de estos límites. En general, los límites más conocidos en una sola transacción giran en torno a SOQL y DML limites
Los desarrolladores escribirán automáticamente un código optimizado que brinde el rendimiento óptimo cuando se realicen personalizaciones teniendo en cuenta estos límites. Con suerte, ahora debe haber entendido que superar los límites del gobernador puede ser desafiante y agradable. Si tienes más dudas o necesitas ayuda de profesionales, siéntete libre de contactarnos.
Servicios de consultoría de Salesforce
Si es nuevo en la automatización y está confundido acerca de Workflow o Process Builder. No se preocupe, lo tenemos todo cubierto. Hable con nuestros expertos y aclare todos los pensamientos nublados sobre la automatización.
