Vamos a sumergirnos en cómo DevOps Center cambiará la forma en que sus equipos de desarrollo gestionan los cambios.
The post Cómo empezar con el Centro de DevOps appeared first on Blog de desarrolladores de Salesforce.
Explore un resumen de TrailblazerDX 2024, con lo más destacado de Einstein 1 Studio, Data Cloud y más funciones de IA generativa.
The post Recapitulación de desarrolladores de TrailblazerDX ’24 appeared first on Blog de desarrolladores de Salesforce.
En nuestra serie de preguntas y respuestas «Engineering Energizers», exploramos las extraordinarias trayectorias de líderes en ingeniería que han realizado importantes contribuciones en sus respectivos campos. Hoy, nos sumergimos en el viaje técnico de Evangelina Martínez Ruiz Moreno, Directora Senior de Salesforce, que encabezó el desarrollo del nuevo Anypoint Flex Gateway de MuleSoft. Sigue leyendo para explorar cómo […]
El post Del concepto a la realidad: Developing MuleSoft’s New Flex Gateway API Management Solution appeared first on Blog de ingeniería de Salesforce.
Seguir leyendo
Revisa las respuestas a la Encuesta sobre el estado de LWC 2023 y, a continuación, completa la encuesta 2024, que se llevará a cabo hasta finales de marzo de 2024.
Participa en la Encuesta sobre el estado de LWC 2024
The post Las principales mejoras que los desarrolladores desean ver en LWC: ¡hágase oír hoy mismo! appeared first on Blog de desarrolladores de Salesforce.
2023 fue un gran año para los desarrolladores de Salesforce. Hubo un montón de nuevas funciones interesantes, grandes mejoras en cosas como Lightning Web Components y, por supuesto, un montón de nuevas herramientas y capacidades que aprovechan la Inteligencia Artificial. Todos los años, en enero, celebramos los mejores contenidos destacados del año anterior y se los traemos […]
The post Los Codeys – Celebrando el contenido más destacado de 2023 appeared first on Blog de desarrolladores de Salesforce.
Los Codeys celebran el contenido más destacado de 2023
Por Krishna Pandey y Scott Nyberg. En nuestra serie de preguntas y respuestas «Engineering Energizers», examinamos las trayectorias profesionales que han formado a los líderes de ingeniería de Salesforce. Conozca a Krishna Pandey, Director de ingeniería de seguridad de Salesforce. Con sede en Bangalore (India), su equipo de tecnología de seguridad de aplicaciones (AST) impulsa el programa de seguridad del código fuente de Salesforce, encargado de utilizar la IA para detectar y […]
The post El poder de la IA: reforzar la seguridad de las aplicaciones eliminando secretos en el código appeared first on Blog de ingeniería de Salesforce.
Seguir leyendo
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.
…
Tuve excelentes conversaciones con clientes y socios en Connections este año, así como a través de la comunidad Trailblazer de MC Account Engagement , con respecto a las acciones externas de Account Engagement . Seguía surgiendo una pregunta: "¿Cómo empiezo con las acciones externas?" En esta publicación, aprenderá qué son las acciones externas, cómo configurarlas y cómo probarlas. Además, sintonice una próxima sesión de codeLive el 20 de julio a las 10 a. m. PT , donde realizaré una demostración de codificación en vivo para mostrarle cómo crear una acción externa y responder sus preguntas.
Las acciones externas son una parte clave deMarketing App Extensions , ya que proporcionan una forma de desencadenar una acción en un sistema externo. El otro componente es Actividades externas, que proporciona una forma de activar la automatización de la participación de la cuenta en función de un evento de participación que ocurre en un sistema externo. Piense en ello como las dos caras de una moneda, las acciones se activan, las actividades se activan. Combinadas, forman una aplicación de extensibilidad de automatización para un servicio, por lo que puede tener una extensión de aplicación de marketing por SMS, por ejemplo.
Por este motivo, las acciones externas se empaquetan en una extensión de aplicación de marketing. En el momento de escribir este artículo, las actividades externas aún no se pueden empaquetar, pero eventualmente también se empaquetarán en la extensión de la aplicación de marketing.
Si desea conectar una aplicación de terceros para automatizar la ejecución de una acción de prospecto en ese sistema, entonces esta es definitivamente la función para usted. En esta publicación, profundizaremos en el lado de la acción externa de las extensiones de aplicaciones de marketing.
Bueno, si me preguntan, ¡diría absolutamente todo! Puede que estés pensando: “¡Claro, todo el mundo dice eso!”. Sin embargo, las posibilidades que desbloquean las acciones externas son realmente amplias. Si alguna vez ha dicho: "Me gustaría que cuando un prospecto llegue a este paso, yo pudiera <insertar deseo aquí>", entonces deseaba una acción externa.
Puede usar una acción externa para registrarse en un seminario web de Zoom desde Account Engagement (consulte el ejemplo en GitHub ). También puede usar una acción externa para enviar un mensaje SMS a través de Twilio, que presentamos en una publicación de blog anterior . Incluso puedes usar acciones externas con webhooks; Usé la función de captura de webhook de Zapier para crear una acción externa que usaba un cliente potencial como desencadenante de un Zap.
Una acción externa consta de una acción invocable de Apex, metadatos de la extensión de la aplicación de marketing, metadatos de una acción externa y una forma de gestionar la autenticación. Los metadatos para las extensiones de la aplicación de marketing y las actividades externas conectan la acción invocable con la participación de la cuenta. Los componentes que se usarán para la autenticación pueden variar según el tipo de autenticación que admita el servicio. Como OAUTH 2.0 es bastante común, el componente que uso más es un proveedor de autorización y Credenciales con nombre . Las credenciales con nombre también facilitan la administración de la autenticación en mi código, y el sistema hace la mayor parte del trabajo.
Con una gran flexibilidad viene la complejidad, por lo que necesitará algunas habilidades en ciertas áreas para construir con éxito una acción externa. Los siguientes son temas clave de los que necesitará una comprensión básica antes de abordar su propia acción externa.
Comprender el ciclo de vida del desarrollo de Salesforce es muy importante para tener éxito en general. Recomiendo aprender Visual Studio y el proceso de implementación de la CLI. No se necesita maestría, solo lo básico para poder empezar. Trailhead ofrece una ruta para ayudarlo a configurar su espacio de trabajo .
El patrón del que hablamos en este artículo se basa en las API REST JSON. Para comprender lo que es posible y recopilar las entradas pertinentes para una acción externa, debe poder leer una especificación API. Consulte las especificaciones de la API de Account Engagement y Twilio .
Apex Invocable Actions es mi forma preferida de codificar mis acciones externas, ya que me permite la mayor flexibilidad y control. Recomendaría, como mínimo, familiarizarse con la compilación y la implementación de código Apex mediante el proyecto Quick Start: Apex de Trailhead. Para obtener más información, encontré útil el trailmix de Apex Basics . No necesita convertirse en un experto, pero al menos debe estar lo suficientemente informado como para poder leer el código de la aplicación de referencia .
No necesita conocer Salesforce Flow para aprender Acciones externas. Sin embargo, es una herramienta de prueba muy poderosa para sus acciones externas, lo que facilita la creación de una interfaz de usuario para controlar las entradas durante la prueba. Si está familiarizado con Engagement Studio, Flow será bastante fácil ya que tiene muchos de los mismos conceptos. Utilicé la ruta Crear flujos con Flow Builder para ponerme al día. Otro beneficio de aprender Salesforce Flow es que abre la puerta a la creación de todo tipo de automatización de procesos comerciales.
Es importante configurar sus entornos de desarrollador y contar con las herramientas adecuadas antes de comenzar con las acciones externas. Yo uso las siguientes herramientas.
Si bien puede codificar acciones externas de muchas maneras, existe un patrón básico que recomiendo al realizar llamadas a la API REST.
Las dos etiquetas que debe recordar son InvocableVariable , que define las entradas y salidas de la acción invocable, e InvocableMethod , que es el método a llamar al ejecutar la acción invocable. Puede ver cómo se aplican en el siguiente código de ejemplo.
Normalmente creo dos clases, una para la entrada y otra para la solicitud de API. Separar mi código en dos clases facilita jsonificar la carga útil. Mi clase de entrada contiene todos los campos de variables invocables que la acción invocable necesita en la entrada. Mi solicitud de API contiene los campos de la solicitud JSON.
InvocableMethod construirá la carga útil a partir de la entrada, la convertirá a JSON y luego la agregará a la solicitud HTTP. A continuación, configura el resto de la solicitud HTTP agregando la URL, los encabezados y el método. Finalmente, realiza la llamada a la API y comprueba si el resultado es correcto o, de lo contrario, genera un error útil para diagnosticar un problema.
Consideración importante: el marco de acción externa espera que se devuelva un error si hay una falla en lugar de detectar el error y luego devolver el éxito. Si se devuelve un error, se informará en la tabla de errores.
De vez en cuando, mientras crea una acción externa, encontrará errores. Cuanto más pueda probar sobre la marcha, más fácil será descubrir dónde radica el problema. Es por eso que recomiendo agregar un paso de prueba para probar en Salesforce Flow antes de probar en Engagement Studio. Elimina la configuración de la acción externa de la imagen, por lo que si la verifica aquí, pero no funciona en Engagement Studio, sabrá que el problema radica en la configuración de la acción externa.
Las pruebas lo ayudan a identificar errores, pero determinar la causa raíz y corregirlos es otra cosa. A continuación se presentan algunas de las técnicas que utilizo para diagnosticar las causas fundamentales.
SUGERENCIA: si tiene una cuenta de Gmail, puede usar un "+" para crear varios registros con su dirección de correo electrónico. Por ejemplo, puedo registrar tanto "ejemplo@ejemplo.com" como "ejemplo+usuario2@ejemplo.com" como prospecto, y cualquier correo enviado a esas direcciones iría al buzón de correo de ejemplo@ejemplo.com. Por ejemplo, usé esto para probar el ejemplo de registro de Zoom porque no quería que el correo electrónico registrado rebotara.
Los errores van a suceder, así es la vida. Me he encontrado con algunos escenarios que me han hecho casi tirarme de los pelos.
El primero es garantizar que la acción exterior sea activa. Si la acción no aparece en Engagement Studio, es probable que esta sea la causa. Recuerde, debe activar tanto la extensión de la aplicación de marketing como la acción externa, además de asignarla a esa unidad comercial.
El siguiente es asegurarse de que su clase de Apex esté activa. La mayoría de las veces ya estará marcado como activo, es el estado predeterminado cuando creas una nueva clase. Es exactamente por eso que es fácil pasarlo por alto.
Otro es buscar extensiones de aplicaciones de marketing al empaquetar. No puedo decirte cuántas veces busco acciones externas, solo para tener un momento de confusión antes de recordar.
Finalmente, si su acción externa no funciona, pero no ve errores, verifique que la acción invocable fue diseñada para generar un error en caso de falla.
Lo anterior no es de ninguna manera exhaustivo, y es probable que encuentre sus propias alegrías. Sin embargo, recomiendo compartirlos con la comunidad si encuentra algunos buenos.
Ahora sabe casi todo lo que hago sobre las acciones externas, desde cómo funciona la función hasta los errores comunes. Recuerde que Acciones externas es su herramienta siempre que se encuentre diciendo: "Me gustaría hacer algo cuando el cliente potencial haga esto", y lo ayudará a automatizar esa acción.
Entonces, configure su entorno de desarrollador, revise la aplicación de referencia y comience a construir su acción externa hoy. El 20 de julio a las 10 a. m. (hora del Pacífico) , realizaremos una sesión de CodeLive en nuestro canal de YouTube para desarrolladores de Salesforce , así que únase y síganos mientras construimos una extensión de la aplicación de marketing de Twilio.
Christopher Cornett es gerente sénior de productos en Salesforce, responsable de la experiencia del desarrollador de Account Engagement. Ha trabajado para Salesforce durante más de cuatro años y tiene más de 13 años de experiencia en gestión de productos, trabajando principalmente en plataformas que van desde la atribución de big data hasta el fraude. Christopher ha ayudado a ofrecer API V5 y extensiones de aplicaciones de marketing, ayudando a los clientes a crear integraciones personalizadas para que su pila de marketing funcione para ellos. Le apasiona la experiencia del desarrollador y le encanta jugar con todas las excelentes funciones para ver qué es posible.
Agregar a Slack Suscríbete a RSS
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.
…
HowToDev_ es una nueva serie sobre Salesforce+ que creamos para ayudar a los desarrolladores a familiarizarse con Salesforce Platform. Si ya tiene habilidades tecnológicas pero es nuevo en el ecosistema de Salesforce, o si desea aprender un poco sobre el desarrollo, ¡HowToDev_ es la serie para usted!
En esta nueva serie, aprenderá a ampliar la Plataforma de Salesforce y crear aplicaciones personalizadas utilizando potentes funciones de desarrollo de Salesforce líderes en la industria. Seré su anfitrión y, en cada episodio, lo explicaré cómo tomar una interfaz de usuario basada en datos que viene lista para usar con Salesforce y crear una experiencia intuitiva e interactiva que facilite la vida de los usuarios.
La plataforma de Salesforce reúne una serie de servicios de infraestructura, red, aplicaciones y datos para crear una poderosa herramienta que puede ampliar en un abrir y cerrar de ojos. Esto se debe a muchas de las complejidades que puede haber utilizado en otras plataformas de usuarios y desarrolladores. En el primer episodio de HowToDev_, repasamos una descripción general de Salesforce Platform y cómo puede crear objetos personalizados para ampliar el modelo de datos.
Realmente solo necesita preocuparse por la aplicación y los servicios de datos que se le proporcionan para construir. Desde su front-end hasta sus API, todo sale de la caja listo para que comience a construir.
¡Espera un segundo! Hay algunas cosas que necesita saber aquí antes de abrir ese entorno de desarrollo. Aquí hay un vistazo de lo que cubrimos en el Episodio 1 .
Comprender la importancia de los metadatos en Salesforce: Nosotros explicar la función de los metadatos, que representan toda la configuración, la automatización y la interfaz de usuario en el entorno de Salesforce.
Definición de qué son una aplicación y una organización en Salesforce: aclaramos los conceptos de una aplicación y una organización en Salesforce, subrayando su distinción con respecto a las aplicaciones y organizaciones tradicionales.
Creación del objeto de propiedad : demostramos el proceso de creación de un objeto personalizado (el objeto de propiedad) en Configuración de Salesforce, que funciona como una tabla de base de datos para administrar y rastrear propiedades.
Agregar nuevos campos al objeto: agregamos dos nuevos campos personalizados al objeto Propiedad (es decir, Fecha de cotización y Días en el mercado), que resaltan la naturaleza dinámica de los campos de Salesforce.
Mirando hacia el futuro: Concluimos el episodio con una mirada al futuro de lo que cubrirá la serie, prometiendo una futura exploración de la codificación y la resolución de problemas complejos dentro de Salesforce.
Una vez que tenga una mayor comprensión de estos conceptos, ¡podemos abrir la CLI en el Episodio 2 !
Todos los episodios se lanzaron a la vez en Salesforce+, ¡así que puede disfrutarlos todos ahora! Esto es lo que se trata en cada episodio:
Episodio 1: Descripción general de la plataforma Salesforce
Episodio 2: Herramientas para desarrolladores de Salesforce
Episodio 3: Código en Salesforce con Apex, SOQL y DML
Episodio 4: compilar componentes web Lightning
Episodio 5: Automatización con flujo y disparadores
Episodio 6: Completar y lanzar su aplicación Salesforce
Stephan Chandler-Garcia es promotor de desarrolladores en Salesforce. Ha estado en el ecosistema de Salesforce durante más de 10 años como cliente, socio e ISV. Puede encontrar a Stephan en persona en un grupo comunitario de Trailblazer o en una de nuestras conferencias en todo el mundo. Alternativamente, sígalo en Twitter @stephanwcg o @schandlergarcia en GitHub, y consulte su repositorio de GitHub para ver código de muestra y proyectos.
Agregar a Slack Suscríbete a RSS
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 2023, Salesforce planea actualizar los colores en nuestra interfaz de usuario de iluminación para que sean más accesibles para las personas con baja visión y para cumplir con las Pautas de accesibilidad de contenido web (WCAG) para el contraste de color que no es de texto y el contraste de color de texto. WCAG es un estándar de accesibilidad moderno requerido por numerosos órganos de gobierno de todo el mundo.
Para hacer esto, actualizaremos las plataformas en las que se crea nuestra interfaz de usuario Lightning: Salesforce Lightning Design System (SLDS) y Base Lightning Components (ambas versiones, Aura y Lightning Web Component). En estas plataformas, actualizaremos componentes, tokens de diseño, ganchos de estilo e íconos. Estos cambios no solo aparecerán en los productos de Salesforce, como Sales Cloud y Service Cloud, sino que también aparecerán en cualquier interfaz de usuario personalizada que haya creado con SLDS o Base Lightning Components.
Para obtener más detalles y ejemplos visuales de las actualizaciones, eche un vistazo a las publicaciones del blog de administración y noticias de Salesforce.
Con los colores actuales en Salesforce, los usuarios con problemas de visión tienen dificultades para reconocer los elementos clave de la interfaz de usuario, lo que no solo los frustra, sino que también les impide adoptar Salesforce. Además, Salesforce y sus clientes enfrentan problemas de cumplimiento clave debido a que un número cada vez mayor de gobiernos en todo el mundo, incluida la Unión Europea (UE) , requieren contraste de color de acuerdo con WCAG 2.1 . WCAG 2.1 ha requerido que los sitios web de las empresas usen texto que cumpla con un contraste de color de 4.5: 1 de su fondo y elementos funcionales que no sean texto que cumplan con un contraste de color de 3: 1 . Aumentar nuestro contraste de color para cumplir con estos estándares nos permitirá brindar una mejor experiencia a los usuarios con baja visión y permitirá a las empresas que usan nuestros productos evitar fuertes multas por accesibilidad.
Todos los íconos se actualizarán como parte del lanzamiento de Summer '23. Las páginas de inicio de registros seleccionados, incluidos los LWC incrustados en las páginas, se actualizarán como parte del lanzamiento de Summer '23. Todas las demás páginas, SLDS y los componentes básicos de Lightning se actualizarán como parte de la versión Winter '24.
Si descargó íconos de Salesforce y seleccionó íconos específicos para usarlos como recursos estáticos, asegúrese de actualizarlos con los nuevos íconos . Si está utilizando nuestro paquete SLDS NPM , actualice ese paquete a la última versión para ver los cambios. Si tiene páginas personalizadas desarrolladas con SLDS, vea cuáles de los siguientes escenarios se aplican a su base de código y realice los cambios correspondientes.
Utiliza un componente Lightning sin anulaciones adicionales. Su código podría verse como el Ejemplo 1 a continuación.
<dx-code-block title language="html" code-block="
Save
«>
Utiliza un componente personalizado que implementa un modelo SLDS y solo usa clases SLDS para diseñar. Su código podría verse como el Ejemplo 2 a continuación.
<dx-code-block title language="html" code-block="
«>
Similar a 2. Componente personalizado con modelo SLDS , pero en este caso, usa un componente personalizado que implementa parcialmente un modelo SLDS o usa más clases de SLDS para diseñar. Su código podría verse como el Ejemplo 3 a continuación.
--slds para cualquier valor de color codificado. Si el valor de color codificado no tiene una coincidencia exacta en términos de ganchos de estilo, querrá considerar usar el gancho de estilo más parecido.<dx-code-block title language="html" code-block="
«><dx-code-block title language="css" code-block="/* CSS */
.my-class { color: #ccc;
En este caso, la clase de CSS personalizada .my-class anula un valor de .slds-button_neutral . Este valor no solo debe actualizarse para tener un mejor contraste, sino que toda la implementación también sería más fácil de mantener si se reemplazara con un componente base Lightning y luego se usara el enlace de estilo --slds-c-button-text-color para hacer una anulación accesible.
Nota: Si no existe un gancho de estilo para el valor codificado, recomendamos usar el gancho de estilo más cercano disponible.
<dx-code-block title language="html" code-block="
Save
«>
Está usando un componente personalizado que usa directamente tokens SLDS dentro de CSS personalizado o usa clases SLDS en el marcado. Su código podría verse como el Ejemplo 4 a continuación.
<dx-code-block title language="html" code-block="
«>
En este ejemplo, el token t(colorBorder) está diseñado para bordes decorativos como tarjetas y divisores. Debe reemplazarse con un gancho de estilo que esté alineado con el plano del botón SLDS.
Está usando un componente personalizado que usa tokens personalizados. Su código podría verse como el Ejemplo 5 a continuación.
Recomendamos reemplazar tokens personalizados con ganchos de estilo SLDS cuando sea posible. Cuando use ganchos de estilo, asegúrese de usar ganchos que tengan el contexto semántico correcto. Por ejemplo, un gancho como --slds-g-color-border-base-1 solo debe usarse para bordes. Esto ayudará a garantizar que su producto siga siendo coherente con el estilo de Salesforce a medida que se produzcan futuras actualizaciones de color.
Si debe mantener su token personalizado por cualquier motivo, vuelva a verificar que su token personalizado no haya experimentado ninguna regresión visual.
<dx-code-block title language="html" code-block="
«><dx-code-block title language="html" code-block="
«>
En este ejemplo, el token t(myBackgroundColor) usa un valor de color desactualizado de SLDS. El lenguaje visual Lightning actual ya no usa este color. El token personalizado debe reemplazarse con el color más parecido de la lista de ganchos de estilo. En este ejemplo, —slds-g-color-neutral-base-95: #f3f3f3 es el gancho de estilo SLDS más parecido.
Está usando un componente personalizado que usa un valor de color codificado como #444 o rgb(68,68,68) . Su código podría parecerse al Ejemplo 3 anterior.
--slds-g-color-border-base-1 solo debe usarse como el color del borde de los elementos del formulario. Si desea mantener su valor de color codificado, verifique que estos colores no hayan experimentado ninguna regresión visual.--lwc Está utilizando un componente Lightning o Aura base y está anulando un token --lwc para personalizar el estilo de uno o más componentes. Su código podría verse como el Ejemplo 7.
NOTA: Esta no es una forma recomendada de personalizar componentes y no hay garantía de que las personalizaciones realizadas de esta manera continúen funcionando.
--lwc tokens para cualquiera de estos componentes .
--lwc que se anula con el enlace de estilo actualizado --slds introducido.<dx-code-block title language="html" code-block="
«>
En este ejemplo, al anular —lwc-colorBorder a rojo, todos los bordes de los botones se vuelven rojos. El equipo de SLDS actualizó esta variante de componente para usar un enlace de estilo global, por lo que esta anulación dejará de funcionar. En este caso, simplemente use --slds-g-color-border-base-4 en el ámbito del selector para anular el color del borde.
--lwc con ganchos de estilo globales.--slds-g-color-border-base-4 o --slds-g-color-neutral-base-50 . Se recomienda usar --slds-g-color-border-base-4 para el contexto de estilo CSS de "border" en lugar de --slds-g-color-neutral-base-50 .var(..) y coloque valores de color codificados como respaldo en caso de que un navegador heredado no pueda leer el enlace de estilo o el token de diseño. Esto es opcional.
background: var(—slds-g-color-neutral-base-50, #747474);Timothy Yeh es Gerente de Producto para Sistemas de Diseño en Salesforce, enfocado en ayudar a los clientes a construir una interfaz de usuario de mayor calidad más rápido al proporcionar sistemas sólidos de patrones.
Agregar a Slack Suscríbete a RSS
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.
…
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.
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!
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.
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.
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.
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.
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:
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.
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!
Grupo de vista previa para desarrolladores en la comunidad de socios
Embalaje gestionado de segunda generación (documentación)
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.
Agregar a Slack Suscríbete a RSS
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.
…
¡MuleSoft se complace en anunciar la disponibilidad general de Anypoint Studio 7.15 ! Con Anypoint Studio , los desarrolladores tienen acceso a un IDE de escritorio para la integración y el desarrollo de API que incluye módulos prediseñados para requisitos de integración comunes.
En MuleSoft, nuestro objetivo es capacitar a los equipos para automatizar los flujos de trabajo, brindar experiencias a los clientes y ser más productivos. Con Studio 7.15, continuamos con este compromiso. Hemos mejorado la experiencia del desarrollador y mejorado el rendimiento de Studio en todos los ámbitos. También fortalecimos la experiencia de importación de activos y agregamos más a las opciones de implementación de CloudHub. Siga leyendo para conocer algunos de los aspectos más destacados de esta versión.
Escuchamos continuamente los comentarios de la comunidad de MuleSoft para ayudarnos a mejorar nuestros productos. Algunas de las principales solicitudes de Anypoint Studio son la capacidad de incluir en la lista de permitidos los archivos de Studio de los análisis antivirus y brindar soporte nativo para la arquitectura centrada en ARM. Hemos añadido ambos.
En 7.15, agregamos la opción para que los desarrolladores excluyan los archivos de Studio del antivirus de Microsoft Defender. Esto ayudará a mejorar tanto el rendimiento como la estabilidad, lo que permitirá a nuestros usuarios ser más productivos. Para aquellos en Windows, Studio ahora será aún más receptivo y estable.
Además, Studio ahora admite de forma nativa la arquitectura centrada en ARM. Esto significa más rendimiento y mayor estabilidad para los usuarios en sistemas como macOS.
Con estas dos adiciones, estamos ayudando a nuestros usuarios a experimentar un Studio más rápido y más estable, en los principales sistemas operativos.
Cuando se trata de hacer que los desarrolladores sean productivos, los detalles importan. No basta con facilitar el desarrollo, la depuración y la implementación. Los trabajos complementarios, como la importación de artefactos y la búsqueda de contexto, también son importantes.
Hoy, importar desde Design Center es más fácil. Los desarrolladores ahora obtendrán los siguientes detalles y capacidades al importar fragmentos y especificaciones de API desde Design Center:
Con la capacidad de buscar fragmentos y especificaciones en Design Center de Studio, los usuarios ahora pueden pasar menos tiempo buscando los activos que necesitan y más tiempo creando flujos de trabajo.
En Studio 7.14, brindamos a los usuarios la capacidad de implementar en CloudHub 2.0 . Con Studio 7.15, estamos mejorando esa capacidad.
Ahora, los usuarios pueden implementar y volver a implementar una aplicación Mule en CloudHub 2.0, incluso si tiene el mismo nombre y destino que una existente en CloudHub 2.0. Esto es particularmente útil para volver a implementar después de realizar cambios en una aplicación Mule. Como resultado, los desarrolladores pueden pasar menos tiempo lidiando con los matices de la implementación.
Con la GA de nuestra última versión de Anypoint Studio, estamos entusiasmados de ver que los desarrolladores y los equipos se vuelven aún más productivos a medida que crean integraciones y API. Descargue Anypoint Studio 7.15 hoy y díganos lo que piensa.
Srini Sekaran es responsable de gestión de productos para varios productos, incluido Anypoint Studio, el IDE de MuleSoft que miles de desarrolladores utilizan a diario para crear integraciones potentes.
Agregar a Slack Suscríbete a RSS
La próxima vez que quiera hacer algo con Tableau, pero no pueda encontrar la manera con la interfaz de usuario, vaya a su confiable Postman Collection y pruebe algunos métodos a través de la API REST de Tableau.
La publicación Usar la API REST de Tableau con Postman para diseñar integraciones apareció primero en el blog de desarrolladores de Salesforce .
Recapitulamos las características actuales de LWC para dispositivos móviles y luego analizamos todas las características nuevas e innovadoras disponibles en la versión Spring '23.
La publicación Funciones y herramientas más recientes de LWC para dispositivos móviles apareció primero en el blog de desarrolladores de Salesforce .
Nuestra encuesta global anual para desarrolladores nos ayuda a saber cómo construye usando los productos de Salesforce, para que podamos mejorar su experiencia al usarlos.
La publicación Da forma al futuro de la construcción y el desarrollo en Salesforce apareció por primera vez en el blog de desarrolladores de Salesforce .
Vea lo que TrailblazerDX '23 tiene reservado para desarrolladores en todo el ecosistema de Salesforce, ya sea que se una a nosotros en San Francisco o en Salesforce+.
La publicación La guía para desarrolladores de TrailblazerDX '23 apareció por primera vez en el blog de desarrolladores de Salesforce .
En Salesforce, la innovación es uno de nuestros valores fundamentales. Con eso en mente, nos comprometemos a innovar en las tecnologías de la plataforma Salesforce, como Heroku y Salesforce Functions, así como a través de nuestra asociación con AWS, para unificar y mejorar la experiencia del desarrollador. En esta publicación de blog, le brindamos una descripción general de nuestras actualizaciones recientes, nuestro […]
La publicación Una experiencia de desarrollador completa en Heroku, Salesforce Functions y AWS apareció por primera vez en el blog de desarrolladores de Salesforce .
¡Nos complace anunciar que Event Relay para AWS ya está disponible de forma general! Event Relay es una gran parte de cómo estamos construyendo una experiencia de desarrollador unificada que abarca las plataformas de Salesforce y AWS. En esta publicación, escuchará cómo Event Relay ayuda a los desarrolladores a ahorrar tiempo al optimizar la integración bidireccional impulsada por eventos entre Amazon EventBridge […]
La publicación Salesforce Event Relay está disponible de forma general apareció por primera vez en el blog de desarrolladores de Salesforce .
Los desarrolladores de Salesforce tienen la desafiante tarea de crear e implementar rápidamente aplicaciones en la era del "trabajo desde cualquier lugar". Por lo tanto, necesitan flexibilidad tanto en cómo trabajan como en dónde trabajan. En Salesforce, nos comprometemos a brindar herramientas para que nuestros desarrolladores sean eficientes y productivos. En el pasado, hemos innovado herramientas para desarrolladores […]
La publicación Crear desde cualquier lugar con Salesforce Code Builder (Beta) apareció primero en el blog de desarrolladores de Salesforce .
En los últimos dos años, muchos de ustedes han estado esperando pacientemente y siguiendo mientras hablábamos y construíamos DevOps Center. De hecho, tenemos más de 3680 miembros (¡y contando!) en DevOps Center Trailblazer Community Group para un producto que aún no se ha lanzado. Sí, el interés y […]
El post DevOps Center ahora está en versión beta abierta. apareció por primera vez en el blog de desarrolladores de Salesforce .
Salesforce es una plataforma multiinquilino que atiende a múltiples clientes en el mismo hardware. Con este tipo de arquitectura, la Plataforma de Salesforce impone límites para hacer cumplir una distribución uniforme de recursos entre todos los inquilinos. Dichos límites incluyen el consumo de API, los límites del gobernador de Apex y otros. La mayoría de los límites relacionados con los desarrolladores se describen en los Límites para desarrolladores de Salesforce […]
La publicación Reducir el consumo de almacenamiento de archivos con las funciones de Salesforce y Amazon S3 apareció primero en el blog de desarrolladores de Salesforce .
Einstein Bots es una solución de chatbot conversacional que funciona con Einstein AI Platform de Salesforce. Su trabajo es interactuar con los clientes y brindarles la información que necesitan rápidamente sin intervención humana. También puede manejar tareas simples y repetitivas, lo que libera a los agentes para que manejen casos más complejos. En Spring '22, lanzamos el […]
La publicación Integrar bots de Einstein en cualquier canal utilizando el nuevo SDK y marco apareció por primera vez en el blog de desarrolladores de Salesforce .
¡Por primera vez en mucho tiempo, toda la comunidad se reunirá nuevamente en TrailblazerDX '22! Durante dos emocionantes días, administradores, desarrolladores, arquitectos, socios, empresarios y estudiantes se sumergirán en una experiencia de aprendizaje de primer nivel. Y, por primera vez, estamos reuniendo comunidades de desarrolladores de Salesforce, Slack, MuleSoft y Tableau. ¿Emocionado? […]
La publicación TrailblazerDX '22 para desarrolladores apareció primero en el blog de desarrolladores de Salesforce .
Esta es la cuarta publicación de blog de una serie de cinco partes. Crear una aplicación de Slack que se integre con Salesforce implica algunos desafíos, como conocer la capacidad de integración correcta para usar en cada caso, elegir el flujo de autorización correcto e implementarlo de forma segura. Esta es la cuarta publicación de blog de una serie en la que cubrimos […]
La publicación Creación de una aplicación de Slack que se integra con Salesforce: Parte 4: Desarrollo local y depuración apareció primero en el blog de desarrolladores de Salesforce .
Cuando crea un nuevo proyecto con el comando force: project: create de la CLI de Salesforce o con la paleta de comandos de VS Code, el estado del proyecto predeterminado le proporciona algunas herramientas útiles. Una herramienta clave es un conjunto de scripts y utilidades de Node.js que mejoran su experiencia de desarrollador. En esta publicación, vamos a recorrer los aspectos clave de […]
La publicación Aproveche al máximo sus proyectos DX con scripts Node.js integrados apareció primero en el Blog de desarrolladores de Salesforce .
