В конце входного файла json обнаружены лишние символы

Обновлено: 01.07.2024

Входные переменные позволяют настраивать аспекты модулей Terraform без изменения собственного исходного кода модуля. Это позволяет вам совместно использовать модули в разных конфигурациях Terraform, делая ваш модуль компонуемым и повторно используемым.

Когда вы объявляете переменные в корневом модуле вашей конфигурации, вы можете устанавливать их значения с помощью параметров CLI и переменных среды. Когда вы объявляете их в дочерних модулях, вызывающий модуль должен передавать значения в блок модуля.

Если вы знакомы с традиционными языками программирования, может быть полезно сравнить модули Terraform с определениями функций:

Входные переменные аналогичны аргументам функции. похожи на возвращаемые значения функции. похожи на временные локальные переменные функции.

Примечание. Для краткости входные переменные часто называют просто "переменными" или "переменными Terraform", когда из контекста ясно, о каком типе переменной идет речь. Другие типы переменных в Terraform включают переменные среды (устанавливаются оболочкой, в которой работает Terraform) и переменные-выражения (используются для косвенного представления значения в выражении).

Каждая входная переменная, принимаемая модулем, должна быть объявлена с помощью блока переменных:

Метка после ключевого слова переменной — это имя переменной, которое должно быть уникальным среди всех переменных в одном модуле. Это имя используется для присвоения значения переменной извне и для ссылки на значение переменной внутри модуля.

Именем переменной может быть любой допустимый идентификатор, кроме следующего: source , version , provider , count , for_each , lifecycle , depend_on , locals .

Эти имена зарезервированы для метааргументов в блоках конфигурации модуля и не могут быть объявлены как имена переменных.

Terraform CLI определяет следующие необязательные аргументы для объявлений переменных:

- Значение по умолчанию, которое затем делает переменную необязательной. - Этот аргумент указывает, какие типы значений принимаются для переменной. - Это указывает документацию входной переменной. - Блок для определения правил проверки, обычно в дополнение к ограничениям типа. - Ограничивает вывод пользовательского интерфейса Terraform, когда переменная используется в конфигурации. - Укажите, может ли переменная быть нулевой в модуле.

Объявление переменной также может включать аргумент по умолчанию. Если переменная присутствует, она считается необязательной, и будет использоваться значение по умолчанию, если при вызове модуля или запуске Terraform значение не задано. Аргумент по умолчанию требует буквального значения и не может ссылаться на другие объекты в конфигурации.

Аргумент типа в блоке переменных позволяет вам ограничить тип значения, которое будет принято в качестве значения для переменной. Если ограничение типа не установлено, принимается значение любого типа.

Несмотря на то, что ограничения типа необязательны, мы рекомендуем указать их; они могут служить полезным напоминанием для пользователей модуля и позволяют Terraform возвращать полезное сообщение об ошибке, если используется неправильный тип.

Конструкторы типов позволяют указывать сложные типы, такие как коллекции:

Ключевое слово any может использоваться для указания того, что допустим любой тип. Дополнительные сведения о значении и поведении этих различных типов, а также подробные сведения об автоматическом преобразовании сложных типов см. в разделе Ограничения типов.

Если указаны и тип, и аргументы по умолчанию, заданное значение по умолчанию должно быть преобразовано в указанный тип.

Поскольку входные переменные модуля являются частью его пользовательского интерфейса, вы можете кратко описать назначение каждой переменной, используя необязательный аргумент описания:

Описание должно кратко объяснять назначение переменной и ожидаемое значение. Эта строка описания может быть включена в документацию по модулю, поэтому она должна быть написана с точки зрения пользователя модуля, а не его сопровождающего. Для комментариев для сопровождающих модулей используйте комментарии.

Эта функция появилась в Terraform CLI v0.13.0.

В дополнение к ограничениям типа, как описано выше, автор модуля может указать произвольные пользовательские правила проверки для конкретной переменной, используя блок проверки, вложенный в соответствующий блок переменных:

Аргумент условия — это выражение, которое должно использовать значение переменной, чтобы возвращать значение true, если значение допустимо, или false, если оно неверно. Выражение может ссылаться только на переменную, к которой применяется условие, и не должно приводить к ошибкам.

Если ошибка выражения является основанием для решения о проверке, используйте функцию can для обнаружения таких ошибок. Например:

Если условие оценивается как false , Terraform выдаст сообщение об ошибке, включающее предложения, указанные в error_message .Строка сообщения об ошибке должна состоять как минимум из одного полного предложения, объясняющего неисправное ограничение, с использованием структуры предложения, аналогичной приведенным выше примерам.

Можно объявить несколько блоков проверки, и в этом случае сообщения об ошибках будут возвращены для всех невыполненных условий.

Эта функция появилась в Terraform v0.14.0.

Настройка переменной как конфиденциальной не позволяет Terraform отображать ее значение в плане или применять выходные данные, когда вы используете эту переменную в другом месте своей конфигурации.

Terraform по-прежнему будет записывать конфиденциальные значения в состояние, поэтому любой, кто может получить доступ к данным состояния, будет иметь доступ к конфиденциальным значениям в виде открытого текста. Дополнительную информацию см. в разделе Конфиденциальные данные в состоянии.

Объявите переменную конфиденциальной, задав для чувствительного аргумента значение true :

Любые выражения, результат которых зависит от конфиденциальной переменной, сами будут рассматриваться как конфиденциальные, поэтому в приведенном выше примере два аргумента ресурса "some_resource" "a" также будут скрыты в выходных данных плана:

В некоторых случаях, когда вы используете конфиденциальную переменную внутри вложенного блока, Terraform может рассматривать весь блок как отредактированный. Это происходит для типов ресурсов, где все блоки определенного типа должны быть уникальными, поэтому раскрытие содержимого одного блока может подразумевать содержание родственного блока.

Поставщик также может объявить атрибут конфиденциальным, что приведет к тому, что Terraform скроет его из обычного вывода независимо от того, как вы присвоите ему значение. Дополнительные сведения см. в разделе Атрибуты конфиденциальных ресурсов.

Если вы используете конфиденциальное значение как часть выходного значения, Terraform потребует, чтобы вы также пометили само выходное значение как конфиденциальное, чтобы подтвердить, что вы намеревались его экспортировать.

Конфиденциальная переменная — это понятие, ориентированное на конфигурацию, и значения отправляются поставщикам без какой-либо запутанности. Ошибка поставщика может раскрыть значение, если это значение включено в сообщение об ошибке. Например, поставщик может вернуть следующую ошибку, даже если "foo" является конфиденциальным значением: "Недопустимое значение "foo" для поля"

Если атрибут ресурса используется как идентификатор ресурса, определенный провайдером, или его часть, при подаче заявки будет раскрыто значение. В приведенном ниже примере атрибуту префикса была присвоена конфиденциальная переменная, но затем это значение («jae») позже раскрывается как часть идентификатора ресурса:

Эта функция доступна в Terraform v1.1.0 и более поздних версиях.

Аргумент, допускающий значение NULL, в блоке переменных определяет, может ли вызывающий модуль присваивать переменной значение null.

Значение по умолчанию для nullable — true . Когда nullable имеет значение true , null является допустимым значением для переменной, и конфигурация модуля всегда должна учитывать возможность того, что значение переменной равно null . Передача нулевого значения в качестве входного аргумента модуля переопределит любое значение по умолчанию.

Установка для значения nullable значения false гарантирует, что значение переменной никогда не будет нулевым в модуле. Если значение nullable равно false и переменная имеет значение по умолчанию, Terraform использует значение по умолчанию, когда входной аргумент модуля равен null .

Аргумент, допускающий значение NULL, определяет только то, где прямое значение переменной может быть null . Для переменных коллекций или структурных типов, таких как списки или объекты, вызывающая сторона может по-прежнему использовать null во вложенных элементах или атрибутах, если сама коллекция или структура не являются null.

В модуле, в котором объявлена переменная, к ее значению можно получить доступ из выражений как var. , где соответствует метке, указанной в блоке объявления:

Примечание. Входные переменные создаются блоком переменных, но вы ссылаетесь на них как на атрибуты объекта с именем var .

Значение, присвоенное переменной, доступно только в выражениях в том модуле, где оно было объявлено.

Когда переменные объявлены в корневом модуле вашей конфигурации, их можно задать несколькими способами:

Отдельно, с параметром командной строки -var.
В файлах определений переменных ( .tfvars ), указанных в командной строке или загружаемых автоматически.
Как переменные среды.

В следующих разделах эти параметры описаны более подробно. Этот раздел не относится к дочерним модулям, где значения для входных переменных вместо этого назначаются в конфигурации их родительского модуля, как описано в разделе Модули.

Чтобы указать отдельные переменные в командной строке, используйте параметр -var при запуске команд terraform plan и terraform apply:

В приведенных выше примерах показан соответствующий синтаксис для оболочек в стиле Unix, таких как Linux или macOS. Дополнительные сведения о заключении в кавычки оболочки, включая дополнительные примеры для командной строки Windows, см. в разделе «Ввод переменных в командной строке».

Вы можете использовать параметр -var несколько раз в одной команде, чтобы установить несколько разных переменных.

Чтобы задать множество переменных, удобнее указать их значения в файле определений переменных (с именем файла, оканчивающимся на .tfvars или .tfvars.json ), а затем указать этот файл в командная строка с -var-file :

Примечание. Именно так Terraform Cloud передает переменные рабочей области в Terraform.

Файл определений переменных использует тот же базовый синтаксис, что и языковые файлы Terraform, но состоит только из назначений имен переменных:

Terraform также автоматически загружает ряд файлов определений переменных, если они присутствуют:

Файлы с именами точно terraform.tfvars или terraform.tfvars.json .
Любые файлы с именами, заканчивающимися на .auto.tfvars или .auto.tfvars.json .

Файлы, имена которых заканчиваются на .json, анализируются как объекты JSON, при этом свойства корневого объекта соответствуют именам переменных:

В качестве запасного варианта для других способов определения переменных Terraform ищет в среде своего собственного процесса переменные среды с именем TF_VAR_, за которыми следует имя объявленной переменной.

Это может быть полезно при запуске Terraform в автоматическом режиме или при последовательном выполнении последовательности команд Terraform с одними и теми же переменными. Например, в командной строке bash в системе Unix:

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

Когда значения переменных указаны в файле определений переменных, вы можете использовать обычный синтаксис Terraform для литеральных выражений, чтобы назначать значения сложного типа, такие как списки и карты.

Некоторые специальные правила применяются к параметру командной строки -var и к переменным среды. Для удобства Terraform по умолчанию интерпретирует -var и значения переменных среды как литеральные строки, которые требуют только кавычек оболочки и не требуют специальных кавычек для Terraform. Например, в оболочке в стиле Unix:

Однако, если переменная корневого модуля использует ограничение типа для требования сложного значения (список, набор, карта, объект или кортеж), Terraform вместо этого попытается проанализировать его значение, используя тот же синтаксис, который используется в файлах определений переменных, что требует особого внимания к правилам экранирования строк в вашей оболочке:

Для удобочитаемости и во избежание необходимости беспокоиться о выходе из оболочки мы рекомендуем всегда задавать значения сложных переменных через файлы определений переменных. Дополнительные сведения о заключении в кавычки и экранировании аргументов -var см. в разделе Входные переменные в командной строке.

Если вы определили значение переменной, но не соответствующее определение переменной <>, вы можете получить сообщение об ошибке или предупреждение в зависимости от того, как вы предоставили это значение.

Если вы укажете значения для необъявленных переменных, определенных как переменные среды, вы не получите сообщение об ошибке или предупреждение. Это связано с тем, что переменные среды могут быть объявлены, но не использоваться во всех конфигурациях, которые могут выполняться.

Если вы укажете значения для необъявленных переменных, определенных в файле, вы получите предупреждение. Это поможет в тех случаях, когда вы указали значение переменной, предназначенное для объявления переменной, но, возможно, в определении значения есть ошибка. Например, следующая конфигурация:

И следующий файл .tfvars:

Заставит Terraform предупредить вас о том, что не объявлена переменная "mosse", что может помочь вам обнаружить эту ошибку.

Если вы используете файлы .tfvars в нескольких конфигурациях и ожидаете появления этого предупреждения, вы можете использовать параметр -compact-warnings для упрощения вывода.

Если вы укажете значения необъявленных переменных в командной строке, Terraform выдаст ошибку. Чтобы избежать этой ошибки, либо объявите блок переменной для значения, либо удалите значение переменной из вызова Terraform.

Вышеуказанные механизмы установки переменных можно использовать вместе в любой комбинации. Если одной и той же переменной присвоено несколько значений, Terraform использует найденное последнее значение, переопределяя все предыдущие значения. Обратите внимание, что одной и той же переменной нельзя присвоить несколько значений в одном источнике.

Terraform загружает переменные в следующем порядке, причем более поздние источники имеют приоритет над более ранними:

Переменные среды
Файл terraform.tfvars, если он есть.
Файл terraform.tfvars.json, если он есть.
Любые файлы *.auto.tfvars или *.auto.tfvars.json, обрабатываемые в лексическом порядке их имен файлов.
Любые параметры -var и -var-file в командной строке в том порядке, в котором они указаны. (Сюда входят переменные, заданные рабочей областью Terraform Cloud.)

Важно: В Terraform 0.12 и более поздних версиях переменные со значениями карты и объекта ведут себя так же, как и другие переменные: последнее найденное значение переопределяет предыдущие значения.Это отличие от предыдущих версий Terraform, которые объединяли значения карт, а не переопределяли их.

В этой статье описывается, как подключить Tableau к локальному файлу JSON и настроить источник данных.

Установите подключение и настройте источник данных

Запустите Tableau и в разделе «Подключение» выберите «Файл JSON» . Затем сделайте следующее:

Выберите файл, к которому хотите подключиться, а затем выберите Открыть .

В диалоговом окне "Выбор уровней схемы" выберите уровни схемы, которые вы хотите просмотреть и проанализировать в Tableau, а затем нажмите кнопку "ОК" . Дополнительные сведения см. в разделе Выбор уровней схемы.

На странице источника данных выполните следующие действия:

(Необязательно) Выберите имя источника данных по умолчанию в верхней части страницы, а затем введите уникальное имя источника данных для использования в Tableau. Например, используйте соглашение об именовании источников данных, которое поможет другим пользователям источника данных определить, к какому источнику данных подключаться.

Выберите вкладку листа, чтобы начать анализ.

Пример источника данных в формате JSON

Вот пример файла JSON в качестве источника данных с использованием Tableau Desktop на компьютере с Windows:

Выберите уровни схемы

Когда вы подключаете Tableau к файлу JSON, Tableau сканирует данные в первых 10 000 строк файла JSON и выводит схему из этого процесса. Tableau сглаживает данные, используя эту предполагаемую схему. Уровни схемы файлов JSON перечислены в диалоговом окне «Выбрать уровни схемы». В Tableau Desktop, если ваш файл JSON содержит более 10 000 строк, вы можете использовать параметр «Сканировать весь документ», чтобы создать схему.

Примечание. Параметр «Сканировать весь документ» отображается только для файлов JSON, содержащих более 10 000 строк. Он недоступен в Интернете.

Уровни схемы, которые вы выбираете в диалоговом окне, определяют, какие измерения и показатели доступны для просмотра и анализа в Tableau. Они также определяют, какие данные публикуются.

Примечание. Когда вы публикуете книгу в Интернете, любые обновления схемы не будут доступны для веб-версии визуализации и могут вызвать ошибки при последующем обновлении визуализации

Если вы выбираете дочерний уровень схемы, родительский уровень также выбирается.

Например, вот фрагмент файла JSON:	Файл JSON создает следующие уровни схемы:

Обнаружение новых полей

Иногда в строках есть дополнительные поля, которые не были просканированы для создания предполагаемой схемы. Если вы заметили, что нужное вам поле отсутствует в Schema , вы можете сделать одно из следующих действий:

Сканировать весь документ JSON. Сканирование может занять много времени.

Выберите уровни схемы из списка, а затем нажмите кнопку ОК . Tableau читает весь ваш документ, и если будут найдены дополнительные поля, они будут перечислены в диалоговом окне «Выбрать уровни схемы».

Всякий раз, когда Tableau обнаруживает, что новые поля доступны, например, во время обновления выписки или когда Tableau создает выписку после того, как вы выбрали уровни схемы, либо значок информации рядом с именем файла, либо уведомление о выборе уровней схемы. диалоговое окно покажет, что были найдены дополнительные поля.

Изменить уровни схемы

Вы можете изменить выбранные уровни схемы, перейдя на страницу источника данных и выбрав Данные > [имя файла JSON] > Выбрать уровень схемы . Или наведите указатель мыши на имя файла на холсте и выберите в раскрывающемся меню > Выбрать уровень схемы .

Объединить файлы JSON

Вы можете объединить данные JSON. Чтобы объединить файл JSON, он должен иметь расширение .json, .txt или .log. Дополнительные сведения об объединении см. в разделе Объединение ваших данных.

При объединении файлов JSON схема выводится из первых 10 000 строк каждого файла в объединении.

Вы можете изменить уровни схемы после объединения файлов. Дополнительные сведения см. в разделе Изменение уровней схемы.

Как организованы папки измерений для иерархических файлов JSON

После выбора вкладки листа выбранные уровни схемы вашего файла JSON отображаются в разделе "Размеры" на панели "Данные". Каждая папка соответствует выбранному вами уровню схемы, и атрибуты, связанные с этим уровнем схемы, перечислены как дочерние элементы папки.

Например, на следующем изображении адрес — это параметр в папке "Компании" на уровне схемы. Категории также являются уровнем схемы, но поскольку они представляют собой список значений, а не иерархию данных, для них не требуется собственная папка, а вместо этого они сгруппированы в родительской папке.Обратите внимание, что уровни схемы в диалоговом окне «Выбрать уровни схемы» не сопоставляются напрямую со структурой папок на панели «Данные». Папки на панели данных сгруппированы по объектам, чтобы вы могли легко переходить к полям и по-прежнему иметь контекст для того, откуда берутся поля.

Для каждого документа создается уникальный индекс, который сохраняется в плоском представлении данных. Также создается индекс для каждого уровня схемы.

Например, на изображении выше, в дополнение к записи индекса документа (созданной), уровни схемы атрибутов и часов имеют сгенерированные индексы.

Почему показатели рассчитываются в иерархических файлах JSON

При сведении иерархического файла JSON данные могут дублироваться. Чтобы меры соответствовали их уровням схемы, Tableau создает расчеты уровня детализации (LOD) для точного представления данных на уровне схемы. Исходные показатели находятся в папке исходных показателей, и вы можете их использовать, но мы рекомендуем вам использовать вычисляемые показатели.

На панели данных вычисляемые показатели помечаются как Число на

Чтобы просмотреть расчет уровня детализации для меры, выполните следующие действия:

Выберите меру.

Выберите стрелку раскрывающегося списка, а затем выберите Изменить .

В следующем примере показан расчет уровня детализации для дохода на документ. Формула выбирает максимальный доход для каждого значения индекса документа.

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

Советы по работе с данными JSON

Эти советы помогут вам работать с данными JSON в Tableau.

Не превышайте ограничение 10 x 10 для вложенных массивов.

Большое количество вложенных массивов создает много строк. Например, вложенные массивы 10x10 дают 10 миллиардов строк. Когда количество строк, которое Tableau может загрузить в память, превышено, отображается ошибка. В этом случае используйте диалоговое окно «Выбрать уровни схемы», чтобы уменьшить количество выбранных уровней схемы.

Загрузка источника данных, содержащего более 100 уровней объектов JSON, может занять много времени.

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

Один объект JSON не может превышать 128 МБ.

Если размер массива верхнего уровня одного объекта превышает 128 МБ, его необходимо преобразовать в файл, в котором объекты JSON определяются по одному в строке.

Опция сводки не поддерживается.

О файлах TTDE и HHYPER

Вы можете заметить файлы .ttde или .hhyper при перемещении по каталогу вашего компьютера. Когда вы создаете источник данных Tableau, который подключается к вашим данным, Tableau создает файл .ttde или .hhyper. Этот файл, также известный как теневой экстракт, используется для повышения скорости загрузки источника данных в Tableau Desktop. Хотя теневой экстракт содержит базовые данные и другую информацию, похожую на стандартный экстракт Tableau, теневой экстракт сохраняется в другом формате и не может использоваться для восстановления ваших данных.

В некоторых ситуациях вам может потребоваться удалить теневую копию с вашего компьютера. Дополнительную информацию см. в разделе Недостаточно места на диске из-за извлечения тени в базе знаний Tableau.

Существует множество других реализаций сериализатора и десериализатора ABAP в JSON в SDN, но по разным причинам все реализации, которые я нашел, не подходили для моих нужд. Начиная с SAP_BASIS 7.40 также доступно простое преобразование для преобразования ABAP в JSON и JSON в ABAP. Это лучший выбор, если вам нужна максимальная производительность и не важен формат сериализации, но для правильной обработки ABAP-типов и красивой печати имен он подходит плохо.

Итак, я написал свой сериализатор ABAP JSON и десериализатор ABAP JSON, которые имеют некоторые ключевые отличия от других реализаций.

Ниже вы можете найти фрагмент написанного мной класса ABAP JSON, который вы можете использовать как локальный класс или как глобальный после переименования.

Исходную и актуальную версию исходного кода можно найти в классе /UI2/CL_JSON, поставляемом с надстройкой UI2 (может применяться к SAP_BASIS 700–76X). Таким образом, вы можете использовать этот парсер ABAP JSON в своем стандартном коде практически в любой системе.

Что он может

ABAP в JSON

Сериализация классов, структур, внутренних таблиц, ссылок на классы и данные, любые элементарные типы. Также поддерживаются и рекурсивно обрабатываются сложные типы, такие как таблица структур/классов, классы со сложными атрибутами и т. д.

От ABAP к JavaScript принят способ сериализации типов данных:

строки, типы символов в строковый формат JavaScript (без ограничения длины),
ABAP_BOOL / BOOLEAN / XFELD / BOOLE_D в логическое значение JavaScript,
Встроенная поддержка TRIBOOL (TRUE/FALSE/UNDEFINED = 'X'/'-'/'') для лучшего управления начальными значениями при сериализации в логические значения JavaScript
int/floats/numeric/packed to JavaScript Integers/float,
дата/время в строковое представление даты/времени JavaScript как "2015-03-24" или "15:30:48",
временная метка для целого числа JavaScript или строки ISO8601
структуры для объектов JavaScript (включаемые типы также поддерживаются; псевдонимы => AS игнорируются)
преобразовать внутреннюю таблицу ABAP в формат JSON, например массивы JavaScript или ассоциативные массивы (объекты)

JSON в ABAP

Десериализуйте объекты JSON, массивы и любые элементарные типы в соответствующие структуры ABAP. Также поддерживаются сложные объекты со встроенными массивами и объекты с любым уровнем вложенности.
Преобразование JSON во внутреннюю таблицу

Общая десериализация объектов JSON в эталонные типы данных:

как простые типы данных (целые, логические или строковые) в общую ссылку на данные (ССЫЛКА НА ДАННЫЕ) -> тип ABAP выбирается на основе типа JSON.
как динамически генерируемый сложный объект (структуры, таблицы, смешанные) для исходных полей REF TO DATA
как типизированные ссылки для предварительно заполненных полей ССЫЛКА НА ДАННЫЕ (вы назначаете ссылку на типизированный пустой объект данных для поля ССЫЛКА НА ДАННЫЕ во время выполнения)

объекты анализируются в соответствующие структуры ABAP, классы (поддерживаются только классы с конструкторами без обязательных параметров) или внутренние хеш-таблицы/отсортированные таблицы
массивы преобразуются во внутренние таблицы (также поддерживаются сложные таблицы).
Булево преобразовано как ABAP_BOOL ("" или "X").
Дата/время/временные метки из JSON преобразованы в зависимости от типа соответствующего элемента ABAP
целые числа/числа с плавающей запятой/строки перемещаются в соответствующие поля с использованием семантики перемещения ABAP (строки не экранируются). Ограничения на размер десериализованных строк нет, единственное ограничение — это ограничения на получение типа данных. Экранированные символы Unicode (\u001F) в строках декодируются.
элементарные типы данных преобразуются, если они не совпадают: целое число JavaScript может войти в строку ABAP или строка JavaScript в целое число ABAP и т. д.
Преобразование учитывает рекомендации по именованию свойств для JSON и ABAP, поэтому имена camelCase будут скопированы в соответствующее поле CAMEL_CASE, если поле CAMELCASE не найдено в структуре ABAP. Не забудьте использовать тот же PRETTY_MODE для десериализации, что и для сериализации.
Значения полей по умолчанию, указанные в эталонной переменной ABAP, сохраняются и не перезаписываются, если не найдены в объекте JSON.
Преобразование структур JSON в экземпляры класса ABAP НЕ поддерживается.

Синтаксический анализатор для сериализации/десериализации использует однопроходный синтаксический анализ и оптимизирован для обеспечения максимально возможной производительности в ABAP независимо от версии. Но для критичных ко времени приложений, имеющих версию ядра 7.20 и выше, рекомендуется использовать встроенные преобразования JSON в ABAP (CALL TRANSFORMATION). Если преобразование по какой-либо причине не работает, пожалуйста, помогите следующими заметками: 1650141 и 1648418.

Пример использования

Описание API

В общих случаях наибольший интерес представляют два статических метода: SERIALIZE и DESERIALIZE. Остальные общедоступные методы делаются общедоступными только для целей повторного использования, если вы хотите создать/расширить свой собственный код сериализации/десериализации.

SERIALIZE : Сериализация объекта ABAP в JSON

> ДАННЫЕ (любые) — любой объект/структура/таблица/элемент ABAP для сериализации
> COMPRESS (bool, по умолчанию = false) — указывает сериализатору пропускать пустые элементы/объекты во время сериализации. Итак, все, для чего НАЧАЛЬНО = ИСТИНА.
> NAME (строка, необязательно) — необязательное имя сериализованного объекта. Будет '"name" : ' вместо ' ', если указано.
> PRETTY_NAME (перечисление, необязательный) — режим, контролирующий преобразование имен полей ABAP в имена атрибутов JSON. См. описание ниже.
> TYPE_DESCR (ссылка на CL_ABAP_TYPEDESCR, необязательно) — если вы уже знаете тип объекта — передайте его для повышения производительности.
> ASSOC_ARRAYS (bool, по умолчанию = false) — управляет сериализацией хэшей или отсортированных таблиц с уникальными ключами. Подробнее см. ниже.
> ASSOC_ARRAYS_OPT (bool, по умолчанию = false) — если установлено, сериализатор оптимизирует отображение связанных массивов имя-значение (хэш-карты) в JSON
> TS_AS_ISO8601 (bool, по умолчанию = false) — указывает сериализатору выводить метки времени в формате ISO8601.
> NUMC_AS_STRING (bool, по умолчанию = false) — управляет способом сериализации полей NUMC. Если установлено значение ABAP_TRUE, поля NUMC сериализуются не как целые числа, а как строки со всеми ведущими нулями. Десериализация работает совместимо с обоими способами сериализованных данных NUMC.
> NAME_MAPPINGS (таблица) — таблица сопоставления имен ABAP JSON
> CONVERSION_EXITS (bool, по умолчанию = false) — использовать выходы преобразования DDIC при сериализации значений (потеря производительности!)
> FORMAT_OUTPUT (bool, по умолчанию = false) — отступы, добавление пробелов для форматирования и разделение на строки, сериализованные JSON
> HEX_AS_BASE64 (bool, по умолчанию = true) — сериализовать шестнадцатеричные значения как base64
JSON (строка) — введите строку объекта JSON для десериализации.
> JSONX (xstring) — ввод объекта JSON в виде необработанной строки для десериализации
> PRETTY_NAME (перечисление, необязательно) — режим, контролирующий, как имена полей JSON сопоставляются с именами компонентов ABAP. См. описание ниже.
> ASSOC_ARRAYS (bool, по умолчанию = false) — управляет десериализацией объектов JSON в хеш-таблицы или отсортированные таблицы с уникальными ключами. Подробнее см. ниже.
> ASSOC_ARRAYS_OPT (bool, по умолчанию = false) — если установлено, десериализатор будет учитывать оптимизированный рендеринг ассоциированных массивов (свойств) в JSON.
> TS_AS_ISO8601 (bool, по умолчанию = false) — указывает десериализатору читать метки времени из строк в поля меток времени, используя формат ISO 8601.
> NAME_MAPPINGS (таблица) — таблица сопоставления имен ABAP JSON
> CONVERSION_EXITS (bool, по умолчанию = false) — использовать выходы преобразования DDIC при десериализации значений (потеря производительности!)
> HEX_AS_BASE64 (bool, по умолчанию = true) — десериализовать шестнадцатеричные значения как base64
<> ДАННЫЕ (любые) — объект/структура/таблица/элемент ABAP для заполнения из строки JSON. Если структура ABAP содержит больше полей, чем в объекте JSON, содержимое несовпадающих полей сохраняется.

GENERATE : создает объект ABAP из JSON

> JSON (строка) — введите строку объекта JSON для десериализации
> PRETTY_NAME (перечисление, необязательно) — режим, контролирующий, как имена полей JSON сопоставляются с именами компонентов ABAP. См. описание ниже.
> NAME_MAPPINGS (таблица) — таблица сопоставления имен ABAP JSON
красивое_имя.

NONE и LOW_CASE работают одинаково для DESERIALIZE.

ASSOC_ARRAYS :

Этот параметр управляет способом сериализации/десериализации хешированных или отсортированных таблиц с уникальными ключами. Обычно внутренние таблицы ABAP сериализуются в массивы JSON, но в некоторых случаях вам может понадобиться сериализовать их как ассоциативные массивы (объекты JSON), где каждая строка таблицы должна отражаться как отдельное свойство объекта JSON. Этого можно добиться, установив для параметра ASSOC_ARRAYS значение TRUE. Если установлено, сериализатор проверяет отсортированные/хешированные таблицы с ключами UNIQUE и сериализует их как объект. Имя свойства JSON, отражающее строку, построенную из значений полей, используемых в ключе, разделенных константой MC_KEY_SEPARATOR = '-'. Если в таблице есть только одно поле, помеченное как ключевое, значение этого единственного поля становится именем свойства и УДАЛЯЕТСЯ из связанного объекта (для устранения избыточности). Если TABLE_LINE используется в качестве уникального ключа, все значения всех полей формируют имена свойств ключа (разделенные MC_KEY_SEPARATOR). При десериализации логика работает наоборот: если для ASSOC_ARRAYS установлено значение TRUE, а объект JSON соответствует внутреннему хэшу или отсортированной таблице с уникальным ключом, объект преобразуется в таблицу, где отражается каждое свойство объекта в отдельной строке таблицы. Если в ABAP-таблице есть только одно ключевое поле, имя свойства преобразуется в значение этого ключевого поля.

ASSOC_ARRAYS_OPT:

По умолчанию при выгрузке хэш/отсортированных таблиц с уникальным ключом в JSON сериализатор запишет ключевое поле как имя свойства, а остальные поля запишут объектное значение свойств:

Оператор JSON позволяет извлекать значения из журналов JSON с помощью большинства выражений JSONPath. Ниже приведены поддерживаемые элементы синтаксиса JSONPath.

Поскольку JSON поддерживает как вложенные ключи, так и массивы, содержащие упорядоченные последовательности значений, оператор Sumo Logic JSON позволяет извлекать:

Отдельные поля верхнего уровня.
Несколько полей.
Вложенные ключи.
Ключи в массивах.

Синтаксис

| json" "[," ", . ] [так как . ]
| json" "[," ", . ] [как ] [nodrop]
| json [поле=] ""[," ", . ] [так как . ]
| json авто [поле =] [максимальная глубина]
| json auto [field= ] [extractarrays]
| json автоматические ключи ""[," ", . ] [повторно] [как . ]

Параметры

nodrop — позволяет отображать сообщения, содержащие недопустимые значения JSON. Дополнительные сведения см. в разделе анализ nodrop и использование параметра nodrop.
field= — позволяет указать поле для анализа, отличное от сообщения по умолчанию. Подробнее см. в поле разбора.
auto — автоматически обнаруживает объекты JSON в журналах и извлекает пары "ключ-значение". Дополнительные сведения см. в разделе об автоматической настройке JSON.

В следующих примерах используется этот образец сообщения журнала:

Поддерживаемые элементы синтаксиса JSONPath

Оператор JSON поддерживает следующие выражения JSONPath:

< тд>. или [] < tr>

JSONPath	Описание
$	Корневой объект или элемент.
@	Текущий объект или элемент.
Дочерний оператор.
..	Рекурсивный спуск. JSONPath заимствует этот синтаксис из E4X.
*	Подстановочный знак. Все объекты или элементы независимо от их имен.
[]	Оператор нижнего индекса. XPath использует его для перебора коллекций элементов и предикатов. В JavaScript и JSON это собственный оператор массива.
[,]	Операция объединения в XPath приводит к объединению наборов узлов. JSONPath допускает альтернативные имена или индексы массива в виде набора.
[start:end]	Оператор среза массива.
()	Выражение скрипта с использованием базового скриптового движка.

Специальные символы

Если в именах ваших свойств есть пробелы или другие специальные символы, такие как @, вы должны использовать скобки, ['foo bar'] .

Например, если вас зовут @something, вам нужно использовать ['@something'] .

Другой пример: если вас зовут fie@ld, вам нужно использовать [‘fie@ld’] .

Чувствительность к регистру

Ссылки на определенные ключи чувствительны к регистру в стандартной операции JSON. Например, если имя ключа — sourceIpAddress, и вы запускаете | json "sourceipaddress" операция не вернет результатов, так как она не соответствует заглавным буквам. Правильный способ - запустить | json "исходный IP-адрес".

При использовании автоматического режима ключи не чувствительны к регистру.

Извлечение одного поля верхнего уровня

Оператор JSON позволяет извлечь одно поле верхнего уровня. Например, чтобы извлечь accountId :

_index=аудит_событий
| json "accountId"
| поля accountId

выдает такие результаты, как:

Извлечение нескольких полей

Вы также можете извлечь несколько полей за одну операцию. Например, чтобы извлечь accountId и eventName:

_index=аудит_событий
| json "accountId", "eventName"
| поля accountId, eventName

выдает следующие результаты:

Кроме того, полям можно присваивать имена, которые отличаются от их исходных ключевых имен. Чтобы использовать aID вместо accountId и eName вместо eventName , вы должны использовать параметр as следующим образом:

_index=sumologic_audit_events
| json "accountId", "eventName" как aID , eName
| поля aID, eName

что дает следующие результаты:

Извлечение вложенного ключа

Пример сообщения журнала содержит вложенные ключи, которые можно извлечь, указав путь с помощью записи через точку:

Например, чтобы извлечь тип вложенного ключа из meta , используйте следующий запрос:

* | json field=jsonobject "meta.type"

Поиск значений в массиве JSON

В некоторых случаях значения полей на самом деле являются массивами, например baselineIntervals в примере сообщения журнала:

Вы можете указать оператору JSON извлечь @baselineIntervals , например:

* | json field=jsonobject "baselineIntervals"

Он возвращает список значений в массиве: ["2014-03-10T23. ", ""2014-03-11T05. "] .

Чтобы сослаться на одну конкретную запись в массиве, укажите индекс массива:

* | json field=jsonobject "baselineIntervals[1]"

Вложенный массив. Вы можете анализировать вложенный массив, используя запись через точку.

_sourceCategory=O365*
| json "Actor[0].Type" as Actortype0
| json "Actor[1].Type" как Actortype1

Результат запроса будет выглядеть следующим образом:

Использование опции nodrop

По умолчанию оператор JSON оптимизирует результаты, удаляя сообщения, в которых не используется указанный ключ или ключи, или сообщения, в которых используются недопустимые ключи JSON. Используйте параметр nodrop, чтобы предотвратить эту оптимизацию, и установите для извлеченных значений полей значение null (пусто):

* | json field=jsonobject "baselineIntervals[0]" nodrop

Использование подстановочного знака (*)

Для доступа к элементам массива в формате JSON можно использовать подстановочный знак (*).
Например, вы можете получить доступ к типу субъекта из сообщения JSON O365 с помощью подстановочного знака.

< бр />

_sourceCategory=O365*
| json "Актер[*].Тип" в качестве Типа Актера

Результат запроса будет выглядеть следующим образом:

< бр />

Далее, если требуется, вы можете использовать элементы массива для выполнения дополнительных операций. Например, вы можете найти максимальное значение Type для CreationTime и Id, используя этот запрос:

_sourceCategory=O365*
| json field=_raw "CreationTime", "Id"
| json "Actor[*].Type" as Actortype
| извлечь field=ActorType"(? \d+)" multi
| max(type) по CreationTime, Id

Результат будет выглядеть следующим образом:

< /p>

Автоматическая настройка JSON

Используйте параметр json auto в запросе, чтобы автоматически обнаруживать объекты JSON в журналах и извлекать пары "ключ-значение" без необходимости указывать поля в операторе синтаксического анализа. После выполнения запроса вы можете использовать обозреватель полей, чтобы выбрать поля, которые вы хотите отобразить. Вы также можете работать с извлеченными полями позже в запросе.

Если вы не укажете никаких дополнительных полей, объекты JSON будут обнаружены автоматически, и будут извлечены все пары "ключ-значение". Обратите внимание, что сообщения, не содержащие JSON, не удаляются.

Часть JSON не обязательно должна охватывать все сообщение журнала. До и после части JSON может быть некоторый текст. Автоматический оператор json автоматически определяет, где находится объект JSON, и анализирует его.

Например, в этом сообщении журнала:

Оператор автоматически обнаруживает объект JSON:

Пример

Дополнительные параметры

* | json auto field=имя поля

Работает с указанным полем. По умолчанию json auto попытается извлечь поля JSON из всего необработанного сообщения журнала. Чтобы он работал с другим полем, используйте параметр поля.

* | автоматическое поле json=

* | автоматические ключи json

Ссылается на определенные ключи в json. Ключи не чувствительны к регистру с опцией auto. Ключи могут быть переименованы (псевдонимы) с помощью as. Пример:

* | json автоматические ключи " ", " " as,

Используйте параметр refonly, чтобы извлечь только указанные ключи. Если вы не используете этот параметр, json auto также извлечет все остальные поля JSON в сообщении.

* | json auto keys " ", " " refonly

* | json авто максимальная глубина

JSON – это иерархическая структура данных, которая может иметь множество уровней объектов и массивов. Например, следующее имеет глубину четыре уровня:

На глубине 1 находится объект, содержащий foo. На глубине 2 находится объект, содержащий бар и баз. На глубине 3 находится массив, содержащий два объекта. На глубине 4 находятся два объекта, содержащие ключи k1 и k2.

Используйте maxdepth, чтобы указать уровень, на котором нужно свести JSON.

В следующих примерах показано, как изменяется предыдущий пример при применении значений maxdepth:

json авто максимальная глубина 1:

json авто максимальная глубина 2:

поле: foo.baz значение: qux

* | json авто максимальная глубина 2

* | json автоматическое извлечение массивов

Извлекает элементы из плоских массивов, при этом каждый элемент массива представляет собой отдельную пару "ключ-значение". Неплоские массивы (массивы, содержащие другие объекты или массивы JSON) извлекаются по умолчанию.

Рассмотрите этот пример:

Без параметра extractarrays json автоматически возвращает

поле: значение foo: [1,2,3]

С параметром extractarrays json автоматически создает следующие пары поле-значение:

поле: foo[0] значение: 1 поле: foo[1] значение: 2 поле: foo[2] значение: 3

Важные примечания

Извлекается до 100 полей; необходимо указать дополнительные поля.
Ключи не чувствительны к регистру с автоматическим параметром.
Пробелы в именах полей автоматически преобразуются в символы подчеркивания.
json auto работает путем поиска больших двоичных объектов json, начинающихся в конце сообщения. Большинство журналов начинаются с преамбулы, такой как метка времени, затем большой двоичный объект json. В тех случаях, когда содержимое появляется в конце сообщения после BLOB-объекта json, извлечение может завершиться ошибкой.

* | json автоматические ключи «имя пользователя» | считать по имени пользователя

Пользователь может просто написать:

* | json авто | считать по имени пользователя

Использование этого имени поля позже в запросе не удастся, так как точки и скобки обычно не допускаются в имени поля. Чтобы использовать эти поля, вы можете экранировать поле, используя знак процента (%).

Например, это не сработает:

* | json авто | количество пользователей[2].address.street

* | json авто | количество пользователей, %[2].address.street

Генератор разбора пользовательского интерфейса

Sumo Logic может сгенерировать для вас выражение синтаксического анализа для определенного ключа JSON. Этот параметр доступен при просмотре журналов JSON на вкладке «Сообщения» в разделе «Поиск».

Щелкните правой кнопкой мыши ключ, который хотите проанализировать, и появится меню.
Нажмите "Разобрать выбранный ключ"
В текстовом поле запроса, куда последний раз был помещен курсор, добавляется новая операция синтаксического анализа JSON, которая будет анализировать выбранный ключ. Например, | json field=_raw "_BOOT_ID" .

Предупреждение о поиске

Невозможно проанализировать ввод как json

По умолчанию оператор JSON оптимизирует результаты, удаляя сообщения, в которых нет полей или ключей, указанных в вашем запросе, или если JSON недействителен. Когда сообщение удаляется, пользовательский интерфейс выводит предупреждающее сообщение:

Это просто предупреждающее сообщение о том, что по крайней мере один журнал, возвращенный в рамках запроса, не имеет указанного ключа.

Используйте параметр nodrop, чтобы предотвратить эту оптимизацию. Например, следующий запрос ищет ключевое событие и указывает не удалять сообщения, не содержащие этого ключа:

_sourceCategory="nginx"
| json "событие" nodrop

Вы можете удалить предупреждение о том, что ключ не найден, указав нужный(е) ключ(и) в области запроса, например так:

_sourceCategory="nginx" " событие "
| json "событие"

Поскольку событие указано в области запроса, оператор json получит только журналы, в которых есть событие.

Читайте также: