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?
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
1 reply Latest Post - 2010-09-30T14:51:36Z by mburati
Pinned topic Profiling the web service call builder
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2010-09-30T14:51:36Z at 2010-09-30T14:51:36Z by mburati
mburati 060000VQ20352 PostsACCEPTED ANSWER
Re: Profiling the web service call builder2010-09-30T14:51:36Z in response to SystemAdminTypically 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.