WSDL with unwanted https_port

[Former Member]

When the WSDL is displayed from the Sender Agreement in Integration Directory, it has two endpoints/wsdl ports. One is HTTP_Port and the other is HTTPS_Port. But my PI system is not set up for https. It uses a Sender SOAP channel and when I try to call it using a Web Service tool, it is picking up the https end point by default. When I manually change the end point to be used as the http one, it is working perfectly.

The second https end point is not needed and should not come automatically in the generated WSDL. What settings should I fix so the WSDL generated from the Sender Agreement has only the HTTP_Port? If this can be fixed, I can give my partner applications the generated Discovery url without second thoughts. Now I have to manually change WSDL everytime and pass on the wsdl file itself, which is very tragic..

[Former Member]

Hi,

One is HTTP_Port and the other is HTTPS_Port. 

That is the default way PI behaves, when WSDL is generated from Sender Agreement.

But my PI system is not set up for https.

Not a problem.

 It uses a Sender SOAP channel and when I try to call it using a Web Service tool, it is picking up the https end point by default.

If you are using an external tool to push out the web service, then you must be providing the URL for the PI server. Use the URL with HTTP. It will never pick the HTTPS in that case.

The second https end point is not needed and should not come automatically in the generated WSDL. What settings should I fix so the WSDL generated from the Sender Agreement has only the HTTP_Port? 

As I said, it is the default behavior of PI tool. It provides both the secured and unsecured URLs and you can use any one of them. There are no settings to change this behavior.

Now I have to manually change WSDL everytime and pass on the wsdl file itself, which is very tragic..

You can generate WSDL from Service Interface in ESR or ID -> Tools -> Display WSDL. The later one will have the URL that you provide while building it.

Regards,

Neetesh

[Former Member]

Thanks. So you are just reiterating that discovery url from Sender Agreement is always useless unless you want to use https endpoint?

[Former Member]

So you are just reiterating that discovery url from Sender Agreement is always useless unless you want to use https endpoint?

No, its not useless.

You can share this URL with Consumer Application development team. Please note that Log-in is required to view the WSDL via browser and to consume it.

You may note that the SOAP URL is automatically generated for you. Each time you change your data type, you don't have to repeat the WSDL generation unlike previous versions of PI and XI. The Consumer application can just refresh the WSDL at its end.

So, the whole idea is if you provide the correct URL to the Consumer Application Dev team, which is HTTP in your case, then it won't pick the HTTPS URL.

Hope this helps.

Regards,

Neetesh

[Former Member]

O.K..I feel you are mixing up Discovery URL and the Endpoint URL. They are not the same. I am talking about the Discovery URL from the Sender Agreement being useless when it is automatically generated. Endpoint URLs (say the http one) from the automatically generated WSDL are not able to serve the same purpose when used by an external application.

[Former Member]

Hi,

Please check this.. may help.

I think specific to your question, settings to block the wsdl for HTTPS_port while wsdl generation thorugh sender channel will be difficult. If suppose you changed the setting and want now secure port for other application, then if you try to block the setting for HTTP_port, will be an issue. So I guess by default while generating wsdl, both port will get generated and HTTP_Port will have your PI system URL with correct port no. and HTTPS_port will have default port no. as 443.

@Experts: Different views on this are always welcome.

Regards,

Praveen.

[Former Member]

Thanks for your reply.

I have no issues with URLs and authorizations. If the WSDLs and Discovery URLs from Sender Agreement cannot be used as they are, what good is that option. It is not even an upgrade from previous versions. Its a real pain in the neck to use it and then fix it. I guess we might as well generate it manually like earlier for reliable URLs and WSDLs.