1 reply Latest Post - ‏2010-09-30T14:51:36Z by mburati
557 Posts

Pinned topic Profiling the web service call builder

‏2010-09-30T11:53:10Z |

I have a web service call builder. I want to dynamically put the WSDL URL in that builder. I have 3 different environment and whenever I deploy the war file in these environment I want the builder to dynamically get the WSDL URL. Is there any way I can do that?
Updated on 2010-09-30T14:51:36Z at 2010-09-30T14:51:36Z by mburati
  • mburati
    352 Posts

    Re: Profiling the web service call builder

    ‏2010-09-30T14:51:36Z  in response to SystemAdmin
    Typically the only thing that changes between dev, test/staging and production deployment is the endpoint URL, so you would not need to change the WSDL for that scenario, you would just use the Web Service Call (or Web Service MultiOperation) builder's host, port and/or URL override inputs in the advanced section of the builder's editor UI to profile or dynamically look up those overrides.

    Can you confirm whether that's all you need to change between the 3 environments?

    If the structure of the data and/or the operations change, that's a bigger issue since most WPF models read the list of operations and data structure schemas at design time so that you can wire up operations and structured data to other builders in the designer. That doesn't fit as easily in a scenario where the data structure and/or operations can change on the deployment server. There is the "Profiled Service Call" builder which allows you to profile the WSDL URL, but you really have to know what you are doing (what do to if/when operations change and/or the structure of the data changes) and do more work manually yourself to make sure you pass the right inputs for whatever data you might get at runtime, based on which operations eventually get called etc. It's not a commonly used scenario and that builder exists mainly for corner cases where someone does want to do all that extra work themselves for a scenario that just can't be determined until runtime. If you can describe what is different in the 3 environments/scenarios, we can probably help suggest a better way of accomplishing it than modifying the WSDL URL. If it really just is 3 different WSDLs you need to support (in both dev and deployment environments) then building 3 separate service providers may be the better way to go.