Schnittstelle

namespace SQRT_WCF
    {
    [DataContract]
    public class PlaceOrder
    {
        [DataMember]
        public string claimID { get; set; }
        [DataMember]
        public string rederenceDate { get; set; }
    }
}

C # -Methode aufgerufen:

public SQ_jsonModel.Response placeOrder(PlaceOrder argPlaceOrderJSON)
{
   ...
}

Ich habe meinen Webservice an die Arbeitsprozesse angehängt und den Code nachverfolgt. Soweit ich es versucht habe, ist die Variable argPlaceOrderJSON null.

Ich habe mindestens drei Varianten ausprobiert:

Variation # 1

{
         "claimID" : "value",
         "rederenceDate" : "value"
}

Variation # 2:

{
    "PlaceOrder" : {
         "claimID" : "value",
         "rederenceDate" : "value"
}

Variation # 3:

{
    "ns0:PlaceOrder" : {
        "@xmlns:ns0" : "SQRT_WCF",
         "claimID" : "value",
        "rederenceDate" : "value"
}

Ich habe ein schnelles C # -Konsolenprogramm geschrieben, um ein Objekt zu erstellen und zu serialisieren. Es entspricht der obigen Variante 1. Jetzt denke ich, dass das Problem nicht JSON ist, sondern das Problem mit dem Handshake zwischen SOAP-UI und dem Webdienst. Ich werde einen C # -Test-Client schreiben, um zu sehen, was dort passiert.

SQRT_WCF.PlaceOrder order = new SQRT_WCF.PlaceOrder();
order.ClaimID = "claim1"; 
string strJson = new JavaScriptSerializer().Serialize(order);

Jemand hat im Webservice nach Attributen gefragt, vorausgesetzt, er meint Folgendes:

public interface ISQRTREST {[OperationContract] void DoWork ();

    [OperationContract]
    [WebInvoke(Method="GET",
        ResponseFormat = WebMessageFormat.Json ,
        BodyStyle = WebMessageBodyStyle.Wrapped ,
        UriTemplate ="json/{id}"
        )]
    string JSONData(String id);


    [OperationContract]
    [WebInvoke(Method = "POST",
        ResponseFormat = WebMessageFormat.Json,
        BodyStyle = WebMessageBodyStyle.Wrapped,
        UriTemplate = "placeOrder/"
        )]
    SQ_jsonModel.Response placeOrder(PlaceOrder order);

}

Web.Config

<?xml version="1.0"?>
<configuration>

  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <services>
      <service name="SQRT_WCF.SQRTREST" behaviorConfiguration="ServiceBehaviour">
        <endpoint address="" binding="webHttpBinding" bindingConfiguration="longTimeoutBinding" contract="SQRT_WCF.ISQRTREST" behaviorConfiguration="web">
        </endpoint>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehaviour">
          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="web">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <bindings>
      <webHttpBinding>
        <binding name="longTimeoutBinding"
        receiveTimeout="00:10:00" sendTimeout="00:10:00">
          <security mode="None"/>
        </binding>
      </webHttpBinding>
    </bindings>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
 <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>

</configuration>

UPDATE: Scheint, als würde BodyStyle = WebMessageBodyStyle geänder

Aber jetzt ist das Problem, dass ich in der Lage sein muss, es mit WebMessageBodyStyle.Wrapped zum Laufen zu bringen.

Dies ist ein bestehender Webdienst, den es in der Produktion gibt. Die Person, die das Programm geschrieben hat, ist längst weg, und jetzt übernimmt das B2B / BizTalk-Team das Projekt. Wir verwenden BT2010, das noch kein REST hat, und wir versuchen, unseren Kunden dieselbe Schnittstelle zur Verfügung zu stellen, damit sie nichts anderes als die URL ändern müssen.

RESTful Web-Service-Body-Format scheint ziemlich gut zu erklären, ich werde gleich Variante 2 mit der Option .wrapped in C # ausprobieren.

Update 2: Beim Versuch von Variante 2 mit BodyWrapped wird immer noch ein Null-Objekt abgerufen:

Dies ist, wie ich es eingewickelt habe. Nahm, was in Update1 @ funktionier

string strPostBodyWrapped = "{\"PlaceOrder\" : " + strPostBody + "}";

Wird nach dem Mittagessen mehr debuggen.

Update 3: Immer noch kein Glück. Basierend auf der obigen StackOverflow-Referenz sollte der Wrapper "entity" sein, was ich auf verschiedene Arten ausprobiert habe:

Von SOAP-UI:

{
    "entity" : { 
        "claimID" : "value",
}

Ich habe auch "Entity" anstelle von "entity" ausprobiert.

Alle Felder in meinem Datenvertrag sind Zeichenfolgen, daher sollte es kein Problem geben, Daten oder Zahlen zu serialisieren.

Von C # Client-Tester-Programm:

            strPostBody = replaceSingleWithDoubleQuotes("{'ClaimID':'testvalue'}"); 

            string strPostBodyWrapped = replaceSingleWithDoubleQuotes("{'entity': ") + strPostBody + "}";

public static string replaceSingleWithDoubleQuotes(string argText)
    {
        return argText.Replace("'", "\"");
    }

Wenn ich in SOAP_UI etwas Schlechtes versuche, wie folgt:

{
    "entity" : {  xxx 
        "claimID" : "value",
}

Dann wurde mir klar, dass die Entität kein Schlüsselwort war, sondern der Name seiner Klasse ... oops. Ich habe also sowohl "Placeorder" als auch "placeorder" als Wrapper für meinen Fall ausprobiert.

Ich erhalte eine nette Fehlermeldung wie diese:

The server encountered an error processing the request. The exception message is 'The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation 'placeOrderSQRT'. Encountered unexpected character 'x'.'...

So verstehe ich nicht, warum in diesem Fall der Parser fehlschlägt, aber in anderen Fällen schlägt er nicht fehl, aber es werden auch keine Feldwerte festgelegt.

Wenn ich ungültige Feldnamen versuche, aber die Syntax korrekt ist, scheint der Parser keinen Fehler zu geben, z. "claimIDxxxxxxxx": "value"