Salesforce Customer 360 Platform proporciona una potente arquitectura dirigida por metadatos para cada instancia de arrendatario de Salesforce individual (también conocida como “organización”). Este documento de fundamentos de arquitectura proporciona una descripción general de áreas donde la arquitectura subyacente de Salesforce Platform crea una consideración clave para las arquitecturas de soluciones construidas en la plataforma.

Existen tres áreas esenciales a comprender al diseñar arquitecturas en Salesforce Platform:

• Transacciones
• Metadata Versus Data
• API de plataforma

En Salesforce Platform, una transacción puede instanciarse mediante la ejecución de código y/o una operación de base de datos. Una competencia fundamental para la arquitectura en Salesforce es comprender cómo la plataforma define y controla transacciones para arrendatarios. Para mantener los recursos para todos los arrendatarios, Salesforce impone límites a cada arrendatario, calculados por transacción y por organización.

A nivel de transacciones, Salesforce establece límites reguladores y de ejecución para garantizar que las instancias individuales de ejecución de código y transacciones de base de datos no monopolicen recursos de computación compartidos. A nivel de toda la organización, Salesforce establece límites basados en edición y tipo de función. Los límites de toda la organización también incluyen un cálculo continuo del uso de API entre todas las transacciones en la organización, que están sujetas a límites de API.

Echemos un vistazo con más detalle a dos partes clave de las transacciones en Salesforce Platform: el contexto de ejecución y la manipulación de la base de datos.

Salesforce calcula los límites de transacciones basándose en un concepto de contexto de ejecución. Es importante comprender que para aplicaciones de Salesforce, esto no es exclusivo de ejecuciones de código personalizado en una única organización de Salesforce. El contexto de ejecución se basa en el motor de tiempo de ejecución de plataforma y todo el código disponible para el motor de tiempo de ejecución para un arrendatario concreto. Esto significa que el código personalizado definido en la organización de un arrendatario, el código de paquetes instalados con esa organización, así como el código contenido en los servicios de la plataforma Salesforce pueden crear instancias de una transacción. La plataforma distingue entre diferentes tipos de código Apex y calcula límites reguladores basándose en esas distinciones.

Consulte la guía del desarrollador de Apex para obtener más información sobre los límites de transacciones Apex.

Cuando una transacción implica manipulación de la base de datos, un orden de ejecución integrado prescribe cómo se comportarán las diferentes partes de la configuración y el código de su organización. Una clave para comprender cómo utilizar correctamente el orden de ejecución en sus aplicaciones de Salesforce es comprender la integridad de datos sólida que proporciona este comportamiento para sus aplicaciones de Salesforce.

La plataforma expone variables de contexto para el estado de operaciones de base de datos en forma de variables de contexto desencadenantes. Es importante comprender que estas variables de contexto de desencadenador describen estados de tiempo de ejecución para todas las transacciones de base de datos en la organización de Salesforce, independientemente de que se hayan definido o no desencadenadores Apex personalizados en esa organización. Están disponibles para herramientas declarativas como Salesforce Flow.

En Salesforce, los datos no se confirman (ni se finalizan las transacciones de datos) hasta la final después de que los comportamientos de desencadenador descritos en el orden de ejecución se hayan completado correctamente. Esto significa que cualquier error fatal o comportamiento de descalificación durante una transacción de datos que se produzca antes de contextos o después de contextos hará que la plataforma revierta todas las operaciones de datos en la transacción. Los cambios solicitados en datos de registro no se confirman en la base de datos y no se ejecuta ninguna lógica posterior a la confirmación. (Apex expone métodos de base de datos para permitir un control más granular de los puntos de guardado y el comportamiento de reversión.)

Un antipatrón clave a evitar en su arquitectura de Salesforce es intentar un acceso directo o sustituir el orden de ejecución integrado de la plataforma.

Para obtener una visión más detallada de la lógica detrás de estos comportamientos de integridad de datos integrados, consulte Por dentro y Por fuera: Transacciones en el blog de Ingeniería de Salesforce.

Al elegir cómo personalizar y ampliar en una organización de Salesforce, es importante comprender qué se considerarán datos y qué se considerarán metadatos desde el punto de vista de Salesforce Platform. Para profundizar en la arquitectura subyacente detrás de esta distinción de datos/metadatos, en el documento Fundamentos de Arquitectura de múltiples arrendatarios de plataforma.

Esta distinción afectará a muchos aspectos del ciclo de vida de desarrollo para su aplicación, como: si un artefacto se copiará o no en entornos de desarrollo sandbox, cómo se puede migrar a otros entornos, si puede o no formar parte de un paquete.

La tabla siguiente ofrece una comparación rápida del desempeño de datos frente a metadatos en lo que se refiere a partes clave del ciclo de vida de la aplicación:

A veces esta distinción es bastante obvia. Por ejemplo, los registros individuales en una organización de Salesforce son datos. Los diversos sObjects de una organización son metadatos.

Las distinciones pueden ser más complejas cuando se trata de funciones de configuración de organización. Un ejemplo clave es Configuración personalizada frente a Tipos de metadatos personalizados. Ambas funciones le permiten configurar información en una organización de modo que esté disponible fácilmente en tiempo de ejecución y se pueda manipular y gestionar de formas similares a registros de base de datos. Ambas funciones están pensadas para permitir patrones de diseño altamente flexibles y acoplados de forma flexible en código y automatización. Sin embargo, Configuración personalizada se almacena en una organización como datos y Tipos de metadatos personalizados se almacenan como metadatos.

Puede determinar si algo son metadatos viendo si aparecen en el Reporte de cobertura de metadatos. Este reporte también le informará acerca de comportamientos clave de desarrollo e implementación para un tipo concreto de metadatos.

Existen muchas API de Salesforce Platform. Las API de Salesforce Platform admiten diferentes formatos y protocolos de datos, varios tipos de operaciones y tiempos. Algunas API le permiten interactuar con los datos en una organización de Salesforce, mientras que otras admiten interacciones con los metadatos en una organización concreta. Algunas API están construidas específicamente para gestionar grandes volúmenes de transacciones, mientras que otras no. Salesforce actualiza el número de versión para todas las API de Salesforce Platform con cada versión.

Una parte clave de la arquitectura de aplicaciones sólida es asegurarse de que los desarrolladores de aplicaciones utilicen la API (y la versión de API) correctas para un caso de uso concreto. Tendrá que considerar los límites de API integrados para sus organizaciones de Salesforce, muchos de los cuales están determinados por la edición y la activación de funciones. Las API de Salesforce Platform admiten el uso retrocompatible, lo que significa que las implementaciones con una versión concreta deben tener un desempeño estable y coherente, incluso cuando se publiquen nuevas versiones de API. Si desea incorporar funciones nuevas o modificadas desde una nueva versión de API, es posible que tenga que refactorizar su aplicación antes de actualizar referencias a la nueva versión de API.

Las muchas API de Salesforce Platform diferentes, junto con la velocidad de las versiones de API de Salesforce, agrega una complejidad significativa al ciclo de vida de cualquier aplicación que utilice las API de Salesforce. Tendrá que planificar evaluaciones regulares de las referencias de API de Salesforce Platform en sus aplicaciones y priorizar los ciclos de mantenimiento de API planificados para mantener las aplicaciones ejecutándose de forma predecible y apropiada.