Skip to content

Etiqueta: DevOps

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 2 ☁️

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 2 ☁️

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

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

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 2 | Blog de desarrolladores de Salesforce

La CLI (interfaz de línea de comandos) de Salesforce es la piedra angular del desarrollo de Salesforce y, como cualquier otra herramienta, evoluciona con el tiempo. Esta publicación es la segunda de una serie de blogs de dos partes sobre sf (v2), la nueva y mejorada CLI de Salesforce. En la Parte 1 , echamos un vistazo a las novedades de sf (v2) y, en esta parte final, exploraremos los nuevos comandos de estilo sf y patrones de banderas y compartiremos cómo puede migrar desde comandos de estilo sfdx y patrones basados en banderas. en nuestra experiencia con aplicaciones de muestra . Si bien la migración puede parecer intimidante a primera vista, compartiremos algunos consejos sobre cómo facilitar la transición.

Conozca los comandos de estilo sf

Si ha estado usando la CLI durante algún tiempo, probablemente comenzó a notar una serie de advertencias en los comandos que usa con frecuencia, como este:

sfdx force:source:push
Warning: We plan to deprecate this command in the future. Try using the "project deploy start" command instead.»>

Estos cambios son el resultado del trabajo continuo en Salesforce CLI Unification que comenzó hace varios lanzamientos (más detalles en la primera parte de esta serie).

Desde entonces, cada vez que instala la CLI de Salesforce, obtiene los dos ejecutables ( sfdx y sf ). Puede usar cualquiera de estos ejecutables ya que la mayoría de los comandos son interoperables, pero le recomendamos que comience a usar sf en su trabajo diario para prepararse para el futuro.

Debido a que sf cubre más que solo el desarrollo de la plataforma central, ofrece una nueva taxonomía de comandos simplificada que refleja el flujo de trabajo de un desarrollador típico en lugar de las marcas, productos o funciones de Salesforce.

Un ejemplo práctico de esto es el comando sf org create . Con este nuevo comando, la intención es más clara: llamas a la misma base de comandos con scratch , sandbox , shape , snapshot o user , mientras que en sfdx tenías que usar una combinación de diferentes comandos ( force:org:create , force:user:create ) y flags ( --type=scratch o --type=sandbox ) para obtener el mismo resultado.

Otra característica interesante de sf es que incluye más comandos visuales e interactivos, como la creación de organizaciones con la capacidad de reanudar operaciones de larga duración en caso de tiempo de espera.

Migrar al ejecutable sf

Además de simplemente cambiar el nombre del ejecutable de sfdx a sf , hay una serie de cambios que se aplican a los comandos CLI al actualizar sus proyectos. La documentación de la CLI de Salesforce proporciona una buena descripción general de estos cambios, pero destacaremos los que nos afectaron durante la actualización de nuestras aplicaciones de muestra.

Comandos sfdx comunes y sus equivalentes sf

En primer lugar, el tema force se eliminó de la mayoría de los comandos, lo cual es una buena noticia, ya que acorta los comandos. El otro cambio importante es que los temas, comandos y subcomandos, que antes estaban separados por dos puntos como en sfdx force:org:list , ahora están separados por espacios, como en sf org list .

Mirando más de cerca los comandos que usamos a diario cuando trabajamos en aplicaciones de muestra, aplicamos los siguientes cambios:

Comando sfdx heredado Comando sf equivalente Migración Comentarios
sfdx force:org:delete -p -u recipes sf org delete scratch -p -o recipes Se debe agregar el subcomando scratch .
El indicador de la organización de destino cambia de -u a -o .
sfdx force:org:create -s -f config/project-scratch-def.json -d 30 -a recipes sf org create scratch -d -f config/project-scratch-def.json -y 30 -a recipes Se debe agregar el subcomando scratch .
El indicador "asignar organización predeterminada" cambia de -s a -d .
El indicador de duración de la organización borrador cambia de -d a -y .
sfdx force:source:push sf project deploy start Este es un cambio significativo, pero el nuevo comando funciona para todos los formatos de proyecto (fuente o metadatos).
Anteriormente, necesitaba comandos distintos.
sfdx force:user:permset:assign -n recipes sf org assign permset -n recipes El tema cambia de user a org y cambia el orden de los subcomandos.
sfdx force:data:tree:import -p data/data-plan.json sf data import tree -p data/data-plan.json
sfdx force:org:open -p lightning/n/Hello sf org open -p lightning/n/Hello
sfdx force:apex:test:run -c -r human -w 20 sf apex test run -c -r human -w 20

Si está buscando otros comandos, la documentación de CLI proporciona una lista completa de comandos sfdx con sus equivalentes sf . Cada vez que reemplace un comando, asegúrese de revisar sus banderas en busca de cambios, especialmente si usa las banderas de formato corto (un solo carácter) ( -o en lugar de --target-org por ejemplo). Puede ejecutar cualquier comando con el indicador -h o --help para obtener su descripción.

Automatice parte de la migración con expresiones regulares

ℹ️ Edición del 27 de julio de 2023: en lugar de expresiones regulares, puede usar un script de migración como se documenta aquí .

Cuando analizamos la migración de nuestros proyectos de aplicaciones de muestra , sabíamos que necesitaríamos automatizar parte del proceso, ya que había cerca de 1700 referencias a sfdx en más de 200 archivos. Para obtener los resultados más precisos aquí, asegúrese de agregar un espacio después de sfdx en su término de búsqueda y excluya la carpeta node_modules de su búsqueda, como hicimos aquí:

Comenzar con una búsqueda es un buen primer paso. Le ayuda a darse cuenta de que tendrá que migrar sus comandos en un par de lugares, como:

  • Scripts de integración continua
  • Guiones de desarrollo local
  • Documentación

Luego puede ir más allá experimentando con una búsqueda y reemplazo de expresiones regulares (RegEx) en VS Code. Este enfoque es una forma rápida de iniciar la migración. Funciona bien para la búsqueda, pero no es perfecto como reemplazo, ya que algunos comandos requieren actualizaciones manuales. En cualquier caso, siempre pruebe el resultado de sus cambios antes de enviarlos a producción.

Comience ejecutando esta búsqueda RegEx y reemplace:

Tenga en cuenta el uso de tres grupos de captura encerrados entre paréntesis en la expresión de búsqueda y representados por signos de dólar seguidos de un número en la expresión de reemplazo. Los grupos de captura le permiten retener dinámicamente ciertos valores (palabras como temas, comandos y subcomandos en nuestro caso) mientras realiza cambios en el resto de la línea (reemplazando los separadores de dos puntos con espacios en nuestro caso).

Si desea obtener más información sobre este RegEx u otros, le recomiendo que consulte regex101.com , ya que proporciona una explicación de la sintaxis y un campo de juego para probar expresiones.

Aquí hay un ejemplo de la entrada y salida en VS Code de la expresión anterior (no olvide activar el modo RegEx como lo indica la flecha roja):

Notará que esta primera ronda de búsqueda y reemplazo no es perfecta ya que obtiene algunos caracteres de espacio adicionales en el texto reemplazado. Puede arreglar esto fácilmente ejecutando una segunda operación RegEx de búsqueda y reemplazo como esta:

Una vez que ejecute este último RegEx, todavía hay un par de cambios manuales que necesitará para operar. Como vimos anteriormente en la tabla de equivalencia de comandos, estas son las cosas clave a tener en cuenta:

  • Algunos comandos usan diferentes temas y subcomandos. Por ejemplo, sf user assign permset es incorrecto: user debe ser reemplazado por org .
  • Algunas banderas necesitan ser cambiadas. Por ejemplo, sf org create scratch -s -f config/project-scratch-def.json -d 30 -a recipes es incorrecto: el indicador -d debe reemplazarse por -y y el indicador -s debe reemplazarse por -d .

Afortunadamente, la mayoría de estos cambios no son demasiado difíciles de aplicar y puede migrar con bastante rapidez a los comandos de estilo sf . Lo dejaremos con una vista de diferencias de GitHub que resume todos los cambios que fueron necesarios para migrar una de nuestras aplicaciones de muestra.

palabras de cierre

Eso es un resumen de esta breve descripción general de la migración de los comandos sfdx -style a los comandos sf -style. Vislumbró el beneficio del ejecutable sf y su nueva sintaxis. Esperamos que se beneficie de nuestra experiencia de migración y de nuestros consejos al actualizar sus proyectos.

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

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

Agregar a Slack Suscríbete a RSS

Seguir leyendo

Explore la API de la plataforma de eventos con la colección de cartero extendida ☁️

Explore la API de la plataforma de eventos con la colección de cartero extendida ☁️

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 la API de la plataforma de eventos con la colección extendida de Postman | Blog de desarrolladores de Salesforce

Para una gran cantidad de nuestros clientes, la plataforma Salesforce sirve como la piedra angular de sus sistemas de información y, por lo tanto, debe integrarse perfectamente con una amplia gama de sistemas de terceros. Entre las muchas opciones de integración disponibles se encuentra la plataforma de eventos de Salesforce.

En esta publicación, repasaremos brevemente la plataforma de eventos y luego exploraremos la nueva plataforma de eventos y las solicitudes de API que se agregaron a la colección de API de la plataforma de Salesforce en Postman. También aprenderá cómo introdujimos la capacidad de configurar Event Relays y canales personalizados con Postman.

Acerca de la plataforma de eventos de Salesforce

Event Platform consta de diferentes funciones que le permiten crear arquitecturas basadas en eventos gracias a Salesforce Event Bus.

Tipos de eventos

El bus de eventos de Salesforce admite dos tipos principales de eventos casi en tiempo real: eventos de plataforma y eventos de cambio.

Los eventos de la Plataforma permiten la comunicación dentro de la Plataforma y con sistemas externos. Estos eventos se pueden enviar y recibir con código personalizado o herramientas declarativas, como Flow. Hay eventos de plataforma estándar con campos predefinidos y eventos personalizados que puede crear con campos personalizados.

Los eventos de cambio son enviados automáticamente por la Plataforma cada vez que se crea, modifica, elimina o recupera un registro. Cada evento de cambio está vinculado a un objeto de Salesforce estándar o personalizado, y los campos de evento coinciden con los de su objeto principal.

Los eventos de plataforma y los eventos de cambio se pueden enviar y recibir gracias a una selección de dos tecnologías de transmisión: la biblioteca CometD heredada o la API Pub/Sub basada en gRCP más moderna . Independientemente de la tecnología o el tipo de evento, publica o se suscribe a eventos a través de canales dedicados.

Canales personalizados

Puede definir un canal personalizado para agrupar mensajes de eventos del mismo tipo (eventos de plataforma o eventos de cambio) en una transmisión. Por ejemplo, puede combinar eventos de cambio de cuenta, contacto y pedido en un solo canal personalizado CustomerUpdates__chn . Después de suscribirse a este canal, recibirá notificaciones sobre cambios en cualquiera de esos tres objetos.

Tenga en cuenta que los canales personalizados son compatibles con eventos de plataforma personalizados, pero no con eventos de plataforma estándar.

Además de la capacidad de agrupar varios eventos, los canales personalizados desbloquean dos funciones: filtrado de eventos y cambio de enriquecimiento de eventos.

El filtrado de eventos le permite configurar expresiones que filtran los eventos que se envían en un canal personalizado. Por ejemplo, podría crear un canal específico como UkLargeCustomerUpdates__chn que filtra las actualizaciones de la cuenta, donde el país de facturación es el Reino Unido y los ingresos anuales superan los 500k. El uso del filtrado de eventos ayuda a simplificar el código del lado del cliente, pero también ayuda a evitar los límites máximos de suscriptores simultáneos .

Los canales personalizados de Change Data Capture también otorgan la capacidad de declarar campos enriquecidos . Cuando se trabaja con eventos de cambio, solo se pasan los valores de campo actualizados en los datos del evento. Esta optimización puede ser problemática en ciertas situaciones, por ejemplo, cuando desea sincronizar con un sistema de terceros con una ID externa. En este caso, el ID externo no cambia, por lo que nunca forma parte de los datos del evento de cambio. Afortunadamente, el enriquecimiento de campos le permite declarar un canal personalizado en el que puede especificar campos que siempre se pasarán en el contexto de eventos de cambio.

Relevo de eventos

Event Relay le permite integrar perfectamente los eventos en tiempo real de Salesforce con Amazon Web Services (AWS). Gracias a Event Relay, los eventos de la plataforma y los eventos de Change Data Capture se envían a Amazon EventBridge a través de canales y los componentes de AWS pueden consumirlos directamente. Los componentes de AWS también pueden publicar eventos de plataforma de forma nativa.

Consulte esta publicación de Event Relay para obtener más información.

Antes del lanzamiento de Summer '23, Event Relay solo se podía configurar a través de las API. Ahora, hay una interfaz de usuario dedicada en Configuración. La única pieza que aún necesita crear a través de la API de herramientas o la API de metadatos son los canales personalizados.

Actualizaciones de Salesforce Event Platform para la colección Postman

En junio, actualizamos la colección de API de Salesforce Platform para Postman para incluir solicitudes para interactuar con Event Platform . Si no está familiarizado con Postman o la colección de API de plataforma, eche un vistazo al proyecto Quick Start: Connect Postman to Salesforce Trailhead para comenzar.

Canales personalizados

Nuestras nuevas solicitudes de Postman son un gran ahorro de tiempo ya que, a partir del lanzamiento de Summer '23, los canales personalizados solo se pueden configurar a través de metadatos o llamadas a la API de herramientas y no se pueden modificar directamente en la configuración de Salesforce.

Hemos introducido una serie de solicitudes para realizar operaciones de creación, lectura, actualización y eliminación (CRUD) en canales personalizados y los dos tipos de metadatos relacionados: PlatformEventChannel (consulte los documentos ) y PlatformEventChannelMember (consulte los documentos ).

A pesar de sus nombres, estos tipos de metadatos funcionan tanto para eventos de plataforma como para canales personalizados de eventos de cambio. Las únicas diferencias son que el valor del atributo ChannelType debe establecerse en event para eventos de plataforma o data para eventos de cambio, y que el atributo EnrichedFields solo está disponible para canales personalizados de eventos de cambio.

Publicar eventos de la plataforma

Hemos agregado una serie de ejemplos para eventos de plataforma de publicación. Movimos la solicitud de la API REST existente a la nueva subcarpeta Publicar eventos de la plataforma y agregamos dos ejemplos para publicar varios eventos en una sola solicitud con la API compuesta y la API SOAP.

Configuración de retransmisión de eventos

La carpeta Configuración de retransmisión de eventos es donde se encuentran la mayoría de las solicitudes nuevas. Estas nuevas solicitudes son fundamentales para configurar un relevo de eventos:

  • Operaciones CRUD en Credenciales con nombre que se introdujeron en Summer '23
  • Operaciones CRUD en la configuración de Event Relay
  • Comentarios de retransmisión de eventos de consultoría

esquema de eventos

Agregamos dos nuevas solicitudes para recuperar el esquema de un evento de plataforma, ya sea desde su ID o desde su nombre . Estas solicitudes son útiles para recuperar los campos de los eventos.

Lo que nos depara la colección Postman

Invertimos continuamente en nuestra colección de API de plataforma y buscamos agregar soporte para la suscripción a eventos de la API Pub Sub. CometD no será compatible, ya que es una biblioteca que requiere un servidor de aplicaciones, pero estamos considerando conectarnos con la API Pub/Sub basada en gRPC .

Postman ha lanzado una serie de funciones para interactuar con las API de gRPC desde el año pasado. Gracias a esto, podemos conectarnos a la API de Pub/Sub, suscribirnos a eventos y recibirlos. Sin embargo, lamentablemente no podemos decodificar su carga útil, ya que está comprimida por la plataforma de Salesforce por motivos de rendimiento. Estamos esperando una nueva característica de Postman que nos permita cargar una biblioteca (Apache Avro) para decodificar las cargas útiles de eventos cuando se reciben.

palabras de cierre

Eso es todo para nuestra breve descripción general de Event Platform y las últimas incorporaciones a la colección de API de Salesforce Platform. Gracias al crecimiento de esta caja de herramientas, puede comenzar rápidamente a explorar y configurar Event Platform.

Si disfruta de nuestro contenido de Postman, háganoslo saber. También puede echar un vistazo a nuestras otras colecciones de código abierto y contribuir .

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

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

Agregar a Slack Suscríbete a RSS

Seguir leyendo

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 1 ☁️

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 1 ☁️

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.

¡Ya está aquí la CLI sf (v2) de Salesforce! — Parte 1 | Blog de desarrolladores de Salesforce

La CLI de Salesforce es una de las herramientas de desarrollo más importantes de nuestro ecosistema. La CLI es el compañero diario de los desarrolladores de Salesforce para crear, probar, implementar y más. Además, la CLI es fundamental para las prácticas de DevOps, como la integración continua, donde la automatización es clave. Después de siete años de disponibilidad general, ahora estamos entrando en un nuevo capítulo para la CLI de Salesforce.

Esta publicación es la primera de una serie de blogs de dos partes sobre sf (v2), la nueva y mejorada CLI de Salesforce. En la Parte 1, veremos las novedades de Salesforce CLI sf (v2). Luego, en la segunda parte de la serie, nos sumergiremos en cómo puede migrar de comandos y banderas de estilo sfdx a los nuevos comandos y patrones de bandera de estilo sf .

Anuncio de disponibilidad general (GA) de sf (v2)

Hace aproximadamente dos años, el equipo de CLI de Salesforce se embarcó en una iniciativa de unificación con la visión de unificar las diversas experiencias de CLI en todo el ecosistema de Salesforce. Anunciamos la próxima evolución de nuestra CLI de Salesforce con un nuevo ejecutable llamado sf . La creación de sf como una CLI separada nos dio la oportunidad de diseñar, probar y lanzar no solo una nueva estructura de comando para un rápido desarrollo entre nubes, sino también una CLI más intuitiva, eficaz y fácil de usar.

Hoy, nos complace anunciar la disponibilidad general (GA) de la segunda versión (v2) de sf . Esta es una versión principal de sf CLI que es lo suficientemente inteligente como para comprender todos sus comandos sfdx , así como los comandos sf , con tiempos de instalación y actualización mucho más rápidos. La CLI sf (v2) es todo lo que es sf y sfdx . Después de instalar sf (v2), tendrá acceso a todos los comandos sfdx y sf , y podrá continuar ejecutando cualquiera de ellos.

Adopte el futuro del desarrollo de Salesforce

La CLI sf (v2) es nuestro camino a seguir. Le permite experimentar actualizaciones e instalaciones más rápidas ya que el tamaño de instalación/descarga se ha reducido considerablemente.

Esto significa que todas las capacidades nuevas vendrán solo a través de sf (v2) y dejaremos de publicar actualizaciones en sfdx (excepto las correcciones relacionadas con la seguridad). Además, todas las nuevas correcciones y características del complemento CLI solo entrarán en sf (v2).

Después de una importante investigación de UX, hemos introducido nuevos comandos de estilo sf y patrones de bandera para brindar una mejor experiencia de usuario. Sin embargo, si le preocupan los esfuerzos necesarios para migrar de sfdx a sf , ¡tenemos buenas noticias para usted! Todavía puede usar los comandos sfdx y la CLI sf seguirá respondiendo de la misma manera. Además, solo tendrá un conjunto de complementos CLI en lugar de uno para sfdx y otro para sf (v1). (Nota: si ha instalado complementos, todos los complementos en sf estarán disponibles en sf (v2). Sin embargo, los complementos en sfdx no están disponibles automáticamente en sf (v2). Instale los que necesita usando sf plugins install ) .

Comience con la CLI de Salesforce sf (v2)

Para familiarizarse con sf (v2), siga las instrucciones de instalación , que le mostrarán cómo pasar a sf (v2) y cómo volver a su instalación CLI actual si es necesario.

Nota sobre la instalación de Salesforce CLI sf (v2):

Creamos un alias para sfdx dentro de sf (v2), para que no necesite actualizar sus scripts de sfdx a sf . Dado que sf (v2) utilizará el alias sfdx, deberá desinstalar sfdx para que ese nombre esté disponible para sf (v2)

La CLI sf (v2) no se puede instalar en una máquina que tenga sfdx instalado. Según las instrucciones de instalación de sf (v2), primero debe desinstalar sfdx . Si no desinstala primero sfdx y, en su lugar, intenta instalar sf a través del paquete npm @salesforce/cli , que ahora alberga sf (v2), la instalación fallará. Tenga en cuenta que su CI no debe instalar sfdx , solo sf(v2) .

¿Que sigue?

Estén atentos para obtener más información sobre cómo pasar de los comandos sfdx -style a los comandos sf -style en la parte final de esta serie de blogs.

Mientras explora sf (v2), recuerde informar cualquier error, solicitud de función o comportamiento sorprendente a través del repositorio CLI GitHub . ¡Estamos emocionados de saber de usted y, como siempre, le agradecemos su apoyo!

Recursos

Sobre los autores

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

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

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

Agregar a Slack Suscríbete a RSS

Seguir leyendo

Anypoint MQ ya está disponible en MuleSoft Government Cloud ☁️

Anypoint MQ ya está disponible en MuleSoft Government Cloud ☁️

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.

Anypoint MQ ya está disponible en MuleSoft Government Cloud | Blog de desarrolladores de Salesforce

Anypoint MQ es un servicio de mensajería en la nube empresarial y multiusuario que proporciona una solución de mensajería asincrónica avanzada para aplicaciones.

Los clientes utilizan Anypoint MQ en los entornos MuleSoft US Cloud y EU Cloud para ejecutar aplicaciones de misión crítica, como el procesamiento de pedidos, la gestión de atención al cliente y la gestión de quioscos de aerolíneas. Un proveedor de comercio electrónico que recibe pedidos a través de varios canales, como web, dispositivos móviles y socios, puede procesar los pedidos en el pedido recibido y, al mismo tiempo, escalar a varias unidades de procesamiento.

Nuestros clientes del sector público han solicitado un servicio de mensajería basado en la nube que pueda integrar tanto sus aplicaciones locales como las basadas en la nube, lo que les permite ofrecer servicios automatizados para los ciudadanos. Con el lanzamiento de Anypoint MQ en MuleSoft Government Cloud, nos complace ayudar a nuestros clientes a lograr su visión.

Funciones de Anypoint MQ

Anypoint MQ admite una amplia gama de casos de uso de mensajería, como patrones de mensajería empresarial, comunicaciones asincrónicas entre microservicios e IoT. Anypoint MQ también proporciona una API REST para publicar o consumir mensajes utilizando marcos, como scripts bash de Node.js, Java, Go y DevOps.

Anypoint MQ incluye las siguientes funciones:

Colas e intercambios de mensajes

Las colas de mensajes proporcionan almacenamiento temporal que permite que las aplicaciones se comuniquen de manera escalable y confiable. Los editores pueden publicar mensajes en las colas y los suscriptores pueden recibir mensajes de las colas. Los intercambios de mensajes le permiten distribuir un solo mensaje a múltiples consumidores. Todas las colas y los intercambios de mensajes están cifrados de forma predeterminada.

Colas de retraso

Las colas de retraso le permiten posponer la entrega de nuevos mensajes a una cola durante un período específico. Los consumidores no pueden ver los mensajes enviados a una cola de demora durante el período de demora. El retraso máximo de una cola es de 15 minutos.

Consola de administración

Con la consola de administración, puede monitorear las estadísticas de las colas, purgarlas y ver cuántos mensajes están en tránsito.

Conector MQ de cualquier punto

Anypoint Connector para Anypoint MQ (Anypoint MQ Connector) proporciona mensajes de publicación y suscripción a aplicaciones Mule. Tenga en cuenta que solo Anypoint MQ Connector 4.x y versiones posteriores son compatibles con el entorno MuleSoft Government Cloud.

API REST

Puede usar la API REST para comunicarse fácilmente con aplicaciones que no son Mule.

Entornos y control de acceso basado en roles

Anypoint MQ está completamente integrado con Anypoint Access Management, lo que le permite especificar diferentes entornos para sus colas, quién puede acceder a cada entorno y qué pueden hacer dentro de cada entorno.

Grandes cargas útiles

Anypoint MQ admite cargas útiles de hasta 10 MB.

Recuperación de desastres

Los servicios de Anypoint MQ se implementan en varias zonas de disponibilidad (AZ) dentro de una región para proporcionar alta disponibilidad (HA). Si el servicio en una zona de disponibilidad deja de funcionar, el servicio Anypoint MQ funciona normalmente en esa región. Si todas las zonas de disponibilidad se desactivan en una región, el servicio Anypoint MQ no estará disponible en esa región hasta que al menos una de las zonas de disponibilidad vuelva a funcionar. Debido a que la solución de almacenamiento para Anypoint MQ es duradera, se retienen los mensajes que ya estaban en el sistema Anypoint MQ antes de que se interrumpiera el servicio.

Conclusión

¡Esperamos que esté tan entusiasmado como nosotros con estas características! Para comenzar a acceder a Anypoint MQ en Government Cloud, visite nuestro tutorial .

Más recursos

Sobre el Autor

Gouthami Kondakindi es un ingeniero líder en Salesforce que trabaja en la creación de servicios que potencian la plataforma MuleSoft Anypoint.

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

Seguir leyendo

Automatización y Salesforce DevOps: una receta para el desarrollo acelerado

Automatización y Salesforce DevOps: una receta para el desarrollo acelerado

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

En el acelerado mundo empresarial actual, la eficiencia en el desarrollo de software es vital. La automatización ha surgido como una solución clave, agilizando los procesos para aumentar la productividad y liberar la innovación. Salesforce no es inmune a estos desafíos y complejidades de toda la industria.

Ingrese a DevOps. DevOps se ha convertido en un elemento esencial en el desarrollo de software, incluido Salesforce. Mediante la colaboración de desarrolladores, administradores y partes interesadas, Salesforce DevOps crea un entorno perfecto para la automatización.

La combinación de automatización y Salesforce DevOps cosecha múltiples beneficios: menos errores, preparación más rápida para el mercado, una canalización de lanzamiento optimizada, menos repeticiones, calidad de código superior y mecanismos de retroalimentación más fuertes. Mejora la eficiencia operativa y la velocidad de implementación en el ecosistema de Salesforce, fomentando un desarrollo ágil.

Este artículo explora la intersección de la automatización y Salesforce DevOps, los beneficios de su sinergia y formas prácticas de aplicarla para un desarrollo más rápido en sus operaciones de Salesforce. Tanto si es un profesional de Salesforce como un novato, este artículo ofrece información para reforzar su enfoque de DevOps de Salesforce con la automatización.

Descripción de DevOps de Salesforce

Antes de profundizar en cómo se cruzan Salesforce DevOps y la automatización, es fundamental comprender lo que implica Salesforce DevOps.

DevOps, una combinación de ' Desarrollo ' y ' Operaciones ', es un conjunto de prácticas diseñadas para fusionar el desarrollo de software, el control de calidad y las operaciones de TI en un proceso unificado y fluido. En un contexto de Salesforce , DevOps es la unión de estos principios con las sólidas capacidades de CRM de Salesforce, con el objetivo de facilitar procesos de desarrollo e implementación más fluidos y rápidos.

En esencia, Salesforce DevOps incorpora principios como:

  1. Integración continua y entrega continua (CI/CD),
  2. responsabilidades compartidas,
  3. Acción centrada en el cliente,
  4. Cultura de colaboración.

El objetivo es crear un entorno cohesivo donde los administradores, desarrolladores y otras partes interesadas puedan trabajar en armonía, lo que lleva a ciclos de desarrollo más cortos, tiempo de comercialización más rápido y software de alta calidad.

Sin embargo, a pesar de las ventajas de Salesforce DevOps, los desarrolladores a menudo enfrentan desafíos. Si bien es un activo, las características integrales y la capacidad de personalización de Salesforce pueden complicar el proceso de desarrollo e implementación .

Los desafíos difieren de un equipo a otro y de un caso de uso a otro, pero estos son algunos de los más comunes:

  • Las diferencias en los entornos,
  • Administrar dependencias de código,
  • Manejo de metadatos,
  • Alinear el trabajo de diferentes equipos
  • Necesidad de mantener la calidad del código
  • Estabilidad del sistema mientras entrega a gran velocidad

Aquí es donde la automatización viene al rescate. La automatización, en esencia, es el uso de la tecnología para realizar tareas con una intervención humana reducida. Cuando se aplica a Salesforce DevOps , puede aliviar significativamente estos desafíos.

Las pruebas automatizadas, por ejemplo, pueden mejorar la calidad del código al identificar errores al principio del proceso de desarrollo. Las implementaciones automatizadas pueden sincronizar metadatos y código en diferentes entornos, lo que reduce los errores de implementación. Del mismo modo, la automatización de tareas repetitivas puede liberar el tiempo de los desarrolladores, lo que les permite concentrarse en actividades que agregan más valor, como el desarrollo de funciones o el diseño de sistemas.

Además, la automatización fomenta un proceso de desarrollo más ágil, lo que permite actualizaciones periódicas e incrementales en lugar de implementaciones rígidas de Salesforce. Este aspecto acorta el ciclo de desarrollo y facilita la reversión de los cambios si algo sale mal, lo que aumenta la estabilidad general del sistema.

Aprovechamiento de la automatización para el desarrollo acelerado de Salesforce

Acelerar el desarrollo de Salesforce a través de la automatización implica identificar tareas manuales y repetitivas, implementar herramientas y marcos de automatización adecuados y perfeccionar los procesos para mejorar la eficiencia y reducir los cuellos de botella. Profundicemos en cada una de estas áreas con más detalle:

Identificación de tareas manuales y repetitivas

El primer paso hacia la automatización es reconocer qué tareas están ralentizando su velocidad de desarrollo.

Estos típicamente incluyen:

  • Revisiones de código,
  • Pruebas,
  • Despliegue,
  • Configuración,
  • Migración de datos.

Suelen implicar procesos manuales tediosos que consumen tiempo y son propensos a errores. Al identificar estas tareas, puede identificar dónde la automatización proporcionará el mayor beneficio y tendrá un impacto significativo en la velocidad y la eficiencia de su desarrollo.

Implementación de herramientas y marcos de automatización

Una vez que haya identificado las áreas que podrían beneficiarse de la automatización, es hora de elegir e implementar las herramientas y los marcos adecuados. Salesforce ofrece varias funciones de automatización integradas, como Apex y Salesforce Flow .

Sin embargo, otras herramientas pueden ser más adecuadas para tareas complejas, como Salesforce DX para la gestión del ciclo de vida del desarrollo, o Jenkins y CircleCI para la integración y entrega continuas. Al seleccionar estas herramientas, asegúrese de que se alineen con las habilidades de su equipo y los requisitos específicos de su entorno de Salesforce.

Optimización de procesos para mejorar la eficiencia

La automatización no se trata solo de herramientas y tecnología. También se trata de refinar sus procesos. Revise su flujo de trabajo de desarrollo actual para identificar posibles cuellos de botella y áreas de mejora.

Por ejemplo:

  1. ¿Cómo se informan y rastrean los errores?
  2. ¿Con qué frecuencia se realizan las implementaciones y cómo se programan?
  3. ¿Cómo se recopilan los comentarios y cómo se actúa en consecuencia?

Simplificar estos procesos puede mejorar drásticamente la eficiencia de su equipo, permitiéndole aprovechar al máximo sus esfuerzos de automatización.

Vale la pena mencionar que los beneficios de la automatización van más allá de acelerar el desarrollo. La automatización también puede mejorar la calidad del código al detectar errores temprano a través de pruebas automatizadas. Puede reducir los errores de implementación al sincronizar el código en diferentes entornos.

Y al liberar a los desarrolladores de las tareas rutinarias, les permite concentrarse más en el desarrollo de características y el diseño del sistema, fomentando así la innovación y mejorando el valor entregado a los usuarios finales.

Pruebas automatizadas para el desarrollo acelerado de Salesforce

Las pruebas son un componente crucial de cualquier ciclo de vida de desarrollo, y su importancia se multiplica para acelerar el desarrollo de Salesforce. Las pruebas periódicas y exhaustivas ayudan a identificar errores y problemas desde el principio, lo que reduce el riesgo de reparaciones costosas y lentas en el futuro. Asegura la calidad y la confiabilidad de la aplicación, lo que a su vez contribuye a mejorar las experiencias de los usuarios y los resultados comerciales.

La automatización puede potenciar este proceso de prueba. Las pruebas automatizadas implican el uso de herramientas de software para ejecutar pruebas y comparar los resultados reales con los resultados esperados. La implementación de una estrategia de prueba automatizada para las aplicaciones de Salesforce puede acelerar drásticamente el proceso de desarrollo, lo que garantiza implementaciones más rápidas, eficientes y confiables con menos errores.

Existen numerosas herramientas disponibles para pruebas automatizadas en Salesforce. Apex proporciona soporte integrado para pruebas unitarias, mientras que herramientas como Selenium, Provar y AssureClick pueden automatizar las pruebas de IU. Jest es una excelente opción para probar Lightning Web Components (LWC). Al seleccionar una herramienta, considere las necesidades específicas de su aplicación, la experiencia de su equipo y la complejidad y frecuencia de sus requisitos de prueba.

Seguir las mejores prácticas es esencial para aprovechar todo el potencial de las pruebas automatizadas. Estas son algunas de las mejores prácticas para pruebas automatizadas eficientes y completas en el desarrollo de Salesforce:

  • Apunte a una alta cobertura de prueba : asegúrese de probar todas las partes de su aplicación. Salesforce requiere una cobertura de código mínima del 75 %, pero apuntar a una mayor cobertura puede brindar más confianza en la confiabilidad de la aplicación.
  • Cree pruebas repetibles y autónomas : las pruebas deben poder ejecutarse en cualquier entorno y no deben basarse en datos de pruebas anteriores. Esto garantiza que cada prueba valide una función específica de forma independiente.
  • Mantenga sus conjuntos de pruebas : a medida que su aplicación evolucione, sus pruebas también deberían hacerlo. Revise y actualice regularmente sus pruebas para asegurarse de que reflejen con precisión el estado actual de su aplicación.
  • Implemente diferentes niveles de prueba : combine pruebas unitarias, pruebas de integración y pruebas de interfaz de usuario para validar todos los aspectos de su aplicación. Cada nivel de prueba proporciona una perspectiva diferente sobre la funcionalidad de la aplicación.
  • Priorizar la legibilidad de la prueba : las pruebas a menudo sirven como documentación, explicando lo que se supone que debe hacer una parte del código. Asegúrese de que sus pruebas estén bien estructuradas y claramente escritas para que sean fáciles de entender para los demás.
  • Incorpore las pruebas al principio del proceso de desarrollo : no espere hasta el final del ciclo de desarrollo para comenzar las pruebas. La incorporación de pruebas de manera temprana y frecuente le permite detectar y solucionar problemas rápidamente.

Integración e implementación continuas con automatización

La integración continua y la implementación continua (CI/CD) forman un pilar central de Salesforce DevOps. CI/CD está diseñado para reducir errores y acelerar el desarrollo a través de la integración continua de código y procesos de implementación automatizados y consistentes.

En el contexto de Salesforce, CI fusiona periódicamente los cambios de código en un repositorio compartido, a menudo varias veces al día. Cada integración se verifica automáticamente mediante la creación de la aplicación y la ejecución de pruebas, lo que garantiza que los nuevos cambios se integren perfectamente con el código existente y no introduzcan errores.

Por otro lado, CD implementa automáticamente esos cambios en la producción, lo que garantiza que las nuevas características, configuraciones y mejoras lleguen a los usuarios finales lo más rápido posible. En Salesforce, CD puede implicar la implementación de cambios en diferentes entornos, como entornos de desarrollo, prueba, ensayo y producción.

La automatización es clave para lograr procesos impecables de CI/CD de Salesforce. A través de la automatización, puede optimizar y estandarizar los pasos involucrados en:

  • Creación, prueba e implementación de aplicaciones de Salesforce,
  • Reducir el potencial de error humano
  • Acelerar el ciclo de desarrollo general.

La automatización del proceso de compilación garantiza que los cambios en el código se integren y validen de manera constante. Las pruebas automatizadas, como comentamos anteriormente, verifican la integridad y la calidad del nuevo código. La automatización del proceso de implementación ayuda a sincronizar el código y los cambios de configuración en diferentes entornos, lo que garantiza que todos los equipos de DevOps trabajen con la versión más reciente y precisa de la aplicación.

Control de versiones y automatización de la gestión de cambios

En el desarrollo de Salesforce, el control de versiones y la gestión de cambios son fundamentales para mantener la integridad, coherencia y calidad de su aplicación.

El control de versiones, una parte integral del desarrollo de software, implica administrar y rastrear diferentes versiones de su base de código. Le permite ver los cambios a lo largo del tiempo, volver a las versiones anteriores cuando sea necesario y administrar el código de varios desarrolladores al mismo tiempo.

La gestión de cambios se refiere a la gestión y el seguimiento de los cambios del sistema, incluidos los cambios de configuración, las modificaciones de código y las implementaciones de nuevas funciones.

La automatización de estos procesos puede mejorar su eficiencia y confiabilidad en el desarrollo de Salesforce.

  1. El control de versiones automatizado permite una integración de código más fluida de diferentes desarrolladores, lo que reduce el riesgo de conflictos y errores.
  2. La gestión de cambios automatizada asegura que todas las modificaciones a su sistema sean rastreadas y verificadas con precisión, mejorando la responsabilidad y facilitando el diagnóstico de cualquier problema que surja.

Varias herramientas pueden ayudar a automatizar el control de versiones y la gestión de cambios en Salesforce. Los sistemas de control de versiones (VCS) como Git permiten un control de versiones efectivo. Facilita el seguimiento de los cambios en la base del código, lo que ayuda a mantener la integridad del código.

Las herramientas de DevOps como Copado o Gearset pueden ayudar a automatizar el seguimiento y la implementación de cambios en diferentes entornos para la gestión de cambios. Brindan una visibilidad integral de su historial de cambios, lo que le permite administrar los cambios de manera más efectiva y mantener la estabilidad de su aplicación.

Automatización de la supervisión y el tratamiento de errores

En el ámbito vertiginoso del desarrollo de Salesforce, el papel de la automatización se extiende más allá de la creación, prueba e implementación. El monitoreo automatizado y el manejo de errores son igualmente importantes para mantener la salud de la aplicación y corregir rápidamente cualquier problema.

El monitoreo automatizado implica el uso de herramientas para realizar un seguimiento constante del rendimiento, el uso y el estado general de sus aplicaciones de Salesforce. Este enfoque proactivo permite a los equipos de desarrollo identificar y abordar posibles problemas antes de que afecten a los usuarios.

El manejo proactivo de errores va de la mano con el monitoreo automatizado. En lugar de esperar a que se informen los problemas, el manejo proactivo de errores implica el uso de sistemas automatizados para identificar y, a menudo, resolver los problemas tan pronto como ocurran. Las notificaciones de error automatizadas aseguran que su equipo esté al tanto de cualquier problema al instante, lo que permite una respuesta rápida, minimiza el tiempo de inactividad y reduce la posibilidad de errores costosos.

La implementación de estas herramientas de automatización en Salesforce DevOps implica el uso estratégico de recursos como Monitoreo de eventos de Salesforce, que proporciona un flujo de eventos de auditoría de aplicaciones de su organización, y herramientas de Monitoreo y advertencia de errores, que pueden notificarle automáticamente sobre errores o excepciones.

Conclusión

La automatización combinada con las prácticas de Salesforce DevOps ofrece una poderosa estrategia para acelerar el desarrollo y mejorar la calidad del software. Es una receta para el éxito en el vertiginoso panorama digital actual.

Para implementar la automatización en su desarrollo de Salesforce, comience por identificar las tareas repetitivas que podrían automatizarse. Luego, implemente herramientas adecuadas para tareas como integración continua, pruebas automatizadas, control de versiones y monitoreo de aplicaciones. Agilice cualquier proceso manual junto con la implementación de estas herramientas, creando un flujo de trabajo de desarrollo eficiente y efectivo.

La adopción de la automatización en Salesforce DevOps acelera el desarrollo y refuerza la confiabilidad y el valor de sus aplicaciones. A medida que el ecosistema de Salesforce continúa evolucionando, el papel de la automatización crecerá aún más, dando forma al futuro del desarrollo de Salesforce.

Este artículo fue escrito por Sam Hops. Es redactora de contenido para una revista digital que cubre temas relacionados con el diseño, el comercio electrónico, el marketing digital y el espíritu empresarial. Sam es un apasionado de todo lo relacionado con el marketing digital, pero tiene un interés particular en el diseño gráfico, el SEO y las redes sociales.

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.

Seguir leyendo

Presentamos apex-mockery, una biblioteca de simulación de pruebas unitarias ☁️

Presentamos apex-mockery, una biblioteca de simulación de pruebas unitarias ☁️

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 apex-mockery, una biblioteca de simulación de pruebas unitarias | Blog de desarrolladores de Salesforce

Escribir pruebas sólidas es crucial para crear aplicaciones comerciales confiables y eficientes. En esta publicación, haremos un repaso de las pruebas unitarias y presentaremos apex-mockery , una biblioteca liviana de pruebas unitarias de Apex que lo ayuda a escribir pruebas unitarias de Apex verdaderamente desacopladas usando simulacros y aserciones. Compartiremos ejemplos de código para ayudarlo a comprender cómo puede usar la biblioteca para crear pruebas unitarias fáciles de entender y de ejecución rápida.

Un repaso a las pruebas unitarias

Antes de echar un vistazo a la biblioteca de Apex-Mockery, demos un paso atrás y analicemos algunos de los conceptos básicos de las pruebas unitarias desde un punto de vista independiente de la tecnología. Luego, veremos Apex y discutiremos por qué la mayoría de nosotros debería escribir pruebas unitarias en lugar de pruebas de integración.

Las pruebas unitarias están en la base de la pirámide de prueba.

La ingeniería de software abarca múltiples tipos de pruebas: unidad, integración, servicio, interfaz de usuario funcional, de extremo a extremo, aceptación del usuario y más. Como dice Martin Fowler , podemos representar un buen equilibrio entre estos tipos de pruebas dentro del alcance de un proyecto representándolos como una pirámide.

Las etiquetas (tipos de prueba) pueden cambiar, pero el principio clave aquí es que las pruebas que se ejecutan rápido y con frecuencia deben estar en la parte inferior de la pirámide. Estos son los más fáciles de implementar y mantener (por lo que cuestan menos). Luego, a medida que subimos a la cima, aumentamos la complejidad y el costo: las pruebas se ejecutan más lentamente y se vuelven más difíciles de implementar y mantener.

En el contexto de esta publicación y en aras de la brevedad, nos centraremos únicamente en las pruebas unitarias. Estos son los primeros que debe implementar en cualquier proyecto, y deben ser una prioridad en su estrategia de prueba.

Por definición, las pruebas unitarias están destinadas a probar la menor cantidad de código (una unidad) de un proyecto. Las pruebas unitarias solo deben basarse en la lógica pura y estar completamente desvinculadas de sus dependencias (otras clases) y límites (otros servicios, como almacenamiento de datos o servicios web). Las pruebas unitarias deben ejecutarse rápido; no requieren una configuración de prueba particular, como la inserción de datos en la base de datos, y requieren que simule las dependencias de la clase bajo prueba.

Escribir pruebas unitarias de Apex en lugar de pruebas de integración

Apex se beneficia de una estrecha integración con la Plataforma de Salesforce y, si bien esta característica es excelente para cosas como acceder rápida y fácilmente a la base de datos, difumina las líneas de separación de preocupaciones entre la lógica y los servicios. Como consecuencia, es muy fácil escribir pruebas de integración de Apex en lugar de pruebas unitarias. Por ejemplo, el código de Apex a menudo se prueba junto con la base de datos utilizando declaraciones @TestSetup y DML. Si bien estas pruebas de integración ayudan a lograr la cobertura, se basan en la base de datos y, por lo tanto, requieren más tiempo para ejecutarse que las pruebas unitarias "puras".

Como compartió Mitch Spano en su presentación de pruebas unitarias puras de Apex , la mayoría de las veces, no es necesario confiar en las pruebas de integración para probar capas de software de alto nivel, como controladores LWC, servicios y capas de aplicación. Gracias a la API de Stub de Apex lanzada en Spring '17, los desarrolladores pueden romper con esas dependencias en el contexto de las pruebas mediante la creación de su propia biblioteca/marco de pruebas unitarias o el uso de uno existente como apex-mockery.

Presentamos la burla del ápice

Como parte del trabajo de ingeniería de Salesforce, estábamos desarrollando un paquete administrado internamente y necesitábamos una biblioteca para escribir pruebas unitarias. Queríamos escribir pasos simples de "arreglar" (como en el patrón Arrange-Act-Assert ), escribir afirmaciones comprensibles y burlarnos de nuestras dependencias. Buscamos en todo el ecosistema una biblioteca fácil de leer y bien probada que pudiéramos usar para crear nuestro producto, pero no encontramos una combinación perfecta, por lo que decidimos escribir la nuestra. Estábamos tan contentos con la implementación final de la biblioteca que decidimos lanzarla como código abierto con el nombre apex-mockery .

La biblioteca apex-mockery proporciona una biblioteca de simulación simple, liviana y fácil de leer para Apex creada con la API Stub. La biblioteca está diseñada para que sea fácil de usar y brinde la mejor experiencia de desarrollador posible al generar simulacros y apéndices, configurar espías y escribir aserciones.

Lo guiaremos a través de un escenario de muestra para que pueda comprender el poder de la biblioteca con algunos ejemplos prácticos. Luego, le mostraremos cómo puede escribir pruebas para este proyecto de muestra en tres pasos:

  1. Crear simulacros y espías de métodos.
  2. Métodos de espionaje de trozo
  3. escribir afirmaciones

Ejemplo de escenario: pedidos de panadería y entrega

Considere el siguiente escenario de ejemplo: una panadería toma pedidos de pastelería y planifica las entregas utilizando un servicio dedicado. Los únicos datos que estamos considerando en el contexto de este escenario son los nombres de los pasteles y su fecha de entrega.

A continuación se muestra la implementación básica de nuestro escenario de panadería (el código completo está disponible en el repositorio del proyecto ).

Pastelería.cls

DeliveryService.cls

DeliveryServiceImpl.cls

Confirmación de pedido.cls

Panadería.cls

Ahora que hemos echado un vistazo a nuestro proyecto de muestra, echemos un vistazo a cómo podríamos escribir pruebas para el método Bakery.order .

Paso 1: crea simulacros y espías de métodos

Para funcionar, la clase Bakery necesita que se pase una instancia DeliveryService en su constructor. En un contexto de producción, el servicio se proporciona con una instancia concreta DeliveryServiceImpl de la siguiente manera:

Sin embargo, en el contexto de las pruebas unitarias, no debe usar una instancia de servicio real para garantizar el desacoplamiento. En otras palabras, DelivertServiceImpl se probará unitariamente por sí solo, por lo que no es necesario que pruebe las dos clases integradas juntas. Puede reemplazar la dependencia del servicio con un simulacro que implemente la interfaz DeliverService .

Así es como puede crear e inyectar fácilmente un simulacro de este tipo, gracias a apex-mockery:

Luego, su prueba necesita un espía, para que pueda controlar el comportamiento del método planDelivery y ejecutar aserciones en sus llamadas.

Ahora que tiene un servicio simulado y un espía en su método planDelivery , veamos cómo puede configurar su espía y ejecutar aserciones en él.

Paso 2: métodos de espionaje de trozo

Una vez que tenga una instancia simulada, puede controlar cómo se comportan sus métodos controlando sus valores de retorno y lanzando excepciones.

Utilice los métodos returns y throwsException para especificar un comportamiento predeterminado que se aplica a todas las llamadas a los métodos auxiliares. Luego, si es necesario, usa una combinación de whenCalledWith(<args>).thenReturn y whenCalledWith(<args>).thenThrow para aplicar comportamientos específicos a las llamadas a métodos que coincidan con los argumentos especificados.

Durante la ejecución de la prueba, apex-mockery comienza buscando una coincidencia en la configuración proporcionada por whenCalledWith . Si no se encuentra ninguno, vuelve a la configuración predeterminada ( returns o throwException ).

Veamos algunas situaciones comunes de configuración de stubs (ver más recetas ).

  • Devolver algo cada vez que se llame planDelivery
  • Lanza una excepción cada vez que se llama planDelivery
  • Devuelve algo cuando se llama con un argumento específico
  • Lanza una excepción cuando se llama con un argumento específico

Ahora que sabe cómo impulsar el comportamiento de su simulacro, puede agregar aserciones para probar su código.

Paso 3: Escribe afirmaciones

apex-mockery proporciona una API de afirmaciones fluidas. Tan pronto como comience su expectativa con Expect.that(mySpy) , tendrá acceso a varios métodos de afirmación. La biblioteca viene con una serie de afirmaciones de comportamiento fáciles de usar, como:

Si los comparadores de argumentos básicos no son suficientes para sus necesidades, también puede crear sus propios comparadores de argumentos personalizados .

Uniendo el ejemplo completo

Ahora que vimos los pasos individuales, terminemos y echemos un vistazo a nuestra prueba para el método Bakery.order . Observe cómo puede usar aserciones de burla de Apex, junto con las aserciones estándar de Apex de la clase system.Assert , en sus pruebas.

palabras de cierre

Esto concluye nuestro recorrido por las pruebas unitarias y la biblioteca de Apex-Mockery. Aprendió cómo las pruebas unitarias desacopladas son más fáciles de escribir y ejecutar mucho más rápido. Tener pruebas rápidas acorta el ciclo de retroalimentación del ciclo de vida del desarrollo, reduce la duración de la ejecución del flujo de trabajo de CI y acelera las implementaciones. Estos factores permiten a los desarrolladores implementar y ejecutar pruebas con frecuencia, mejorando así la calidad.

apex-mockery lo ayuda a dirigir su proyecto en esta dirección. Consulte el repositorio del proyecto para comenzar. Encontrará la documentación de la biblioteca con las opciones de instrucciones de instalación (instalación de fuente o paquete desbloqueado), algunas recetas de muestra y una guía de migración. ¡Feliz prueba unitaria!

Sobre los autores

Ludovic Meurillon es ingeniero de software en el equipo de Service Cloud en Grenoble, Francia. Empujó el código a la producción durante años, disfruta eliminando más líneas de código de las que agrega y prefiere la programación en pares sobre las revisiones de código y los productos de trabajo sobre el diseño perfecto. Sígalo en Twitter @LudoMeurillon o consulte sus proyectos de GitHub @ludomeurillon .

Sébastien Colladon es CTA e ingeniero de software en el equipo de Service Cloud en París, Francia. Le encanta contribuir a hacer del ecosistema de Salesforce un lugar mejor y disfruta aprender y trabajar con otros. Consulte sus proyectos de GitHub @ scolladon .

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

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

Agregar a Slack Suscríbete a RSS

Seguir leyendo

Una actualización importante de nuestro plan de jubilación Legacy API ☁️

Una actualización importante de nuestro plan de jubilación Legacy API ☁️

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.

Una actualización importante de nuestro plan de jubilación Legacy API | Blog de desarrolladores de Salesforce

En 2021, anunciamos unplan para retirar las versiones heredadas de la API de la plataforma anualmente, de modo que nuestros equipos de ingeniería pudieran centrar sus esfuerzos de desarrollo en mejorar las últimas versiones de la API para mejorar la experiencia general de Salesforce al crear funciones personalizadas a través de aplicaciones. En esta publicación, compartiremos una actualización importante del plan de retiro de la API heredada, algunos consejos sobre cómo identificar el uso de la API heredada y cómo actualizar esas solicitudes de API.

Actualización importante del plan de jubilación de la API heredada

La última fase del plan de retiro de la API heredada se anunció a principios de 2022 y entró en vigencia durante el lanzamiento de Summer '22. Con esta versión, dejamos de usar las versiones SOAP, REST y Bulk API que van de la 21.0 a la 30.0. Como parte de nuestro plan original, estas versiones de API ya no serían compatibles, pero permanecerían disponibles hasta que las retiremos en la versión Summer '23.

Luego de consultar con la comunidad y nuestros socios, decidimos retrasar el próximo retiro de la API al lanzamiento de Summer '25 para garantizar una transición sin problemas (consulte el artículo de conocimientos ). Debido a esta extensión, las versiones de API 21.0 a 30.0 aún no son compatibles, pero seguirán estando disponibles hasta el lanzamiento de Summer '25.

Desde Summer '21 , cada vez que realiza una llamada a una API heredada con REST o Bulk API, verá un encabezado Warning en la respuesta con un mensaje que describe el problema como este:

Una vez que las versiones heredadas de la API se retiren en Summer '25, las solicitudes a esas versiones fallarán con los siguientes errores:

  • La API REST devolverá el estado HTTP 410: GONE
  • La API SOAP devolverá el estado HTTP 500: UNSUPPORTED_API_VERSION
  • La API masiva devolverá el estado HTTP 400: InvalidVersion

Ahora que conoce el último plan, veamos cómo puede identificar si se ve afectado y cómo.

Identificar el uso de la API heredada

Puede verificar las llamadas API heredadas usted mismo en cualquier momento, y hay varias formas de hacerlo.

Todas las transacciones de la API de Salesforce se registran en los registros de Monitoreo de eventos. El monitoreo de eventos normalmente requiere una licencia específica, pero hemos expuesto el evento Uso total de la API ( ApiTotalUsage ) a todos los clientes de forma gratuita, para que pueda monitorear el consumo de la API heredada e identificar los clientes y las integraciones que deben actualizarse. Las organizaciones habilitadas para API tienen acceso gratuito a los archivos de registro de eventos de uso total de API con retención de datos de 1 día. Con el Monitoreo de eventos habilitado, puede acceder a este y a todos los demás tipos de archivos de registro de eventos con una retención de datos de 30 días.

Los registros contienen campos clave que guían sus investigaciones:

  • Los clientes proporcionan CLIENT_NAME opcionalmente, pero es especialmente útil para identificar aplicaciones e integraciones que realizan llamadas API que requieren investigación y ajustes. Compartiremos más sobre este campo en la última sección de esta publicación.
  • CONNECTED_APP_ID le dice qué aplicación conectada está en el origen de las llamadas a la API.
  • USER_ID y CLIENT_IP son útiles para identificar el origen de las llamadas API heredadas, pero existe la posibilidad de que estos valores se compartan entre varias aplicaciones en caso de que se realice una cuenta técnica de usuario/sistema (ID de usuario compartido) o llamadas desde una ubicación de oficina física ( dirección IP compartida). Compartiremos cómo usar la nueva licencia de usuario de integración para abordar los problemas de usuarios compartidos en la última sección de esta publicación.
  • Los campos API_FAMILY , API_VERSION , API_RESOURCE , URI y HTTP_METHOD le brindan pistas valiosas sobre el tipo de operaciones que realizan los clientes API.

Compartimos varias herramientas para acceder a los registros en nuestra publicación anterior , y también puede usar herramientas de terceros para automatizar esta tarea. Compartiremos una opción adicional que puede ser relevante para los usuarios preocupados por ejecutar código de terceros con acceso API a su organización.

Uso de Postman para identificar el uso de la API heredada

Puede utilizar la colección Postman de las API de la plataforma de Salesforce para inspeccionar sus registros de Salesforce con estos pasos:

  • Configure la colección Postman y autentíquese en su organización .
  • Enumere los archivos de registro que rastrean el acceso a la API:
    1. Seleccione REST > Solicitud de consulta .
    2. Reemplace el valor del parámetro de consulta q con la siguiente consulta SOQL: SELECT LogFile, EventType, CreatedDate FROM EventLogFile WHERE EventType IN ('API', 'RestApi', 'BulkApi', 'ApiTotalUsage')
    3. Haz clic en Enviar.
    4. Recupere los ID del archivo de registro de la respuesta.

  • Para cada archivo de registro devuelto en el paso anterior, recupere y escanee el contenido del registro:
    1. Seleccione REST > Registros > Obtener solicitud de archivo de registro de eventos .
    2. Establezca el ID del archivo de registro en el valor de la variable de ruta id .
    3. Haz clic en Enviar.
    4. Lea el contenido del archivo de registro en la respuesta. Puede moverse a la pestaña Respuesta sin procesar y guardarla como un archivo CSV o usar la pestaña Visualizar para obtener una vista previa del contenido directamente en Postman.
    5. Mire la columna URI o API_VERSION y verifique las versiones de API heredadas (versiones 30.0 y anteriores).

Después de identificar que está llamando a versiones de API heredadas, el siguiente paso es actualizar estas dependencias a versiones de API heredadas.

Actualizar dependencias a versiones de API heredadas

El procedimiento de actualización depende del tipo de API que esté utilizando, pero aquí hay una breve descripción general de lo que se requiere:

  • Para llamadas API basadas en SOAP, genere un nuevo WSDL e incorpórelo a la integración afectada
  • Para puntos finales REST, actualice el número de versión en el URI a la versión principal actual
  • Aunque puede actualizar de manera similar los URI para puntos finales /async en el caso de Bulk API, la forma más gratificante de actualizar las llamadas heredadas es adoptar Bulk API 2.0 y disfrutar del flujo de trabajo más simple y los límites mejorados.

Tenga en cuenta que las aplicaciones (p. ej., el cargador de datos) y los paquetes también pueden estar realizando llamadas API heredadas debido a bibliotecas obsoletas (conectores de servicios web, kit de herramientas AJAX, interfaz COM SForceOfficeToolkit o kit de herramientas Force.com para PHP, solo por nombrar algunos) . Asegúrate de actualizarlos también.

Y recuerda: no importa el cambio, asegúrate de realizar pruebas de regresión para asegurarte de que todo funciona como se esperaba.

Preparándonos para el futuro

Ya sea que se haya visto afectado por el plan de jubilación heredado o no, debe planificar el futuro retiro de la versión API. Le dejaremos algunas prácticas recomendadas para el gobierno de API.

Aproveche las licencias de usuario de la integración de Salesforce

En Spring '23, presentamos un nuevo tipo de licencia dedicado a las integraciones: la licencia de usuario de Integración de Salesforce . Esta nueva licencia se basa en el principio de acceso con privilegios mínimos y le permite crear usuarios solo de API para integraciones de sistema a sistema con derechos de acceso específicos. La principal ventaja de este nuevo tipo de licencia es la seguridad, pero también permite un mejor seguimiento de las acciones de integración, ya que podrá asignar distintos usuarios solo de API a la integración y relacionar las llamadas de API de integración con ID de usuario específicas en sus registros.

Se incluyen cinco licencias de usuario de Integración de Salesforce en cada organización Enterprise, Unlimited y Performance Edition. También puede comunicarse con su ejecutivo de cuenta si necesita más.

Especifique un nombre de cliente al crear integraciones de API REST

Al crear nuevas integraciones con la API REST, asegúrese de especificar un nombre de cliente utilizando el encabezado de solicitud Sforce-Call-Options de la siguiente manera:

Sforce-Call-Options: client=myClientName

El nombre del cliente que especifique en el encabezado estará visible en los registros en el campo CLIENT_NAME . Esto le ayuda a depurar y auditar las llamadas a la API de integración.

palabras de cierre

Esperamos que este retraso adicional en nuestro plan de retiro de API heredado permita una transición sin problemas, y lo alentamos a que comience hoy, independientemente de la nueva fecha límite. Migrar a versiones de API más nuevas siempre es una apuesta segura para obtener acceso a nuevas capacidades y mejorar el rendimiento y la seguridad.

Sobre el Autor

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

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

Agregar a Slack Suscríbete a RSS

Seguir leyendo

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

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

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 .

Seguir leyendo

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

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

TrailblazerDX '23 estuvo lleno de innovación y contenido para los desarrolladores. En este blog, la perspectiva de un desarrollador de Salesforce Platform y una lista de recursos de TDX.

La publicación Retrospectiva de un desarrollador de plataforma de TrailblazerDX '23 apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

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

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

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

La publicación Prepare su aplicación para pasar la revisión de seguridad de AppExchange apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

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

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

Las API de Salesforce ahora son compatibles con las credenciales de cliente de OAuth, lo que facilita más que nunca establecer integraciones de servidor a servidor que no necesariamente necesitan el contexto del usuario.

La publicación Uso del flujo de credenciales del cliente para una autenticación API más sencilla apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Mejore la disponibilidad en su organización ☁️

Esté atento a estos antipatrones comunes y utilice estas estrategias para evitarlos y mejorar la disponibilidad en su organización.

La publicación Mejore la disponibilidad en su organización apareció por primera vez en el blog de desarrolladores de Salesforce .

Seguir leyendo

Simplificando la complejidad de Salesforce CPQ

Última actualización el 2 de marzo de 2023 por Rakesh Gupta Salesforce CPQ (Configure, Price, Quote) es una plataforma robusta, diseñada para proporcionar precios precisos a las empresas con cualquier escenario de configuración de producto dado. La plataforma automatiza el proceso de generación de cotizaciones para pedidos, lo que permite a los representantes de ventas cotizar precios de forma rápida y precisa. Citas

La publicación Simplificando la complejidad de Salesforce CPQ apareció primero en Automation Champion .

Seguir leyendo

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

Consulte la tercera y última publicación de blog de nuestra serie que relata el viaje de la CLI de sfdx hacia el código abierto, ahora con confiabilidad mejorada.

La publicación Lograr una CLI de Salesforce de código abierto apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Transmita eventos a escala con filtros de eventos y enriquecimiento de campo ☁️

Escale su uso de eventos de plataforma y eventos de captura de datos modificados con filtros de eventos y enriquecimiento de campos. Pero primero, un repaso sobre los eventos de transmisión.

La publicación Transmisión de eventos a escala con filtros de eventos y enriquecimiento de campos apareció por primera vez en el blog de desarrolladores de Salesforce .

Seguir leyendo

La guía para desarrolladores de TrailblazerDX '23 ☁️

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 .

Seguir leyendo

Servicios externos y actualizaciones de API | Aprende MOAR Primavera '23 ☁️

Puede esperar una gran cantidad de servicios externos y actualizaciones de API en Spring '23, lo que hace que sea aún más fácil aprovechar Salesforce para automatizar cualquier cosa.

La publicación Servicios externos y actualizaciones de API | Learn MOAR Spring '23 apareció por primera vez en el blog de desarrolladores de Salesforce .

Seguir leyendo

Anunciando los Ganadores del Premio Codey 2022 ☁️

Consulte los ganadores del Premio Codey a los mejores blogs, videos y podcasts de 2022, según la votación de la comunidad de desarrolladores de Salesforce.

La publicación Anunciando los ganadores del premio Codey 2022 apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Resumen de 2022: nuevas funciones para desarrolladores del año pasado ☁️

Cada año, los desarrolladores de Salesforce se encuentran en el extremo receptor de una cinta transportadora de funciones nuevas importantes y, a veces, esenciales de la plataforma de Salesforce.

La publicación 2022 en revisión: nuevas funciones para desarrolladores del año pasado apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Organizaciones temporales para administrador de Salesforce

Última actualización el 1 de enero de 2023 por Rakesh Gupta Con la creciente adopción de Salesforce DevOps, las organizaciones temporales de repente están en el centro de atención. Este blog explicará qué son las organizaciones borrador, por qué son útiles y cómo puede crear una fácilmente con clics, no con código. ¿Qué es una organización temporal?

La publicación Scratch Orgs for Salesforce Admin apareció por primera vez en Automation Champion .

Seguir leyendo

Grandes mejoras en la CLI de Salesforce ☁️

¡No te preocupes, no están rompiendo cambios!

La publicación Grandes mejoras en la CLI de Salesforce apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Aproveche al máximo Salesforce DevOps Center

Última actualización el 15 de diciembre de 2022 por Rakesh Gupta El momento que muchos profesionales de Salesforce han estado esperando finalmente ha llegado: ¡Salesforce DevOps Center GA! Pero antes de instalar DevOps Center en su organización y comenzar a usarlo para implementar metadatos, analicemos cómo aprovecharlo al máximo.

La publicación Aproveche al máximo Salesforce DevOps Center apareció primero en Automation Champion .

Seguir leyendo

Procesamiento de grandes cantidades de datos con API (parte 2 de 2) ☁️

Cuando trabaje en un entorno empresarial, es posible que deba procesar grandes cantidades de registros de Salesforce utilizando las API de la plataforma. Esta publicación es la segunda parte de una serie de dos publicaciones que se centran en el procesamiento de datos a escala con API. En la primera parte de la serie, nos enfocamos en operaciones de lectura con la API REST y […]

La publicación Procesamiento de grandes cantidades de datos con API (Parte 2 de 2) apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo

Procesamiento de grandes cantidades de datos con API (parte 1 de 2) ☁️

Cuando trabaje en un entorno empresarial, es posible que deba procesar grandes cantidades de registros de Salesforce utilizando las API de la plataforma. En esta serie de dos publicaciones, presentaremos opciones para procesar datos a escala. En esta primera publicación, nos centraremos en las operaciones de lectura con la API REST y las API masivas. Presentaremos cuál es la mejor opción […]

La publicación Procesamiento de grandes cantidades de datos con API (Parte 1 de 2) apareció primero en el blog de desarrolladores de Salesforce .

Seguir leyendo