פיתוח יישומים
יישומים Iroha צריכים להפוך את התנהגותו של העסקה לבהיר, לשמור על מצב החתימה מכוסה, ולהשתמש בשאלות ואירועים בדרכים שאפשר לצפות בקלות בהפעלה.
הגדרת הלקוח
- שמור את ההסדרות של הלקוח מחוץ לקוד המקור של האפליקציה. טעון את שרשרת ID, Torii URL, חשבון חתימה, ואת הגדרות העסקאות מההסדר הספציפי לסביבה.
- שמרו על קבצים
client.tomlבנפרד עבור רשתות מקומיות, Taira, Minamoto ורשתות פרטיות. חותם טסטנט שנעתיק אף פעם לא צריך להפוך לחותם מרכזי. - להגדיר חיי העסקה ותקופה של מצב בכוונה. תקופת חיים קצרה מאוד יכולה להסתיים תחת רדת רשת רגילה, בעוד שאחת ארוכה מאוד עשויה לגרום להגישויות כפופות להיות קשה יותר לחשוב עליהן.
- השתמש
nonce = trueרק כאשר עסקאות חוזרות על עצמה צריכות להיות בהשדים נפרדים. עבור פעולות עסקית אי-פוטנציאליות, שמור ולהשתמש מחדש בקשה של יישום ID כך שיוכלו לעקוב אחר ניסיונות חוזרים.
ראו הסדרת הלקוח עבור השדות הנוכחיים TOML.
עסקאות
- לבנות עסקאות מתוך הוראות טפוטות SDK, ככל האפשר, במקום משאבים חומריים JSON או מטענים מועילים שנאספו בחוטים.
- Preflight חשוב כותב עם שאלות קריאה בלבד: קיומו של חשבון, סולכות נכסים, מצב רשות, זמינות נכס תשלום, ומצבו אובייקט יעד.
- רשום את האש של העסקה, חשבון הסמכות, סיכום הוראות ושינוי מצב צפוי לפני הגשת.
- מתייחסו
Rejected,Expired, והתוצאות של תשעון זמן שונות. תשעון הזמן אומר שהלקוח לא ציין מצב סופי; זה אינו מוכיח כי הרשת התעלמה מהעסקה. - לאחר כתיבה מוצלחת, לאמת את המצב המוצא עם חיפוש או נקודת בדיקת אירוע שמתאימה לפעילות העסק.
עבור מכניקה של עסקאות, ראה עסקים.
שאלות ואירועים
- השתמשו בקשתות למצב הנוכחי וזרמי אירועים עבור הודעות לשינוי. הימנעו מחליפה של ניהול אירוע עם בקשות רחבות חוזרות.
- פתיח דפים על שאילות חוזרות ונשנות רחבות כגון רשימות חשבונות, נכסים ובלוקים.
- מעדיפים פילטרים צרכים עבור חיבורים ומפעילים. פילטרים רחבים הם שימושיים לדיאגנסטיקה אבל יכולים להוסיף ביצועים לא נחוצים ועיבוד בצד הלקוח.
- לשמור על בדיקות עשן קריאה בלבד נפרדות מבחני העסקה חתומים כדי שיהיה קל יותר לאבחן זמינות נקודת סוף.
ראו השאלות, התרחשויות, ו המסנן .
פיתוח עזר על ידי סוכנים
- תנו לסוכנים לבחון מסמכים, קוד SDK, ותנאי רשת קריאה בלבד לפני שתבקשו מהם לכתוב קוד עסקאות.
- שמרו על ניסויים ברשתות חיות בגין דגל סביבה כגון
TAIRA_LIVE=1. - אל תדביקו מפתחות פרטיות, חומר התאוששות חשבונות, טוקנים API או כותרות מחברים המובילות לתוך פוסטים.
- תדרוש תוכנית עסקה לפני שכל סוכן יגיש עסקאות טסטנץ חי. התוכנית צריכה לציין את הרשת, הסמכות, ההוראות, נכס הוצאות, קריאתן של מקרי הטיסה, תוצאה צפויה והתנהגות ניסיון מחדש.
עבור זרימת העבודה Taira MCP ראה בניית על SORA 3: Taira ו Minamoto.