defineLogicFunction
Определяйте логические функции и их триггеры
defineLogicFunction
Определяйте логические функции и их триггеры
Каждый файл функции использует Доступные типы триггеров:Тип
В обработчике обращайтесь к переданным заголовкам следующим образом:Основные моменты:
defineLogicFunction() для экспорта конфигурации с обработчиком и необязательными триггерами.src/logic-functions/createPostCard.logic-function.ts
- httpRoute: Публикует вашу функцию по HTTP-пути и методу под конечной точкой
/s/:
например,path: '/post-card/create'вызывается по адресуhttps://your-twenty-server.com/s/post-card/create
- cron: Запускает вашу функцию по расписанию с использованием выражения CRON.
- databaseEvent: Запускается при событиях жизненного цикла объектов рабочего пространства. Когда операция события —
updated, можно указать конкретные поля для отслеживания в массивеupdatedFields. Если оставить не заданным или пустым, любое обновление будет вызывать функцию.
например,person.updated,*.created,company.*
Вы также можете вручную выполнить функцию с помощью CLI:Вы можете просматривать логи с помощью:
Полезная нагрузка триггера маршрута
Когда триггер маршрута вызывает вашу логическую функцию, она получает объектRoutePayload, который соответствует формату AWS HTTP API v2.
Импортируйте тип RoutePayload из twenty-sdk:RoutePayload имеет следующую структуру:| Свойство | Тип | Описание | Пример |
|---|---|---|---|
headers | Record\<string, string | undefined> | HTTP-заголовки (только перечисленные в forwardedRequestHeaders) | см. раздел ниже |
queryStringParameters | Record\<string, string | undefined> | Параметры строки запроса (несколько значений объединяются запятыми) | /users?ids=1&ids=2&ids=3&name=Alice -> { ids: '1,2,3', name: 'Alice' } |
pathParameters | Record\<string, string | undefined> | Параметры пути, извлечённые из шаблона маршрута | /users/:id, /users/123 -> { id: '123' } |
body | object | null | Разобранное тело запроса (JSON) | { id: 1 } -> { id: 1 } |
isBase64Encoded | boolean | Является ли тело закодированным в base64 | |
requestContext.http.method | string | Метод HTTP (GET, POST, PUT, PATCH, DELETE) | |
requestContext.http.path | string | Необработанный путь запроса |
forwardedRequestHeaders
По умолчанию HTTP-заголовки из входящих запросов не передаются в вашу логическую функцию по соображениям безопасности. Чтобы получить доступ к определённым заголовкам, перечислите их в массивеforwardedRequestHeaders:Имена заголовков приводятся к нижнему регистру. Обращайтесь к ним, используя ключи в нижнем регистре (например,
event.headers['content-type']).Предоставление функции как инструмента
Логические функции можно предоставлять как инструменты для ИИ-агентов и рабочих процессов. Когда функция помечена как инструмент, она становится доступной для функций ИИ Twenty и может использоваться в автоматизациях рабочих процессов.Чтобы пометить логическую функцию как инструмент, установитеisTool: true:src/logic-functions/enrich-company.logic-function.ts
- Вы можете комбинировать
isToolс триггерами — функция может одновременно быть инструментом (вызываемым агентами ИИ) и запускаться событиями. toolInputSchema(необязательно): объект JSON Schema, описывающий параметры, которые принимает ваша функция. Схема вычисляется автоматически на основе статического анализа исходного кода, но вы можете задать её явно:
Напишите хорошее описание в поле
description. Агенты ИИ опираются на поле description функции, чтобы решить, когда использовать инструмент. Чётко опишите, что делает инструмент и когда его следует вызывать.definePostInstallLogicFunction
Определяет послеустановочную логическую функцию (по одной на приложение)
definePostInstallLogicFunction
Определяет послеустановочную логическую функцию (по одной на приложение)
Послеустановочная функция — это функция логики, которая автоматически выполняется после завершения установки вашего приложения в рабочем пространстве. Сервер выполняет её после того, как метаданные приложения синхронизированы и клиент SDK сгенерирован, так что рабочее пространство полностью готово к использованию, а новая схема уже применена. Типичные сценарии использования включают предзаполнение данных по умолчанию, создание начальных записей, настройку параметров рабочего пространства или выделение ресурсов в сторонних сервисах.Вы также можете вручную выполнить постустановочную функцию в любое время с помощью CLI:Основные моменты:
src/logic-functions/post-install.ts
- Послеустановочные функции используют
definePostInstallLogicFunction()— специализированный вариант, который опускает настройки триггеров (cronTriggerSettings,databaseEventTriggerSettings,httpRouteTriggerSettings,isTool). - Обработчик получает
InstallPayloadс{ previousVersion?: string; newVersion: string }—newVersion— это устанавливаемая версия, аpreviousVersion— версия, установленная ранее (илиundefinedпри чистой установке). Используйте эти значения, чтобы отличать чистые установки от обновлений и запускать логику миграции, зависящую от версии. - Когда запускается хук: по умолчанию только при чистой установке. Передайте
shouldRunOnVersionUpgrade: true, если хотите, чтобы он также выполнялся при обновлении приложения с предыдущей версии. Если флаг опущен, по умолчанию он равенfalse, и при обновлении хук пропускается. - Модель выполнения — по умолчанию асинхронно, синхронный режим по выбору: флаг
shouldRunSynchronouslyопределяет, как выполняется post-install.shouldRunSynchronously: false(по умолчанию) — хук помещается в очередь сообщений сretryLimit: 3и выполняется асинхронно в воркере. Ответ на установку возвращается сразу после постановки задания в очередь, поэтому медленный или дающий сбой обработчик не блокирует вызывающую сторону. Воркер выполнит до трёх повторных попыток. Используйте это для длительных задач — наполнение большими наборами данных, вызовы медленных сторонних API, подготовка внешних ресурсов — всего, что может выйти за разумное окно ответа HTTP.shouldRunSynchronously: true— хук выполняется непосредственно в процессе установки (тот же исполнитель, что и для pre-install). Запрос установки блокируется, пока обработчик не завершится, и если он генерирует исключение, вызывающая сторона установки получаетPOST_INSTALL_ERROR. Автоматических повторов нет. Используйте это для быстрых задач, которые должны завершиться до отправки ответа — например, выдача ошибки валидации пользователю или быстрая настройка, на которую клиент будет полагаться сразу после возврата вызова установки. Имейте в виду, что к моменту запуска post-install миграция метаданных уже применена, поэтому сбой в синхронном режиме не откатывает изменения схемы — он лишь выявляет ошибку.
- Убедитесь, что ваш обработчик идемпотентен. В асинхронном режиме очередь может выполнить до трёх повторных попыток; в любом режиме хук может запускаться снова при обновлениях, когда
shouldRunOnVersionUpgrade: true. - Переменные окружения
APPLICATION_ID,APP_ACCESS_TOKENиAPI_URLдоступны внутри обработчика (как и в любой другой логической функции), поэтому вы можете вызывать API Twenty с токеном доступа приложения, ограниченным вашим приложением. - Для каждого приложения допускается только одна послеустановочная функция. Сборка манифеста завершится ошибкой, если будет обнаружено более одной такой функции.
- Параметры функции
universalIdentifier,shouldRunOnVersionUpgradeиshouldRunSynchronouslyавтоматически добавляются в манифест приложения в полеpostInstallLogicFunctionво время сборки — вам не нужно указывать их вdefineApplication(). - Тайм-аут по умолчанию установлен на 300 секунд (5 минут), чтобы позволить выполнять более длительные задачи настройки, такие как инициализация данных.
- Не выполняется в режиме разработки: когда приложение зарегистрировано локально (через
yarn twenty dev), сервер полностью пропускает процесс установки и синхронизирует файлы напрямую через наблюдатель CLI — поэтому post-install никогда не запускается в режиме разработки, независимо отshouldRunSynchronously. Используйтеyarn twenty exec --postInstall, чтобы запустить это вручную для запущенного рабочего пространства.
definePreInstallLogicFunction
Определяет предустановочную логическую функцию (по одной на приложение)
definePreInstallLogicFunction
Определяет предустановочную логическую функцию (по одной на приложение)
Функция pre-install — это логическая функция, которая автоматически выполняется во время установки, до применения миграции метаданных рабочего пространства. Она использует ту же структуру полезной нагрузки, что и post-install (Вы также можете вручную выполнить предустановочную функцию в любое время с помощью CLI:Основные моменты:
InstallPayload), но находится раньше в процессе установки, чтобы подготовить состояние, от которого зависит предстоящая миграция, — типичные сценарии включают резервное копирование данных, проверку совместимости с новой схемой или архивирование записей, которые будут реструктурированы или удалены.src/logic-functions/pre-install.ts
- Функции pre-install используют
definePreInstallLogicFunction()— та же специализированная конфигурация, что и у post-install, только привязанная к другому этапу жизненного цикла. - И обработчики pre-, и post-install получают один и тот же тип
InstallPayload:{ previousVersion?: string; newVersion: string }. Импортируйте его один раз и используйте повторно в обоих хуках. - Когда запускается хук: выполняется непосредственно перед миграцией метаданных рабочего пространства (
synchronizeFromManifest). Перед выполнением сервер запускает чисто добавочную «урезанную синхронизацию», которая регистрирует в метаданных рабочего пространства pre-install функцию новой версии — ничего больше не затрагивается — а затем выполняет её. Поскольку эта синхронизация только добавляет, объекты, поля и данные предыдущей версии остаются нетронутыми к моменту запуска вашего обработчика: вы можете безопасно читать и сохранять состояние до миграции. - Модель выполнения: pre-install выполняется синхронно и блокирует установку. Если обработчик генерирует исключение, установка прерывается до применения каких-либо изменений схемы — рабочее пространство остаётся на предыдущей версии в согласованном состоянии. Это сделано намеренно: pre-install — ваш последний шанс отказать в рискованном обновлении.
- Как и в случае с post-install, для каждого приложения допускается только одна предустановочная функция. Она автоматически добавляется в манифест приложения в поле
preInstallLogicFunctionво время сборки. - Не выполняется в режиме разработки: как и post-install, процесс установки полностью пропускается для локально зарегистрированных приложений, поэтому pre-install никогда не запускается при
yarn twenty dev. Используйтеyarn twenty exec --preInstall, чтобы запустить это вручную.
Pre-install и post-install: когда что использовать
Выбор подходящего хука установки
Pre-install и post-install: когда что использовать
Выбор подходящего хука установки
Оба хука являются частью одного и того же процесса установки и получают один и тот же Pre-install всегда синхронный (он блокирует установку и может её прервать). Post-install по умолчанию асинхронный — ставится в очередь воркера с автоматическими повторами — но может перейти к синхронному выполнению с Используйте Общее правило:
InstallPayload. Разница в том, когда они запускаются относительно миграции метаданных рабочего пространства, и это определяет, к каким данным можно безопасно обращаться.shouldRunSynchronously: true. См. аккордеон definePostInstallLogicFunction выше о том, когда использовать каждый режим.Используйте post-install для всего, что требует наличия новой схемы. Это распространённый случай:- Наполнение данными по умолчанию (создание начальных записей, стандартных представлений, демонстрационного контента) для недавно добавленных объектов и полей.
- Регистрация вебхуков в сторонних сервисах теперь, когда у приложения уже есть учётные данные.
- Вызов вашего собственного API для завершения настройки, зависящей от синхронизированных метаданных.
- Идемпотентная логика «убедиться, что это существует», которая должна приводить состояние в соответствие при каждом обновлении — совместите с
shouldRunOnVersionUpgrade: true.
PostCard по умолчанию после установки:src/logic-functions/post-install.ts
pre-install, когда миграция в противном случае уничтожит или повредит существующие данные. Поскольку pre-install работает с предыдущей схемой и при сбое откатывает обновление, это правильное место для всего рискованного:- Резервное копирование данных, которые будут удалены или реструктурированы — например, вы удаляете поле в v2 и вам нужно скопировать его значения в другое поле или экспортировать их в хранилище до запуска миграции.
- Архивирование записей, которые новое ограничение сделает недопустимыми — например, поле становится
NOT NULL, и вам сначала нужно удалить или исправить строки со значениями null. - Проверка совместимости и отказ от обновления, если текущие данные нельзя корректно мигрировать — выбросьте исключение из обработчика, и установка прервётся без внесения изменений. Это безопаснее, чем обнаружить несовместимость в середине миграции.
- Переименование или изменение ключей данных перед изменением схемы, которое привело бы к потере связи.
src/logic-functions/pre-install.ts
| You want to… | Использовать |
|---|---|
| Наполнить данными по умолчанию, настроить рабочее пространство, зарегистрировать внешние ресурсы | post-install |
| Выполнить длительное наполнение или сторонние вызовы, которые не должны блокировать ответ установки | post-install (по умолчанию — shouldRunSynchronously: false, с повторами воркера) |
| Выполнить быструю настройку, на которую вызывающая сторона будет полагаться сразу после возврата вызова установки | post-install с shouldRunSynchronously: true |
| Прочитать или сохранить данные, которые предстоящая миграция может потерять | pre-install |
| Отклонить обновление, которое повредит существующие данные | pre-install (бросьте исключение из обработчика) |
| Выполнять согласование при каждом обновлении | post-install с shouldRunOnVersionUpgrade: true |
| Сделать одноразовую настройку только при первой установке | post-install с shouldRunOnVersionUpgrade: false (по умолчанию) |
Если сомневаетесь, выбирайте по умолчанию post-install. Обращайтесь к pre-install только тогда, когда сама миграция разрушительна и вам нужно перехватить предыдущее состояние, прежде чем оно исчезнет.
Типизированные клиенты API (twenty-client-sdk)
Пакетtwenty-client-sdk предоставляет два типизированных клиента GraphQL для взаимодействия с API Twenty из ваших логических функций и фронт-компонентов.
| Клиент | Импорт | Конечная точка | Генерируется? |
|---|---|---|---|
CoreApiClient | twenty-client-sdk/core | /graphql — данные рабочего пространства (записи, объекты) | Да, на этапе dev/build |
MetadataApiClient | twenty-client-sdk/metadata | /metadata — конфигурация рабочего пространства, загрузка файлов | Нет, поставляется в готовом виде |
CoreApiClient
Запрос и изменение данных рабочего пространства (записи, объекты)
CoreApiClient
Запрос и изменение данных рабочего пространства (записи, объекты)
CoreApiClient — основной клиент для запросов и изменений данных рабочего пространства. Он генерируется из схемы вашего рабочего пространства во время yarn twenty dev или yarn twenty build, поэтому полностью типизирован в соответствии с вашими объектами и полями.true, чтобы включить поле, используйте __args для аргументов и вкладывайте объекты для отношений. Вы получаете полное автодополнение и проверку типов на основе схемы вашего рабочего пространства.CoreApiClient генерируется на этапе dev/build. Если вы используете его, не запустив сначала
yarn twenty dev или yarn twenty build, он выбросит ошибку. Генерация происходит автоматически — CLI анализирует GraphQL-схему вашего рабочего пространства и создает типизированный клиент с помощью @genql/cli.Использование CoreSchema для аннотаций типов
CoreSchema предоставляет типы TypeScript, соответствующие объектам вашего рабочего пространства — это полезно для типизации состояния компонентов или параметров функций:MetadataApiClient
Конфигурация рабочего пространства, приложения и загрузка файлов
MetadataApiClient
Конфигурация рабочего пространства, приложения и загрузка файлов
MetadataApiClient поставляется в готовом виде вместе с SDK (генерация не требуется). Он выполняет запросы к эндпоинту /metadata для получения конфигурации рабочего пространства, приложений и загрузки файлов.Загрузка файлов
MetadataApiClient включает метод uploadFile для прикрепления файлов к полям типа файла:| Параметр | Тип | Описание |
|---|---|---|
fileBuffer | Buffer | Необработанное содержимое файла |
filename | string | Имя файла (используется для хранения и отображения) |
contentType | string | Тип MIME (по умолчанию application/octet-stream, если не указан) |
fieldMetadataUniversalIdentifier | string | Значение universalIdentifier для поля типа файла в вашем объекте |
- Он использует
universalIdentifierполя (а не его идентификатор, специфичный для рабочего пространства), поэтому ваш код загрузки будет работать в любом рабочем пространстве, где установлено ваше приложение. - Возвращаемый
url— это подписанный URL, который можно использовать для доступа к загруженному файлу.
Когда ваш код выполняется на Twenty (логические функции или фронт-компоненты), платформа предоставляет учётные данные в виде переменных окружения:
TWENTY_API_URL— базовый URL API TwentyTWENTY_APP_ACCESS_TOKEN— краткоживущий ключ, ограниченный ролью функции по умолчанию вашего приложения
process.env. Права ключа API определяются ролью, указанной в defaultRoleUniversalIdentifier в вашем application-config.ts.