Հանդիպման սանձազերծող օրինակ

Այս օրինակում օգտագործվում է IDs կանոնիկ դոմեյնային հաշիվ եւ Iroha 3 տվյալների մոդելում կանխատեսված ակտիվների սահմանումները:

Ենթադրենք, որ ցանցը ունի

• Քանոնիկ հաշիվ, որը վերահսկվում է Ալիսայի բանալինով:
• Քանոնիկ հաշվետվություն, որը վերահսկվում է Խելագար Hatter- ի բանալինով
• wonderland.universal ենթակետում կանխատեսված ակտիվի սահմանումը՝ tea
• այդ ակտիվի բալանսը, որը պահվում է յուրաքանչյուր հաշվին:

Գլխավոր նպատակն է գրանցել մի գործարկիչ, որը դիտում է Ալիսայի թեյի հավասարակշռությունը եւ ուղարկում է փոխանցում 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 ֆիլտրը օգտակար է debugging- ի համար, բայց այն ստիպում է յուրաքանչյուր համապատասխանող իրադարձությունը վճարել trigger- ի գնահատման ծախսերը:

5. Գրանցեք գործարկիչը:

Գրանցեք գործարկիչը հետեւյալ անունով.

• բյուջե TriggerId
• կատարելի հրահանգների հաջորդականությունը
• Repeats::Indefinitely կամ Repeats::Exactly(n)
• տեխնիկական հաշվետվությունը
• իրադարձությունների ֆիլտրը
• նախընտրական մետադատա

Trigger գրանցումը ինքնուրույն նորմալ գործարք է, այնպես որ գրանցող հաշիվը պահանջում է թույլտվություն գրանցել triggers. Տեխնիկական հաշիվը պետք է թույլտվերները, որոնք պահանջվում են trigger- ի կատարման համար:

Գործադրանքի կարգը

Երբ բլոկը կատարվում է.

1. Սովորական գործարքների հրահանգները սկսվում են առաջինը:
2. Նշված հրահանգների համաձայն ստեղծված տվյալները հավաքվում են:
3. Նշվում է, թե ինչն է առաջացնում այդ իրադարձությունները:
4. Բլոկի գործարկման խողովակաշարի մեջ կառավարվում են սթրիկատորների կողմից արտադրված ազդեցությունները, առանց սահմանափակ ռեկուրսիվ սթրիկը կատարելու թույլ տալու:

Եթե գործարկիչը օգտագործում է Repeats::Exactly(n), գրանցեք նոր գործարկիչ, երբ հաշիվն ավարտված է եւ նույն վարքագիծը կրկին անհրաժեշտ է: