Forum Discussion

Kumar8765's avatar
Kumar8765
Occasional Visitor
8 years ago

unable to load WSDLs from SOAP UI

Hi,

We are on PepleSoft FSCM 9.1 and PeopleTools 8.52.

Our Integration Broker is configured to HTTPS.

I did created WSDLs for CI_USERMAINT_SELF and CI_USER_PROFILE using HTTPS.

When I paste the WSDL's in browser, I can see the XML document format with no issues, but when I am trying to load the WSDL's via SOAP UI it giving me below error:

WSDLException (at /wsdl:description): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.

WSDL URL is as below:

https://XXXXXXX/PSIGW/PeopleSoftServiceListeningCo nnector/PT_LOCAL/CI_USERMAINT_SELF.1.wsdl

Can any once please help me on what the issue is?


SOAP UI error log:

ERROR:com.eviware.soapui.impl.support.definition.s upport.InvalidDefinitionException
com.eviware.soapui.impl.support.definition.support .InvalidDefinitionException
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlInte rfaceDefinition.load(WsdlInterfaceDefinition.java:53)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlCont ext.loadDefinition(WsdlContext.java:62)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlCont ext.loadDefinition(WsdlContext.java:34)
at com.eviware.soapui.impl.support.definition.support .AbstractDefinitionContext.cacheDefinition(Abstrac tDefinitionContext.java:246)
at com.eviware.soapui.impl.support.definition.support .AbstractDefinitionContext.access$400(AbstractDefi nitionContext.java:48)
at com.eviware.soapui.impl.support.definition.support .AbstractDefinitionContext$Loader.construct(Abstra ctDefinitionContext.java:219)
at com.eviware.soapui.support.swing.SwingWorkerDelega tor.construct(SwingWorkerDelegator.java:46)
at com.eviware.soapui.support.swing.SwingWorker$2.run (SwingWorker.java:131)
at java.lang.Thread.run(Unknown Source)

1 Reply

  • ripmcmanus's avatar
    ripmcmanus
    Occasional Visitor

    This post has gone unanswered for a long time. Did you find a way to make it work? I've seen this addressed on other websites as requiring that the "Generate WSDL 2.0" option not be used. It would be nice if SmartBear would simply publish the requirements for the application tag. I don't mind overriding what's generated, but when what's generated is apparently valid anywhere else you check, SmartBear's deflection to the WSDL/WADL provider, their typical response, is kind of a cop-out.