Web Service XML prefix - c#

Let me start this by saying I know prefix should not matter for xml that follows standards. I am forced to use a web service that requires the request to look like this
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:prefix="http://www.url.com">
<soapenv:Header/>
<soapenv:Body>
<prefix:Search>
<SearchCriteria>
<registrationStatus>A</registrationStatus>
<startDate/>
<endDate/>
</SearchCriteria>
</prefix:Search>
</soapenv:Body>
</soapenv:Envelope>
When I generate my request it ends up looking like this
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://www.url.com">
<soapenv:Header/>
<soapenv:Body>
<Search (also tried here xmlns="http://www.url.com")>
<SearchCriteria>
<registrationStatus>A</registrationStatus>
<startDate/>
<endDate/>
</SearchCriteria>
</Search>
</soapenv:Body>
</soapenv:Envelope>
Because the prefix is missing I get an error saying it can't find the search child. Using fiddler I have recomposed this message a million different ways and all fails unless I add the prefix and the namespace for it. I don't own the web service and the owner won't make changes so I am stuck trying to figure it out.
My question is how can I add the prefix and the namespace to the request? I have added the service to my c# console test app using add service reference, I tried modifying the qualified and not qualified settings but that did not add the prefix.

I was able to find a good solution here Intercept SOAP messages from and to a web service at the client
This worked perfectly for anyone else looking to do the same

i think you have to provide targetnamepace for your class Search.

Related

Why chaninging tempui.org in wsdl made my service work?

I have a soap web service which is working ok on the local server but not accessible from the outside and fails with the error that HTTP header not found.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="http://tempui.org">
but when I use
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="https:www.mycompanydomainname.org/">
It works.
The only different is that I put instead of xmlns:urn="http://tempui.org"> this, I put this xmlns:urn="https:www.mycompanydomainname.org/"
And it started working.
Why?

Finding out why this web service is failing

I am dealing with a web service from one of my government agencies for electronic documents. The WSDL can be found here: https://maullin.sii.cl/DTEWS/CrSeed.jws?WSDL
I tried calling the getSeed() method (which is the only relevant one) at http://www.soapclient.com/soaptest.html to see if it's working, and indeed it is.
I created a WCF Service Library to test this and i got the following error:
System.ServiceModel.FaultException: 'org.xml.sax.SAXParseException: Content is not allowed in prolog.'
A quick online search shows that many users have this problem trying to implement this particular Web service and they all seems to point out some windows update. Everyone points to a different one to uninstall and that's how some of them resolved this issue.
I don't believe it's a matter of a particular windows update, perhaps there is something else. So instead I tried creating the WCF Service Application and hosting the web service in IIS to check if maybe it was some debug problem.
In a console project I try to call the getSeed() method, but it ended up returning a null string instead of throwing a SAXParseException.
So whats the deal in here?. It seems pretty straight forward to me:
1. Add the service reference
2. Create a new instance of CrSeedClient class
3. Call getSeed() method.
Why I am getting all this trouble over this particular web service?
BTW, i am using Net Framework 4.7.2 / Windows 10 / Visual Studio 2017
Can anyone test it out please?
Thanks.
EDIT !: Read my own answer...
Ok so in the end this was a nightmare. It involved first disable a security patch made by
microsoft. Here the details:
https://support.microsoft.com/en-us/help/3155464/ms16-065-description-of-the-tls-ssl-protocol-information-disclosure-vu
I made it programmatically:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
AppContext.SetSwitch("Switch.System.Net.DontEnableSchSendAuxRecord", true);
That way i could get past the org.xml.sax.SAXParseException which was a response made by the WebServer. Even when i changed the raw message using a custom message enconder, it seems to be WCF or maybe even the OS was writting some bytes or modify the final SOAP message on the fly. Disabling that security patch on the fly prevented this from happening.
Now next thanks to the custom message encoder, i could see that the webservice was finally returning a valid message, but WCF didnt parse it correctly. After hours of testing, i figure it out:
Original response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getSeedResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getSeedReturn xsi:type="xsd:string">
<?xml version="1.0" encoding="UTF-8"?><SII:RESPUESTA xmlns:SII="http://www.sii.cl/XMLSchema"><SII:RESP_BODY><SEMILLA>013052590000</SEMILLA></SII:RESP_BODY><SII:RESP_HDR><ESTADO>00</ESTADO></SII:RESP_HDR></SII:RESPUESTA>
</getSeedReturn>
</getSeedResponse>
</soapenv:Body>
</soapenv:Envelope>
By removing the ns1 prefix everywhere (including xmlns:ns1="http://DefaultNamespace") i could finally get the correct parsing.
After fixed:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getSeedResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<getSeedReturn xsi:type="xsd:string">
<?xml version="1.0" encoding="UTF-8"?><SII:RESPUESTA xmlns:SII="http://www.sii.cl/XMLSchema"><SII:RESP_BODY><SEMILLA>013052590000</SEMILLA></SII:RESP_BODY><SII:RESP_HDR><ESTADO>00</ESTADO></SII:RESP_HDR></SII:RESPUESTA>
</getSeedReturn>
</getSeedResponse>
</soapenv:Body>
</soapenv:Envelope>
I still dont understand neither the security patch or why WCF fails to parse the message with the NS1 prefix.
If anyone dare to take a look at this i would be very happy, cause i think this solutions are a little hacky and honestly i can see why people would prefer to use java instead of WCF.
In your scenario (.net 4.7) I prefer to use this technology: "add web reference" and not "add service reference"
Here you can find the difference between using one or another technology, one is more current than the other:
Web Reference vs. Service Reference
Since your scenario is not .net core then you have a choice.

WCF SOAP namespaces

I need to host a SOAP service for an external client who requires a specific WSDL and therefore specific input and output soap payloads. I've managed to get the payloads close but I'm having issues generating namespaces exactly how I want them on both the input payload and the output payload.
For example:
REQUIRED inbound payload:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:glen="http://www.glen.com/glen/">
<soapenv:Header/>
<soapenv:Body>
<glen:ProcessXMLMessage>
<MessageID></MessageID>
<XML></XML>
</glen:ProcessXMLMessage>
</soapenv:Body>
</soapenv:Envelope>
ACTUAL inbound payload:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:glen="http://www.glen.com/glen/">
<soapenv:Header/>
<soapenv:Body>
<glen:ProcessXMLMessage>
<glen:MessageID></glen:MessageID>
<glen:XML></glen:XML>
</glen:ProcessXMLMessage>
</soapenv:Body>
</soapenv:Envelope>
The only differences here is that the namespace is used on the attributes, and from what I can see there is no native way to do this in WCF. See another post on the topic that was never answered: WCF SOAP - Remove namespace from child nodes
I also had an issue with formatting the WSDL to force mandatory attributes however I was able to get around that using this: http://thorarin.net/blog/post/2010/08/08/Controlling-WSDL-minOccurs-with-WCF.aspx
Any help greatly appreciated.

sending SOAP request in asp.net mvc3

I want to send following SOAP/XML request and get the SOAP response back in asp.net mvc/C#
<?xml
<soapenv:Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:myurn">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:fLocHistory 
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <HistRequest 
xsi:type="urn:SubMemLocationHistoryRequest">
            <MSID xsi:type="xsd:string">test</MSID>
            <AID xsi:type="xsd:int">2</AID>
            <MemMSISDN xsi:type="xsd:string">test</MemMSISDN>
         </HistRequest>
      </urn:fLocHistory>
   </soapenv:Body>
</soapenv:Envelope>
What is the better way to send request. I have seen example regarding MSXML2, WCF or asmx. If you could point some good starting tutorial. I have seen some examples here and here and here.

Delphi SOAP Envelope and WCF

I am working on a system that provides a soap interface. One of the systems that are going to use the interface is coded in Delphi 7. The web service is developed with WCF, basic http binding, SOAP 1.1.
If I use SOAP UI (JAVA), the service works properly. But Delphi seems to do special things here ;)
This is how the message looks like in SOAP UI:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.xxx.de/xxx">
<soapenv:Header/>
<soapenv:Body>
<ser:GetCustomer>
<!--Optional:-->
<ser:GetCustomerRequest> <!-- this is a data contract -->
<ser:Id>?</ser:Id>
</ser:GetCustomerRequest>
</ser:GetCustomer>
</soapenv:Body>
</soapenv:Envelope>
I am not a delphi developer , but I developed a simple test client to see what's going wrong. This what Delphi sends as a SOAP envelope.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:NS2="http://services.xxx.de/xxx">
<NS1:GetCustomer xmlns:NS1="http://services.xxx.de/xxx">
<GetCustomerRequest href="#1"/>
</NS1:GetCustomer>
<NS2:GetCustomerRequest id="1" xsi:type="NS2:GetCustomerRequest">
<Id xsi:type="xsd:int">253</Id>
</NS2:GetCustomerRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
WCF throws an error that is in German language... ;)
Es wurde das Endelement "Body" aus Namespace "http://schemas.xmlsoap.org/soap/envelope/" erwartet. Gefunden wurde "Element "NS2:GetCustomerRequest" aus Namespace "http://services.xxx.de/xxx"". Zeile 1, Position 599.
Means something like
The Body was expected. But instead the Element "NS2:GetCustomerReques" was found.
Now my questions is: Can I somehow change the way Delphi creates the envelope? Or are the ways to make WCF work with such message formats? Any help is greatly appreciated!
Contrary to what some people here seem to be implying, Delphi is not sending invalid SOAP, it is simply sending RPC/Encoded SOAP. It's very easy to recognize from all the xsi:type attributes. RPC/Encoded is not WS-I compliant but it is still valid SOAP.
WCF, by default, uses the Document/Literal/Wrapped SOAP format, which Delphi 7 can't handle at all on the server side and you have to make some adjustments on the client side.
The simplest solution is to simply tell Delphi to use the Document/Literal style. You do that by turning on soLiteralParams in the THttpRio.Converter.Options. This tells Delphi not to "unwind" the parameters as you are seeing. The "Document" aspect is something that the Delphi WSDL importer can usually figure out so you shouldn't need to worry about that.
The other solution is to tell the WCF service to use RPC/Encoded style, which you can do by adding the following attributes to the service:
[ServiceContract]
[XmlSerializerFormat(Style = OperationFormatStyle.Rpc,
Use = OperationFormatUse.Encoded)]
public interface IMyService
{
// etc.
}
The second is not recommended because, as I mentioned earlier, RPC/Encoded is not WS-I compliant, but nevertheless most SOAP toolkits do recognize it, so I list it here as a possibility.
I just did one of these, and I ended up with a series of stringreplace calls to alter my XML output to strip the in-line namespaces out and make it look like SoapUI's format. Yes it takes a lot of manual hacking to do that.
ex:
After you create the RIO, call your own BeforeExecute proc:
...
EEUPSERTRIO.OnBeforeExecute := self.RIO_BeforeExecute;
...
procedure TMyWrapper.RIO_BeforeExecute(const MethodName: string; var SOAPRequest: WideString);
{
Since Delphi isn't very good at SOAP, we need to fix the request so that the namespaces are correct.
Basically, you take what Delphi gives you and try it in SoapUI.
If yours doesn't work and SoapUI's version does, make yours look like theirs.
}
...
Now strip out the in-line Namespaces:
SOAPRequest := StringReplace(SOAPRequest,' xmlns:NS1="http://services.xxx.de/xxx"','',[rfReplaceAll,rfIgnoreCase]);
...
Lots of these.
Then you'll replace the soap header with one that contains the namespaces that you want.
SOAPRequest := StringReplace(SOAPRequest,'xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"','xmlns:ns1="http://services.xyzcorp.com/xyz/EnterpriseEmployeeService_1_0" '+'xmlns:ns1="http://schemas.xyzcorp.com/TLOIntegration_HRO_Preview/TLOIntegration_1_0" ',[]);
Then you can re-inject good ones:
ReplaceTag(SOAPRequest,'<metaData>','ns1:');
ReplaceTag(SOAPRequest,'<trackingId>','ns1:');
ReplaceTag(SOAPRequest,'<srcSystem>','ns1:');
Lastly, you can easily capture your Delphi output by re-consuming the WSDL with SoapUI and having it host a mockservice. Then point your app to it as the endpoint, and it'll capture the ouput.
Or, you can use Fiddler as a proxy, to capture requests.
Delphi and Java frameworks use different name space. One way to make if compatible is to intercept the raw xml and change all the "NS2" to whatever the deserializer expects
Cheers

Categories

Resources