איך לבטל בקשה אוטומטית שכבר נכנסה לתהליך עבודה

קטגוריה: AI & אוטומציה | תאריך: ספטמבר 2026

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

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

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

להפריד בין עצירה, ביטול ופעולת פיצוי

אלה שלוש פעולות שונות שחשוב להגדיר לפני בניית המסך:

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

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

למפות נקודות ביטול לאורך התהליך

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

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

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

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

בקשת ביטול אינה אישור שהבקשה בוטלה

המשתמש צריך לראות הבדל בין ״בקשת הביטול התקבלה״ לבין ״בוטל״. אפשר להגדיר מצבים כגון:

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

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

לטפל במרוץ בין ביצוע לביטול

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

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

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

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

למנוע ביטול כפול ופיצוי כפול

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

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

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

דוגמה להמחשה: ביטול בקשת ציוד

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

לפני יצירת ההזמנה: מסמנים שהביטול התקבל ומונעים מעבר לביצוע באמצעות מנגנון תיאום מקומי. רק לאחר אימות שלא נשלחה פעולת יצירה מציגים ״בוטל״.

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

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

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

להגדיר הרשאות ותיעוד לביטול

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

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

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

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

בדיקת קבלה צריכה לכלול יותר מלחיצה על הכפתור בתרחיש רגיל:

1. ביטול לפני שעובד הרקע אסף את הבקשה.
2. ביטול במקביל להתחלת ביצוע.
3. ביטול אחרי שליחת API שתוצאתו אינה ידועה.
4. שליחת אותה בקשת ביטול שוב לאחר תקלה.
5. הצלחה במערכת אחת וכשל במערכת אחרת.
6. בקשת ביטול ללא הרשאה מספקת.
7. שינוי ברשומה לאחר הביצוע המקורי ולפני הפיצוי.
8. ניסיון לבטל לאחר נקודת האל־חזור.

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

שאלות נפוצות

האם אפשר פשוט למחוק הודעה מתור העבודה?

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

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

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

מה ההבדל בין rollback לפיצוי?

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

האם כדאי להתחיל בפרויקט נפרד לכל האוטומציות?

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

להתחיל ממפת ביטול לתהליך אחד

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

Adaptico עוסקת ב[אינטגרציות ואוטומציה למערכות ארגוניות](/#services). אם בקשות ביטול אצלכם מתגלגלות בין מיילים ומסכים, אפשר [לקבוע שיחת התאמה](/#contact) ולמפות תהליך אחד, את יכולות המערכות ואת גבולות הביטול שלו לפני פיתוח.