Пример trigger событий

В этом примере используются канонические счета без домена IDs и прогнозируемые определения активов в модели данных Iroha 3.

Предположим, что сеть имеет:

• Канонический отчет, контролируемый ключом Алисы.
• Канонический отчет, контролируемый ключом безумного шляпщика.
• определение активов, прогнозируемое как tea в соответствии с wonderland.universal
• баланс этого актива, находящегося на каждом счете;

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

1. Подготовка счетов и активов

Сначала зарегистрируйте учетные записи участников и определение активов. В текущем Iroha, счета IDs приходят от контролеров счетов, в то время как проектируемые домены используют domain.dataspace Форма:

domain: wonderland.universal
asset definition projection: tea in wonderland.universal
holder accounts: AccountId(controller=alice_key), AccountId(controller=mad_hatter_key)

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

2. Выберите орган запуска

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

Технический аккаунт должен уже существовать и иметь разрешение на представление инструкций в запускающем устройстве.

3. Определить исполняемое

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

Transfer(
  source = AssetId(tea_definition, mad_hatter_account),
  value = Numeric(1),
  destination = AssetId(tea_definition, alice_account)
)

Используйте текущие типовые конструкторы SDK для окончательной полезной загрузки транзакции. Избегайте жесткого кодирования старого текстового IDs в код запуска; анализируйте или запрашивайте канонический IDs перед созданием исполняемого.

4. Определить фильтр событий

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

EventFilterBox::Data(
  DataEventFilter for asset changes involving
  AssetId(tea_definition, alice_account)
)

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

5. Зарегистрируйте триггер.

Зарегистрируйте триггер с:

• устойчивый TriggerId
• последовательность выполняемых инструкций
• Repeats::Indefinitely или Repeats::Exactly(n)
• технический учет
• фильтр событий
• необязательные метаданные

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

Приказ исполнения

Когда блок выполняется:

1. Обычные инструкции о транзакциях выполняются первыми.
2. Собираются данные о событиях, вызванных указанными инструкциями.
3. Запускаются триггеры, фильтры которых совпадают с этими мероприятиями.
4. Эффекты, вызванные триггером, обрабатываются в цепочке исполнения блока без ограничения рекурсивного выполнения триггера.

Если в пуске используется Repeats::Exactly(n), зарегистрируйте новый пуск, когда число исчерпано и снова требуется одно и то же действие.