בניית הלוגיקה של האימות

במסמך הזה מתוארים תהליך ליצירת מערכת לבדיקת כתובות לטיפול במגוון תגובות מ-Address Validation API. במאמר מוסבר איך לפתח את הלוגיקה כדי להשתמש בתשובה בצורה נכונה, איך לבדוק אותות אחרים מה-API, ומתי ואיך לבקש מהלקוחות מידע נוסף.

באופן כללי, התגובה מה-API קובעת את הדרכים הבאות שבהן המערכת צריכה לטפל בכתובת:

• handyman תיקון – האיכות של הכתובת נמוכה. צריך לבקש מידע נוסף.
• edit אישור – הכתובת באיכות גבוהה, אבל יש בה שינויים מכתובת הקלט. יכול להיות שתוצג בקשה לאישור.
• check אישור – הכתובת באיכות גבוהה. אפשר לאשר את הכתובת שצוינה.

מטרת המפתח

המסמך הזה יעזור לכם לשנות את המערכת כדי לנתח בצורה הטובה ביותר את התשובה מה-API ולהחליט מהן הפעולות הבאות שצריך לבצע עם הכתובות שסופקו. פסאודוקוד הבא מדגים תהליך אפשרי.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

הלוגיקה המדויקת תלויה בנסיבות שלכם – מידע נוסף זמין במדריך להטמעה. אפשר גם להשתמש בהטמעה של הלוגיקה הזו בקוד פתוח, שנמצאת בספריית הרכיבים המורחבת.

סקירה כללית של תהליך העבודה

בטבלה הבאה מפורטות שתי פעולות שאפשר לבצע במערכת:

1. תהליך העבודה שבו צריך להשתמש, בהתאם להתנהגות של תיקון, אישור וקבלה.
2. האות הראשון לבדיקה מהתגובה. האותות המתוארים כאן מגיעים מהנכס verdict, והם לא האותות היחידים שאנחנו בודקים, אבל הם מספקים אינדיקטור ראשוני לגבי איכות הכתובת. לכל סוג התנהגות יש קטע במסמך הזה שמתאר אותות נוספים שיכול להיות שצריך לבדוק.

הדרכה בנושא הטמעה

כשאתם מתכננים את התגובה של המערכת לאותות מ-Address Validation API, ההמלצות הבאות יכולות לעזור לכם ליצור מודל תגובה יעיל יותר. עם זאת, אלה רק המלצות, לכן חשוב לזכור שההטמעה צריכה להתאים למודל העסקי שלכם.

תיקון כתובת

צריך לתקן כתובת כשהתוצאות מצביעות בבירור על כך שלא ניתן לשלוח אליה חבילה. לאחר מכן, המערכת תוכל לבקש מהלקוח לספק את המידע הנדרש, ואז תוכלו להפעיל מחדש את תהליך העבודה כדי לקבל כתובת למשלוח.

תיקון האותות

ממשק Address Validation API מספק מספר אותות כדי להודיע לכם אם צריך לתקן כתובת.

1. רמת פירוט האימות והרכיבים החסרים

שני האותות האלה מספקים את האינדיקציה הטובה ביותר לכתובת בעייתית:

• בכל פעם ששדה validationGranularity הוא OTHER, המערכת צריכה לבדוק את האותות של רכיבי הכתובת כדי לקבל מידע נוסף על המיקום שבו השגיאה התרחשה ועל הדרך לתקן אותה.
• בכל פעם שאובייקט address שמעובד לאחר מכן מחזיר שדה missingComponentTypes, המערכת צריכה לבדוק אם הרכיב הזה קיים. רכיבים חסרים גם הופכים את הכתובת לחלקית ולא ניתנת למסירה.

2. אותות אחרים

ב-Address Validation API יש גם אותות אחרים שעוזרים לאבחן בעיות ספציפיות:

3. אותות של כתובות בארה"ב

שדות מסוימים שחלים רק על כתובות בארה"ב מספקים אות שימושי לכך שהכתובת לא ניתנת למשלוח וצריכה תיקון. בכתובת שצריך לתקן, יופיעו הפרטים הבאים:

פרטים על dpvConfirmation זמינים במאמר טיפול בכתובות בארה"ב.

דוגמאות לתיקון כתובות

אישור כתובת

מאשרים כתובת כשהתוצאה מציינת ש-Address Validation API הסיק או ביצע שינויים ברכיבי הכתובת כדי ליצור כתובת מאומתת. במקרים כאלה, יש לכם כתובת שאפשר לשלוח אליה, אבל אתם רוצים לוודא שהכתובת שהתקבלה היא הכתובת שהלקוח התכוון אליה.

כדי לספק ללקוח את ההנחיה הנכונה, הלוגיקה תזהה את הרכיבים שסומנו על ידי השירות כדי לקבוע איזו פעולה או תג ה-API הוחלו על הרכיב, כמו inferred,‏ replaced או spellCorrected. מידע נוסף זמין במאמר AddressComponent.

אישור האותות

ממשק Address Validation API מספק מספר אותות כדי להודיע לכם אם צריך לאשר כתובת.

1. רמת הפירוט של האימות

הערך של validationGranularity יכול להיות ROUTE או גבוה יותר, אבל הערכים 'PREMISE' או 'SUBPREMISE' מספקים אות חזק יותר לגבי יכולת המסירה.

2. אותות אחרים

כשמחליטים לאשר את כתובת הלקוח, התוצאה כוללת גם את הפרטים הבאים שיעזרו לכם לקבוע אילו רכיבים לבדוק:

3. אותות של כתובות בארה"ב

שדות מסוימים שחלים רק על כתובות בארה"ב מציינים שהלוגיקה שלכם צריכה לאשר את הפרטים עם הלקוח. אחת מהאפשרויות הבאות מתקיימת:

דוגמאות לכתובות לאישור

אישור כתובת

מאשרים כתובת כשהתוצאה מספקת רמת ודאות גבוהה שהכתובת ניתנת למשלוח ואפשר להשתמש בה בלי אינטראקציה נוספת עם הלקוח בתהליך במורד הזרם.

אישור אותות

ממשק Address Validation API מספק מספר אותות כדי להודיע לכם אם צריך לאשר כתובת.

1. רמת הפירוט של האימות

הערך של validationGranularity יכול להיות PREMISE או גבוה יותר, אבל במקרים מסוימים הערך ROUTE עדיין מציין כתובת שאפשר לשלוח אליה מוצרים.

2. אותות אחרים

חוות דעת על כתובת באיכות גבוהה צריכה לכלול גם את הפרטים הבאים:

• אין נתונים שהוחלפו. במקרה הזה, hasReplacedComponents: FALSE.
• אין רכיבים משוערים. במקרה הזה, hasInferredComponents: FALSE.

3. אותות של כתובות בארה"ב

שדות מסוימים שחלים רק על כתובות בארה"ב מציינים כתובת באיכות גבוהה שאפשר לשלוח אליה חבילות. כתובת בארה"ב שתקפה צריכה לכלול את הפרטים הבאים:

דוגמאות לכתובות לקבלה