S
Steve Schuler
Hi all, I have a trading partner who wants to send a document
<soap:Envelope...>
<soap:Body>
<ACORD ...>
<etc/>
</ACORD>
</soap:Body>
</soap:Envelope>
They are using a Java-based toolkit that evidently is more flexible than
..NET... here's where the mismatch comes from:
I need to retrieve the entire fragment under the Body, *including* the
<ACORD ...> element. I can get almost there by using[SoapDocumentMethod(
ParameterStyle=SoapParameterStyle.Bare )], but that still leaves an outer
element named for my Web Method's parameter. I could tell the deserializer
to treat the ACORD elemement as the Web Method's parameter like so:
public XmlElement ProcessXML([XmlElement("ACORD")] XmlElement acordDoc)
but this causes me to get the inner XML of the ACORD element as the value of
acordDoc, dropping the ACORD element itself. I've thought of two hacks,
both of which really suck:
Hack #1 is that I declare my method with no parameters, and then I use
Context.Request.InputStream and then parse the ACORD from the SOAP myself.
That's easy were it not for one problem: This message actually comes in as
a SOAP with Attachments (SwA) MIME stream (I've written a SoapExtension that
strips off the attachments, so the Web Method only sees the SOAP). The
problem is that Context.Request.InputStream gives you the raw MIME - I don't
see any way for a Web Method to say "give me the SOAP message". So I'd be
left with the Web Method implementor being forced to parse the MIME
themselves to do this, which kind of loses the whole point of SOAP and the
SwA SoapExtension design.
Hack #2 is I use the [XmlElement("ACORD")] trick to make the parameter name
ACORD, and simply live with losing the ACORD element. As long as that
element doesn't get too creative with namespaces, *and* doesn't have any
attributes that I need to process, I can "re-hydrate" an input parameter
that I declare as an XmlElement array by wrapping an ACORD element I create
around the array input parameter. The problem with this one is that it's
not general purpose: I lose the attributes and I have to know up front what
the namespaces are that will be declared on the ACORD element.
Can anyone see a better way?
Thanks,
Steve Schuler
Application Consulting, ITOps
SAFECO Insurance Companies
To reply with email, remove the "NOSPAM"
<soap:Envelope...>
<soap:Body>
<ACORD ...>
<etc/>
</ACORD>
</soap:Body>
</soap:Envelope>
They are using a Java-based toolkit that evidently is more flexible than
..NET... here's where the mismatch comes from:
I need to retrieve the entire fragment under the Body, *including* the
<ACORD ...> element. I can get almost there by using[SoapDocumentMethod(
ParameterStyle=SoapParameterStyle.Bare )], but that still leaves an outer
element named for my Web Method's parameter. I could tell the deserializer
to treat the ACORD elemement as the Web Method's parameter like so:
public XmlElement ProcessXML([XmlElement("ACORD")] XmlElement acordDoc)
but this causes me to get the inner XML of the ACORD element as the value of
acordDoc, dropping the ACORD element itself. I've thought of two hacks,
both of which really suck:
Hack #1 is that I declare my method with no parameters, and then I use
Context.Request.InputStream and then parse the ACORD from the SOAP myself.
That's easy were it not for one problem: This message actually comes in as
a SOAP with Attachments (SwA) MIME stream (I've written a SoapExtension that
strips off the attachments, so the Web Method only sees the SOAP). The
problem is that Context.Request.InputStream gives you the raw MIME - I don't
see any way for a Web Method to say "give me the SOAP message". So I'd be
left with the Web Method implementor being forced to parse the MIME
themselves to do this, which kind of loses the whole point of SOAP and the
SwA SoapExtension design.
Hack #2 is I use the [XmlElement("ACORD")] trick to make the parameter name
ACORD, and simply live with losing the ACORD element. As long as that
element doesn't get too creative with namespaces, *and* doesn't have any
attributes that I need to process, I can "re-hydrate" an input parameter
that I declare as an XmlElement array by wrapping an ACORD element I create
around the array input parameter. The problem with this one is that it's
not general purpose: I lose the attributes and I have to know up front what
the namespaces are that will be declared on the ACORD element.
Can anyone see a better way?
Thanks,
Steve Schuler
Application Consulting, ITOps
SAFECO Insurance Companies
To reply with email, remove the "NOSPAM"