Объект метаданных 1с: Объекты метаданных 1С

Содержание

Тема 3.3 Объекты метаданных | Пакеты прикладных программ

Учебные программы » Пакеты прикладных программ » Конспект лекций » Тема 3.3 Объекты метаданных

Метаданные 1С

Любое прикладное решение в 1C:Предприятии имеет в своей основе набор проблемно-ориентированных объектов, поддерживаемых на уровне технологической платформы. Задача разработчика заключается в том, чтобы собрать из этих объектов, как из конструктора, необходимую структуру прикладного решения и затем описать специфические алгоритмы функционирования и взаимодействия этих объектов, отличающиеся от их типового поведения.

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

Рис.14. Объекты метаданных ППП 1С:Предприятие

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

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

Состав объектов, которые может использовать разработчик, определен и фиксирован на уровне платформы 1C:Предприятие.

Основные объекты метаданных

Количество и возможности объектов метаданных отличаются в различных версиях 1С (в первую очередь это касается версии 8 по сравнению с предыдущими версиями, той же 1С 7.7). Краткое описание некоторых объектов метаданных 1C:Предприятие приведено ниже.

Справочники

Служит для описания таких сущностей как товары, контрагенты, валюты, склады и пр. Все эти сущности имеют общие свойства: внутренняя идентификация объекта в системе, необходимость поддержки иерархии и группировки элементов, необходимость поддержки вложенных таблиц и т.д.

Документы, журналы документов, нумераторы, последовательности

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

Регистры накопления

«Отвечают» за учет движений ресурсов (финансов, товаров, материалов и т.д.). Позволяет автоматизировать такие направления как складской учет, взаиморасчеты, планирование. В регистрах накопления хранится информация о поступлении и расходе тех или иных ресурсов, а функциональность этих объектов предоставляет возможность получения остатков на определенный момент времени, расчета итогов, кэширования итогов и т. д.

Регистры сведений

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

Планы счетов и регистры бухгалтерии

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

Планы видов расчета и регистры расчета

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

Задачи и бизнес-процессы

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

Обработки, отчеты

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

Планы видов характеристик

Предназначены для хранения информации о характеристиках различных объектов. Позволяет пользователю создавать всевозможные характеристики, описывать тип этих характеристик и задавать их значения. Может использоваться, например, для предоставления пользователю возможности описывать товары произвольным количеством произвольных характеристик (цвет, размер, запах и т.д.). Позволяет создавать и хранить название характеристики и тип данных, который должны принимать значения этой характеристики.

Планы обмена

Предназначены для описания структуры распределенной информационной системы и задания перечня данных, которыми будет производиться обмен в пределах этой распределенной системы. Позволяет создавать территориально распределенные информационные системы как на основе информационных баз 1C:Предприятия, так и с использованием произвольных информационных систем, не основанных на 1C:Предприятии.

Константы

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

Перечисления

Предназначены для описания перечня значений, которые может принимать какая-либо переменная. Например, перечисление может хранить значения, описывающие статус покупателя: «оптовый» и «розничный».

Критерии отбора

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

Роли

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

Подписки на события

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

Регламентные задания

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

Интерфейсы

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

XDTO пакеты

Механизм XDTO предназначен прежде всего для описания типов параметров и возвращаемых значений Web-сервисов. Также этот механизм может использоваться для обмена данными между различными конфигурациями 1C:Предприятия 8 или другими информационными системами.

Web-сервисы и WS-ссылки

Механизм Web-сервисов позволяет создавать Web-сервисы в конфигурации 1C:Предприятия 8, а также взаимодействовать в конфигурации 1C:Предприятия 8 с веб-сервисами, опубликованными сторонними поставщиками.

Стили

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

Языки

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

CC-BY-CA Анатольев А.Г., 23.04.2014

Разделы дисциплины

Методические материалы

Конспект лекций

Лабораторный практикум

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

Материалы раздела

Полный конспект лекций (.pdf, 2.3МБ)

Тема 1.1 Введение в предмет. Понятие ППП

Тема 1.2 Структура и основные компоненты ППП

Тема 1.3 Эволюция ППП

1.3.1 Примеры современных прикладных пакетов

Тема 2.1 Структура и состав MS Office. Основные приложения

Тема 2.2 Введение в офисное программирование

Тема 2.3 Макросы. Использование макрорекордера

Тема 2.4 Среда разработки VBE

Тема 2.5 Синтаксис VBA

2.5.1 VBA. Ветвления

2.5.2 VBA. Организация циклов

2.5.3 VBA. Процедуры и функции

2.5.4 VBA. Модули

2.5.5 Структурные типы данных

Тема 2.6 Объектно-ориентированное программирование в VBA

Тема 2.7 Объектная модель компонентов MS Office. Библиотеки типов

Тема 2.8 Разработка приложений для MS Office

Тема 2. 9 Формы и компоненты управления. Обработка событий

Тема 2.10 Интеграция с внешними приложениями

Тема 3.1 Структура и состав ППП 1С:Предприятие. Режимы работы

Тема 3.2 Основные компоненты ППП 1С:Предприятие. Конфигурации и информационные базы

Тема 3.3 Объекты метаданных

Тема 3.4 Конфигуратор. Назначение и возможности

Тема 3.5 Разработка приложений в 1С

Тема 3.6 Входной язык 1С. Общий синтаксис

Тема 3.7 Библиотечные процедуры и функции

Тема 3.8 Взаимодействие с внешними приложениями

Тема 3.9 Отладка и профилирование

Тема 3.10 Управление пользователями в 1С

Тема 3.11 Сервисное обслуживание информационных баз

4.1 Основные тенденции в развитии ППП

Связанные темы

Тема 2.6 Объектно-ориентированное программирование в VBA

Тема 2.7 Объектная модель компонентов MS Office. Библиотеки типов

Тема 2.8 Разработка приложений для MS Office

Тема 2.9 Формы и компоненты управления. Обработка событий

Типы метаданных в конфигурации 1С Предприятие 8.3

от Qlik Expert Russia

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

Рассмотрим назначение каждого типа метаданных.

  • Общие. В этом разделе дерева конфигурации хранятся объекты, так или иначе относящиеся ко всем объектам конфигурации. Так, если в подразделе Реквизиты задать общий реквизит, то этот реквизит может быть использован в любом из объектов конфигурации (например, при создании общего реквизита «Примечание» мы можем использовать его в любом из документов конфигурации). К созданным в разделе Общие общим модулям можно обратиться из любого модуля разрабатываемой конфигурации (то же касается общих форм и общих макетов — печатных форм), в подразделе Роли мы задаем роли всех пользователей и их права, в подразделе Интерфейсы — интерфейсы всех пользователей.
  • Константы предназначены для хранения постоянной и условно-постоянной информации, которая в процессе работы не изменяется или изменяется редко. Главная особенность констант — возможность их многократного использования. Приведу пример: пусть на предприятии работает сотрудник, ответственный за составление документов и их подписание. Обычно рядом с местом для подписи на таких документах должна указываться также фамилия этого человека. Фамилию можно прописать в печатной форме документа, а можно записать в константу. Если записывать фамилию в печатную форму, то при смене лица, ответственного за выписку документов, придется править все печатные формы (а их может быть много). Гораздо проще Ф.
    И.О. ответственного лица записать в константу, а уже ссылку на нее поместить в печатную форму каждого документа. Если нужно изменить фамилию, она правится непосредственно в константе, и на печатных формах будет меняться автоматически, — ведь там находится не само значение, а только ссылка на него.
  • Справочники — это средство для работы со списками однородных элементов данных. При помощи справочников организуется ввод стандартной информации в документы, ее просмотр и изменение. Обычно справочниками являются списки товаров, организаций, валют, сотрудников и др. Основные поля, по которым уникально характеризуется любая запись в справочнике, — это код и наименование.
  • Документы — основное средство совершения хозяйственных операций в системе «1С:Предприятие». С их помощью осуществляются все движения товарноденежных потоков на предприятии, осуществляется ввод первичных данных в систему, их просмотр и корректировка. Приход товаров на склад, перемещение между складами, отгрузка или продажа через кассовый аппарат, поступление денег на расчетный счет или в кассу, списание неликвидов — вся эта информация вводится в систему посредством документов соответствующего типа: приходных и расходных накладных, перемещений, списаний, банковских выписок, кассовых ордеров и т.
    п. Основные поля, по которым уникально характеризуется любой документ, — это его номер и дата.
  • Журналы документов являются средством для отображения списка документов (по аналогии с реестром). Работая с журналом, пользователь может вводить документы, просматривать, редактировать и удалять. Журналы позволяют сортировать и группировать список документов, просматривать выбранный документ, править его либо удалить. Сами по себе журналы никакой информации не хранят, они лишь отображают списки документов в удобном виде.
  • Перечисления — это специальные типы данных. Они не представляют собой самостоятельные объекты, как справочники или документы, а используются в комплексе с прочими типами данных: числовыми, текстовыми и т. п. Например, в крупном оптовом магазине формируются накладные к отправке заказчикам. Перед погрузкой товаров по каждой накладной товар проверяет и пересчитывает контролер или охранник: проверил и сделал в накладной пометку «Проверено». Какое может быть состояние проверки? Либо проверено, либо нет. Если бы нам для чего-либо потребовалось указывать в накладной, прошла она проверку или нет — мы могли бы добавить в документ реквизит Проверено, принимающий значения либо «Да», либо «Нет». Вот это и есть перечисление — такой тип данных, который может принимать только одно из заранее определенных значений. В данном случае: или «Да», или «Нет».
  • Отчеты предназначены для выборки определенных пользователем данных за указанный период. Сами по себе отчеты не являются хранимыми в базе данных объектами, содержащими информацию, наподобие справочников или документов. Это всего лишь выборки из подобных объектов, создаваемые динамически. Например, вам нужно отобрать остатки в ценах себестоимости по одному из складов за последний месяц. При запуске соответствующего отчета он выбирает из множества записей в базе данных те, которые соответствуют условиям отбора, и выдает на экран в форме, заданной программистом при проектировании отчета в конфигураторе.
  • Обработки — это программный код, предназначенный выполнять заданные программистом действия. Метаданные этого вида схожи с отчетами, однако, в отличие от последних, могут не только делать выборку данных, но и производить их изменение, в том числе групповые действия над большим количеством данных. Например, чтобы внести в справочник товаров розничные цены на 20% выше текущих, можно написать обработку, перебирающую все записи справочника и перемножающие соответствующие им розничные цены на 1,2. Обработки бывают внутренними и внешними. Внутренние являются элементами дерева конфигурации, внешние запускаются из внешних файлов с расширением epf через меню Файл | Открыть. Внешние обработки не являются частью конфигурации, а представляют собой внешние программные модули. Понятия «отчет» и «обработка» очень часто пересекаются — внешние отчеты в EPF-файлах являются ничем иным, как внешними обработками.
  • Планы видов характеристик предназначены для хранения информации о характеристиках различных объектов.
    Например, характеристиками товара могут служить цвет, размер, запах, вкус и т. д. По своей структуре планы видов характеристик схожи со справочниками.
  • Планы счетов — совокупность синтетических счетов, предназначенных для хранения и группировки информации о хозяйственной деятельности предприятия. Счета имеют иерархическую структуру и могут разбиваться на неограниченное количество субсчетов (вложенных счетов). Анализ остатков на таких счетах и движений между счетами позволяет получить информацию о деятельности предприятия в денежном выражении и его текущем финансовом состоянии.
  • Планы видов расчета используются в механизме сложных периодических расчетов и служат для описания видов расчета и их взаимного влияния друг на друга.
  • Регистры сведений — в упрощенном представлении это таблицы, которые позволяют хранить произвольные данные в разрезе нескольких измерений. Информация в регистре сведений хранится в виде записей, каждая из которых содержит значения измерений и соответствующие им значения ресурсов.
    Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию.
  • Регистры накопления — многомерные таблицы, составляющие основу механизма учета движения средств (товаров, денежных средств и т. д.), который позволяет автоматизировать такие направления, как складской учет, взаиморасчеты, планирование. Регистр накопления образует многомерную систему измерений и позволяет «накапливать» числовые данные в разрезе нескольких измерений. Например, в подобных регистрах можно накапливать информацию об остатках товаров в разрезе номенклатуры или склада или информацию о продажах в разрезе номенклатуры или точек продажи. Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию.
  • Регистры бухгалтерии — это многомерные таблицы, использующиеся в бухгалтерском учете и позволяющие вести учет по нескольким планам счетов, а также количественный, суммовой и валютный учет по отдельным разрезам аналитики. По принципу работы схожи с регистрами накопления. Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию.
  • Регистры расчета — многомерные таблицы, которые служат для хранения записей о тех или иных видах расчета, а также для хранения промежуточных данных и самих результатов выполненных расчетов. Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию.
  • Бизнес-процессы — вид метаданных, предназначенный для описания схем бизнес-процессов.
  • Задачи предназначены для учета заданий и описывают способ их распределения по исполнителям с учетом организационной структуры предприятия. Напрямую взаимосвязаны с механизмом безнес-процессов.
  • Внешние источники данных позволяют работать с внешними базами данных, не основанными на «1С:Предприятии», — такими как MS SQL Server или Oracle Database.

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

0 0 голос

Рейтинг статьи

1С:Предприятие 8. Метаданные (объекты конфигурации)

Любое прикладное решение в 1С:Предприятии имеет в своей основе набор проблемно-ориентированных объектов, поддерживаемых на уровне технологической платформы. По большому счету задача разработчика заключается в том, чтобы собрать из этих объектов, как из конструктора, необходимую структуру прикладного решения и затем описать специфические алгоритмы функционирования и взаимодействия этих объектов, отличающиеся от их типового поведения.

Состав объектов, поддерживаемых технологической платформой, является результатом анализа предметных областей использования 1С:Предприятия, и выделения и классификации используемых в этих областях бизнес-сущностей. В результате этого анализа разработчик может оперировать такими объектами как справочники, документы, регистры сведений, планы счетов и пр.

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

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

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

Состав объектов, которые может использовать разработчик, фиксирован и определен на уровне технологической платформы «1С:Предприятие 8.0». Разработчик не может создавать собственные виды объектов, он может оперировать только тем набором объектов, который имеется. Подобный подход к разработке прикладных решений позволяет, во-первых, стандартизировать процесс разработки, а во-вторых — обеспечить простую и быструю модификацию прикладных решений другими разработчиками или пользователями.

Состав основных объектов конфигурации, используемых в 1С:Предприятии 8.0, показан на следующем рисунке:

Справочник

Служит для описания таких сущностей как товары, контрагенты, валюты, склады и пр. Все эти сущности имеют общие свойства: внутренняя идентификация объекта в системе, необходимость поддержки иерархии и группировки элементов, необходимость поддержки вложенных таблиц и т. д.

Документ, журнал документов, нумератор, последовательность

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

Регистр накопления

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

Регистр сведений

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

План счетов и регистр бухгалтерии

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

План видов расчета и регистр расчета

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

Задача и бизнес-процесс

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

Обработка, отчет

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

План видов характеристик

Предназначен для хранения информации о характеристиках различных объектов. Позволяет пользователю создавать всевозможные характеристики, описывать тип этих характеристик и задавать их значения. Может использоваться, например, для предоставления пользователю возможности описывать товары произвольным количеством произвольных характеристик (цвет, размер, запах и т.д.). Позволяет создавать и хранить название характеристики и тип данных, который должны принимать значения этой характеристики.

План обмена

Предназначен для описания структуры распределенной информационной системы и задания перечня данных, которыми будет производиться обмен в пределах этой распределенной системы. Позволяет создавать территориально распределенные информационные системы как на основе информационных баз 1С:Предприятия, так и с использованием произвольных информационных систем, не основанных на 1С:Предприятии.

Константа

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

Перечисление

Предназначено для описания перечня значений, которые может принимать какая-либо переменная. Например, перечисление может хранить значения, описывающие статус покупателя: «оптовый» и «розничный».

Критерий отбора

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

Язык

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

Стиль

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

Интерфейс

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

Роль

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

Понимание модели метаданных

В основе Tableau лежат данные — ваши данные. Ваши данные могут поступать в различных форматах и ​​структурах, классифицироваться с разным уровнем детализации и могут иметь отношения с другими данными. Это тип метаданных, которые вы можете ожидать от API метаданных с использованием GraphQL.

Чтобы успешно создавать эффективные запросы GraphQL, вам необходимо понимать, как Tableau интерпретирует контент и ресурсы и взаимодействует с ними. Понимание этого поможет определить наиболее эффективный способ доступа к метаданным на необходимом уровне детализации.

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

В этом разделе

  • Содержимое и ресурсы таблицы
    • Объекты и их роли
    • Типы объектов и унаследованные атрибуты
    • Другие объекты, связанные с содержимым и активами Tableau
  • Модель метаданных Tableau
    • Пример модели метаданных
    • Пример сценария 1: анализ воздействия
    • Пример сценария 2: Анализ происхождения
    • Дополнительные примечания о модели метаданных

Контент и активы Tableau

API метаданных отображает контент и активы, составляющие ваш сайт Tableau Cloud или сервер Tableau, роли контента и активов, а также то, как контент и активы связаны друг с другом.

Общее содержание таблицы

Контент Tableau уникален для платформы Tableau. Содержимое включает следующее:

  • Источники данных — как опубликованные, так и встроенные
  • Рабочие тетради
  • листов
  • Панели мониторинга, включая истории
  • Поля: вычисляемые, столбец — поскольку они относятся к источнику данных, группе, бину, набору, иерархии, комбинированному и комбинированному набору
  • Фильтры: источник данных
  • Параметры
  • Потоки
  • Метрики
  • Виртуальные соединения
  • Таблицы виртуальных соединений

Содержимое Tableau Cloud и Tableau Server

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

  • Сайты
  • Проекты
  • пользователей
  • Сертификаты и сертификаторы
  • Предупреждения и сообщения о качестве данных

Примечание. Некоторым содержимым, перечисленным выше, также можно управлять с помощью Tableau REST API.

Внешние активы, связанные с содержимым Tableau

API метаданных обрабатывает информацию о любых данных, поступающих из-за пределов среды Tableau, как внешние активы. К внешним активам относятся следующие:

  • Базы данных — включая локальные файлы, удаленные подключения к серверам и коннекторы веб-данных (WDC)
  • Таблицы — включает запросы (пользовательский SQL)

Примечание. Кубы не поддерживаются.

Объекты и их роли

Схема GraphQL, используемая API метаданных, упорядочивает контент и активы в Tableau Cloud и Tableau Server, группируя их по объектам и ролям. Эти объекты и их роли являются основой для ваших запросов GraphQL.

Родительский объект и роль

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

Родительские объекты

  • Базы данных
  • Столы
  • Опубликованные источники данных
  • Виртуальные соединения
  • Таблицы виртуальных соединений
  • Рабочие тетради
  • Метрики
  • Потоки
  • сайтов
  • Проекты
  • пользователей
Дочерний объект и роль

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

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

Дочерние объекты

  • Столбцы
  • Поля
  • Встроенные источники данных
  • листов
  • Параметры
  • Фильтры источника данных
Отношение родительского/дочернего объекта

Схема GraphQL определяет отношение родительского/дочернего объекта по тому, что могут содержать объекты. Другими словами, объект является родительским объектом, когда он функционирует как контейнер для других (дочерних) объектов. Некоторые примеры таких отношений приведены ниже.

  • База данных
    • Таблица базы данных
      • Столбец
  • Опубликованный источник данных
    • Поле
    • Фильтр источника данных
    • Параметр
    • DataQualityWarning
    • Сертификация качества данных
  • Рабочая тетрадь
    • Вид
    • Встроенный источник данных
      • Поле
    • Параметры

Типы объектов и унаследованные атрибуты

Параллельно с ролью и отношениями родительского/дочернего объекта схема GraphQL организует объекты по типу объекта и атрибутам, которые она может наследовать от объекта.

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

Примеры типов объектов и их унаследованных атрибутов

В таблице ниже приведены примеры объектов, типы объектов (интерфейс), а также их общие и уникальные атрибуты и свойства.

Объект Тип объекта или интерфейс Общие атрибуты и свойства Уникальные атрибуты и свойства
База данных
  • CloudFile
  • Сервер базы данных
  • Файл
  • WebDataConnector
  • id
  • vizportalid
  • luid
  • name
  • hostname
  • port
  • isEmbedded
  • connectionType
  • description
  • contact
  • isControlledPermissionsEnabled
  • isCertified
  • certificationNote
  • certifier
  • tables
  • tablesConnection
  • dataQualityWarning
  • hasActiveWarning
  • служба
CloudFile
  • провайдер
  • fileExtension
  • mimeType
  • поле
  • requestUrl
База данныхСервер
  • extendedConnectionType
  • hostName
  • порт
Файл
  • путь к файлу
вебдатаконнектор
  • коннекторUrl
Стол
  • Таблица базы данных
  • Таблица CustomSQL
  • id
  • название
  • isEmbedded
  • описание
  • isCertified
  • сертификацияПримечание
CustomSQLTable
  • запрос
Таблица базы данных
  • luid
  • vizportalId
  • схема
  • fullName
  • контакт
Источник данных
  • Опубликованный источник данных
  • Встроенный источник данных
  • id
  • name
  • hasUserReference
  • hasExtracts
  • extractLastRefreshTime
  • extractLastUpdateTime
  • extractLastIncrementalUpdateTime
  • extractLastUpdateTime
  • fields
  • fieldsConnection
  • datasourceFilters
  • datasourceFiltersConnection
Опубликованный источник данных
  • luid
  • parameters
  • parametersConnection
  • site
  • project
  • owner
  • isCertified
  • certifier
  • certificationNote
  • certifierDisplayName
  • description
  • uri
  • vizportalURLId
Встроенный источник данных
  • рабочая тетрадь
Предупреждение (предупреждение о качестве данных)
  • CloudFile
  • DatabaseServer
  • File
  • WebDataConnector
  • DatabaseTable
  • PublishedDatasource
  • Flow
  • id
  • hasActiveWarning
  • dataQualityWarning

Другие объекты, связанные с содержимым и активами Tableau

Объекты ярлыков Lineage

API метаданных позволяет вам видеть отношения между содержимым и активами, которые вы оцениваете, с другими элементами на вашем сайте Tableau Cloud или на сервере Tableau. К ним относятся следующие:

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

Вы можете быстро получить доступ к этому типу информации с помощью ярлыков объектов, определенных в схеме GraphQL. Эти объекты происхождения или отношения используют префикс вышестоящего или нижестоящего . Например, вы можете использовать upstreamTablesConnection для запроса таблиц, используемых источником данных, используйте downstreamSheetsConnection для запроса листов, используемых рабочей книгой, или upstreamLinkedFlows и downstreamLinkedFlows для запроса потоков, которые находятся непосредственно выше или ниже друг друга.

Пример запроса с использованием ярлыка происхождения см. в разделе «Фильтрация» в разделе «Примеры запросов». Дополнительные сведения о связанных потоках см. в разделе Работа с объектами связанных потоков ниже.

Объекты пагинации

API метаданных позволяет вам перемещаться по отношениям в данных, которые вы запрашиваете, используя разбиение на страницы. Схема GraphQL определяет объекты разбивки на страницы как те объекты, которые используют суффикс Connection . Например, вы можете использовать databasesConnection , чтобы получить список разбитых на страницы результатов активов базы данных на вашем сайте Tableau Cloud или сервере Tableau.

Пример запроса, использующего разбиение на страницы, см. в разделе Разбиение на страницы в разделе Примеры запросов.

Унаследованные объекты

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

Пример запроса, в котором используется объект наследования описания, см. в разделе «Наследование» в разделе «Примеры запросов».

Модель метаданных таблицы

Вместе все объекты, роли, которые они играют, отношения, которые они имеют друг с другом, а также их атрибуты и свойства определяют модель метаданных для определенного набора объектов. Модель метаданных — это моментальный снимок (или, в терминах GraphQL, график) того, как Tableau интерпретирует и связывает набор объектов на вашем сайте Tableau Cloud или на сервере Tableau. Из модели метаданных вы можете понять зависимости и отношения в ваших данных.

Чтобы увидеть, как работает модель метаданных, используемая API метаданных, просмотрите следующие примеры сценариев.

Пример модели метаданных

Предположим, у вас есть три книги (родительские объекты) и два источника данных (родительские объекты), опубликованные в Tableau Cloud или Tableau Server.

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

Вот как может выглядеть модель метаданных для этого сценария.

Примечания:

  • Строка со стрелкой указывает на отношения собственности.
  • Пунктирная линия указывает на связь ссылки.

Пример сценария 1: Анализ воздействия

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

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

Как вы теперь знаете из модели метаданных, объекты листа принадлежат объектам рабочей книги, а объекты листа могут ссылаться на объекты поля. В этом сценарии объекты полей принадлежат объектам опубликованных источников данных. Опубликованные объекты источников данных владеют объектами полей. Таким образом, если John County — 1 будет удалено, дочерние объекты F1, Hills Library и Garden Library будут затронуты напрямую, а их существование будет скомпрометировано из-за их зависимости от этого объекта-источника данных. Другие дочерние объекты, F2, Garden Senior Center и Cliff Senior Center, хотя и могут быть затронуты удалением объекта источника данных, их существование не подвергается риску.

В ходе этого анализа вы можете видеть, что, поскольку John County — 1 не владеет объектами рабочей книги, которые к нему подключены, сами объекты рабочей книги, как Sakura District , так и Maple District , могут продолжать существовать при отсутствии опубликованного объекта источника данных.

Пример сценария 2: Анализ происхождения

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

В этом сценарии вам может понадобиться узнать, откуда берется точка данных из объекта листа Garden Senior Center в объекте рабочей книги Maple District .

На основании того, что вы знаете из модели метаданных, атрибуты наследуются от родительского объекта. Таким образом, если вы начнете с объекта листа Garden Senior Center , вы можете перейти к ссылочному объекту поля, F2, чтобы увидеть, что он принадлежит опубликованному объекту источника данных. В этом случае округ Джон — 2 является источником точки данных.

Во время этого анализа вы можете свободно включать или исключать части модели метаданных, чтобы понять поток родословной для Garden Senior Center . Например, вы можете исключить объект листа Garden Library , даже если он также принадлежит тому же объекту рабочей книги, Maple District .

Дополнительные примечания о модели метаданных

Использование пользовательского SQL

Модель метаданных интерпретирует запросы customSQL как таблицы.

Если в источнике данных или потоке определены пользовательские SQL-запросы, запросы должны соответствовать набору критериев, чтобы их можно было распознать и интерпретировать с помощью API метаданных. Дополнительные сведения см. в разделе Поддержка каталога Tableau для пользовательского SQL в справке Tableau.

Программные методы для определения того, не поддерживается ли пользовательский SQL, используемый в источнике данных или потоке, см. логические значения isUnsupportedCustomSql и containsUnsupportedCustomSql в справочнике по API.

Использование объекта databaseTable в запросе

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

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

Базы данных, которые могут возвращать неверную схему в описанном выше сценарии, включают Amazon Athena и Exasol.

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

При запуске запроса происхождения для определения вышестоящих баз данных (D1 и D2) из ​​рабочей книги (WB) используются только базы данных (D1), поля которых (F1) используются на листе рабочей книги (S) возвращаются. Базы данных (D2), на которые может ссылаться рабочая книга, но поля которых не используются листом напрямую, не будут отображаться как восходящие.

Запуск запроса тегов

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

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

 {
  теги {
    ресурсы {
      я бы
      имя
    }
  }
}
 

В этом примере запрос возвращает две книги с запутанными результатами.

 {
  теги {
    ресурсы {
      {идентификатор: "А", имя: ноль}
      {идентификатор: "B", имя: ноль}
    }
  }
}
 

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

 {
  теги {
    книги {
      я бы
      имя
    }
}
 

Когда вы изменяете запрос тегов, чтобы указать тип, запрос возвращает метаданные тегов для WorkbookA.

 {
  теги {
    книги {
      {идентификатор: "A", имя: "WorkbookA"}
      {идентификатор: "B", имя: ноль}
    }
}
 

Работа со связанными потоковыми объектами

В отличие от upstreamFlows и downstreamFlows объектов, которые возвращают все восходящие и нисходящие потоки, запросы, включающие 9Объекты 0497 upstreamLinkedFlows и downstreamLinkedFlows возвращают дополнительные структурные метаданные о восходящих и нисходящих потоках. Объекты upstreamLinkedFlows и downstreamLinkedFlows могут предоставлять информацию о порядке, расстоянии и взаимосвязи между потоками, которые находятся непосредственно выше и ниже по течению друг от друга.

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

 запрос upstreamflows_vs_upstreamlinkedflows {
  потоки (фильтр: {имя: "Superstore_AllUp"}) {
    имя
    я бы
    восходящие потоки{
      имя
      я бы
    }
    восходящий канал LinkedFlows{
      актив{
        имя
        я бы
      }
      toEdges
      из краев
    }
  }
}
 

Приведенный выше запрос возвращает следующую информацию.

 {
  "данные": {
    "течет": [
      {
        "name": "Супермаркет_Клиенты",
        "id": "089839c4-7edd-b887-3178-fcc2367e938b",
        "восходящие потоки": [
          {
            "name": "Superstore_Pods",
            "id": "66e8f90d-f02d-eea1-850e-2014b4b09b96"
          },
          {
            "name": "Супермаркет_Маркетинг",
            "id": "7efe5f86-511b-760b-18d4-1a6a28c220b5"
          },
          {
            "имя": "Супермаркет_Операции",
            "id": "cd79250f-bc27-1d9d-7b22-aca1534863e1"
          },
          {
            "name": "Супермаркет_Продажи",
            "id": "e78d4c54-df3a-12a9-ef1a-9849c2625b35"
          }
        ],
        "upstreamLinkedFlows": [
          {
            "актив": {
              "name": "Супермаркет_Клиенты",
              "идентификатор": "089839c4-7edd-b887-3178-fcc2367e938b"
            },
            "к краям": [
              "e78d4c54-df3a-12a9-ef1a-9849c2625b35",
              "7efe5f86-511b-760b-18d4-1a6a28c220b5",
              "cd79250f-bc27-1d9d-7b22-aca1534863e1"
            ],
            "из краев": []
          },
          {
            "актив": {
              "name": "Супермаркет_Продажи",
              "id": "e78d4c54-df3a-12a9-ef1a-9849c2625b35"
            },
            "к краям": [
              "cd79250f-bc27-1d9d-7b22-aca1534863e1"
            ],
            "из краев": [
              "089839c4-7edd-b887-3178-fcc2367e938b"
            ]
          },
          {
            "актив": {
              "name": "Супермаркет_Маркетинг",
              "id": "7efe5f86-511b-760b-18d4-1a6a28c220b5"
            },
            "к краям": [],
            "из краев": [
              "089839c4-7edd-b887-3178-fcc2367e938b"
            ]
          },
          {
            "актив": {
              "имя": "Супермаркет_Операции",
              "id": "cd79250f-bc27-1d9d-7b22-aca1534863e1"
            },
            "к краям": [
              "66e8f90d-f02d-eea1-850e-2014b4b09b96"
            ],
            "из краев": [
              "089839c4-7edd-b887-3178-fcc2367e938b",
              "e78d4c54-df3a-12a9-ef1a-9849c2625b35"
            ]
          },
          {
            "актив": {
              "name": "Superstore_Pods",
              "id": "66e8f90d-f02d-eea1-850e-2014b4b09b96"
            },
            "к краям": [],
            "из краев": [
              "cd79250f-bc27-1d9d-7b22-aca1534863e1"
            ]
          }
        ]
      }
    ]
  },
}
 
  • Из объекта upstreamFlows возвращаются следующие восходящие потоки: Superstore_Pods, Superstore_Marketing, Superstore_Operations и Superstore_Sales.

  • Принимая во внимание, что из объекта upstreamLinkedFlows возвращается следующая информация:

    • Из параметра актива видно, что возвращается Superstore_Customers. Это исходный поток или поток, из которого вы хотите понять его связь с другими потоками.
    • Из параметра fromEdges вы видите три прямых потока, с которыми Superstore_Customer связывается: Superstore_Marketing, Superstore_Operations и Superstore_Sales. Кроме того, вы видите дополнительную информацию об отношениях потоков для этих трех прямых потоков.
      • Superstore_Marketing, параметр fromEdges показывает Superstore_Customers как прямой восходящий поток, а параметр toEdges не показывает прямых нисходящих потоков.
      • Superstore_Operations, toEdges показывает как Superstore_Customers, так и Superstore_Sales как его прямые восходящие потоки, а toEdges показывает Superstore_Pods непосредственно после него.
    • Из параметра toEdges видно, что у Superstore_Customers нет прямых потоков, на которые он ссылается. Другими словами, Superstore_Customers находится в нижней части цепочки взаимоотношений.

Метаданные для объектов LookML | Смотритель

Пользователи с разрешением разработки могут просматривать контекстно-зависимую информацию об объектах на панели метаданных Looker IDE.

Для просмотра панели метаданных в Looker IDE:

  1. Перейдите к файлам проекта.
  2. Щелкните значок информации, чтобы открыть панель быстрой справки.
  3. На центральной панели поместите курсор на объект, который вы хотите видеть на панели метаданных.
  4. Щелкните вкладку Метаданные , чтобы открыть панель метаданных.

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

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

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

Метаданные для моделей

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

Метаданные для представлений

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

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

    Метаданные для Исследований

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

    1. Идентифицирует Исследователь по имени и по значку, представляющему его тип объекта (все значки возможных типов объектов см. на странице документации Навигация по проектам с помощью панели обозревателя объектов). Панель метаданных также содержит имя файла и номер строки, в которой Explorer определен в файле LookML (и ссылку на Explore в вашем проекте).
    2. Базовый вид Исследователя (вид, используемый в качестве отправной точки для построения Исследователя).
    3. Другие виды, объединенные в базовый вид.

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

    Метаданные для полей

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

    1. Идентифицирует поле по имени и значку, представляющему его объект тип (см. страницу документации Навигация по проектам с помощью панели обозревателя объектов для всех возможных значков типов объектов). Панель метаданных также показывает тип поля и предоставляет имя файла и номер строки, где поле определено в файле LookML (и ссылку на поле в вашем проекте).
    2. Модели, включающие представление этого поля.
    3. Представления, использующие это поле.

    Метаданные для расширений

    При нажатии параметра просмотра или исследования на панели метаданных отображаются расширения объекта. Вот пример расширенного объекта Explore:

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

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

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

    Метаданные для уточнений

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

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

    Метаданные для импортированных проектов

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

    На панели метаданных вы можете щелкнуть ссылку, чтобы перейти к импортированному файлу, в котором определен объект:

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

    Что такое метаданные Salesforce? Руководство для начинающих

    в Администраторы , гиды 

    Поделиться этой статьей…

    Метаданные — это основные компоненты или функции Salesforce. Без метаданных большая часть магии просто невозможна!

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

    Что такое метаданные Salesforce?

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

    Метаданные можно импортировать в Salesforce, изменять в интерфейсе продукта или управлять ими через API метаданных Salesforce.

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

    • Данные: основные компоненты структуры данных, на которых строится большинство настроек. Например. Пользовательские объекты, наборы значений и пользовательские приложения.
    • Программируемость: пользовательский код, разработанный поверх платформы. Например. Классы Apex, страница Apex и триггеры Apex.
    • Презентация: настройка взаимодействия пользователей с платформой. Например. Компоненты, страницы VisualForce и Lightning.

    Чтобы просмотреть полный список типов метаданных, щелкните здесь.

    Почему метаданные?

    Жестко запрограммированные приложения ушли в прошлое; персонализация — мода сезона.

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

    Чем метаданные отличаются от данных?

    Начинающие (и даже опытные) администраторы Salesforce предполагают, что метаданные и данные — это одно и то же, но это не так.

    Данные относятся к записям, на которые опирается бизнес, таким как Пользователи, Учетные записи, Контакты и т.д. С другой стороны, метаданные — это данные, описывающие другие данные.

    Запутались? Давайте разберем это на нескольких примерах.

    Пример 1. Метаданные в базовой форме

    Сначала рассмотрим метаданные в их самой базовой форме. Например, наша компания по производству велосипедов только что заключила сделку с Austin Bicycle Enterprise. Экземпляром этого объекта возможности Salesforce являются наши данные, а поле, такое как «Источник потенциальных клиентов», — это некоторые из метаданных, которые помогают описать и предоставить ценную информацию об этой отдельной возможности. Даже «Имя учетной записи» является важным метаданным, без этой информации мы бы не знали, как назвать эту возможность!

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

    Пример 2. Метаданные как правила проверки

    Из приведенного выше примера видно, что метаданные могут быть бесценны для организации; однако большая часть этой важной информации зависит от ручного ввода. Торговые представители, инженеры службы поддержки и другие пользователи обогащают Salesforce данными по мере выполнения своей работы. Одной из серьезных проблем является обеспечение точности метаданных в Salesforce. Отличный способ сделать это — использовать правила проверки.

    Правила проверки — это настраиваемые проверки, которые можно добавить в описания метаданных объектов Salesforce. В приведенном выше примере я создаю правило, чтобы наши идентификаторы ContractID соответствовали утвержденному корпоративному формату. Я также могу создавать более сложные правила с помощью формул, таких как vLookups (поклонники Excel, радуйтесь!), чтобы решать простые проблемы, такие как проверка правильности ввода почтового индекса.

    Пример 3: Метаданные как автоматизация

    У Unitrends, нашей дочерней компании-партнера, есть несколько интересных проблем, когда дело доходит до выполнения и обеспечения. В зависимости от своих потребностей клиенты приобретают оборудование, программное обеспечение или подписки SaaS. Иногда они покупают все три!

    Эти простые значения метаданных имеют БОЛЬШОЕ влияние на наши внутренние процессы. Каждое из этих значений запускает разные запросы, и разные команды начинают действовать в зависимости от значения. Если клиенту просто нужно резервное копирование Office 365 SaaS, все полностью автоматизировано: оплата, выставление счетов и т. д. — все это обрабатывается программным обеспечением.

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

    Удивительно, на что способны несколько простых полей!

    Вау! Новая функция «

    Где это используется?» Функция

    В выпуске Salesforce Winter ’19 была представлена ​​удивительная функция « Где это используется ?». Эта функция позволяет администраторам получать доступ к метаданным, не разрешая доступ к данным. Теперь пользователи могут легко создавать, редактировать и удалять метаданные, не касаясь самих данных.

    Новая функция доступна в следующих выпусках: Lightning Experience и Salesforce Classic в версиях Professional, Enterprise, Performance и Unlimited.

    Пользователи могут проверить ссылки на настраиваемое поле, например «Макет» или «Триггер Apex», нажав кнопку «Где это используется?» .

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

    Резюме

    Что делает Где это используется? Функция настолько привлекательна тем, что обеспечивает простоту доступа и настройки — и все это одновременно. Однако это также делает метаданные и данные более уязвимыми для атак.

    Добавьте к этому, предупреждающая метка, которая поставляется с этой функцией, не делает ситуацию лучше:

    Используйте эту функцию на свое усмотрение.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *