Categories
Developers

Pasar datos del componente web Lightning al flujo de pantalla

Última actualización el 17 de julio de 2023 por Rakesh Gupta

Gran idea o pregunta duradera:

  • ¿Cómo pasa datos del componente web lightning al flujo de pantalla principal?

Objetivos:

Después de leer este blog, podrá:

  • Incruste un componente web relámpago dentro del flujo de pantalla
  • Pase los datos del componente web lightning a una variable de flujo
  • Interactuar con el componente web lightning y los elementos de flujo de pantalla en la misma pantalla
  • y mucho más

En el pasado, escribí algunos artículos sobre Lightning Web Component . ¿Por qué no echarles un vistazo mientras estás en ello?

  1. Uso del componente web Lightning para mostrar un banner de alerta
  2. Obtenga el Id. de registro y el nombre de la API del objeto en el componente web Lightning

Janel Parrish trabaja como desarrollador junior en Gurukul on Cloud (GoC). Janel tiene un requisito comercial para hacer lo siguiente:

  1. Desarrollar un componente LWC capaz de recibir entradas de latitud y longitud.
  2. Pase los valores introducidos a los componentes de flujo de pantalla correspondientes.

Construir pantallas con componentes reactivos

Con la función Crear pantallas con componentes interactivos (actualmente en versión beta), ahora puede habilitar la interacción directa entre un componente web Lightning y otros elementos de flujo en la misma pantalla.

Anteriormente, no existía una disposición directa para la interacción dinámica entre un componente web Lightning y los elementos de flujo. Como resultado, los usuarios tenían que navegar a la siguiente pantalla para ver los datos pasados por el componente web Lightning en Screen Flow.

Enfoque de Campeón de Automatización (I-do):

Al crear el componente web Lightning, también utilizaremos el evento FlowAttributeChangeEvent . Esto permitirá que un componente controle la navegación del flujo y notifique al flujo los cambios en los valores de los atributos.

Los eventos FlowAttributeChangeEvent solo se admiten en componentes donde el destino es lightning__FlowScreen .

Práctica guiada (nosotros hacemos):

Hay 2 pasos para resolver el requisito empresarial de Janel utilizando Lightning Web Component y Screen Flow . Debemos:

  1. Cree un componente web Lightning de ubicación de entrada para Screen Flow
  2. Pasos de flujo de Salesforce
    1. Definir propiedades de flujo para el flujo de pantalla
    2. Agregue una pantalla para mostrar el componente personalizado de ubicación de entrada
    3. Agregar un componente de número de entrada para mostrar la latitud desde la ubicación de entrada Componente LWC
    4. Agregar un componente de número de entrada para mostrar la longitud desde la ubicación de entrada Componente LWC

Paso 1: Cree un componente web Lightning de ubicación de entrada para Screen Flow

En primer lugar, cree un componente web Lightning de ubicación de entrada con el siguiente código. El componente lightning-input-location representa un campo de geolocalización compuesto que acepta valores de latitud y longitud introducidos por el usuario, siendo ambos coordenadas geográficas expresadas en grados decimales. Le permite identificar ubicaciones utilizando estas coordenadas.

El rango aceptable para la latitud está entre -90 y 90, mientras que la longitud acepta valores de -180 a 180. Cualquier entrada más allá de estos rangos especificados genera un mensaje de error. Este ejemplo muestra un campo de geolocalización compuesto, que muestra una latitud de 27,70750 y una longitud de -122,3948370.

Si no sabe cómo crear un componente Lightning, consulte esta guía para desarrolladores, Crear un componente web Lightning .

lwcToScreenFlow.html

Utilizaremos el componente de ubicación de entrada de rayos para aceptar valores de latitud y longitud. Desglosemos el código:

  • En LWC, el archivo HTML de cada componente debe envolverse con una etiqueta <plantilla> .
  • latitude={latitude} :- Esto vincula la propiedad de latitud de la clase JavaScript de LWC con el atributo de latitud del componente.
  • longitude={longitude} :- Similar a la latitud, esto une la propiedad de longitud de la clase JavaScript de LWC con el atributo de longitud del componente.
  • onchange={handleChange} :- Esto configura un detector de eventos en el componente. Cada vez que cambia el valor del componente (ya sea latitud o longitud), se llama al método handleChange de la clase JavaScript de LWC.

<plantilla> <relámpago-entrada-ubicación etiqueta="Coordenadas predeterminadas" latitud={latitud} longitud={longitud} onchange={handleChange}> </ubicación-de-entrada-del-relámpago>
</plantilla>
lwcToScreenFlow.js

Este código JavaScript de muestra utiliza el decorador @api para crear propiedades públicas, es decir, accesibles desde otros componentes o utilizadas en plantillas HTML. Por ejemplo, @api latitude y @api longitude declaran dos propiedades públicas.

  • FlowAttributeChangeEvent crea y distribuye el evento personalizado que transfiere datos del componente web Lightning a un flujo.
  • handleChange(event) es un método de controlador de eventos que se llama cuando ocurre un evento de cambio en el componente lightning-input-location en la plantilla HTML de LWC.
  • this.latitude = event.target.latitude y this.longitude = event.target.longitude , estas líneas actualizan las propiedades de latitud y longitud con los valores del objetivo del evento (el componente lightning-input-location).
  • [“latitud”, “longitud”].forEach((loc) => this.dispatchEvent(new FlowAttributeChangeEvent(loc, this[loc]))) , esta línea recorre una matriz que contiene cadenas de latitud y longitud, y para cada uno de estos, envía un nuevo FlowAttributeChangeEvent.

importar { LightningElement, api } desde 'lwc';
importar {FlowAttributeChangeEvent} desde 'lightning/flowSupport'; exportar la clase predeterminada LwcToScreenFlow extiende LightningElement { @api latitud; @api longitud; handleChange(evento){ esta.latitud = evento.objetivo.latitud; this.longitude = event.target.longitude; ["latitud", "longitud"].forEach((loc) => this.dispatchEvent(new FlowAttributeChangeEvent(ubicación, esta[ubicación])) ); }
}
lwcToScreenFlow.js-meta.xml

El elemento isExposed se establece en verdadero, lo que hace que el componente esté disponible para su uso en herramientas como Lightning App Builder o Flow Builder. El elemento de objetivos se usa para especificar dónde se puede usar su componente. En este caso, la etiqueta lightning__FlowScreen significa que este componente está diseñado para usarse en las pantallas de Salesforce Flow.

Los elementos targetConfigs y targetConfig le permiten definir propiedades que se pueden establecer en el contexto del constructor. En este caso, las propiedades son latitud y longitud . Ambos están configurados para ser del tipo Integer y tienen la función de outputOnly , lo que significa que se pueden configurar en el flujo, pero el usuario no puede modificarlos dentro del componente. Estas propiedades se pueden usar para pasar datos del LWC al flujo.


<?versión xml="1.0" codificación="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadatos"> <apiVersion>58.0</apiVersion> <isExposed>verdadero</isExposed> <objetivos> <target>relámpago__FlowScreen</target> </objetivos> <configuraciones de destino> <targetConfig objetivos="relámpago__FlowScreen"> <property label="Latitude" name="latitude" type="Integer" role="outputOnly"/> <property label="Longitud" name="longitud" type="Integer" role="outputOnly"/> </targetConfig> </configuraciones de destino>
</LightningComponentBundle>

Paso 2.1: Definir propiedades de flujo

  1. Haga clic en Configuración .
  2. En el cuadro Búsqueda rápida, escriba Flujos .
  3. Seleccione Flujos , luego haga clic en Nuevo flujo .
  4. Seleccione el flujo de pantalla   y haga clic en Crear y configurar el flujo.
  5. Se abrirá el diseñador de flujo para usted.

Paso 2.2: agregue una pantalla para mostrar el componente personalizado de ubicación de entrada

  1. En Flow Designer, haga clic en el icono + y seleccione el elemento Pantalla .
  2. Ingrese la siguiente información :
    1. Ingrese la etiqueta, el nombre de la API se completará automáticamente.
  3. Haga clic en Listo.

Paso 2.3: Agregue un componente de número de entrada para mostrar la latitud desde el componente LWC de ubicación de entrada

  1. En la sección Entrada en Elemento de pantalla , arrastre y suelte el componente Número en la pantalla.
  2. Ingrese la siguiente información :
    1. Ingrese la etiqueta, el nombre de la API se completará automáticamente.
    2. Valor predeterminado : {!lwcToFlow.latitude}
  3. Haga clic en Listo.

Paso 2.4: Agregar un componente de número de entrada para mostrar la longitud desde la ubicación de entrada Componente LWC

  1. En la sección Entrada en Elemento de pantalla , arrastre y suelte el componente Número en la pantalla.
  2. Ingrese la siguiente información :
    1. Ingrese la etiqueta, el nombre de la API se completará automáticamente.
    2. Valor predeterminado : {!lwcToFlow.longitude}
  3. Haga clic en Listo.

Al final, Janel's Flow se verá como la siguiente captura de pantalla:

Una vez que todo se vea bien, realice los siguientes pasos:

  1. Haga clic en Guardar .
  2. Ingrese la etiqueta de flujo, el nombre de la API se completará automáticamente.
  3. Haga clic en Mostrar avanzado .
  4. Versión de API para ejecutar el flujo : 58
  5. Etiqueta de entrevista : Pase de Screen Flow a LWC {!$Flow.CurrentDateTime}
  6. Haga clic en Guardar .

Prueba de concepto

Evaluación formativa:

¡Quiero saber de ti!

¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://automationchampion.com/2023/07/17/pass-data-from-lightning-web-component-to-screen-flow-3/

Categories
Developers Tutoriales de Salesforce

Las extensiones Open VSX ahora son compatibles con Code Builder ☁️

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 extensiones Open VSX ahora son compatibles con Code Builder | Blog de desarrolladores de Salesforce

Nos complace anunciar que Code Builder ahora le permite agregar extensiones desde Open VSX Registry , que brinda acceso de código abierto a las extensiones de VS Code. Con esta nueva funcionalidad, puede personalizar Code Builder con extensiones de la comunidad y de terceros para satisfacer sus necesidades más rápido y ser más productivo. En esta publicación de blog, aprenderá sobre los beneficios que Open VSX aporta a Code Builder, cómo usarlo y cómo compartir sus comentarios con nosotros.

¿Qué es el generador de código?

Code Builder es un entorno de desarrollo moderno basado en la web que está optimizado para Salesforce. Actualmente en Beta, Code Builder le permite implementar un entorno de desarrollo integrado (IDE) con todas las funciones en su navegador desde su organización de Salesforce, con solo presionar un botón.

Las funciones clave, como la finalización y refactorización de código, ayudan a aumentar la productividad del desarrollador, mientras que las herramientas de apuntar y hacer clic dentro de Code Builder, como SOQL Builder, y la compatibilidad con todos los lenguajes y marcos de trabajo de Salesforce, facilitan el desarrollo de cualquier forma que desee. me gusta

Finalmente, con Code Builder, que se basa en AWS, puede acceder a las mismas extensiones de Salesforce y CLI que están disponibles en el escritorio.

Mejor juntos: Code Builder + Open VSX

Cuando inicia Code Builder desde una organización, viene precargado con las herramientas de Salesforce que necesita, incluido todo el paquete de extensiones de Salesforce y la CLI de Salesforce. Sin embargo, como parte del proceso de su equipo, es posible que necesite otras herramientas para realizar el trabajo. Ahí es donde Open VSX Registry puede ayudar.

Por ejemplo, tomemos el control de fuente. Code Builder ya tiene acceso a Git y GitHub, pero quizás su equipo use algo diferente. Si su equipo trabaja con Jira y BitBucket, puede agregar las extensiones de Jira y Bitbucket en su entorno personal de Code Builder, lo que le permite trabajar con historias y control de fuente sin problemas dentro de Code Builder.

Con casi 3000 extensiones y 1600 editores diferentes en Open VSX, hay muchos otros complementos para elegir para personalizar su entorno Code Builder.

Salesforce y Open VSX

En Salesforce, estamos comprometidos con el código abierto . Dentro de las organizaciones que fomentan y adoptan el código abierto, los beneficios para los desarrolladores son claros:

  • Código de mayor calidad: el código fuente abierto generalmente exhibe las mejores prácticas de diseño de software; está escrito de forma modular y limpia, y también está bien documentado, ya que los desarrolladores de todo el mundo necesitan entender cómo funciona.
  • Mejora de habilidades blandas: trabajar en código abierto lo lleva a aprender naturalmente cómo ser un gran compañero de equipo y colaborador. También aprende de otros desarrolladores expertos siguiendo las pautas de contribución y revisando el código.
  • Innovación: La inteligencia colectiva es extremadamente poderosa. Al tener diferentes cerebros con diferentes antecedentes y mentalidades trabajando juntos, nuevas funciones e ideas innovadoras pueden surgir rápidamente.

Open VSX es una gran representación de la colaboración de código abierto. Dado su continuo crecimiento, la Fundación Eclipse ha formado un grupo de trabajo para guiar la evolución del Registro Open VSX . Salesforce es patrocinador y miembro del grupo de trabajo para ayudar a garantizar que nuestros usuarios tengan las herramientas y funciones necesarias para construir en nuestra plataforma.

Próximos pasos

Code Builder se encuentra actualmente en versión beta abierta y está disponible para que cualquiera lo pruebe. Si desea encontrar más recursos, o si tiene preguntas o comentarios, consulte el grupo de la comunidad Code Builder Trailblazer . ¡Esperamos sus comentarios!

Tenga en cuenta que también puede acceder a las extensiones de Salesforce en Open VSX, por lo que están disponibles en cualquier lugar donde las necesite.

Sobre los autores

Stephanie Maddox es directora del equipo de gestión de productos de Salesforce. Puedes seguirla en LinkedIn o Twitter .

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/06/open-vsx-extensions-are-now-supported-in-code-builder.html

Categories
Developers Tutoriales de Salesforce

Presentamos las mejoras de la beta abierta de Anypoint Code Builder ☁️

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.

Presentamos las mejoras de la versión beta abierta de Anypoint Code Builder | Blog de desarrolladores de Salesforce

¡Nos complace anunciar el lanzamiento en junio de la versión beta abierta de Anypoint Code Builder! Anypoint Code Builder es el IDE (Entorno de desarrollo integrado) de próxima generación de MuleSoft, para que los desarrolladores diseñen, desarrollen e implementen API e integraciones. Desde su lanzamiento Open Beta en febrero de 2023, el equipo ha estado agregando mejoras regularmente en una cadencia bimensual. Mientras que el lanzamiento de abril se centró en capacidades de IU adicionales, el lanzamiento de junio se centra en una mayor accesibilidad para los usuarios y la flexibilidad en la forma en que los usuarios pueden diseñar e implementar sus API.

Disponibilidad de Open Beta en el plano de control de la UE

Desde su lanzamiento, la versión beta abierta de Anypoint Code Builder solo ha estado disponible en el plano de control de EE. UU. Nos complace decir que esta restricción ya no existe. ¡La versión beta abierta de Anypoint Code Builder ahora está disponible para todos los usuarios en el plano de control de la UE! Esto significa que los usuarios de la UE ya no necesitarán crear nuevas cuentas de prueba en el plano de control de NA para acceder a una instancia de IDE en la nube y experimentar una latencia mucho menor a medida que diseñan y desarrollan. En el futuro, todas las versiones y mejoras futuras de Anypoint Code Builder estarán disponibles para los aviones de control de EE. UU. y la UE simultáneamente.

Entonces, ¿cómo pueden comenzar los usuarios de la UE? Simplemente haga que el administrador de su organización acepte los Términos y condiciones de la versión Beta y le otorgue permisos, luego diríjase a Anypoint Code Builder Central , donde puede crear una nueva instancia de su IDE en minutos. Y dado que es un IDE basado en la nube, seleccionaremos automáticamente el plano de control adecuado para su instancia. ¡Es fácil!

Diseño e implementación de API iterativas

Con Anypoint Code Builder, a los usuarios se les ofrecen tres recorridos principales para comenzar: diseñar especificaciones de API , implementar especificaciones de API y desarrollar integraciones . Tradicionalmente, la única forma de implementar una especificación de API era terminar por completo la fase de diseño y publicarla en nuestro mercado público, Anypoint Exchange . Sin embargo, no existe una regla que diga que el diseño y la implementación de la API deben estar aislados (después de todo, todos somos Trailblazers aquí, ¿no?). Es por eso que presentamos el diseño e implementación de API iterativas en Anypoint Code Builder. Esto le permite comenzar a diseñar la especificación de su API y luego saltar directamente a la fase de implementación para comenzar a agregar lógica empresarial antes de completar la fase de diseño. El resultado final es una experiencia optimizada que permite a los usuarios flexibilizarse entre las fases de diseño e implementación, abordando todo el proyecto en secciones en lugar de todo a la vez. Y para colmo, hemos hecho que toda esta experiencia sea perfecta al proporcionar una vista única para ambas fases directamente desde su navegador.

Se agregó soporte de interfaz de usuario para fragmentos

Cuando se lanzó por primera vez Open Beta para Anypoint Code Builder, la interfaz de usuario era de solo lectura. Los desarrolladores podían usarlo para visualizar su trabajo, pero no había forma de desarrollarlo activamente. Sin embargo, este siempre fue un plan temporal y el objetivo final es brindar a los usuarios dos opciones sólidas para la integración y el desarrollo de API: código bajo y código profesional. Durante los últimos seis meses, hemos estado trabajando para lograr esta visión agregando formas de interactuar con la interfaz de usuario. Por ejemplo, en nuestro lanzamiento de abril, introdujimos la capacidad de agregar nuevos componentes a sus flujos simplemente usando el símbolo "+".

En nuestro lanzamiento de junio, presentamos dos mejoras más en la interfaz de usuario para mejorar la experiencia de código bajo. La primera es la capacidad de seleccionar conectores directamente desde Anypoint Exchange mientras se agregan componentes. Esto proporciona a los desarrolladores una alternativa de interfaz de usuario a la paleta de comandos, al mismo tiempo que les brinda una forma más limpia de clasificar todas las versiones y operaciones del conector que están disponibles. El segundo es la capacidad de agregar fragmentos de la interfaz de usuario.

Los fragmentos son bloques de código preempaquetados que los desarrolladores pueden reutilizar en varios proyectos. Hay algunos que vienen preconstruidos con Anypoint Code Builder, pero los desarrolladores también pueden crearlos personalizados. Esto acelera el desarrollo al facilitar la replicación de tareas repetitivas. Por ejemplo, supongamos que con frecuencia necesita obtener información de contacto de una organización específica en Salesforce. La primera vez que haga esto, escribirá el XML con toda la configuración necesaria. Una vez escrito, puede empaquetar ese código en un fragmento. La próxima vez que necesite obtener información de contacto de esa organización, simplemente puede seleccionar ese fragmento de la interfaz de usuario en lugar de codificarlo todo nuevamente. A medida que los desarrolladores comienzan a crear bibliotecas de fragmentos, vemos que se trata de una herramienta increíblemente poderosa que ayudará a promover la reutilización en toda la organización.

Conclusión

El lanzamiento en junio de la versión beta abierta de Anypoint Code Builder es un hito fundamental en nuestro camino hacia la disponibilidad general. Con la expansión al plano de control de la UE, estamos entusiasmados de brindarles a más desarrolladores la oportunidad de tener en sus manos el producto. Y esperamos continuar introduciendo capacidades de interfaz de usuario adicionales junto con algunas funcionalidades de inteligencia artificial emocionantes a finales de este año. Si desea obtener una descripción general más detallada de las mejoras de junio, consulte la descripción general completa del video .

Más recursos

Sobre el Autor

Rohan Vettiankal es gerente de marketing de productos en MuleSoft, donde dirige su cartera de integración. A lo largo de su carrera, ayudó a llevar una variedad de productos al mercado, incluida una herramienta de visualización de datos basada en la web, una plataforma de infraestructura de datos local y un producto PaaS en la nube. En su tiempo libre, Rohan disfruta de actividades al aire libre como el senderismo, el snowboard y la escalada en roca. También le encanta la música y ha estado tocando el piano desde que tenía 12 años y recientemente ha estado aprendiendo guitarra. Siga a Rohan 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/06/introducing-anypoint-code-builder-open-beta-enhancements.html

Categories
Developers Tutoriales de Salesforce

Explore el adaptador de cable GraphQL, ahora en versión beta ☁️

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.

Explore el adaptador de cable GraphQL, ahora en versión beta | Blog de desarrolladores de Salesforce

¡Atención, desarrolladores de Salesforce! Hemos estado incursionando en GraphQL durante algún tiempo y estamos llevando las cosas al siguiente nivel. Hace unos meses, anunciamos el lanzamiento piloto del adaptador de cable GraphQL. Mantenga sus soportes porque estamos implementando la versión beta del adaptador de cable GraphQL de Salesforce en nuestro lanzamiento de verano '23. En este blog, exploraremos las novedades de la versión Beta y cómo utilizar Recetas de LWC para crear fácilmente su aplicación Salesforce con la tecnología de GraphQL.

La versión Beta del GraphQL Wire Adapter es un avance significativo en la gestión de datos de Salesforce en LWC. Con la introducción de nuevas funciones, como Recetas LWC, Actualización de datos e Integridad referencial, el proceso de desarrollo se ha vuelto más ágil y eficiente.

El adaptador de cable GraphQL permite consultar datos de Salesforce mediante consultas expresivas con funcionalidades como filtrado, clasificación, paginación y seguimiento de relaciones padre/hijo. También incluye una capa de gestión de datos y almacenamiento en caché del lado del cliente de Lightning Data Service. Estas funciones mejoran la eficiencia y la velocidad del acceso a los datos de Salesforce desde sus aplicaciones web y móviles de LWC.

El adaptador de cable GraphQL interactúa con la API de Salesforce GraphQL, que expone todos los objetos estándar y personalizados disponibles a través de la API de la interfaz de usuario, junto con los metadatos de los objetos. La API también mantiene la seguridad a nivel de objeto y de campo del usuario actual durante la ejecución de la consulta.

Para familiarizarse con el esquema de la API de GraphQL, sugerimos revisar la documentación del esquema utilizando el cliente de Altair GraphQL . Las herramientas disponibles en este cliente facilitan la redacción de su consulta GraphQL y su validación. Luego puede copiar y pegar su consulta directamente en su código JavaScript en Visual Studio Code.

Novedades en Beta:

  1. Recetas LWC: estos son componentes listos para usar que muestran varios casos de uso de GraphQL
  2. Actualización de datos: un mecanismo para actualizar los datos devueltos por su consulta de GraphQL
  3. Integridad referencial: este mecanismo garantiza la coherencia de los datos y las referencias a los recursos de Salesforce, como entidades y campos, son sólidas.

Analicemos cada una de estas características en detalle.

Recetas LWC

LWC Recipes es un repositorio de GitHub con una colección de ejemplos de código disponibles públicamente para componentes web Lightning. Incluye tres recetas GraphQL para ayudarlo a comenzar rápidamente a crear su aplicación Salesforce con GraphQL.

El repositorio proporciona instrucciones sobre cómo configurar su entorno, crear su organización de Salesforce, clonar el repositorio en su máquina local e implementar la aplicación en su organización. El código fuente se puede importar directamente a su Visual Studio Code como un proyecto que puede personalizar según sus necesidades.

Una vez que implemente la aplicación Recetas de LWC en su organización de Salesforce, es posible que vea los siguientes componentes mediante consultas de GraphQL.

Aquí hay una descripción general de los cuatro componentes de LWC que usan consultas GraphQL:

  • graphqlContacts : obtiene contactos que cumplen ciertos criterios, ordenados por nombre y limitados a los primeros cinco registros
  • graphqlVariables : captura la entrada del usuario en una barra de búsqueda en una variable y compone una consulta para devolver contactos cuyo nombre coincide parcialmente con la cadena de entrada
  • graphqlRefresh : obtiene una cantidad de empleados en una cuenta y actualiza los datos al hacer clic en el usuario
  • graphqlPagination : Habilita la paginación a través de una lista de contactos

Dado que muchos de nuestros clientes preguntan sobre la paginación, profundicemos un poco más. El adaptador de cable GraphQL es compatible con la paginación basada en cursores de GraphQL. Puede recorrer las páginas de los resultados de su consulta y controlar la cantidad de resultados que desea obtener cada vez. Para especificar el número de registros a devolver, utilice el first argumento. El número predeterminado es 10.

Si hasNextPage es verdadero, puede proporcionar el valor de endCursor al argumento after de una consulta posterior para solicitar la siguiente página de resultados.

Aquí hay una captura de pantalla de cómo podría verse el proyecto Recetas de LWC en Visual Studio Code. Puede ver un código de ejemplo para la implementación de la paginación.

Actualización de datos

En el mundo del desarrollo de aplicaciones, mostrar datos actualizados es fundamental para una buena experiencia de usuario y para generar confianza. Por lo tanto, en la versión Beta del GraphQL Wire Adapter, presentamos la función refreshGraphQL .

Esta función permite a los desarrolladores activar manualmente una repetición de la consulta. ¿El resultado? Una actualización de los datos proporcionados por el adaptador de cable GraphQL, lo que garantiza que los usuarios siempre vean los datos más actualizados.

Esta actualización se puede activar a pedido, como un clic de botón de un usuario o un evento de JavaScript específico. Esto significa que puede optimizar su aplicación para que se actualice solo cuando sea necesario, lo que proporciona una manera eficiente de mantener los datos actualizados y maximizar el rendimiento de la aplicación. En pocas palabras, la función refreshGraphQL ofrece un método amigable con el rendimiento para mantener los datos actualizados, mejorando la experiencia del usuario y aumentando la confiabilidad de la aplicación.

Aquí hay un ejemplo de uso:

Consulte el componente graphqlRefresh en las recetas de LWC para ver otro ejemplo del uso de la función de actualización de datos.

Integridad referencial

La versión Beta del adaptador de cable GraphQL presenta integridad referencial. He aquí una breve descripción de sus beneficios e implicaciones.

Lightning Data Service (LDS), la capa de administración de datos del lado del cliente de Salesforce, mejora la eficiencia de la aplicación al permitir que los componentes compartan datos, reducir las llamadas al servidor y mantener la coherencia de los datos. También garantiza referencias sólidas a los recursos de Salesforce, propagando cambios de nombre y evitando eliminaciones cuando las referencias persisten.

En la versión piloto del adaptador, requerimos el uso de directivas @category para ayudar a LDS a comprender el esquema de datos y normalizar sus datos de GraphQL.

Sin embargo, en la versión Beta, estas directivas ya no se requieren manualmente. Si se usaron anteriormente, ahora se pueden eliminar de sus consultas de GraphQL. El compilador gestiona de forma autónoma estas directivas, agilizando su proceso de código y reduciendo posibles errores manuales.

¿Qué sigue para GraphQL?

Recordatorio: Salesforce es una empresa que cotiza en bolsa y los clientes deben basar sus decisiones de compra en los productos y servicios que están disponibles actualmente.

Estamos comprometidos a continuar invirtiendo en GraphQL. Esto es lo que puede esperar en los próximos lanzamientos (se aplica la declaración prospectiva):

Invierno '24:

  • Adaptador de cable GraphQL (GA)
  • Compatibilidad con mutaciones en la API de GraphQL
  • Compatibilidad con consultas agregadas en GraphQL Adapter
  • Capacidad de consulta de tareas y eventos en GraphQL API (Beta)

Primavera 24 y más allá:

  • Compatibilidad con mutaciones en GraphQL Adapter
  • Funciones avanzadas de paginación
  • Soporte de campos opcionales

Recursos para desarrolladores

Sobre el Autor

Suvda Myagmar es directora de gestión de productos en Salesforce y le apasionan las plataformas de datos e IA. Le encantan las carreras largas mientras escucha audiolibros.

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/06/explore-the-graphql-wire-adapter-now-in-beta.html

Categories
Developers Tutoriales de Salesforce

Muévete a 2GP Administrado con Migraciones de Paquetes ☁️

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.

Pasar a 2GP administrado con migraciones de paquetes | Blog de desarrolladores de Salesforce

Han pasado casi cuatro años desde que lanzamos por primera vez el paquete administrado de segunda generación (2GP) , que permite a nuestros socios de AppExchange crear y distribuir soluciones utilizando un modelo de desarrollo basado en CLI, basado en fuente y fácil de automatizar.

Desde entonces, recibimos una gran cantidad de excelentes comentarios de nuestra comunidad de desarrolladores, y continuamos innovando en múltiples áreas relacionadas con la experiencia del desarrollador, el rendimiento, la paridad del tipo de metadatos con el paquete administrado de primera generación (1GP), etc. Cada vez que nos reunimos con desarrolladores de ISV, constantemente escuchamos sobre la necesidad de que Salesforce los ayude a ellos y a sus clientes a pasarse al mundo de 2GP.

¡Hoy, tengo algunas noticias emocionantes para compartir con todos ustedes! Estamos abordando la pregunta n.º 1 de nuestros desarrolladores de ISV al presentar una nueva función: Migraciones de paquetes . En pocas palabras, Package Migrations automatiza por completo el proceso de convertir paquetes 1GP a 2GP y migra sin problemas a los clientes con paquetes instalados a 2GP. Si es un socio ISV que crea paquetes administrados, ¡esta publicación de blog es para usted!

Antes de sumergirnos en los detalles de las migraciones de paquetes, echemos un vistazo a algunos beneficios de usar 2GP para el desarrollo de paquetes.

Beneficios de usar 2GP para el desarrollo de paquetes

En el corazón de 2GP se encuentra un modelo de desarrollo basado en fuente, donde un repositorio de código fuente como Git representa la fuente de la verdad para su paquete. Esto es fundamentalmente diferente del mundo de 1GP, donde utiliza una organización de empaquetado para mantener todos los metadatos que desea empaquetar y distribuir a sus clientes.

Este modelo de desarrollo impulsado por la fuente, impulsado por la CLI de Salesforce , puede aumentar drásticamente la productividad y la colaboración de su equipo. Los desarrolladores pueden usar Dev Hub para activar rápidamente organizaciones temporales , crear una función de forma conjunta y comprometerla con el control de código fuente. Cuando esté listo para distribuir una nueva versión de su 2GP, simplemente extraiga la rama correspondiente a una máquina local y use la CLI para crear su nueva versión del paquete.

Es importante destacar que este enfoque basado en CLI también significa que puede integrar fácilmente su proceso de empaque por completo en CI/CD, lo que facilita la automatización completa de su flujo de trabajo. Puede, por ejemplo, ejecutar automáticamente Salesforce Code Analyzer en una base de código y, siempre que no se encuentren problemas, crear una nueva versión del paquete.

En el mundo de 1GP, estabas atrapado usando un espacio de nombres diferente para cada uno de tus paquetes. En 2GP, todos sus paquetes pueden compartir el mismo espacio de nombres, lo que le permite aprovechar un enfoque verdaderamente modular para el desarrollo de paquetes para mantener sus paquetes bien organizados. También es posible declarar explícitamente dependencias entre paquetes , asegurando que todo funcione en conjunto sin problemas.

Con 2GP, también obtiene un control de versiones flexible, lo que le permite abandonar versiones de paquetes que ya no desea utilizar. En su lugar, puede especificar un ancestro de la versión del paquete y crear efectivamente una nueva rama en la que desee continuar con su desarrollo.

Finalmente, apoyar a los clientes nunca ha sido tan fácil con 2GP. En el mundo de 1GP, los parches solo se pueden crear desde una organización de parches. Con el modelo de desarrollo basado en el código fuente de 2GP, puede simplemente crear una versión del paquete de parches directamente desde la CLI y, siempre que el parche cumpla con los requisitos relacionados con los cambios menores y la ascendencia del paquete, se crea y está listo para instalarse en la organización de su cliente.

Dicho todo esto, 2GP puede agregar mucho valor a su proceso de desarrollo. ¡Ahora, averigüemos cómo las Migraciones de paquetes pueden ayudarlo a llegar al mundo de 2GP!

Introducción a las migraciones de paquetes

Package Migrations amplía la funcionalidad de 2GP con comandos CLI adicionales y capacidades adicionales para ayudar a los desarrolladores de ISV a realizar una transición completa al mundo de 2GP. Actualmente se encuentra en Developer Preview y está abierto para que todos los desarrolladores de ISV lo prueben en sus paquetes 1GP existentes. ¡Siga leyendo para saber cómo participar en la versión preliminar para desarrolladores!

Hay dos elementos para las migraciones de paquetes: conversión de paquetes y migración de paquetes.

La conversión de paquetes se inicia a través del nuevo comando sf package convert . Toma una versión específica de su paquete 1GP existente (Acme v1.0 en este ejemplo) y usa algo de magia detrás de escena para convertirlo en una versión de paquete 2GP correspondiente (Acme v1.0.0.1 usando la numeración de versión 2GP).

Una vez que tenga una versión de paquete 2GP convertida, puede migrar clientes a 2GP. Si tiene un suscriptor con Acme v1.0 instalado, iniciaría el proceso tratándolo como una actualización de paquete normal: a través de la CLI con sf package install (ver documentos ), instalación de URL o actualizaciones automáticas.

Mientras intenta instalar su paquete 2GP convertido v1.0.0.1, que coincide con la versión mayor.menor del paquete 1GP instalado en el suscriptor A, ejecutamos una nueva lógica que inicia el proceso de migración del paquete . Sin cambiar ningún metadato en la organización del cliente, y sin requerir la intervención del usuario si usa actualizaciones automáticas, simplemente cambiamos las referencias del paquete para que apunten al nuevo paquete 2GP.

Una vez que un cliente migre a 2GP, cualquier parche o actualización del paquete de este cliente deberá usar 2GP.

Participación en la versión preliminar para desarrolladores de migraciones de paquetes

Para probar las migraciones de paquetes, debe ser un socio ISV con acceso a la comunidad de socios de Salesforce .

En la Comunidad de socios, encontrará un canal exclusivo para esta versión preliminar para desarrolladores. Le recomendamos que se una a este canal y configure las notificaciones para enviar por correo electrónico cada publicación para recibir las últimas actualizaciones del equipo de Migraciones de paquetes.

En este canal, encontrará una serie de enlaces útiles, incluido un formulario para registrarse en Developer Preview. Necesitaremos algunos detalles, como su ID de organización de empaquetado, para que podamos activar la función Migraciones de paquetes.

Es importante destacar que participar en Developer Preview no tendrá ningún impacto en su paquete de 1GP. Por lo tanto, no se preocupe y participe, ya que sus comentarios son esenciales para ayudarnos a identificar y resolver problemas lo antes posible.

Una vez que esté activado, puede comenzar a probar las migraciones de paquetes.

Probar la conversión de un paquete administrado de primera generación

Muy bien, ¡comencemos! En primer lugar, asegúrese de haber instalado la CLI de Salesforce.

Si lo instaló anteriormente, asegúrese de estar usando la última versión:

sf update

Ahora asegúrese de que está ejecutando dentro del contexto de un proyecto de SalesforceDX. Puedes crear un nuevo proyecto usando:

sf project generate --name <Your project name>

Vincule el espacio de nombres de su 1GP administrado iniciando sesión en su DevHub y siga los pasos .

¡Eso es todo para la configuración! Ahora puede continuar e intentar convertir su paquete.

sf package convert --installation-key mdpTest --package 033xxx --wait 20

Repasemos los parámetros. Estamos utilizando la clave de instalación mdpTest . Será necesario cada vez que intente instalar esta versión del paquete en el futuro. Alternativamente, puede usar --installation-key-bypass para omitir la clave de instalación. Deberá ingresar su ID de paquete 1GP completo comenzando con 033 después de --package . El proceso de conversión puede demorar un poco y, por lo tanto, agregamos la opción --wait para esperar 20 minutos.

A medida que se ejecuta el proceso de conversión, obtendrá una actualización de su estado. Suponiendo que todo salió bien, recibirá un mensaje de éxito con la ID y la URL de instalación para la versión del paquete 2GP recién convertida.

Converting Package... ... Successfully created the package version [08cxxx00000KzFSAA0]. Subscriber Package Version Id: 04txxx00000u1cqAAA
Package Installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA
As an alternative, you can use the "sfdx package:install" command.

¡Felicitaciones, su paquete ahora está convertido a 2GP! Si encontró algún problema en el camino, infórmenos utilizando el formulario en el grupo Comunidad de socios .

Nota: Al momento de escribir esta publicación de blog, este comando convertirá la última versión administrada y lanzada de su paquete. Estamos trabajando para permitirle convertir versiones de paquetes Beta y anteriores. Por otro lado, durante Developer Preview, no es posible promocionar paquetes 2GP convertidos al estado Lanzado.

Ahora que su paquete está convertido, probemos la migración de una organización suscriptora.

Probar la migración de un paquete administrado de primera generación instalado

Para probar la migración de un suscriptor, deberá crear una organización borrador ya que, durante la versión preliminar para desarrolladores, solo admitimos organizaciones borrador. Puede configurar una nueva organización borrador como esta:

sf org create scratch -f project-scratch-def.json -a MyScratchOrg

En el código anterior, -f apunta a su archivo de definición de organización borrador . Debe asegurarse de que su archivo de definición de organización borrador incluya cualquier función de Salesforce de la que pueda depender su paquete. Finalmente, estamos usando MyScratchOrg como el alias de esta organización.

Con la configuración de la organización borrador, continúe e instale la versión del paquete 1GP que convirtió anteriormente utilizando la URL de instalación que obtiene de su organización de empaquetado 1GP. Esta debería ser su última versión administrada y lanzada en este momento.

Puede confirmar que el paquete se instaló correctamente durante la pantalla de instalación. Vea el ejemplo a continuación.

Y consulte la sección Paquetes instalados del menú Configuración.

Ahora que instaló su 1GP en la organización borrador, está listo para la migración.

Inicie el proceso de migración utilizando la URL de instalación que recibió al final del proceso de conversión del paquete:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx00000u1cqAAA

Ahora pasará por el mismo conjunto de pantallas que el anterior, pero esta vez para su paquete 2GP convertido.

Actualmente, la interfaz de usuario muestra que la "instalación" se ha completado. En realidad, lo que hicimos fue una migración de paquetes que se completó con éxito.

Tenga en cuenta que en este ejemplo, he usado la segunda compilación Beta para la versión 1.7, que corresponde a la misma versión mayor.menor que la versión del paquete 1GP instalada anteriormente. Como el 2GP convertido, durante la Vista previa del desarrollador, se crea como una versión Beta, se muestra como tal.

Una vez más, puede confirmar la versión del paquete actualizado en la sección Paquetes instalados del menú Configuración, que también muestra, en este ejemplo, que el número de versión es 1.7 (Beta 2).

Una vez que haya migrado el paquete en su organización borrador, le recomendamos que lo pruebe para asegurarse de que funciona como se esperaba.

También debe aprovechar la oportunidad para verificar si las aplicaciones, como la aplicación de administración de licencias o la aplicación de administración de funciones, muestran la información correcta para su paquete migrado. Si encuentra algo que no está bien, por favor plantéelo como un problema y lo investigaremos.

Mientras tanto …

Se necesitarán algunos lanzamientos para que las migraciones de paquetes estén disponibles de forma general. Su participación en Developer Preview, probando sus paquetes y brindándonos comentarios, es esencial para ayudarnos a identificar y resolver problemas antes.

Mientras tanto, ¿qué más puedes hacer? Le recomendamos que experimente con el uso de paquetes de segunda generación como parte de su modelo de desarrollo actual basado en 1GP. ¿Confundido? Dejame explicar.

Como mencioné anteriormente, hay una serie de ventajas específicas de 2GP. De estos, hay algunos de los que puede comenzar a beneficiarse hoy. Estos son los pasos que puede seguir:

  1. Puede configurar su control de código fuente y alimentarlo con metadatos extraídos de su organización de empaquetado.
  2. Puede crear un DevHub y organizaciones borrador derivadas para el desarrollo utilizando metadatos de su control de código fuente.
  3. Puede crear un paquete 2GP para desarrollo interno y pruebas que reflejen su paquete 1GP, pero usando un espacio de nombres solo interno o el mismo que su paquete 1GP. Las colisiones de espacios de nombres evitarán que los paquetes 1GP y 2GP con el mismo espacio de nombres se instalen en el mismo entorno.
  4. Una vez que esté satisfecho con el contenido de su paquete 2GP, puede migrar los metadatos desde la rama de control de fuente correspondiente a su organización de empaquetado y emitir una nueva versión de su paquete para distribuir a los clientes.

Esto lo ayudará a sumergirse en el mundo de 2GP y, una vez que Package Migrations esté disponible de forma general, podrá abandonar su modelo de desarrollo de 1GP por completo y pasar por completo a un modelo de desarrollo de 2GP.

Conclusión

Estamos muy entusiasmados con las migraciones de paquetes, pero necesitamos su ayuda para asegurarnos de que sea lo mejor posible. Si es un desarrollador de ISV, continúe y regístrese para la Vista previa para desarrolladores en la Comunidad de socios.

¡Estamos ansiosos por recibir sus comentarios!

Más recursos

Grupo de vista previa para desarrolladores en la comunidad de socios

Embalaje gestionado de segunda generación (documentación)

Sobre el Autor

John Belo es director de gestión de productos para productos de experiencia de desarrollador y se centra en migraciones de paquetes, analizador de código de Salesforce y análisis de aplicaciones de AppExchange. Ha estado en Salesforce durante más de siete años y pasó la mayor parte de este tiempo en el equipo de AppExchange. Comenzó liderando un equipo de evangelistas técnicos de ISV en EMEA y ahora es parte del equipo de gestión de productos de experiencia de desarrollador, siempre con la intención de ayudar a los ISV a tener el mayor éxito posible.

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/move-to-managed-2gp-with-package-migrations.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
AppExchange Developers Tutoriales de Salesforce

Lo que los socios ISV deben saber sobre Lightning Web Security ☁️

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.

Lo que los socios ISV deben saber sobre Lightning Web Security | Blog de desarrolladores de Salesforce

Lightning Web Security (LWS) habilita algunas de las funciones nuevas más buscadas para Lightning Web Components (LWC), como importaciones de espacios de nombres cruzados, mayor compatibilidad con bibliotecas de JavaScript de terceros y más. Sin embargo, los ISV deben tener en cuenta algunas consideraciones importantes al trabajar con LWS. En esta publicación de blog, brindaremos una breve descripción general de LWS y luego pasaremos a las recomendaciones específicas de ISV. ¡Un agradecimiento especial a mi colega Alba Rivas, quien me permitió probar su excelente Respuesta de StackExchange para la primera parte de este blog!

Parte I: ¿Qué es Lightning Web Security (LWS)?

LWS es una nueva arquitectura de seguridad del lado del cliente para Lightning Web Components (LWC) que reemplaza a Lightning Locker . LWS es menos restrictivo, pero tan seguro como Lightning Locker. En Spring '23, implementaremos una versión beta abierta de LWS para los componentes de Aura (se aplica el puerto seguro ). Cualquiera puede optar por esta versión beta activando una configuración en el menú Configuración de su organización (más detalles sobre esto más adelante en la publicación).

¿Cómo funciona LWS?

LWS sigue el modelo de los últimos estándares TC39 y evolucionará con las plataformas de navegador a medida que pase el tiempo. Los componentes están aislados en su propia caja de arena de JavaScript hecha de un iframe separado. Esto nos permite exponer objetos globales de ventana, documento y elemento directamente, sin abrir la puerta a amenazas de seguridad. LWS altera el código que se ejecuta en el espacio aislado de JavaScript para evitar comportamientos inseguros.

¿Cuáles son los beneficios de LWS sobre Lightning Locker?

LWS promueve el diseño modular, la reutilización de código y flexibilidad adicional. Con LWS puedes:

  • Importe y use LWC de diferentes espacios de nombres mediante composición o extensión
  • Interactuar con objetos globales (p. ej., ventana, documento, elemento)
  • Use bibliotecas de JavaScript de terceros que manipulen objetos globales
  • Acceda al contenido de iframe y a la identidad si el contenido es del mismo origen (nuevo en la versión Winter '23)

Para los ISV, LWS les permite anidar componentes de un espacio de nombres dentro de un componente de un espacio de nombres diferente. O pueden usar un LWC sin cabeza como una biblioteca JS de utilidad compartida que reside en un espacio de nombres de paquete "base" e importarlo a componentes de otros espacios de nombres. Estos casos de uso no eran posibles antes de LWS e ilustran las mejores prácticas en la reutilización de código. Como beneficio adicional, los clientes de un ISV también pueden usar los componentes con espacio de nombres del ISV dentro de sus propios componentes de la misma manera si el ISV ha expuesto los componentes.

Mientras que Locker no permite que los componentes accedan a objetos estándar globales como ventana , documento y elemento (los reemplaza con versiones de envoltorio seguro de estos objetos), LWS sí lo permite y también restringe menos propiedades y funciones relacionadas con estos objetos. Para ver la lista completa de diferencias, compare LWS Distortion Viewer con Locker API Viewer para cada uno de estos tres objetos (más información sobre estas herramientas más adelante). Un beneficio adicional de trabajar con estos objetos estándar directamente es la alineación con los estándares y sintaxis familiares para los desarrolladores web, lo que lleva a una mayor productividad de los desarrolladores al hacer que el código y los registros de depuración sean más fáciles de trabajar.

Sin embargo, el mayor beneficio de LWS que permite el acceso a estos objetos globales es que desbloquea la capacidad de usar muchas bibliotecas de JavaScript de terceros populares que no eran compatibles con Locker. La siguiente imagen muestra tres bibliotecas de terceros populares, D3 , Chart.js y FullCalendar , que funcionan dentro de una organización de Salesforce. Esto no era posible antes de LWS debido a las restricciones de Locker. La imagen también ilustra los componentes de un espacio de nombres anidados o importados en componentes de varios otros espacios de nombres. Como recordatorio, LWS actualmente es solo para LWC mientras trabajamos para lanzar LWS para componentes Aura.

LWS también proporciona un rendimiento mejorado en comparación con Lightning Locker porque no utiliza envoltorios seguros que pueden reducir el rendimiento. El equipo de ingeniería sigue centrándose en mejorar el rendimiento con cada versión.

La lista de beneficios de LWS crecerá con el tiempo a medida que introduzcamos nuevas características que requieren que LWS esté habilitado. Por ejemplo, estamos trabajando arduamente en funciones muy esperadas, como la creación de componentes dinámicos, así como las importaciones dinámicas para LWC ( puerto seguro ), que dependerán de que LWS esté habilitado en una organización para funcionar correctamente.

En el resto de esta publicación de blog, nos referiremos al grupo anterior de funciones que LWS hace posible como funciones "solo LWS".

¿Cómo puedo activar LWS?

Vaya a ConfiguraciónConfiguración de sesión y habilite Usar Lightning Web Security para componentes web Lightning . Esto afecta a todos los componentes de LWC personalizados en su organización, incluidos aquellos en paquetes administrados.

En Spring '23, esta configuración cambiará para habilitar LWS para los componentes LWC y Aura en la organización. El nombre de la configuración cambiará a: "Usar seguridad web Lightning para componentes web Lightning (GA) y componentes Aura (beta)" para reflejar esto ( puerto seguro ).

Parte 2: ¿Deberían los ISV adoptar características exclusivas de LWS hoy?

Recomendamos que los ISV esperen al menos hasta el verano de 2023 para adoptar funciones exclusivas de LWS para casos de uso de producción. Para los ISV que realmente desean usar las funciones exclusivas de LWS ahora, exploraremos sus opciones más adelante en esta publicación.

La razón por la que recomendamos esperar es que LWS pasó a estar disponible de forma general (GA) en la primavera de 22 solo para LWC . LWS para Aura todavía está en desarrollo y tiene como objetivo una versión de verano de 23 GA ( puerto seguro ). La activación de LWS en una organización que usa componentes Aura aún no es compatible * y puede causar problemas.

*"No compatible" significa que si surge un problema a causa de esto, el servicio de asistencia técnica de Salesforce no podrá ayudar a depurar y resolver el problema. No significa que los componentes de Aura dejarán de funcionar por completo.

Por esta razón, nuestra guía actual para los clientes que usan componentes Aura es habilitar LWS solo después de haber probado exhaustivamente todos sus casos de uso de componentes Aura en un espacio aislado con LWS habilitado. y siéntase cómodo habilitando LWS en producción, ya que LWS para Aura todavía está en versión beta hasta el esperado lanzamiento de GA en el verano de 23 ( puerto seguro ).

Esto significa que es probable que la mayoría de los ISV tengan una combinación de algunos clientes con LWS habilitado en sus organizaciones y otros sin él.

¿Cómo deben prepararse los ISV para LWS?

Dado que los ISV querrán incorporar nuevos clientes y brindar soporte a los clientes existentes que pueden o no tener LWS habilitado, deben asegurarse de que su aplicación funcione correctamente en organizaciones con y sin LWS habilitado.

Para asegurarse de que su aplicación ISV funcione en una organización sin LWS, no confíe aún en las funciones exclusivas de LWS (sin un plan alternativo). Los ISV no pueden asumir que LWS estará habilitado en todos los lugares donde se ejecute su aplicación, ya que algunos clientes aún no podrán habilitar LWS (p. ej., porque usan componentes de Aura que crearon o que están incluidos en el paquete de otro ISV y que tienen cuando LWS está habilitado o el cliente no tiene ancho de banda para la prueba de regresión).

Para asegurarse de que su aplicación ISV funcione en una organización con LWS, pruebe cualquier caso de uso basado en componentes de Aura en una organización que tenga LWS habilitado para asegurarse de que funcionen como se espera. Si LWS causa un problema (lo que es poco probable), proporcionamos algunas herramientas que pueden ser útiles para la depuración.

Diseñamos una lista de verificación para probar LWC con LWS. Esto puede darle algunas ideas sobre cómo hacer lo mismo con Aura. Por ejemplo, considere si algunas de las Reglas de ESLint pueden ser útiles en su caso, o consulte el LWS Distortion Viewer para ver si las API globales que está utilizando están restringidas por LWS.

Si no puede resolver el problema, considere si puede migrar su caso de uso de Aura a LWC, o dígales a sus clientes que esperen para habilitar LWS en sus organizaciones hasta que se resuelva el problema.

Una vez que se admite LWS para Aura, todas las organizaciones pueden habilitar LWS de manera segura. En este punto, Salesforce comenzará a activarse automáticamente y eventualmente implementará LWS en todas las organizaciones restantes en un cronograma gradual con mucha anticipación.

¿Cuáles son las opciones de los ISV para adoptar funciones exclusivas de LWS?

Opción 1

Espere hasta que todas las organizaciones puedan habilitar de forma segura LWS (Summer '23, puerto seguro) para distribuir funciones exclusivas de LWS a las organizaciones de clientes. Mientras tanto, puede experimentar con estas funciones, planificar el trabajo futuro o crear funciones en una rama de Git de larga duración que no se fusionará con la principal ni se enviará a los clientes hasta que LWS para Aura esté disponible en general. Esto se puede hacer ahora en el desarrollo de LWC; para hacer esto en Aura, mantén los ojos abiertos para un piloto de LWS Aura próximamente.

Tenga en cuenta que incluso cuando LWS para Aura esté disponible de forma general, todavía habrá muchos clientes que no habiliten LWS en sus organizaciones de inmediato. Confiar en funciones exclusivas de LWS en ese momento significa que es posible que deba persuadir a algunos clientes para que habiliten LWS (hasta que Salesforce aplique LWS para todas las organizaciones).

opcion 2

Verifique en tiempo de ejecución si LWS está habilitado en una organización y cree bifurcaciones lógicas en su código utilizando declaraciones if para manejar ambos escenarios (LWS está habilitado frente a LWS no está habilitado).

Tenga en cuenta que este enfoque no funcionará si el LWC de una aplicación ISV usa referencias estáticas de espacios de nombres cruzados. Estas referencias intentarían ejecutarse o renderizarse en la creación de instancias y no pueden ser bloqueadas por una declaración if. Esto provocaría un error en las organizaciones donde LWS no está habilitado.

Estamos considerando crear una forma con soporte oficial para verificar si LWS está habilitado en una organización desde el código ( puerto seguro ), pero por ahora, puede adaptar el siguiente fragmento de código:

Aquí hay un ejemplo de cómo usarlo para crear una lógica alternativa dentro de un LWC:

Nota: si bien esperamos que este patrón continúe funcionando cuando LWS para Aura se convierta en GA, le recomendamos que realice una prueba de regresión durante cada vista previa de la versión en cualquier lugar donde use este patrón para asegurarse de que continúe funcionando como se esperaba.

Opción 3

Mantenga dos paquetes separados : uno para organizaciones con LWS habilitado y otro para organizaciones sin LWS habilitado (o un paquete base para todas las organizaciones y una extensión solo para organizaciones con LWS habilitado).

Si bien la documentación analiza esta opción, y técnicamente se puede hacer, no es una opción viable en el uso real de las aplicaciones de AppExchange . Además de la carga de mantener varios paquetes, esta opción no es lo suficientemente ágil para situaciones en las que un cliente puede activar y desactivar LWS varias veces si descubre que causó problemas imprevistos. Esto puede provocar la rotura de las aplicaciones de ISV y es imposible de predecir para los ISV.

Para los estudiantes visuales, aquí hay un modelo mental para ayudar a los ISV a decidir si es seguro usar funciones exclusivas de LWS:

¿Cómo puedo obtener ayuda?

Para informar problemas, proporcionar comentarios y hacer preguntas sobre LWS, publique en el grupo Lightning and Components de la comunidad de socios. Si está informando un problema, abra también un caso de soporte y comparta el número de caso en su publicación con el grupo.

Si es un ISV que busca una consulta estratégica para alinearse con la hoja de ruta de Salesforce, necesita ayuda para planificar su estrategia de adopción de LWS o desea comprender las mejores prácticas y cómo incorporarlas en su aplicación, reserve una consulta de Platform Expert con mi equipo en cualquier momento.

Recursos

Sobre el Autor


James Quinn es un experto principal en plataformas ISV en Salesforce. Trabaja para facilitar la vida de los socios de AppExchange a través de la escucha activa de la comunidad, abogando internamente por la preparación de ISV de los productos de Salesforce y brindando a los socios orientación estratégica sobre la arquitectura del producto y las experiencias centradas en el ser humano.

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/12/what-isv-partners-need-to-know-about-lightning-web-security.html

Categories
Developers Tutoriales de Salesforce

Aprende MOAR en Winter '23 con Release Highlights para desarrolladores ☁️

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.

Aprenda MOAR en Winter '23 con aspectos destacados de la versión para desarrolladores | Blog de desarrolladores de Salesforce

¿Escuchaste? ¡Es la semana de Dreamforce! Sí, nuestra reunión familiar de Trailblazer finalmente está aquí, los días son un poco más cortos y los PSL han comenzado a resurgir en los menús de cerca y de lejos (eso es "Pumpkin Spice Lattes", pero si leyó eso y pensó en "Licencias de conjunto de permisos", entonces definitivamente eres uno de nuestra gente!). ¡Todo esto significa que es hora una vez más de otro lanzamiento de invierno repleto para administradores y desarrolladores! Sabemos que cada versión trae consigo muchas funciones nuevas y sorprendentes, y puede haber mucho que digerir. Con Learn MOAR, empaquetamos el lanzamiento y se lo ofrecemos en un formato fácil de digerir con blogs, videos y más.

¡Calienta con Winter '23!

Es fácil empezar:

  • ¡Explore los trailmixes de Trailhead con los aspectos más destacados del lanzamiento clave para administradores o desarrolladores, o ambos!
  • Síganos todos los días de esta semana mientras publicamos blogs que destacan todas las excelentes funciones nuevas en los blogs de desarrolladores de Salesforce y administradores de Salesforce.
  • ¡Prepárese para Developer Release Ready Live! ¡Por primera vez en la historia, Release Readiness Live estará en vivo en Dreamforce! Únase a los expertos en productos y defensores de los desarrolladores para conocer las nuevas características de la versión Winter '23. Si se unirá a Dreamforce en persona, únase a la sesión el 22 de septiembre a las 11:00 a. m. (hora del Pacífico). ¿Sintonizando Dreamforce virtualmente este año? Únase a nosotros para una transmisión en vivo.

Siga y complete un trailmix de Learn MOAR Winter '23 para administradores o desarrolladores antes del 30 de noviembre 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 .

Funciones generalmente disponibles

El lanzamiento de Salesforce Winter '23 está sobre nosotros y viene con excelentes funciones nuevas para desarrolladores. Hemos reunido una lista de funciones que creemos que debe tener en cuenta, incluidas las que ahora están disponibles de forma general:

API GraphQL : si visitó el blog durante los últimos meses, sabe que estamos emocionados de compartir nuestro desarrollo en la nueva API GraphQL de Salesforce . Bueno, ¡esa API de GraphQL ahora es GA! El esquema inicial que estamos entregando le permite paginar, filtrar y ordenar sus sObjects expuestos de API de interfaz de usuario. Además de ser escalable y de alto rendimiento, le otorga la capacidad de consultar y obtener los datos exactos que necesita en una sola solicitud: nada más y nada menos. ¡Consulte nuestra increíble Guía para desarrolladores de la API de GraphQL para ver ejemplos de código!

Clonación rápida para Sandboxes en Hyperforce : sabemos que los tiempos de copia de sandbox pueden ser largos y esta nunca es una gran experiencia. Afortunadamente, Hyperforce está cambiando esto a partir del lanzamiento de Winter '23 con Quick Clone para Developer y Developer Pro Sandboxes en Hyperforce. Quick Clone es una nueva capacidad para sandboxes en Hyperforce que hará que los tiempos de clonación sean significativamente más rápidos, lo que conducirá a tiempos de copia más rápidos para entornos de desarrolladores individuales o aquellos que se usan para el control de calidad, un mejor uso de sandboxes en sus canalizaciones de CI y ciclos de lanzamiento más cortos en general.

Retransmisiones de eventos para AWS : ha sido un gran verano para las arquitecturas basadas en eventos, primero con la GA de la API Pub Sub que simplifica la forma en que los equipos publican y consumen eventos en Salesforce, y ahora extendiéndose a AWS con nuestras nuevas retransmisiones de eventos de GA para ¡AWS! Ahora puede publicar eventos de forma nativa en Amazon EventBridge sin necesidad de oyentes codificados personalizados u otro middleware.

DevOps Center : actualmente en versión beta, DevOps Center es una solución de administración de versiones y cambios de código bajo que sabemos que muchos de ustedes están esperando con ansias, ¡y no tendrán que esperar mucho más! Nuestro objetivo es una GA a principios de diciembre para DevOps Center, que proporciona una abstracción conveniente sobre las ramas de GitHub y los flujos de trabajo típicos basados en Git, lo que permite que más equipos participen en el proceso de administración de versiones.

Mejoras de características

Adaptador Salesforce Connect para Amazon Athena : fanáticos de Amazon Athena, ¡hay excelentes noticias por delante! Continuamos ampliando nuestra asociación con AWS y nos complace compartir que los clientes ahora pueden acceder a los datos administrados por Amazon Athena desde Salesforce. Todo ello sin necesidad de utilizar middleware, proporcionando la misma excelente experiencia de objetos externos para los datos estructurados almacenados en Amazon S3. Esto significa que podrá utilizar informes y paneles con objetos externos expuestos a través de Athena y acceder a esos datos de Athena mediante SOQL y Apex (sin DML).

Nuevo componente estándar para incrustar flujos de pantalla en LWC : si ha hurgado en el blog de administración una o dos veces, sabe que nos encanta un poco de flujo, por lo que estamos muy emocionados de presentar el nuevo componente lightning-flow . Ahora puede incrustar fácilmente sus flujos de pantalla en LWC y también personalizar lo que hace: desde un comportamiento de acabado único hasta un estilo personalizado y mucho más. Este es un ejemplo de cómo se vería con un Flujo de encuesta de clientes:

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

Funciones de vista previa y piloto

Actualmente en Pilot, hemos introducido una nueva función que le permite sincronizar los datos de los componentes sin actualizar la página mediante el uso de la API RefreshView. Hasta ahora, LWC no presentaba una API para actualizar datos sin continuar y actualizar toda la página. Este piloto cambia eso, permitiendo a los desarrolladores actualizar los datos para una jerarquía específica de componentes sin recargar toda la página.

El siguiente paso: la capacidad de construir componentes en el modo de sombra mixta ahora está en versión beta. Si es nuevo en esto, el modo de sombra mixto permite que los LWC usen el DOM de sombra nativo incluso cuando se aplica el relleno sintético de sombra, como en las versiones anteriores de Microsoft Edge. Esto significa que los desarrolladores simplifican las pruebas y la creación aprovechando la velocidad y la eficiencia de la sombra nativa dondequiera que puedan en su aplicación, mientras crean un camino elegante hacia la migración a la sombra nativa en el futuro. Para habilitar el modo de sombra mixta en un componente, establezca la propiedad estática shadowSupportMode en any :

¡Otra gran versión beta para aquellos de ustedes que construyen en Experience Cloud es la capacidad de actualizar las implementaciones de su sitio con nuevos tipos de API de metadatos ! Eso significa usar comandos familiares para implementar sitios LWR mediante programación y el concepto de contenido como metadatos. Siguiendo la imagen a continuación, cuando recupera DigitalExperienceBundle, los espacios de trabajo de su sitio se almacenan en la carpeta del sitio (1). Cada uno de sus sitios LWR mejorados tiene su propio espacio de trabajo (2), donde las carpetas para cada tipo de contenido (3) organizan los elementos de contenido individuales (4) que componen el sitio.

Para los desarrolladores que crean para Slack, también nos complace compartir que Apex SDK para Slack ahora está en Beta . Si estás cerca de Dreamforce, verás algunas cosas nuevas y emocionantes con este, pero con la Beta estamos permitiendo que los equipos usen las habilidades de Apex que ya tienen para crear experiencias personalizadas en Slack, y hacerlo sin necesidad para dominar Block Kit, o sin necesidad de ponerse de pie y mantener una conexión de software intermedio. Esta versión Beta también traerá consigo una gestión optimizada de usuarios internos y externos, brindándole un mayor control sobre el acceso a los datos dentro de las nuevas interfaces de usuario que ofrece.

Por último, ¡esperamos que no se haya perdido la Beta recientemente anunciada para Code Builder ! Code Builder es un IDE moderno y optimizado para Salesforce en su navegador. Ahora, los desarrolladores y administradores tienen la flexibilidad de usar nuestras extensiones de VS Code de Salesforce para VS Code de escritorio, o implementar un entorno de desarrollo preconfigurado y con todas las funciones en su navegador, directamente desde su organización. Mire este video para ver un recorrido reciente de Code Builder en acción por parte de Mohith Shrivastava, uno de nuestros increíbles promotores de desarrolladores.

¡Vea estas nuevas funciones en acción!

No se olvide de ver la vista previa para desarrolladores de Winter '23 el 22 de septiembre durante Release Readiness Live para ver demostraciones de un subconjunto de estas nuevas y emocionantes características. Y si asistes a Dreamforce, ¡ únete a nosotros EN VIVO ! ¡Asegúrese de consultar el mix de aprendizaje de Learn MOAR Winter '23 para desarrolladores y siga el blog esta semana para obtener más información sobre Learn MOAR!

Sobre el Autor

Ryan Schellack es el director de marketing de productos de la plataforma Salesforce. Su equipo se enfoca en servicios para desarrolladores, DevOps, IA y automatización. Puedes seguirlo en Twitter @rschellack .

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/09/learn-moar-in-winter-23-with-release-highlights-for-developers.html

Categories
Developers Tutoriales de Salesforce

Aprenda MOAR en Winter '23 con DevOps Center ☁️

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.

Aprenda MOAR en Winter '23 con DevOps Center | Blog de desarrolladores de Salesforce

Siga y complete un trailmix de Learn MOAR Winter '23 para administradores o desarrolladores antes del 30 de noviembre 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 .

DevOps Center es nuestro nuevo producto que mejora enormemente el proceso de gestión de cambios y versiones cuando se desarrolla con Salesforce. Permite que equipos completos aprovechen las mejores prácticas modernas de DevOps, ya sea que elijan usar la nueva interfaz de usuario basada en clics del DevOps Center o las herramientas modernas existentes como Salesforce CLI o IDE.

Por qué DevOps Center es ideal para equipos

DevOps Center se basa en la misma base que nuestra SFDX CLI. Esto significa que DevOps Center utiliza el mismo proyecto, comandos y principios generales de SFDX que se han introducido a lo largo de los años con Salesforce DX. Más importante aún, esto también significa que DevOps Center es compatible con las metodologías que se utilizan con Salesforce DX. Esta es una mejora significativa con respecto a los conjuntos de cambios, que son básicamente incompatibles con la CLI de SFDX y el desarrollo basado en código fuente en general.

Ahora, equipos completos pueden aprovechar las capacidades modernas, como el desarrollo basado en código fuente, el uso de control de código fuente y la automatización, pero utilizando las herramientas que prefieran. Pueden usar interfaces de línea de comandos como la CLI, IDE como VS Code o Code Builder y GitHub, O una interfaz de usuario declarativa/basada en clics. Llamamos a este tipo de equipos "equipos híbridos" y, como hemos estado desarrollando DevOps Center, uno de nuestros objetivos ha sido brindarles una experiencia sólida.

¿Quién está en el equipo?

Al diseñar DevOps Center, nos hemos centrado en algunas personas de usuarios clave para quienes estamos trabajando para ofrecer una sólida experiencia de administración de cambios y versiones de extremo a extremo:

  • DeeDee : una desarrolladora declarativa, o administradora, que utiliza principalmente herramientas de código bajo y basadas en clics para realizar su desarrollo.
  • Pedro: un desarrollador programático que utiliza metodologías más pro-código, incluidos Salesforce CLI y Source Control
  • Romeo: un administrador de versiones, que puede estar utilizando interfaces basadas en clics o interfaces de línea de comandos para realizar implementaciones.

Ejemplos de casos de uso de equipos híbridos

Veamos algunos casos de uso comunes que resaltan cómo estos equipos híbridos pueden unirse mediante el uso de DevOps Center.

Caso de uso n.° 1: DeeDee contribuye con sus cambios a un repositorio de proyecto compartido mediante una interfaz declarativa/basada en IU

Esta es una de las luchas de equipo más comunes de las que escuchamos hoy.

La situación actual:
Una parte del equipo ha adoptado prácticas de desarrollo basadas en fuentes y está utilizando un repositorio de control de fuentes para administrar su fuente de metadatos. Los desarrolladores declarativos del equipo usan conjuntos de cambios para administrar sus cambios. Todos estos cambios, ya sea mediante control de código fuente o conjuntos de cambios, terminan en las mismas organizaciones de prueba y producción.

Desafíos con la situación actual:
Los metadatos administrados por el conjunto de cambios nunca ingresan al repositorio de control de código fuente, ya que el proceso declarativo de los desarrolladores no proporciona una interfaz que les facilite introducir sus cambios en el repositorio. Por lo tanto…

  • El repositorio en realidad no refleja todos los cambios para todo el equipo.
  • Los conflictos son difíciles de manejar
  • Es difícil entender lo que está pasando en el lanzamiento.

Centro DevOps al rescate:
Con DevOps Center, DeeDee puede confirmar sus cambios en el mismo repositorio de control de código fuente que usa el equipo con simples clics. Incluso puede crear una solicitud de incorporación de cambios en GitHub con solo hacer clic en un botón en DevOps Center, indicando a otros en el equipo que su cambio está confirmado y listo para revisión. Cuando Pedro u otra persona de su equipo revisa y aprueba el cambio, se puede marcar como "Listo para promocionar" en DevOps Center, lo que lo hace disponible para su promoción (implementación) por parte de Romeo (o DeeDee, según el proceso de gobierno del equipo) para las organizaciones de prueba compartidas en la canalización.

Beneficios realizados:
DeeDee ahora puede trabajar dentro de DevOps Center mediante clics y sus cambios se administran en el repositorio de control de código fuente centralizado del equipo. Por lo tanto…

  • El repositorio incluye el trabajo de todo el equipo.
  • Los conflictos se pueden identificar antes
  • Hay una mayor visibilidad de los cambios que se realizan en el lanzamiento.
  • El equipo logra una mejor gobernanza y gestión del cambio.

Caso de uso n.º 2: Pedro y DeeDee contribuyen al mismo proyecto, pero Pedro quiere usar la CLI y el IDE, y DeeDee quiere usar una interfaz declarativa basada en clics. Y quieren visibilidad de los cambios de los demás.

Esto es similar al caso de uso n.º 1 desde la perspectiva de DeeDee, pero este caso de uso agrega el escenario en el que Pedro está haciendo su propio desarrollo a través de sus metodologías existentes basadas en CLI e IDE. Con DevOps Center, todos pueden tener visibilidad de lo que está sucediendo con el proyecto y los cambios que se están realizando.

Cómo el modelo de proyecto de DevOps Center facilita la colaboración

El proyecto DevOps Center está asociado con un repositorio en GitHub. Este es el mismo repositorio de proyectos que usa todo el equipo para administrar la fuente de metadatos. El proyecto DevOps Center también contiene una canalización que define las etapas por las que pasan los cambios desde el desarrollo, las pruebas y la producción. Cada una de estas etapas está asociada con una organización de Salesforce, así como con una rama en el repositorio de control de código fuente. DevOps Center también utiliza "elementos de trabajo" como objeto principal para definir los cambios que se realizarán y realizar un seguimiento a lo largo del ciclo de vida. Cada elemento de trabajo tiene una rama de función asociada en el repositorio. Esta rama de funciones la crea automáticamente DevOps Center cuando se inicia el elemento de trabajo y el nombre de la rama coincide con el ID del elemento de trabajo (p. ej., WI-00001).

Por lo tanto, la clave para hacer que este caso de uso funcione es asegurarse de que las ramas con las que trabaja Pedro en el sistema de control de código fuente estén alineadas con las ramas con las que está configurado el proyecto DevOps Center (o viceversa). Los cambios que se realicen en el repositorio de control de código fuente en cualquiera de las ramas que conoce DevOps Center se reflejarán en DevOps Center.

Veamos un flujo de trabajo típico para ver cómo funciona.

1. Empezar a trabajar

Pedro recoge su elemento de trabajo en DevOps Center. Selecciona la opción para "… desarrollar y confirmar mis cambios en la rama de características del elemento de trabajo desde fuera del DevOps Center". Esto pone el elemento de trabajo en el estado "En progreso" Y crea una rama de funciones en el repositorio con un nombre que coincide con el elemento de trabajo. Como alternativa, Pedro podría simplemente crear la rama en el repositorio, pero debe tener el mismo nombre que el elemento de trabajo para que la sincronización funcione correctamente.

2. Realice cambios en IDE y confirme cambios en la rama de características en el repositorio

Ahora Pedro puede hacer sus cambios como quiera. Por ejemplo, podría usar VS Code con extensiones de Salesforce, o el nuevo Code Builder, un IDE basado en web que proporciona las mismas capacidades que VS Code, pero en una interfaz basada en web fácil de configurar. Desprotege la rama de funciones del elemento de trabajo, realiza sus cambios y luego confirma esos cambios en la rama de funciones del elemento de trabajo.


Ahora, si alguien mirara este elemento de trabajo en DevOps Center, vería la confirmación que acaba de hacer Pedro. También mostrará los archivos que formaron parte de la confirmación. ¡Resbaloso!

3. Crear solicitud de extracción

Ahora, cuando Pedro esté listo para crear una solicitud de extracción para iniciar una revisión y fusionar sus cambios en la rama de la siguiente etapa, puede hacerlo directamente desde GitHub, el IDE o la CLI, según lo desee. La solicitud de extracción debe crearse entre la rama de función del elemento de trabajo en la que ha estado confirmando sus cambios y la rama que corresponde a la primera etapa de la canalización. En nuestro ejemplo a continuación, esta es la rama de integración.

Después de que Pedro crea esta solicitud de extracción, sus compañeros de equipo pueden ver en DevOps Center que el elemento de trabajo está "En revisión" y tienen fácil acceso a la solicitud de extracción directamente desde el elemento de trabajo. ¿Qué tal eso para facilitar la colaboración en equipo?

4. Combinar la solicitud de extracción

Una vez que se revisa y aprueba la solicitud de incorporación de cambios, alguien del equipo puede optar por fusionarla directamente desde GitHub.

Ahora, en DevOps Center, el equipo puede ver que los cambios se fusionaron "externamente" o desde fuera de DevOps Center. Y dado que el paso Promoción en DevOps Center realiza tanto la fusión como la implementación, debido a que el elemento de trabajo ahora se ha fusionado, le dice al usuario que los cambios ahora deben implementarse para mantener la rama de integración y la organización sincronizadas entre sí.

5. Completar la promoción del elemento de trabajo

En la versión beta abierta actualmente disponible de DevOps Center, la implementación debe completarse desde DevOps Center. En el marco de tiempo de GA, entregaremos un complemento de CLI que permite que la implementación se realice a través de la CLI y, por lo tanto, desde fuera de DevOps Center, según se desee. Esto permitirá que todo el flujo se realice dentro de DevOps Center, fuera de DevOps Center o mediante una combinación de ambos.

¡Obtenga DevOps Center ahora!

DevOps Center está actualmente disponible en versión beta abierta y se puede habilitar e instalar en cualquier organización de producción con una edición Professional, Enterprise o Unlimited. También está disponible en las organizaciones de zona de juegos de Trailhead y Developer Edition. Para obtener información sobre cómo habilitar, instalar, configurar y usar DevOps Center, consulte:

Para obtener más información, demostraciones en video y para ser parte de la conversación, visite nuestro grupo comunitario Trailblazer de DevOps Center .

¡Vea estas nuevas funciones en acción!

No se olvide de ver la vista previa para desarrolladores de Winter '23 el 22 de septiembre durante Release Readiness Live para ver demostraciones de un subconjunto de estas nuevas y emocionantes funciones. Y si asistes a Dreamforce, ¡ únete a nosotros EN VIVO ! ¡Asegúrese de consultar Learn MOAR Winter '23 for Developers Trailmix y siga el blog esta semana para obtener más información sobre Learn MOAR!

Sobre el Autor

Karen Fidelak es directora sénior de gestión de productos para DevOps Center en Salesforce. Cuando no está trabajando para llevar excelentes productos a la comunidad de desarrolladores de Salesforce, disfruta explorando el aire libre en su hermoso estado natal de Colorado.

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/09/learn-moar-in-winter-23-with-devops-center.html

Categories
Developers Tutoriales de Salesforce

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

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.

Introducción a Apex para desarrolladores de Java | Blog de desarrolladores de Salesforce

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

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

Pruebas

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

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

Límites del gobernador

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

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

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

Diferencias de sintaxis y comportamiento

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

Sintaxis insensible a mayúsculas y minúsculas

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

Colecciones

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

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

Herencia

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

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

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

Modificadores de clase y método

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

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

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

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

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

Procesamiento asíncrono

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

Genéricos y anotaciones

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

Excepciones

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

Acceso a datos y seguridad

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

Lenguajes de consulta de datos

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

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

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

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

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

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

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

Lenguajes de manipulación de datos (DML)

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

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

Comprobaciones de permisos

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

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

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

Espacios de nombres y paquetes

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

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

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

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

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

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

palabras de cierre

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

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

Recursos

Sobre el Autor

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

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/09/an-introduction-to-apex-for-java-developers.html

Categories
Developers Tutoriales de Salesforce

La guía para desarrolladores de Dreamforce 2022 ☁️

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 guía para desarrolladores de Dreamforce 2022 | Blog de desarrolladores de Salesforce

¡Llamando a todos los desarrolladores! ¡Bienvenido de nuevo a Dreamforce! El equipo de relaciones con los desarrolladores está ansioso por compartir lo que le espera en Dreamforce 2022. Todos están trabajando arduamente para brindarle un programa de sesiones y experiencias atractivas, ya sea que asista en persona o lo vea en Salesforce+ . Hemos preparado esta práctica guía para que aproveches al máximo tu experiencia Dreamforce. ¡No puedo esperar a verte allí y celebrar nuestra comunidad!

Fiesta del día 0 del desarrollador

¡Encuéntranos en Developer Galaxy para celebrar los 20 años de Dreamforce entre tus compañeros desarrolladores! Estará en una compañía estelar cuando se unan las superestrellas de los desarrolladores de Salesforce, MuleSoft, Slack y Tableau. Únase a nosotros la noche anterior al inicio de Dreamforce para disfrutar de comidas, bebidas y diversión con la comunidad. Se requerirá prueba de registro de Dreamforce para ingresar.

📆 Marque sus calendarios: 19 de septiembre, 7:00 pm PT @ Temple SF
Haz clic para registrarte en el Dev Day 0

Discurso principal sobre el futuro del desarrollo

La Keynote para desarrolladores de Salesforce debe ser la piedra angular de su experiencia con Dreamforce. La energía, la innovación y las historias de los clientes serán verdaderamente inspiradoras.

Le mostraremos cómo puede utilizar todo el poder de Salesforce Customer 360 para impulsar el impacto en su empresa, en su carrera y en sus comunidades. Verá demostraciones en vivo de las últimas funciones para desarrolladores en acción, aprenderá consejos prácticos de sus compañeros y se irá con información e inspiración para abrir camino con Salesforce.

Si lo va a seguir desde su casa, vea el discurso de apertura completo mientras se transmite en vivo en Salesforce+ . Asegúrese de ver el discurso de apertura en vivo con la interpretación del lenguaje de señas americano (ASL).

🎤 Oradores destacados: Christophe Coenraets, Andy Fawcett, Ananya Jha, Sue Berry, Jeremiah Peoples, Greg Whitworth
📅 Marquen sus calendarios: 20 de septiembre, 1:00 p. m. PT
Haga clic para agregar el Keynote sobre el futuro del desarrollo a su agenda

Mejora de habilidades en la vía del desarrollador

Para 2022, Developer Track tiene una combinación de sesiones de teatro de 20 minutos en Developer Theatre y sesiones de 40 minutos. Aprenderá habilidades y conocimientos importantes tanto de los expertos que crearon los productos como de sus pares en la comunidad que los han dominado.

Espere recibir mejores prácticas, consejos y mucha inspiración de desarrolladores de todo el mundo. ¡Y hay algo para todos, sin importar los temas que te apasionen! Tenemos sesiones para todos los niveles (principiante, intermedio, avanzado) en todas las funciones y temas: Automatización, Salesforce Flow, MuleSoft RPA, Transformación digital, DevOps Center, Salesforce y AWS, Anypoint Code Builder, Slack, Lightning Web Components y más.

📍 Las sesiones de Developer Theatre serán en Developer Grove en el primer piso de Moscone West. Las sesiones de trabajo de Developer Track se llevarán a cabo en el segundo piso de Moscone West. Asegúrese de revisar su agenda para conocer las ubicaciones exactas de las habitaciones. ¡Y por primera vez, estaremos transmitiendo algunas sesiones de seguimiento de desarrolladores en Salesforce+! Mírelo en vivo , mírelo con interpretación ASL o mire la repetición más tarde .

Algunas sesiones imperdibles

Para encontrar estas sesiones en el catálogo de Dreamforce , seleccione "Funciones" en la navegación de la izquierda y marque "Desarrollador" para ver todas las sesiones etiquetadas para desarrolladores.

Desarrolle API más rápido con Anypoint Code Builder
Ponentes: Simone Geib y Rohan Vettiankal
Qué esperar: Obtenga información sobre la próxima versión beta abierta de Anypoint Code Builder, el IDE de próxima generación de MuleSoft para diseñar, desarrollar e implementar API e integraciones.
Pulsa para añadir esta sesión a tu agenda

Developer Luminary: la nueva API Pub/Sub
Ponente: Tyson Read
Qué esperar: El Pub/Sub API es la última forma de crear integraciones basadas en eventos con Salesforce. Venga a conocer las nuevas características que esta API tiene para ofrecer y cómo Salesforce está construyendo para escalar. Inmediatamente después, habrá una sesión de preguntas y respuestas de 20 minutos dirigida por Tyson en Developer Campfire.
Pulsa para añadir esta sesión a tu agenda

Lo que necesita saber acerca de las pruebas traseras, frontales y de extremo a extremo
Ponente: Philippe Özil
Qué esperar: aprenda cómo pasar de pruebas de back-end con Apex a pruebas de front-end con Jest y Lightning Web Components, y cubriremos las pruebas de extremo a extremo (E2E) con el modelo de automatización de pruebas de interfaz de usuario (UI Testing Automation Model, UTAM). .
Pulsa para añadir esta sesión a tu agenda

Primeros pasos con Salesforce DevOps
Ponentes: Gilson Canario y Nicolás Piccolo
Qué esperar: ¿Está buscando comenzar a adoptar prácticas de DevOps pero no está seguro de cómo comenzar? Venga a escuchar cómo puede comenzar a tomar medidas hoy para iniciarse en un viaje de Salesforce DevOps.
Pulsa para añadir esta sesión a tu agenda

Trabajar con CORS y CSP para llamar a las API desde LWC
Ponentes: Aditya Naag Topalli
Qué esperar: en esta sesión, exploraremos el motivo detrás de los errores comunes de la API y cómo solucionarlos. Únase a esta sesión para ver en profundidad cómo utilizar con éxito estas técnicas de integración.
Pulsa para añadir esta sesión a tu agenda

Salesforce en funciones de Salesforce
Ponentes: Christopher Marino y Ben Gray
Qué esperar: aprenda cómo Salesforce está usando Functions internamente para identificar duplicaciones de objetos y reducir la redundancia de datos en más de 100 000 cuentas todos los días.
Pulsa para añadir esta sesión a tu agenda

Desbloquee la productividad del desarrollador con herramientas modernas
Ponentes: Mohith Shrivastava
Qué esperar: esta sesión le mostrará cómo usar Code Builder y DevOps Center para crear e implementar rápidamente aplicaciones de Salesforce mientras mantiene el control y la gestión de cambios.
Pulsa para añadir esta sesión a tu agenda

Pregúntame cualquier cosa con los desarrolladores de Salesforce
Oradores: Peter Chittum, Christie Fidura, Gursev Singh Kalra y Ben Sklar
Esta sesión será el mejor lugar para obtener sus respuestas en Dreamforce '22, de nuestros mejores expertos. Únase a esta sesión de teatro con un panel de defensores de desarrolladores de Salesforce que responderán sus preguntas en vivo.
Pulsa para añadir esta sesión a tu agenda

Qué esperar en Developer Grove

Developer Grove es tu hogar para la comunidad de desarrolladores durante Dreamforce.

Únase a nosotros para ponerse manos a la obra con los Mini Hacks. Cree LWC con bibliotecas JS externas. Cree un complemento personalizado para la CLI unificada. Integre con la sede digital de Slack. Cree una visualización de datos de Tableau personalizada e insértela en Salesforce. Y este año te animamos a hackear con un compañero. Como siempre para Mini Hacks, tendremos expertos en productos disponibles para ayudarlo a completar con éxito estos proyectos prácticos, divertidos y del tamaño de un bocado.

Developer Campfire presenta charlas interactivas cada 30 minutos. Aprenderá sobre importantes proyectos de código abierto y herramientas de desarrollo para Salesforce Platform, MuleSoft, Slack y Tableau. También podrá profundizar más con las sesiones extendidas de preguntas y respuestas sobre los estándares web, los depuradores de Apex, la CLI de Salesforce y la API Pub/Sub.

Los miembros del equipo de relaciones con desarrolladores estarán en Developer Grove durante la duración de Dreamforce, así que visítanos para decir "Hola". ¡Nos encantaría verte!

Noche de juegos para desarrolladores

¿Eres más inteligente que un promotor de desarrolladores? Ven a probar tus conocimientos en un divertido juego de Dev Trivia y compite por la oportunidad de ganar el derecho a fanfarronear y fantásticos premios.

📅 Marque sus calendarios: 20 de septiembre a las 5:00 p. m. PT en el Developer Theatre
Haz clic para agregar Dev Game Night a tu agenda

Preparación para el lanzamiento de Winter '23 en vivo: ¡Vista previa del desarrollador!

Release Readiness Live es en persona en Dreamforce '22! Conozca las funciones principales para desarrolladores de la versión Winter '23. Nos sumergiremos en las nuevas API de GraphQL, la creación de acciones externas para compromisos de cuenta con Apex y las próximas actualizaciones de Salesforce Flow, incluida la incorporación de flujos de pantalla en LWC. A esto le seguirá una sesión de preguntas y respuestas en vivo donde podrá obtener respuestas a todas sus preguntas.

🎤 Oradores destacados: Danielle Larregui, Rene Winkelmeyer, Suvda Myagmar, Sam Reynard y Christopher Cornett
📅 Marquen sus calendarios: 22 de septiembre, 11:00 am PT
Pulsa para añadir RRL a tu agenda

Main Show Keynote y True to the Core

Dreamforce comenzará oficialmente el martes 20 de septiembre con la presentación principal de Dreamforce con los codirectores ejecutivos Marc Benioff y Bret Taylor, ¡junto con invitados especiales!

¡Y el jueves 22 de septiembre, True to the Core regresa para Dreamforce 2022! Únase al cofundador y CTO Parker Harris, al director de productos David Schmaier y a los líderes de productos en un foro de preguntas y respuestas en vivo sobre nuestra hoja de ruta de productos.

Si nunca ha asistido, True to the Core es una excelente sesión para que los desarrolladores hagan preguntas y escuchen las respuestas de nuestros gerentes de producto. Una cosa que seguirá siendo "central" para True to the Core es que habrá muchas preguntas.

📅 Marquen sus calendarios: 20 de septiembre, 10:00 am PT
Pulsa para añadir la Keynote a tu agenda

📆 Marquen sus calendarios: 22 de septiembre a las 12:00 p. m. PT
Haga clic para agregar True to the Core a su agenda

Obtenga aún más contenido en Salesforce+

¡Este año, Salesforce+ tendrá una experiencia de transmisión EN VIVO! Así es, durante los tres días, habrá dos canales, 72 horas de transmisión en vivo y adquisiciones globales.

Además de la experiencia en vivo, este año, estarán disponibles más de 200 sesiones a pedido repletas de contenido y momentos exclusivos. ¿Entusiasmado? ¡Usted debería ser! Mire el contenido de desarrollo de Dreamforce en vivo , mírelo con interpretación ASL o mire la repetición más tarde .

¡Prepárate ahora!

¿Que estas esperando? ¡Estos son los pasos que puede seguir hoy para prepararse para Dreamforce '22!

  1. Empiece a pensar sobre qué productos o funciones desea obtener más información. ¿Qué proyectos planea emprender el próximo año que podrían beneficiarse de los consejos y las mejores prácticas?
  2. ¡Planea, planea, planea! Eche un vistazo a Agenda Builder, lea sobre todas las sesiones disponibles y comience a planificar su calendario de Dreamforce '22.
  3. Asegúrese de agregar el discurso principal sobre el futuro del desarrollo a su agenda.
  4. Conéctese con sus pares en el grupo de la comunidad Developer Trailblazer .
  5. Si no asistirá en persona, asegúrese de registrarse para la experiencia Salesforce+ .
  6. Siga a @SalesforceDevs en Twitter y LinkedIn para obtener más actualizaciones.

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/09/the-developers-guide-to-dreamforce-2022.html

Categories
Developers

Establecer seguridad a nivel de campo para un campo en conjuntos de permisos durante la creación de campos

Última actualización el 19 de agosto de 2022 por Rakesh Gupta

Gran idea o pregunta duradera:

  • ¿Cómo configurar la seguridad a nivel de campo para un campo en conjuntos de permisos en lugar de perfiles durante la creación del campo?

Martin Jones trabaja como administrador de sistemas en Gurukul on Cloud (GoC) . Martin está trabajando actualmente en un proyecto de implementación de servicio de campo.

Tiene el requisito de crear un campo personalizado Fuera del negocio (Lista de selección, Sí/No) en el objeto de la cuenta y configurar el permiso para los siguientes conjuntos de permisos como se menciona en la tabla a continuación.

Seguridad a nivel de campo para el conjunto de permisos Acceso de lectura Editar acceso
Permisos de administrador de servicio de campo
Permisos de agente de servicio de campo
Permisos de despachador de la comunidad de Field Service No
Permisos de despachador de servicio de campo
No
Integración de servicios de campo
Permisos de recursos de Field Service No
Permisos de autoservicio de Field Service No
Ver toda la cuenta No

Enfoque de Campeón de Automatización (I-do):

Una de las cosas que me gustan de Salesforce es escuchar a sus clientes y mejorar los productos en función de sus comentarios. Los formularios dinámicos, la lista relacionada dinámica y los campos de direcciones personalizadas son algunos ejemplos.

Mientras revisaba las notas de la versión Winter'23 , me topé con una función: establecer la seguridad a nivel de campo para un campo en conjuntos de permisos en lugar de perfiles durante la creación de campos (Beta ) ; Lo encontré muy útil sobre muchas otras características.

Tomemos unos minutos de pausa aquí para entender el problema primero.

En estos días, estamos implementando la seguridad de las aplicaciones solo a través del conjunto de permisos y mantenemos la cantidad de perfiles al mínimo. También usamos conjuntos de permisos para otorgar acceso a aplicaciones, objetos y campos.

El problema surge cuando empezamos a crear nuevos campos. En el paso 3 , Salesforce le permite asignar permisos de campo a los perfiles.

Pero, en muchos escenarios, queremos usar conjuntos de permisos para asignar acceso a campos. En tales casos, debe abrir cada conjunto de permisos y otorgar permisos de campo uno por uno. Eso es demasiada inversión de tiempo.

¿Qué sucede si Salesforce le permite establecer permisos de campo para un campo en conjuntos de permisos en lugar de un perfil?

En este artículo, explicaré paso a paso las instrucciones para configurar la seguridad a nivel de campo para un campo en conjuntos de permisos en lugar de perfiles durante la creación de campos.

Práctica guiada (nosotros hacemos):

Después del lanzamiento de winter'23 , cuando crea un campo en un objeto, puede seguir las prácticas recomendadas y establecer la seguridad a nivel de campo para un campo en conjuntos de permisos en lugar de perfiles. Y en lugar de otorgar acceso manualmente a un campo en cada conjunto de permisos, puede configurar la seguridad a nivel de campo en los conjuntos de permisos durante la creación del campo. Esta función también está disponible cuando configura la seguridad a nivel de campo en un campo o cambia el tipo de campo en un campo.

  1. Habilite la seguridad a nivel de campo para los conjuntos de permisos durante la creación de campos (beta) en la configuración de administración de usuarios.
  2. Crear un campo personalizado en el objeto de cuenta
    1. Haga clic en Configuración .
    2. En el Administrador de objetos, escriba Cuenta .
    3. Seleccione Campos y relaciones , luego haga clic en Nuevo .
    4. Seleccione Lista de selección como Tipo de datos, luego haga clic en Siguiente.
    5. Ingrese Etiqueta de campo y haga clic en la tecla de tabulación, se completará el Nombre de campo .
      1. Ingrese los detalles:
        1. Valores seleccione Ingrese valores, con cada valor separado por una nueva línea
          1. No
        2. Como práctica recomendada, introduzca siempre una descripción y un texto de ayuda.
        3. Haga clic en el botón Siguiente .
    6. Establezca la seguridad a nivel de campo en los conjuntos de permisos .
    7. Agregue este campo a Diseño de página .
    8. Haga clic en Guardar .

Cosas para recordar

  1. La lista incluye conjuntos de permisos que tienen acceso de creación, lectura, edición o eliminación en el objeto del campo. Si ningún conjunto de permisos tiene ese acceso en el objeto del campo, la lista contiene todos los conjuntos de permisos.
  2. Si desea asignar seguridad a nivel de campo a los perfiles, desactive la Seguridad a nivel de campo para conjuntos de permisos durante la creación de campos (beta) en Configuración de administración de usuarios.

Evaluación formativa:

¡Quiero saber de ti!

¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://automationchampion.com/2022/08/19/set-field-level-security-for-a-field-on-permission-sets-during-field-creation-2/

Categories
Developers Tutoriales de Salesforce Uncategorized

Las funciones de Salesforce están generalmente disponibles ☁️

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.

Hoy, nos complace anunciar la disponibilidad general de las funciones de Sal esforce. Con Salesforce Functions, los clientes pueden ofrecer experiencias escalables al ampliar sus datos y flujos de trabajo con el poder de la computación elástica y la flexibilidad del lenguaje abierto. Las funciones empoderan a los equipos y aceleran la productividad de los desarrolladores al facilitarles la adopción de técnicas modernas y las herramientas de su elección.

Como desarrollador de Salesforce, desea centrarse en llevar su solución al mercado de forma rápida y sencilla sin preocuparse por el aprovisionamiento de infraestructura o la gestión de nuevas aplicaciones. Pero a veces, tenía que salir de la plataforma para obtener la potencia informática y la escalabilidad que necesitaba. A partir de hoy, con Salesforce Functions, ahora hay otra forma.

Con Functions, los desarrolladores de Salesforce ahora pueden ejecutar sus programas en un entorno seguro y dedicado que escala elásticamente para satisfacer la demanda. Las funciones se pueden escribir en lenguajes de programación estándar como JavaScript / TypeScript (usando Node.js) y Java, y tienen acceso al vasto universo de código fuente abierto y bibliotecas para acelerar el desarrollo.

Las funciones permiten a los desarrolladores concentrarse en el problema que necesitan resolver y no preocuparse por el costo o la complejidad operativa de ejecutar sus propias aplicaciones. No hay necesidad de servicios externos, aplicaciones conectadas, claves de cliente, certificados y autorización, o el costo operativo de la infraestructura y la administración de aplicaciones. Las funciones se encargan de todo esto para el desarrollador y permiten que sus programas se ejecuten con la seguridad y el cumplimiento que confían en Salesforce.

Invocación de función

Las funciones de Salesforce se pueden invocar desde Apex ejecutándose en cualquier lugar de la plataforma. Esto significa que las funciones se pueden invocar desde Flows, Process Builder, Lightning Web Components y Apex Triggers, tanto para trabajos por lotes como para aplicaciones interactivas, lo que brinda todo el poder del software personalizado a todos los que crean en Salesforce.

Arquitectura de invocación de funciones

Productividad de código bajo

Ahora, el desarrollo de código bajo es más productivo porque los desarrolladores pueden crear aplicaciones ensamblando componentes creados con funciones sin sacrificar la seguridad o el rendimiento. Y hoy, con Functions GA, los clientes ahora están desarrollando funciones que serán invocadas desde Flows usando Apex Actions, dando a sus Flow Builders un poder que nunca antes habían tenido.

Nuevas funciones listas para producción

Espacios nuevos

Terminamos la versión Beta de Functions en junio y agregamos algunas características importantes que permiten implementarlas en organizaciones de producción de forma segura. Primero, con Functions GA, sus funciones se pueden desarrollar y probar en su propio "Espacio" de Funciones aislado. Esto permite que el desarrollo, la integración y las pruebas se realicen por separado de las organizaciones de producción sin ningún impacto o interferencia.

Con Functions, tendrá acceso a dos espacios completamente independientes: uno para pruebas y otro para implementaciones de producción. Test Space está listo de inmediato para que los desarrolladores implementen funciones en sus organizaciones desde cero o sandbox. Cuando terminan con el desarrollo, las implementaciones de funciones pueden apuntar al espacio de producción para las operaciones de la organización de producción en vivo.

Habilite las funciones de Salesforce desde la página de configuración

Los desarrolladores pueden compartir el espacio de prueba para el desarrollo de funciones organizativas de prueba y sandbox, así como para la puesta en escena e integración de lanzamientos completos. El desarrollo impulsado por la fuente permite implementar el mismo repositorio de la fuente en el espacio de producción, que está separado y aislado de todas las actividades de desarrollo, prueba e integración.

Nuevos permisos

La implementación en organizaciones de producción debe administrarse con cuidado, y Functions incluye dos nuevos permisos que se pueden usar para administrar el acceso a los espacios de prueba y producción.

  • Compute Access : permite el acceso a las funciones de Functions, incluida la implementación en Test Space
  • Compute Production Access : permite el acceso al espacio de producción

Juntos, estos permisos le permiten crear y administrar personas de desarrollador y administrador que otorgan solo los derechos de acceso que necesitan para desarrollar y / o implementar funciones en organizaciones específicas.
Página de configuración de conjuntos de permisos

Por ejemplo, es posible que desee considerar la posibilidad de crear Functions Developers y Functions Administrator (o actualizar los perfiles existentes o los conjuntos de permisos que tenga). Estos nuevos permisos le permiten distinguir entre desarrolladores que pueden programar funciones y administradores que pueden implementar funciones en el espacio de producción pero que no tienen permisos completos de administrador del sistema de Salesforce.

Nueva experiencia de desarrollador

En Dreamforce '21, dimos el siguiente paso hacia la unificación de CLI para el desarrollo en todo Salesforce. Salesforce Functions es el primer producto que utiliza la estructura de comando y la cli sf recién lanzada , que permite a los desarrolladores crear, probar e implementar en Salesforce desde una experiencia de línea de comandos unificada.

Para Functions, esto significa una experiencia de implementación y desarrollo fluida que abarca el desarrollo, la prueba y la implementación. Con un solo comando, sf deploy functions , puede enviar la fuente de su función al servicio de compilación de Functions, donde se compilará y comenzará a ejecutarse en un espacio, esperando una invocación de su organización.

Finalmente, tenemos nuestro increíble complemento Visual Studio Code para funciones, ¡lo que hace que sea muy fácil comenzar!

Cree una función de Java con Visual Studio Code

Sencillo, seguro, seguro y sólido

Las funciones incluyen un SDK que alivia a los desarrolladores de la carga de autorizar el acceso a su organización y administrar la conexión y el contexto de la organización en su código. Esto, junto con la compatibilidad con conjuntos de permisos para el acceso restringido a los datos de Salesforce, proporciona una experiencia de desarrollador simple, segura y sin problemas para acceder a los datos de la organización.

Empiece hoy

Juntas, estas nuevas funciones y el SDK hacen de Salesforce Functions la forma más sencilla y segura de ampliar el poder de su organización. Puede obtener más información sobre las funciones y cómo comenzar su desarrollo visitando la documentación del desarrollador . También estamos planeando una prueba de Funciones de registro abierto por tiempo limitado que estará disponible en breve. Estén atentos a las actualizaciones.

Sobre el Autor

Chris Marino dirige la gestión de productos para los servicios informáticos elásticos de la plataforma Salesforce. Antes de este puesto, Chris dirigió la gestión de productos para las ofertas de Heroku Compute y Private Spaces. Antes de Salesforce, Chris estuvo en Cisco y en varias otras empresas de redes desarrollando soluciones para el enrutamiento y la gestión del tráfico de la red.

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/10/salesforce-functions-is-generally-available.html

Categories
Developers Tutoriales de Salesforce

Controle el acceso a registros confidenciales con reglas de restricción (ahora en versión Beta) ☁️

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.

En Summer ’21, le presentamos una forma completamente nueva de administrar el control de acceso de su organización. Presentamos reglas de restricción, una función de uso compartido fácil de administrar que le permite otorgar acceso a los registros de una manera segura y granular. Simplemente elija qué usuarios deben ver qué subconjunto de registros , ¡y listo!

Sin reglas de restricción, los usuarios que tienen acceso a una cuenta pueden ver sus contratos, tareas y eventos, incluso cuando el valor predeterminado de toda la organización está configurado como Privado. Para los objetos personalizados, los usuarios pueden ver todos sus registros secundarios. Las reglas de restricción le permiten definir qué usuarios ven qué registros en Lightning Experience para objetos, contratos, tareas y eventos personalizados y configurar el acceso verdaderamente “Privado” para estos objetos. La creación, edición y eliminación de reglas de restricción solo están disponibles a través de las API de herramientas y metadatos.

¿Qué son las reglas de restricción?

Las reglas de restricción permiten que ciertos usuarios tengan acceso solo a registros específicos. Las reglas de restricción impiden que los usuarios accedan a registros que pueden contener datos confidenciales. También se pueden utilizar para ayudar a los usuarios a ver lo que necesitan para su trabajo diario.

Por ejemplo, digamos que su empleada, Sally, puede ver actualmente cuatro contratos de varios tipos de registros en un informe.


Pero para el papel de Sally, solo necesita ver los contratos internos. El acceso de Sally a otros tipos de registros de contratos es un problema de seguridad. Además, ralentiza la productividad de Sally ver contratos que no están relacionados con su trabajo.

¿La solución? ¡Reglas de restricción! Creamos la siguiente regla de restricción para que los usuarios en el rol de Sally vean solo los contratos internos. Establecemos userCriteria , o los usuarios a los que se aplica la regla, al ID de rol de Sally. Establecemos recordFilter , o qué registros se muestran a estos usuarios, a contratos con el tipo de registro «Interno».

 { "FullName": "restriction_rule_internal_contracts", "Metadatos": { "activo": verdadero, "description": "Una regla de restricción que permite a los usuarios en el rol ??? ver solo los contratos internos.", "forcementType ":" Restringir ", "masterLabel": "Contratos internos", "recordFilter": "RecordType = 'Interno'", "targetEntity": "Contrato", "userCriteria": "$ User.UserRoleId = '005xxxxxxxxxxx1'", "versión 1 } }

Y aquí está nuestro resultado. Ahora Sally solo ve los contratos internos necesarios para su papel en este informe.

En Lightning Experience, las reglas de restricción se aplican a todas estas funciones:

  • Enlaces
  • Vistas de lista
  • Búsquedas
  • Listas relacionadas
  • Informes
  • Buscar
  • SOQL
  • SOSL

¿Cómo creo reglas de restricción?

Puede crear reglas de restricción utilizando el objeto de herramientas RestrictionRule o el tipo de metadatos RestrictionRule . Aquí hay una regla de restricción creada usando la API de herramientas que permite a los usuarios con el perfil especificado ver solo los registros de tareas que poseen.

 { "FullName": "restriction_rule_tasks_you_own", "Metadatos": { "activo": verdadero, "description": "Una regla de restricción que permite a los usuarios de un perfil específico ver solo las tareas de su propiedad", "forcementType ":" Restringir ", "masterLabel": "Tareas que posee", "recordFilter": "OwnerId = $ User.Id", "targetEntity": "Tarea", "userCriteria": "$ User.ProfileId = '005xxxxxxxxxxx2'", "versión 1 }
}

Todavía no hay una interfaz de usuario de administrador en la configuración para las reglas de restricción, ¡pero estad atentos!

¿Cómo afectan las reglas de restricción a otras configuraciones de uso compartido?

Los usuarios obtienen acceso a los registros según los valores predeterminados de su organización y otros mecanismos de uso compartido, como las reglas de uso compartido o la gestión del territorio empresarial.

Cuando se aplica una regla de restricción a un usuario, los datos a los que tienen acceso de lectura a través de su configuración de uso compartido se limitan a solo registros que coinciden con recordFilter . Este comportamiento es similar a cómo puede filtrar los resultados en una vista de lista o un informe, excepto que es permanente. La cantidad de registros visibles para el usuario puede variar mucho según el valor que establezca en recordFilter.

Conclusión

Si tiene usuarios que solo deberían tener acceso a un subconjunto específico de registros, las reglas de restricción brindan otra capa de seguridad que puede superponer a los valores predeterminados existentes de toda la organización, las reglas de uso compartido y otras configuraciones. Las reglas de restricción también le permiten configurar su acceso para que los objetos, contratos, tareas y eventos personalizados sean completamente “privados”, incluso para usuarios con acceso a cuentas relacionadas, lo que anteriormente no era posible.

Si está interesado, comuníquese con el servicio de atención al cliente de Salesforce para probar esta función beta por sí mismo. Para obtener más información, consulte la Guía para desarrolladores de reglas de restricción (Beta) . Y si tiene alguna pregunta o comentario, publíquelo en la Comunidad Trailblazer de Reglas de restricción .

Sobre los autores

Larry Tung es el director de producto del equipo Record Access Experience, donde trabaja en la próxima generación de funciones para compartir.

Dana Holloway es redactora técnica senior del equipo Record Access Experience.

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/05/control-access-to-sensitive-records-with-restriction-rules-now-in-beta.html