1

Hei all,

I noticed a strange behavior of my SOAP Webservice.

When sending the request via soap ui i filled every property of the object.

While debugging the webservice only a few properties where filled. It seems the top 5 properties, out of 15, are filled. When switching the properties in the Soap request, again the top 5 are filled.

Does anyone have a clue, why the serializing of the request object is not working ?

The interfaces are defined as OperationContract , properties and the request class as DataMember / DataContract.

Here is the Request Class

[DataContract]
public class Article
{
    [DataMember]
    public String ArticleName
    {
        get { return _ArticleName; }
        set { _ArticleName = value; }
    }

    [DataMember]
    public String Description
    {
        get { return _Description; }
        set { _Description = value; }
    }

    [DataMember]
    public Int ProductSubGroupNumber
    {
        get { return _ProductSubGroupNumber; }
        set { _ProductSubGroupNumber = value; }
    }

    [DataMember]
    public Double ArticleNumber
    {
        get { return _ArticleNumber; }
        set { _ArticleNumber = value; }
    }

    [DataMember]
    public Int Color
    {
        get { return _Color; }
        set { _Color = value; }
    }

    [DataMember]
    public Double Quantity
    {
        get { return _Quantity; }
        set { _Quantity = value; }
    }

    [DataMember]
    public Int Version
    {
        get { return _Version; }
        set { _Version = value; }
    }

    [DataMember]
    public Int Material
    {
        get { return _Material; }
        set { _Material = value; }
    }

    [DataMember]
    public Int Warehouse
    {
        get { return _Warehouse; }
        set { _Warehouse = value; }
    }
}

And the Soap Request

      <CreateArticle>
     <ArticleGroup>1232456789</ArticleGroup>
     <Articles>
        <Article>
           <ArticleName>test</ArticleName>
           <Description>TEST 1213123</Description>
           <ProductSubGroupNumber>987654</ProductSubGroupNumber>
           <ArticleNumber>12345</ArticleNumber>
           <Color>0</Color>
           <Quantity>1</Quantity>
           <Material>0</Material>
           <Warehouse>0</Warehouse>
           <Version>0</Version>
        </Article>
     </Articles>
  </CreateArticle>

In the debugger are only Attributes till Color filled - the rest is Null. If I swap them in the request, other are Filled and others not.

The Request Contains a ArticleGroupID as Int and an Array of Articles.

Twiebie
  • 412
  • 1
  • 7
  • 16
  • impossible to say much without code, but: were they set to the corresponding default values, perhaps? – Marc Gravell Jan 22 '18 at 10:06
  • well its just a simple request Class with get and set functions for each property. Defauld values are not set, all properties are only simple types (int, double and string) – Twiebie Jan 22 '18 at 10:08
  • Show the relevant C# code and show the request in SoapUI. – CodeCaster Jan 22 '18 at 10:09
  • We can do nothing without the provided code, sorry – David Hruška Jan 22 '18 at 10:18
  • @CodeCaster added code samples ;) – Twiebie Jan 22 '18 at 10:20
  • @DavidHruška added code samples ;) – Twiebie Jan 22 '18 at 10:20
  • `Int` isn't a type, it's either `int` or `Int32`, so I guess you modified the code somewhat. Anyway WCF SOAP elements are order-sensitive. Either set an explicit order using attributes, or make sure the request XML matches the declared property order - [which isn't guarenteed](https://stackoverflow.com/questions/9062235/get-properties-in-order-of-declaration-using-reflection) anyway. – CodeCaster Jan 22 '18 at 10:25
  • IIRC, `DataContractSerializer` is fussy about the order, and reflection by itself *has no guaranteed order*, so you'd need to add `Order = n` to each of your `[DataMember]` attributes to tell it the order you expect – Marc Gravell Jan 22 '18 at 10:27
  • I pasted the code in Word from VS. So it may auto formated it to Int from int. By sending the Attributes in a different order, there should be no problem with it, or? When serializing XMLs, missing or empty values are filled with null, so do I need this ordering? – Twiebie Jan 22 '18 at 10:28
  • @MarcGravell I have the option to switch the serializer, is there a better one to use, if DataContractSerializer is to fuzzy? – Twiebie Jan 22 '18 at 10:29
  • Yes, there should be a problem. The received elements are matched in order against the type. If the order doesn't match, successive elements are ignored. Apply the Order property to the DataMember attribute, and/or order your XML properly. – CodeCaster Jan 22 '18 at 10:29
  • Note: you can *usually* use the provided WCF tools (`svcutil`, IIRC) to generate the C# types *for you* from a SOAP definition - it will generate exactly what it needs – Marc Gravell Jan 22 '18 at 10:38

1 Answers1

2

It looks like this is DataContractSerializer's fussy "order" enforcement. It really really wants to know what order the data will be in. You could try educating it:

[DataMember(Order=0)]
public string ArticleName {get;set;}

[DataMember(Order=1)]
public string Description {get;set;}

[DataMember(Order=2)]
public int ProductSubGroupNumber {get;set;}

[DataMember(Order=3)]
public double ArticleNumber {get;set;}

[DataMember(Order=4)]
public int Color {get;set;}

[DataMember(Order=5)]
public double Quantity {get;set;}

[DataMember(Order=8)]
public int Version {get;set;}

[DataMember(Order=6)]
public int Material {get;set;}

[DataMember(Order=7)]
public int Warehouse {get;set;}
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • After adding and order to the DataMembers and changing the Order in the Soap XML Request repectivly, all worked fine. Many thanks ! ;) – Twiebie Jan 22 '18 at 10:51
  • 1
    I usually write the attribute like this `[DataMember(nameof(MyProperty), Order = 0, IsRequired = true)]` - therefore I have secured orders and required elements :) – David Hruška Jan 22 '18 at 11:04
  • 1
    @DavidHruška the name is implicitly the member name when not specified, though; adding the `nameof(...)` here *introduces* the risk of a copy/paste bug, without actually doing anything additional – Marc Gravell Jan 22 '18 at 11:05
  • Yep, I agree. I am quite used to this expression, but to prevent the copy/paste bug isbetter to omit the Name property. Agree ;) – David Hruška Jan 22 '18 at 11:11