studio - crear y consumir web service c#

¿Cómo se pueden usar dos WSDL y mantener una instancia de prueba con una aplicación C#?

Question

Creé un servicio que se comunica con la plataforma SalesForce a través de C #, utilizando su WSDL. Ocurre que SalesForce (más bien lógicamente) permite instancias de "recinto de seguridad" de su plataforma y instancias de "producción" de su plataforma. Mi aplicación está diseñada para trabajar con producción, pero he estado usando la caja de arena para la prueba de integración y la prueba unitaria. Ahora estoy llegando al punto en el que necesito implementar para producción. Sin embargo, enfrento un gran problema en el sentido de que si alguna vez necesito construir y probar nuevas características, tendré que actualizar el WSDL de la instancia de producción a la instancia del recinto de seguridad, luego cambiar de un lado a otro a medida que agregue nuevas características. ¡Esto se debe a que los dos WSDL son completamente diferentes y tengo que generar código de ellos! Esto no solo es descuidado, es peligroso. Podría afectar algunos de mis datos del sistema en vivo.

Me gustaría encontrar una forma de usar una clave de registro, un valor de texto o alguna configuración que le indique a mi aplicación qué WSDL usar. ¿El problema es? No puedo entender cómo uno podría acercarse a eso. Los mismos objetos a los que hace referencia mi código se generan a partir de ese WSDL. ¿Algunas ideas?

Answer 1

¡Los WSDL no deberían ser completamente diferentes entre los dos! Por supuesto, a menos que se hayan creado muchos objetos nuevos y campos personalizados en la zona de pruebas y aún no se haya lanzado a producción ...

¿Hay alguna posibilidad de que hayas mezclado los WSDL de empresa (versión fuertemente tipada) y socio (más genérica)? Consulte este tema de ayuda para obtener más información: http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_quickstart_intro.htm#choose_wsdl

Si realmente está preocupado por el modelo de datos, puede decidir usar la versión de socio (el código generado es un poco feo porque le da sObjects genéricos en lugar de una cuenta más específica, un contacto, etc.). Siempre estuve bien con la versión empresarial (las cosas de las cajas de arena eventualmente llegaron a la producción y una vez que los diferentes sistemas comenzaron a confiar en el modelo de datos, los equipos comenzaron a sincronizar sus lanzamientos si es posible).

La forma de distinguirlos que funcionó para mí fue examinar los puntos finales (en la parte inferior del archivo). Estaba haciendo integraciones de PHP así que para mí no fue un problema dar la vuelta al punto final sobre la marcha pero "confiar" en la misma estructura de objetos. No tengo idea de cómo se ve en C # world, ¿dónde termina esta información en el código analizado? ¡Buena suerte!

Enterprise - Sandbox

<service name="SforceService">
<documentation>Sforce SOAP API</documentation>
<port binding="tns:SoapBinding" name="Soap">
    <soap:address location="https://test.salesforce.com/services/Soap/c/26.0/(18 char sandbox Id)"/>
</port>
</service>

Enterprise - Producción

https://login.salesforce.com/services/Soap/c/26.0/(prod id)

Los WSDL de los socios tienen "u" en la URL en lugar de "c" y no tienen una identificación de organización específica: https://test.salesforce.com/services/Soap/u/26.0"/

(Mi pequeño truco para memorizar esto es pensarlo como "Cliente" o "Personalizado" y "Universal")

Editar: por supuesto, si te apegas a "empresa", el único punto final con el que realmente puedes contar es la producción. Los ID de organización de Sandbox cambian cada vez que se actualizan.