واقعہ ٹرگر مثال

اس مثال میں Iroha 3 ڈیٹا ماڈل میں کینونیکل ڈومین لیس اکاؤنٹ IDs اور متوقع اثاثہ تعریفیں استعمال کی جاتی ہیں.

فرض کریں کہ ایک نیٹ ورک میں:

• الیس کی چابی کے کنٹرول میں ایک کینونیکل اکاؤنٹ
• پاگل ہیٹر کی کلید کے ذریعہ کنٹرول کردہ ایک کینونیکل اکاؤنٹ۔
• wonderland.universal کے تحت tea کے طور پر پیش گوئی کی گئی ایک اثاثہ تعریف
• اس اثاثے کا بیلنس جو ہر اکاؤنٹ کے پاس ہے

مقصد ایک ٹرگر کو رجسٹر کرنا ہے جو ایلس کے چائے کے توازن کا مشاہدہ کرتا ہے اور جب میچنگ ڈیٹا واقعہ جاری ہوتا ہے تو پاگل ہیٹر اکاؤنٹ سے منتقلی جمع کراتا ہے۔

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) کا استعمال کرتا ہے تو، جب گنتی ختم ہو جاتی ہے اور اسی رویے کی ضرورت ہوتی ہے تو، ایک نیا ٹرگر رجسٹر کریں۔