Una introducción a Apex para desarrolladores de Java ☁️

Si es un desarrollador de Java que explora el ecosistema de Salesforce y se pregunta qué es Apex, ¡esta publicación es para usted! Apex es el lenguaje de programación backend de la plataforma Salesforce. Apex, junto con herramientas declarativas como Flows, le permite personalizar la lógica empresarial. Apex se basa en la sintaxis de Java optimizada específicamente para los requisitos de la plataforma multiinquilino de Salesforce y ofrece una serie de funciones listas para usar, como multiinquilino, seguridad, compatibilidad con versiones anteriores y escalabilidad. En esta publicación, exploramos las funciones de Apex desde la perspectiva de un desarrollador de Java. Veremos los pasos desde el código fuente hasta el tiempo de ejecución, las diferencias de sintaxis y comportamiento, el acceso y la seguridad de los datos y, finalmente, los espacios de nombres y los paquetes. Desde el código fuente hasta el tiempo de ejecución Compile al implementar A diferencia de Java, no hay un compilador de Apex que se ejecute en su máquina. Apex solo se ejecuta en Salesforce Platform y el código se compila automáticamente en el momento de la implementación. Intentar implementar código que no compila anula la implementación. Este proceso reduce en gran medida la posibilidad de que la Plataforma aloje un código Apex "no válido". La plataforma expone un servidor de idioma que lo ayuda a validar su código fuente. Esto le permite desarrollar en un IDE local o remoto, como VS Code, con las extensiones de Salesforce o Code Builder (Beta).

Además de la compilación en el momento de la implementación, las clases e interfaces de Apex están vinculadas a las versiones de la API. Esto garantiza una sólida compatibilidad con versiones anteriores a medida que evoluciona la Plataforma. Podría lograr algo similar recompilando el código fuente de Java para diferentes versiones de tiempo de ejecución, pero el poder de Apex ejecutándose en una organización de Salesforce es que el código escrito hace una década, así como el código reciente, se ejecutan en el mismo tiempo de ejecución.

Pruebas

Al igual que con cualquier idioma, las pruebas son una parte clave del proceso de desarrollo. Sin embargo, la diferencia con el ecosistema de Salesforce es que la plataforma requiere una cobertura de código mínima del 75 % cuando se implementa en un entorno de producción. Si no se cumple este objetivo, se cancela la implementación.

Las pruebas de Apex se pueden ejecutar en cualquier momento gracias a las API de la plataforma o las herramientas para desarrolladores. La plataforma incluye su propio ejecutor de pruebas yfunciones de pruebas unitarias en forma de afirmaciones y anotaciones de Apex.

Límites del gobernador

La plataforma de Salesforce se basa en una arquitectura de múltiples inquilinos. Cuando se ejecuta el código Apex, hay una serie de límites estrictos que imponen una calidad de servicio equitativa entre todos los inquilinos. Los límites son una parte clave del tiempo de ejecución, como dice la documentación:

[…] el motor de tiempo de ejecución de Apex impone límites estrictamente, de modo que el código o los procesos de Apex fuera de control no monopolizan los recursos compartidos. Si algún código de Apex supera un límite, el gobernador asociado emite una excepción de tiempo de ejecución que no se puede manejar.

Existen diferentes tipos de límites, como el tiempo de CPU, el tamaño del almacenamiento dinámico y los límites por transacción. Asegúrese de leer la sección de límites y reguladores de ejecución de la Guía del desarrollador de Apex para obtener una descripción general de esos límites. Los límites son especialmente importantes cuando se trabaja con datos. Volveremos a esto en la sección de acceso a datos de esta publicación.

Diferencias de sintaxis y comportamiento

Si bien la sintaxis de Apex es similar a la de Java 5, existen varias diferencias sintácticas y de comportamiento.

Sintaxis insensible a mayúsculas y minúsculas

Una de las mayores sorpresas para los desarrolladores que son nuevos en Apex puede ser el hecho de que el lenguaje no distingue entre mayúsculas y minúsculas. Leer código de Apex que no tiene un estilo coherente puede resultar confuso para un desarrollador de Java. Le recomendamos que siga usando las convenciones de código Java para la clase, el método y la nomenclatura de variables cuando trabaje con Apex, incluso si esas convenciones se basan en la distinción entre mayúsculas y minúsculas.

Colecciones

En Apex, solo hay tres tipos de colección: List , Set y Map . A diferencia de Java, estos tres tipos son clases, no interfaces. Se crean instancias directamente en Apex y no hay equivalentes para implementaciones de colecciones de Java especializadas, como ArrayList , LinkedSet o HashMap .

Puede encontrar más información sobre las colecciones en la publicación de blog Mastering Apex Collections .

Herencia

Los métodos y las clases de Apex son definitivos de forma predeterminada. Esto significa que solo puede extender clases si especifica:

• El modificador virtual en la clase padre
• El modificador de override en los métodos secundarios que anulan un método principal

Consulte la Guía para desarrolladores de Apex para obtener más información sobre cómo ampliar una clase .

Modificadores de clase y método

El modificador static tiene algunas diferencias notables entre Java y Apex.

• No se puede acceder a las variables de clase estática o métodos estáticos a través de instancias de clase
• Las clases internas se comportan como una clase interna de Java estática pero no requieren la palabra clave static
• Los métodos y variables estáticos solo se pueden declarar en una definición de clase de nivel superior, no en una clase interna

En Apex, el modificador de método predeterminado es private (no existe un equivalente para el modificador de acceso Java "predeterminado") y los métodos de interfaz no tienen modificadores (siempre son globales).

Apex introduce un par de modificadores que no existen en Java:

• El modificador de acceso global para clases y métodos. Compartiremos más sobre este modificador en la sección "Paquetes y espacios de nombres" de esta publicación.
• Los modificadores with sharing , without sharing y de clase de inherited sharing . Volveremos a estos modificadores en la sección "Acceso a datos y seguridad", y puede leer más sobre estos modificadores de seguridad en la Guía para desarrolladores de Apex.

Procesamiento asíncrono

Si bien Apex no expone el acceso programático a los subprocesos, existen algunos patrones y clases dedicados que le permiten ejecutar código de forma asíncrona. El módulo Apex asíncrono de Trailhead y la Guía para desarrolladores de Apex brindan una excelente descripción general y orientación sobre las diferentes opciones para el procesamiento asíncrono: métodos futuros, lotes, colas y trabajos programados.

Genéricos y anotaciones

Apex admite tipos y anotaciones genéricos para tipos de sistema; sin embargo, no puede declarar sus propios tipos y anotaciones genéricos personalizados.

Excepciones

Las clases de excepción deben extender la clase de Exception base u otra excepción definida por el usuario, y su nombre de clase termina con la palabra "excepción".

Acceso a datos y seguridad

A diferencia del código Java, que está diseñado para ejecutarse en varios servidores de aplicaciones y conectarse a diferentes tipos de bases de datos, Apex está estrechamente relacionado con la plataforma Salesforce. Esta especialización permite una gran optimización y sencillez a la hora de trabajar con datos. Apex interactúa con los datos gracias a dos lenguajes de consulta integrados y al lenguaje de manipulación de datos (DML). Apex también aplica automáticamente verificaciones de permisos para el acceso a datos.

Lenguajes de consulta de datos

La sintaxis de Apex integra dos lenguajes de consulta que son específicos de Salesforce:

• Lenguaje de consulta de objetos de Salesforce (SOQL): un lenguaje utilizado para recuperar registros con consultas de tipo SQL
• Lenguaje de búsqueda de objetos de Salesforce (SOSL): un lenguaje utilizado para búsquedas basadas en texto

Gracias a estas integraciones, puede recuperar datos rápidamente y asignarlos a clases con unas pocas líneas de código en lugar de decenas de líneas de Java:

<dx-code-block title language code-block="// SOQL query that retrieves accounts from the automotive industry
List accounts = [ SELECT Id, Name FROM Account WHERE Industry = ‘Automotive’
]; // SOSL query that retrieves a mixed list of accounts and contacts
// as long as any of their fields starts with "united"
List<List> results = [ FIND ‘united*’ IN ALL FIELDS RETURNING Account(Id, Name), Contact(Id, Name)
];»>

Tenga en cuenta el uso de SObject (ver documentos ) en la segunda consulta. SObject es la clase principal para todos los objetos que se pueden almacenar en la base de datos de la plataforma: objetos estándar como Account o Contact , así como cualquier objeto de base de datos personalizado definido por el usuario.

Cada vez que un administrador crea un objeto personalizado, la plataforma genera automáticamente una clase coincidente con los campos relevantes para este objeto y vuelve a compilar su base de código sin tiempo de inactividad.

Pruebe el módulo Conceptos básicos y base de datos de Apex en Trailhead para obtener más información sobre cómo Apex interactúa con los datos.

Lenguajes de manipulación de datos (DML)

Además de recuperar datos, la plataforma proporciona palabras clave que le permiten realizar operaciones DML , como insertar, actualizar o eliminar, con una cantidad mínima de código.

Las operaciones DML se incluyen de forma automática y transparente en una transacción de base de datos, que puede revertirse en caso de error.

Comprobaciones de permisos

Más allá de las funciones básicas de la base de datos, Apex también proporciona mecanismos para hacer cumplir el modelo de seguridad definido por los administradores de Salesforce para controlar qué usuarios pueden acceder o modificar objetos, registros o campos. Apex aplica estas reglas de seguridad y uso compartido al ejecutar consultas y operaciones DML.

Las reglas de uso compartido son parte del modelo de seguridad que influye en el acceso a los registros. Estas reglas se aplican en función de los modificadores de seguridad de clase ( with sharing , without sharing y inherited sharing ) y el contexto de ejecución actual (si un usuario específico o el sistema inició la ejecución). Sin embargo, estos modificadores de acceso no aplican los permisos del usuario ni la seguridad de nivel de campo (FLS).

A partir del lanzamiento de Winter '23, hay una versión beta en curso para las operaciones de base de datos en modo usuario . El modo de usuario garantiza que se respeten los permisos FLS y de objeto del usuario que ejecuta, a diferencia de cuando se ejecuta en modo de sistema (el modo predeterminado para Apex).

Espacios de nombres y paquetes

Tanto Apex como Java usan la noción de paquetes, pero estos significan cosas diferentes según el idioma. El equivalente más cercano a los paquetes de Java en Apex son los espacios de nombres , pero su uso es diferente.

Las clases de Apex se pueden aislar de otras clases gracias a los espacios de nombres, sin embargo, se aplican consideraciones especiales:

• Un espacio de nombres está registrado en una organización de Salesforce
• Una organización solo puede tener un espacio de nombres
• El nombre de un espacio de nombres debe ser único en todos los clientes de Salesforce
• No hay subespacios de nombres
• Los espacios de nombres solo están disponibles cuando se usan con paquetes de Salesforce

No profundizaremos en los diferentes tipos de paquetes de Salesforce en aras de la brevedad, pero los paquetes actúan como un contenedor para los entregables y estos incluyen más que el código Apex. Los paquetes pueden incluir la mayoría de los tipos de metadatos, como definiciones de objetos y campos, diseños, informes y paneles, componentes de la interfaz de usuario y más. Algunos tipos de paquetes ( paquetes administrados ) se crean con un espacio de nombres.

El modificador de acceso global permite acceder a clases y métodos fuera de su espacio de nombres. Una clase pública dentro de un paquete no es visible para una organización donde está instalado el paquete.

No hay administradores de paquetes o dependencias para Apex como Maven o Gradle. Los paquetes se instalan utilizando su ID de versión, ya sea desde las API de Salesforce, herramientas como la CLI de Salesforce o AppExchange (mercado de Salesforce).

palabras de cierre

Esto concluye nuestra descripción general de Apex. Aprendió sobre los detalles de cómo desarrollar, probar, implementar y empaquetar su código fuente de Apex. Obtuvo una descripción general de las herramientas de desarrollo y las características clave del lenguaje. Usted vio lo que hace que Apex sea excepcionalmente poderoso para abordar el desafío de un entorno de nube basado en datos y de múltiples inquilinos y cómo el acoplamiento estrecho de la plataforma permite optimizaciones que Java no admitiría.

Ahora está listo para continuar su viaje como desarrollador con Apex. Te dejaremos algunos recursos para guiarte en el camino.

Recursos

Sobre el Autor

Philippe Ozil es un defensor principal de desarrolladores en Salesforce, donde se enfoca en la plataforma de Salesforce. Escribe contenido técnico y habla con frecuencia en conferencias. Es un desarrollador de pila completa y disfruta trabajar en proyectos DevOps, robótica y realidad virtual. Sígalo en Twitter @PhilippeOzil o consulte sus proyectos de GitHub @pozil .