აპლიკაციის შემუშავება

Iroha აპლიკაციებმა უნდა განახორციელონ ტრანზაქციის ქცევა მკაფიოდ, შეინარჩუნონ ხელმოწერის მდგომარეობა და გამოიყენონ კითხვები და მოვლენები ისე, რომ პროდუქციაში ადვილად აღინიშნოს.

კლიენტის დაყენება

• შეინახეთ კლიენტის კონფიგურაცია აპლიკაციის წყარო კოდის გარეთ. დატვირთეთ ჯაჭვი ID, Torii URL, ხელმოწერის ანგარიში და ტრანზაქციის პარამეტრები გარემოს სპეციფიკური კონფიგურიდან.
• შეინახეთ client.toml ფაილები ცალკე ლოკალურ ქსელზე, Taira, Minamoto და კერძო ქსელებზე. გადაწერილი ტესტნეტის ხელმომწერი არასდროს უნდა გახდეს ძირითადი ქსელის ხელმომწერის.
• განზრახ დააყენეთ ტრანზაქციის ხანგრძლივობა და სტატუსის დროები. ძალიან მოკლე ხანგრძლივი პერიოდი შეიძლება ამოიწუროს ნორმალური ქსელის ტრიფტის დროს, ხოლო ძალიან დიდი ხანგრძლივები შეიძლება გაუჭირდება დუბლიტური წარდგენების დასაბუთება.
• გამოიყენეთ nonce = true მხოლოდ მაშინ, როდესაც განმეორებადი ტრანზაქციები უნდა შეიცავდეს ცალკეულ ჰეშებს. idempotent ბიზნეს ოპერაციებისთვის, შეინახეთ და გაიმეორეთ განაცხადის მოთხოვნა ID ისე, რომ განმეორებითი მცდელობები შეიძლება გამოიყურებოდეს.

იხილეთ კლიენტის კონფიგურაცია მიმდინარე TOML ველებისთვის.

ოპერაციები

• ტრანზაქციები შეიქმნას SDK ტიპირებული ინსტრუქციებიდან, სადაც შესაძლებელია ნედლეულის JSON ან მავთულხლართებით შეკრებილი სასარგებლო ტვირთების მაგივრად.
• Preflight important წერს მხოლოდ კითხვაზე: ანგარიშის არსებობა, აქტივების ბალანსი, ნებართვის მდგომარეობა, საფასური აქტივების ხელმისაწვდომობა და მიზნობრივი ობიექტის მდგომარეობა.
• დაფიქსირეთ ტრანზაქციის ჰეში, ავტორიტეტის ანგარიში, ინსტრუქციის შეჯამება და მოსალოდნელი მდგომარეობის ცვლილება წარდგენამდე.
• Rejected, Expired და დროის შეწყვეტის შედეგები განსხვავდება. დროის შეზღუდვა ნიშნავს, რომ კლიენტი საბოლოო სტატუსს არ აკვირდებოდა; ეს არ ადასტურებს იმას, რომ ქსელმა ტრანზაქცია იგნორირა.
• წარმატებული ჩანაწერის შემდეგ, შეამოწმეთ მიღებული მდგომარეობა გამოკითხვის ან მოვლენის შემოწმების პუნქტით, რომელიც ემთხვევა ბიზნეს ოპერაციას.

ტრანზაქციების მექანიკის შესახებ იხილეთ ტრანზაქცია.

კითხვები და მოვლენები

• გამოიყენეთ შეკითხვები მიმდინარე მდგომარეობისა და მოვლენების ნაკადებისთვის ცვლილების შესახებ შეტყობინებებისათვის. თავიდან აიცილეთ მოვლენის მართვის შეცვლა მრავალჯერადი ფართო შეკითხვებით.
• ფართო განმეორებადი გამოკითხვების გვერდები, როგორიცაა ანგარიში, აქტივი და ბლოკის სიები.
• ფართო ფილტრები სასარგებლოა დიაგნოსტიკისთვის, მაგრამ შეიძლება დაამატოს ზედმეტი შესრულება და კლიენტის მხრიდან დამუშავება .
• შეინახეთ მხოლოდ წაკითხვის მქონე სიგარეტის შემოწმება ხელმოწერილი ტრანზაქციული ტესტებისგან, რათა საბოლოო წერტილების ხელმისაწვდომობა უფრო ადვილი იყოს დიაგნოსტიკის გაკეთება.

იხილეთ კითხვები, შეხვედრები და ფილტრები .

სააგენტო დახმარებით განვითარება

• ნება მიეცით აგენტებს შეამოწმონ დოკუმენტები, SDK კოდი და მხოლოდ წაკითხვის ქსელის სტატუსი სანამ სთხოვენ მათ ჩაწერონ ტრანზაქციის კოდი.
• გაითვალისწინეთ ცოცხალი ქსელის ტესტების ჩატარება გარემოს დროშის მიღმა, როგორიცაა TAIRA_LIVE=1.
• არ ჩასვით კერძო გასაღები, ანგარიშის აღდგენის მასალა, API ტოკენები ან გადამისამართებული ავტოგრაფების სათაურები შეტყობინებებში.
• მოითხოვეთ გარიგების გეგმა, სანამ რომელიმე აგენტი პირდაპირი ტესტნეტის ტრანზაქციას წარადგენს. გეგმამ უნდა დაასახელოს ქსელი, ავტორიტეტი, ინსტრუქცია, საფასური აქტივი, ფრენის წინასწარი წაკითხვა, მოსალოდნელი შედეგი და განმეორებითი მცდელობის ქცევა.

Taira MCP სამუშაო პროცესის შესახებ იხილეთ შენება SORA 3: Taira და Minamoto.

SDK ჰიგიენა

• pin SDK და binary ვერსიები ერთად, გამოყენებით Compatibility Matrix.
• შენარჩუნება გენერირებული კლიენტის კოდი, snippets და მაგალითები სინქრონიზებულია pinned upstream სამუშაო სივრცე რევიზიის.
• დაამატეთ ერთეულის ტესტები ტრანზაქციების მშენებლობის კოდისა და ინტეგრაციის ტესტების მინიმალური წაკითხვისა და წერის გზები თქვენი განაცხადი დამოკიდებულია.