Как DataWeave знает, какой читатель / писатель использовать? (Мул 4)

У меня проблема с пониманием очень простой темы с DW: я прочитал https://docs.mulesoft.com/mule-user-guide/v/4.1/dataweave-formats но для меня это не объясняет, что именно имеется в виду "DataWeave может читать и записывать много типов форматов данных", то есть:

1) В какой момент DW решает, что он "читает", скажем, ввод JSON?

2) Как именно принимается это решение, т. Е. Что в сообщении Mule определяет, что входные данные должны читаться как JSON (тип полезной нагрузки? Атрибуты?)?

3) В какой момент DW "пишет", скажем, вывод в формате JSON?

4) Как точно выглядит сообщение Mule, созданное, скажем, из вывода JSON сценария DW, (тип полезной нагрузки? Атрибуты?)?

1 ответ

Решение

Я попытаюсь объяснить, как DW работает внутри мула:

Входная часть

  1. У Mule есть специальный объектный вызов TypedValue, этот класс представляет собой пару, являющуюся DataType = Pair.
  2. Все переменные, полезные данные являются TypedValue. И это может также присутствовать в более вложенных местах. Например, операция list в File возвращает List, поэтому полезная нагрузка будет TypedValue, DataType>, что позволяет нам одновременно перечислять файлы разных типов json, xml и т. Д. И dw, чтобы читать их все.

DW использует часть DataType, чтобы определить, какое средство чтения использовать на основе MimeType и как настроить это средство чтения (свойства кодирования, средства чтения) на основе свойств mimetype

Выходная часть

DW всегда выводит TypedValue. Теперь интересная часть заключается в том, как DW выводит часть DataType, которая определяет, какой модуль записи использовать.

  1. Если пользователь указывает его в сценарии с помощью директивы output, то это легко
  2. Если выполняемый сценарий назначен полю обработчика сообщений, то механизм выдаст DW подсказку о том, что является ожидаемым типом, на основе метаданных этого поля. Например, если это Pojo, то DW будет знать, какой класс создавать, и будет знать, что ему нужно использовать Java Writer, поэтому пользователю не нужно будет знать все эти внутренние вещи.
  3. Интересная часть - это когда мы не знаем, например, set-payload. Тогда логика выглядит так:

    • DW посмотрит на сценарий и увидит, какие входные данные используются, если все они имеют одинаковые / совместимые типы данных, тогда он будет использовать это. Это означает, что если в вашем скрипте вы положили <set-payload value="#[payload.foo]/> Мы собираемся посмотреть на тип полезной нагрузки, и если полезной нагрузкой является Json, то мы будем использовать Json Writer. Теперь, если используется более одного ввода, и они относятся к разным типам данных, то будет сгенерирована ошибка IE <set-payload value="#[payload.foo ++ vars.bar]/> являющийся vars.bar типа xml и payload типа Json. Поэтому иногда специально для xml вы можете написать выражение для набора полезных данных, и вы можете потерпеть неудачу, потому что это в конечном итоге является недопустимым xml (например, несколько корней).

    • Если вход не используется, то используется Java-писатель. Так <set-payload value="#[{a: true}]/> собирается вывести java.util.Map с записью ("a", true)

  4. Для Logger В обработчике сообщений мы сделали специальную вещь, чтобы избежать ошибок в журнале. Мы пытаемся использовать логику под #3 но если это не удается из-за того, что средство записи не может выдать эту структуру данных, тогда мы используем модуль записи DataWeave, который может записать любую структуру данных, возможную, поскольку язык dw в основном является надмножеством всех форматов, которые он обрабатывает (он содержит все их функции: объекты, массивы, пространства имен, числа, строки и т.д...)

Надеюсь, это объясняет

Другие вопросы по тегам