Etiqueta: VSCODE

Categories
Developers Tutoriales de Salesforce

Herramientas para desarrolladores desde cero (Parte 1 de 2) ☁️

Herramientas para desarrolladores desde cero (Parte 1 de 2) ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Herramientas para desarrolladores desde cero (Parte 1 de 2) | Blog de desarrolladores de Salesforce

Tanto si es un nuevo desarrollador que acaba de empezar su carrera en el ecosistema de Salesforce como si es un desarrollador experimentado de Salesforce que aún no se ha cambiado a nuestras nuevas herramientas para desarrolladores, esta serie de publicaciones de blog es para usted. Le mostraremos cómo configurar y utilizar las herramientas que pueden ayudar a todos los desarrolladores de Salesforce a ser mucho más productivos y felices.

Antes de que empieces

Si es nuevo en Salesforce y no tiene una organización (instancia de Salesforce) disponible para practicar, regístrese en una organización Developer Edition . Es completamente gratis y tiene la mayoría de las funciones de Salesforce preinstaladas para que pruebe y aprenda. Deberá proporcionar un nombre de usuario en forma de dirección de correo electrónico, pero no es necesario que sea uno real. Es solo un nombre de usuario que debe ser único en todos los productos de Salesforce. Después de solicitar una organización, recibirá un correo electrónico con los pasos para iniciar sesión. Tome nota del nombre de usuario de la organización que proporcionó, ya que tendrá que usarlo más adelante.

Si es un desarrollador de Salesforce establecido y un usuario de Developer Console, este es el momento adecuado para adoptar las nuevas herramientas de desarrollador. Si bien Developer Console puede ser una forma rápida de cambiar algunas líneas de código, usar las herramientas más modernas cambiará las reglas del juego, ya que incluyen un montón de capacidades que simplificarán su trabajo. Usar las nuevas herramientas requiere un cambio de hábitos al principio, pero te prometo que muy pronto entenderás sus beneficios. Además, tenga en cuenta que ya no estamos invirtiendo en Developer Console, y problemas como la falta de soporte para Lightning Web Components son algo que no abordaremos.

Instalación de las herramientas de desarrollador

Los metadatos de su organización están en la nube, pero para desarrollarse de una manera más productiva, desarrollará localmente. El modus operandi será trabajar con los metadatos en su máquina local y sincronizarlos con su organización, lo que significa recuperarlos o implementarlos cuando sea necesario.

Una alternativa al desarrollo local es usar Code Builder (Beta) , un IDE basado en web que puede iniciar desde su organización y que tiene las herramientas de desarrollador instaladas. Sin embargo, en este blog, nos centraremos en el flujo de trabajo de desarrollo local.

El primer paso es instalar las siguientes herramientas en su máquina:

  • CLI de Salesforce : esta es la herramienta de interfaz de línea de comandos que utilizará para escribir comandos para mover su código entre su entorno local y su organización, ejecutar pruebas, implementar datos de muestra y mucho más. Si no le gusta escribir comandos en una terminal, no tema, ya que tenemos opciones alternativas como se describe en esta publicación de blog.
  • Código VS : este es el IDE que usará para desarrollar en su máquina local.
  • Java : algunas funciones en las extensiones de Salesforce para VS Code dependen de la plataforma Java, kit de desarrollo de edición estándar (JDK). Instálelo siguiendo las instrucciones vinculadas.
  • Extensiones de Salesforce para VS Code : Este es un grupo de extensiones de VS Code que aumentan las capacidades de VSCode, exponiendo la mayoría de los comandos de la CLI de Salesforce en la interfaz de usuario de VS Code, para que pueda ejecutarlos con clics. Las extensiones también agregan funciones para habilitar la depuración, facilitar las pruebas, permitirle explorar los metadatos en su organización y más.

Creación de un proyecto de Salesforce DX

Cuando trabaja con los metadatos de una organización localmente, los archivos de metadatos deben almacenarse en una carpeta de proyecto, siguiendo una estructura determinada. Eso es lo que llamamos un proyecto de Salesforce DX.

Una vez instaladas las herramientas para desarrolladores, puede continuar y crear un proyecto de Salesforce DX que luego conectará a su organización. Una forma de hacerlo es escribir un comando que utilice la CLI de Salesforce para crear el proyecto. Puede escribir ese comando en una terminal normal.

sf project generate -n myProject

Nota: la CLI de Salesforce contiene dos ejecutables, sfdx y sf . En este blog, escribiremos los comandos utilizando el ejecutable y la sintaxis más modernos, que es sf .

El indicador -n indica el nombre del proyecto. La CLI de Salesforce aplicará scaffolding a un proyecto en una carpeta con ese nombre. Una vez que se crea el proyecto, puede abrirlo en VS Code, con File → Open Folder .

Gracias a las extensiones de Salesforce para VS Code, existe una forma sin escribir para ejecutar los comandos de la CLI de Salesforce. Simplemente abra la paleta de comandos de VS Code con View → Command Palette y escriba SFDX para ver todos los comandos disponibles. También podríamos haber creado el proyecto con SFDX: Create Project en lugar de escribir el comando.

Autorizar y establecer una organización como predeterminada

Una vez que su proyecto esté configurado, el siguiente paso es autorizar la CLI de Salesforce para que funcione con su organización. Comencemos esta vez con la forma de hacerlo sin escribir. Cuando abra el proyecto por primera vez, simplemente haga clic en el botón Sin conjunto de organizaciones predeterminado y aparecerá la paleta de comandos, sugiriendo que autorice una organización. Proceda siguiendo las instrucciones del comando.

Otra forma de hacerlo es ejecutar un comando CLI de Salesforce. Esta vez, y de ahora en adelante, le recomiendo que use el terminal integrado de VS Code para ejecutar comandos, ya que tener todas las herramientas en la misma pantalla reduce el cambio de contexto. Puede abrirlo en Terminal → New Terminal .

El comando CLI de Salesforce utilizado para autorizar una organización es:

sf org login web -s

Luego, siga las instrucciones dadas por el comando. El indicador -s configurará esa organización como su organización predeterminada para este proyecto. Puede ver la organización predeterminada de su proyecto en la barra inferior de VS Code.

Todos los comandos de la CLI de Salesforce tienen varios indicadores disponibles. Por ejemplo, si desea conectarse a una zona de pruebas, puede pasar la URL de la instancia de la zona de pruebas a sf org login web usando -r . Para ver la ayuda del comando y todos sus indicadores disponibles, ejecute el comando agregando --help al final.

Cuando trabaja con varias organizaciones, será común autorizar la CLI de Salesforce con varias organizaciones. Puede ver las organizaciones a las que la CLI de Salesforce tiene autorización para acceder ejecutando sf org list . Puede cambiar la organización predeterminada de un proyecto haciendo clic en el nombre de la organización en la barra inferior de VS Code, como hicimos para autorizar por primera vez, o ejecutando:

sf config set target-org=your-org-username@sf.com

Permítanme compartir con ustedes un último consejo. Las organizaciones pueden tener alias. Esto es útil cuando no desea recordar nombres de usuario largos o complejos. Para establecer un alias, escriba el siguiente comando.

sf alias set myalias=your-org-username@sf.com

Cuando se establece un alias, puede utilizar el alias en lugar del nombre de usuario de la organización en cualquiera de los comandos de la CLI de Salesforce.

Implementación de metadatos en la organización

Una vez que la CLI de Salesforce y su IDE estén autorizados con su organización, y la organización esté configurada como la organización predeterminada para su proyecto, puede comenzar a desarrollar e implementar cambios. Por ejemplo, digamos que queremos crear una clase de Apex. Puede crear el archivo de metadatos que representa la clase de Apex manualmente en la carpeta classes . Sin embargo, es mucho más efectivo crear la clase desde la paleta de comandos.

También puede crear una clase escribiendo el siguiente comando de la CLI de Salesforce:

sf apex generate class -n myClass -d force-app/main/default/classes

Una vez que su clase esté lista para implementarse en su organización, hay varias formas de hacerlo. Una forma es especificar los metadatos en el comando.

sf project deploy start -m ApexClass

Una segunda forma es especificar una carpeta para implementar.

sf project deploy start -p force-app/main/default/classes

Y una tercera forma, disponible gracias a Salesforce Extensions for VS Code, es hacer clic con el botón derecho en el archivo y hacer clic en Deploy This Source to Org .

Todas esas opciones le permiten ejecutar las implementaciones usted mismo. Si desea automatizar este paso e implementar un archivo cada vez que se guarda, puede establecer la configuración Implementar al guardar VS Code en "Verdadero" y ahorrar algo de tiempo.

Cuando se implementan sus metadatos, normalmente querrá abrir su organización para realizar pruebas. Puede iniciar sesión utilizando su navegador como de costumbre. Pero para los desarrolladores, es más eficiente hacer clic en el botón de abrir organización en la barra inferior de VS Code.

Conclusión

En esta publicación de blog, aprendió cómo obtener una organización gratuita para el desarrollo y cómo instalar las herramientas de desarrollo que todo desarrollador de Salesforce debería usar hoy. Ha entendido cómo crear un proyecto y autorizarlo con su organización y, por último, cómo implementar metadatos mediante la CLI de Salesforce o VS Code. En la Parte 2 de esta serie, aprenderá cómo recuperar metadatos, trabajar con organizaciones con seguimiento de origen y usar bibliotecas de Node para cuidar la calidad de su código. Además, compartiremos otras gemas ocultas de las extensiones de Salesforce para VS Code. Si te gusta un formato de video, mira nuestro episodio de codeLive . Y si tiene preguntas, no dude en hacerlas en Salesforce Developers Trailblazer Community . ¡Estén atentos para la segunda publicación de blog de esta serie mañana!

Sobre el Autor

Alba Rivas trabaja como Principal Developer Advocate en Salesforce. Puedes seguirla en Linkedin , Twitter o GitHub .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/05/developer-tooling-from-scratch-part-1-of-2.html

Categories
Developers Tutoriales de Salesforce

Escriba Apex simplificado y seguro con las actualizaciones de Spring '23 ☁️

Escriba Apex simplificado y seguro con las actualizaciones de Spring '23 ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Escriba Apex simplificado y seguro con las actualizaciones de Spring '23 | Blog de desarrolladores de Salesforce

La versión Spring '23 de Salesforce Platform, disponible en general a partir del 13 de febrero, agregó algunas actualizaciones fantásticas al lenguaje de Apex. Hemos implementado algunas de las actualizaciones de Spring '23 en la aplicación de ejemplo Apex-Recipes , lo que ha simplificado significativamente la base de código existente.

En esta publicación de blog, revisaremos las actualizaciones en Spring '23 para Apex con ejemplos de código. Estas actualizaciones ayudan a los desarrolladores a crear aplicaciones más seguras para sus organizaciones.

1. Operaciones de base de datos en modo usuario

Apex, de forma predeterminada, se ejecuta en modo Sistema con permisos elevados, lo que significa que los desarrolladores pueden pasar por alto los controles de seguridad sin darse cuenta al escribir código.

Antes de continuar, revisemos rápidamente los controles de seguridad que los administradores de Salesforce pueden colocar para garantizar que los usuarios solo puedan acceder y manipular los datos para los que están autorizados a ver o editar. Las viñetas a continuación resumen diferentes mecanismos para aplicar un modelo de seguridad detallado para sus datos de Salesforce.

  • CRUD significa "Crear, Leer, Actualizar y Eliminar", las cuatro operaciones básicas que un usuario puede realizar en un registro en Salesforce
  • FLS significa "Seguridad de nivel de campo", que determina qué campos dentro de un registro que un usuario puede ver o editar
  • El uso compartido de registros permite al administrador configurar reglas sobre quién puede ver o editar un registro en función de varios criterios.

Con las operaciones de base de datos en modo usuario , los desarrolladores pueden optar por ejecutar Apex en el contexto del usuario, lo que garantiza que se apliquen las reglas CRUD/FLS y de uso compartido del usuario configuradas. Veamos esto en acción con ejemplos de código detallados.

Aplicar CRUD/FLS y reglas de uso compartido para SOQL estático

Puede indicar el modo de operación usando la palabra clave WITH USER_MODE para el modo de usuario y WITH SYSTEM_MODE para el modo de sistema en su consulta SOQL. Vea el ejemplo a continuación.

<dx-code-block title language code-block="List accounts = [SELECT Name, ShippingCity, ShippingStreet FROM Account WITH USER_MODE];»>

En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:

  • Permisos de lectura en el objeto Cuenta (configurado para Perfil/Conjunto de permisos) para el usuario
  • Permisos de campo (FLS) para Nombre, Calle de envío y Ciudad de envío para el usuario
  • Configuración de nivel de registro (como valores predeterminados de toda la organización y reglas de colaboración) para el objeto Cuenta para el usuario

El WITH USER_MODE la palabra clave también es compatible con agregar SOQL para hacer cumplir CRUD/FLS y reglas de uso compartido de registros.

<dx-code-block title language code-block="List groupedResults = [SELECT SUM(AMOUNT) total FROM Opportunity WHERE AccountId = :accountId WITH USER_MODE];»>

En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:

  • Permisos de lectura en el objeto Oportunidad para el usuario
  • Permisos de campo (FLS) para Amount y AccountId (sí, incluso los campos utilizados en la cláusula SOQL WHERE se verifican para FLS) para el usuario
  • Acceso a nivel de registro (como valores predeterminados de toda la organización y reglas de colaboración) en el objeto Oportunidad para el usuario

Para obtener más ejemplos, consulte la clase SOQLRecipes de la aplicación apex-recipes.

Aplicar CRUD/FLS y reglas de uso compartido para SOQL dinámico

Los nuevos métodos Database (ver documentos ) ahora admiten un parámetro AccessLevel que le permite ejecutar operaciones de base de datos en modo de usuario en lugar de en el modo de sistema predeterminado. Veamos un código de ejemplo para ejecutar un SOQL dinámico en el modo de usuario.

<dx-code-block title language code-block="String query = 'SELECT ID, Name FROM Account LIMIT 1';
List lstAccounts = Database.query(query, AccessLevel.USER_MODE);»>

En el ejemplo anterior, el modo de usuario se aplicará de manera similar al ejemplo de SOQL estático que vimos en la sección anterior.

Para obtener más ejemplos, consulte la clase DynamicSOQLRecipes de apex-recipes. Hemos actualizado todos los métodos de la clase para usar el parámetro AccessLevel .

Hacer cumplir CRUD/FLS y reglas de uso compartido para SOSL

WITH USER_MODE o WITH SYSTEM_MODE también son compatibles con declaraciones SOSL (Lenguaje de búsqueda de objetos de Salesforce).

Veamos un ejemplo de una instrucción SOSL estática.

<dx-code-block title language code-block="String keyword = 'Alaska';
List<List> searchResults = [ FIND :keyword IN Name FIELDS RETURNING Account(Name), Contact(LastName, Account.Name) WITH USER_MODE ];»>

En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:

  • Permisos de lectura en los objetos Cuenta y Contacto para el usuario
  • Permisos de campo (FLS) para el campo Nombre en Cuenta y campo Apellido en Contacto para el usuario
  • Acceso a nivel de registro (como valores predeterminados de toda la organización y reglas de colaboración) en los objetos Cuenta y Contacto para el usuario

Para Dynamic SOSL, los nuevos métodos Search (ver documentos ) también admiten el parámetro AccessLevel similar a los nuevos métodos Database . A continuación se muestra un ejemplo de cómo usar el parámetro AccessLevel para ejecutar SOSL en el contexto de los usuarios.

<dx-code-block title language code-block="String query = 'FIND 'Edge*' IN ALL FIELDS RETURNING Account(ID,Name), Contact, Lead'; List<List> searchResults = Search.query(query, AccessLevel.USER_MODE);»>

Hacer cumplir CRUD/FLS y reglas de uso compartido para DML

Las operaciones de la base de datos pueden especificar el modo de usuario o sistema utilizando las palabras clave as user o as system .

El siguiente es un código de ejemplo que ejecuta DML en el modo de usuario aplicando CRUD/FLS y reglas de uso compartido.

Para Dynamic DML, los desarrolladores pueden utilizar el parámetro AccessLevel para ejecutar operaciones de base de datos en el modo de usuario o en el modo de sistema.

Echemos un vistazo a un ejemplo de la aplicación apex-recipes para ver cómo puede diseñar métodos para que sean genéricos, de modo que el consumidor del método pueda decidir ejecutar el código en el modo de usuario o de sistema.

El fragmento de código siguiente muestra cómo invocar este método en el modo de usuario.

El siguiente fragmento de código muestra cómo invocar este método en el modo de sistema.

Para obtener más ejemplos, consulte la clase DMLRecipes de la aplicación apex-recipes.

Consideraciones importantes

  1. Las operaciones de la base de datos en modo usuario generan excepciones de seguridad si se encuentra una infracción CRUD/FLS. Si tiene un requisito para evitar excepciones y aún aplicar la seguridad, use el método Security.stripInaccessible() (consulte los documentos ). Consulte la clase StripInaccessibleRecipes (ver documentos ) de la aplicación apex-recipes para ver ejemplos de código.
  2. Si usa la palabra clave WITH SECURITY_ENFORCED en sus declaraciones SOQL para hacer cumplir CRUD/FLS, ahora le recomendamos que use la palabra clave WITH USER_MODE en su lugar debido a las siguientes razones:
    1. La consulta SOQL que usa la palabra clave WITH USER_MODE admite muchas innovaciones nuevas, como reglas de restricción, reglas de alcance y cualquier otra operación de seguridad para el acceso a datos y CRUD/FLS, que la plataforma puede agregar en el futuro, por lo que es una especie de prueba del futuro
    2. La consulta SOQL que usa la palabra clave WITH USER_MODE maneja casos de uso de seguridad complejos mucho mejor. Por ejemplo, WITH USER_MODE es compatible con SOSL y consultas polimórficas .
    3. Las declaraciones SOQL que usan la palabra clave WITH USER_MODE manejan CRUD/FLS para los campos usados en la cláusula where y order by o campos usados en la consulta de relación o búsqueda polimórfica
    4. Las consultas SOQL que utilizan la palabra clave WITH USER_MODE funcionan mucho mejor en comparación con el uso WITH SECURITY_ENFORCED
  3. El modo de usuario anula la configuración de nivel de clase para la consulta SOQL o DML escrita en modo de usuario. Exploremos esto con el siguiente código de ejemplo.

<dx-code-block title language code-block="public without sharing ExampleCls { public static List getAccount() { String query = ‘SELECT Id FROM Account Limit 1’; return Database.query(query, AccessLevel.USER_MODE); } }»>

En el ejemplo anterior, aunque la clase Apex está configurada para ejecutarse en el contexto del sistema (sin la palabra clave compartida), la consulta SOQL se ejecuta en el modo de usuario, lo que refuerza la seguridad. El modo de usuario para la operación (SOQL/SOSL o DML) anula el uso compartido a nivel de clase.

2. Pasar dinámicamente variables de vinculación a consultas SOQL

Spring '23 agregó nuevos métodos como Database.queryWithBinds , Database.getQueryLocatorWithBinds y Database.countQueryWithBinds .

Estos métodos proporcionan los siguientes beneficios:

  • Anteriormente, si los desarrolladores usaban variables de vinculación en SOQL dinámico (usando el método Database.query ) que están fuera de contexto, la consulta no podía resolver las variables. Con queryWithBinds , las variables de vinculación de la consulta se resuelven directamente desde un parámetro Map con una clave en lugar de variables de código de Apex.
  • Con Database.queryWithBinds , los ataques de inyección SOQL se evitan automáticamente.

Echemos un vistazo a un ejemplo de código para comprender el segundo punto con más profundidad.

<dx-code-block title language code-block="public static List simpleBindingSoqlQuery(Map bindParams) { String query = ‘SELECT Id, Name ‘ + ‘FROM Account ‘ + ‘WHERE name = :name’; return Database.queryWithBinds( query, bindParams, AccessLevel.USER_MODE );
}»>

El código anterior ejecuta un SOQL dinámico en el modo de usuario. El método acepta un parámetro Map y se puede llamar usando el código a continuación.

<dx-code-block title language code-block="String accountName = 'Codey And Co';
Map nameBind = new Map{‘name’ => accountName};
List accounts = simpleBindingSoqlQuery(nameBind);
System.debug(accounts);»>

Tenga en cuenta que no es necesario que nos aseguremos de que el nombre de la variable esté en el mismo ámbito de método que la consulta dinámica. Además, no es necesario usar el método String.escapeSingleQuotes para el valor en la variable name cuando se usa queryWithBinds .

Para obtener más ejemplos de código, consulte esta solicitud de incorporación de cambios en nuestro repositorio de GitHub apex-recipes.

3. Especifique un retraso en la programación de trabajos en cola

Otra característica importante que lanzamos en Spring '23 es la capacidad de especificar demoras para trabajos programados que se pueden poner en cola.

Puede ser beneficioso ajustar el tiempo antes de que se ejecute el trabajo en cola en los siguientes casos de uso:

  • Si el sistema externo tiene una velocidad limitada y puede sobrecargarse con trabajos en cola encadenados que realizan llamadas rápidas
  • Al sondear los resultados, y ejecutar demasiado rápido puede provocar el uso desperdiciado de los límites diarios de Apex asíncrono

Usa el método System.enqueue(queueable, delay) (ver docs ) para especificar retrasos. Los retrasos pueden variar de cero a 10 minutos. Veamos un ejemplo para comprender mejor esta función.

El ejemplo anterior agrega un trabajo para la ejecución asincrónica retrasada al pasar una instancia de la implementación de su clase de la interfaz Queueable para la ejecución. Hay un retraso mínimo de cinco minutos antes de que se ejecute el trabajo.

Especificar un retraso predeterminado en toda la organización en la programación de trabajos en cola

Actualmente, si tiene un trabajo en cola de Apex, utiliza el tiempo estándar en cola sin demoras adicionales. Los administradores pueden definir un retraso predeterminado en toda la organización para todos los trabajos en cola que no especifican retraso usando
System.enqueue(queueable, delay) . Este es principalmente un mecanismo para manejar trabajos fuera de control que podrían estar ejecutándose demasiado rápido.

Importante consideración

Cuando establece el retraso en 0 (cero), el trabajo en cola se ejecuta lo más rápido posible. Con trabajos en cola encadenados, implemente un mecanismo para ralentizar o detener el trabajo si es necesario. Sin un mecanismo a prueba de fallas de este tipo, puede alcanzar rápidamente el límite de Apex asíncrono diario.

También hay una próxima función Beta en la versión Summer '23 (planificada para estar disponible el 10 de junio de 2023 en todas las organizaciones) que permite a los desarrolladores controlar la profundidad de los trabajos en cola encadenados.

4. Obtenga el SObject de origen de una instancia DescribeFieldResult usando el nuevo método getSObjectType

El método getSObjectType (ver documentos ) en el objeto DescribeFieldResult (ver documentos ) es un método de mejora de la calidad de vida del desarrollador que se implementó en Spring '23.

Anteriormente, los desarrolladores tenían que hackear y escribir código adicional para obtener el objeto de origen de la información del esquema de campos obtenida a través de la descripción del campo. Puede consultar las soluciones anteriores a través de esta publicación de stackexchange .

A continuación se muestra un ejemplo de código de cómo usar el nuevo método getSObjectType .

Con el método getSObjectType , los desarrolladores ya no tienen que pasar el nombre del objeto como una cadena. Consulte un ejemplo más completo en las notas de la versión de Spring '23.

Actualizaciones de herramientas

Hemos actualizado el servidor de idioma de Apex para admitir las últimas adiciones de sintaxis, como insert as user, insert as system y mucho más. Y ahora admitimos las últimas adiciones de sintaxis en el lanzamiento reciente de las Extensiones de Salesforce para VSCode .

También quiero agradecer a Dang Mai por actualizar el complemento más bonito para Apex (usado para formatear el código Apex automáticamente) para admitir todas las palabras clave introducidas para las operaciones de la base de datos en modo usuario.

Conclusión

En conclusión, la versión Spring '23 de Salesforce incluye varias actualizaciones. Mediante el uso de estas nuevas funciones, los desarrolladores pueden crear aplicaciones más eficaces y seguras para sus organizaciones.

Los equipos de productos de Apex no se detienen ahí y hay más innovaciones en la hoja de ruta. Puede obtener una vista previa de lo que viene para Apex en Summer '23 (nuestro próximo lanzamiento) en la vista previa de las notas de la versión . También recomiendo ver la grabación de la sesión TrailblazerDX '23, Apex: What's New and What's Coming , para aprender más sobre lo que se está cocinando.

Referencias adicionales

Sobre el Autor

Mohith Shrivastava es promotor de desarrollo en Salesforce con una década de experiencia en la creación de productos a escala empresarial en la plataforma de Salesforce. Actualmente se está enfocando en las herramientas para desarrolladores de Salesforce, Flow, Apex y Lightning Web Components en Salesforce. Mohith se encuentra actualmente entre los principales contribuyentes en Salesforce Stack Exchange, un foro de desarrolladores donde los desarrolladores de Salesforce pueden hacer preguntas y compartir conocimientos. Puedes seguirlo a través de su Twitter @msrivastav13 .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/05/write-simplified-and-secure-apex-with-spring-23-updates.html

Categories
Developers Tutoriales de Salesforce

Use la API REST de Tableau con Postman para diseñar integraciones ☁️

Use la API REST de Tableau con Postman para diseñar integraciones ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Use la API REST de Tableau con Postman para diseñar integraciones | Blog de desarrolladores de Salesforce

La nueva Postman Collection para la API REST de Tableau puede ayudar a que los desarrolladores sean más productivos y democratiza el acceso a las capacidades de la API tanto como Tableau democratiza el análisis de datos. Tener acceso a la API REST es excelente para cualquier administrador de Tableau y es crucial al desarrollar aplicaciones analíticas con Tableau.

Los desarrolladores de Salesforce ahora tienen acceso a herramientas mejoradas, lo que acelera la adopción de Tableau como una capa de visualización para datos ubicados dentro y fuera de los productos de Salesforce. ¿Desea una lista de paneles de Tableau disponibles para usuarios específicos, de modo que pueda crear un catálogo de análisis llamativo en Experience Cloud? La respuesta es: use la API REST. ¿Desea administrar mediante programación extensiones analíticas para ejecutar predicciones de Einstein, así como código Python y R en Tableau? Sí, la respuesta también es: ¡use la API REST!

Los datos son el recurso sin procesar que las aplicaciones requieren para ejecutarse. Las API son las interfaces que permiten que las aplicaciones funcionen entre sí. Esta publicación de blog tiene como objetivo ayudarlo a comenzar con la API REST de Tableau, para que pueda crear soluciones que combinen ambos dominios.

Introducción a la API REST de Tableau

Aprender a usar una nueva API puede ser una tarea abrumadora. Estos son los tipos de desafíos en los que la experiencia del desarrollador puede significar la diferencia entre una implementación superficial y la verdadera magia.

Una mirada a la referencia de la API es suficiente para comprender la minuciosidad de la superficie de la API REST de Tableau, y una revisión más profunda de los conceptos clave despejará el resto del camino. Tableau tiene métodos para usuarios, libros de trabajo, fuentes de datos, proyectos, permisos y más. De hecho, si ha usado la querida utilidad de línea de comandos Tabcmd o la biblioteca Python de cliente de Tableau Server en el pasado, debe saber que ambas tecnologías usan la API REST de Tableau.

En otras palabras, puede escribir código que le diga a Tableau qué hacer. Puede simplificar sus funciones como administrador del servidor con la automatización a través de secuencias de comandos programadas o basadas en eventos. Un ejemplo de este tipo de escenario sería un administrador que aprovecha los webhooks de Tableau para recibir notificaciones cuando una fuente de datos en particular se actualiza y luego responde activando una tarea de actualización de extracción separada. El programador integrado puede ayudar al administrador a ejecutar actualizaciones en momentos fijos, mientras que las API de Tableau permiten que estas tareas se activen de forma asincrónica después de que se cumplan ciertas condiciones.

Los lectores interesados en DevOps deben saber que estos métodos pueden realizar tareas útiles, como migrar activos de Tableau entre sitios o entornos. Los desarrolladores pueden responder a eventos de webhook en activos, como cuando un usuario de Tableau actualiza un libro de trabajo de plantilla, usando la interfaz de usuario de Tableau y luego responder a ese evento publicando este nuevo libro de trabajo en un entorno de prueba o producción con la API REST. Los métodos de publicación de la API se pueden integrar en su propio proceso de revisión y aprobación.

Esta aplicación de muestra usa una combinación de las API de Tableau para ofrecer características analíticas completas a una fracción del costo, el esfuerzo y el tiempo que llevaría desarrollar las mismas capacidades internamente. Los desarrolladores pueden solicitar activos de Tableau a través de llamadas HTTP para satisfacer diversas necesidades. Por ejemplo, puede solicitar miniaturas e imágenes de alta resolución de Tableau, de modo que pueda crear hermosos catálogos y menús para ayudar a los usuarios finales a explorar el contenido analítico. Las respuestas de la API REST se personalizan para cada usuario, lo que le permite aplicar las funciones de seguridad integradas de Tableau, incluso cuando solicita activos, como archivos PDF, diapositivas y conjuntos de datos.

[contenido incrustado]

La API REST de Tableau le permite aprovechar la mejor plataforma de visualización de datos de su clase para monetizar sus activos de datos, ya que le permite escribir integraciones entre su aplicación y la capa de Tableau. Tableau ha resuelto muchos de los problemas de datos más desafiantes para clientes de todo el mundo, por lo que la integración con Tableau significa que puede salir al mercado antes y de manera más confiable, y deleitar a sus usuarios con muchas más funciones.

Tienes datos. Sabes que es valioso. Las personas con las que trabaja saben que es valioso. Sus clientes saben que es valioso. Con Tableau, puede ser la primera persona en llevar su idea al mundo. La API REST es la clave para aprovechar Tableau como plataforma. Como resultado, el análisis en su aplicación tendrá muchas funciones y se construirá a escala. Dado que Tableau traduce las interacciones de los usuarios directamente a SQL, un importante punto de venta de Tableau es que libera a los analistas de la dependencia de una capa de servicios web independiente (es decir, un ORM, que es lo que suele escribir SQL para desarrolladores y terminales de API) que debe ser diseñado, protegido, construido y mantenido por grandes equipos de desarrolladores.

Si ha tenido una experiencia similar, esto debería traducirse inmediatamente en mucho tiempo y dinero. ¿Alguna vez has oído hablar del término "backend para una interfaz"? Sin Tableau, muy a menudo sus análisis externos enfrentan un cuello de botella similar: "backend para un tablero". En primer lugar, rara vez los servicios web están diseñados específicamente para un tablero, por lo que a menudo los desarrolladores front-end unen múltiples puntos finales que con el tiempo evolucionan por separado. Esto es una molestia para mantener. Además, la gestión de cambios de toda esta pila es demasiado costosa y requiere mucho tiempo para mantener sus análisis actualizados y modernos. Es por eso que muchas iniciativas ambiciosas dan como resultado gráficos estáticos con pocas distinciones llamativas, como una "información sobre herramientas interesante", pero nunca se vuelven más significativos o interactivos.

Si la visualización de datos no es su negocio principal, pero sus clientes quieren análisis modernos, entonces, ¿por qué se tomaría tantas molestias? Algunas personas aprenden de los consejos de otros, otras personas deben cometer errores ellos mismos. Este último grupo a menudo finalmente reconsidera su estrategia de visualización de datos y elige asociarse con Tableau.

Colección Postman de la API REST de Tableau

Postman brinda una experiencia práctica sin requisitos de codificación a través de un cliente HTTP que puede ayudarlo a planificar nuevas integraciones a la velocidad del pensamiento, al igual que Tableau le permite analizar datos a la velocidad del pensamiento. Te permite concentrarte en lo que importa. Esta es esencialmente la mejor parte de la nueva Colección Postman de Tableau; elimina gran parte de la fricción experimentada al trabajar con una nueva API.

El archivo de colección está emparejado con un archivo de entorno, los cuales están alojados en el espacio de trabajo de Desarrolladores de Salesforce , un espacio de trabajo público de Postman que aloja varias otras colecciones utilizadas en Salesforce. La colección de API de la plataforma Salesforce es extraordinariamente popular con 132.000 bifurcaciones hasta la fecha.

Las instrucciones sobre cómo usar la colección Postman de Tableau y cómo contribuir a ella se pueden encontrar en el repositorio de GitHub . Si ya está familiarizado con la API REST de Tableau y Postman, la forma más fácil de comenzar es bifurcar la colección .

ponerse manos a la obra

Antes de comenzar, asegúrese de bifurcar tanto la colección de la API REST de Tableau como los archivos de entorno como se describe en esta guía . Debe agregar valores para las variables enumeradas en su archivo de entorno, como server , api-version y credenciales de usuario. Si prevé que necesitará acceso a más de un sitio de Tableau, puede administrar fácilmente estos sitios bifurcando nuevos archivos de entorno. Aquí hay algunas razones por las que eventualmente querrá acceder a más de un entorno de Tableau:

  • Tiene sitios de Tableau para diferentes propósitos, como un sitio para empleados y otro para usuarios externos, incluidos clientes, proveedores y socios.
  • Usted mismo aloja Tableau Server y desea probar diferentes configuraciones de servidor o hardware en un entorno que no sea de producción (Nota: Tableau Cloud no requiere estas pruebas ya que Tableau administra esta infraestructura por usted)
  • Brinda servicios y consultoría de Tableau o relacionados con los datos a diferentes clientes.
  • Quiere acceso anticipado a funciones de prueba que solo están disponibles en Developer Preview, por lo que se unió al Programa para desarrolladores de Tableau y creó un sitio de pruebas para desarrolladores.

Las credenciales de usuario que elija usar son importantes. Los recursos de la API REST responderán con más o menos información según el rol del usuario en el sitio , mientras que otros recursos solo están reservados para los administradores. Además de eso, los permisos asignados a los usuarios de Tableau definirán aún más el acceso al contenido y las funciones del producto. Dada esta información, generalmente es una buena idea seleccionar al menos una opción de autenticación para un usuario administrador (si es posible). Puede obtener más información sobre qué credencial elegir leyendo la documentación del proyecto . La referencia de la API especificará qué permisos y roles de sitio se requieren para enviar solicitudes a cada método en la API REST. Hay otros temas avanzados, como la suplantación de identidad , que son compatibles con la colección y serán útiles para los desarrolladores que crean experiencias personalizadas para los usuarios finales.

Al principio, esto puede parecer mucho para tener en cuenta, pero no se preocupe. Será bastante sencillo interactuar con Tableau, incluso para los usuarios nuevos, pero también ofrece más capas de potencial para aquellos que desean un mayor control.

Su primera solicitud a Tableau debe ser para autenticarse en la API REST. Si tiene éxito, la respuesta incluirá una clave de API (sesión temporal) para usar en solicitudes posteriores a su entorno de Tableau, de modo que pueda identificar quién las está realizando. Su código deberá agregar un encabezado X-Tableau-Auth con esta clave API como su valor.

Lo bueno de esta colección de Postman es que contiene secuencias de comandos de prueba que tomarán la clave de API obtenida de cualquier solicitud de autenticación exitosa y luego configura las solicitudes futuras para que incluya automáticamente el valor de encabezado correcto. Además de eso, la colección tiene un script opcional de solicitud previa de autenticación automática que autentica al usuario antes de realizar cualquier solicitud, por lo que la sesión del usuario siempre se mantiene actualizada. De esa forma, nunca tendrá que solicitar manualmente una nueva sesión de Tableau después de despertarse y abrir Postman a primera hora de la mañana.

A partir de ahí, la colección Postman se convierte en un arenero interactivo y una navaja suiza. Hace que la API de REST sea accesible y lo ayuda a satisfacer muchas de sus necesidades de Tableau. Para ejecutarlo rápidamente, solicite una lista de todos los libros de trabajo en su sitio utilizando el método Obtener libros de trabajo para el sitio . Tenga en cuenta que la respuesta debe incluir una lista de libros de trabajo con varios atributos.

Llevemos esa solicitud un paso más allá y probemos algunos parámetros de consulta útiles, como expresiones de campo y filtrado . En la pestaña llamada "Params", busque un parámetro llamado "fields" y asígnele un valor de workbook.name,workbook.createdAt,owner.name , que enumera los campos que desea. Ahora envía la solicitud y mira la respuesta. Esta vez, el XML debería tener muchos menos atributos y aún así contener los campos en el valor del encabezado.

Las expresiones de campo permiten a los desarrolladores especificar los campos que necesitan en lugar de utilizar el conjunto de atributos predeterminado. Para filtrar esta respuesta, busque un parámetro llamado "filtro" y asígnele un valor similar a este patrón: createdAt:gte:2023-04-06T21:45:46Z . En este caso, querrá reemplazar todo después de createdAt: gte: con una de las fechas del libro de trabajo que puede encontrar en la respuesta anterior que usa el mismo formato de fecha/hora.

Este ejercicio simula cómo se pueden usar estas funciones útiles para ajustar la respuesta que obtiene de Tableau.

La colección es útil para desarrolladores experimentados que se sienten cómodos escribiendo sus propias solicitudes. Una vez que sepa qué terminales desea usar y cómo configurar una solicitud, Postman puede generar código para usted en varios idiomas. Puede generar una solicitud cURL rápida, que es una buena solución para tareas improvisadas usando la terminal. También puede generar código de solicitud en Python, JavaScript y otros lenguajes. El siguiente ejemplo ha desactivado el encabezado de aceptación predeterminado generado por Postman (con un valor de */* ) y lo reemplazó con un encabezado agregado manualmente que usa application/json en su lugar. Esto obliga a Tableau a responder con JSON en lugar de XML. Observe cómo la generación de código en el lado derecho agregó correctamente el encabezado 'Accept': 'application/json' al código de solicitud de Python. Este es un ahorro de tiempo significativo, incluso para solicitudes simples.

He usado esta funcionalidad en el pasado para generar rápidamente una biblioteca de solicitudes de API REST en algunos de mis proyectos . A medida que implementa más y más funciones de Tableau en su aplicación, una biblioteca de solicitudes es una forma útil de mantener flujos de trabajo más grandes de alto nivel y más fáciles de mantener, mientras que las solicitudes en sí se describen por separado y se importan cuando es necesario. La generación de código y este tipo de estructura de directorios me ayudan a dedicar menos tiempo a preocuparme por los detalles de las bibliotecas HTTP y el lenguaje con el que estoy trabajando, de modo que puedo centrar más mi atención en el panorama general: hacer el trabajo.

Conclusión

La próxima vez que desee hacer algo con Tableau, pero no pueda encontrar una manera de hacerlo con la interfaz de usuario (como administrar webhooks o automatizar una tarea), puede ir a su colección de Postman de confianza y probar algunos métodos para ver si esta tarea es posible a través de la API REST de Tableau. Te sorprenderá la variedad de escenarios que esto te abrirá.

El mejor siguiente paso es obtener una bifurcación de los archivos de Postman y unirse a nosotros, los #datadevs que adoran Tableau y las API en el Programa para desarrolladores de Tableau . Tenemos mucho más contenido, API y recursos para compartir con usted, incluida una zona de pruebas gratuita para desarrolladores para el acceso anticipado a nuevas funciones. Háganos saber si tiene algún comentario y siéntase libre de contribuir a la colección.

Sobre el Autor

Stephen Price es ingeniero de soluciones en Salesforce con experiencia en análisis integrado y la plataforma de desarrollo de Tableau. Contribuyó al lanzamiento inicial de la colección Postman de Tableau como una forma de empoderar a otros, para que puedan crear soluciones con Tableau más fácilmente. Stephen nació y creció en Quito, Ecuador, y actualmente vive en Austin, TX. Además de ser fanático de Tableau, el análisis y el desarrollo de software, disfruta aprender nuevos idiomas, leer sobre historia, jardinería, cuidar a su perro y jugar al didgeridoo.

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/04/use-the-tableau-rest-api-with-postman-to-architect-integrations.html

Categories
Developers Tutoriales de Salesforce

Retrospectiva de un desarrollador de plataforma de TrailblazerDX '23 ☁️

Retrospectiva de un desarrollador de plataforma de TrailblazerDX '23 ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Retrospectiva de un desarrollador de plataforma de TrailblazerDX '23 | Blog de desarrolladores de Salesforce

TrailblazerDX '23 fue increíble, lleno de innovación y contenido para desarrolladores. Un mes después de la feria, todavía hay mucho que puedes aprender de este gran evento. En esta publicación de blog, compartiré las recomendaciones de un desarrollador de Salesforce Platform y una lista de recursos para ayudarlo a navegar por los diferentes anuncios de productos y funciones.

Principales anuncios principales

Como era de esperar de una conferencia de tecnología, la parte más esperada del programa fue el discurso principal . Hicimos una serie de anuncios clave que muestran las nuevas innovaciones de Salesforce. He seleccionado los tres temas más importantes para desarrolladores que se trataron durante el discurso principal del programa principal. ¡Sigue leyendo!

Anuncio de GPT de Einstein

Lo más destacado de TrailblazerDX '23 fue el anuncio de Einstein GPT , la inversión de Salesforce en IA generativa en toda nuestra cartera de productos. Compartimos una serie de demostraciones de cómo funciona con diferentes productos (Sales Cloud, Service Cloud, Slack y Tableau, solo por nombrar algunos), pero lo que más se destaca para los desarrolladores es el aumento de productividad potencial que brinda la capacidad de aprovechar la tecnología GPT para la generación de código.

En particular, pudimos vislumbrar cómo Einstein GPT podría ayudarnos a generar código Apex basado en un aviso en VS Code: Einstein GPT generó un método y el código de prueba relacionado. ¿Cuan genial es eso?

Este es solo el comienzo de una experiencia de desarrollador completamente nueva, sin embargo, no me malinterpreten: la IA no reemplazará a los desarrolladores. Einstein GPT ayuda a los desarrolladores a ser más productivos al sugerir fragmentos de código, pero la responsabilidad de los desarrolladores es usar el código generado como punto de partida, luego refinarlo y mantenerlo para satisfacer las necesidades comerciales.

Nube de datos

El segundo anuncio importante del discurso de apertura fue una muestra de Data Cloud (anteriormente conocida como Genie). Vimos cómo Data Cloud puede ingerir datos de múltiples fuentes, armonizar y transformar los datos y luego desencadenar acciones casi en tiempo real. Esta última parte es la más interesante para los desarrolladores: Data Cloud puede generar eventos de plataforma y desencadenar flujos basados en reglas personalizadas. Con estas capacidades, los desarrolladores pueden implementar fácilmente una lógica empresarial personalizada que se activa cuando se actualizan los datos de Customer 360.

Automatización

La automatización es una parte clave de nuestra estrategia de plataforma. Anunciamos una serie de funciones que simplificarán y ampliarán la forma en que los Trailblazers pueden automatizar con o sin código, gracias a Flow, Flow Orchestrations, MuleSoft y Slack. Estos son mis aspectos más destacados para los desarrolladores de plataformas:

  • Los componentes de pantalla reactivos (Beta a partir de Spring '23) son un cambio de juego para crear componentes web Lightning personalizados que interactúan con otros componentes de un flujo.
  • Las llamadas HTTP (Beta a partir de Spring '23) son excelentes acciones de flujo declarativo que ayudan a reducir en gran medida (si no a eliminar) la necesidad de código Apex personalizado al interactuar con sistemas y API de terceros.
  • Los flujos invocables (Beta en Summer '23) permiten a los constructores llamar a sistemas de MuleSoft y de terceros con solo clics y una configuración optimizada

¿Quiere profundizar en el contenido principal? Consulte la grabación de la conferencia magistral completa en Salesforce+ y los capítulos específicos que cubrimos anteriormente:

Recursos del producto

Mientras se transmitía y grababa el discurso principal, una buena parte de la experiencia de TrailblazerDX en persona fue navegar por las demostraciones de productos en el piso de la exposición e interactuar con los gerentes de productos y otros expertos de Salesforce.

Esta parte de la experiencia en realidad no se presta para ser compartida de forma remota, pero tengo buenas noticias: he reunido trailmixes dedicados para todas y cada una de las demostraciones presentadas en la exposición. Estos trailmixes dedicados incluyen un montón de recursos relevantes, como videos, publicaciones de blog, episodios de podcast, documentos de hoja de ruta y más.

Demostraciones de productos destacados

Herramientas/plataformas para desarrolladores y DevOps

Código

API y eventos

Móvil

Personalización y configuración de código bajo

Seguridad y privacidad

Sesiones en Salesforce+

Además del discurso de apertura principal, varias sesiones se transmitieron en vivo y se grabaron en Salesforce+ .

Aquí está la selección curada del equipo de defensa de desarrolladores de excelentes sesiones para desarrolladores:

Discurso principal de la plataforma: hoja de ruta para crear y ampliar su Customer 360
Conozca las últimas actualizaciones de la hoja de ruta de Salesforce Platform directamente de expertos en productos. Vea cómo puede ampliar su Customer 360 con automatización, DevOps y seguridad.

Apex: novedades y novedades
Aprenda de Chris Peterson y Daniel Ballinger sobre las funciones recientemente lanzadas y las próximas en la hoja de ruta de Apex.

De la idea a la producción: creación de aplicaciones escalables en Heroku
Únase a Julián Duque y Jonathan Jenkins para conocer cómo Salesforce Heroku le permite crear aplicaciones seguras y escalables utilizando lenguajes abiertos en la Plataforma Salesforce.

Simplifique la integración de API con servicios externos
Jennifer Jin y Lily Sai muestran interesantes actualizaciones de los servicios externos, lo que hace que sea más fácil que nunca realizar llamadas API de forma segura desde Salesforce, incluida la capacidad de realizar llamadas de servicios externos de forma nativa desde Apex.

Cree su primera aplicación en Salesforce
Aprenda a crear su primera aplicación de Salesforce con LeeAnne Rimel y Julie Thompson. Descubra cómo crear su modelo de datos, diseñar la seguridad de su aplicación, ajustar la UX con herramientas declarativas e implementar para sus usuarios.

Administrar lanzamientos con DevOps Center
Karen Fidelak explica cómo administrar lanzamientos con el centro DevOps. Aprenderá a administrar cambios y lanzamientos con confianza, sin necesidad de conjuntos de cambios.

Resumiendo

TrailblazerDX '23 fueron dos días llenos de gran contenido. De hecho, hubo tanta bondad que esta publicación de blog solo araña la superficie. Espero que esta retrospectiva le haya permitido ponerse al día y entusiasmarse con la próxima innovación relacionada con Einstein GPT, la nube de datos y la automatización, y que haya aprendido más sobre nuestros productos y funciones. Prepárese para más actualizaciones de desarrolladores a medida que trabajamos para el lanzamiento de Summer '23 en los próximos meses.

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 full-stack y disfruta trabajar en proyectos DevOps, robótica y VR. Sígalo en Twitter @PhilippeOzil o consulte sus proyectos de GitHub @pozil .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/04/a-platform-developers-retrospective-of-trailblazerdx-23.html

Categories
AppExchange Developers Tutoriales de Salesforce

Prepare su aplicación para pasar la revisión de seguridad de AppExchange ☁️

Prepare su aplicación para pasar la revisión de seguridad de AppExchange ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Prepare su aplicación para pasar la revisión de seguridad de AppExchange | Blog de desarrolladores de Salesforce

Esta guía se publicó originalmente en Medium a principios de 2021 y se actualizó con la orientación y los consejos más recientes, incluidas nuevas funciones de seguridad como parte de los lanzamientos recientes y una nueva estructura de precios para las revisiones .

Ha creado su aplicación, funciona muy bien y ahora está listo para lanzarla al mundo. Pero antes de que pueda publicar su creación en AppExchange , su aplicación debe pasar una revisión de seguridad. En Salesforce, nada es más importante que la confianza de nuestros clientes. El proceso de revisión de seguridad está aquí para validar que se puede confiar en su aplicación con los datos del cliente.

En esta publicación de blog, brindaremos orientación sobre el proceso de revisión de seguridad de AppExchange para arquitectos, desarrolladores, evaluadores, propietarios de productos y cualquier otra persona involucrada en el desarrollo o envío de un paquete determinado.

Enlaces rápidos:

  1. Descripción general
  2. preguntas frecuentes
  3. Problemas comunes y antipatrones
  4. Estampación
  5. Estrategia de presentación
  6. Conclusión

Este artículo incluye una colección de las mejores prácticas de desarrollo seguro y una lista de verificación de los errores comunes encontrados durante la revisión de seguridad (SR) de AppExchange. Puede ahorrar tiempo antes de su revisión de seguridad asegurándose de evitar estos problemas comunes. No es una lista exhaustiva, y el campo de la seguridad está en constante evolución. Para evitar la duplicación, vincularemos a la fuente autorizada para un tema determinado.

Comencemos abordando algunas preguntas frecuentes sobre el proceso de revisión de seguridad.

¿Por qué mi paquete pasó el escaneo inicial y no la revisión de seguridad más profunda?

La revisión de seguridad es un proceso complejo de varias capas que involucra varias herramientas y especialistas en seguridad. Las herramientas de verificación de código automatizadas iniciales brindan una evaluación de alto nivel de su código, pero no pueden encontrar todas las vulnerabilidades de seguridad encontradas durante una revisión manual, ya que este es un campo en constante evolución y requiere experiencia humana.

¿Qué hizo que nuestro paquete fallara en la revisión?

La persona que envió la revisión debería haber recibido un correo electrónico con un archivo adjunto que detalla qué causó que la revisión fallara. Comuníquese con su administrador de cuentas de socios (PAM) si no tiene acceso a este correo electrónico/informe.

He corregido todos los resultados de la revisión de seguridad, ¡pero ahora he vuelto a fallar!

El informe de revisión de seguridad no es una lista de verificación exhaustiva de las cosas que se deben corregir, especialmente si hay una gran cantidad de problemas con un envío. Enumera las clases de vulnerabilidades encontradas en su aplicación, pero no todas las instancias en las que ocurren. La función de la revisión de seguridad es validar que su paquete cumpla con las mejores prácticas de seguridad actuales, que no tenga vulnerabilidades conocidas y que, en general, sea seguro promocionarlo a AppExchange, donde la confianza es nuestra prioridad número 1. La revisión de seguridad no está ahí para encontrar todos los problemas de seguridad por usted, esto es algo que debe integrarse en su proceso de desarrollo y revisarse periódicamente.

Envié mi paquete para revisión, ¿cuándo se revisará?

Hay un par de pasos para esto: una vez que lo envía, el paquete está sujeto a algunas comprobaciones iniciales antes de que se coloque en la cola de SR más grande. Esto detecta cualquier error de envío importante, como la versión incorrecta del paquete enviado, y brinda una respuesta rápida de que el paquete debe volver a enviarse. Una vez pasada esta etapa, pasa a la cola principal de SR. Debido al proceso laborioso de realizar la revisión de seguridad, hay un tiempo de espera de seis a nueve semanas. Consulte la documentación para obtener la información más reciente sobre la longitud de las colas.

¡Lanzamos mañana/la próxima semana y necesitamos que se revise ahora!

El proceso de revisión de seguridad lleva tiempo y debe tenerlo en cuenta en su ciclo de desarrollo y lanzamiento. En circunstancias excepcionales, se puede dar prioridad a una revisión en particular, pero recuerde que esto realmente significa excepcional y aún requiere que un revisor de seguridad esté disponible, lo que podría demorar varios días (¡nuestras revisiones son exhaustivas!). Comuníquese con su administrador de cuentas de socios si necesita ayuda.

Nuestro paquete no pasó la revisión de seguridad y lo hemos vuelto a enviar. ¿Podemos saltarnos la cola?

Cuando envía una nueva prueba, ya tiene un probador asignado, lo que, en cierto modo, se salta el tiempo de cola y va directamente a la cola de su probador.

¡Nuestro paquete ha fallado varias veces!

Hay varias razones por las que esto podría suceder:

  1. Se corrigieron algunos problemas, pero no todos . Recuerde, no destacamos todo, así que verifique su código para ver todas las instancias de un problema.
  2. Nuevo código, nuevos problemas : ¿se ha agregado un nuevo código que presenta problemas adicionales?
  3. Malentendido de los problemas planteados : esto significa que los problemas no se solucionan correctamente.
  4. Mal diseño de seguridad : ¿hay instancias en las que su código es inseguro por diseño? Puede requerir re-arquitectura.
  5. ¿Ha revisado minuciosamente la solución usted mismo? El propósito de la revisión de seguridad es confirmar que la solución se diseñó teniendo en cuenta la seguridad, no la van a asegurar por usted.

Cada aplicación es única, pero la mayoría de las fallas de revisión de seguridad se dividen en algunas categorías. Esta sección los detalla y proporciona enlaces a la documentación para ayudarlo a evitar estos problemas.

CRUD, FLS

  1. Objeto (CRUD) y Seguridad de nivel de campo (FLS) : se configuran en perfiles y conjuntos de permisos y se pueden usar para restringir el acceso a objetos estándar y personalizados y campos individuales. Los desarrolladores de Salesforce deben diseñar sus aplicaciones para hacer cumplir la configuración CRUD y FLS de la organización en objetos estándar y personalizados, y degradar correctamente si se ha restringido el acceso de un usuario. Algunos casos de uso en los que podría ser aceptable omitir CRUD/FLS son: creación de resúmenes acumulativos o agregados que no expongan directamente los datos, modificación de objetos o campos personalizados como registros o metadatos del sistema que no deberían ser accesibles directamente para el usuario a través de CRUD/FLS, y casos en los que otorgar acceso directo al objeto personalizado crea un modelo de seguridad menos seguro. Asegúrese de documentar estos casos de uso como parte de su presentación. Para obtener más información, consulte la documentación de CRUD y FLS en los documentos para desarrolladores de Salesforce.
  2. Reforzar la seguridad a nivel de campo y de objeto en Apex : el método Security.stripInaccessible para la protección de datos a nivel de campo y de objeto ya está disponible de forma general. Utilice el método stripInaccessible para eliminar los campos a los que el usuario actual no puede acceder desde los resultados de consultas y subconsultas. Utilice el método para eliminar campos inaccesibles de sObjects antes de una operación DML para evitar excepciones. Además, use el método stripInaccessible para desinfectar los sObjects que se han deserializado de una fuente que no es de confianza.
    Dónde: este cambio se aplica a Lightning Experience y Salesforce Classic en las ediciones Enterprise, Performance, Unlimited y Developer.
    Cómo: el método stripInaccesible verifica los registros de origen en busca de campos que no cumplan con la verificación de seguridad a nivel de campo y objeto para el usuario actual y crea una lista de devolución de sObjects. La lista de devolución es idéntica a los registros de origen, excepto que se eliminan los campos inaccesibles para el usuario actual.
  3. Seguridad contra rayos — Debido a que el código Lightning comparte el mismo origen que el código creado por Salesforce, se imponen mayores restricciones al código Lightning de terceros. Estas restricciones se aplican mediante Lightning Locker y una Política de seguridad de contenido especial. También hay un escrutinio adicional en la revisión de seguridad de AppExchange.
  4. Recursos externos : todo lo que interactúa con el paquete y el usuario es un objetivo para la revisión de seguridad. Es importante que el equipo de seguridad de Salesforce revise cada paquete de extensión. Incluso los paquetes pequeños pueden presentar vulnerabilidades de seguridad.
  5. Para obtener más información, consulte: Utilice las mejoras de seguridad de Apex para reducir el tiempo de desarrollo .
  6. Código Apex seguro con operaciones de base de datos en modo de usuario : los nuevos métodos Database y Search admiten un parámetro accessLevel que le permite ejecutar operaciones de base de datos y búsqueda en modo de usuario en lugar de en el modo de sistema predeterminado. Esta función, ahora disponible de forma general, incluye algunos cambios desde la última versión. El código de Apex se ejecuta en modo de sistema de forma predeterminada, lo que significa que se ejecuta con permisos sustancialmente elevados sobre el usuario que ejecuta el código. Esta función se introdujo en Spring '23.
  7. Para organizaciones de segmentación por código anteriores a Spring '23, WITH SECURITY_ENFORCED es el nivel de acceso a usar.
  8. Para las organizaciones de orientación de código posteriores a Spring '23, WITH USER_MODE es el nivel de acceso a usar.
  9. Selección del modo de uso compartido correcto: use las palabras clave de uso compartido WITH SHARING o WITHOUT SHARING en una clase para especificar si se deben aplicar las reglas de uso compartido. Incluya siempre estos últimos en los informes de falsos positivos. Utilice la palabra clave compartida heredada en una clase para ejecutar la clase en el modo compartido de la clase que la llamó.
  10. El uso compartido heredado es un tema avanzado y requiere una consideración adicional. Debido a que el modo de uso compartido se determina en el tiempo de ejecución, debe tener sumo cuidado para asegurarse de que su código de Apex sea seguro para ejecutarse tanto con el modo de uso compartido como sin el modo de uso compartido.

Puntos finales inseguros

  1. Utilice siempre HTTPS cuando se conecte a puntos finales externos para insertar o extraer datos en Salesforce como parte de su aplicación. Cualquier atacante de la red puede acceder a los datos enviados a través de HTTP en texto claro y representa una amenaza para el usuario. Encuentre más información en la Guía de codificación segura .
  2. Todos los servicios web externos a los que se hace referencia se someterán a pruebas de penetración, así que asegúrese de que estén configurados correctamente. Un problema común es cuando un servicio externo se implementa en producción en modo de depuración, lo que hace que divulgue información (seguimiento de la pila, etc.) si la prueba de penetración logra bloquearlo al enviar datos con formato incorrecto.

SOQL

  1. Evite problemas de rendimiento comunes, como consultas SOQL, en bucles FOR anidados.
  2. Evite los ataques de inyección de SOQL desinfectando las entradas y adoptando un estilo de programación defensivo.

Estilo CSS

  1. CSS para LWC s debe estar en el CSS del componente, no en línea.
  2. El CSS en línea está fuertemente desaconsejado y restringido por el modelo de seguridad de contenido .
  3. Si su CSS rompe otro componente, fallará la revisión.
  4. No use .THIS, fijo, absoluto o flotante en CSS. Los componentes están destinados a ser modulares y ejecutarse en páginas con otros.
    1. Puede agregar una documentación de falso positivo para esto, pero debe estar bien justificada.
  5. CSS también puede ser un vector de ataque, por lo que es importante prestar atención a esto. Consulte los siguientes recursos:
    1. https://css-tricks.com/css-security-vulnerability/
    2. https://www.netsparker.com/blog/web-security/private-data-stolen-exploiting-css-injection/

JavaScript

  1. Hay numerosas recomendaciones de JavaScript a lo largo de este documento, por lo que evitaremos repetirlas aquí. Una cosa adicional a considerar es verificar las versiones heredadas de las bibliotecas, especialmente jQuery. Las versiones heredadas con vulnerabilidades conocidas harán que falle la revisión, y esto es fácil de resolver antes de tiempo. Además, vale la pena mencionar de nuevo retire.js , que se puede ejecutar como una tarea de compilación o como una extensión del navegador.
  2. Las versiones heredadas de JavaScript que se incluyen con los paquetes son uno de los problemas más comunes y más fáciles de evitar que causan fallas; asegúrese siempre de estar usando la versión más reciente.

Política de seguridad de contenido

La descripción general de la política de seguridad de contenido es un excelente recurso sobre cómo Lightning Framework utiliza la política de seguridad de contenido (CSP) para imponer restricciones al contenido. El objetivo principal es ayudar a prevenir las secuencias de comandos entre sitios ( XSS ) y otros ataques de inyección de código.

Los navegadores web siguen las reglas de CSP especificadas en los encabezados de las páginas web para bloquear las solicitudes a servidores desconocidos de recursos, incluidos scripts, imágenes y otros datos. Las directivas de CSP también se aplican a JavaScript del lado del cliente, por ejemplo, restringiendo JavaScript en línea en HTML.

Tantos problemas vuelven a los puntos planteados en esa página, que tiene sentido replicar los puntos principales aquí:

  1. Solo se puede hacer referencia a las bibliotecas de JavaScript desde su organización : todas las bibliotecas de JavaScript externas deben cargarse en su organización como recursos estáticos. La directiva script-src 'self' requiere que la fuente del script se llame desde el mismo origen. Para obtener más información, consulte Uso de bibliotecas de JavaScript externas .
  2. Los recursos deben estar ubicados en su organización de manera predeterminada : las directivas font-src , img-src , media-src , frame-src , style-src y connect-src están configuradas en 'self' . Como resultado, los recursos como fuentes, imágenes, videos, contenido de marcos, CSS y scripts deben estar ubicados en la organización de forma predeterminada. Puede cambiar las directivas de CSP para permitir el acceso a recursos de terceros agregando Sitios de confianza de CSP. Para obtener más información, consulte Crear sitios de confianza de CSP para acceder a API de terceros .
  3. Conexiones HTTPS para recursos : todas las referencias a fuentes externas, imágenes, marcos y CSS deben usar una URL HTTPS. Este requisito se aplica tanto si el recurso se encuentra en su organización como si se accede a él a través de un sitio de confianza de CSP.
  4. URL de blob no permitidas en iframes : la directiva frame-src no permite el esquema blob:. Esta restricción evita que un atacante inyecte contenido arbitrario en un iframe en un intento de secuestro de clics. Use un enlace regular a una URL de blob y abra el contenido en una nueva pestaña o ventana en lugar de usar un iframe.
  5. JavaScript en línea no permitido : las etiquetas de script no se pueden usar para cargar JavaScript y los controladores de eventos no pueden usar JavaScript en línea. La fuente insegura en línea para la directiva script-src no está permitida. Por ejemplo, se evita este intento de usar un controlador de eventos para ejecutar un script en línea: <button onclick = " doSomething () "></button> .

vulnerabilidades comunes

  1. Script entre sitios (XSS) — Los ataques de Cross-Site Scripting son un tipo de problema de inyección, en el que se inyectan scripts maliciosos en sitios web de confianza y benignos. Los ataques de secuencias de comandos en sitios cruzados (XSS) ocurren cuando un atacante utiliza una aplicación web para enviar código malicioso, generalmente en forma de secuencia de comandos del lado del navegador, a un usuario final diferente. Las fallas que permiten que estos ataques tengan éxito están bastante extendidas y ocurren en cualquier lugar donde una aplicación web use la entrada de un usuario en la salida que genera sin validarla ni codificarla. Un atacante puede usar XSS para enviar un script malicioso a un usuario desprevenido. El navegador del usuario final no tiene forma de saber que no se debe confiar en el script y lo ejecutará. Debido a que cree que la secuencia de comandos proviene de una fuente confiable, la secuencia de comandos maliciosa puede acceder a cualquier cookie, token de sesión u otra información confidencial retenida por su navegador y utilizada con ese sitio. Estos scripts pueden incluso reescribir el contenido de la página HTML. Los ataques XSS almacenados son persistentes y ocurren como resultado de que la aplicación web almacene información maliciosa y luego la presente a los usuarios. Para obtener más información, consulte lawiki de OWASP .
  2. Falsificación de solicitud entre sitios (CSRF) : CSRF es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado actualmente. Con un poco de ayuda de ingeniería social (como enviar un enlace por correo electrónico/chat), un atacante puede obligar a los usuarios de una aplicación web a ejecutar acciones de su elección. Un exploit CSRF exitoso puede comprometer los datos del usuario final y realizar acciones de cambio de estado en estos datos sin el conocimiento del usuario. Si el usuario final objetivo es la cuenta de administrador, esto puede comprometer toda la aplicación web. El uso de encabezados personalizados (incluidos métodos como PUT) para protegerse de CSRF no es un enfoque perfecto. Todavía necesita implementar el token CSRF como una medida de seguridad en profundidad.
  3. Manejo de cookies de sesión inseguro : todas las cookies de sesión deben configurarse a través de conexiones HTTPS con el indicador SEGURO. Estas cookies deben invalidarse al cerrar la sesión, y las ID de sesión almacenadas en dichas cookies deben ser aleatorias con suficiente entropía, para evitar que un atacante las adivine con una probabilidad razonable de éxito. Los valores de las cookies nunca deben reutilizarse y deben ser únicos por usuario, por sesión. Los datos confidenciales del usuario no deben almacenarse en la cookie.

Consideraciones de código

  1. Código comentado : se permiten comentarios en pequeños fragmentos y muestras, pero las funciones y clases completas que están comentadas deben eliminarse.
  2. Documentación de prueba incompleta: es importante que la documentación sea lo más completa posible, incluida la documentación de sus respuestas a los falsos positivos . Esto ayuda al revisor a comprender por qué puede estar haciendo algo de una manera particular que normalmente no sería la mejor práctica, y comprender qué acciones ha tomado para mitigar cualquier problema de seguridad.
  3. Versiones de software no seguras: Cuando se descubren nuevas vulnerabilidades en el software, es importante aplicar parches y actualizaciones a una versión del software para la que se corrige la vulnerabilidad. Los atacantes pueden crear ataques para vulnerabilidades reveladas muy rápidamente, por lo que los parches de seguridad deben implementarse tan pronto como estén disponibles. Nota: Si cree que se trata de un falso positivo, envíe un documento de falso positivo en la próxima prueba con sus motivos.
  4. Secretos en código: no almacene secretos en código. Use configuraciones personalizadas protegidas , metadatos personalizados o credenciales con nombre, según corresponda.
  5. Almacenamiento de datos confidenciales — Este es un recurso brillante sobre cómo trabajar de forma segura con datos confidenciales. Si su aplicación copia y almacena datos confidenciales que se originaron en Salesforce.com, debe tomar precauciones adicionales. Salesforce.com se toma muy en serio las amenazas a los datos que se originaron en su sitio, y una violación o pérdida de datos podría poner en peligro su relación con Salesforce si es un socio. Asegúrese de seguir las mejores prácticas de la industria para el almacenamiento seguro en su plataforma de desarrollo. Nunca almacene contraseñas de Salesforce fuera de la plataforma.
  6. Acceso al sistema externo, exfiltración de ID de sesión: la postura de seguridad sobre el uso de ID de sesión se ha endurecido significativamente en los últimos años. Específicamente, enviar el ID de sesión a un sistema externo a través de la API dará como resultado una falla automática en el futuro. Las alternativas sugeridas son usar un usuario de integración dedicado u OAuth como alternativas modernas. Borrador de orientación (se requiere iniciar sesión en la Comunidad de socios ).
  7. Eco de contraseña : almacenar información confidencial en el código fuente de su aplicación rara vez es una buena práctica, ya que cualquiera que tenga acceso al código fuente puede ver los secretos en texto claro.

Fuga de información

La fuga de información implica la revelación inadvertida de datos del sistema o la información de depuración que ayuda a un adversario a aprender sobre el sistema y formar un plan de ataque. Se produce una fuga de información cuando los datos del sistema o la información de depuración abandonan el programa a través de un flujo de salida o una función de registro.

  1. Información confidencial en la depuración: revelar información en las declaraciones de depuración puede ayudar a revelar posibles vectores de ataque a un atacante. Las declaraciones de depuración pueden ser invaluables para diagnosticar problemas en la funcionalidad de una aplicación, pero no deben divulgar públicamente información confidencial o demasiado detallada (esto incluye PII, contraseñas, claves y seguimientos de pila como mensajes de error, entre otras cosas).
  2. Información confidencial en la URL: no olvide que uno de los medios de transferencia de datos más simples es la propia URL. La información confidencial que se pasa a través del método GET (HTTP GET Query String) a la aplicación web puede provocar una fuga de datos y exponer la aplicación de varias maneras. La URL completa a menudo se almacena "tal cual" en el servidor en registros de texto claro que pueden no almacenarse de forma segura, el personal puede verlos y un tercero puede comprometerlos. Los motores de búsqueda indexan las URL que almacenan información confidencial sin darse cuenta. Almacenamiento de rutas URL completas en el historial del navegador local, caché del navegador, marcadores y marcadores sincronizados entre dispositivos. La información de URL se envía a aplicaciones web de terceros a través del encabezado de referencia. Los secretos a largo plazo, como nombre de usuario/contraseña, tokens de acceso de larga duración y tokens de API, no deben enviarse en URL.
  3. Configuración TLS/SSL: debido a las restricciones de exportación históricas de la criptografía de alto grado, los servidores web heredados y nuevos a menudo pueden y están configurados para manejar opciones criptográficas débiles. Incluso si normalmente se usan e instalan cifrados de alto grado, se podría usar alguna configuración incorrecta del servidor para forzar el uso de un cifrado más débil para obtener acceso al supuesto canal de comunicación seguro. El servidor no debe admitir cifrados, como SSL v2/SSL v3/TLS v1.0/TLS v1.1, o cifrados que utilicen un cifrado NULL o que tengan longitudes de clave débiles. TLS 1.0 y 1.1 han sido declarados al final de su vida útil por la mayoría de los sistemas y ya no deben usarse. Consulte: Pruebas de SSL-TLS . Actualmente, Salesforce requiere TLS 1.2 o superior.

Me gustaría hablar con el revisor.

Esto se puede arreglar, generalmente, con un mínimo de tres semanas de anticipación ya que el servicio es popular. Los revisores de seguridad tienen horario de oficina y los equipos pueden programar una sesión con ellos para analizar los resultados de una revisión. Si su paquete ha fallado un par de veces, puede valer la pena programar una cita justo después de la próxima revisión para hablar con un ingeniero de seguridad. Reserve su sesión de horario de oficina a través del Portal de seguridad para socios .

Falsos positivos

Hay momentos en los que tiene una razón legítima para hacer algo de cierta manera y ha tomado medidas para garantizar la seguridad de los datos. Estas instancias deben estar claramente marcadas en el código y deben proporcionarse comentarios para evitar falsos positivos . Sin embargo, si encuentra que tiene muchas excepciones en su código, es posible que deba considerar si su código sigue un antipatrón y necesita una nueva arquitectura.

La seguridad es un estado de ánimo, no una casilla de verificación

El propósito de la revisión de seguridad es validar que ha tomado todas las precauciones necesarias. Muchos socios tienen su primer paquete que no pasa la revisión de seguridad la primera vez, y hacen que su prioridad sea que esto no vuelva a suceder, por lo que revisan agresivamente el código de todos sus paquetes y dependencias, como servicios web externos. Esto es beneficioso para todos: hace que el proceso de revisión de seguridad sea más rápido y el socio es proactivo con respecto a la seguridad: este es el objetivo final .

Hay muchas herramientas disponibles, cada una con su propio enfoque. Úselos para ayudar en el análisis de seguridad, pero recuerde que la seguridad es una mentalidad y un proceso arquitectónico explícito. Si bien las herramientas pueden detectar patrones particulares, antipatrones y otros problemas, nunca tendrán la comprensión completa de lo que la solución está tratando de hacer o la mentalidad de un revisor humano. Aquí hay más información sobre algunas de estas herramientas:

  1. Analizador de código de Salesforce (Anteriormente Escáner CLI de Salesforce): esta es una herramienta desarrollada internamente para el análisis estático del código fuente. Es útil usar esto como parte de su proceso de desarrollo en curso. Consulte publicaciones de blog anteriores sobre esta herramienta como referencia:
    1. Desarrolle un código aún más seguro con Salesforce Code Analyzer.
    2. Mejore la calidad de su código con el escáner CLI de Salesforce
  2. Chimera : este es un servicio de escaneo en tiempo de ejecución basado en la nube que se puede usar para escanear sitios web de terceros. Tenga en cuenta que Chimera es solo para sitios web de su propiedad o en los que puede cargar un token.
  3. Escáner de código fuente (Checkmarx) — Source Code Scanner le permite programar escaneos, descargar informes de escaneos, buscar todos los escaneos para su organización y administrar los créditos de escaneo para sus organizaciones. Para obtener más información, consulte las preguntas frecuentes de Checkmarx .
  4. ZAP : Zed Attack Proxy es un escáner web de código abierto de OWASP.org y se puede usar para escanear sitios web de terceros.
  5. Vulnerabilidades y exposiciones comunes : CVE® es un diccionario de vulnerabilidades y exposiciones de seguridad cibernética divulgadas públicamente cuya búsqueda es gratuita.
  6. Retire.js — Hay una gran cantidad de bibliotecas de JavaScript para usar en la web y en las aplicaciones de Node.js. Esto simplifica enormemente las cosas, pero debemos mantenernos actualizados sobre las correcciones de seguridad. El "Uso de componentes con vulnerabilidades conocidas" ahora forma parte del OWASP Top 10 y las bibliotecas inseguras pueden representar un gran riesgo para su aplicación web. El objetivo de Retire.js es ayudarte a detectar el uso de versiones con vulnerabilidades conocidas.
  7. Base de datos nacional de vulnerabilidades : NVD es el repositorio del gobierno de EE. UU. de datos de gestión de vulnerabilidades basados en estándares representados mediante el Protocolo de automatización de contenido de seguridad (SCAP).

¿Cómo presento una revisión de seguridad?

Usted envía su paquete para su revisión a través de la Comunidad de socios . Antes de hacerlo, consulte la guía de ISVforce para obtener la orientación más reciente y asegúrese de leer toda la información en este artículo.

Modelo de precios por revisión

Tenga en cuenta que, a partir del 16 de marzo de 2023, las tarifas de revisión de seguridad pasarán a ser un modelo por intento.

  • Se elimina la tarifa de revisión inicial de $2,550.
  • Se elimina la cuota anual de $150.
  • La tarifa de revisión de seguridad es de $999 por intento para aplicaciones pagas.

¿Qué pasa con las aplicaciones gratuitas? ¿Aquí también se aplicará la nueva tarifa?

En el momento de escribir este artículo, el estado de las aplicaciones gratuitas es el siguiente:

No habrá tarifas por revisiones de seguridad para soluciones gratuitas mientras trabajamos para redefinir la política.

Sin embargo, consulte la página de actualizaciones de tarifas y la discusión para obtener la información más reciente.

Versiones de paquetes

Envíe una versión puntual (p. ej., 16.7→16.8, etc.), no una versión de parche (16.7. 1234 ). El escáner de seguridad en el portal de socios está diseñado para funcionar solo con versiones principales y secundarias (Mayor.Minor). Las versiones de parches (Major.Minor.PATCH) no son compatibles y se filtran deliberadamente de la lista de paquetes disponibles. La mayoría de los problemas que encuentran los socios cuando su paquete no está visible en el escáner de seguridad se resuelven creando una nueva versión Major.Minor (p. ej., 16.7→16.8).

Envío de paquetes múltiples

Al enviar una solución que consta de varios paquetes, es importante ser explícito en el caso de los paquetes incluidos en la organización y su relación entre ellos.

Por ejemplo:
xx = paquete base
yy – depende de xx
zz depende de xx + yy

Solo los paquetes directamente relacionados con el envío de revisión de seguridad deben estar en la organización; de lo contrario, se rechazará el envío.

Tras el envío: comprobaciones previas a la cola

Una vez que se ha enviado un paquete, entra en un estado de cola previa donde se realizan comprobaciones para confirmar la validez del envío. Es posible que estos pasos tarden unos días en comprobarse manualmente antes de que el paquete pase a la cola oficial de SR.

  1. Paquete(s) enviado(s) correcto(s) : el paquete debe administrarse. No se permiten paquetes beta, no administrados o desbloqueados.
  2. No se enviaron otros paquetes : si hay paquetes adicionales (consulte Envío de paquetes múltiples ), proporcione una explicación detallada sobre la dependencia del paquete.
  3. El acceso a la organización de prueba está validado : 2FA/MFA debe estar deshabilitado, para que el equipo de prueba pueda iniciar sesión para probar. Del mismo modo, para una aplicación web o un sitio remoto, asegúrese de proporcionar las credenciales de trabajo.

El proceso de revisión de seguridad está diseñado para validar que ha tomado buenas decisiones sobre la higiene de los datos y ha considerado una seguridad por diseño en su aplicación. Cuanto más piense en la seguridad por diseño, más fácil será el proceso de envío. Esta publicación le brinda una ventaja sobre las cosas que debe hacer y evitar hacer para que su revisión sea un proceso lo más fluido posible.

Recursos

Sobre el Autor

Jonathan McNamee es un evangelista técnico con sede en el Reino Unido en Salesforce, que ayuda a los socios ISV a aprovechar al máximo su inversión en la plataforma de Salesforce. Tiene 20 años de experiencia en el desarrollo de soluciones de tecnología web para empresas de todos los tamaños en una variedad de industrias y ha estado trabajando en el ecosistema de Salesforce desde 2020. Sus intereses incluyen la escalabilidad, la eficiencia y la resiliencia de los sistemas. Síguelo en LinkedIn .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/04/prepare-your-app-to-pass-the-appexchange-security-review.html

Categories
Developers Integrations Tutoriales de Salesforce

Uso del flujo de credenciales del cliente para una autenticación API más sencilla ☁️

Uso del flujo de credenciales del cliente para una autenticación API más sencilla ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Uso del flujo de credenciales del cliente para una autenticación API más sencilla | Blog de desarrolladores de Salesforce

Puede llegar un momento en el que necesite integrar una aplicación con su organización de Salesforce para realizar una tarea específica, como recuperar datos de cuentas o clientes potenciales de Salesforce. Para hacerlo, Salesforce proporciona un conjunto completo de API que abordan una amplia gama de casos de uso. Una vez que haya averiguado qué API desea usar, su pregunta de seguimiento probablemente será: "¿Cómo me autentico?"

Aquí es donde entra en juego OAuth. OAuth (abreviatura de "autorización abierta") es un estándar IETF para la delegación de acceso que se utiliza para que los usuarios de Internet otorguen a las aplicaciones acceso a su información en otros sitios, generalmente sin compartir sus contraseñas.

Salesforce ha admitido OAuth 2.0 y varios de sus flujos durante mucho tiempo. El flujo más popular es el otorgamiento de código de autorización , que es el que normalmente usa cuando conecta un sitio web (por ejemplo, Airbnb a su cuenta de Google) para iniciar sesión. Salesforce le permite usarlo en varias áreas, como su Páginas de inicio de sesión de Mi dominio o Experience Cloud, a través de un proveedor de autenticación .

Esto es excelente cuando desea una autenticación basada en el usuario mediante la cual desea que un sistema (su aplicación) se conecte a Salesforce en el contexto de un usuario específico .

Por qué implementar el flujo de credenciales del cliente

Sin embargo, en ocasiones, desea conectar su aplicación a las API de Salesforce fuera del contexto de un usuario en particular. Por ejemplo, su aplicación puede ser una aplicación de respaldo o una aplicación de análisis; no conoce ningún nombre de usuario y no tiene las credenciales de ningún usuario específico. Por lo tanto, cualquier otro medio de autenticación está fuera de la mesa. Aquí es donde entra en juego la "concesión de credenciales de cliente" de OAuth. RFC6749 señala lo siguiente:

El cliente puede solicitar un token de acceso utilizando solo sus credenciales de cliente (u otros medios de autenticación admitidos) cuando el cliente solicita acceso a los recursos protegidos bajo su control, o los de otro propietario de recursos que se han acordado previamente con el servidor de autorización ( cuyo método está más allá del alcance de esta especificación).

En el lenguaje de OAuth, las credenciales del cliente son el identificador del cliente y el secreto del cliente. En el lenguaje de Salesforce, los llamamos clave y secreto del consumidor. Puede encontrarlos en su aplicación conectada en la sección etiquetada API (Habilitar configuración de OAuth) como se ve en la captura de pantalla a continuación.

Haga clic en Administrar detalles del consumidor , lo que lo llevará a la siguiente captura de pantalla.

Configurando el flujo

En Configuración > Administrador de aplicaciones, cree una nueva aplicación conectada. En las pantallas de detalles, proporcione un nombre y un contacto en la sección de información básica. Lo que elijas realmente no importa allí. Centrémonos en cambio en la siguiente sección, API (Habilitar configuración de OAuth).

Seleccione la casilla de verificación junto a "Habilitar flujo de credenciales de cliente". Esto habilitará el flujo de OAuth para la aplicación conectada seleccionada y los ámbitos de OAuth. Luego, elija sus alcances; debido a que esto está destinado al acceso a la API, debe elegir el alcance solo de API.

Una vez que haya hecho eso y haya guardado su aplicación, debe ir a administrar su aplicación para editar las políticas que rigen la aplicación.

En particular, querrá elegir un usuario para que el flujo "se ejecute como". ¿Un usuario? Bueno, sí, todo en Salesforce se ejecuta en el contexto de un usuario, por lo que aunque este flujo está destinado a ejecutarse fuera del contexto de un usuario, aún debemos asignarlo a un usuario. Piense en esto como el patrón de "usuario de integración". Ese usuario puede ser un administrador o un usuario con permisos que le permitan tocar todos los datos que le interesan. En Spring '23, el usuario debe ser "Solo API", pero ese requisito se eliminará de Summer '23 en adelante. . Tenga en cuenta que las organizaciones de Developer Edition no tienen el permiso Solo API, por lo que si está en Spring '23, necesitará una edición diferente.

Probarlo todo

Usemos Postman para probar. Estamos de suerte ya que la colección API de Salesforce (presentada por el increíble Philippe Ozil) ya contiene una muestra para las credenciales de los clientes. Todo lo que necesita hacer es abrir esa muestra y asegurarse de que las bibliotecas de su colección contengan valores actualizados para:

  • client_id: puede encontrar este valor dentro de la aplicación conectada. En el menú desplegable junto a la aplicación conectada, haga clic en Ver . Luego ubique la sección API (Habilitar configuración de OAuth) y haga clic en Administrar detalles del consumidor . Esto le permitirá copiar su clave de consumidor y secreto de consumidor (también conocido como ID de cliente y secreto de cliente).
  • client_secret : Ver arriba.
  • URL: por ejemplo, su URL puede ser algo como: https://login.salesforce.com .

Invocar esta llamada devolverá un token de acceso opaco que puede usar en llamadas posteriores. Recuerde: este token de acceso se emite para el usuario "Ejecutar como". Por lo tanto, si elige un usuario con un amplio conjunto de permisos (quizás un perfil de administrador del sistema), entonces el token de acceso obtiene la misma cantidad. Esto es excelente para las integraciones, pero puede ser peligroso de lo contrario, así que trate su token con cuidado. Cree un usuario de integración dedicado y limite su acceso mediante conjuntos de permisos al subconjunto más pequeño posible de funciones necesarias.

Así es como se ve la respuesta:

Conclusión

Ahora que Salesforce agregó soporte para la concesión de credenciales de cliente de OAuth 2.0, es más fácil que nunca establecer integraciones de servidor a servidor que no necesariamente necesitan el contexto del usuario. Para obtener más información, consulte el RFC para obtener detalles esenciales o nuestra página de ayuda .

Sobre el Autor

David Brossard es el director sénior de gestión de productos para identidad en Salesforce. Se enfoca en todo lo relacionado con el SSO y la identidad del cliente. Es miembro fundador de IDPro y colaborador de estándares, como XACML y SCIM. David habla regularmente en conferencias de identidad como Identiverse.

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/03/using-the-client-credentials-flow-for-easier-api-authentication.html

Categories
Developers Tutoriales de Salesforce

Las funciones y herramientas más recientes de LWC para dispositivos móviles ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Las funciones y herramientas más recientes de LWC para dispositivos móviles | Blog de desarrolladores de Salesforce

El objetivo de Mobile Platform Experience es facilitar que los desarrolladores tengan éxito al crear aplicaciones para dispositivos móviles. Es por eso que estamos tan emocionados de que el lanzamiento de Spring '23 esté lleno de innovaciones para hacer que sus componentes web Lightning (LWC) brillen en teléfonos móviles y tabletas. También hacen que la experiencia de desarrollo de esos LWC sea mucho más fácil. ¡Sigue leyendo para aprender más!

Resumen rápido de las innovaciones anteriores a Spring '23

En primer lugar, hagamos un resumen rápido de las herramientas, características y prácticas recomendadas de LWC para dispositivos móviles que se han publicado en versiones recientes. Puede que no los conozcas, ¡y podemos decirte que son geniales!

Si no está familiarizado con estas funciones, mire codeLive: LWC para dispositivos móviles para verlas en acción.

A continuación, sigamos hablando de las novedades de Spring '23.

Mejoras en el complemento BarcodeScanner

Los complementos de Nimbus le permiten usar capacidades nativas de dispositivos móviles en sus componentes web Lightning. Los complementos permanecen inactivos en el escritorio y cobran vida en las aplicaciones móviles. Por ejemplo, algunos clientes ya están utilizando los complementos de Nimbus para escanear códigos de barras para casos de uso como verificar el inventario de productos, etiquetar la ubicación de un trabajador de campo para una orden de trabajo del cliente, importar contactos desde un dispositivo a una cuenta de Salesforce y sincronizar eventos de calendario hacia y desde Salesforce. .

Tenemos complementos de Nimbus ya disponibles o que se están agregando actualmente a las aplicaciones creadas por Salesforce, incluida la aplicación Salesforce Mobile (con Health Cloud y Retail Experience), Salesforce Field Service y Mobile Publisher para Experience Cloud. Hemos priorizado el soporte de los diferentes casos de uso de dispositivos nativos implementados en las diferentes aplicaciones móviles en función de los comentarios de los clientes. Consulte la siguiente tabla para obtener más información.

Característica Servicio de campo de Salesforce Editor móvil para Experience Cloud Aplicación móvil Salesforce Aplicación Salesforce+ (sin conexión)
Escáner de código de barras Invierno planeado '24 Disponible Disponible Disponible
Servicio de localización Disponible Disponible Futuro Disponible
Servicio de geocercas No estaba planeado Disponible Futuro Futuro
ContactosServicio No estaba planeado Disponible Futuro Futuro
CalendarioServicio No estaba planeado Disponible Futuro Futuro

La compatibilidad y los requisitos de los complementos de Nimbus cambian constantemente, y puede encontrar la información más actualizada en la Guía del desarrollador de LWC debajo de cada complemento.

En Summer '22, pusimos a disposición nuestro complemento BarcodeScanner. Agregamos un ejemplo de implementación a nuestra aplicación de muestra Dreamhouse y publicamos una publicación de blog sobre cómo usarla. En Spring '23, el complemento BarcodeScanner se mejoró para manejar mejor el escaneo de múltiples códigos de barras, ya que esta era una función muy solicitada por los clientes.

Las nuevas mejoras incluyen:

  • Se puede habilitar un cuadro delimitador para resaltar el código de barras particular que se escaneará
  • La confirmación manual permite al usuario confirmar qué código de barras/código QR escanear cuando hay varios en la vista
  • La vista previa de los datos capturados permite que el escáner obtenga una vista previa de los datos capturados en el escaneo incluso antes de salir de la pantalla de escaneo

Consulte la documentación de BarcodeScanner para obtener más información.

Utilidad de cambio de tamaño de imagen para lightning-input

Hemos agregado una biblioteca de compresión y cambio de tamaño de imágenes ( mediaUtils ) que puede usar con el componente base lightning-input para mejorar el rendimiento de la carga de imágenes. Esto es especialmente importante para los dispositivos móviles. Para facilitar la comprensión de la función, hemos actualizado la implementación de nuestro carrusel de imágenes de la aplicación de muestra Dreamhouse . Ahora, el componente usa lightning-input en lugar de lightning-file-upload . Tenga en cuenta que este último es más fácil de usar si no necesita manipular las imágenes antes de cargarlas.

<dx-code-block title language="html" code-block=" «>

En el código JavaScript del componente, importamos processImage desde lightning/mediaUtils . Esto le permite manejar el cambio de tamaño y la compresión de imágenes sin escribir todo ese código usted mismo. Ver el ejemplo completo para más información.

Validación fuera de línea de LWC

Para los clientes móviles, permitir que los usuarios finales trabajen sin conexión (sin conexión a la red o conectividad limitada) es una necesidad clave. Los trabajadores de campo realizan trabajos de reparación, visitan tiendas, visitan pacientes en el hogar y más. En estos casos, necesitan hacer su trabajo independientemente de la conectividad de la red. Ahora, puede crear LWC que se ejecuten en este tipo de escenarios gracias a LWC Offline.

LWC Offline es un entorno de tiempo de ejecución avanzado para componentes web Lightning. Disponible solo para dispositivos móviles, reemplaza el tiempo de ejecución estándar de los componentes Lightning y lo aumenta con funciones diseñadas específicamente para uso móvil y sin conexión. Para admitir LWC Offline y Briefcase en la aplicación Salesforce Mobile, Salesforce App+ estuvo disponible como un programa piloto cerrado en el lanzamiento de Winter '23 y pasará a la versión beta cerrada en Spring '23. LWC sin conexión está generalmente disponible (GA) como una mejora opcional para la aplicación móvil Salesforce Field Service. Obtenga más información revisando el artículo Creación de aplicaciones móviles listas para usar sin conexión con Salesforce .

Característica Servicio de campo de Salesforce Editor móvil para Experience Cloud Aplicación móvil Salesforce Aplicación Salesforce+ (sin conexión)
LWC fuera de línea Disponible No estaba planeado No estaba planeado Disponible

Para los desarrolladores que crean LWC que deberían funcionar sin conexión, pueden aprovechar nuestro complemento VS Code ESLint más nuevo, eslint-plugin-lwc-graph-analyzer . Este validador utiliza el analizador estático de Komaci, que lo ayuda a asegurarse de que las dependencias de código y los datos que necesita su componente puedan prepararse cuando hay una conexión de red disponible, haciendo que el componente y sus datos estén disponibles sin conexión cuando la red tiene conectividad limitada o nula. Con el complemento instalado, obtiene comentarios instantáneos sobre la preparación sin conexión a medida que construye sus LWC. El validador también proporciona punteros a las descripciones de los errores de validación y cómo solucionarlos. Para obtener más información sobre la instalación y el uso del complemento ESLint para VSCode, consulte la Guía para desarrolladores móviles sin conexión .

Arnés de prueba móvil para aplicaciones fuera de línea

Mobile Offline Test Harness (Test Harness, para abreviar) es una aplicación liviana de prueba y depuración que puede instalar en su emulador de Android o simulador de iOS. Con la aplicación Test Harness, puede confirmar que sus LWC funcionan como se esperaba antes de que estén listos para la prueba de integración dentro de una aplicación móvil de Salesforce habilitada sin conexión (Salesforce Field Service y Salesforce App+ a partir de hoy). El arnés de prueba incluye:

  • Un flujo de aplicaciones rápido y conveniente centrado en el lanzamiento de acciones rápidas de LWC con un SObject seleccionado
  • Una cola de borrador dedicada para ver el estado de las operaciones de modificación de datos pendientes
  • Una consola de depuración integrada en la aplicación para obtener una vista amplia de las tareas en curso y una inspección granular de los mensajes de registro
  • Recargas de aplicaciones inmediatas y bajo demanda para reiniciar rápidamente y volver a ejecutar sus últimos cambios de código LWC
  • La capacidad de adjuntar depuradores de navegador para ver más errores y advertencias específicos del desarrollador desde la vista web de LWC

Test Harness se ejecuta en una versión constantemente compatible de LWC Offline, por lo que puede esperar tiempos de respuesta rápidos y un entorno de prueba y depuración siempre actualizado.

Para obtener más información sobre la instalación y el uso del arnés de prueba móvil sin conexión, consulte la guía Desarrollar LWC listos para usar sin conexión con el arnés de prueba móvil sin conexión .

UTAM para Móvil

El modelo de automatización de pruebas de interfaz de usuario (UTAM) se basa en el popular patrón de diseño del modelo de objeto de página que se usa comúnmente en las pruebas de interfaz de usuario. Para usar UTAM, un desarrollador debe crear un objeto de página para cada componente de la interfaz de usuario para encapsular las interacciones en un solo lugar. UTAM proporciona una gramática JSON para escribir objetos de página y un compilador para generar código ejecutable en Java o JavaScript.

El equipo de Salesforce Mobile está trabajando en estrecha colaboración con UTAM para ayudarlo a realizar pruebas de interfaz de usuario en dispositivos móviles. Hoy, puede usar el nuevo inspector móvil de UTAM para identificar objetos de página para dispositivos móviles. Cuando escribe una prueba para una página nativa de una aplicación híbrida de Salesforce Mobile, a menudo es confuso saber qué objetos de página usar. El inspector móvil de UTAM le presenta el conjunto apropiado de objetos de página para la página que está navegando actualmente e identifica qué elementos de página se ven afectados por los métodos en un objeto de página seleccionado.

Próximamente, mejoraremos esta experiencia con herramientas en VSCode para ayudarlo a agregar pruebas UTAM para sus componentes web Lightning en dispositivos móviles.

Empieza ahora

¡Vaya, eso fue mucho! Esperamos que haya disfrutado de esta publicación de blog y que esté ansioso por usar todas esas nuevas capacidades para crear LWC para dispositivos móviles fácilmente y lograr la mejor experiencia de usuario para sus usuarios de dispositivos móviles. Para obtener más información, consulte la Guía del desarrollador de LWC para obtener información sobre todas las herramientas disponibles para la experiencia del desarrollador móvil, o vea los últimos videos, blogs, podcasts e insignias de senderos en el LWC para el Centro de desarrollo móvil .

Sobre los autores

Sue Berry es directora de gestión de productos en Salesforce, donde se centra en Salesforce Mobile. Actualmente está trabajando en Salesforce Mobile SDK y las nuevas herramientas móviles que se presentan en este blog. Lleva más de 15 años creando herramientas para desarrolladores. @suzetteaberry

Alba Rivas trabaja como Principal Developer Advocate en Salesforce. Actualmente se enfoca en el desarrollo de Lightning Web Components y Slack. Puedes seguirla en Twitter @AlbaSFDC .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/02/lwc-for-mobiles-newest-features-tools.html

Categories
Developers Tutoriales de Salesforce

Lograr una CLI de Salesforce de código abierto ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Lograr una CLI de Salesforce de código abierto | Blog de desarrolladores de Salesforce

Esta es la tercera y última publicación de blog que relata el progreso del equipo de CLI de Salesforce hacia el código abierto de la interfaz de línea de comandos (CLI) de sfdx . Si no ha leído las publicaciones anteriores, consulte la primera y la segunda para refrescarse y comprender dónde comenzamos, qué tan lejos hemos llegado y hacia dónde vamos. ¡Este ha sido un largo viaje y estamos muy felices de cerrar este capítulo y poner nuestra mirada en el futuro!

CLI + OSS

Nos gustaría celebrar y decir: “¡Lo hemos logrado!” Hemos estado trabajando para desmantelar el complemento salesforce-alm (también conocido como Toolbelt) durante los últimos dos años y estamos a punto de eliminarlo por completo. El complemento salesforce-alm solía contener todos los comandos, ¡aproximadamente 201 en total! Ahora, la CLI sfdx está organizada en complementos que contienen comandos agrupados lógicamente. Por ejemplo, plugin-packaging contiene todos los comandos sfdx force:source:package(1):* . No solo movimos el código de un repositorio a otro y lo llamamos bueno, aprovechamos esta oportunidad para refactorizar todo. Modernizamos nuestro código, movimos la funcionalidad a bibliotecas que se pueden compartir entre equipos de herramientas, agregamos pruebas sólidas y confiables y reescribimos nuestro sistema CI/CD para pruebas y lanzamiento. Este fue un esfuerzo mayor de lo que habíamos supuesto inicialmente.

Para cada complemento nosotros:

  1. Se agregaron muchas pruebas unitarias y de integración para garantizar que no romperíamos los flujos de trabajo y la CI existentes.
    1. Aproximadamente 2700 pruebas unitarias que incluyen complementos y bibliotecas
    2. Aproximadamente 850 pruebas de integración para complementos y bibliotecas
  2. Se refactorizó una gran cantidad de código y funcionalidad, por lo que estamos orgullosos de ello.
    1. Reducción de una gran cantidad de redundancia y código enrevesado
    2. Como es de código abierto, puedes ver todo lo que escribimos.
  3. Se migró a las últimas versiones de nuestras bibliotecas para reducir los errores y descartar las versiones antiguas que ya no admitimos.
    1. Mismas versiones de bibliotecas para admitir sf y sfdx
    2. Una corrección de errores da como resultado dos errores corregidos
  4. Para algunos complementos más grandes, los dividimos en un complemento y una biblioteca. Esto nos permitió separar nuestras áreas de interés, crear una funcionalidad coherente en todas nuestras herramientas y permitir que otros desarrolladores de Salesforce utilicen estas bibliotecas. A partir de eso, hemos creado las siguientes bibliotecas.
    1. fuente-implementar-recuperar
    2. Seguimiento de la fuente
    3. embalaje
    4. plantillas-salesforcedx
    5. ventasforcedx-apex
    6. plugins-testkit
    7. fuente-testkit
    8. sfdx-núcleo

¡Ahora, imagina hacer eso para los 20 complementos principales que ahora instalamos cuando instalas el sfdx-cli ! Teníamos mucho trabajo por hacer, ¡pero estamos muy felices de decir que lo hemos hecho! A partir de este mes, ya no incluiremos el complemento salesforce-alm de forma predeterminada, pero siempre puede usar sfdx plugins:install salesforce-alm si realmente necesita un comando que todavía está allí.

Si recuerda las publicaciones de blog anteriores, hay un gif en cada uno que muestra la salida de sfdx plugins --core y lo usamos para mostrar cómo el complemento salesforce-alm se dividía en complementos. Ahora, si ejecuta ese comando, verá todos nuestros complementos como los describimos en la primera publicación del blog.

[contenido incrustado]

Construyendo una CLI confiable

Un tema común que escuchamos de nuestra comunidad a lo largo de los años ha sido "la confiabilidad sobre las funciones", y lo hemos tomado muy en serio. A medida que desglosamos el complemento Toolbelt, aumentamos la confiabilidad, por lo que podemos proporcionarle una herramienta de línea de comandos en la que puede confiar.

Para mejorar la confiabilidad, adoptamos un enfoque cuádruple desde el punto de vista de la ingeniería y la arquitectura.

Complementos, complementos y más complementos

Tomamos el complemento Toolbelt y lo dividimos en complementos individuales. También tenemos otros complementos de Salesforce que no están incluidos directamente con la CLI, pero están disponibles para que los instale y los ejecute si está interesado. No nos detuvimos allí, le hemos dado el poder de crear sus propios comandos a través de complementos.

Mejores bibliotecas

Abstraer la funcionalidad común en las bibliotecas nos ha ayudado mucho con la coherencia, ya que todas nuestras herramientas de desarrollo (incluidas las Extensiones para VSCode, CodeBuilder, DevOps Center, etc.) usan las mismas bibliotecas comunes. Incluso hemos visto a otros desarrolladores de Salesforce usar estas bibliotecas para resolver sus propios casos de uso.

TUERCAS para pruebas

Mejoramos las pruebas al agregar más NUT (pruebas no unitarias) que incluyen todo lo que no es una prueba unitaria, como pruebas E2E, pruebas de humo, pruebas de integración, etc. No solo probamos los complementos, sino también las bibliotecas mismas. Proporcionamos el mismo kit de prueba NUTs (que usamos internamente para escribir nuestras pruebas) para cualquier persona que quiera escribir un complemento y probar sus comandos. ¡Hemos visto que este tipo de pruebas bloquean múltiples errores y regresiones para que nunca se publiquen!

Adiós cinturón de herramientas

A partir de este mes, salesforce-alm (también conocido como Toolbelt) ya no aparecerá en la lista. Queremos tomarnos un minuto para agradecer a todos y cada uno de ustedes que se tomaron el tiempo para probar una beta: comando(s). Hubiera sido imposible entregar una herramienta CLI completamente reescrita sin muchos cambios importantes si no hubiera sido por su ayuda. Todos en el equipo de CLI y el resto de los equipos de herramientas para desarrolladores están humildemente agradecidos con todos ustedes por usar nuestras herramientas y ser parte de la comunidad.

Hablando de la comunidad, comenzamos a tener discusiones de GitHub sobre nuevas funciones, formas de corregir errores o comportamientos antiguos, preguntas o comentarios. Descubrimos que estas son formas muy útiles de recopilar ideas de todos en la comunidad y planeamos continuar usándolas en el futuro. También comenzamos a agregar la etiqueta Help Wanted a los problemas en los que una contribución de código abierto sería una forma sencilla y rápida de solucionar el problema. Por lo general, dejaremos un comentario con material de inicio para orientarlo en la dirección correcta.

Hemos visto un gran éxito de esto, por ejemplo, este problema se marcó como Help Wanted con algunos comentarios sobre dónde podría ocurrir la solución, y luego llegó esta contribución que solucionó el problema. Nos encanta ver estas interacciones y continuaremos construyendo la comunidad a su alrededor. Si desea participar, consulte la pestaña de problemas de nuestro repositorio de GitHub para ver todos los problemas Help Wanted .

¿Qué pasa con el futuro?

Puede leer más sobre las formas en que introduciremos nuevas funciones y estilos en sfdx en una publicación reciente del blog (algunas de estas ya se han introducido en sfdx ). ¡Lo alentamos a que adopte los nuevos estilos, los pruebe y comparta sus comentarios!

Conclusión

Ha sido todo un viaje lograr una CLI de código abierto en la que pueda confiar, ¡y estamos contentos de haberlo logrado finalmente! Hemos aprendido mucho en el camino, y han sido unos años locos desde que comenzamos este gran proyecto. Ya sea que haya estado usando la CLI desde antes de que comenzáramos o se unió a nosotros a la mitad de esta serie, todos en el equipo y en Salesforce están increíblemente agradecidos por usted y siempre asombrados por las formas en que continúa mejorando las herramientas. sfdx ahora es de código abierto y la CLI sf es de código abierto de forma predeterminada. Cerramos este capítulo y abrimos el siguiente capítulo sobre sf : ¡estamos llenos de energía para el próximo año y listos para traerte nuevos y emocionantes comandos!

Sobre los autores

Willie Ruemmele ha sido ingeniero en el equipo de CLI de Salesforce durante más de 3 años y ha supervisado este viaje hacia el código abierto de principio a fin. Está muy emocionado de hacer la transición del enfoque a la CLI sf y crear una gran cantidad de funciones útiles que la comunidad quiere ver. Cuando no está trabajando, le gusta estar activo al aire libre, pasar tiempo con amigos y viajar.

Pooja Reddivari es gerente sénior de gestión de productos en la organización Herramientas y experiencia para desarrolladores de plataformas en Salesforce. Le apasiona crear productos escalables y resistentes que deleiten a desarrolladores y clientes. Pooja ha trabajado en las verticales de empresa, educación y fintech con más de 12 años de experiencia como profesional de ingeniería y gestión de productos. Ella es @poojasalesforc1 en Twitter y en/poojareddivari/ en LinkedIn.

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/02/achieving-an-open-source-salesforce-cli.html

Categories
Developers Tutoriales de Salesforce

Trabajando con registros de Salesforce usando SOQL y DML ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Trabajar con registros de Salesforce utilizando SOQL y DML | Blog de desarrolladores de Salesforce

SOQL (lenguaje de consulta de objetos de Salesforce) y DML (lenguaje de manipulación de datos) son los lenguajes utilizados en Salesforce para leer y modificar registros, respectivamente. En esta publicación de blog, exploraremos cómo usarlos en Apex, incluidas las mejores prácticas para evitar alcanzar los límites del gobernador. Esto será particularmente útil para los desarrolladores que son nuevos en el desarrollo de Salesforce o para aquellos que necesitan una actualización sobre estos temas.

Multiusuario en Salesforce

Antes de sumergirse en SOQL y DML, es importante comprender primero cómo se almacenan sus registros en Salesforce. La base de datos que contiene sus registros detrás de escena en realidad no contiene una tabla SQL para cada uno de sus objetos estándar y personalizados. La base de datos almacena registros en una base de datos multiinquilino, una base de datos que almacena datos y metadatos de múltiples inquilinos de forma estandarizada. La base de datos contiene tablas genéricas para almacenar registros de objetos estándar y personalizados.

Me gusta especialmente la siguiente imagen de una sesión anterior de Dreamforce que ayuda a ilustrar cómo se almacenan los registros de diferentes inquilinos:

También me gusta la explicación de multiusuario en la página wiki de arquitectura multiusuario y la guía Mejores prácticas para implementaciones con grandes volúmenes de datos .

Como puede imaginar, un desarrollador de Salesforce no puede usar SQL para acceder a estas tablas directamente por razones de seguridad. En su lugar, lee datos escribiendo consultas SOQL que el optimizador de consultas traduce de forma transparente a las consultas SQL correspondientes. A diferencia de otros lenguajes de base de datos, los datos no se pueden modificar mediante SOQL. Tenemos otro lenguaje para hacer eso, que es DML.

Modelo de datos de ejemplo

Para ilustrar cómo funcionan SOQL y DML, usaremos un par de objetos personalizados en los ejemplos de código que se muestran más adelante en esta publicación. Tendremos un objeto personalizado Species__c para representar especies de plantas y tendremos un objeto personalizado Plant__c para representar plantas que pertenecen a una determinada especie.


En Salesforce, relaciona objetos mediante relaciones de búsqueda o maestro-detalle . Estos campos son equivalentes a lo que se conoce en otros lenguajes de base de datos como clave externa, un campo que hace referencia a otro objeto. Esto significa que el objeto Plant__c tendrá una relación de búsqueda con Species__c (su padre).

Lectura de datos con SOQL

Comencemos hablando de SOQL. La siguiente es una consulta SOQL simple que usamos para leer registros para un objeto personalizado llamado Plant__c :

2021-01-01 ORDER BY Acquisition_Date__c LIMIT 3″>

Examinemos las diferentes palabras clave utilizadas en la consulta:

  • SELECT : se utiliza para indicar los campos que desea recuperar. El único que se devuelve por defecto es el campo Id . Puede SELECT FIELDS(STANDARD) para recuperar todos los campos estándar para los que el usuario tiene permisos. Eche un vistazo a todas las opciones disponibles para la función y las API en las que son compatibles.
  • FROM : la tabla principal de la que queremos recuperar los registros
  • WHERE : se utiliza para especificar las condiciones del filtro.
  • ORDER BY : se utiliza para ordenar los resultados por un campo específico
  • LIMIT : para limitar el número de resultados devueltos. Sugerencia: el uso LIMIT 1 le permite asignar el resultado en Apex a una única variable de registro. Solo use esta opción si está 100% seguro de que el registro siempre estará allí.

El siguiente es el resultado de esta consulta en una organización en la que creé algunos datos de muestra:

Puede ejecutar consultas con fines de depuración en Developer Console, o preferiblemente en VSCode después de haber instalado el paquete de extensión de Salesforce . En VSCode existen diferentes opciones para hacerlo. La opción preferida y más sencilla es utilizar SOQL Builder , una herramienta para crear y ejecutar consultas visualmente. También puede ejecutar una consulta escrita seleccionándola en el texto o introduciéndola en línea en la barra de comandos .


Sin embargo, donde normalmente usará consultas en producción es en su código Apex. Los objetos estándar y personalizados (también otros tipos de objetos, como los objetos externos) tienen un tipo de datos equivalente en Apex. Por ejemplo, tener un objeto Species__c implica que hay una clase Species__c que representa objetos de ese tipo y que contiene todos los campos del objeto Species__c . También hay una clase sObject genérica que puede usar para cualquier tipo de objeto. Puede construir estos tipos usted mismo o usarlos para almacenar los registros devueltos por una consulta SOQL:

Así es como llamamos a nuestra consulta SOQL desde Apex, encerrándola entre corchetes y asignando el valor devuelto a una List<sObject> o List<ConcreteObject__c> :

<dx-code-block title language code-block="// Executing a query and storying its returned value
List plants = [SELECT Name, Acquisition_Date__c FROM Plant__c WHERE Acquisition_Date__c > 2021-01-01];»>

En la consulta anterior, especificamos todos los valores que queríamos usar, como la fecha de adquisición para filtrar o el número de registro para limitar. Pero, ¿y si no conoce esos valores de antemano? En ese caso, puede vincular las variables de Apex mediante dos puntos ( : de la siguiente manera:

<dx-code-block title language code-block="// Binding an Apex variable
Date acquisitionDate = Date.newInstance(2021,01,01);
List plants = [SELECT Name, Acquisition_Date__c FROM Plant__c WHERE Acquisition_Date__c > :acquisitionDate];»>

El resultado en este caso sería exactamente el mismo, pero la variable acquisitionDate se evaluaría en tiempo de ejecución.

Nota: En Apex, asegúrese de incluir WITH SECURITY_ENFORCED (ver documentos ) en sus consultas, para hacer cumplir la verificación de permisos de seguridad a nivel de campo y objeto.

Traer registros relacionados con consultas de relación

Analicemos ahora cómo puede incorporar datos de registros relacionados en sus consultas SOQL. Esta es probablemente la diferencia más notable con otros lenguajes de consulta. En SOQL, ejecuta consultas en una sola tabla y luego tiene mecanismos para traer datos relacionados como parte de la consulta. Para hacer eso, los objetos necesitan tener una relación. Concretamente, puedes:

  • Consultar a un niño y traer sus datos principales (consulta de niño a padre)
  • Consultar a un padre y traer los datos de sus hijos (consulta de padre a hijo)

Esto significa que en SOQL se pueden realizar uniones como en otros lenguajes de consulta, pero usando una sintaxis diferente y siempre en base a una clave foránea (relación). Esta decisión de diseño se tomó para aumentar el rendimiento en el momento en que el optimizador de consultas traduce las consultas a SQL.

Consultas de relación de hijo a padre

Este tipo de consultas le permiten ejecutar la consulta principal en un objeto secundario y traer sus datos principales como parte del resultado.

Para poder hacer referencia al padre en la parte SELECT , necesitaremos usar el nombre de la API que representa la relación con el padre. En nuestro caso, al ser un objeto personalizado, será el nombre del campo de relación sustituyendo __c por __r . Para objetos estándar, solo use el nombre de la API del campo de relación.

<dx-code-block title language code-block="List plants = [SELECT Name, Acquisition_date__c, Species__r.Name FROM Plant__c];»>

Este es el resultado que obtuve para mi organización:

Si desea obtener información sobre las relaciones de objetos estándar, eche un vistazo a los diferentes modelos de datos de aplicaciones en el sitio de Salesforce Architects.

Consultas de relación padre-hijo

Este tipo de consultas le permiten ejecutar la consulta principal en un objeto principal y traer los datos de sus hijos como parte del resultado.

Para poder hacer referencia a la lista de elementos secundarios en la parte SELECT , necesitaremos usar el nombre de la relación secundaria definido en el campo de relación más __r , o solo el nombre de la relación secundaria para los objetos estándar. En este caso, como el padre puede tener varios hijos, necesitaremos usar una subconsulta.


Por ejemplo, en nuestro caso, podemos traer todas nuestras especies con sus plantas hijas:

<dx-code-block title language code-block="List species = [SELECT Name, (SELECT Name FROM Plants__r) FROM Species__c];»>

El resultado:

Es decir, ¡tengo dos plantas de Jazmín, una Pothos y dos Aloe Vera en mi terraza!

Para manejar el resultado en Apex, tenga en cuenta que el campo de relación devuelto contendrá una lista de hijos:

Hacer más con los campos de relación

Hay mucho más que podemos hacer en SOQL. Por ejemplo, podríamos usar campos de relación principal en la parte WHERE para filtrar por valor(es) de campo principal:

<dx-code-block title language code-block="List plants = [SELECT Name, Acquisition_date__c FROM Plant__c WHERE Species__r.Name = ‘Aloe Vera’];»><dx-code-block title language code-block="List speciesNames = new List{‘Aloe Vera’,’Jasmine’}; // Can also be a Set
List plants = [SELECT Name, Acquisition_date__c FROM Plant__c WHERE Species__r.Name IN :speciesNames];»>

O también podríamos usar una subconsulta en la parte WHERE para filtrar por hijos relacionados:

<dx-code-block title language code-block="List plants = [SELECT Name, Acquisition_date__c FROM Plant__c WHERE Species__c IN (SELECT Id FROM Species__c WHERE Name IN (‘Aloe vera’,’Jasmine’))];»>

Construcción de consultas en tiempo de ejecución con SOQL dinámico

Hasta ahora, hemos usado SOQL estático para ejecutar nuestras consultas. Pero a veces, debe construir la consulta en tiempo de ejecución (en forma de cadena) y luego ejecutarla como una consulta dinámica . Así es como lo haces:

<dx-code-block title language code-block="String myQuery = 'SELECT Name FROM Species__c';
List sobjList = Database.query(myQuery); // Can be assigned to List too»>

Se prefieren las consultas estáticas cuando es posible, ya que se evalúan en el momento de la compilación, lo que evita consultas mal construidas y ataques de inyección de SOQL. Para evitar la inyección de SOQL en consultas dinámicas, vincule siempre el valor proporcionado por el usuario utilizando la notación de dos puntos.

Aprovechar el poder de las consultas agregadas

Las consultas agregadas le permiten acumular y resumir registros. Por ejemplo, puedo contar la cantidad de registros que coinciden con una condición específica, como la cantidad de plantas de Aloe Vera que tengo:

O puedo usar la función AVG() para calcular los valores promedio de temperatura máxima que admite mi especie:

<dx-code-block title language code-block="List groupedResults = [SELECT AVG(Max_Temperature__c) avgTemp FROM Species__c]; for (AggregateResult ar : groupedResults) { System.debug(‘Average Temperature: ‘ + ar.get(‘avgTemp’));
}»>

Esto es lo que obtuve como resultado:

Las consultas agregadas se vuelven aún más poderosas cuando se usa GROUP BY . Por ejemplo, así es como calculo los valores promedio de temperatura máxima que soporta mi especie, agrupados por tipo de especie (ornamental o comestible):

<dx-code-block title language code-block="List groupedResults = [SELECT Type__c, AVG(Max_Temperature__c) avgTemp FROM Species__c GROUP BY Type__c]; for (AggregateResult ar : groupedResults) { System.debug(‘Type__c: ‘ + ar.get(‘Type__c’)); System.debug(‘Average Temperature: ‘ + ar.get(‘avgTemp’));
}»>

En este caso, obteniendo:

Modificación de registros con DML

A continuación, echemos un vistazo a cómo manipula los registros en Apex. Para ello, en lugar de utilizar SOQL, utilizamos DML , nuestro lenguaje de manipulación de datos. Gracias al uso de DML para la modificación de registros, podemos prevenir fallas de inyección de SOQL asociadas a estas operaciones.

Con DML, puede insert , update , upsert , delete e incluso undelete y merge registros utilizando esas palabras clave antes de un registro o una lista de registros para manipular. Aquí hay unos ejemplos:

Manejo de excepciones y control de transacciones para operaciones DML

El manejo de excepciones es un aspecto importante a tener en cuenta al realizar operaciones DML. Si una operación DML falla, el tiempo de ejecución de Apex lanza una DMLException . Esto puede suceder, por ejemplo, cuando el sObject a modificar contiene valores incorrectos o cuando no se cumple una validación en un disparador. Si no se manejan las excepciones, Salesforce revierte automáticamente todas las operaciones DML que ocurrieron durante esa transacción .

Puede manejar excepciones y realizar reversiones totales o parciales usted mismo utilizando los mecanismos de control de transacciones de Apex.

En este caso, si el registro Species__c se insertó correctamente pero la creación del registro Plant__c falló, el registro Species__c aún se creará. La reversión automática de Salesforce no sucedió; en su lugar, revertimos manualmente la base de datos al estado que tenía después de que se creó el registro Species__c . Al hacer eso, revertimos cualquier cambio realizado por los activadores y automatizaciones que se ejecutaron durante la operación de inserción de la planta antes de que ocurriera la falla. De esa manera, mantuvimos la integridad de los datos.

Modificación de registros en tiempo de ejecución con DML dinámico

De la misma manera que construye consultas dinámicas, puede crear registros dinámicamente y luego manipularlos usando DML. Esta opción puede ser interesante cuando no se sabe el nombre del objeto o los campos a modificar de antemano.

Límites del gobernador y aumento de volumen

Por último, cubramos un concepto importante que los desarrolladores de Salesforce deben comprender y tener en cuenta al escribir código. El concepto de tenencia múltiple no solo se aplica a la base de datos. Toda su instancia de Salesforce se ejecuta en una infraestructura compartida de forma segura con otros inquilinos. Es por eso que Salesforce evita que su código personalizado monopolice los recursos y, lo que más me gusta del desarrollo de Salesforce, necesita escribir un código óptimo, porque si no lo hace, alcanzará fácilmente los límites del gobernador . Algunos límites reguladores que se aplican a las operaciones SOQL y DML son:

  • Puede ejecutar como máximo 100 consultas SOQL dentro de una transacción
  • Puede ejecutar como máximo 150 declaraciones DML en una transacción

Esto significa que para minimizar la cantidad de consultas SOQL y operaciones DML que su código ejecuta dentro de una transacción, es una buena práctica:

  • Realice siempre esas operaciones sobre colecciones de registros en lugar de sobre registros únicos (lo que llamamos "agrupar").
  • Nunca, nunca, nunca ejecute SOQL o DML dentro de un ciclo
  • Use SOQL para bucles (más eficiente) cuando sea posible

Sugerencia: sus bloques catch no podrán manejar las excepciones de límite del regulador y siempre se comportarán como excepciones no controladas, lo que resultará en una reversión completa.

SOSL

En una nota final, hay otro lenguaje que se usa para construir consultas de texto basadas en búsqueda llamado SOSL (Lenguaje de búsqueda de objetos de Salesforce), sin embargo, no cubriremos SOSL en esta publicación de blog.

Recursos y próximos pasos

En esta publicación de blog, aprendió sobre los aspectos más importantes que un desarrollador de Salesforce debe conocer para comenzar a escribir código Apex que funcione con registros de Salesforce. Hemos visto cómo funciona SOQL para leer registros y cómo modificar registros usando DML.

Algunas entradas de blog relacionadas:

Y si prefiere ponerse manos a la obra, diríjase a Trailhead y aborde los siguientes módulos:

Autores

Alba Rivas trabaja como Principal Developer Advocate en Salesforce. Actualmente se enfoca en el desarrollo de Lightning Web Components y Slack. Puedes seguirla en Twitter @AlbaSFDC .

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/08/working-with-salesforce-records-using-soql-and-dml.html

Categories
Developers Tutoriales de Salesforce

Aprende MOAR en Summer '22 con Developer Tooling ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Siga y complete un trailmix de Learn MOAR Summer '22 para administradores o desarrolladores antes del 31 de julio de 2022 a las 11:59 p. Se aplican restricciones. Aprenda cómo participar y revise las reglas oficiales visitando la página de Trailhead Quests .

El lanzamiento de Summer '22 trae consigo una serie de actualizaciones a nuestras herramientas para desarrolladores que ayudarán a aumentar su productividad y experiencia como desarrollador. Desde actualizaciones de VS Code Extension hasta algunas características completamente nuevas, el futuro es brillante para los desarrolladores de Salesforce. Echemos un vistazo a todas las funciones nuevas que los desarrolladores pueden usar a medida que amplían Salesforce con código.

Actualizaciones de la extensión de código VS

En Salesforce, nos esforzamos por mejorar y actualizar continuamente nuestras herramientas de desarrollador para garantizar que tenga la mejor experiencia de desarrollador posible. Puede mantenerse al día con los últimos cambios directamente en el repositorio de salesforcedx-vscode en GitHub consultando el registro de cambios .

Comando Renombrar componente

Los desarrolladores de componentes de iluminación han estado esperando la posibilidad de cambiar el nombre de los componentes web de iluminación y los componentes de aura dentro de un proyecto. ¡Con el nuevo comando Renombrar componente, es fácil!

Todo lo que tiene que hacer es hacer clic con el botón derecho en el directorio de un componente de iluminación y seleccionar SFDX: Renombrar componente. Aquí podrá proporcionar un nombre y se cambiará el nombre de todos los archivos.

Compatibilidad mejorada con Apex anónimo

Hay algunas mejoras excelentes para Apex en VS Code. Una función muy solicitada ahora está disponible: ¡Soporte de autocompletar en archivos .apex! Este es un gran ahorro de tiempo para los desarrolladores y debería proporcionar un gran impulso a la productividad.

Sabemos que los desarrolladores de Salesforce usan Apex anónimo para probar el código sin necesidad de implementarlo. Sin autocompletar, esto puede convertirse en una tarea desalentadora. Es por eso que también agregamos soporte de autocompletado para las clases de Apex anónimas en VS Code. Además de esto, ahora puede hacer clic en la lente Ejecutar código Apex anónimo que aparecerá en la parte superior de su archivo.

Depurador de reproducción de Apex: la manera fácil

Muchos desarrolladores han adoptado Replay Debugger, sin embargo, usarlo siempre ha implicado bastantes pasos. Requería que activase los indicadores de rastreo, ejecutara su código para generar un registro de depuración y luego iniciara Replay Debugger con su archivo de registro. Bueno, ahora puede acceder directamente al depurador de reproducción directamente desde su archivo Apex anónimo o su clase de prueba. Para comenzar, todo lo que tiene que hacer es abrir la paleta de comandos mientras está en su prueba o iniciarla directamente desde su archivo.

Generador de manifiestos

El Generador de manifiestos está aquí para ayudarlo a crear más fácilmente sus manifiestos (o package.xml como lo conoce actualmente). Enumera componentes o tipos de metadatos específicos que puede usar para implementar grandes cantidades de metadatos al mismo tiempo. La extensión Manifest Builder le permitirá seleccionar archivos específicos que le gustaría implementar, directamente desde la vista del Explorador.

Plantillas personalizadas para sus comandos Create

¿Siempre ha querido que su propio código repetitivo aparezca en los archivos de origen cuando crea un objeto de metadatos como una clase de Apex? Bueno, ahora puedes usar plantillas personalizadas para hacer precisamente eso. Agregamos la capacidad de personalizar las plantillas utilizadas detrás de escena para su SFDX: Create Apex Class , SFDX: Create LWC Component , SFDX: Create Aura Component y otras tareas de creación en VS Code.

Las plantillas son esencialmente carpetas con archivos que contienen su código personalizado. Puede consultar nuestro repositorio git de muestra que es una colección de plantillas oficiales de Salesforce para componentes de metadatos. Simplemente clone este repositorio, manteniendo la misma estructura de carpetas, luego actualice los archivos de plantilla relevantes con su código. Elimine los archivos que no desea anular y tendrá su propia plantilla personalizada lista para usar.

Actualizaciones de CLI

También vale la pena mencionar algunas actualizaciones notables de la CLI de esta versión. Después de una versión beta exitosa y de la incorporación de los comentarios de nuestra comunidad, los siguientes comandos que solían estar en el tema force:mdapi:beta ahora están disponibles de forma general:

  • force:mdapi:deploy
  • force:mdapi:retrieve
  • force:mdapi:deploy:report
  • force:mdapi:retrieve:report
  • force:mdapi:convert

¿Qué significa esto? La funcionalidad que agregamos a force:mdapi:beta:deploy , por ejemplo, ahora está en force:mdapi:deploy . La funcionalidad del antiguo force:mdapi:deploy ahora está en force:mdapi:legacy:deploy . A corto plazo, puede usar estos comandos force:mdapi:legacy si tiene problemas con los nuevos comandos. Los nuevos comandos son de código abierto y se encuentran en el complemento plugin-source .

Aprende MOAR esta semana

Los gerentes de producto y el equipo de relaciones con los desarrolladores están de regreso para compartir las características y funcionalidades más recientes en Summer '22. Para ayudarlo a desarrollarse más rápido, el nuevo contenido de Developer Relations cubrirá sus nuevas características favoritas. Además, asegúrese de consultar Release Readiness Live el viernes 20 de mayo de 2022 a las 9:00 a. m. PST . Por último, esté atento al blog de desarrolladores de Salesforce todos los días de esta semana para obtener más publicaciones sobre Summer '22.

Para obtener aún más información, consulte la mezcla de senderos Summer '22 .

Sobre el Autor

Stephan Chandler-Garcia es desarrollador evangelista sénior en Salesforce. Se centra en el desarrollo de aplicaciones, la seguridad y Experience Cloud. Puedes seguirlo en Twitter @stephanwcg .

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/05/learn-moar-in-summer-22-with-developer-tooling.html

Categories
Developers Tutoriales de Salesforce

Creación de una aplicación de Slack que se integre con Salesforce: Parte 4: desarrollo local y depuración ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Esta es la cuarta publicación de blog de una serie de cinco partes.

Crear una aplicación de Slack que se integre con Salesforce implica algunos desafíos, como conocer la capacidad de integración correcta para usar en cada caso, elegir el flujo de autorización correcto e implementarlo de forma segura. Esta es la cuarta publicación de blog de una serie en la que cubrimos todo el proceso de creación de una aplicación de Slack que se integre con Salesforce desde cero. Aprenda junto con nosotros mientras creamos Ready to Fly , nuestra nueva aplicación de muestra para enviar y aprobar solicitudes de viaje en Salesforce sin salir de Slack.

Nota: algunas partes de esta aplicación han sido codificadas en vivo por mis colegas Mohith Shrivastava (@msrivastav13) y Kevin Poorman (@codefriar) en su serie de videos codeLive: Building with Slack .

Revisa las publicaciones anteriores del blog:

Mejorar la experiencia del desarrollador

Hasta ahora, hemos visto cómo se diseñan las diferentes partes de nuestra aplicación Ready to Fly y cómo hacemos que los diferentes sistemas interactúen. Puede compilar toda la aplicación mientras envía cambios a Salesforce y Heroku cada vez; sin embargo, podemos obtener una experiencia de desarrollador mucho mejor al ejecutar nuestra aplicación Node.js localmente y usar un depurador.

Desarrollo local con Modo Socket

La opción más sencilla para ejecutar una aplicación de Slack localmente es ejecutarla en modo Socket , donde Slack proporciona una URL de WebSocket dedicada a su aplicación. WebSocket es un protocolo que, a diferencia de HTTP, permite la comunicación bidireccional entre el cliente y el servidor. Al usar el modo de socket, no necesita exponer un punto final HTTP público para recibir eventos de Slack. La URL con la que Slack se comunica se crea en tiempo de ejecución y Bolt la actualiza periódicamente. El modo Socket también se puede usar para ejecutar aplicaciones detrás de un firewall. Obtenga más información leyendo las instrucciones para ejecutar su aplicación en modo Socket.

Sin embargo, hay algunos casos en los que el modo Socket no se puede utilizar actualmente para el desarrollo local, por ejemplo, si necesita:

  • Implemente el flujo Slack OAuth (p. ej., para aplicaciones de directorio ) para almacenar la información de instalación de forma segura
  • Llame desde Salesforce a una ruta HTTP personalizada definida en Slack
  • Use un ExpressReceiver personalizado para enrutar las solicitudes HTTP cuando el receptor original no funcione para usted

En esos casos, la opción alternativa es utilizar una solución de tunelización, como ngrok . Esto es lo que tuvimos que usar en las últimas etapas de desarrollo de Ready to Fly. Como implementamos una llamada de Salesforce a Slack, también necesitábamos un ExpressReceiver personalizado para usar la biblioteca express-session rápida, ya que el estándar no es compatible con el middleware.

Desarrollo local con ngrok

Ngrok expone su servidor local al exterior a través de un túnel seguro. Cuando lo ejecuta, proporciona una URL pública que puede usar en sus integraciones, por ejemplo, para llamar desde Salesforce a la aplicación Node.js que se ejecuta en su máquina local.

Tienes varias opciones para instalar ngrok . En nuestro caso, decidí usar npm:

 npm instalar ngrok -g

A continuación, tendrás que registrarte . Una vez que haya iniciado sesión, vaya a "Configuración e instalación" y copie su token de autenticación, ya que deberá almacenarlo en su máquina local.

La forma más fácil de almacenar su token de autenticación es ejecutar:

 ngrok authtoken my_auth_token

¡Y eso es todo! Después de eso, podrá ejecutar un túnel ngrok de la siguiente manera:

 ngrok http 3000

En la imagen de arriba, podemos ver cómo se está ejecutando el túnel ngrok. Las solicitudes que lleguen a http://2246-213-194-153-236.ngrok.io serán reenviadas por ngrok a http://localhost:3000.

Veamos ahora cómo configurar Slack, Salesforce y la aplicación Node.js para usar esa URL pública de ngrok. Tendrá que copiar la URL pública en varios lugares (¡asegúrese de copiar el HTTPS!):

1. Copie la URL pública en las URL de solicitud de su aplicación de Slack. Puede encontrar la configuración de la aplicación Slack en api.slack.com .

2. Copie la URL pública en el archivo .env de la aplicación Node.js para anular la variable de entorno HEROKU_URL.

Es una buena práctica almacenar la configuración en variables de entorno . De esa forma, la configuración de diferentes entornos de ejecución es sencilla y los tokens y los secretos se mantienen seguros, separados de su código fuente. Como parte de la configuración realizada por el kit Slack Starter de Salesforce , las variables de entorno se configuran en Heroku a través de config vars, pero también en un archivo .env local que nunca se compromete con el repositorio.

Luego, usamos la biblioteca dotenv npm para leerlos en el código de la aplicación Node.js, lo que significa que las vars de Heroku se usarán cuando la aplicación se ejecute en Heroku. Pero cuando se ejecuta localmente, se usará el archivo .env vars en su lugar. Ese es el archivo donde tendrá que actualizar el valor de la variable de entorno HEROKU_URL para que apunte a la URL pública de ngrok.

3. Agregue la URL pública de ngrok en el campo URL de devolución de llamada de la aplicación conectada en Salesforce. Eso es lo que usamos para la autorización. Encontrará la definición de la aplicación conectada en "Configuración → Administrador de aplicaciones".


4. Agregue una nueva configuración de sitio remoto que contenga la URL pública de ngrok. Este es el que usaremos para llamar desde Salesforce a Slack, ¡y debemos hacer que Salesforce lo permita!

5. Modifique el campo BoltAppConfigHeroku del registro de tipo de metadatos personalizado de URL__c tal como se usa en la lógica de Apex para realizar la llamada.

¡Ahora está preparado para ejecutar Ready to Fly localmente! En otra terminal (diferente a la que está ejecutando ngrok), ejecute node app.js Su aplicación se ejecutará en https://localhost:3000 y ngrok canalizará cualquier solicitud entrante a esa dirección. A continuación, puede realizar cambios en el código, así como iniciar y detener la aplicación tantas veces como desee, lo que hace que el desarrollo sea mucho más fácil y productivo.

depuración

Para maximizar aún más la productividad, y dado que su aplicación ahora se ejecuta localmente, puede adjuntar un depurador. Una forma simple y efectiva de hacerlo es usar VSCode:

  • Vaya a la pestaña "Ejecutar y depurar" en VSCode
  • Seleccione "Terminal de depuración de JavaScript" en el menú desplegable y haga clic en el botón Reproducir

  • ¡Agregue puntos de interrupción a su código!
  • Finalmente, ejecute la aplicación en el terminal de depuración de JavaScript con node app.js Recuerde detener cualquier otra instancia en ejecución de la aplicación de antemano para evitar que se use el puerto. Cuando interactúa con la aplicación, desde Salesforce o desde Slack, el código se detendrá en los puntos de interrupción alcanzados y podrá examinar las variables, la pila de llamadas, etc., lo que se vuelve extremadamente efectivo al desarrollar Node.js aplicación!

Otras herramientas para desarrolladores

Finalmente, quiero mencionar algo más que me resultó muy útil: las herramientas para desarrolladores de Slack . Estos le permiten obtener acceso rápido a los documentos API de Slack dentro de Slack, recuperar información útil como ID de conversación y espacio de trabajo, e investigar la estructura de los mensajes del canal. ¡Darle una oportunidad!

Terminando

En esta publicación de blog, hemos cubierto cómo ejecutar la parte de la aplicación Node.js de nuestra integración localmente. También hemos visto cómo usar un depurador para poder detenernos en los puntos de interrupción e inspeccionar nuestro código en profundidad. Estas herramientas, junto con las herramientas para desarrolladores de Slack, lo convertirán en un desarrollador mucho más productivo (¡y feliz!) al crear una aplicación de Slack.

¡Asegúrese de clonar el kit de inicio de Slack de Salesforce y pruebe el desarrollo local con ngrok!

Estén atentos a la publicación de blog final de la serie en la que cubriremos las funciones interesantes en las que Salesforce está trabajando para hacer que el desarrollo de las aplicaciones de Slack + Salesforce sea mucho más fácil.

Sobre el Autor

Alba Rivas trabaja como Principal Developer Advocate en Salesforce. Se centra en los componentes web Lightning y la estrategia de adopción de Lightning. Puedes seguirla en Twitter @AlbaSFDC .

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/03/building-a-slack-app-that-integrates-with-salesforce-part-4-local-development-and-debugging.html

Categories
Developers Tutoriales de Salesforce

The Codey Awards: celebrando el mejor contenido de 2021 ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

2021 fue un GRAN año para los desarrolladores de Salesforce. Vimos innumerables funciones nuevas y emocionantes, innovaciones inspiradoras en toda la comunidad y asistimos a algunos eventos increíbles, en persona y virtualmente. Celebramos los mejores momentos destacados del contenido de 2021 y se los traemos con The Codeys.

Siga leyendo para ver la lista y ponerse al día con cualquiera que se haya perdido el año pasado. ⤵️

SOQL Builder está generalmente disponible

SOQL Builder es una extensión de VSCode que facilita el diseño de consultas en sus datos de Salesforce.

Las funciones de Salesforce están generalmente disponibles

Aprovechando el poder de la computación elástica y la flexibilidad del lenguaje abierto, Salesforce Functions hace que sea más fácil que nunca ampliar sus datos y flujos de trabajo.

Serie de sitios Lightning Web Runtime

Comience a crear sitios Lightning Web Runtime con esta conveniente serie de videos en nuestro canal oficial de YouTube.

Cree experiencias escalables: funciones y CLI

Esta emocionante demostración fue una de las favoritas de la multitud en TDX21; puede verla usted mismo a pedido en Salesforce+.

Pub/Sub API: crear integraciones basadas en eventos ahora es aún más fácil

Descubra cómo la próxima disponibilidad general de Pub/Sub API revolucionará y simplificará la forma en que creamos integraciones basadas en eventos.

Desarrolle aplicaciones empresariales con Apex

Obtenga la primicia sobre cómo se ve la creación de aplicaciones modernas de nivel empresarial utilizando Apex. Este destacado de Dreamforce 2021 está disponible en Salesforce+.

Aplicación de estilos a componentes web Lightning mediante propiedades públicas

Mire esta breve toma rápida en nuestro canal de YouTube para aprender cómo hacer que el estilo y la personalización de los componentes sean fácilmente accesibles para un administrador de Salesforce.

¡Eso es un final para 2021! Esperamos que haya disfrutado ser parte de la comunidad de desarrolladores de Salesforce el año pasado y estamos ansiosos por compartir aún más con usted en 2022.

Asegúrese de unirse a nosotros en la Comunidad Trailblazer de desarrolladores de Salesforce recientemente actualizada para mantenerse actualizado sobre los últimos anuncios, conectarse con sus pares y obtener respuestas a sus preguntas por parte de otros desarrolladores.

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/01/the-codey-awards-celebrating-the-top-content-of-2021.html

Categories
Developers Tutoriales de Salesforce

Rompimos ganchos de despliegue/recuperación ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

La CLI de Salesforce ha realizado, y seguirá realizando, algunos cambios importantes en el funcionamiento de los ganchos de implementación y recuperación . Si crea o usa complementos personalizados que utilizan ganchos predeploy , postdeploy , preretrieve , postretrieve o postsourceupdate , hay cambios tanto en la carga útil como en el comportamiento de esos ganchos que podrían afectarlo.

En esta publicación de blog, explicaremos por qué estamos haciendo estos cambios. También analizaremos los detalles de los cambios y brindaremos ejemplos de lo que se romperá y lo que no, junto con posibles soluciones alternativas y algunas declaraciones prospectivas.

Fondo de ganchos y caso de uso de ejemplo

Echemos un vistazo a cómo solían funcionar los ganchos. Antes de nuestros cambios recientes, los ganchos de implementación y recuperación proporcionaban una forma de interceptar metadatos (código, configuración, etc.) que iban desde su máquina local a una organización de Salesforce (o viceversa) y realizaban cambios en la operación de implementación/recuperación.

Por ejemplo, un gancho del mundo real que encontramos reemplazó los marcadores de posición en la fuente local con secretos. Para comprender cómo funcionó, consideremos el caso de uso de una fuente de datos externa de Salesforce Connect. Supongamos que desea implementar y ejecutar pruebas con una fuente de datos externa, pero no desea almacenar un campo de password en el control de fuente.

Su gancho podría reemplazar $xdsPassword

 < password>$xdsPassword</password>

con un valor del medio ambiente

 < password>myPwdFromTheEnv</password>

antes del despliegue.

Luego, la máquina de un desarrollador o un sistema de CI que tiene la variable de entorno puede implementar los metadatos de ExternalDataSource sin siquiera escribir la contraseña en los archivos de origen.

Cómo solían funcionar los ganchos durante una implementación

Hasta la versión 7.111 de CLI, un comando force:source:deploy funcionaba así:

  1. En una implementación, la CLI convertiría todo el código con formato fuente al formato API de metadatos (leería cada archivo y lo escribiría en un directorio temporal).
  2. Los mdapiFilePath predeploy apuntaría a cada archivo temporal junto con los metadatos sobre ese archivo.
  3. El código de ganchos recibiría esa matriz de archivos y realizaría cualquier lógica
  4. En nuestro ejemplo, el complemento personalizado buscaría tipos de ExternalDataSource y luego abriría ese archivo y modificaría el valor de la password con el valor del entorno.
  5. El enlace saldría y la CLI continuaría comprimiendo los metadatos (ahora modificados) y enviándolos a la API de metadatos.

Como desarrollador de complementos, puede garantizar la ejecución constante de su código de enlace en cada implementación realizada desde la CLI o las extensiones de VSCode, ya que llamaban a la CLI.

force:source: retrieve y force:source:pull funcionaron casi igual, pero a la inversa. Ellos recuperarían el archivo zip, lo descomprimirían en un directorio temporal, activarían ganchos posteriores a la recuperación para permitirle modificar el resultado, y luego convertirlo y escribirlo en sus carpetas de origen.

Conozca la nueva biblioteca de implementación/recuperación de fuentes

Escuchamos de nuestros usuarios que querían implementaciones más rápidas y que las implementaciones grandes eran particularmente lentas. Además, los usuarios de la extensión VSCode que cambiaron un archivo querían implementarlo en su organización de Salesforce lo más rápido posible. Para abordar estas preocupaciones y aumentar la velocidad de implementación y recuperación, creamos la biblioteca Source Deploy/Retrieve (SDR).

El SDR acelera la implementación/recuperación al:

Reducción de las operaciones del sistema de archivos. En lugar de escribir cada archivo convertido en el directorio temporal, escribir esa carpeta en un archivo zip y cargar el zip, el SDR transmite archivos desde el código fuente a un archivo zip en memoria que va directamente a la API de metadatos. La única operación del sistema de archivos es leer los archivos que se implementarán. Las operaciones del sistema de archivos son lentas, especialmente en máquinas con Windows, y evitarlas significa implementaciones más rápidas. Los proyectos grandes pueden tener 10 000 archivos de metadatos en una implementación (¡y potencialmente muchos más una vez que todos esos elementos secundarios descompuestos de CustomObject se conviertan en archivos individuales!)

Dado que no todos usaban una versión reciente de CLI que incluye SDR, observamos las métricas de octubre y observamos una reducción del 36 % en el tiempo medio de implementación y una reducción del 57 % en el tiempo de recuperación (y una enorme reducción del 75 % en implementaciones en el percentil 90… las que estaban tardando bastante).

Permitiendo el uso directo por VSCode. Salesforce VSCode Extensions originalmente usaba la CLI para implementar y recuperar metadatos. Dado que la CLI se cargó como un proceso secundario, su uso agregó mucho tiempo de sobrecarga a los comandos de implementación/recuperación en VS Code. Llamar a la CLI directamente también significaba que estábamos analizando automáticamente los indicadores de entrada, haciendo validaciones, cargando mensajes de ayuda, etc., la mayoría de los cuales no son necesarios cada vez que "implementa al guardar", por ejemplo. Las extensiones de Salesforce ahora hacen llamadas directamente al SDR y ahorran mucho tiempo al no generar procesos secundarios ni realizar tareas innecesarias relacionadas con la CLI.

Además de estas ganancias de rendimiento, SDR es una biblioteca de código abierto que puede ser utilizada por cualquier otra persona que escriba herramientas de metadatos; no es trivial mantener la lógica de conversión para los cientos de tipos de metadatos y las docenas de tipos nuevos que aparecen en cada uno. Lanzamiento de la fuerza de ventas. Si su complemento personalizado trata con metadatos o la API de metadatos, esta es una gran mejora para usted.

Para lograr estas ganancias, estamos adoptando el SDR. Sin embargo, eso rompe algunos casos de uso para ganchos.

¿Qué está usando SDR?

A partir de la versión 7.135.0, la CLI actualmente usa SDR para:

  • source:deploy, source:retrieve , source:convert y source:delete (y sus variantes de report )
  • source:beta:pull, source:beta:push y source:beta:status que ofrecen ganancias de rendimiento similares a las que se muestran arriba
  • mdapi:beta deploy retrieve y deploy:report

En Salesforce VS Code Extensions, usamos SDR en las siguientes áreas:

  • Comandos del menú contextual y de la paleta de comandos: Deploy/Retrieve Source from Manifest , Deploy/Retrieve Source from Org
  • Navegador de la organización
  • Detección de conflictos
  • Funcionalidad de prueba de Apex

Cómo el SDR rompe anzuelos

En primer lugar, se eliminó postsourceupdate para los comandos de recuperación en 7.112.0, por lo que los ganchos que dependen de él no se ejecutarán. La conversión de fuente ocurre en la secuencia tan pronto como se descarga y descomprime el zip recuperado, por lo que postretrieve ahora ocurre en la misma etapa que la postsourceupdate (es decir, después de que se escriben los archivos de formato de fuente local).

En segundo lugar, no hay una ruta de directorio temporal para modificar el código. Si sus ganchos esperaban usar la ubicación temporal de la fuente con formato de metadatos, ya no existe.

En tercer lugar, las extensiones de VSCode ahora llaman directamente al SDR (en lugar de a la CLI) para implementar/recuperar. Los ganchos no se activarán en absoluto para las operaciones de implementación/recuperación iniciadas desde VSCode a menos que esté utilizando la CLI en la terminal de VSCode.

Ejemplos y soluciones

En nuestro ejemplo anterior (reemplazando un marcador de posición con secretos del entorno), el complemento puede ver lo que se va a implementar desde el predeploy a la implementación. Pero sin el directorio temporal, no puede realizar ningún cambio en el código fuente antes de implementarlo. En este caso, el desarrollador podría hacer una de las siguientes cosas:

  1. Escriba un comando de deploy o push personalizado que incluya el paso de secretos. Es significativamente más fácil ahora que nuestros comandos son de código abierto y el SDR está disponible.
  2. Escriba un script de shell que haga de manera efectiva lo que hizo el proceso original de ganchos:
    1. Convierta los archivos de origen en una carpeta de metadatos temporal ( force:source:convert )
    2. Revisa esa carpeta y modifica lo que quieras.
    3. Implemente esa carpeta de metadatos temporales ( force:mdapi:deploy )
    4. Eliminar la carpeta de metadatos temporales
  3. Use un postdeploy a la implementación para recrear el proceso original como una pequeña segunda implementación:
    1. Vea si se implementaron archivos de ExternalDataSource y si contienen el marcador de posición
    2. Convierta esos archivos en una carpeta de metadatos temporal
    3. Cambiar el marcador de posición/secreto
    4. Implemente esa carpeta de metadatos temporales
    5. Eliminar esa carpeta de metadatos temporales

Otro enlace que vimos elimina la propiedad UserPermissions de Profile y PermissionSet durante una recuperación. Si su complemento anteriormente usaba un gancho posterior a la recuperación, ya notó que force:source:retrieve tiene una carga útil de gancho diferente. Todavía contiene la ruta a los archivos recuperados, que su complemento podría usar para buscar cualquier Profile o conjunto de PermissionSet y reescribir esos archivos sin UserPermissions. En este caso, el desarrollador podría:

  1. Vuelva a escribir el código de gancho para manejar las cargas útiles de gancho nuevas y antiguas
  2. Una vez que todos los comandos estén usando SDR, elimine el controlador para el formato de gancho anterior a SDR

Otro complemento que encontramos usa ganchos para cambios destructivos en una implementación, una función que agregamos recientemente al comando stock source:deploy . No hay necesidad de continuar usando el complemento para cambios destructivos.

Una más: un desarrollador notó un error en el seguimiento de fuentes de Salesforce. Después de cambiar el nombre de un campo, CustomField aparecería en los cambios, pero no lo haría un informe que usara el campo (aunque su código fuente cambió para reflejar el cambio del campo). El complemento usó un preretrieve a la recuperación para examinar los archivos de código fuente locales e insertar cualquier informe que haga referencia al campo en el paquete.xml, de modo que el informe se incluya en la recuperación. En este caso, el desarrollador podría:

  1. Ver los archivos recuperados (a través de un gancho postretrieve a la recuperación)
  2. Haga que su gancho inicie otra recuperación ( force:source:retrieve -m Report:SomeReport ) para obtener el informe que falta en la fuente local

Aviso: push y pull se romperá a continuación

Reescribimos push and pull para usar el SDR, y esos cambios están actualmente en versión beta a partir de 7.25.0. Eventualmente cambiaremos la nueva versión para que sea la predeterminada, lo que hará que los ganchos cambien como se discutió anteriormente.

Advertencia: no se garantiza que VSCode use la CLI

Como parte del cambio a SDR, las extensiones de Salesforce cambiaron a una "estrategia de biblioteca" y ya no llaman a la CLI directamente a través de nuestro menú contextual y los comandos de la paleta de comandos. A partir de la última versión de Extensiones de Salesforce (53.1.0), la CLI solo se usa en segundo plano para algunas funciones básicas de configuración y autenticación del depurador. Cualquier complemento de ganchos (incluso en el nuevo estilo) no activará los mismos ganchos en VS Code en el futuro.

Soluciones transitorias

El push and pull existente se moverá bajo el subtema force:source:legacy , por lo que puede continuar usándolos tal como funcionan actualmente incluso después de que las nuevas versiones se conviertan en las predeterminadas.

Puede utilizar versiones anteriores de la CLI (le garantizamos que habrá al menos 40 versiones anteriores disponibles). Las versiones anteriores a la 7.112 no incluían el SDR para implementar/recuperar y usar las versiones anteriores de ganchos.

Del mismo modo, puede usar versiones anteriores de Salesforce Extensions: se pueden instalar alrededor de 200 versiones anteriores directamente desde VS Code. El SDR se introdujo en VS Code en la versión 48.5.0 , pero la capacidad de volver a la implementación de CLI y usar ganchos estaba disponible a través de la versión 53.1.0 . Para volver a la implementación de CLI desde una versión anterior, busque Experimental: Deploy Retrieve en la configuración de VS Code .

Nota: Realmente nos referimos a estos como soluciones transitorias. Además de perderse las ganancias de rendimiento de SDR, también se está abriendo a todos los errores y actualizaciones de seguridad que se han corregido en las versiones más recientes de la CLI y las extensiones de Salesforce para VS Code.

Conclusión

Romper los cambios siempre es difícil. Esperamos que esta publicación lo haya ayudado a comprender por qué hicimos estos cambios recientes, qué podría verse afectado y qué puede hacer para abordarlos. Para mantenerse al día con las actualizaciones de la CLI, como el próximo cambio en los comandos push y pull, siga las notas de la versión de SFDX o ejecute sfdx whatsnew . Si está creando complementos personalizados, explore los comandos source y mdapi de SDR y Salesforce que lo implementan.

Sobre el Autor

Shane McLaughlin es desarrollador en el equipo de CLI de Salesforce y ha estado construyendo en la plataforma de Salesforce desde 2011. Es @mshanemc tanto en Twitter como en GitHub.

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/02/we-broke-deploy-retrieve-hooks.html

Categories
Developers Tutoriales de Salesforce

Cómo construir una extensión de código VS impulsada por Webview con LWC ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

La creación de extensiones interactivas para Visual Studio Code (VS Code) no siempre es fácil cuando usa la funcionalidad incorporada. Para cambiar esto, puede utilizar Webviews. Le permiten ejecutar aplicaciones web locales dentro de VS Code, y esas aplicaciones web también pueden comunicarse con el IDE. Esta publicación de blog le presentará las extensiones de VS Code, cómo crear una aplicación web para VS Code con Lightning Web Components (LWC) y brindará un consejo útil para acelerar el desarrollo de LWC en general.

¿Qué es una extensión de VS Code?

VS Code se creó con la extensibilidad como uno de sus principios principales. Una extensión de VS Code es un complemento que agrega funcionalidad a VS Code, extendiéndolo o personalizándolo. Puede crear extensiones para admitir un nuevo lenguaje de programación, ejecutar tareas automatizadas, mostrar una interfaz de usuario con la que los usuarios pueden interactuar y mucho más. Las opciones son enormes. Puede encontrar algunas extensiones populares de VS Code publicadas por Salesforce en Salesforce Extension Pack .

Una forma en la que puede crear extensiones de VS Code es utilizando Webviews y la API de Webview . Puede pensar en una vista web como un iframe, en el que puede representar una interfaz de usuario construida con HTML, JavaScript y CSS. Puede comunicar la interfaz de usuario integrada con el código de extensión VS Code pasando mensajes en ambas direcciones, utilizando las API proporcionadas.

Un ejemplo de una extensión de VS Code impulsada por Webview es un proyecto divertido en el que Kotaro Nishino y yo hemos estado trabajando recientemente. Lo hemos llamado LWC Builder. LWC Builder facilita la creación de componentes web Lightning que están diseñados para ejecutarse en la plataforma Salesforce. Su principal ventaja es que le permite seleccionar las opciones de configuración de los componentes desde una interfaz de usuario. Por ejemplo, las páginas para las que desea que esté disponible o las propiedades que aparecerán en el generador de aplicaciones. Esto le evita tener que recordar o buscar las diferentes opciones, sintaxis y etiquetas necesarias en el archivo de metadatos. La extensión también le permite obtener una vista previa de los archivos de componentes y, finalmente, puede crearlos con un solo clic.

La interfaz de usuario desde la que puede configurar y obtener una vista previa de los archivos de componentes es una aplicación LWC OSS incrustada en una vista web de VS Code. Puede instalar la extensión LWC Builder VS Code que se nos ocurrió a través de su archivo VSIX .

El siguiente video muestra algunas de las capacidades que tiene LWC Builder. Creamos un componente que muestra una propiedad cuando se coloca en las páginas de inicio. También hacemos que el componente esté disponible para las páginas de registro de algunos objetos. Finalmente, obtenemos una vista previa de los archivos de componentes resultantes antes de crearlos.

[contenido incrustado]

Cómo crear una extensión de VS Code

Las extensiones de VS Code se pueden escribir en JavaScript o TypeScript. Puede usar Yeoman y el paquete de nodo generador de extensiones de VS Code . Puede instalarlo ejecutando npm install -g yo generator-code y luego ejecutarlo ejecutando yo code. Esto abrirá un asistente, similar al que obtienes con create-lwc-app ; reunirá las opciones de configuración seleccionadas para crear la estructura básica del proyecto.

Por ejemplo, si crea una extensión de TypeScript, esta es la estructura del proyecto que se crea, siendo extension.ts el punto de entrada de la aplicación.

Cómo incrustar una aplicación LWC OSS como vista web

Para LWC Builder, dividimos la aplicación en dos partes muy bien diferenciadas: la aplicación LWC OSS , que puede ejecutarse independientemente de VS Code, como una aplicación LWC OSS normal, y la extensión VS Code .

La extensión VS Code importa la aplicación LWC OSS a través de la resolución del módulo npm para incrustarla en una vista web . Esto nos permitió iterar rápidamente en el proceso de desarrollo, publicando nuevas versiones de la aplicación LWC OSS con frecuencia y simplemente actualizando la dependencia en el archivo package.json de extensión de VS Code para obtener los cambios. Puede adoptar un enfoque diferente, pero nuestra experiencia de desarrollo al hacerlo de esta manera fue muy fluida.

 { "dependencias": { "lwc-builder-ui": "^ 0.1.20" } // ...
}

Para crear una vista web, debe crear una instancia de un WebviewPanel que incluya los archivos de la aplicación de la interfaz de usuario. En nuestro caso, los archivos de la aplicación LWC OSS compilados. Básicamente, lo que hacemos es leer los archivos compilados de la aplicación LWC OSS de la node_modules (descargados previamente a través de npm install ) y aplicar algunas transformaciones necesarias.

 this.webviewPanel = vscode.window.createWebviewPanel ( 'lwcBuilder', 'LWC Builder', vscode.ViewColumn.One, { // Habilite los scripts en la vista web enableScripts: verdadero, } ); // Establecer el contenido del panel de vista web const pathToLwcDist = path.join (context.extensionPath, LWC_BUILDER_UI_PATH); const pathToHtml = path.join (pathToLwcDist, HTML_FILE); let html = fs.readFileSync (pathToHtml) .toString (); this.webviewPanel.webview.html = HtmlUtils.transformHtml (html, pathToLwcDist, webview);
);

Las transformaciones que tienes que aplicar son:

  • Para transformar las etiquetas HTML <script> y <link>, ya que VS Code usa un protocolo que necesita rutas de archivo relativas para comenzar con vscode-webview-resource , por ejemplo, en lugar de tener <script src=“index.js”> , Necesitará usar <script src=“vscode-webview-resource:0.app.js:index.js”> . Lo mismo se aplica a los enlaces.
  • Para agregar una metaetiqueta de Política de seguridad de contenido , de modo que se puedan cargar scripts y hojas de estilo locales.

Cómo ejecutar acciones de VS Code desde su WebView

La aplicación incorporada y la extensión VSCode pueden comunicar mensajes de paso. Es decir, el receptor puede definir un oyente (suscribirse a un mensaje), que se ejecutará cuando el editor publique un mensaje. Esto funciona en ambas direcciones.

Como ejemplo, echemos un vistazo a cómo pasamos un mensaje de la aplicación LWC OSS a la extensión VS Code en LWC Builder. Cuando el usuario ha terminado de configurar el nuevo componente y hace clic en «Crear», la aplicación LWC OSS envía un mensaje a Webview, que contiene la configuración seleccionada por el usuario.

 onButtonClick () { // Enviar mensaje al servidor const message = new LWCBuilderEvent ('create_button_clicked', this.contents); this.vscode? .postMessage (mensaje);
}

Cuando se escucha este mensaje , la extensión de VS Code crea los archivos LWC correspondientes utilizando la API de VS Code . El controlador de mensajes, o escucha, debe estar adjunto al panel de Webview .

 export class WebviewInstance { // ... this.webviewPanel.webview.onDidReceiveMessage (this.onDidReceiveMessageHandler, this, this.subscriptions); protegido onDidReceiveMessageHandler (evento: LWCBuilderEvent): void { // Manejo de mensajes desde el interruptor de IU (event.type) { caso 'create_button_clicked': createLwcFolder (event.payload, this.lwcFolderUri); caso 'error': vscode.window.showErrorMessage (event.error); regreso; defecto: vscode.window.showInformationMessage (`Evento desconocido: $ {event.type}`); } } // ... }

Este es un diagrama que representa el flujo de información:

Cómo definir los puntos de contribución para lanzar la vista web

Para poder lanzar una extensión de VS Code, debe definir al menos un punto de contribución . Los puntos de contribución son los puntos de entrada a través de los cuales queremos permitir que los usuarios ejecuten el código de extensión. Un punto de contribución típico es cuando el usuario selecciona un comando en la paleta de comandos, pero puede ser casi cualquier cosa: seleccionar un texto en el código, hacer clic en un menú, etc. Los puntos de contribución se definen en el archivo package.json. Para LWC Builder definimos dos puntos de contribución: un comando que está disponible en la paleta de comandos, cuando estás dentro de un proyecto SFDX, y también una opción cuando haces clic derecho en el menú de la carpeta lwc

 { "contribuye": { "comandos": [ { "comando": "lwc-builder.openLWCBuilder", "title": "Abrir LWC Builder" } ], "menús": { "explorador / contexto": [ { "comando": "lwc-builder.openLWCBuilder", "title": "Abrir LWC Builder", "when": "explorerResourceIsFolder && resourceFilename == lwc && sfdx: project_opened" } ], "commandPalette": [ { "comando": "lwc-builder.openLWCBuilder", "when": "sfdx: project_opened" } ] } }, // ...
}

Comandos de lanzamiento de puntos de contribución. Usted define los comandos en el archivo de entrada de la extensión ( extension.ts en nuestro caso). Para LWC Builder, creamos un openLWCBuilder que crea una instancia de la vista web. Vinculamos los dos puntos de contribución al mismo comando.

 const openLWCBuilderCommand = vscode.commands.registerCommand ( 'lwc-builder.openLWCBuilder', (uri: vscode.Uri) => { nueva WebviewInstance (contexto, uri); } ); context.subscriptions.push (openLWCBuilderCommand);

Cómo empaquetar y publicar el archivo VSIX

Finalmente, empaquetar y publicar una extensión de VS Code es sencillo. Solo tiene que usar vsce («Extensiones de código de Visual Studio») , una herramienta de línea de comandos creada para este propósito. Puede instalarlo ejecutando npm install -g vsce . Luego, puede generar el .vsix instalable ejecutando el vsce package y, opcionalmente, publicarlo en el mercado de VS Code que ejecuta vsce publish.

Conclusiones

Las extensiones de VS Code son geniales, te ayudan a personalizar y extender VS Code de infinidad de formas. ¡Las extensiones pueden hacer que su experiencia de desarrollo sea más rápida, fácil e incluso más divertida! Crear extensiones de VS Code no es difícil, y debo decir que trabajar con la documentación de VS Code fue increíble. Es fácil de seguir, completo y lleno de ejemplos.

Las extensiones de VS Code se pueden ampliar enormemente con Webview, incorporando aplicaciones web personalizadas fácilmente. Inicialmente, LWC Builder era una aplicación web independiente construida con LWC OSS. Gracias a las vistas web, pudimos reutilizar lo que ya habíamos creado. De hecho, la aplicación LWC OSS aún puede ejecutarse de forma independiente si es necesario.

La creación de una extensión de código VS y una aplicación LWC OSS fue una gran experiencia para nosotros. Aprendimos mucho y ahora esperamos que la extensión pueda ayudar a otros desarrolladores a ser más productivos. Estamos abiertos a contribuciones. ¡No dude en ayudarnos a mejorar la aplicación LWC OSS o la extensión VS Code con sus increíbles ideas!

Sobre los autores

Alba Rivas trabaja como líder en desarrollo evangelista en Salesforce. Se centra en los componentes web Lightning y la estrategia de adopción de Lightning. Puedes seguirla en Twitter @AlbaSFDC.

Kotaro Nishino trabaja como ingeniero de demostración en Salesforce. Crea demostraciones para clientes en Japón y Corea del Sur, y crea activos y herramientas que mejoran la productividad de los pioneros. Record Clone es uno de sus trabajos recientes.

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2021/04/how-to-build-a-webview-powered-vs-code-extension-with-lightning-web-components.html

Categories
Developers Salesforce Tutoriales de Salesforce

10 extensiones de VS Code que potenciarán su desarrollo de Salesforce

Algunos de ustedes se habrán preguntado qué le ha pasado a Mike e incluso a Chris, ¿por qué una pausa tan larga? No hay una razón única o una explicación fácil que no sea la vida. Digamos que convergieron varios desafíos de la vida.

Como parte de enfrentar los desafíos de la vida, he estado buscando formas de ser más productivo con mi rutina de trabajo diaria. Una herramienta que uso a diario, y me refiero a diario, es VSCode. VSCode es el entorno de desarrollo integrado (IDE) de código abierto gratuito de Microsoft. Lo que hace que la herramienta sea tan adictiva y útil es la comunidad en torno a las extensiones. Las extensiones son formas ingeniosas para que el desarrollador agregue y personalice la experiencia VSCode con cosas como temas, íconos para nuevos servicios que abren posibilidades ilimitadas de personalización para el desarrollador y Salesforce.

Salesforce anunció hace unos años que ya no sería compatible con Eclipse y el IDE de force.com , y comenzó la migración a VSCode. De manera constante, este cambio ha evolucionado y madurado. ¡De ahí el título de esta publicación de blog!

Aquí vamos, comenzando con la extensión más obvia del paquete.

1.) Extensiones de Salesforce para Visual Studio Code

¿Qué hace? – Hace que interactuar con nuestra querida plataforma Salesforce sea muy fácil. Le permite trabajar con todos los tipos de metadatos programáticos como Apex Class, Apex Triggers, Aura y Lightning Web Components. Bucear en la Consola de desarrollador para ejecutar pruebas fue un dolor de cabeza, ya sabes qué. Salesforce Extensions le permite ejecutar rápidamente todas las pruebas y depurar desde VSCode. ¿Cuan genial es eso?

Por último, siempre es y sigue siendo difícil obtener todos los metadatos, que es donde el «Navegador de la organización» resulta útil para interactuar con los diferentes tipos de metadatos.

2.) Documentador de Salesforce

Oye, nada habla más de productividad que los elegantes comentarios de código que te recuerdan a tus compañeros y a ti para qué diablos se diseñó esta clase … Esta extensión agrega una capa de coherencia que solo una computadora puede proporcionar: esto inyectará comentarios perfectos para ti en la clase y los métodos , dejándote solo para completar ¡QUÉ!

3.) Ápice PMD

¿Qué es peor que no tener comentarios en el código? Intentando depurar código que es demasiado complejo y que caen en antipatrones.

Apex PMD es como su propio Code Guru personal, que analiza su código a medida que escribe. Es importante tener en cuenta que, aunque no puede escribir el código por usted ni un sustituto del aprendizaje, puede indicar cuándo comienza a desviarse del camino feliz hacia el infierno de espaguetis.

Los desarrolladores de 32K Salesforce piensan que esta extensión puede ayudar, nadie puede discutir eso.

4.) Visualizador de cobertura de código Apex

A veces, cuando pasa mucho tiempo codificando, nada sobresale más que algunas imágenes brillantes que confirman algo tan seco como la Cobertura del Código Apex.

5.) Kit de herramientas de Salesforce

Esta es la última extensión centrada en Salesforce antes de pasar a las extensiones que no son de Salesforce. Completando nuestras extensiones de aumento de la productividad de Salesforce, esta es una adición reciente a mi configuración de VSCode. Cuando comienzo un nuevo proyecto, después de configurar mi contraseña e iniciar sesión, lo siguiente que hago es autenticar esa organización con la cli de Salesforce. Hago esto para poder aprovechar el comando sfdx cli open org que abre esa Org en la ventana de Chrome actualmente enfocada. No hay nada más frustrante que tratar de recordar su nombre de usuario y contraseña.

La extensión realmente brilla con su panel de información de la organización cuando abre una organización autenticada y obtiene una gran cantidad de información sobre la organización conectada.

Prometimos 10, por lo que las siguientes 5 extensiones son Extensiones VSCode generales.

6.) Markdown todo en uno

Aparte del lenguaje de programa que elija, el lenguaje (sintaxis) más popular en el mundo de los desarrolladores es el markdown. Todo el código puede beneficiarse de un README bien escrito: ¡esta extensión suaviza el proceso de creación y mantenimiento de rebajas!

7.) Servidor en vivo

Poner en marcha un servidor web local puede ser difícil, esto le brinda un servidor web local instantáneo con un solo clic. Si tiene una página HTML o similar enfocada dentro de VSCode, presione Go Live y se abrirá una sesión de navegador para usted.

Salesforce TIP: Live Server puede ayudarlo a probar y crear fácilmente soluciones externas de widget de chat integrado

8.) Editar CSV

Como dice en la lata «Editar CSV», en estos días es fácil interactuar con los datos de Salesforce utilizando un conjunto de comandos cli, realizar consultas y descargar los resultados en CSV. Para todas esas ediciones rápidas de datos, ¡ahora es fácil de editar directamente dentro de VSCode!

9.) Embellecer Bash

Uno de los beneficios importantes de VSCode es que tiene Terminal integrado directamente en el IDE, es fácil abrir Terminal y ejecutar comandos. Una vez que pasa el nivel de principiante con el cli, comienza a pensar en estas líneas … Sigo ejecutando estos mismos comandos, ¿cómo puedo ejecutarlos todos a la vez? Hola, scripting de BASH, sí, más código, pero abre la puerta a una automatización seria y enorme. ganancias de productividad para el desarrollador. Ahora, ¿qué pasaría si VSCode solo tomara su script bashing y lo hiciera lucir hermoso? Por supuesto, aún puede no funcionar, ¡pero seguro que se vería bonito!

10.) pavo real

Completando el puesto; y seguir con nuestro tema coherente aquí, ¡que se trata de ser productivo mientras se ve bien!

Y Peacock no es una excepción a eso, trayendo un cálido arco iris de colores a sus diferentes espacios de trabajo de VSCode. Peacock agrega casi la cantidad correcta de color al amado tema oscuro común y hace que estos tiempos oscuros para todos nosotros parezcan mucho menos oscuros.

Esperamos que esta publicación te ilumine el día y aumente la productividad de VSCode. ¡Que tengas una gran semana!

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://salesforceweek.ly/2020/07/10-vscode-extensions-that-will-supercharge-your-salesforce-development.html

Categories
Developers Enterprise Software Tutoriales de Salesforce

Aprovechando las nuevas características de ESXX en LWC

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores, consultores, administradores y arquitectos de Salesforce para toda Iberoamérica.

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Cada año el Comité Técnico Internacional 39 (TC39), del que Salesforce es miembro, publica una nueva edición de ECMA-262, los estándares de especificación del lenguaje ECMAScript, en los que se basa JavaScript. La próxima edición es la ES2021 (ES12), que actualmente se encuentra en borrador y cuya publicación está prevista para junio. Los navegadores, compiladores (como Babel y Typescript) y tiempos de ejecución (como Node.js) trabajan duro para mantenerse al día con los estándares de ECMAScript mediante la implementación de soporte para las nuevas características añadidas. Continúe leyendo para conocer algunas de las características más nuevas y geniales de ECMAScript y cómo puede utilizarlas en Lightning Web Components.

Proceso de compilación de LWC

Para entender las implicaciones del uso de ciertas características de ES6+ JavaScript en LWC, es importante desplegar cómo funciona el proceso de compilación de LWC. Cuando se empujan o despliegan archivos LWC a la plataforma, se realizan varias tareas.

Primero, ejecutamos un linter que escanea tu código utilizando la configuración base de nuestro complemento LWC Eslint. Esto evita errores comunes con LWC, y hace cumplir otras restricciones de la plataforma Salesforce. Tenga en cuenta que esto es diferente a cuando el linter se ejecuta localmente en VSCode. En VSCode puedes elegir qué configuración de linting utilizar: más o menos restrictiva.

A continuación, compilamos el código que has escrito. El compilador de LWC utiliza Babel y Rollup para realizar esta tarea. Este proceso conlleva tres pasos: analizar, transformar y agrupar.

En primer lugar, el analizador sintáctico (Babel) lee tu código para entender qué estructuras sintácticas estás utilizando. Por ejemplo, identifica si estás usando una función, una clase (ES6), la sintaxis de extensión de objetos (ES9), o el operador de encadenamiento opcional (ES11). Actualizamos el analizador a menudo para que pueda analizar las nuevas estructuras sintácticas incluidas en las nuevas versiones de ES

Entonces, el código se transforma para generar dos salidas diferentes:

  • Salida ES6 – Este código se ejecuta en los navegadores modernos, que soportan la sintaxis ES6 de forma nativa y mejoran el rendimiento considerablemente. Para esta versión del código, transformamos un subconjunto de características de la sintaxis ES6+ – incluyendo ES7, ES8, Rest/Spread Properties, y Class Fields – a ES6.
  • Salida de ES5 – Este código se ejecuta en navegadores antiguos (los llamamos navegadores de compatibilidad), como Internet Explorer 11. Estos navegadores no soportan las características de sintaxis incluidas en versiones superiores a ES5, por lo que transformamos un subconjunto de características de sintaxis de ES5+ (las mismas que las enumeradas anteriormente, más las características de sintaxis de ES6) a ES5.
  • Salida de ES5

Ambas salidas también incluyen los archivos de plantilla y CSS compilados, que se agrupan utilizando Rollup. El archivo de plantilla se compila porque el DOM del componente se genera dinámicamente en JavaScript. El archivo CSS se transforma para dar alcance a los estilos del componente cuando se utiliza el Shadow DOM sintético.

¿Qué ocurre si se utiliza una característica sintáctica que no transformamos (por ejemplo, el operador de encadenamiento opcional de ES11)? Si el analizador sintáctico lo entiende (normalmente lo hace, ya que lo actualizamos a menudo), la característica se incluye en ambas versiones de código, y sólo funciona si tu navegador es capaz de entender la sintaxis (a menudo es el caso de los navegadores modernos).

Nota que este panorama es correcto en la fecha de publicación del blog. Sin embargo, puede cambiar pronto, ya que el equipo de LWC está trabajando en la adición de nuevas transformaciones para mantenerse al día con las sintaxis recién introducidas.

Ejecución en tiempo de ejecución y polyfills

Ahora hablemos de la ejecución en tiempo de ejecución. Cuando tu aplicación se ejecuta en un navegador, utilizamos el agente de usuario para detectar qué navegador. Dependiendo del navegador, se carga la versión ES5 o ES6 del código, junto con los polyfills necesarios en el caso de los navegadores de compatibilidad. Un polyfill es una característica que falta (normalmente un objeto o método de la API del navegador) que se añade al lenguaje en tiempo de ejecución. Tenga en cuenta que son diferentes de las características de sintaxis. Algunos ejemplos de características que pueden ser polyfilled son Promise (ES6), Object.entries() (ES8), y Promise.any() (ES12). LWC utiliza core-js polyfills.

  • Para los navegadores de compatibilidad, todas las funciones de ES6 están polifiladas.
  • Para los navegadores de compatibilidad, todas las funciones de ES6 están polifiladas
  • Para los navegadores modernos, no se cargan los polyfills de ES6, ya que no son necesarios.
  • Para los navegadores de compatibilidad, se cargan todos los polyfills de ES6

¿Qué ocurre si utilizas una API para la que no proporcionamos un polyfill (por ejemplo, Promise.any() de ES12)? Funciona si el navegador en el que ejecutas la app lo soporta, siempre y cuando Locker lo soporte también.

Nota: para LWC OSS sólo se genera por defecto la versión ES6. También linting y polyfilling no son parte de LWC OSS fuera de la caja.

Características de ESXX soportadas en LWC

Los nuevos estándares de ECMAScript incluyen características que te harán mucho más productivo, y tu código más eficiente y fácil de leer. Puedes utilizar la mayoría de ellas en LWC, dado que están soportadas por los navegadores en los que se ejecuta tu aplicación. Esto no es diferente de lo que ocurre con las aplicaciones JavaScript normales!

Estas son algunas de las características más recientes que puedes utilizar a día de hoy:

He creado una aplicación que facilita la comprensión de las características de ESXX que se pueden utilizar en LWC, dado que son soportadas por su navegador, y cómo. La aplicación contiene componentes con ejemplos de código que muestran las características incluidas en las versiones desde ES9 hasta ES12, aunque recuerda que las características de las versiones anteriores también están soportadas. Puedes mirar el código de cada ejemplo, y opcionalmente depurar cada ejemplo individualmente con las herramientas de desarrollo del navegador, para una comprensión más profunda.

También he creado una versión LWC OSS de la aplicación, porque cuando se crean aplicaciones con LWC OSS, no se ejecuta Locker y se relajan algunas restricciones para poder utilizar más funciones de ESXX que soporta la plataforma Salesforce. Te recomiendo que clones esta versión si sueles desarrollar LWC fuera de la plataforma.

¡Un gran poder conlleva una gran responsabilidad!

En esta entrada del blog, te expliqué cómo funciona el proceso de compilación de LWC, cómo proporcionamos una versión compatible con versiones anteriores de tu código y cómo rellenamos las características que faltan (ES6, y algunas de ES7 y ES8) para los navegadores más antiguos. También ha aprendido que puede utilizar la mayoría de las demás características de ESXX, siempre que utilice un navegador que las soporte.

Para ayudarte a saber qué características de ESXX entran en cada categoría, he compartido dos aplicaciones que te muestran las características soportadas y cómo usarlas. Clone la aplicación LWC o la aplicación LWC OSS y compruébelo. Y si quieres aprender más, que sepas que voy a hacer una serie de webinars en Trailhead Live sobre este tema empezandoel jueves 25 de febrero – asegúrate de añadirlo a tu calendario. Gracias por leer y ¡feliz codificación!

Recursos relacionados

Trail: Aprende a trabajar con JavaScript

Sobre el autor

Alba Rivas trabaja como Lead Developer Evangelist en Salesforce. Se centra en la estrategia de adopción de Lightning Web Components y Lightning. Puede seguirla en Twitter @AlbaSFDC.

Cada año el Comité Técnico Internacional 39 de Ecma (TC39), del que Salesforce es miembro, publica una nueva edición de ECMA-262, los estándares de especificación del lenguaje ECMAScript, en los que se basa JavaScript. La próxima edición es ES2021 (ES12), que se encuentra actualmente en fase de borrador y cuya publicación está prevista para junio. Navegadores, compiladores (como Babel y […]

El post Aprovechando las nuevas características de ESXX en LWC apareció primero en Blog de Desarrolladores de Salesforce.

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2021/02/leveraging-the-newest-esxx-features-in-lwc.html

Categories
Developers Tutoriales de Salesforce

Mejore sus habilidades como desarrollador con la serie de vídeos de desarrollo de aplicaciones modernas

Las aplicaciones modernas requieren una combinación de código bajo y código profesional. Los desarrolladores de Salesforce tienen la difícil tarea de ofrecer soluciones escalables más rápido que nunca, ya que las organizaciones buscan acelerar su transformación digital.

En diciembre de 2020, publicamos un blog post que explica varios patrones que combinan low-code y pro-code. Estos patrones muestran que al combinar el elastic runtime de Heroku y la arquitectura multi-tenant de Salesforce core, se pueden ofrecer soluciones que no sólo pueden escalar, sino que son flexibles y requieren menos tiempo para construir e implementar.

Investigamos las habilidades requeridas por los desarrolladores para implementar los patrones resaltados en esa publicación del blog de diciembre, y concluimos que los desarrolladores de Salesforce disfrutarían aprendiendo más sobre la plataforma Heroku. Con Heroku, los desarrolladores de Salesforce pueden descargar operaciones complejas y aprovechar las bibliotecas de código abierto. Del mismo modo, los desarrolladores de Heroku pueden beneficiarse de conocer las capacidades de bajo código de la plataforma Salesforce. La combinación de la potencia del código bajo y de Heroku permite que las aplicaciones se entreguen más rápido.

La serie de vídeos «Desarrollo de aplicaciones modernas en Salesforce» es un conjunto de trece vídeos en el canal de YouTube de Salesforce Developers. Estos vídeos te enseñan a diseñar, construir, probar y desplegar aplicaciones utilizando Salesforce y Heroku.

¿Quién debería ver estos vídeos?

  • Los desarrolladores de Salesforce con experiencia que quieran mejorar sus habilidades más allá de Apex y Visualforce. Aquellos que quieran entender las herramientas modernas para desarrolladores que incluyen Salesforce CLI, Salesforce Extension Pack para VSCode, scratch orgs, las últimas mejoras de Salesforce Flows, la construcción de componentes personalizados utilizando LWC, la arquitectura basada en eventos utilizando Platform Events y Change Data Capture, además de mucho más.
  • Los desarrolladores con experiencia en Salesforce que quieran mejorar sus habilidades más allá de Apex y Visualforce
  • Desarrolladores de Heroku que deseen comprender cómo combinar el código bajo y el código profesional para construir aplicaciones potentes.
  • Los desarrolladores nuevos que deseen comprender cómo combinar el código bajo y el código profesional para construir aplicaciones potentes
  • Desarrolladores nuevos que desean una visión general de las tecnologías que los desarrolladores de Salesforce utilizan en su trabajo diario.
  • Desarrolladores procedentes de otras tecnologías que quieran explorar la posibilidad de convertirse en desarrolladores de Salesforce» como carrera profesional.

¿Qué temas cubrimos?

Cubrimos todo el espectro del ciclo de vida de las aplicaciones en esta serie de vídeos: diseño, construcción, pruebas e implementación. Hemos aprovechado eCars, una de nuestras aplicaciones de la Galería de Ejemplos, para explicar varios conceptos con un enfoque práctico, con código.

Herramientas para desarrolladores

Estas sesiones introducen Salesforce y Heroku. También mostramos cómo utilizar la CLI de Salesforce y la CLI de Heroku. Ambos utilizan el framework común de código abierto oclif.

La siguiente diapositiva ofrece una visión general de las herramientas CLI de Salesforce y sus funciones.


También explicamos cómo darse de alta en los playgrounds gratuitos para desarrolladores de Salesforce y en la plataforma Heroku en estas sesiones. Tener acceso a entornos para desarrolladores al alcance de tu mano significa que puedes experimentar y aprender a tu propio ritmo.

Episodio 1: Herramientas para desarrolladores
Episodio 2: Experiencia del desarrollador de Heroku

Diseño del modelo de datos

Explicamos la importancia del diseño del modelo de datos para una aplicación de Salesforce y cómo los demás metadatos tienen una dependencia de los metadatos de los objetos.

La siguiente imagen ofrece una visión general de las dependencias de los metadatos de Salesforce con respecto a los metadatos de los objetos.

También nos adentramos en los complementos de Heroku y en los Servicios de Datos. Tuvimos algunas conversaciones emocionantes al comparar y contrastar el diseño del modelo de datos en Salesforce Core frente a Heroku.

Episodio 3: Diseño de modelos de datos en Salesforce y Heroku Data Services

Diseño de aplicaciones frontales

El diseño de aplicaciones de front-end es una especie de arte en Salesforce. Requiere el conocimiento de las capacidades de varias herramientas de código bajo. Los desarrolladores deben saber hasta qué punto pueden personalizar la experiencia y qué se necesita para construir y diseñar Lightning Web Components.

Esta imagen proporciona algunos principios orientativos sobre cómo abordar el diseño de aplicaciones y la creación de prototipos para construir aplicaciones frontales en Salesforce

Episodio 4: Construir experiencias personalizadas con LWC y SLDS
Episodio 5: Crear experiencias personalizadas con LWC y SLDS (parte 2)
Episodio 6: Comunicación entre componentes de LWC mediante eventos

Automatiza tu proceso de negocio

En esta sesión, nos adentramos en los flujos de Salesforce y en Apex.

La captura de pantalla que aparece a continuación muestra un ejemplo de un «flujo de automatización desencadenado por un registro anterior a la actualización». Salesforce Flow es una herramienta de bajo código que permite a los desarrolladores crear automatizaciones mediante clics.


También cubrimos cuándo usar Flows vs. Apex y cómo los desarrolladores de código profesional con conocimientos de Apex y JavaScript pueden aprovechar Flows y construir acciones y pantallas que los administradores pueden incrustar en Flows.

Episodio 7: Automatice sus procesos de negocio utilizando Flows y Apex

Escala las aplicaciones de Salesforce con microservicios Node.js en Heroku

Estas sesiones desmitifican la arquitectura de la aplicación y el código detrás de la aplicación de ejemplo de eCars. Enseñamos a los desarrolladores cómo construir microservicios Node.js en Heroku, conectar estos servicios a Salesforce y construir Progressive Web Apps en Heroku.

Esta imagen muestra una arquitectura de ejemplo sobre cómo construir un servicio en tiempo real en Heroku usando Node.js. El servicio utiliza el protocolo MQTT para enviar señales en tiempo real a las apps de Salesforce utilizando websockets.

Episodio 8: Escala de aplicaciones con Node.js en Heroku
Episodio 9: Escalar aplicaciones usando microservicios Node.js en Heroku (parte 2)

Test de unidades

Probar por unidades el código de tu aplicación es un hábito difícil de adoptar, pero es importante que los desarrolladores prueben su código antes de enviar su app a producción.

La siguiente imagen explica el patrón AAA para las pruebas unitarias.


También tenemos una sesión de pruebas unitarias de JavaScript y Apex para ayudar a los desarrolladores a adoptar las pruebas unitarias.

Episodio 10: Pruebas unitarias de JavaScript
Episodio 11: Apex Testing

Empaquetado y despliegues

En los últimos episodios, exploramos cómo empaquetar y desplegar aplicaciones de Salesforce y Heroku.

Con la CLI de Salesforce, git y las herramientas de CI/CD (como las acciones de Github o el servidor de integración continua), los desarrolladores pueden colaborar mejor y automatizar los lanzamientos de sus aplicaciones de Salesforce.

Este visual muestra cómo el desarrollo basado en el código fuente puede ayudar a automatizar las implementaciones.

También cubrimos cómo hacer CI/CD y DevOps para aplicaciones de Salesforce y Heroku.

Episodio 12: Implementación de aplicaciones Salesforce y Heroku con facilidad
Episodio 13: Automatizar el flujo de trabajo y la implementación de los desarrolladores