Introducción Salesforce Communities Cloud es una plataforma en línea que permite a las empresas crear comunidades virtuales para sus clientes. Estas comunidades son espacios donde los clientes pueden interactuar entre sí, compartir información y recibir soporte de la empresa. La creación de una comunidad en línea se ha vuelto cada vez más importante para las […]
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.
…
Si la desarrolladora de Salesforce, Farah Sherif , pudiera comenzar su carrera nuevamente, comenzaría a aprender Salesforce antes. No esperaba dedicarse a la codificación para ganarse la vida, pero pronto descubrió que era la carrera adecuada para ella. “Solía pensar que la codificación era realmente complicada”, dice Farah, “pero Salesforce y Trailhead lo hicieron fácil. Además, con suficiente dedicación, puedes aprender cualquier cosa en Salesforce”.
Trailhead es la puerta de entrada al ecosistema de Salesforce, donde cualquier persona puede aprender las habilidades más demandadas y relevantes de la actualidad de forma gratuita, obtener credenciales dignas de currículum y conectarse con oportunidades globales. Hoy, más de 18 millones de Trailblazers están aprendiendo, creando redes y desarrollando sus habilidades para construir carreras exitosas.
Solía pensar que la codificación era realmente complicada, pero Salesforce y Trailhead lo hicieron fácil.
Farah conoció Salesforce gracias a su primo, que es miembro del Salón de la fama de MVP de Salesforce , allá por 2018. Él le envió un par de módulos en la plataforma de aprendizaje de Trailhead, incluida la ruta Admin Beginner , y ella se enganchó de inmediato.
En la actualidad, la carrera de Farah es próspera y actualmente es desarrolladora sénior de Salesforce para Oloop Technology Solutions , una firma de consultoría de tecnología empresarial con sede en Aurora, IL. Ella también se ha convertido en MVP de Salesforce.
Trailhead ha sido el entorno de aprendizaje de Farah desde el primer día, y desde entonces ha superado cientos de unidades y módulos. Hasta la fecha, Farah ha completado 34 senderos y ganado la friolera de 365 insignias y 11 superbags, lo que la ha llevado al nivel Triple Star Ranger .
Farah también ha mejorado su currículum al lograr 15 certificaciones de impulso profesional de Salesforce , y recomienda este enfoque a otros desarrolladores que buscan avanzar en su carrera. Ella dice: "Aunque no tenga experiencia en un tema, si estudia lo suficiente y aborda la certificación, le da la oportunidad de ser parte de un proyecto que utiliza los productos que aprendió en su certificación".
A pesar de todos sus logros, Farah continúa usando Trailhead como su fuente principal para aprender nuevas habilidades. “Aunque hay varios recursos disponibles”, dice, “primero empiezo con Trailhead y luego reviso otros recursos. Al prepararme para las certificaciones, las preguntas de práctica han sido realmente útiles”.
Aunque hay varios recursos disponibles, primero empiezo con Trailhead.
Para los desarrolladores que desean explorar ejemplos de trabajo, Farah sugiere consultar Code Sample Gallery , que ella considera "una joya oculta subestimada". Contiene ejemplos de código escritos por el equipo de defensa de desarrolladores de Salesforce que muestran una variedad de características de la plataforma de Salesforce, como componentes web Lightning, Apex y flujos, así como casos de uso como la transformación de páginas de Visualforce en componentes web Lightning. Farah dice: "Es la mejor manera de aprender, ya que el código está escrito por expertos de Salesforce y hay toneladas de ejemplos sobre cómo hacer todo".
Junto con las habilidades técnicas, Farah ha aprendido que la buena comunicación es vital para el éxito del desarrollador. A medida que avanzaba en su carrera, Farah llegó a creer que los desarrolladores no se sientan detrás de una computadora y programan todo el día. Los desarrolladores deben poder comunicarse bien con los demás para realizar su trabajo o mostrar su solución. Ya sea que se trate de reportar bloqueadores a un gerente de producto, discutir una solución alternativa o incluso explicar un enfoque técnico a un cliente, es importante que los desarrolladores puedan expresarse claramente.
“No lo aprendí en un día”, dice Farah, “pero he recorrido un largo camino desde la primera vez que hablé con un cliente. Las habilidades de comunicación también ayudan cuando escuchas conversaciones porque entonces estás aprendiendo cómo tratar con las personas y cómo manejar a los clientes”. (Consejo: consulte elmódulo Narración y comunicación en Trailhead para mejorar sus habilidades).
Una de las razones por las que a Farah le encanta ser desarrolladora de Salesforce es la experiencia de desarrollo en sí misma. Le gusta construir algo desde cero que pueda ayudar a las personas a ahorrar tiempo o facilitarles la vida. También se emociona cuando puede trabajar en algo que antes la gente pensaba que no era posible y ayudar a darle vida. Ella dice: "Me encanta programar porque es desafiante y te obliga a pensar de manera estructurada para encontrar una solución a prueba de errores".
La clave del éxito de Farah: hacer preguntas. Cuando se enfrenta a requisitos desconocidos, Farah dedica mucho tiempo a aprender e investigar para obtener información sobre un tema nuevo, lo que beneficia a toda su organización. “Cuando paso tiempo aprendiendo un nuevo producto o una nueva función de Salesforce, siempre es valioso para mi equipo, ya que puedo actuar como una fuente de conocimiento de ese tema más adelante cuando tengamos que usarlo”.
Farah también recurre a Salesforce Developers Trailblazer Community para buscar ayuda de expertos o seguir a líderes de opinión como David Liu y Salesforce Ben. Farah dice: "La Comunidad Trailblazer es mi espacio seguro, donde todos son increíblemente útiles, y cuando sé que cuando contacte a alguien, realmente querrán ayudar". Sus grupos favoritos son Apex Hours y Ladies Be Architects .
Farah completó la universidad con un título en Ciencias de la Computación y llevaba unos meses en su nuevo trabajo, esforzándose por demostrar su valía como desarrolladora de Salesforce estudiando y obteniendo certificaciones. Pero fue solo cuando comenzó a involucrarse más profundamente con la comunidad Trailblazer que sus perspectivas de carrera comenzaron a cambiar.
“ Después de pasar algunos meses aprendiendo sobre Trailhead”, recuerda Farah, “Solicité dirigir el grupo comunitario local de Trailblazer en El Cairo, Egipto. Esas reuniones realmente me ayudaron a mejorar mis habilidades y, de hecho, conseguí mi primer trabajo como desarrollador de Salesforce asistiendo a ellas y conectándome con la gente. ”
La dedicación de Farah al aprendizaje ya la comunidad no pasó desapercibida. En octubre de 2020, Salesforce le otorgó una rara sudadera con capucha dorada para celebrar su compromiso y su trayectoria como Trailblazer.
“Cuando recibí la sudadera con capucha dorada”, recuerda, “fue un momento increíble del que estaré orgullosa para siempre”. El premio se sintió como una verificación de todos sus esfuerzos. Dos años más tarde, estaba en su primera conferencia de Salesforce y el significado de la sudadera con capucha finalmente hizo clic. “Fue entonces cuando realmente sentí lo especial que es tener la sudadera con capucha dorada. Es diferente cuando puedes usarlo en persona y ser reconocido por más de 4000 personas”. Comparte más de su perspectiva y experiencia, así como un vistazo de su Golden Hoodie, en un episodio de Trailhead Live (a las 25:32).
Cuando recibí la sudadera con capucha dorada, fue un momento increíble del que estaré orgulloso para siempre.
Farah aconseja a los desarrolladores que son nuevos en el ecosistema de Salesforce que hagan preguntas y no dejen de aprender. Para mantenerse al día con las últimas novedades, recomienda consultar las notas de la versión de Salesforce que incluyen mejoras en la funcionalidad existente y nuevas herramientas. También sugiere involucrarse con su comunidad local de Salesforce , asistir a reuniones grupales y conferencias, donde tiene la oportunidad de establecer contactos y conocer a otros profesionales y regresar con nuevas ideas e inspiración.
Para Farah, el aprendizaje es un proceso continuo, algo que trata de recordar todos los días. Ella dice: “No dejas de aprender solo cuando tienes X número de certificaciones o cuando crees que has alcanzado un hito. Cuando mantienes el aprendizaje como un hábito, realmente vale la pena”.
Para conocer a desarrolladores como Farah y ampliar sus habilidades técnicas, únase a la comunidad de desarrolladores de Salesforce y sea parte de la conversación sobre todo lo relacionado con el desarrollo de Salesforce.
Christie Fidura es la directora de Global Trailblazer Engagement. En este rol, busca involucrar y elevar a la comunidad y trabajar directamente con ellos para comprender sus desafíos, preocupaciones, victorias e inspiraciones. Puede encontrar a Christie en Trailblazer Community en https://trailblazer.me/id/christiefidura . Christie, administradora comunitaria certificada y comercializadora ganadora de múltiples premios, cree en la tecnología, la comunidad y la igualdad.
Agregar a Slack Suscríbete a RSS
Una estadística sorprendente de Skuid revela que entre el 20 y el 70 % de los proyectos de CRM fallan debido a la falta de experiencia profesional. Las empresas sin administradores de Salesforce capacitados son similares a los propietarios de automóviles costosos de alto rendimiento pero sin licencia de conducir. Lo tienes, pero no puedes usarlo en todo su potencial. Como un hábil conductor detrás del volante, los administradores de Salesforce garantizan el funcionamiento perfecto de Salesforce, la plataforma de CRM líder en el mundo. Pueden adaptar la plataforma para que se adapte a las necesidades comerciales únicas, navegando sus complejidades con facilidad. Pero surge una pregunta importante: ¿qué factores influyen significativamente en el salario de un administrador de Salesforce?
En esta Guía de salario de administrador de Salesforce, profundizaremos en estas preguntas y descubriremos información crucial en el camino. A partir de esta guía, puede esperar descubrir:
Profundicemos y desentrañemos los aspectos importantes de ser un administrador de Salesforce exitoso.
Los administradores de Salesforce tienen muchas funciones. Administran usuarios, datos y seguridad, personalizan Salesforce para satisfacer las necesidades comerciales, crean informes y paneles y brindan capacitación a los usuarios finales. Su función requiere una combinación de habilidades técnicas y blandas, incluida la resolución de problemas, la comunicación, la gestión de proyectos y una comprensión profunda de las funcionalidades de Salesforce.
Según un estudio realizado por IDC, se prevé que el ecosistema de Salesforce, incluidos sus clientes y socios, genere 9,3 millones de nuevos puestos de trabajo y contribuya a $1,6 billones en nuevos ingresos comerciales a nivel mundial para 2026. A medida que más empresas adopten Salesforce, el papel de Salesforce Los administradores solo se volverán más fundamentales, haciendo de esta profesión no solo un trabajo, sino una opción de carrera próspera.
Según Payscale, para aquellos que recién comienzan su viaje como administradores de Salesforce, el salario inicial en los EE. UU. es de aproximadamente $ 61,000 por año. Esta cifra representa el salario inicial estándar para los administradores que tienen menos de un año de experiencia. La cifra puede cambiar según variables como la ubicación, la industria y el tamaño de la empresa.
El salario anual promedio de los administradores de Salesforce en los EE. UU. es de alrededor de $ 73,500. Esta cifra es un promedio de varios niveles de experiencia, industrias y ubicaciones dentro de los EE. UU. Incluye el salario base, aguinaldos, participación en las utilidades y cualquier otro beneficio económico, en su caso.
Con 2 a 5 años de experiencia, los administradores pueden esperar ganar alrededor de $71,000 por año. Los administradores sénior de Salesforce con más de 5 años de experiencia pueden ganar entre $86 000 y $92 000 por año, según los datos de Payscale.
La industria también juega un factor clave en la determinación del salario. Por ejemplo, los administradores de Salesforce en los sectores de tecnología y finanzas a menudo ganan más que los de otras industrias debido a la mayor demanda y complejidad de las tareas en estos sectores.
La ubicación geográfica es otro factor clave que influye en los salarios. Los estados que tienen costos de vida más altos, como California y Nueva York, frecuentemente ofrecen salarios más altos como contrapeso. De manera similar, los estados con una alta concentración de empresas tecnológicas, como Washington y Texas, también tienden a ofrecer salarios más altos debido al mercado laboral competitivo.
India es uno de los mercados más grandes para el talento tecnológico y juega un papel crucial en el ecosistema de Salesforce. Los ingresos de los administradores de Salesforce en la India también están determinados por numerosas variables, como la experiencia, la ubicación geográfica, la industria y las certificaciones.
Según Talent.com, la estructura del salario del administrador de Salesforce en India varía ampliamente, dependiendo de varios factores. En promedio, pueden esperar ganar ₹ 1,100,000 por año. Para aquellos que recién comienzan su viaje de Salesforce, los salarios de nivel de entrada son alrededor de ₹ 500,000 por año.
Sin embargo, a medida que los administradores de Salesforce acumulan experiencia y perfeccionan sus habilidades, su potencial de ingresos crece significativamente. Los profesionales más experimentados en este campo pueden obtener salarios de hasta ₹ 1 737 500 por año, lo que demuestra la importante progresión financiera posible en esta carrera.
En el panorama tecnológico en constante evolución, los administradores de Salesforce desempeñan un papel fundamental a nivel mundial. Aquí hay un resumen de los salarios promedio de los administradores de Salesforce en varios países a través de diferentes niveles de experiencia:
Estos números pueden variar según numerosos factores, incluidos el país, la industria y el tamaño de la organización. A medida que los administradores obtienen más experiencia y dominan las funcionalidades de Salesforce, sus salarios aumentan significativamente.
El poder de las certificaciones y la experiencia de Salesforce para configurar el salario de un administrador de Salesforce no se puede subestimar. Según la Encuesta de salarios de Mason Frank, se reveló que el 43% de los encuestados vieron un aumento en su salario después de obtener una certificación, lo que destaca la correlación directa entre la mejora profesional y las recompensas financieras.
También es fundamental centrarse estratégicamente en las certificaciones más pertinentes. La certificación de Administrador Avanzado, por ejemplo, es muy buscada ya que valida la experiencia en características y funcionalidades avanzadas de Salesforce. Del mismo modo, tener una certificación de Platform App Builder puede brindar una ventaja considerable para aquellos que aspiran a validar su competencia en el diseño, la creación y la implementación de aplicaciones personalizadas en la plataforma Salesforce.
La experiencia también tiene un peso inmenso en el salario de un administrador de Salesforce. El mismo estudio de Mason Frank sugiere que un profesional de Salesforce con más de cinco años de experiencia puede ganar hasta un 20% más que sus contrapartes con menos experiencia.
Sin embargo, si bien es beneficioso tener múltiples certificaciones, es crucial equilibrar esto con la adquisición de experiencia en el mundo real. Los empleadores valoran la experiencia práctica, por lo que centrarse únicamente en las certificaciones sin aplicar las habilidades aprendidas podría hacerte parecer sobrecualificado o fuera de contacto con los aspectos prácticos del puesto.
En el sector de la tecnología, y específicamente dentro de los roles de Salesforce, a menudo vemos una mezcla de experiencias. Para algunos, la lealtad a una sola organización conduce a una progresión salarial constante, especialmente si pueden obtener un ascenso dentro de la organización. Sin embargo, otros descubren que cambiar de trabajo cada pocos años acelera el crecimiento de su salario de administrador de Salesforce debido a la "prima de salto de trabajo".
Según los hallazgos del Instituto de Investigación ADP, los empleados que se apegan a sus trabajos han visto crecer sus salarios en un 5,9 %, mientras que aquellos que cambian de trabajo ven un salto mayor, con un aumento del 8,0 %.
Sin embargo, no se trata solo de perseguir el salario más alto. Cambiar de trabajo puede conducir potencialmente a percepciones de inestabilidad o falta de compromiso, lo que podría afectar las perspectivas laborales futuras. Por otro lado, permanecer en una empresa durante un período prolongado podría limitar la exposición a diversas experiencias y, potencialmente, ralentizar el ritmo de desarrollo de habilidades y progresión profesional.
Por lo tanto, si bien cambiar de trabajo puede generar una ganancia financiera inmediata, considere otros factores, como las oportunidades de aprendizaje, la cultura laboral, el equilibrio entre el trabajo y la vida personal y el crecimiento profesional a largo plazo al tomar tales decisiones. Después de todo, una carrera satisfactoria es algo más que las cifras de su cheque de pago.
Estos son algunos consejos prácticos para los administradores de Salesforce que buscan aumentar sus ingresos.
A medida que la ola de transformación digital sigue aumentando, la demanda de administradores de Salesforce capacitados se dispara. En particular, las funciones de estos profesionales se extienden más allá de la competencia técnica y exigen una combinación armoniosa de habilidades blandas y una comprensión profunda de los procesos comerciales.
No se puede subestimar la influencia de las certificaciones, la experiencia y la ubicación geográfica en el salario de un administrador de Salesforce. Un administrador certificado de Salesforce, especialmente con habilidades de nicho como CPQ, puede esperar un aumento salarial, con incrementos adicionales paralelos a su experiencia acumulada. Los datos muestran que los cambios frecuentes de trabajo también pueden contribuir a un aumento más rápido de los ingresos en comparación con permanencias más largas en una empresa.
Sin embargo, no se trata solo de buscar certificaciones o cambiar de trabajo. La creación de una red sólida, la búsqueda de mentores y el perfeccionamiento de sus habilidades de negociación son esenciales para mejorar su valor y, en consecuencia, su potencial de ingresos.
Para los posibles administradores de Salesforce o los experimentados que buscan avanzar, recuerde que es una combinación de aprendizaje continuo, movimientos profesionales estratégicos y aprovechar la vibrante comunidad de Salesforce lo que lo colocará en los tramos salariales más altos.
Última actualización el 31 de julio de 2023 por Rakesh Gupta
Durante la última década, el papel de un administrador de Salesforce ha evolucionado drásticamente, manteniendo el ritmo del panorama dinámico de las ventas y la gestión de las relaciones con los clientes. Lo que alguna vez fue principalmente una posición de entrada de datos se ha convertido en un rol multifacético que abarca la planificación estratégica, el análisis y la optimización de procesos. A medida que las empresas reconozcan la importancia de Salesforce para impulsar el crecimiento y mejorar las experiencias de los clientes, los administradores proporcionarán un puente fundamental entre la tecnología y el éxito comercial.
Este artículo explorará cómo los administradores pueden aprovechar la automatización de procesos junto con el ecosistema de Salesforce para fomentar la colaboración en equipo, mejorar la eficiencia organizacional y mejorar la gestión de datos.
La automatización del correo electrónico se utiliza para optimizar varios aspectos de la comunicación por correo electrónico con clientes potenciales y clientes dentro de la plataforma de Salesforce para garantizar una programación de citas rápida y eficiente. Permite a las empresas administrar de manera eficiente sus campañas de marketing y ventas por correo electrónico, la participación del cliente y las reservas.
En los últimos años, la automatización revolucionó los procesos de ventas y soporte al agilizar la reserva de citas, reducir la carga de trabajo manual y brindar a los clientes opciones convenientes de autoservicio. Actualmente, los administradores de Salesforce pueden aprovechar herramientas como SUMO Scheduler junto con flujos nativos y alertas por correo electrónico para enviar automáticamente invitaciones a citas. Al crear disparadores que monitorean campos de datos específicos asociados con registros de contactos y lanzar flujos personalizados, los administradores pueden asegurarse de que los clientes potenciales siempre puedan programar citas, independientemente de la hora del día o la ubicación.
Las reuniones de cara al cliente son vitales para los equipos de ventas y soporte, y las citas perdidas o canceladas pueden afectar negativamente los objetivos estratégicos y el resultado final. Los administradores de Salesforce pueden aprovechar las actualizaciones automáticas de temas dentro de la programación de citas para reducir las cancelaciones de manera efectiva y aumentar la participación en las citas. Al implementar esta funcionalidad, los administradores pueden mejorar la comunicación, brindar claridad e infundir confianza en el proceso de citas para los clientes y la organización.
Se puede activar una actualización automática del tema para incluir detalles esenciales como la fecha, la hora, la ubicación y el propósito de la cita al programarla. Este mensaje de confirmación sirve como recordatorio para el cliente y reduce las posibilidades de cancelaciones involuntarias o de no presentarse.
Las actualizaciones automáticas de temas también se pueden personalizar para atender a clientes individuales. Los administradores pueden incluir detalles personalizados, como el nombre del cliente o referencias de citas específicas, para captar su atención y crear una sensación de personalización. Esto ayuda a fomentar una conexión con el cliente y refuerza su compromiso con la cita.
Finalmente, en caso de cambios o actualizaciones en la cita, los administradores pueden usar actualizaciones automáticas de temas para comunicar la información revisada. Esto asegura que los clientes estén informados sobre cualquier modificación en tiempo real, minimizando la confusión o la necesidad de cancelar debido a detalles desactualizados o inexactos.
Al permitir la flexibilidad en la programación y el mantenimiento de registros precisos dentro de Salesforce con la ayuda de líneas de asunto automatizadas, los administradores pueden optimizar de manera efectiva su proceso de ventas, mejorar la experiencia del usuario y fortalecer las relaciones con los clientes.
La flexibilidad es clave para satisfacer las necesidades únicas de los clientes, y los administradores de Salesforce pueden aprovechar el poder de los campos de correo electrónico para notificaciones personalizadas, sin importar cuán complejas sean. Esta personalización permite una experiencia más personalizada que cumple con requisitos específicos, como el cumplimiento normativo o las políticas internas.
En el contexto de Salesforce, los campos de correo electrónico se utilizan para recopilar y almacenar las direcciones de correo electrónico de los clientes. Estos campos aseguran que los datos ingresados sigan el formato adecuado, evitando entradas incorrectas o no válidas. Las direcciones de correo electrónico recopiladas a través de estos campos se pueden usar para enviar recordatorios, actualizaciones, mensajes de seguimiento y otras notificaciones relacionadas con citas. Cada campo de correo electrónico actúa como una medida confiable de capturar y utilizar información de contacto para mejorar el compromiso y mantener canales de comunicación efectivos.
Los campos de correo electrónico de Salesforce pueden mejorar la precisión al garantizar que la información de contacto almacenada en CRM esté actualizada y sea confiable. Al utilizar campos de correo electrónico dedicados dentro de Salesforce, los representantes de ventas pueden capturar y almacenar direcciones de correo electrónico específicas de personas o entidades con precisión. Esto ayuda a eliminar el riesgo de usar direcciones de correo electrónico desactualizadas o incorrectas asociadas con otros campos, como información de contacto personal o comercial, lo que da como resultado comunicaciones por correo electrónico más confiables, tasas de rebote reducidas y precisión de datos mejorada. 
Las herramientas de programación nativas de Salesforce permiten a los equipos de ventas automatizar la creación de clientes potenciales, lo que garantiza una captura precisa de la información y los datos demográficos de los clientes potenciales en el CRM. Al automatizar el proceso de creación de clientes potenciales tan pronto como se programa una cita, los administradores pueden ahorrar tiempo, mantener la integridad de los datos y evitar la redundancia. Los flujos automatizados agilizan el proceso y eliminan los errores de entrada manual. La precisión mejorada y la colaboración entre las partes interesadas mejoran las tasas de conversión de clientes potenciales y proporcionan datos confiables para informes y análisis.
Para automatizar rápidamente la creación de clientes potenciales en Salesforce en el momento de la reserva, puede seguir estos pasos:
Al automatizar la creación de clientes potenciales en Salesforce en el momento de la reserva, los representantes de ventas y los administradores pueden ahorrar tiempo, garantizar la precisión de los datos y mantener un proceso de gestión de clientes potenciales optimizado. Esta automatización facilita la captura eficiente de clientes potenciales, reduce el esfuerzo manual y mejora la productividad del equipo de ventas.
Los flujos de programación automatizados, junto con las poderosas capacidades de SUMO Scheduler, simplifican y mejoran los procesos de trabajo, ahorran tiempo, reducen errores y mejoran la satisfacción del cliente. Al adoptar la automatización, los administradores de Salesforce pueden impulsar mejoras significativas en la eficiencia, la productividad y el rendimiento comercial general. La optimización de los procesos de programación y el aprovechamiento de los flujos de automatización en Salesforce con SUMO Scheduler es una combinación ganadora para las empresas que buscan optimizar sus operaciones. ¡Adopte la revolución de la automatización hoy e impulse a su equipo de ventas a nuevos niveles de éxito!
Haga clic aquí para visitar SUMO Scheduler en Salesforce AppExchange y obtener más información sobre el poder de la programación automática de autoservicio .
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
La CLI (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.
sfSi 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.
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.
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.
ℹ️ 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:
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:
sf user assign permset es incorrecto: user debe ser reemplazado por org .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.
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.
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 .
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.
…
Salesforce Data Cloud permite a los desarrolladores aprovechar el poder de los grandes datos para las empresas. Al utilizar Data Cloud, los clientes pueden consolidar los datos de clientes de múltiples sistemas en una única instancia de Salesforce, creando una vista unificada de los datos en toda la empresa. Estos datos se pueden utilizar para análisis, aprendizaje automático y acciones automatizadas. En este primer blog de nuestra serie de dos partes, exploraremos diferentes utilidades de Apex para consultar datos en Data Cloud y brindaremos orientación sobre cómo utilizarlas de manera efectiva.
Apex ofrece una variedad de utilidades para Data Cloud. Por ejemplo, permite que los desarrolladores construyan con Lightning Web Components para personalizar las experiencias de usuario estándar de Data Cloud, o que los ISV construyan su propio código para automatizar operaciones específicas de Data Cloud, como la resolución de identidades, la creación y ejecución de conocimientos calculados de Data Cloud o la segmentación.
Antes de analizar cómo consultar datos de Data Cloud, comprendamos un poco acerca de los objetos de Salesforce Data Cloud y cómo difieren con respecto a los objetos estándar/personalizados de Salesforce Platform.
Salesforce Data Cloud tiene un modelo de datos canónico que incluye objetos de lago de datos (DLO) y objetos de modelo de datos (DMO). Puede leer acerca de cómo estos objetos se asignan entre sí y sus propósitos en la documentación de ayuda.
Los objetos de Data Cloud pueden ingerir y almacenar volúmenes de datos mucho más grandes (en la magnitud de miles de millones de registros) en comparación con los objetos estándar y personalizados regulares en la Plataforma de Salesforce. Los objetos estándar/personalizados están diseñados para casos de uso transaccional y no son adecuados para almacenar y procesar big data. Por otro lado, los objetos de Data Cloud agregan capacidades similares a las de un lago de datos .
Otra distinción clave es que los objetos de Data Cloud no admiten disparadores Synchronous Apex. Sin embargo, aún puede lograr la automatización de procesos suscribiéndose a Change Data Capture (CDC) y utilizando Flows o Apex. Lo que es común entre los objetos de la nube de datos y los objetos de la plataforma es que están construidos sobre la misma base impulsada por metadatos, lo que hace posible el uso de características de la plataforma, como Salesforce Flow, Apex y Platform Events.
Antes de profundizar en algún código, exploremos un ejemplo de caso de uso de una aplicación de nube de datos.
Para nuestros ejemplos de código en esta publicación de blog, supongamos que estamos trabajando para una empresa ficticia llamada Solar Circles que captura datos de todos sus paneles solares instalados en Data Cloud. Cada mes, se generan decenas de millones de puntos de datos a partir de estos paneles. Al tener estos datos en Data Cloud, Solar Circles obtiene la capacidad de realizar análisis, utilizar técnicas de aprendizaje automático y obtener información procesable de los datos.
El código de Apex en esta publicación asume una condición importante: la nube de datos está habilitada y el código de Apex se ejecuta en la organización de la nube de datos y no en las organizaciones de Salesforce que están conectadas a la organización de la nube de datos.
Para acceder a datos de objetos de Data Cloud (DLO o DMO), utilice la clase CdpQuery (ver documentos ) en Apex. Esta clase está disponible en el espacio de nombres ConnectApi (ver documentos ).
A continuación se muestra un fragmento de código de ejemplo que muestra cómo acceder a los datos de un objeto de nube de datos mediante una instrucción SQL.
<dx-code-block title language="apex" code-block="@AuraEnabled(cacheable=true)
public static void getSolarPanelData(String customerId) { List<Map> returnData = new List<Map>(); // Create input for query operation ConnectApi.CdpQueryInput queryInput = new ConnectApi.CdpQueryInput(); queryInput.sql = ‘SELECT * ‘ + ‘FROM Solar_Panel_Events_solar_panel_F4C03__dlm ‘ + ‘WHERE CustomerId__c = » + customerId + » ‘ + ‘ORDER BY date_time__c DESC LIMIT 50’; // Execute SQL ConnectApi.CdpQueryOutputV2 response = ConnectApi.CdpQuery.queryAnsiSqlV2( queryInput ); Map responseMetadata = new Map(); responseMetadata = response.metadata; // Parse response System.debug( ‘Number of rows in the result data set ‘ + response.rowCount ); System.debug(‘Next batch ID ‘ + response.nextBatchId); System.debug(‘Query Metadata’ + responseMetadata); for (ConnectApi.CdpQueryV2Row resultRow : response.data) { for (Object result : resultRow.rowData) { system.debug(result); } } «>
En el ejemplo anterior, estamos recuperando datos para un componente LWC personalizado en una página Lightning de caso de objeto estándar para un agente de servicio. El componente muestra datos de dispositivos recientes provenientes de los paneles instalados en el sitio del cliente.
customerId , lo que indica que recupera los datos del panel solar para un cliente específicoConnectApi.CdpQueryInput llamada queryInput para definir la operación de consulta.queryInput.sql se establece con una consulta SQL que selecciona todos los campos del objeto de datos Solar_Panel_Events_solar_panel_F4C03__dlm , filtrado por CustomerId__cConnectApi.CdpQuery.queryAnsiSqlV2(queryInput) , que devuelve un objeto ConnectApi.CdpQueryOutputV2 denominado responseresponse.metadata se asigna a responseMetadata , que almacena los metadatos de la respuesta de la consulta.recordId con el que está trabajando) para limitar la cantidad de filas y evitar alcanzar el límite de CPU de 10 segundos.queryAnsiSqlV2 (consulte los documentos ) en lugar de queryAnsiSql para aprovechar las solicitudes posteriores y los tamaños de respuesta más grandes para casos de uso en los que necesita extraer grandes volúmenes de datos.nextBatchAnsiSqlV2(nextBatchId) (ver documentos ) para proporcionar batchId de la respuesta anterior para recuperar el siguiente conjunto de resultados.Antes de analizar cómo buscar información de perfil de Data Cloud en Apex, debemos comprender qué es un perfil unificado.
Supongamos que Solar Circles, nuestro fabricante ficticio de paneles solares, tiene datos sobre un cliente llamado Martha en varios sistemas. Cada sistema tiene información diferente sobre ella, como diferentes direcciones de correo electrónico. Estos datos únicos se denominan puntos de contacto . Los clientes como Martha están representados por múltiples registros de contacto y perfiles específicos del sistema en varios sistemas. Esto es necesario para que cada nube y producto funcione de forma independiente, pero puede crear silos de datos.
Data Cloud proporciona una función de resolución de identidad para resolver este problema. Mediante el uso de reglas de identidad , el sistema crea perfiles individuales unificados que se pueden usar para segmentación y activaciones en varios otros sistemas.
A continuación se muestra un código Apex de utilidad de ejemplo que busca información de perfil. Tenga en cuenta que se utiliza el método queryProfileApi de la clase ConnectApi.CdpQuery .
<dx-code-block title language="apex" code-block=" @AuraEnabled public static List
Aquí hay un fragmento de código de ejemplo que invoca el código de utilidad anterior al pasar los parámetros.
<dx-code-block title language="apex" code-block=" List
El código busca la información de perfil del cliente Martha en el objeto de modelo de datos UnifiedIndividual__dlm .
ConnectApi.CdpQuery.queryProfileApi() para ejecutar la consulta de datos de perfil en la nube de datosdataModelName ), el objeto del modelo de datos secundario ( childDataModelName ), el campo de clave de búsqueda ( searchKey ) y el nombre del cliente ( customerName )ConnectApi.CdpQueryOutput llamado responseresponse.data , que representa los datos recuperados de la consultaLos conocimientos calculados le permiten definir y calcular métricas multidimensionales en todo su estado digital en Data Cloud. Data Cloud genera información calculada al escribir SQL , de manera declarativa usando Insights Builder o usando Apex.
Hay dos tipos de información en Data Cloud: transmisión e información calculada.
Los conocimientos calculados son funciones que pueden calcular métricas en datos históricos. Se procesan en lotes. Por ejemplo, en nuestra aplicación Solar Circles, podemos tener una visión calculada que mide la potencia total generada por los paneles agrupados por cada cliente.
La información de transmisión se genera casi en tiempo real mediante el análisis del flujo continuo de datos entrantes. Estos conocimientos permiten la activación inmediata de acciones en los sistemas posteriores. Por ejemplo, la información de transmisión se puede utilizar para identificar a los clientes cuyos paneles solares generan una potencia mínima. Al aprovechar una acción de datos en la transmisión de conocimientos, podemos crear de manera proactiva un caso para dichos clientes en Salesforce Service Cloud.
Para consultar datos de las perspectivas calculadas, use el método queryCalculatedInsights de la clase CdpQuery . A continuación se muestra un fragmento de código de ejemplo que muestra cómo consultar datos de una perspectiva calculada conocida.
queryCalculatedInsights de ConnectApi.CdpQuery se usa para recuperar información calculada de Data Cloud.__cio . Por ejemplo, <calculted insight api name> podría reemplazarse por totalpowergenerated__cio .null para estos parámetros incluye todas las dimensiones y medidas disponibles.null .ConnectApi.CdpQueryOutput denominado response .En esta publicación de blog, brindamos una descripción general de cómo puede aprovechar el poder de Salesforce Data Cloud y Apex para aprovechar los grandes datos para las empresas. Los ejemplos de código y los puntos destacados demuestran enfoques prácticos para acceder y consultar datos de objetos de Data Cloud.
La publicación también destaca las mejores prácticas y las limitaciones que se deben tener en cuenta al trabajar con Data Cloud y Apex, como administrar los límites de la CPU, utilizar el procesamiento asincrónico para grandes conjuntos de datos y garantizar la denominación correcta de la API para los conocimientos calculados.
En la siguiente parte de la serie, profundizaremos en las clases de Apex como CdpCalculatedInsight (consulte los documentos ), CdpIdentityResolution (consulte los documentos ) y CdpSegment (consulte los documentos ) que se pueden usar para administrar información calculada, crear reglas de resolución de identidad y segmentación en Data Cloud mediante Apex.
Mohith Shrivastava es promotor de desarrollo en Salesforce con una década de experiencia en la creación de productos a escala empresarial en la plataforma de Salesforce. Actualmente se está enfocando en las herramientas para desarrolladores de Salesforce, Flow, Apex y Lightning Web Components en Salesforce. Mohith se encuentra actualmente entre los principales contribuyentes en Salesforce Stack Exchange, un foro de desarrolladores donde los desarrolladores de Salesforce pueden hacer preguntas y compartir conocimientos. Puedes seguirlo a través de su Twitter @msrivastav13 .
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.
…
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.
Event Platform consta de diferentes funciones que le permiten crear arquitecturas basadas en eventos gracias a Salesforce Event Bus.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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 .
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 .
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.
…
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 .
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.
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 ) .
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.
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) .
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!
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 .
Agregar a Slack Suscríbete a RSS
Última actualización el 6 de julio de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
Jestilla Zetkin trabaja como arquitecta de Salesforce en Gurukul On Cloud (GoC), recientemente se encontró con una publicación de blog titulada Monitoreo de publicación de eventos y uso de entrega de la plataforma . Esta publicación proporcionó información sobre cómo varias formas de monitorear el uso de la publicación y entrega de eventos de la plataforma.
A medida que se expande el negocio de GoC, la afluencia de datos ha llevado a casos frecuentes de alcanzar los límites diarios para los eventos de la plataforma. En consecuencia, Jestilla está buscando una solución para monitorear el consumo de eventos de la plataforma según el nombre del evento, la identificación del cliente o el tipo. Esta capacidad de monitoreo le permitirá analizar qué evento está consumiendo una parte significativa de la asignación, lo que le permitirá tomar las medidas adecuadas en consecuencia.
Las arquitecturas basadas en eventos se han vuelto muy populares en los últimos años y por una buena razón. Se basa en el patrón de fuego y olvido . Activar un evento y dejar que cada sistema maneje la lógica empresarial le permite mantener los sistemas no relacionados desacoplados y puede ayudar a simplificar la arquitectura.
Los eventos de la plataforma le permiten entregar notificaciones de eventos seguras, escalables y personalizables dentro de Salesforce o desde fuentes externas. Las aplicaciones pueden publicar y suscribirse a eventos de plataforma en la plataforma de Salesforce mediante Apex, Flow o en un sistema externo mediante CometD. Si desea obtener más información sobre el evento de plataforma, consulte el módulo de Trailhead .
Hagamos una pausa aquí y familiarícese con el objeto PlatformEventUsageMetric en Salesforce.
Contiene datos de uso para la publicación y entrega de eventos a clientes CometD y Pub/Sub API, componentes empApi Lightning y retransmisiones de eventos. Si las métricas de uso mejoradas están habilitadas, los datos de uso están disponibles para las últimas 24 horas, hasta la última hora y para el uso diario histórico.
En API 58.0 y versiones posteriores, puede habilitar Métricas de uso mejoradas para obtener datos de uso por nombre de evento y cliente para intervalos de tiempo granulares. PlatformEventUsageMetric contiene métricas de uso separadas para eventos de plataforma y eventos de captura de datos modificados.
| Nombre del campo |
Detalles |
| Tipo de evento | El tipo de evento para el que le gustaría consultar las métricas de uso, como un evento de cambio o un evento de plataforma personalizado. Este campo está disponible cuando las métricas de uso mejoradas están habilitadas. |
| Segmento de tiempo | El intervalo de tiempo utilizado para agregar los datos de uso devueltos en los resultados de la consulta. Este campo está disponible cuando las métricas de uso mejoradas están habilitadas. |
| Tipo de uso | Este campo está disponible cuando las métricas de uso mejoradas están habilitadas. El tipo de métricas de uso de eventos para consultar, como publicación de eventos o entrega de eventos. Utilice este campo con los campos EventName o EventType. Los valores posibles son:
|
| Valor | El valor de uso para la métrica y el intervalo de fechas especificados. |
Para obtener datos de uso completos para cada evento, aprovecharemos las métricas de uso de eventos mejoradas. Esta función nos permitirá recopilar información agregada e identificar los eventos específicos que consumen una parte importante de la asignación.
Mientras que PlatformEventSettings representa configuraciones para eventos de plataforma y eventos de captura de datos modificados.
| Nombre del campo |
Detalles |
| enableEnhancedUsageMetrics | Habilita métricas de uso mejoradas para consultas ejecutadas en PlatformEventUsageMetric. Las métricas de uso mejoradas proporcionan campos adicionales para las consultas y segmentos de tiempo granulares. Para obtener más información, consulte Métricas de uso mejoradas en la Guía para desarrolladores de eventos de plataforma. El valor predeterminado es falso. |
Antes de que pueda obtener más métricas de uso, debe habilitar las Métricas de uso mejoradas en la API de metadatos . Para hacer esto, establezca el valor del campo enableEnhancedUsageMetrics en verdadero en PlatformEventSettings . Una vez hecho esto, podrá obtener métricas de uso detalladas para el consumo de eventos de la plataforma.
SELECCIONE EventName, EventType, UsageType, Value, StartDate, EndDate FROM PlatformEventUsageMetric WHERE TimeSegment='Diario'
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
Última actualización el 29 de junio de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
Jestilla Zetkin se desempeña actualmente como arquitecta de Salesforce en Gurukul On Cloud (GoC). El Director Comercial le ha confiado a Jestilla un desafío único. El objetivo es asegurarse de que, en el momento de la creación, los prospectos de Salesforce (creados a través de Web-to-lead) reciban los detalles exactos de la zona horaria, que se determinan en función de sus respectivas coordenadas geográficas.
Hay muchas posibilidades de que su base de clientes esté repartida en varias zonas horarias. Este factor puede influir en gran medida en sus interacciones con ellos, especialmente al programar llamadas, reuniones o enviar mensajes automáticos. La plataforma de Salesforce ofrece un entorno altamente adaptable para almacenar y administrar datos de clientes, pero de forma predeterminada, no proporciona una forma de registrar automáticamente la zona horaria del cliente potencial en función de sus coordenadas geográficas.
La API de zona horaria de Google es un servicio ofrecido por Google como parte de su plataforma Google Maps. La API proporciona datos de zona horaria para cualquier ubicación en todo el mundo en función de las coordenadas de latitud y longitud. Este servicio puede ser particularmente útil para los desarrolladores que necesitan ajustar la comunicación de acuerdo con la ubicación geográfica de un cliente potencial o contacto o para empresas que operan en diferentes zonas horarias.
La API de zona horaria proporciona la siguiente información:
Tenga en cuenta que la API de zona horaria de Google está sujeta a cargos, por lo que es importante comprender las implicaciones de costos antes de implementarla.
La API de zona horaria de Google funciona tomando coordenadas de latitud y longitud y devolviendo datos de zona horaria en formato JSON. Aquí hay un ejemplo básico de cómo usarlo.
La siguiente solicitud HTTP GET obtiene información de zona horaria para una ubicación en la latitud 40.712776 y longitud -74.005974 (ciudad de Nueva York), y asume que está realizando la solicitud en una determinada marca de tiempo (marca de tiempo UNIX).
https://maps.googleapis.com/maps/api/timezone/json?location=40.712776,-74.005974×tamp=1458000000&key=YOUR_API_KEY
En la URL de solicitud anterior, reemplace YOUR_API_KEY con su clave API real.
Aquí hay una respuesta de muestra en formato JSON que la API podría devolver:
{ "dstOffset": 3600, "compensación sin procesar": -18000, "estado": "OK", "timeZoneId": "América/Nueva_York", "timeZoneName" : "Hora de verano del Este" }
La respuesta incluye la siguiente información:
Recuerde, en la URL de solicitud, se requiere el parámetro de marca de tiempo y el parámetro de ubicación espera coordenadas de latitud y longitud.
Además, no olvide incluir su clave API.
La API de zona horaria de Google ofrece una serie de beneficios significativos, especialmente para desarrolladores y empresas que necesitan operar en diferentes zonas horarias. Estos son algunos de los beneficios clave:
Al aprovechar estos beneficios, las empresas pueden mejorar la experiencia del cliente, aumentar la eficiencia operativa y garantizar un registro de datos preciso, entre otras ventajas.
Antes de comenzar a usar la API de zona horaria, necesita un proyecto con una cuenta de facturación y la API de zona horaria habilitada. Aquí hay una guía paso a paso para configurar su proyecto de Google Cloud y habilitar la API de zona horaria:
Debe vincular una cuenta de facturación a su proyecto para usar la API de zona horaria de Google. Así es cómo:
Una vez que haya configurado su proyecto y su cuenta de facturación, puede habilitar la API de zona horaria.
Finalmente, necesita una clave de API para autenticar sus solicitudes en la API de zona horaria.
Ahora, su proyecto de Google Cloud está todo configurado y puede comenzar a usar la API de zona horaria de Google.
👉 Si bien la API de zona horaria es compatible con OAuth 2.0 y la cuenta de servicio para la autenticación, esta guía se enfoca en el método de clave de API más simple por razones de brevedad. Si necesita un método de autenticación más seguro o complejo, consulte la documentación de autenticación oficial de Google.
Si bien esto se puede resolver utilizando varias herramientas de automatización como Apex Trigger y otras, utilizaremos Salesforce Flow y la función de flujo HTTP Callout (GET) recientemente introducida .
HTTP Callout extrae o envía datos entre la base de datos de Salesforce y un sistema externo a través de Flow Builder sin usar código. Puede configurar integraciones directas según sea necesario sin tener que trabajar con un desarrollador o llamar a una herramienta de middleware, como Mulesoft. Después de configurar la acción de llamada HTTP en un flujo, Flow Builder genera automáticamente un registro de servicio externo , una acción invocable y una clase de Apex que puede usar para crear un recurso definido por Apex para flujos. A continuación, puede utilizar la salida de datos de la solicitud de la API como entrada en Flow Builder y en Salesforce.
Puede usar HTTP Callout para conectar un flujo a una variedad de API.
Antes de discutir la solución, permítame mostrarle un diagrama del proceso a un alto nivel. Dedique unos minutos a revisar el siguiente diagrama de flujo para comprenderlo.
Comencemos a construir este proceso de automatización.
Hay 3 pasos para resolver el requisito empresarial de Jestilla mediante Record-Triggered After-Save Flow . Debemos:
En este paso, hemos establecido campos personalizados dentro del objeto principal. Estos servirán como repositorios para los datos de respuesta de la API de zona horaria de Google.
| Etiqueta de campo | Nombre de API de campo | Tipo de datos |
| dstOffset | dstOffset __c | Número (18,0) |
| rawOffset | rawOffset__c | Número (18,0) |
| Posición actual | Posición_actual__c | Geolocalización |
| Identificación de zona horaria | Time_Zone_Id__c | Texto (255) |
| Nombre de zona horaria |
Nombre_de_la_zona_horaria__c | Texto (255) |
Paso 3.3: configurar una acción de llamada HTTP GET
HTTP Callout lo guía a través de la introducción de los detalles sobre el servicio HTTP basado en web o el punto final de la API REST al que se está conectando. Después de completar la configuración, invoca la acción en un flujo.
{ "timeZoneName": "cadena de muestra", "compensación sin procesar": 1, "timeZoneId": "cadena de muestra", "errorMessage": "cadena de muestra", "dstOffset": 1, "estado": "cadena de muestra"
}
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.
…
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.
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.
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.
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.
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:
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 ).
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 .
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.
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 ).
planDelivery planDelivery Ahora que sabe cómo impulsar el comportamiento de su simulacro, puede agregar aserciones para probar su código.
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 .
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.
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!
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 .
Agregar a Slack Suscríbete a RSS
Última actualización el 15 de junio de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
👉 En el pasado escribí algunos artículos sobre Apex . ¿Por qué no echarles un vistazo mientras estás en ello?
Isabella Stewart trabaja como administradora de Salesforce en Gurukul On Cloud (GoC). Aunque es relativamente nueva en la programación de Apex, está ansiosa por explorar diferentes métodos para programar clases por lotes en Salesforce y ampliar su conocimiento en esta área.
En Salesforce, un trabajo programado se refiere a una función que permite a los administradores y desarrolladores programar la ejecución automática de clases de Batch en momentos o intervalos específicos.
Los trabajos programados en Salesforce generalmente se usan para realizar varias acciones, como actualizaciones de datos, procesamiento de registros, envío de notificaciones por correo electrónico, generación de archivos PDF e integración con sistemas externos. Pueden ser particularmente útiles para tareas que deben realizarse a intervalos regulares, como por hora, día, semana o mes.
👉 Para programar una clase de Apex para que se ejecute a intervalos regulares, primero escriba una clase de Apex que implemente la interfaz Schedulable proporcionada por Salesforce.
la clase global ScheduleAccountSync implementa Programable { ejecución de vacío global (Contexto programable SC) { AccounSync ASync = new AccounSync(); } }
Para crear un trabajo programado en Salesforce, puede usar Apex Scheduler a través de la configuración de Salesforce o el método System.schedule desde Developer Console (Ejecutar anónimo).
👉 Puede monitorear el progreso del trabajo en la página Todos los trabajos programados .
Una limitación clave de Apex Scheduler radica en su incapacidad para ejecutar una tarea cada pocos minutos, cada seis horas o en días específicos, como el primer lunes o el último día hábil del mes. Para abordar esto, podemos utilizar el método System.schedule a través de la consola del desarrollador, que permite escenarios de programación más complejos.
Cuando una clase se implementa con la interfaz Schedulable , se puede usar el método System.schedule para ejecutarla. En particular, el programador opera a nivel del sistema, lo que garantiza que todas las clases se ejecuten independientemente de los permisos de los usuarios individuales.
El método System.schedule toma tres parámetros: el nombre del trabajo, una expresión que indica la hora y la fecha programadas para la ejecución del trabajo y el nombre de la clase. La estructura de la expresión cron es la siguiente:
Los siguientes son los valores de la expresión:
| Nombre | Valores | Caracteres especiales |
|---|---|---|
| Segundos | 0–59 | Ninguno |
| Minutos | 0–59 | Ninguno |
| Horas | 0–23 | , – * / |
| Dia del mes | 1–31 | , – * ? / LW |
| Mes | 1–12 o lo siguiente:
|
, – * / |
| Día de la semana | 1–7 o lo siguiente:
|
, – * ? / L # |
| año_opcional | nulo o 1970–2099 | , – * / |
Lea esta guía para desarrolladores de Salesforce para obtener más información sobre el método System.Schedule. No es posible actualizar los trabajos programados. Debe eliminar el trabajo existente y luego programarlo nuevamente.
Por ejemplo, si desea ejecutar la clase de Apex ScheduledAccountSync cada hora, específicamente cinco minutos después de cada hora, ejecute la siguiente declaración a través de Ejecutar de forma anónima en Developer Console.
System.schedule('AccountSyncJob', '0 5 * * * ?', new ScheduleAccountSync()); //AccountSyncJob = Nombre del trabajo //0 5 * * * ? = Expresión cron //ScheduleAccountSync = Clase de Apex con interfaz programable
También puede usar CronMaker , una aplicación simple que lo ayuda a crear expresiones cron para su escenario.
Aquí hay varios ejemplos que ilustran cómo utilizar la expresión cron.
Para programar un trabajo para que se ejecute cada seis horas de lunes a viernes, ejecute la siguiente expresión cron:
System.schedule('AccountSyncJobWeekDayPerSixHour', '0 0 0,6,12,18 ? * MON-FRI', new ScheduleAccountSync());
Para programar un trabajo para que se ejecute cada cuatro horas diariamente, ejecute la siguiente expresión cron:
System.schedule('AccountSyncJobEveryFourHour', '0 0 0/4 * * ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecuta cada hora a lo largo de cada día, utilice la siguiente expresión cron:
System.schedule('AccountSyncJobEveryHour', '0 0 0/1 * * ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecuta cada media hora todos los días, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob0', '0 0 * * * ? *', new ScheduleAccountSync()); System.schedule('AccountSyncJob30', '0 30 * * * ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute una vez al día a las 22:00, utilice la siguiente expresión cron:
System.schedule('AccountSyncJobOnceInADay', '0 0 22 * * ?', new ScheduleAccountSync());
Para programar un trabajo que se ejecute los viernes y sábados a las 11:00 p. m., utilice la siguiente expresión cron:
System.schedule('AccountSyncJobVie-Sat', '0 0 23 ? * FRI,SAT *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute el viernes a las 11:00 a. m., utilice la siguiente expresión cron:
System.schedule('AccountSyncJobFriOnly', '0 0 23 ? * VIE *', new ScheduleAccountSync());
Para programar un trabajo que se ejecuta el primer día de cada año, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob-1er día del año', '0 0 1 1 1 ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute el último día de cada mes, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob-Último día del mes', '0 0 1 L * ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute el último viernes de cada mes, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob-Last Friday', '0 0 1 ? * 6L *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute cada día 15 del mes, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob-Every 15th', '0 1 0 15 * ? *', new ScheduleAccountSync());
Para programar un trabajo que se ejecute el primer y tercer domingo de cada mes, utilice la siguiente expresión cron:
System.schedule('AccountSyncJob-1st Sunday', '0 0 2 ? 1/1 SUN#1 *', new ScheduleAccountSync()); System.schedule('AccountSyncJob-3rd Sunday', '0 0 2 ? 1/1 SUN#3 *', new ScheduleAccountSync());
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Esta es una traducción 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.
…
Apex es una habilidad única que los desarrolladores deben dominar al crear soluciones personalizadas con Salesforce. Hay algunos conceptos básicos que son esenciales. Ciertas cosas, como la sintaxis y el flujo de control, son como aprender cualquier otro idioma. Otras cosas, como operaciones masivas, límites reguladores y disparadores, son particulares de Apex y cómo se implementa en la Plataforma de Salesforce. Una vez que tenga una idea de estas características y modismos clave, ¿a dónde va después?
En esta publicación, aprenderá sobre algunas características de Apex que son críticas para cualquier desarrollador de Apex que busque mejorar más allá de lo básico, junto con dónde puede ir para aprender sobre ellas.
Nota: Siempre que sea posible, los ejemplos de código en esta publicación se toman directamente o se adaptan de la aplicación de muestra Recetas de Apex o la Guía para desarrolladores de Apex. Ver las referencias al final del artículo.
En estos días, si desea un proceso automatizado o una interfaz de usuario similar a un asistente, Flow siempre debe ser una opción que considere. El alcance, la flexibilidad y la madurez de Flow han crecido enormemente. Aún así, es raro que los problemas comerciales complejos se puedan resolver sin ningún tipo de código.
Introduzca Apex invocable.
La anotación @InvocableMethod se usa para definir métodos llamados por Flow. Y @InvocableVariable muestra los parámetros para que Flow pase datos a su código Apex. ¿Por qué llamaría a Apex desde Flow? Quizás la lógica de su flujo se está volviendo demasiado compleja. Tal vez su automatización necesite realizar una operación que no sea accesible para Flow. En casos como estos, Apex puede ser su amigo.
Aquí hay una ilustración básica del uso de la anotación @InvocableMethod :
<dx-code-block title language="java" code-block="public class AccountQueryAction { @InvocableMethod(label='Get Account Names' description='Returns the list of account names corresponding to the specified account IDs.' category='Account') public static List getAccountNames(List ids) { List accountNames = new List(); List accounts = [SELECT Name FROM Account WHERE Id in :ids]; for (Account account : accounts) { accountNames.add(account.Name); } return accountNames; } }»>
Este ejemplo de la Guía para desarrolladores de Apex ilustra cómo la anotación marca esto como un método que Flow puede invocar. Tenga en cuenta que la anotación también define detalles como una etiqueta y una descripción que determinan lo que se muestra al usuario de Flow Builder.
Un efecto secundario importante de las anotaciones de @Invocable… del que pocas personas hablan es que esto muestra automáticamente su Apex al punto final de la API <INSTANCEURL>/data/<VERSION>/actions/custom/apex .
Otra cosa útil que puede hacer al invocar Apex desde su flujo es acceder a los diferentes tipos de Apex asíncrono. Lo que trae a colación la siguiente característica de Apex que se debe abordar.
La ejecución asíncrona desacopla una acción que queremos realizar del contexto de ejecución actual. Siguiendo las mejores prácticas actuales, existen tres formas de ejecutar Apex de forma asincrónica: en cola, programable y por lotes. Aunque técnicamente el bus de eventos es asíncrono, lo omitiremos por el momento.
Si solo necesita activar un poco de código para ejecutarlo de forma asincrónica, la opción en cola es la herramienta de referencia. Si tiene varias tareas asincrónicas, queueable las ejecuta de manera determinista en orden. Debido a que están en cola en orden, también puede encadenar una llamada asíncrona de otra. Y Apex en cola admite entradas de objetos o tipos primitivos.
Apex programado funciona tal como lo esperaría: ejecute algún código de Apex en un horario. Batch Apex está optimizado para trabajar con conjuntos de datos muy grandes. Para utilizar Apex asíncrono, debe crear una clase de Apex que implemente una interfaz específica: Queueable , Schedulable o Batchable , respectivamente.
Nota: algunos desarrolladores pueden estar familiarizados con la anotación @Future para hacer que un solo método sea asincrónico, también conocido como "métodos futuros". Los métodos futuros, aunque rápidos y fáciles, tienen limitaciones que los hacen menos útiles. No hay nada que pueda hacer con un método futuro que no se pueda hacer mejor con una clase en cola. Por este motivo, no recomendamos implementaciones de producción con métodos futuros.
Por lo tanto, echemos un vistazo a un ejemplo de una clase de Apex que se puede poner en cola.
<dx-code-block title language="Java" code-block="public with sharing class QueueableRecipes implements Queueable { public static void execute(QueueableContext qc) { List accounts = [ SELECT Id, Description FROM Account LIMIT 1000 ]; for (Account acct : accounts) { acct.Description += ‘ Edited by Queueable class’; } try { update accounts; } catch (DmlException dmle) { System.debug( LoggingLevel.INFO, ‘real life use cases should do more than just logging the error: ‘ + dmle.getMessage() ); } }
} «>
Todas las interfaces asíncronas de Apex tienen un método execute() que debe implementarse como se muestra arriba. Para ejecutar su clase Queueable , debe ponerla en cola.
Si bien no se muestra en este ejemplo de la aplicación de muestra Recetas de Apex, para pasar datos a su cola, anule el constructor con los parámetros que necesita.
El término "Apex dinámico" es un poco inapropiado. O, al menos, podría malinterpretarse como que Apex de alguna manera funciona como un lenguaje de programación dinámico. Esto no es a lo que se refiere (por ejemplo, no hay Apex
función eval !).
Dynamic Apex es un código que se adapta a diferentes tipos de SObject ( Account , Contact , My_Custom_Object__c , etc.) en tiempo de ejecución. Esto se hace abstrayendo referencias específicas de SObject. La clave es usar la superclase SObject cuando se trabaja con datos. También utilizará las funciones de "descripción" de Apex para detectar con qué objetos y campos está trabajando y qué puede hacer con ellos (por ejemplo, si este usuario puede consultar este objeto).
Esta es una habilidad esencial para los desarrolladores de ISV. A menudo, creará una aplicación que debe adaptarse al entorno local del cliente que instala su aplicación. Esto significa que su código necesita detectar, describir y adaptar su comportamiento dependiendo de datos conocidos o incluso desconocidos.
Aunque es esencial para un desarrollador de ISV, también es importante para cualquier persona que quiera escribir código más reutilizable.
Tome este ejemplo de consulta muy básico:
<dx-code-block title language="Java" code-block="List accts = [SELECT Id, Name, Website FROM Account];»>
Esto funcionará todo el día consultando los datos de la cuenta. Pero, ¿y si queremos construir una consulta para cualquier SObject?
Para convertir esto en un Apex "dinámico", necesitamos abstraer las referencias de campo y SObject específicas. Y tal vez lo incluiríamos en un método que permitiera a otro desarrollador pasarlos. También podríamos verificar para asegurarnos de que el usuario tenga los permisos de objeto para realizar la operación que estamos a punto de intentar.
<dx-code-block title language="Java" code-block="public static List executeDynamicQuery(Schema.DescribeSObjectResult obj, List fields){ // Create a result-set list List resultRecords; if (obj.isQueryable()){ // Set up a query string String queryTemplate = ‘SELECT {0} FROM {1}’; List queryDetails = new List{String.join(fields, ‘, ‘), obj.getName()}; String queryString = String.format(queryTemplate, queryDetails); // Run your query resultRecords = Database.query(queryString); } return resultRecords; } «>
Lo anterior construye una consulta para un SObject que se pasa al método y una lista arbitraria de campos. Utiliza el objeto DescribeSObjectResult para detectar la capacidad de consulta e inferir el nombre de la API de SObject al construir y ejecutar la consulta. A continuación, debe invocarlo.
Así es como podríamos hacer eso con los objetos Cuenta y Contacto, respectivamente:
<dx-code-block title language="Java" code-block="List accountRecords = DynamicApexClass.dynamicQuery(Account.SObjectType.getDescribe(), new List{‘Id’,’Name’,’Website’}); List contactRecords = DynamicApexClass.dynamicQuery(Contact.SObjectType.getDescribe(), new List{‘Id’,’FirstName’,’LastName’}); «>
Este ejemplo no aborda algunos riesgos de SOQL dinámico, como la inyección de SOQL. Por lo tanto, asegúrese de leer sobre Apex dinámico. Aprender a escribir Apex seguro hará que sea menos probable que implemente código vulnerable en su organización (o la de un cliente). El enlace de variables en sus consultas SOQL es una herramienta clave para proteger su Apex dinámico de ser explotado. El método escapeSingleQuotes() es otra herramienta más antigua que también puede encontrar. El modo de usuario también es clave para garantizar que cualquier acción realizada tenga que cumplir con todas y cada una de las restricciones del usuario que la ejecuta.
Para obtener un ejemplo más completo y seguro de Apex dinámico, consulte la receta de Apex del método invocable en la aplicación de ejemplo Recetas de Apex. Esa acción invocable funciona con el objeto Cuenta o Tarea.
Con Salesforce, hay algunas formas de realizar la integración sin código. Específicamente, si solo necesita una aplicación o servicio de cliente para obtener datos de Salesforce, hay muchas API que se muestran automáticamente sin ningún tipo de codificación en el lado de Salesforce. Incluso se ajustan a su esquema personalizado. Si está integrando su organización a un sistema externo compatible con OData, puede usar Salesforce Connect y objetos externos (nuevamente, no se requiere código).
Pero a veces, es posible que deba llamar desde su organización a un servicio externo. O tal vez desee mostrar un punto final personalizado que agrupe más complejidad que una de las API estándar. Nuevamente, Apex contiene funciones que admiten tanto la aparición de nuevas API personalizadas como la llamada a servicios web.
Al pensar en API personalizadas, en estos días, la mayoría de los desarrolladores pensarían en API REST. Puede crear una API REST personalizada en Salesforce Platform creando una clase de Apex que se anota con la anotación @RestResource . Parte del trabajo de la anotación es definir también el nombre del recurso. Todas las API REST personalizadas basadas en Apex se encuentran en <INSTANCEURL>/services/apexrest/ .
Para definir los comportamientos que necesita admitir, hay una serie de anotaciones de métodos que corresponden a verbos HTTP, como @HttpGet y @HttpPost . La clase RestContext contiene un conjunto de elementos de acceso para obtener el estado de la solicitud HTTP entrante y la respuesta saliente que devuelve. A continuación, se muestra un ejemplo de un extremo REST básico que aparece en el método HTTP GET. Tenga en cuenta cómo se utilizan las anotaciones.
<dx-code-block title language="Java" code-block="@RestResource(urlmapping='/integration-service/*')
global inherited sharing class CustomRestEndpointRecipes( … @HttpGet global static String getRecordsToReturn() { RestResponse response = RestContext.response; try { List accounts = [ SELECT Id, Name, Phone, Website FROM Account WITH USER_MODE ]; response.statusCode = 200; String serializedAccounts = JSON.serialize(accounts); return serializedAccounts; } catch (QueryException qe) { System.debug( LoggingLevel.INFO, ‘Failed to query a list of Accounts. Error is: ‘ + qe.getMessage() ); response.statusCode = 400; return qe.getMessage(); } }
} «>
Si su requisito es crear un servicio SOAP, también hay un conjunto de características para admitir ese protocolo.
Fuera del código real, necesitará una sesión autorizada para acceder a cualquier servicio web que cree. Pero si ya tiene un cliente autorizado, la solicitud es solo otra llamada al punto final personalizado que defina.
La llamada a un punto final REST externo se realiza a través de un conjunto de clases. La clase HttpRequest le permite definir los parámetros de cómo se comportará su solicitud (punto final, verbo HTTP, encabezados, etc.). La solicitud se realiza a través del método estático Http.request() . Esto devuelve un objeto HttpResponse que le proporciona los datos devueltos o el error si la solicitud falla.
Nota: Las clases HttpRequest y HttpResponse son las mismas para las llamadas REST y los servicios REST personalizados.
Se requiere cierta configuración para su texto destacado. Específicamente, deberá configurar una credencial con nombre en la mayoría de los casos. Esta configuración le permite descargar el protocolo de enlace de autenticación de su código. Aunque, si está llamando a un servicio anónimo no autenticado, también puede optar por usar una configuración de sitio remoto más simple.
= 200 && response.getStatusCode()
El ejemplo anterior hace una llamada simple a un punto final. Tenga en cuenta que no se utilizan las opciones para establecer encabezados ni usar una credencial con nombre, ya que esta solicitud es para una API simple que no requiere autenticación.
La transmisión de eventos es una herramienta valiosa para crear arquitecturas débilmente acopladas en aplicaciones complejas. La plataforma de Salesforce implementa la transmisión de eventos a través de dos características principales: eventos de plataforma y captura de datos modificados. La columna vertebral de estas funciones es el bus de eventos.
De la Guía para desarrolladores de eventos de plataforma, el bus de eventos es "Un servicio de entrega y almacenamiento de eventos de múltiples inquilinos y múltiples nubes basado en un modelo de publicación-suscripción". Tanto su organización como los sistemas externos pueden publicar y suscribirse a eventos. Por supuesto, es clave que si publicas un mensaje, algo debe haberse suscrito para que suceda cualquier otra cosa.
Los eventos de plataforma representan los datos que pasan a través del bus de eventos. Los eventos se procesan en el orden en que se reciben. Una forma de pensar en ellos es como un SObject efímero que se almacena temporalmente en el bus de eventos en su camino hacia su destino. De hecho, los metadatos de un evento se almacenan en el mismo lugar de su proyecto que sus SObjects. Puede distinguir los eventos de plataforma personalizados de los SObjects por su sufijo __e (por ejemplo Order_Complete__e ).
Una vez que completa un evento con sus datos, el método EventBus.publish() es similar a una llamada DML en su SObject normal. Tenga en cuenta el código a continuación que publica un evento.
En Apex, se suscribe a un evento creando un disparador asíncrono para él. Pero los disparadores asíncronos son diferentes de la operación DML transaccional estándar de un disparador normal. Por esta razón, debe tener en cuenta algunas diferencias. Con disparadores asíncronos, el tamaño del lote es diferente. Necesitas configurar tu usuario de ejecución. Las operaciones de activación de eventos también se pueden volver a intentar. Asegúrese de conocer estas diferencias a medida que comience a implementar activadores de eventos de plataforma. Tenga en cuenta el disparador a continuación.
A diferencia de los disparadores DML típicos, los disparadores de eventos de plataforma solo admiten el contexto after insert . Tampoco existe una acción explícita para suscribir un disparador a un evento de plataforma. Una vez que el activador se implementa en su organización, se suscribe automáticamente.
Además de Apex, los eventos de la plataforma pueden activarse y suscribirse mediante sistemas externos y Flow. Son clave en las integraciones débilmente acopladas. Como tal, es raro que Apex active y se suscriba al mismo evento.
Hemos cubierto mucho. Pero de ninguna manera esto es todo lo que necesita saber como desarrollador de Apex. Los elementos cubiertos se basan en algunas características bastante comunes. Pero es posible que deba aprender otras funciones de Apex según los requisitos de su proyecto. Aquí hay algunos otros elementos que debe tener en cuenta.
Caché de plataforma : si proviene de otras plataformas de programación, estará familiarizado con la noción de una variable estática o global persistente en todas las transacciones. Pero en Apex, las estáticas se limitan a la transacción. La memoria caché de la plataforma es una característica de Apex que permite la persistencia de datos en memoria entre transacciones. Si encuentra un retraso en el rendimiento relacionado con la recuperación de datos, la memoria caché de la plataforma puede ayudar.
Marcos de activación : no es una característica del lenguaje, sino bibliotecas que facilitan el uso de activadores. Estos proyectos creados por la comunidad abstraen el código de activación repetitivo que a menudo necesita escribir. Al usar un marco de activación, debería permitirle concentrarse solo en la lógica que debe abordarse. Para algo más que un disparador trivial, se recomienda encarecidamente adoptar un marco. Y conozco a algunos que argumentarían que debería considerar un marco incluso para ese disparador trivial. Pero este no es el lugar para debatir el tiempo de valor frente a la optimización prematura. Hay una implementación muy simple de esto en la aplicación Apex Recipes .
SOSL : el lenguaje de búsqueda de objetos de Salesforce ( SOSL ) es el primo subestimado de SOQL. SOSL permite consultas basadas en texto no deterministas. Es muy eficiente para encontrar datos de texto en comparación con la búsqueda de campos de texto con SOQL y comodines. Admite la búsqueda de varios SObjects simultáneamente y contiene funciones para filtrar de forma determinista los resultados de la búsqueda. Si tiene consultas SOQL de texto que son lentas, definitivamente consulte esta herramienta.
AuraEnabled : para mostrar el código Apex personalizado en sus componentes web Lightning (LWC), esta anotación es clave. Es muy probable que ya esté usando este si comenzó su viaje de Salesforce creando LWC. Pero si aún no lo ha usado, búsquelo en cualquier proyecto que involucre una interfaz de usuario personalizada. ¿Por qué "Aura" habilitado si es para LWC? Bueno, esta anotación se creó inicialmente para admitir el predecesor de LWC, el marco Aura. Tenía sentido no reinventar una nueva anotación cuando la existente funcionaría igual de bien para LWC.
Cada viaje para aprender un nuevo lenguaje de programación tiene algunas características clave que todos deben conocer. La sintaxis básica, el control de flujo y el modelo de ejecución de la plataforma son fundamentales para comprender. Pero una vez que tenga esos conceptos básicos, trabajar en funciones más avanzadas es clave para aumentar su conjunto de habilidades. Las acciones invocables, el Apex asíncrono, el Apex "dinámico", la integración y el bus de eventos son funciones que probablemente utilizará a medida que avanza. Al familiarizarse con estos ahora, no solo se preparará para abordar proyectos en el futuro, sino que también podrá tomar mejores decisiones de solución.
Si cree que está listo para aprender, los senderos para desarrolladores intermedios y avanzados en Trailhead pueden ayudarlo a encaminarse con todos estos temas y más.
Aplicación de muestra Apex Recipes en Github
Guía para desarrolladores de Apex
Guía de referencia de idiomas de Apex
Centro de desarrolladores de Apex
Peter Chittum ha trabajado en software empresarial y habilitación para desarrolladores durante más de 20 años. Pasó los últimos 12 años ayudando a miles de desarrolladores a tener éxito en la plataforma de Salesforce, y más recientemente lideró el equipo de promotores de desarrolladores en Salesforce. Pasa su tiempo libre con su familia, anda en bicicleta de montaña, cocina y toca música. Sígalo en Twitter (@pchittum), LinkedIn (en/PeterChittum) o BlueSky Social (@pchittum.bsky.social).
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.
…
¡Únase a nosotros para Release Readiness Live esta semana! Los expertos en productos y los defensores de los desarrolladores analizarán y demostrarán las nuevas funciones en el lanzamiento de Summer '23 y, al final de nuestra transmisión, responderemos sus preguntas. Sintonice a las 9 am PT el 19 de mayo para la sesión de desarrolladores. ¿No puedes unirte a nosotros en vivo? La grabación se publicará unas horas después de que finalice la transmisión.
El verano finalmente está aquí, y para nosotros los desarrolladores, ¡eso significa un nuevo y emocionante lanzamiento! Exploremos las próximas características que trae la versión Summer '23 para los desarrolladores centrados en la integración de plataformas.
A partir de la API de la plataforma de Salesforce v58.0, SOQL ahora admite consultas de relación que atraviesan hasta cinco niveles de registros primarios y secundarios . Anteriormente, solo se admitía un nivel. Esta característica está disponible para objetos estándar y personalizados, y está limitada a consultas realizadas a través de llamadas de consulta REST y SOAP.
Probémoslo probando una relación padre-hijo de cuatro niveles usando la API REST con la siguiente consulta:
La llamada API ahora devuelve los registros anidados solicitados en la siguiente jerarquía: Cuenta (Nivel 1) → Contacto (Nivel 2) → Caso (Nivel 3) → Comentarios del caso (Nivel 4).
Otra característica útil introducida en esta versión es la capacidad de administrar credenciales con nombre tanto desde la API REST de Connect como desde la API de Connect . Ya no necesita interrumpir su configuración para crear credenciales a través de la interfaz de usuario; ahora, se puede hacer programáticamente,
Por ejemplo, puede recuperar la lista de todas las credenciales con nombre existentes realizando la siguiente llamada a la API:
GET /services/data/v58/named-credentials/named-credential-setup
Alternativamente, puede usar Apex con lo siguiente:
También puede crear credenciales con nombre mediante programación con la API y Apex. Este es un ejemplo de cómo hacerlo con Apex:
Consulte nuestra colección Postman para desarrolladores de Salesforce que presenta las nuevas API de Named Credentials y consulte la documentación de la clase NamedCredentials Apex para obtener más información.
Nuestra API GraphQL sigue mejorando y, con esta versión, estamos agregando soporte para registros de consulta que usan funciones agregadas con o sin agrupación .
Podrá contar la cantidad de registros que coinciden con ciertos criterios, calcular el ingreso promedio en todas las cuentas o ver la cantidad total de todas las oportunidades.
Se admiten las siguientes funciones agregadas:
avg : devuelve el valor promedio de un campo numéricocount : devuelve el número de resultados que coinciden con los criterios de consultacountDistinct : devuelve el número de valores de campo distintos y no nulos que coinciden con los criterios de consultagrouping : especifica si se utiliza un campo al componer el grupo; usar con el argumento de consulta groupBy y el tipo ROLLUP o CUBEmax – Devuelve el valor máximo de un campomin – Devuelve el valor mínimo de un camposum : devuelve la suma total de un campo numérico Echemos un vistazo a una consulta de ejemplo. La siguiente consulta calcula el ingreso anual promedio de todas las cuentas, agrupadas por industria. Tenga en cuenta que estamos usando el campo aggregate en uiapi en lugar de query , lo que nos permite aprovechar las funciones agregadas.
A continuación, una consulta de GraphQL utilizando la función de agregado promedio y la función de agrupación.
También puede realizar consultas tradicionales dentro de la misma solicitud:
Si desea probarlo, puede usar el cliente Altair GraphQL o nuestra colección Postman de desarrolladores de Salesforce .
En febrero de 2023, anunciamos la versión piloto de nuestro adaptador GraphQL de Salesforce Connect y ahora nos complace anunciar que estará disponible de forma general en esta versión de verano de 2023.
El nuevo adaptador de Salesforce Connect para GraphQL actúa como un cliente para integrar datos de fuentes externas que exponen sus capacidades a través de GraphQL. Lo hace de una manera de copia cero al hacer llamadas en vivo a los puntos finales de la API cuando una acción del usuario o del sistema requiere registros específicos. Solo los datos necesarios para esa acción en particular se consultan a través de GraphQL y Salesforce Connect no almacena ni almacena en caché los registros devueltos por el servidor. Además, este adaptador incluye extensiones especiales para AWS AppSync y brinda acceso sin inconvenientes a Amazon RDS.
Para aprovechar este nuevo adaptador, simplemente cree una nueva fuente de datos externa y seleccione el tipo GraphQL .
Con el lanzamiento de Summer '23, ahora puede realizar un seguimiento de la publicación de eventos de la plataforma utilizando Apex Publish Callbacks . Con esta nueva versión, puede obtener el resultado final de una llamada EventBus.publish a través de una devolución de llamada de publicación de Apex que implemente. Esto le da la opción de realizar un seguimiento de los errores o los éxitos para recibir el resultado final de la publicación. En función de ese resultado, puede decidir qué acción tomar, como intentar volver a publicar eventos fallidos, por ejemplo.
Para realizar un seguimiento de un evento fallido publicado, escriba una clase de Apex e implemente la interfaz EventBus.EventPublishFailureCallback . Si la operación asincrónica falla, se invocará el método onFailure . El parámetro result contiene los valores del campo EventUuid para cada evento fallido, pero no incluye los datos del evento en sí.
Para realizar un seguimiento de las publicaciones de eventos exitosas, escriba una clase de Apex e implemente la interfaz EventBus.EventPublishSuccessCallback . Debido a que la mayoría de las llamadas de publicación suelen tener éxito, el procesamiento de publicaciones de eventos exitosas probablemente no sea una preocupación. Observe siempre los límites de rendimiento y del gobernador de Apex cuando procese este tipo de resultado.
Como práctica recomendada, siempre cree eventos usando sObjectType.newSObject , ya que esto incluye un EventUuid que puede usar para rastrear el evento. Al crear eventos con este enfoque, recomendamos no publicar el mismo evento más de una vez para evitar duplicaciones EventUuid .
Con esta actualización, ahora puede obtener métricas de uso de eventos mejoradas para eventos de plataforma consultando el objeto PlatformEventUsageMetric . Esto le permite agregar datos de uso por nombre de evento y determinar qué evento consume más de sus asignaciones. Además, puede agrupar el uso por cliente para descubrir cuántos clientes se suscribieron a un evento en particular y cómo se distribuye el uso de entrega de eventos entre los clientes. Además, utilice agregaciones granulares de tiempo de períodos diarios, por hora y de 15 minutos para segmentar los datos de uso para obtener información más detallada.
Cuando consulta PlatformEventUsageMetric , puede usar estos nuevos campos: EventName , Client , EventType y UsageType .
La siguiente consulta de ejemplo devuelve el uso de eventos por hora para eventos entregados entre el 1 y el 2 de abril en horario UTC. También agrega los resultados en intervalos de una hora según lo especificado por el campo TimeSegment . Dado que los campos EventName y Client se especifican en la consulta, los resultados se agruparán por evento y cliente.
= 2023-04-01T00:00:00.000Z AND EndDate
Un resultado de muestra de la consulta anterior sería similar al siguiente, incluirá datos de uso para todos los eventos, Order_Event__e y AccountChangeEvent .
Para obtener más información sobre esta función, consulte la documentación .
HTTP Callout ahora está generalmente disponible para solicitudes GET , lo que le permite traer datos externos a Flow Builder sin ningún código. Usted crea una acción de Llamada HTTP desde dentro de Flow, que puede llamar a cualquier API de servicio basado en la web. Después de agregar los detalles de la API, Flow Builder genera una acción de llamada reutilizable que puede usar para diferentes flujos y en todo Salesforce.
Para ponerlo en uso, desde el elemento Acciones, seleccione Crear llamada HTTP .
Junto con GA, hemos incluido algunos cambios desde la última versión que agilizan el proceso de configuración.
Ahora puede editar una acción de llamada HTTP de forma declarativa. Las API cambian regularmente, por ejemplo, cuando se agrega un nuevo campo obligatorio a un sistema externo. Anteriormente, para editar la acción de llamada HTTP reutilizable, modificó la especificación de API generada automáticamente, lo que requería conocimientos de JSON. Ahora, puede editar la acción con clics en el menú de configuración de Servicios externos.
También se simplificó la configuración de la estructura de datos de la respuesta de la API. Proporciona una respuesta de API de muestra y Flow infiere los tipos de datos y analiza el JSON para que los datos se puedan utilizar en los flujos. Anteriormente, si necesitaba cambiar los tipos de datos inferidos, editaba el propio JSON. Ahora, selecciona los tipos de datos del campo con clics. Ahora también se admiten los tipos de datos de fecha, fecha/hora y booleano.
Como bonificación adicional, obtiene mensajes de error más intuitivos al crear su acción de llamada HTTP para ayudar a resolver el error y evitar problemas en el tiempo de ejecución.
Y si no puede OBTENER suficiente con HTTP Callout, ahora puede usar el método POST (Beta) para enviar datos de Salesforce a un servidor externo en Flow Builder. Por ejemplo, una nueva cuenta en Salesforce activa un flujo que crea una factura en un sistema externo. Seleccione POST (Beta) , ingrese un cuerpo de solicitud JSON de muestra que la API espera al configurar la llamada HTTP, y Flow infiere la estructura de datos externos.
Guau, ¡son bastantes nuevas características de integración de plataforma para probar! Confío en que facilitarán la vida de muchos desarrolladores. ¡Pero hay más por descubrir! Lo invito a explorar nuestras otras publicaciones de blog para conocer las últimas actualizaciones de LWC, Mobile, MuleSoft y Tableau.
Nuestros gerentes de producto y defensores de desarrolladores están de vuelta para compartir las últimas características y funcionalidades que llegarán en Summer '23. Para ayudarlo a desarrollarse más rápido, hay una gran cantidad de contenido nuevo del equipo de relaciones con desarrolladores que cubre sus nuevas funciones favoritas. ¡Asegúrese de consultar Release Readiness Live el viernes 19 de mayo a las 9:00 a. m. PST, y lea lo último en el blog de desarrolladores de Salesforce para conocer más innovaciones relacionadas con desarrolladores en el lanzamiento de Summer '23!
¡Explore los trailmixes de Trailhead con aspectos destacados de lanzamiento clave para desarrolladores o administradores, o ambos! Siga y complete un trailmix de Learn MOAR Summer '23 para administradores o desarrolladores para obtener una insignia exclusiva de la comunidad.
Julián Duque es un defensor principal de desarrolladores en Salesforce, donde se enfoca en Node.js, JavaScript y desarrollo backend. Le apasiona la educación y el intercambio de conocimientos y ha estado involucrado en la organización de comunidades tecnológicas y de desarrolladores desde 2001.
Sígalo en Twitter @julian_duque , @julianduque.co en Bluesky o LinkedIn .
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.
…
La versión Spring '23 de Salesforce Platform, disponible en general a partir del 13 de febrero, agregó algunas actualizaciones fantásticas al lenguaje de Apex. Hemos implementado algunas de las actualizaciones de Spring '23 en la aplicación de ejemplo Apex-Recipes , lo que ha simplificado significativamente la base de código existente.
En esta publicación de blog, revisaremos las actualizaciones en Spring '23 para Apex con ejemplos de código. Estas actualizaciones ayudan a los desarrolladores a crear aplicaciones más seguras para sus organizaciones.
Apex, de forma predeterminada, se ejecuta en modo Sistema con permisos elevados, lo que significa que los desarrolladores pueden pasar por alto los controles de seguridad sin darse cuenta al escribir código.
Antes de continuar, revisemos rápidamente los controles de seguridad que los administradores de Salesforce pueden colocar para garantizar que los usuarios solo puedan acceder y manipular los datos para los que están autorizados a ver o editar. Las viñetas a continuación resumen diferentes mecanismos para aplicar un modelo de seguridad detallado para sus datos de Salesforce.
Con las operaciones de base de datos en modo usuario , los desarrolladores pueden optar por ejecutar Apex en el contexto del usuario, lo que garantiza que se apliquen las reglas CRUD/FLS y de uso compartido del usuario configuradas. Veamos esto en acción con ejemplos de código detallados.
Puede indicar el modo de operación usando la palabra clave WITH USER_MODE para el modo de usuario y WITH SYSTEM_MODE para el modo de sistema en su consulta SOQL. Vea el ejemplo a continuación.
<dx-code-block title language code-block="List accounts = [SELECT Name, ShippingCity, ShippingStreet FROM Account WITH USER_MODE];»>
En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:
El WITH USER_MODE la palabra clave también es compatible con agregar SOQL para hacer cumplir CRUD/FLS y reglas de uso compartido de registros.
<dx-code-block title language code-block="List groupedResults = [SELECT SUM(AMOUNT) total FROM Opportunity WHERE AccountId = :accountId WITH USER_MODE];»>
En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:
WHERE se verifican para FLS) para el usuario Para obtener más ejemplos, consulte la clase SOQLRecipes de la aplicación apex-recipes.
Los nuevos métodos Database (ver documentos ) ahora admiten un parámetro AccessLevel que le permite ejecutar operaciones de base de datos en modo de usuario en lugar de en el modo de sistema predeterminado. Veamos un código de ejemplo para ejecutar un SOQL dinámico en el modo de usuario.
<dx-code-block title language code-block="String query = 'SELECT ID, Name FROM Account LIMIT 1';
List lstAccounts = Database.query(query, AccessLevel.USER_MODE);»>
En el ejemplo anterior, el modo de usuario se aplicará de manera similar al ejemplo de SOQL estático que vimos en la sección anterior.
Para obtener más ejemplos, consulte la clase DynamicSOQLRecipes de apex-recipes. Hemos actualizado todos los métodos de la clase para usar el parámetro AccessLevel .
WITH USER_MODE o WITH SYSTEM_MODE también son compatibles con declaraciones SOSL (Lenguaje de búsqueda de objetos de Salesforce).
Veamos un ejemplo de una instrucción SOSL estática.
<dx-code-block title language code-block="String keyword = 'Alaska';
List<List> searchResults = [ FIND :keyword IN Name FIELDS RETURNING Account(Name), Contact(LastName, Account.Name) WITH USER_MODE ];»>
En el ejemplo anterior, al usar la palabra clave WITH USER_MODE , la consulta respeta estas restricciones de seguridad:
Para Dynamic SOSL, los nuevos métodos Search (ver documentos ) también admiten el parámetro AccessLevel similar a los nuevos métodos Database . A continuación se muestra un ejemplo de cómo usar el parámetro AccessLevel para ejecutar SOSL en el contexto de los usuarios.
<dx-code-block title language code-block="String query = 'FIND 'Edge*' IN ALL FIELDS RETURNING Account(ID,Name), Contact, Lead'; List<List> searchResults = Search.query(query, AccessLevel.USER_MODE);»>
Las operaciones de la base de datos pueden especificar el modo de usuario o sistema utilizando las palabras clave as user o as system .
El siguiente es un código de ejemplo que ejecuta DML en el modo de usuario aplicando CRUD/FLS y reglas de uso compartido.
Para Dynamic DML, los desarrolladores pueden utilizar el parámetro AccessLevel para ejecutar operaciones de base de datos en el modo de usuario o en el modo de sistema.
Echemos un vistazo a un ejemplo de la aplicación apex-recipes para ver cómo puede diseñar métodos para que sean genéricos, de modo que el consumidor del método pueda decidir ejecutar el código en el modo de usuario o de sistema.
El fragmento de código siguiente muestra cómo invocar este método en el modo de usuario.
El siguiente fragmento de código muestra cómo invocar este método en el modo de sistema.
Para obtener más ejemplos, consulte la clase DMLRecipes de la aplicación apex-recipes.
Security.stripInaccessible() (consulte los documentos ). Consulte la clase StripInaccessibleRecipes (ver documentos ) de la aplicación apex-recipes para ver ejemplos de código.WITH SECURITY_ENFORCED en sus declaraciones SOQL para hacer cumplir CRUD/FLS, ahora le recomendamos que use la palabra clave WITH USER_MODE en su lugar debido a las siguientes razones:
WITH USER_MODE admite muchas innovaciones nuevas, como reglas de restricción, reglas de alcance y cualquier otra operación de seguridad para el acceso a datos y CRUD/FLS, que la plataforma puede agregar en el futuro, por lo que es una especie de prueba del futuroWITH USER_MODE maneja casos de uso de seguridad complejos mucho mejor. Por ejemplo, WITH USER_MODE es compatible con SOSL y consultas polimórficas .WITH USER_MODE manejan CRUD/FLS para los campos usados en la cláusula where y order by o campos usados en la consulta de relación o búsqueda polimórficaWITH USER_MODE funcionan mucho mejor en comparación con el uso WITH SECURITY_ENFORCED<dx-code-block title language code-block="public without sharing ExampleCls { public static List getAccount() { String query = ‘SELECT Id FROM Account Limit 1’; return Database.query(query, AccessLevel.USER_MODE); } }»>
En el ejemplo anterior, aunque la clase Apex está configurada para ejecutarse en el contexto del sistema (sin la palabra clave compartida), la consulta SOQL se ejecuta en el modo de usuario, lo que refuerza la seguridad. El modo de usuario para la operación (SOQL/SOSL o DML) anula el uso compartido a nivel de clase.
Spring '23 agregó nuevos métodos como Database.queryWithBinds , Database.getQueryLocatorWithBinds y Database.countQueryWithBinds .
Estos métodos proporcionan los siguientes beneficios:
Database.query ) que están fuera de contexto, la consulta no podía resolver las variables. Con queryWithBinds , las variables de vinculación de la consulta se resuelven directamente desde un parámetro Map con una clave en lugar de variables de código de Apex.Database.queryWithBinds , los ataques de inyección SOQL se evitan automáticamente.Echemos un vistazo a un ejemplo de código para comprender el segundo punto con más profundidad.
<dx-code-block title language code-block="public static List simpleBindingSoqlQuery(Map bindParams) { String query = ‘SELECT Id, Name ‘ + ‘FROM Account ‘ + ‘WHERE name = :name’; return Database.queryWithBinds( query, bindParams, AccessLevel.USER_MODE );
}»>
El código anterior ejecuta un SOQL dinámico en el modo de usuario. El método acepta un parámetro Map y se puede llamar usando el código a continuación.
<dx-code-block title language code-block="String accountName = 'Codey And Co';
Map nameBind = new Map{‘name’ => accountName};
List accounts = simpleBindingSoqlQuery(nameBind);
System.debug(accounts);»>
Tenga en cuenta que no es necesario que nos aseguremos de que el nombre de la variable esté en el mismo ámbito de método que la consulta dinámica. Además, no es necesario usar el método String.escapeSingleQuotes para el valor en la variable name cuando se usa queryWithBinds .
Para obtener más ejemplos de código, consulte esta solicitud de incorporación de cambios en nuestro repositorio de GitHub apex-recipes.
Otra característica importante que lanzamos en Spring '23 es la capacidad de especificar demoras para trabajos programados que se pueden poner en cola.
Puede ser beneficioso ajustar el tiempo antes de que se ejecute el trabajo en cola en los siguientes casos de uso:
Usa el método System.enqueue(queueable, delay) (ver docs ) para especificar retrasos. Los retrasos pueden variar de cero a 10 minutos. Veamos un ejemplo para comprender mejor esta función.
El ejemplo anterior agrega un trabajo para la ejecución asincrónica retrasada al pasar una instancia de la implementación de su clase de la interfaz Queueable para la ejecución. Hay un retraso mínimo de cinco minutos antes de que se ejecute el trabajo.
Actualmente, si tiene un trabajo en cola de Apex, utiliza el tiempo estándar en cola sin demoras adicionales. Los administradores pueden definir un retraso predeterminado en toda la organización para todos los trabajos en cola que no especifican retraso usando
System.enqueue(queueable, delay) . Este es principalmente un mecanismo para manejar trabajos fuera de control que podrían estar ejecutándose demasiado rápido.
Cuando establece el retraso en 0 (cero), el trabajo en cola se ejecuta lo más rápido posible. Con trabajos en cola encadenados, implemente un mecanismo para ralentizar o detener el trabajo si es necesario. Sin un mecanismo a prueba de fallas de este tipo, puede alcanzar rápidamente el límite de Apex asíncrono diario.
También hay una próxima función Beta en la versión Summer '23 (planificada para estar disponible el 10 de junio de 2023 en todas las organizaciones) que permite a los desarrolladores controlar la profundidad de los trabajos en cola encadenados.
SObject de origen de una instancia DescribeFieldResult usando el nuevo método getSObjectType El método getSObjectType (ver documentos ) en el objeto DescribeFieldResult (ver documentos ) es un método de mejora de la calidad de vida del desarrollador que se implementó en Spring '23.
Anteriormente, los desarrolladores tenían que hackear y escribir código adicional para obtener el objeto de origen de la información del esquema de campos obtenida a través de la descripción del campo. Puede consultar las soluciones anteriores a través de esta publicación de stackexchange .
A continuación se muestra un ejemplo de código de cómo usar el nuevo método getSObjectType .
Con el método getSObjectType , los desarrolladores ya no tienen que pasar el nombre del objeto como una cadena. Consulte un ejemplo más completo en las notas de la versión de Spring '23.
Hemos actualizado el servidor de idioma de Apex para admitir las últimas adiciones de sintaxis, como insert as user, insert as system y mucho más. Y ahora admitimos las últimas adiciones de sintaxis en el lanzamiento reciente de las Extensiones de Salesforce para VSCode .
También quiero agradecer a Dang Mai por actualizar el complemento más bonito para Apex (usado para formatear el código Apex automáticamente) para admitir todas las palabras clave introducidas para las operaciones de la base de datos en modo usuario.
En conclusión, la versión Spring '23 de Salesforce incluye varias actualizaciones. Mediante el uso de estas nuevas funciones, los desarrolladores pueden crear aplicaciones más eficaces y seguras para sus organizaciones.
Los equipos de productos de Apex no se detienen ahí y hay más innovaciones en la hoja de ruta. Puede obtener una vista previa de lo que viene para Apex en Summer '23 (nuestro próximo lanzamiento) en la vista previa de las notas de la versión . También recomiendo ver la grabación de la sesión TrailblazerDX '23, Apex: What's New and What's Coming , para aprender más sobre lo que se está cocinando.
Mohith Shrivastava es promotor de desarrollo en Salesforce con una década de experiencia en la creación de productos a escala empresarial en la plataforma de Salesforce. Actualmente se está enfocando en las herramientas para desarrolladores de Salesforce, Flow, Apex y Lightning Web Components en Salesforce. Mohith se encuentra actualmente entre los principales contribuyentes en Salesforce Stack Exchange, un foro de desarrolladores donde los desarrolladores de Salesforce pueden hacer preguntas y compartir conocimientos. Puedes seguirlo a través de su Twitter @msrivastav13 .
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
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 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.
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:
410: GONE500: UNSUPPORTED_API_VERSION400: InvalidVersionAhora que conoce el último plan, veamos cómo puede identificar si se ve afectado y cómo.
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:
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.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.
Puede utilizar la colección Postman de las API de la plataforma de Salesforce para inspeccionar sus registros de Salesforce con estos pasos:
q con la siguiente consulta SOQL: SELECT LogFile, EventType, CreatedDate FROM EventLogFile WHERE EventType IN ('API', 'RestApi', 'BulkApi', 'ApiTotalUsage') 
id . 
Después de identificar que está llamando a versiones de API heredadas, el siguiente paso es actualizar estas 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:
/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.
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.
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.
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.
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.
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 .
Agregar a Slack Suscríbete a RSS
Última actualización el 30 de abril de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
Jestilla Zetkin trabaja como arquitecta de Salesforce en Gurukul On Cloud (GoC) . Recientemente, enfrentó desafíos mientras trabajaba con eventos de plataforma, principalmente límites de gobernadores. Quiere aprender a configurar el tamaño del lote para el activador de eventos de la plataforma. En este ejercicio, configuraremos el tamaño del lote para lo siguiente:
Las arquitecturas basadas en eventos se han vuelto muy populares en los últimos años, y por una buena razón. Se basa en el patrón de fuego y olvido . Activar un evento y dejar que cada sistema maneje la lógica empresarial le permite mantener los sistemas no relacionados desacoplados y puede ayudar a simplificar la arquitectura.
Los eventos de la plataforma le permiten entregar notificaciones de eventos seguras, escalables y personalizables dentro de Salesforce o desde fuentes externas. Las aplicaciones pueden publicar y suscribirse a eventos de plataforma en la plataforma de Salesforce mediante Apex, Flow o en un sistema externo mediante CometD. Si desea obtener más información sobre el evento de plataforma, consulte el módulo de Trailhead .
De forma predeterminada, el disparador de eventos de la plataforma se ejecuta como el usuario del sistema de procesos automatizados con un tamaño de lote de 2000 mensajes de eventos. A veces es necesario cambiar el usuario y el tamaño del lote para eludir los límites del gobernador u otros desafíos.
Salesforce le permite anular el usuario de ejecución predeterminado y el tamaño de lote de un desencadenador de Apex de evento de plataforma con PlatformEventSubscriberConfig en la API de herramientas o la API de metadatos para configurar el desencadenador.
Puede especificar cualquier usuario activo en la organización de Salesforce. El activador se ejecuta en un contexto de sistema con privilegios para acceder a todos los registros independientemente de los permisos de nivel de campo y de objeto del usuario. Puede especificar un tamaño de lote personalizado de 1 a 2000. El tamaño del lote es el número máximo de mensajes de eventos que se pueden enviar a un disparador en una ejecución.
Hagamos una pausa aquí, familiarícese con el objeto de la API de herramientas PlatformEventUsageMetric en Salesforce. Representa los ajustes de configuración para un disparador de Apex de evento de plataforma, incluido el tamaño del lote y el usuario que ejecuta el disparador.
| Nombre del campo |
Detalles |
| Tamaño del lote | Un tamaño de lote personalizado, de 1 a 2000, para el desencadenador Apex del evento de plataforma. El tamaño del lote corresponde al número máximo de mensajes de eventos que se pueden enviar a un disparador en una ejecución. El tamaño de lote predeterminado es 2000 para activadores de eventos de plataforma. |
| Nombre del desarrollador | El nombre exclusivo del objeto PlatformEventSubscriberConfig. |
| etiqueta maestra | Etiqueta para PlatformEventSubscriberConfig. En la interfaz de usuario, este campo es Configuración de suscriptor de eventos de plataforma. |
| PlatformEventConsumerId | El ID del desencadenador de Apex del evento de plataforma que se va a configurar. |
| ID de usuario | El ID del usuario con el que se ejecuta el desencadenador de Apex del evento de plataforma. De forma predeterminada, el disparador de eventos de la plataforma se ejecuta como la entidad de proceso automatizado. Establecer el usuario que ejecuta a un usuario específico tiene estos beneficios:
|
Los componentes PlatformEventSubscriberConfig tienen el sufijo .platformEventSubscriberConfig y se almacenan en la carpeta PlatformEventSubscriberConfigs .
Este componente PlatformEventSubscriberConfig tiene la etiqueta LeadGenerationEventTriggerConfig . Contiene la configuración de un disparador de eventos de plataforma, LeadGenerationTrigger , y especifica el tamaño del lote y el usuario.
Para agregar una configuración, realice una solicitud POST como se menciona a continuación:
Puede consultar y recuperar las configuraciones en su organización con SOQL. Si consulta desde Developer Console Query Editor, asegúrese de seleccionar Use Tooling API . Esta consulta de ejemplo recupera todas las configuraciones establecidas en su organización de Salesforce. 
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Esta es una traducción 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.
…
Roma no se construyó en un día… pero casi se arruinó en una noche. Eso es lo que tienen los imperios, son frágiles. Al igual que la confianza. Podemos extender aún más esta analogía a nuestra arquitectura empresarial; se necesita mucho tiempo y un gran esfuerzo para construir una organización exitosa y ganarse la confianza del cliente, pero un percance de seguridad puede reducir todos los escombros de sus esfuerzos.
En 2022, todos escuchamos sobre la filtración del juego GTA 6 justo antes de su fecha de lanzamiento. Esta filtración fue lo suficientemente grande como para poner en problemas financieros al editor del juego, y hubo especulaciones de que una persona interna, como un empleado, estaba involucrada. Entonces la pregunta es: "¿A quién debemos confiar con la seguridad?" La seguridad es tan fuerte como el eslabón más débil.
Y la respuesta es: “No confíes en nadie”, y eso es lo que nos lleva a Zero Trust Security (ZTS) .
ZTS es un marco arquitectónico que tiene como objetivo proteger a las organizaciones de amenazas de seguridad, ataques y violaciones de datos al cumplir con los protocolos de seguridad en cada punto de acceso.
Antes de ZTS, la seguridad basada en el perímetro era el enfoque popular. En la seguridad perimetral, autenticamos y autorizamos a la entidad solo a nivel periférico mediante firewalls, redes privadas virtuales, etc. Una vez que la entidad obtiene acceso, puede acceder a todos los recursos. El movimiento lateral no autorizado ha sido una de las principales preocupaciones en la seguridad perimetral.
Por el contrario, ZTS impone autenticación y autorización en cada punto de entrada. En general, podemos aplicar ZTS a aplicaciones empresariales, aplicaciones nativas de la nube, API, etc. En esta publicación de blog, nos centraremos principalmente en implementar ZTS para API y explorar lo que MuleSoft tiene para ofrecer en lo que respecta a Zero Trust Security.
Todo el concepto de ZTS se basa en los siguientes cuatro principios básicos:
Es muy probable que su infraestructura existente ya tenga algunas medidas de seguridad implementadas. Para implementar ZTS, no tiene que comenzar a construir todo desde cero o reconstruir su infraestructura de seguridad existente. Todo lo que necesita hacer es planificar bien las medidas de seguridad e identificar las lagunas. Puede lograr esto adoptando un enfoque de microsegmentación o seguridad en capas.
Esta es una técnica en la que dividimos la infraestructura en niveles o segmentos y luego aplicamos medidas de seguridad. También podemos considerarlo como "divide y vencerás", donde estamos dividiendo la gran infraestructura en fragmentos más pequeños para una mejor seguridad y control. Este enfoque nos brinda seguridad a nivel granular.
Podemos implementar los principios básicos de ZTS de la siguiente manera:
Es posible que ya esté familiarizado con las capacidades de integración de MuleSoft y cómo aprovechar la conectividad dirigida por API para construir una infraestructura componible. Lo siguiente lo ayudará a comprender cómo implementar ZTS usando las capacidades de seguridad de MuleSoft.
Tomemos en consideración una arquitectura componible creada con conectividad dirigida por API (vea la imagen a continuación). La línea exterior punteada en rojo denota seguridad basada en el perímetro, ya que estamos aplicando seguridad en un nivel periférico. Para aplicar ZTS, aplicaremos medidas de seguridad en cada capa de la API y en todo el punto final de la API. Las líneas internas de puntos rojos en la capa de proceso indican que hemos aplicado una política de eliminación de encabezado y autenticación básica en el punto de entrada de la capa de experiencia a la capa de proceso.
En este blog, hemos aprendido sobre Zero Trust Security y sus principios básicos. También somos conscientes de la diferencia entre la seguridad basada en el perímetro y ZTS, y por qué ZTS es importante. Además, hemos aprendido cómo podemos implementar ZTS usando MuleSoft y las capacidades de seguridad que MuleSoft tiene para ofrecer.
Akshata Sawant es promotora sénior de desarrolladores en Salesforce. Es autora, bloguera y oradora, y coautora del título, MuleSoft for Salesforce Developers . Akshata es un miembro activo de la comunidad de MuleSoft y ex embajador de MuleSoft. Le encanta leer, bailar, viajar y la fotografía, y es una gran entusiasta de la comida. Síguela en Twitter y LinkedIn.
Agregar a Slack Suscríbete a RSS
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 .
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 .
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 .
Última actualización el 15 de marzo de 2023 por Rakesh Gupta Durante la última década, Salesforce AppExchange ha tenido un gran éxito debido a su capacidad para ayudar a las empresas a impulsar el éxito y el crecimiento. Hoy en día, hay más de 6000 aplicaciones y firmas de consultoría listadas en el intercambio. Con tantas excelentes opciones disponibles, identificar
La publicación Maximice su uso de Salesforce AppExchange apareció primero en Automation Champion .