SOAP Plug-in: Error adding a soap host

[deqcan]

Hi to all,

I'm trying to add a soap host to my vcenter orchestrator inventory using the builtin "Add a soap host" workflow, providing the following parameters:

Name: CMDBuild

Provide WSDL Content: Yes

WDSL Content: <See the attachment>

Connection Timeout: 30.0

Request Timeout: 60.0

Authentication Type: None

but the workflow execution stops with the following error:

java.lang.NullPointerException (Dynamic Script Module name : addSOAPHostWithWSDLContent#8)

Is the provided WSDL "compatible" with this plugin?

What am I doing wrong?

Thanks in advance.

[tschoergez]

Hi!

I don't have a solution, unfortunatly, but I can confirm: Just tried to add a new soap host with your WSDL, got the same error:

java.lang.NullPointerException (Dynamic Script Module name : addSOAPHostWithWSDLContent#8)

Can you open a support ticket for that?

Regards,

Joerg

[sanchezs · Accepted solution]

Hi,

There is some kind of issue with the WSDL regarding 3 operations that, apparently, require no input parameters:

• getActivityMenuSchema
• getCardMenuSchema
• getMenuSchema

They define their request messages as:

<wsdl:message name="getActivityMenuSchemaRequest">
  </wsdl:message>

<wsdl:message name="getCardMenuSchemaRequest">
  </wsdl:message>

<wsdl:message name="getMenuSchemaRequest">
  </wsdl:message>

And this seems to be a problem for the SOAP library that the plug-in is using (Axis) when the service port is defined as "soap12" (SOAP 1.2) or "soap" (SOAP 1.1); when the port is defined as "http" it seems to be fine.

One workaround is to define an empty element inside the WSDL and add to the previous messages a part pointing to that element, something like:

<xs:element name="emptySchemaRequest">
    <xs:complexType />
</xs:element>

...

<wsdl:message name="getActivityMenuSchemaRequest">
    <wsdl:part name="parameters" element="xsd:emptySchemaRequest"></wsdl:part>
  </wsdl:message>

<wsdl:message name="getCardMenuSchemaRequest">
    <wsdl:part name="parameters" element="xsd:emptySchemaRequest"></wsdl:part>
  </wsdl:message>

<wsdl:message name="getMenuSchemaRequest">
    <wsdl:part name="parameters" element="xsd:emptySchemaRequest"></wsdl:part>
  </wsdl:message>

When the WSDL contains this information it can be imported properly using the plug-in. And I guess the operations can be invoked without problems. Can you verify it?

I'm not sure whether this issue is more related to the WSDL generator that you could be using (maybe some flag allows to avoid creating this kind of empty messages) or to the client library that the plug-in uses (but I haven't seen so far any option to avoid this issue). We have tested with other WSDLs that define also operations that require no input parameters but they are defined separately for SOAP ports and for HTTP ports. For example for the SOAP ports, their request messages are defined like in the last example above, but for the HTTP ports, their request messages are defined as empty (without "wsdl:part") but the input elements inside their bindings are defined as "http:urlEncoded" or "mime:content type='application/x-www-form-urlencoded'".

I hope it helps.

Sergio

[deqcan]

Hi,

I can confirm that now it works!

Thank you for your support.

[Tobbra]

Hi Sergio,  I'm having a similar problem while adding NetApp's VSC (virtual storage console) WSDL to the plugin. Right now I cannot see what might be wrong with the WSDL. Is the port 8143 in the URI causing problems? Maybe you could shed some light on that, please?  Thanks,  Tobi

[sanchezs]

Hi Tobi,

When are you facing the problem? When you try to import the WSDL file or when you try to invoke some operation? What is the plug-in error message exactly?

Furthermore, if it's when you import the WSDL... what does the URL look like? (https, port, etc.) Does it require any extra authentication accessing to the URL? (HTTP Basic, HTTP Digest)

The port shouldn't be a problem, but in any case, few things you can try to find out the problem:

- Try to use a different port

- Try to disable the HTTPS access and use HTTP instead

- Try to avoid the schema import inside the WSDL (or with a different port or without HTTPS)

- Try to disable the extra authentication (if any)

And I'd suggest to open a new discussion in this community with all those details. Thanks!

Sergio

[Tobbra]

Hi Sergio,  I'm facing the problem when I try to add a SOAP host to the inventory using the existing plugin-in workflow. I'm getting the very same error as noted in the first message of this discussion. That's why I did not open a new discussion.  Unfortunately I cannot change the port or the protocol (http instead of https) since that would impact a lot of other things in our development environment. I've already tried to remove the schema import statement in replace it with the actual type descriptions. That had no influence.   Authentication is not required to access the WebServices or the WSDL. The certificate has been imported successfully.  Thanks for the quick answer,  Tobi

[sanchezs]

Could you provide a single file with the full WSDL? (replacing the schema import with the actual type descriptions)

Do you get exactly the same error in that case?

Regards,

Sergio

[Tobbra]

Hi Sergio,

yes, I get the same error. Here're some more details of what I'm doing:

Then I get:

The WSDL provided is attached.

When I try to read the WSDL directly:

Then I get:

with the following logs:

Thanks,

Tobi

[sanchezs]

Hi Tobi,

One more question. Have you tried using the latest WSDL that you sent with any other application? I tried to import it on another SOAP/WSDL tool (soapUI 3.6.1 http://www.eviware.com/soapUI/soapui-products-overview.html) and it fails validating the WSDL with errors like this:

Error: C:\...\NetApp_VSC_WSDL_types_inline.xml:0: error: src-resolve.a: Could not find type 'clearAllFinishedOpOffloadStatus@http://server.kamino.netapp.com/'. Do you mean to refer to the type named clearAllFinishedOpOffloadStatus (in NetApp_VSC_WSDL_types_inline.xml)?

And the same for all the types defined on the file. Can you verify that this WSDL works independently of the SOAP plug-in?

Regards,

Sergio

[Tobbra]

Hi Sergio,

no, I have not tried that. It was just a simply try to replace the "schema import" statements with the real type definitions. What I tried already is using the powershell cmdlet New-WebServiceProxy to directly connect to the WSDL URI. That work without any problem - I proxy was generated and I could access the methods of the WebService without any problem.

I'll have a look if I can somehow manage to use and fix the "inline" WSDL, but I'm not sure if I'm able to tweak our environment in that way. Anyway I would prefer to read the WSDL from the URI directly.

Thank you very much for your help.

Tobi

edit: I've fixed the combined WSDL and have tested it via soapUI. Now it works and I can send requests to the WebService successfully. The fixed WSDL is attached.

[Tobbra]

Hi Sergio,

using the combined WSDL worked in the end. So it seems that the addSOAPHost workflow has some problems with the "schema import" statement.

Thanks a lot for your help.

Tobi

[sanchezs]

Hi Tobi,

I'm glad that you found a workaround at the end. You are right, in that case the problem might come with the "import schema" using SSL. We'll try to reproduce the same environment with the same conditions to find out the issue. And thank you for sending the working WSDL, we'll analyze it as well. I expect that we can improve the plug-in for its next update with your feedback.

Regards,

Sergio