Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняется, как создать пользовательский API в Power Apps для Microsoft Dataverse с помощью решения. Чтобы определить свойства запроса и ответа, протестируйте пользовательский API и свяжите его подключаемый модуль. Если вы не знакомы с решениями, сначала прочитайте статью "Создание решения".
Решение должно быть ассоциировано с издательством. Издатель имеет определенный префикс настройки, связанный с ним. При создании пользовательского API необходимо использовать префикс настройки, и этот префикс должен быть одинаковым префиксом, используемым издателем решения. Следующие инструкции используют значение sample как префикс настройки, поскольку оно установлено для издателя.
Это важно
- Теперь есть лучший интерфейс для создания пользовательского API. Конструктор можно использовать в инструменте регистрации подключаемых модулей. Дополнительные сведения см. в статье "Создание пользовательского API" с помощью средства регистрации подключаемых модулей.
- Вы не можете изменить множество полей, связанных с созданием пользовательского API после их создания. Тщательно спланируйте проектирование пользовательского API перед началом работы. Если позже вы решите, что необходимо изменить эти поля, может потребоваться удалить существующую запись и повторно создать пользовательский API. Дополнительные сведения см. в таблицах CustomAPI.
Создайте пользовательскую запись API
В решении выберите новый>>дополнительный>пользовательский API из раскрывающегося списка.
Измените поля, чтобы задать свойства пользовательского API. Задайте значения для следующих полей. Дополнительные сведения см. в столбцах таблицы настраиваемых API.
Невозможно задать значения для типа подключаемого модуля перед его созданием. Это значение можно изменить позже.
Нажмите кнопку "Сохранить". Форма должна выглядеть следующим образом:
Создание параметров запроса
Пользовательский API не требует параметров. Создайте столько параметров, сколько необходимо передать данные, необходимые для логики.
В решении в раскрывающемся списке выберите новый>>дополнительный параметр>запроса пользовательского API.
Измените поля, чтобы задать свойства настраиваемого параметра запроса API. Дополнительные сведения см. в разделе "Столбцы таблицы CustomAPIRequestParameter".
Нажмите кнопку "Сохранить". Форма должна выглядеть примерно так:
Создание свойств ответа
Настраиваемый API, представляющий действие, не требует свойств ответа. Функция должна иметь по крайней мере одну. Если операция прошла успешно, она возвращает положительный ответ. Если действие завершается неудачей, возвращается ошибка. Определите свойства ответа для всех данных, возвращаемого API.
Если вы определяете только одно свойство ответа Entity или EntityCollection , ответ имеет этот тип. При определении нескольких свойств или одного или нескольких свойств простого типа API возвращает сложный тип, в котором каждое свойство ответа является свойством этого сложного типа.
Например, если пользовательское имя sample_CustomAPIExampleAPI является уникальным, он возвращает сложный тип sample_CustomAPIExampleResponse с свойствами для каждого определяемого свойства ответа.
В вашем решении выберите в раскрывающемся списке Новое>Больше>Другое>Свойство пользовательского ответа API.
Измените поля, чтобы задать свойства пользовательского свойства ответа API. Дополнительные сведения см. в статье CustomAPIResponseProperty Table Columns.
Нажмите кнопку "Сохранить". Форма должна выглядеть примерно так:
Просмотрите результат в документе службы
Если свойство для пользовательского API не задано IsPrivate , вы можете получить определение службы из документа CSDL $metadata с помощью GET запроса даже из браузера. Если URL-адрес для вашей среды указанhttps://yourorg.crm.dynamics.com, этот URL-адрес можно ввести в поле адреса браузера, чтобы получить $metadata: https://yourorg.crm.dynamics.com/api/data/v9.1/$metadata
Выполните поиск по результатам, чтобы найти название пользовательского API. Например, API, определенный с помощью предыдущих шагов, выглядит следующим образом:
<ComplexType Name="sample_CustomAPIExampleResponse">
<Property Name="StringProperty" Type="Edm.String" Unicode="false" />
</ComplexType>
<Action Name="sample_CustomAPIExample">
<Parameter Name="StringParameter" Type="Edm.String" Nullable="false" Unicode="false" />
<ReturnType Type="mscrm.sample_CustomAPIExampleResponse" Nullable="false" />
</Action>
Протестируйте ваш пользовательский API
После создания пользовательского API его можно попробовать. Даже если вы не задаете тип подключаемого модуля для определения основной операции, вы можете протестировать его сейчас, чтобы проверить правильность вызова. Все свойства ответа возвращают значение по умолчанию, например null. Дополнительные сведения см. в разделе "Вызов пользовательских API".
Обновление пользовательского типа подключаемого модуля API
Сведения о написании подключаемого модуля для пользовательского API, см. в статье "Написание подключаемого модуля для пользовательского API".
После регистрации сборки необходимо задать значение типа подключаемого модуля для созданного пользовательского API. Это значение является свойством подстановки, поэтому необходимо найти подключаемый модуль, представляющий тип, созданный при регистрации сборки.
После задания типа подключаемого модуля можно протестировать пользовательский API, чтобы убедиться, что возвращаются правильные результаты.
Другие способы создания пользовательских API
Инструмент регистрации плагинов предоставляет индивидуальный редактор API. Дополнительные сведения см. в статье "Создание пользовательского API" с помощью средства регистрации подключаемых модулей.
Возможно, у вас есть требования к созданию клиентского приложения, позволяющего создавать пользовательские API за пределами конструктора. Так как данные для пользовательских API хранятся в таблицах, их можно создать с помощью кода. Дополнительные сведения см. в статье "Создание пользовательского API с кодом".
Процесс ALM может лучше обслуживаться путем создания пользовательских API путем редактирования файлов решения. Дополнительные сведения см. в статье "Создание пользовательского API с файлами решения".
См. также
Создание и использование пользовательских API
Создание пользовательского API с помощью средства регистрации подключаемых модулей
Создание пользовательского API с кодом
Создание пользовательского API с файлами решения
Создание собственных сообщений