OMElement Error
Hi All,
While trying to pass the SOAP Request, i am getting this error: "Couldn't create OMElement from string value". What is it actually? The WSDL that i have has <soap:operation soapAction="" /> for this method so i kept the SOAPAction Header in the connector as Blank (its optional though). How do i resolve this?
I tried removing the header parseXML but it didn't work
Please Note: I have a header to pass. When i traced i saw pzAddCustomHeadersToSoapEnvelope is getting called from InvokeAxis2.
Mainak
Pega version: 6.3 SP1
Accepted Solution
PEG
IN
If SOAP-Service is expecting headers to pass along with request, then we need to place these headers in Request tab of Connect-SOAP rule. In Headers sections we need to mention all the required headers with proper namespaces.
1)If request builds properly then we will be able to hit the remote web service.
2)If request isn't well forward call won't go to the remote web service.
I believe in your case scenario mentioned in 2nd point is happening. Please check the SOAP Request envelope by enabling debug logs on InvokeAxis2 or running tracer to see the request.
Coforge DPA
AU
I understand that. Can i set the namespace anywhere in the Request DT? I tried changing the namespace with a working target namespace (of existing services), and tried to reconsume the wsdl, on doing so it was not able to consume the WSDL itself (No mehtods were displayed in the accelarator.). My point is even if the service is not up and running, i should be able to send request. PRPC will send back its generic message "SOAP Service failure", but in my case i am not even able to send the request as it is not forming the header.
An example of WSDL is below:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:msg="http://xyz/types/r2/v6"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:Port_0="http://xyz/services/r2/v6"
I understand that. Can i set the namespace anywhere in the Request DT? I tried changing the namespace with a working target namespace (of existing services), and tried to reconsume the wsdl, on doing so it was not able to consume the WSDL itself (No mehtods were displayed in the accelarator.). My point is even if the service is not up and running, i should be able to send request. PRPC will send back its generic message "SOAP Service failure", but in my case i am not even able to send the request as it is not forming the header.
An example of WSDL is below:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:msg="http://xyz/types/r2/v6"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:Port_0="http://xyz/services/r2/v6"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:this="http://xyz/r2/v6" name="xyz service"
targetNamespace="http://xyzs/r2/v6"
xmlns:p="http://www.w3.org/2001/XMLSchema">
If i understand correctly, u mean that i need to have a Valid TargetNamespace.
Accepted Solution
PEG
IN
If SOAP-Service is expecting headers to pass along with request, then we need to place these headers in Request tab of Connect-SOAP rule. In Headers sections we need to mention all the required headers with proper namespaces.
1)If request builds properly then we will be able to hit the remote web service.
2)If request isn't well forward call won't go to the remote web service.
I believe in your case scenario mentioned in 2nd point is happening. Please check the SOAP Request envelope by enabling debug logs on InvokeAxis2 or running tracer to see the request.
Coforge DPA
AU
Actually i saw that in my XSD its given that <elementFormDefault="unqualified" attributeFormDefault="unqualified">. I think this is the reason why its not able to create the header in the invoke axis2.Am i correct? i will try to change my XSD and re import. But in the mean time pls let me know if this is the correct understanding.
regarding the namespace, i was informed that the one provided in the WSDL is correct is in use in a different geography.
PEG
IN
I think most of the xsd's contain these lines in top. I don't think this caused the issue.
<elementFormDefault="unqualified" attributeFormDefault="unqualified">
Coforge DPA
AU
Well i saw in a few of the WSDL’s (OOTB) as I can’t see the XSD’s, they all were qualified. Also the existing services that we have are qualified. That’s y I had this doubt. Anyway.. thanks..