Invalid values in u0093Read Outbound Deliveryu0094 response?

[Former Member]

<b>Issue:</b> The <a href="http://erp.esworkplace.sap.com/socoview(bD1lbiZjPTgwMCZkPW1pbg==)/smdisplay.asp?id=1B491BE4E28711DB2B24000F20DAC9EF&fragID=&packageid=DBBB6D8AA3B382F191E0000F20F64781&context=&iv=">Read Outbound Delivery</a> service (<b>ECC_OUTBOUNDDELIVERY000QR</b>)

generates a response (OutboundDeliveryByIDResponse_sync/OutboundDelivery ) which contains invalid XML values according to their data types.

<b>Request:</b>

Following request was sent:

<OutboundDeliverySelectionByID ><ID>80015338</ID></OutboundDeliverySelectionByID>

<b>Response issues:</b>

<b>1.</b> The <b><i>“DeliveryTerms/OrderCombinationAllowedIndicator”</i></b> element contained a value of “X”, which is an invalid according to its type="Indicator".

<b>2.</b> The<i><b> “ Item/LastChangeDateTime”</b></i> element contained an invalid value of “0000-00-00T00:00:00”.

<b>Abnormalities:</b>

1. The <b>Indicator</b> type, which is essentially a wrapper around xsd:Boolean data type can only contain values: <i>true</i>, or <i>false</i>.

Following are the excerpts from its WSDL type definition:

<xsd:element name="OrderCombinationAllowedIndicator" type="Indicator" minOccurs="0"/>
<xsd:simpleType name="Indicator"><xsd:restriction base="xsd:boolean"/></xsd:simpleType>

<b>2.</b> The<i><b> “ Item/LastChangeDateTime”</b></i> element contains an invalid DateTime field value (the nearest valid value would be “0001-01-01T00:00:00”.

<xsd:complexType name="DateTime">
	<xsd:simpleContent>
		<xsd:extension base="xsd:dateTime">
			<xsd:attribute name="timeZoneCode" type="TimeZoneCode"/>
		<xsd:attribute name="daylightSavingTimeIndicator" type="xsd:boolean"/>
		</xsd:extension>
	</xsd:simpleContent>
</xsd:complexType>

<b>Consequences:</b>

The service consumers, who have their data types auto-generated in their proxy classes according to the WSDL, would receive runtime framework errors in their programs. The runtime systems would try to de-Serialize the eSOA response XML into the fields of their .NET or Java Objects; and because of invalid values, just fail to parse them into variables of those types <i>(bool and DateTime).</i>

<b>Questions</b>

I was really surprise to observe this interesting phenomenon. It is hard for me to characterize it as a benign bug/overlook. May be I am failing to understand the entire process, and therefore seeking help from <i>eSOA</i> <b>gurus</b> (even at <b>SAP</b>). Following questions instinctively pop up into my mind:

-- Is the XSD Data Type checking being performed at eSOA service output level? If so, did this specific data <i>actually</i> <b>validate</b> in conformance with <b>type</b> declarations within their WSDL?

-- If the data type was boolean in the backend system, how come the value "X" could be stored in that. How is the <b>eSOA</b> server serializer streaming out a value "X" for a boolean field ...??

[Former Member]

I think I have answered this question through other posting in this forum or XI forum.

Anyway let us get started.

WSDL is the service contract generated for an SOA or ESOA service when we use web service as a technology to implement services.

In WSDL all we have done is provide the following information

1. Data type and message types the service functions used in request response model ( directly or indirectly).

2. The rules of engagement for data types and associated contraints, that is what XSD do inside the WSDL. XSD is the schema specification which allow us to define the constraints rules applied to an XML data build using data types and messages defined inside a WSDL.

3. Ports which connect the message to methods of a service

4. Binding: which connect the port to a transport protocol such as JMS and SOAP. That include a combination of style and usage

Style have two values RPC and Literal

Usage has also two value encoded lieral

Combination of style and literal put another contraint on how XML data is passing between consumer and provider of services.

When you accept the contract aggreement as service service consumer, all we are checking is an acceptance of the term and conditions as explained above through the WSDL.

However during the run time, it is upto the XML serialization class implementation at the consumer side to de-serialize the incoming stream of data and serialize outgoing stream of data as per the style and usage combination requirements specificed in the WSDL.

During the XML serilization and deserilization work, it is upto the vendor's implementation to deal with XML with XSD or without XSD, some vendor like Microsoft has some crazy buggy approach to this which create a lot of problem to the inter portability of web services.

My recomendation to your problem related to the way it work in MS world.

1. Test your service using a common WSDL client such as one provided by SAP or another publically available client.

2. Make sure the error is gone away

3. Work with MS guy from your shop, check with him the version of C# and XML serilization class, their startup parameters etc to control these kind of problems during run time and make it work.

Thanks

[Former Member]

Shaji,

did you actually read the original problem? I wonder what the goal of your generic/automated answering of questions is.

So, for you in one sentence: The service returned a response not conforming to the service contract it defined itself.

Someone correct me if I am wrong,

anton

[Former Member]

Shaji,

Thanks for your quick response. I appreciate your enthusiasm while ignoring the lack of comprehension that has caused some irrelevant remarks.

Having said that, would you now look at the questions, and try to answer them. I am sorry for asking a question which you have already answered, please ignore my mistake in not reading all of your answers -- in fact I never even went to XI forum.

Let me now try to guess on what you may have intended to suggest- the question was purely on XML contents not being according to W3C XSD types -- nothing to do with any specific programming language.

"<i>it is upto the vendor's implementation to deal with XML with XSD or without XSD</i>".

So your understanding is that XSD types could be theoretically ignored by an <b>eSOA</b> consumer -- OK!

Of course you know I am specifically taking about <b>SAP</b>'s implementation (eSOA). Are you sure <b>SAP</b> is doing <i>(ignoring)</i> that?

<i>It is a specific question about just one specific eSOA service</i>. Can you really represent <b>SAP</b> on that (partly understood) policy?

I have already successfully consumed dozens of <i>eSOA</i> services, and have always found them to be in compliant with their WSDL declared data types.

Have you <i>actually</i> had an experience that suggests otherwise, even for specific SAP eSOA implementation?? or I may ignore this a mere speculation.

Are you really sure that according the <b>SAP</b> recommendations, <b>xsd:boolean</b> and <b>xsd:dateTime</b> data types should not be taken as a guideline while parsing the eSOA XML contents ?

Just in case you did not understand my question, it is a pure W3C XSD question, I don't know what distracted your off my question when you said: "<i>Microsoft has some crazy buggy approach to this which create a lot of problem to the inter portability of web services</i>".

I would suggest to be a bit more specific/objective -- read the question; and comment on the aspects where you really had experiences, and please share with us.

<i>Now about the irrelevant:</i>

<u><i>There is no point in narrating any failures in upgrading to MS .NET platforms – I am ignoring them and sincerely suggest that MSDN would be a much better forum for that. Like so many developers, I stated with JAVA more than a decade ago but could successfully move to C#/.NET without any issues. So I am not the best person to share your frustration.</i></u>