on 12-28-2005 11:12 PM
Hi
I have a question regarding consuming webservices published on the XI server - I want to generate client proxies in a .net env that consumes the webservice on the XI server. I have read from SAP documentation and several weblogs that using the *wsdl file generated in the ID during the WS creation process is the way to do it.
My question is : can I generate client proxies in the .net env by directly pointing to a URL on the XI server - that defines that particular webservice - instead of using WSDL as a starting point ? By doing this, when we move to the QA/Test environments in the corresponding *.net applications, we can re-generate the proxies by pointing to the central webservice definition on the XI server.
I hope I have been clear with my question. Thanks in advance for your time.
Hi Karthik,
<i>By doing this, when we move to the QA/Test environments in the corresponding *.net applications, we can re-generate the proxies by pointing to the central webservice definition on the XI server.</i>
I have a different understanding on thsi point.The .NET interfaces created are based on the WSDls pointing to the development server.when you change to the QA or Production server the <b>URL of the wsdl</b> will change and hence you will have to recompile and produce new DLLs.
Hope you are clear that URL(server name and port) keeps changing with the XI box .
Cheers,
Rashmi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rashmi
Just to clarify my understanding on - the steps involved in moving the webservice published on XI server to a different environment ( Dev --> QA )
1. The webservice must be created in the XI QA environment - in the Integration Directory of the XI QA box - using WS creation wizard - the url pointing to the XI QA server this time. This step ensures that the webservice is now available on the XI QA server
2.The *VB source ( proxies ) in the .net QA application must be edited to change the webservice url to point to the XI QA box - and this *VB source must be recompiled...
Let me know if your understanding of this process is different.
Karthik,
Have a small correction to ur response
>>2.The *VB source ( proxies ) in the .net QA application >>must be edited to change the webservice url to point to >>the XI QA box - and this *VB source must be >>recompiled...
you dont have to recompile the code jsut becasuse the endpoint has changed from DEV to QA. this endpoint or URL will be driven from a webconfig or application config file. Hence all one has to do is change the endpoint information in the corresponding config file.
Cheers,
Naveen
Hi Naveen
Till now, in our environment the *net client applications were grabbing the wsdl that XI published and then directly generated client proxies out of those - based on this procedure, the url for the wsdl is directly embedded in the proxy code - can you give me an example of how to put the same url that is embedded in the vb proxy code on to a webconfig file - Is it very difficult to do this ?
Hi,
when you add the web reference (webservice) in the current project using Visual Studio IDE, if you see the properties of the webreference, you will find a property <b>"URL Behaviour"</b> this is set to static by default, change it to dynamic, this will make create a new entry in the webconfig.
Now as you go between different development mediums, just go into the webconfig, find the endpoint and change it in the config file.
cheers,
naveen
Hi
Thank you for your quick response. Just one more question on this : The weblog that you had sent regarding publishing WSDLs on to the WAS UDDI server, we implemented that in our XI DEV environment.
Now , the WAS UDDI server holds just the WSDLs , right ? Can we not access the webservice on the XI server directly from the *net application as we access a webservice on the *net env - *asmx ?? Is the UDDI server a location -only to hold WSDLs ?
Hope I have been clear in my question.
Hi,
UDDI is just a place holder for wslds, unlike *.asmx.
uddi wsdld = http://...asmx?wsdl
Cheers,
naveen
Naveen,
I did not understand the last part uddi wsdld = http://...asmx?wsdl
Hi,
In the .net world, a webservice actually refers to the actual endpoint ie http://test.com/test/test.asmx, now if you want to get the wsdl of this webservice, you can it from the endpoint by http://test.com/test/test.asmx?wsdl
hence in .net
enpoint = http://test.com/test/test.asmx
wsdl = http://test.com/test/test.asmx?wsdl
in XI
enpoint = http://server:port/ISOAPAdapter/MessageServlet?channel=xx:xx:xx
wsdl = now this wsld can be on uddi.
cheers,
naveen
Hi karthik
try this blog
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2131 [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken]
Cheers
shailesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
85 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.