Creo que todos lo hemos sufrido -> «Salesforce no soporta FTP nativo» -> Mala cara.

De mi background como arquitecto de Integración esa afirmación sorprende, pero cuando conoces las capacidades de Integración de Salesforce y otros aspectos como su Seguridad, Fiabilidad, Documentación, Comunidad, etc., se te pasa el susto.
Mantengo una lista de las limitaciones (no en el aspecto negativo) que comparto por si pueden ser de ayuda a alguien y ahorrar algo de tiempo. Por favor, si hay alguna incorrecta (lo siento de antemano) o me faltara alguna, pido por favor mencionarlo, para tener una lista mejor.
- Salesforce no tiene un BUS de Integración propio (aunque con Platform Events, Lightning Connect, Streaming API, etc., se da respuesta a muchos casos de uso)
- Salesforce no soporta transacciones ACID
- Salesforce no soporta WS-Security (https://en.wikipe
- dia.org/wiki/WS-Security)
- Salesforce no implementa WS-ReliableMessaging (https://en.wikipedia.org/wiki/WS-ReliableMessaging) – que utilizando Outboung Messaging queda mitigado por la lógica de los reintentos cada 10» durante 24h
- Salesforce no soporta WS-Addressing, lo que complica el enrutamiento dinámico, en un escenario de Orquestacion empresarial con BUS de Integración disponible
- Con Outbound Messaging, no podemos invocar servicios REST (pero hy abierta Idea 08730000000DhyEAAS)
- Con Outbound Messaging si al cabo de 10» no hay respuesta se reenvia la petición (hay que certificar Idempotencia en el diálogo)
- Con Outbound Messaging solo es posible enviar datos de un objeto, aunque puede recibirse del objeto y de sus objetos relacionados
- Las Workflow Rules no son aplicables el borrado de un registro, por lo tanto, no podemos invocar a un servicio externo directamente (existe Workaround mediante trigger)
- Entornos con grandes volúmenes de datos, típicos de un Patrón de Batch, que requieran el uso de BULK API tanto en modo Serial como Parallel, con o sin Chunking, son difíciles de abordar sin herramientas ETL de terceros (que habitualmente tienen un CTO elevado). Nosotros utilizamos Informatica Cloud, aunque ODI y estoy seguro que otras facilitan el uso de BULK API.
- Los certificados para comunicación segura con Salesforce deben renovarse anualmente (un poco tedioso para los compañeros de sistemas)
- No hay una versión oficial de Data Loader para Linux (es una herramienta de escritorio para Windows y Mac, pero la posibilidad de usarlo como carga masiva usando la BULK API en servidores empresariales Linux es siempre muy tentador y podría…)
- Salesforce no proporciona una herramienta de escritorio de ETL simple para que el equipo de negocio pueda cargar datos transformándolos mínimamente (Mass Loader/Update y herramientas como Jitterbit y Dataloader.io, pueden suplir en parte esta carencia)
- El Force.com Excel Connector dejó de soportarse hace mucho tiempo, y muchos usuarios preguntan por funcionalidad similar
No menciono los Governor Limits, pq creo que son protecciones necesarias en un entorno Multi-tenant, y en muchos casos, romperlos implica que la solución adoptada no es la adecuada.
Seguramente tenemos otras de muy bajo nivel técnico, pero mi intención es solo compartir mi lista y si es posible mejorarla.
*Si perteneces a Salesforce y lees este artículo, no fruncir el ceño por favor, no hay mejor elogio para un fabricante, que sus clientes utilicen sus herramietnas y la conozcan bien.
Crédito de la imagen para: elearningindustry.com
Deja una respuesta