#אירוע לפני פעולה

#מבוא

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

אם צומת 'סיום תהליך עבודה' מופעל בתהליך העבודה שהופעל, או אם צומת אחר נכשל בביצוע (עקב שגיאה או אי-השלמה אחרת), פעולת הטופס תיוּרט. אחרת, הפעולה המיועדת תבוצע כרגיל.

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

#הגדרות טריגר

#יצירת טריגר

בעת יצירת תהליך עבודה, בחרו בסוג 'אירוע לפני פעולה':

#בחירת אוסף

בטריגר של תהליך עבודה מיירט, הדבר הראשון שיש להגדיר הוא ה אוסף המתאים לפעולה:

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

#מצב יירוט

סוגי הפעולות הנתמכים כרגע הם 'יצירה', 'עדכון' ו'מחיקה'. ניתן לבחור מספר סוגי פעולות בו-זמנית.

#הגדרות פעולה

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

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

#תנאים ליירוט

ב'אירוע לפני פעולה', קיימים שני תנאים שיגרמו ליירוט הפעולה המתאימה:

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

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

#פרמטרים קשורים לפעולה המתאימה

ב תהליך עבודה מסוג 'אירוע לפני פעולה', נתונים שונים מהטריגר יכולים לשמש כמשתנים ב תהליך עבודה עבור פעולות שונות:

#פלט הודעת תגובה

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

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

#סטטוס הודעת תגובה

אם צומת 'סיום תהליך עבודה' מוגדר לצאת עם סטטוס 'הצלחה', בקשת הפעולה עדיין תיוּרט כאשר צומת זה מבוצע, אך הודעת התגובה שתחזור תוצג עם סטטוס 'הצלחה' (במקום 'שגיאה'):

#דוגמה

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

שאר השלבים זהים לאלה שבהוראות. עם זאת, מכיוון שהזמנה אחת כוללת מספר מוצרים, בנוסף להוספת קשר רב-לרבים 'הזמנה' <-- M:1 -- 'פרטי הזמנה' -- 1:M --> 'מוצר' במודל הנתונים, עליכם גם להוסיף צומת 'לולאה' ב תהליך עבודה מסוג 'אירוע לפני פעולה', המשמש לבדיקה חוזרת אם מלאי כל מוצר מספיק:

אובייקט הלולאה נבחר כמערך 'פרטי הזמנה' מנתוני ההזמנה שנשלחו:

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

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

כפי שאתם יכולים לראות, הודעת התגובה לא ציינה שמלאי המוצר הראשון, 'iPhone 15 pro', אינו מספיק, אלא רק שמלאי המוצר השני, 'iPhone 14 pro', אינו מספיק. זאת מכיוון שבלולאה, מלאי המוצר הראשון היה מספיק, ולכן הוא לא יורט, בעוד שמלאי המוצר השני לא היה מספיק, ולכן הגשת ההזמנה יורטה.

#קריאה חיצונית

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

עבור תהליכי עבודה המקושרים מקומית לכפתור פעולה, אתם יכולים לקרוא להם כך (באמצעות כפתור היצירה של אוסף ה-posts כדוגמה):

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post."
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey"

כאשר פרמטר ה-URL triggerWorkflows הוא מפתח תהליך העבודה; מספר מפתחות תהליך עבודה מופרדים בפסיקים. ניתן לקבל מפתח זה על ידי ריחוף העכבר מעל שם תהליך העבודה בחלק העליון של קנבס תהליך העבודה:

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

אם תהליך העבודה המוגדר מגיע ל'צומת סיום', הלוגיקה זהה לזו של פעולת ממשק: הבקשה תיוּרט, ולא ייווצרו נתונים. אם סטטוס צומת הסיום מוגדר כ'נכשל', קוד סטטוס התגובה שיוחזר יהיה 400; אם 'הצליח', הוא יהיה 200.

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

{
  "errors": [
    {
      "message": "message from 'Response message' node"
    }
  ]
}

מבנה ההודעה כאשר 'צומת סיום' מוגדר להצלחה הוא:

{
  "messages": [
    {
      "message": "message from 'Response message' node"
    }
  ]
}

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

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post."
  }'
  "http://localhost:3000/api/posts:create"