Ein knackiger und kompakter Überblick auf die...

Read more

Auch am dritten Tag gab es interessante...

Read more

Die großen Ankündigungen aus dem ersten Tag...

Read more

Keynote - Stand der Integration - Jon Fancey:...

Read more

Integrieren Sie noch oder managen Sie bereits den...

Read more

Inwieweit lassen sich vorhandene BizTalk Lösungen...

Read more

Wie kann ein Prozess Monitoring einfach und...

Read more

Führende Veranstaltung rund um Connectivity auf...

Read more

Stellenanzeige: Wir suchen dringend an unserem...

Read more

How-to: Array-Serialisierung in der JSON-Send-Pipeline

Wir hatten vor kurzem ein sehr faszinierendes Problem, dass das von BizTalk erzeugte JSON nicht unseren Erwartungen entsprach. Insbesondere wurde ein Element mal als Array serialisiert, mal nicht. Relativ schnell stellte sich heraus, dass ein Array genau dann erzeugt wurde, wenn mehr als ein entsprechendes Element vorhanden war.

Schauen wir erstmal ein minimal working Example an:

Soweit nichts Spannendes. Versuchen wir also mal das folgende XML mit dem üblichen JSON-Encoder umzuwandeln:

Und dabei kommt raus:

Perfekt! Aber was, wenn wir nur ein ArrayElements-Tag haben, so wie hier?

Heraus kommt:

ArrayElements ist kein Array mehr! Aber wir kommt das? Im Schema steht doch ganz klar:

Und dieses maxOccurs=“unbounded“ ist tatsächlich auch das Einzige, was entscheidet, ob ein Element immer als Array serialisiert wird oder nicht. Aber das steht offensichtlich da, folglich sollte ArrayElements als Array serialisiert werden. Sehr mysteriös! Das Problem ist ein Element höher, denn das heißt nicht SingleElements, sondern nur SingleElement. Dadurch findet der JSON Encoder das ArrayElements-Element nicht mehr im Schema und erkennt somit nicht mehr, dass dieses als Array serialisiert werden soll. Also kein Problem, wir korrigieren das Schema ­– die Eingangsnachricht war korrekt – und schreiben dort SingleElement im Singular. Neu deployt, ab durch den JSON Encoder damit und …

… Moment mal. Jetzt ist SingleElement plötzlich ein Array? Nach allem, was wir gerade gelernt haben, können wir den Fehler aber zum Glück schnell erkennen. SingleElement hat ebenfalls das Attribut maxOccurs=“unbounded“. Das ist an dieser Stelle aber offensichtlich nicht korrekt. Nur weil es bisher falsch geschrieben wurde, wurde es nicht als Array serialisiert. Ob das schon beim Generieren des Schemas passiert ist oder durch händischen Eingriff ließ sich nicht mehr nachvollziehen, aber die Korrektur war denkbar einfach.

Was haben wir gelernt?

Schemas werden von BizTalk generell eher als Empfehlung angesehen, und eine Validierung ist auch nicht immer gewünscht, da die Qualität der Eingangsnachrichten schwankt; so sind Elemente nicht immer in der erwarteten Reihenfolge, was aber außer bei der Validierung überhaupt keine Probleme bereitet. So kam es dann auch, dass BizTalk nicht erkennen konnte, dass das Schema nicht passte, und es erst bei Dynamics zu einem Fehler kam. Eine Ausnahme von

Erschwerend kam hinzu, dass der WCF-WebHttp-Adapter Fehlermeldungen verwirft und diese nicht in BizTalk angezeigt werden. Zudem ist es überraschend kompliziert, an das generierte JSON zu kommen, denn BizTalk trackt nur das XML. Es war somit nicht sofort klar, dass es sich hier um einen Deserialisierungfehler in Dynamics handelt, und mangels JSON ließ sich der Fehler nicht so einfach reproduzieren, um z.B. mit Postman an die Fehlermeldung zu kommen. Es bietet sich an, JSON z.B. mit QUIBIF light im Send Port zu tracken.

Zu guter Letzt sollte man daran denken, bei aus XML generierten, und noch mehr bei von Hand geschriebenen Schemas darauf zu achten, dass die maxOccurs-Attribute den tatsächlichen Anforderungen entsprechen. Außerdem wurde hier wieder der Wert einer guten Testmatrix klar, denn beim Testen wurden offenkundig keine Daten mit nur einem ArrayElements-Tag geschickt, sonst wäre der Fehler schon dort aufgefallen.

Dieser Tipp kommt aus Berlin, QUIBIQ Berlin

© QUIBIQ GmbH · Imprint · Data protection