Ծրագրերի զարգացում

Iroha ծրագրերը պետք է բացահայտեն գործարքի վարքագիծը, պահպանեն ստորագրման վիճակը եւ օգտագործեն հարցումները եւ իրադարձությունները այնպես, որ հեշտությամբ դիտարկվեն արտադրության ընթացքում:

Հաճախորդի կարգավորումը

• Պահպանեք հաճախորդի կարգավորումը հավելվածի աղբյուրային կոդից դուրս: Բեռնել շղթան ID, Torii URL, ստորագրման հաշիվը եւ գործարքի կարգավորումները միջավայրի հատուկ կոնֆigurացիայից:
• Պահպանեք client.toml ֆայլերը առանձին տեղական ցանցի, Taira, Minamoto եւ մասնավոր ցանցերի համար: Կոպիացված փորձարկման ցանցի ստորագրողը երբեք չպետք է դառնա հիմնական ցանցի ստորագրիչ:
• Առեւտրի տեւողությունը եւ վիճակի ժամկետները կանխիկորեն սահմանեք: Շատ կարճ ժամանակահատվածը կարող է ավարտվել ցանցի նորմալ ցնցման պայմաններում, մինչդեռ շատ երկար ժամանակահատվածում կրկնօրինակ ներկայացումները կարող են ավելի դժվար լինել մտածելու համար:
• Օգտագործեք nonce = true միայն այն դեպքում, երբ կրկնվող գործարքները պետք է ունենան տարբեր շիշեր: Idempotent բիզնես գործողությունների համար պահեք եւ վերաօգտագործեք հայտի պահանջը ID այնպես որ հետագա փորձերը կարող են հետեւել:

Դիտեք Հաճախորդի կարգավորումը՝ ընթացիկ TOML դաշտերի համար:

Գործարքներ

• Գործարքներ կառուցել SDK տիպված հրահանգներից, որտեղ հնարավոր է, այլ ոչ թե հումքի JSON կամ շղթայով հավաքված օգտակար բեռների փոխարեն:
• Preflight կարեւորը գրում է միայն ընթերցման հարցերով. հաշիվի առկայությունը, ակտիվների բալանսները, թույլտվության վիճակը, վճարային ակտիվների մատչելիությունը եւ նպատակային օբյեկտի վիճակը:
• Գրանցեք գործարքի хэշը, իրավասու հաշիվը, հրահանգների ամփոփումը եւ սպասվող վիճակի փոփոխությունը նախքան ուղարկելը:
• Բարեւ Rejected, Expired, եւ ժամանակահատվածի արդյունքները տարբերվում են: Timeout- ը նշանակում է, որ հաճախորդը չի նկատել վերջնական կարգավիճակը; դա չի ապացուցում, որ ցանցը անտեսել է գործարքը:
• Հաջողակ գրելուց հետո ստուգեք արդյունքում գտնվող վիճակը հարցման կամ իրադարձության հետ կապված վերահսկողության կետով, որը համապատասխանում է բիզնեսի գործողությանը:

Գործարքների մեխանիզմների համար դիտեք Գործարքներ.

Հարցեր եւ իրադարձություններ

• Օգտագործեք ընթացիկ վիճակի եւ իրադարձությունների հոսքի հարցումները փոփոխության ծանուցումների համար: Խուսափեք իրադարձությունների կառավարման փոխարինելուց կրկնվող լայն հարցումների հետ.
• Կարդացեք լայն կրկնվող հարցումներ, ինչպիսիք են հաշիվները, ակտիվները եւ բլոկային ցուցակները:
• Նախընտրում են նեղ ֆիլտրերը բաժանորդագրությունների եւ գործարկիչների համար: Հասարակ ֆիլտրները օգտակար են ախտորոշման համար, բայց կարող են ավելացնել ոչ անհրաժեշտ կատարում եւ հաճախորդի կողմից մշակումը:
• Պահպանեք միայն ընթերցվող ծխի ստուգումները բաժանված ստորագրված գործարքային փորձարկումներից, որպեսզի վերջնական կետերի մատչելիությունը ավելի հեշտ լինի ախտորոշել:

Նայեք Հարցեր, Պատահանդեսներ եւ Ֆիլտրեր.

Գործակալների աջակցությամբ զարգացում

• Թույլ տվեք գործակալներին ստուգել փաստաթղթերը, SDK կոդը եւ միայն ընթերցվող ցանցի վիճակը նախքան նրանց խնդրել գրել փոխանցման կոդը:
• Պահպանեք կենդանի ցանցի փորձարկումները' ընտրելով միջավայրի դրոշ, ինչպիսիք են TAIRA_LIVE=1:
• Մի տեղադրեք անձնական բանալիներ, հաշիվների վերականգնման նյութեր, API տոկեններ կամ ուղարկված հեղինակային գլխավորագրերը հրահանգների մեջ:
• Պահանջեք գործարքի պլան, նախքան ցանկացած գործակալ ներկայացնի կենդանի փորձարկման ցանցի գործարք: Ծրագիրը պետք է նշել ցանցը, իշխանությունը, հրահանգները, վճարային ակտիվը, թռիչքից առաջ կարդալը, ակնկալվող արդյունքը եւ կրկին փորձել վարքը:

Taira MCP աշխատանքային հոսքի համար տես Կառուցեք SORA 3 վրա: Taira եւ Minamoto.

SDK Մաքրություն

• Pin SDK եւ բինար տարբերակները միասին՝ օգտագործելով համատեղելիության մատրիկան .
• Պահպանեք առաջադրված հաճախորդի կոդը, հատվածները եւ օրինակները համաժամեցված վերածննդային աշխատանքային տարածքի թարմացման հետ:
• Ավելացրեք գործարքների կառուցման կոդի եւ ինտեգրման փորձարկումների համար միավորների թեստերը ՝ ձեր ծրագիրը կախված է ամենափոքր ընթերցման եւ գրելու ուղիների համար.