domhk: Taking JSON input with D365 service and deserialize into contract class

[DSPIC]

Давайте разбираться.

Цитата:

Сообщение от gl00mie

Это называется "закат солнца вручную".
...
PS. Сама постановка задачи уже наводит на подозрения:
Зачем это, спрашивается, в D365FO делать кастомный сервис, который на входе получал бы JSON, а не нормальный типизированный контракт?..

Про закат вручную:
Тут не вручную, а помощью стандартного класса FormJsonSerializer (D365).

Во-вторых - задача, когда на вход извне впаривают сырой JSON (или XML) стоит сплошь и рядом: "Мы вам будем передавать XML\JSON строку и точка. Мы не можем переделать нашу систему под вашу, чтобы завязаться на ваш веб сервис. Или можем, но за большие деньги, где-то через года пол. Наши клиенты по всему миру, мы работаем только так".
А какие есть альтернативы? Чаще всего для jSON встречается ручной парсинг строк strScan, strFind и т.д. Изредка попадаются продвинутые выринты - используют Newton.JSon.dll. C XML немного проще - стандартный класс пробега по XML с большего освоили, но это всё-равно абсолютный хардкод.

Про аттрибут:
Класс FormJsonSerializer понимает только DataCollectionAttribute. Более того, для дата-контрактов с их parm* методами этот аттрибут идеально подходит (на входе один параметр с таким же типом что и на выходе).

AifCollectionTypeAttribute пришел из AX2012. Он больше подходит для описания сервис-операций, где может быть несколько входных параметров, разных типов, а на выходе что-то третье. Но в AX2012 других выриантов не было.

Для сравнения:

// D365:
[
  DataMemberAttribute("Student list"),
  DataCollectionAttribute(Types::Class, classStr(StudentInfoContract))
]
public List parmStudentList(List _studentList = studentList)

// ИЛИ AX2012:
[
  DataMemberAttribute("Student list"),
  AifCollectionTypeAttribute("return", Types::Class, classStr(StudentInfoContract)),
  AifCollectionTypeAttribute("_studentList", Types::Class, classStr(StudentInfoContract))
]
public List parmStudentList(List _studentList = studentList)

Т.е.второй вариант избыточный для дата-контрактов имхо.
Единственное - не уверен, понимает ли сериализатор D365 этот атрибут при описании контрактов для веб-сервисов - не приходилось применять, но как бы must Have.

Цитата:

Сообщение от mazzy

пробелы в названии...
Какие заботливо разложенные грабли.

В XML так нельзя. В jSON можно.



Претензия к автору блога у меня только одна: корее всего куски кода он где-то вырвал и не тестировал. Или спешил, промазал и недопроверил

while (enumerator.moveNext())
        {
            Newtonsoft.Json.Linq.JObject    jObj = enumerator.current();

            studentInfoContract = FormJsonSerializer::deserializeObject(classNum(StudentInfoContract),jObj.ToString());

            str studentId, studentName;

            studentId   = studentInfoContract.parmStudentId();
            studentName = studentInfoContract.parmStudentName();

            Info(strFmt("Studnet # %1: %2", studentId, studentName));
        }

естественно, вот на этом получит моментальный взлёт, пытаясь закастить аксаптовский класс в CLR тип.

Newtonsoft.Json.Linq.JObject    jObj = enumerator.current();

Вообще не понятно, как это должно было работать. С другой стороны - юридически, он прикрылся "This posting is provided "AS IS" with no warranties, and confers no rights."

Наверное он так хотел сделать:

public static void main(Args _args)
    {
        StudentsContract        studentsContract;

        void addStudent(str _id, str _name)
        {
            StudentInfoContract student = new StudentInfoContract();

            student.parmStudentId(_id);
            student.parmStudentName(_name);

            studentsContract.parmStudentList().addEnd(student);
        }

        studentsContract = new StudentsContract();

        studentsContract.parmStudentList(new List(Types::Class));
        
        addStudent("1", "First");
        addStudent("2", "Second");

        // Serialize
        str jSon = FormJsonSerializer::serializeClass(studentsContract);

        // Deserialize
        studentsContract = FormJsonSerializer::deserializeObject(classNum(StudentsContract), jSon);

        ListEnumerator enumerator = studentsContract.parmStudentList().getEnumerator();

        while (enumerator.moveNext())
        {
            StudentInfoContract student = enumerator.current();

            info(strFmt("Studnet # %1: %2", student.parmStudentId(), student.parmStudentName()));
        }
    }

[gl00mie]

Цитата:

Сообщение от DSPIC

Тут не вручную, а помощью стандартного класса FormJsonSerializer (D365).

Имя стандартного класса как бы намекает, что он задумывался больше для форм, чем для сервисов

Цитата:

Сообщение от DSPIC

Во-вторых - задача, когда на вход извне впаривают сырой JSON (или XML) стоит сплошь и рядом: "Мы вам будем передавать XML\JSON строку и точка. Мы не можем переделать нашу систему под вашу, чтобы завязаться на ваш веб сервис.".

Наверно, так тоже бывает, но в данном случае автор сам же пишет: я решил сделать сервис, вот его контракт, в контракте есть коллекция классов. Он не пишет, что парсит чей-то чужой JSON - напротив, он получает на вход именно тот контракт, который заказывал, только "недодесериализованный", полусырой, так сказать. Скажу больше: кастомные сервисы в D365FO доступны извне и как REST (с JSON-ом на входе), и как SOAP-сервисы (c XML на входе), но из-за того, что автор использовал не тот атрибут в контракте, он и для SOAP-варианта своего сервиса получил полусырой WSDL, в котором коллекция классов будет представлена как просто абстрактный массив не пойми чего. Использованием неправильного атрибута автор и себе лишнюю работу создал, и клиентам, которые попытаются WSDL сервиса посмотреть, проблем подкинул.

Цитата:

Сообщение от DSPIC

Про аттрибут:
Класс FormJsonSerializer понимает только DataCollectionAttribute. Более того, для дата-контрактов с их parm* методами этот аттрибут идеально подходит (на входе один параметр с таким же типом что и на выходе).

Идеально подходит для любителей ручного разбора JSON и полусырых WSDL-ей

Цитата:

Сообщение от DSPIC

AifCollectionTypeAttribute пришел из AX2012.

Какая разница, откуда пришел атрибут? DataContractAttribute тоже был в AX2012, и что, может, на этом основании его не использовать? Приложение D365FO на 90-95% - это приложение AX2012 R3, и если какие-то вещи из AX2012 продолжают успешно работать в D365FO, а альтернатива им - закат солнца вручную, то какой смысл от них отказываться?

Цитата:

Сообщение от DSPIC

Он больше подходит для описания сервис-операций, где может быть несколько входных параметров, разных типов, а на выходе что-то третье.

Либо на входе сервисного метода - коллекция одних типов, а на выходе - коллекция других типов.

Цитата:

Сообщение от DSPIC

Но в AX2012 других выриантов не было.

Во-первых, были альтернативы, посмотрите хотя бы на полёт фантазии в FormLetterContract:

[DataMemberAttribute]
public str parmDataSourceRecordsPacked(str _dataSourceRecordsPacked = '')
{
    if (prmIsDefault(_dataSourceRecordsPacked))
    {
        return SysOperationHelper::base64Encode(this.parmDataSourceRecordMapPacked());
    }

    return SysOperationHelper::base64Encode(this.parmDataSourceRecordMapPacked(SysOperationHelper::base64Decode(_dataSourceRecordsPacked)));
}

Мощно?!
Во-вторых, никто не мешал даже в AX2012 определить свой класс атрибута и парсить вручную что угодно аналогично тому, как это теперь делает FormJsonSerializer.

Цитата:

Сообщение от DSPIC

Для сравнения:

// D365:
[
  DataMemberAttribute("Student list"),
  DataCollectionAttribute(Types::Class, classStr(StudentInfoContract))
]
public List parmStudentList(List _studentList = studentList)

// ИЛИ AX2012:
[
  DataMemberAttribute("Student list"),
  AifCollectionTypeAttribute("return", Types::Class, classStr(StudentInfoContract)),
  AifCollectionTypeAttribute("_studentList", Types::Class, classStr(StudentInfoContract))
]
public List parmStudentList(List _studentList = studentList)

Мы же помним, что кастомные сервисы в D365FO доступны извне одновременно и как REST, и как SOAP-сервисы, причем в REST метаданные, мягко говоря, победнее. Сделаем в контракте два поля, одно - studentList - с атрибутом DataCollection, а другое - studentListAif - с атрибутом AifCollectionType. И посмотрим теперь, как такие поля в контракте сервиса D365FO выглядят в WSDL:

PHP код:

<xs:complexType name="StudentsContract">
 <xs:complexContent mixed="false">
  <xs:extension xmlns:q8="http://schemas.datacontract.org/2004/07/Microsoft.Dynamics.Ax.Xpp" base="q8:XppObjectBase">
   <xs:sequence>
    <xs:element xmlns:q9="http://schemas.microsoft.com/2003/10/Serialization/Arrays"
                minOccurs="0" name="StudentList"
              nillable="true" type="q9:ArrayOfanyType"/>
    <xs:element minOccurs="0" name="StudentListAif"
              nillable="true" type="tns:ArrayOfStudentInfoContract"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>
<xs:element name="StudentsContract" nillable="true" type="tns:StudentsContract"/>
<xs:complexType name="ArrayOfStudentInfoContract">
 <xs:sequence>
  <xs:element minOccurs="0" maxOccurs="unbounded" name="StudentInfoContract" nillable="true" type="tns:StudentInfoContract"/>
 </xs:sequence>
</xs:complexType>
<xs:element name="ArrayOfStudentInfoContract" nillable="true" type="tns:ArrayOfStudentInfoContract"/>
<xs:complexType name="StudentInfoContract">
 <xs:complexContent mixed="false">
  <xs:extension xmlns:q10="http://schemas.datacontract.org/2004/07/Microsoft.Dynamics.Ax.Xpp" base="q10:XppObjectBase">
   <xs:sequence>
    <xs:element minOccurs="0" name="StudentId" nillable="true" type="xs:string"/>
    <xs:element minOccurs="0" name="StudentName" nillable="true" type="xs:string"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType> 


Видим, что для DataCollection мы получили StudentList в виде ArrayOfanyType, без какой-либо дальнейшей детализации.
А для AifCollectionType мы получили StudentListAif в виде ArrayOfStudentInfoContract с полной разблюдовкой: мы видим в WSDL и сам StudentInfoContract, и то, что он состоит из двух строковых полей: StudentId и StudentName. И повторюсь: для AifCollectionType платформа занимается тем, что десериализует для вашего сервиса коллекцию объектов и заодно проверяет, что объекты в коллекции - нужного типа, а не абы что. По-моему, это всё в совокупности стоит того, чтобы добавить методу лишний атрибут.