הבחירה שלא באמת עוסקת בטכנולוגיה
כשארגון מתחיל לדבר על Event Driven Architecture ב-Salesforce, השיחה נוטית מהר מדי לכיוון "Platform Events או CDC?" — כאילו זו שאלת כלים. בפועל מדובר בשאלה אחרת לגמרי: איזה צד באינטגרציה הוא מקור האמת, מה מותר לו לאבד, ומי סופג את העלות כשהודעה מגיעה באיחור, כפול, או לא מגיעה כלל.
התשובה הקצרה: Change Data Capture מתאים כשמערכת חיצונית צריכה לדעת ש-Salesforce עדכן שורה, ואין צורך לעטוף את זה בלוגיקה עסקית. Platform Events מותאמים אישית מתאימים כשרוצים לפרסם אירוע עסקי בעל משמעות — "לקוח שדרג מסלול", לא "שדה Status__c השתנה". הבחירה הלא נכונה לא נראית ביום ההשקה; היא נראית כשמישהו צריך לשחזר מה קרה אחרי כשל חלקי, ומגלה שאין דרך אמינה לדעת.
מי שמחפש את התמונה הרחבה של אינטגרציות Salesforce מעבר לאירועים ימצא אותה במדריך ארכיטקטורת CRM.
שלוש שאלות שקובעות את הארכיטקטורה לפני שכותבים שורת קוד
לפני שבוחרים מנגנון, צריך תשובה לשלוש שאלות. דילוג על אחת מהן הוא הסיבה השכיחה ביותר לפרויקטי אינטגרציה שנתקעים בשלב הבדיקות.
מי הבעלים של הנתון? אם Salesforce הוא מקור האמת לרשומת הלקוח, אירועי יציאה מ-Salesforce (Platform Event או CDC) הם הכיוון הטבעי. אם מערכת ה-ERP היא הבעלים, הכיוון ההפוך נכון, ו-Salesforce צריך לצרוך אירועים ולא לפרסם אותם על אותה ישות.
מה מותר לאבד? התראה לדשבורד ניהולי יכולה לאבד הודעה בודדת בלי נזק. עדכון יתרת אשראי לפני אישור עסקה לא יכול. ההבחנה הזו קובעת אם מספיק Fire-and-Forget או שנדרש מנגנון אישור וניטור פערים (Reconciliation).
מה קורה כשההודעה מגיעה פעמיים? Platform Events מבטיחים At-Least-Once ולא Exactly-Once. אם התשובה "לא יודעים" — הפתרון עדיין לא מוכן לייצור, בלי קשר לכמה נקי הקוד.
Platform Events לעומת CDC — טבלת החלטה
| קריטריון | Platform Event מותאם | Change Data Capture |
|---|---|---|
| מה מפורסם | אירוע עסקי מוגדר (Payload מותאם) | שינוי שורה גולמי (Before/After) |
| מי בונה את הלוגיקה | מפתח Salesforce, בזמן ה-Trigger או Flow | הפלטפורמה, אוטומטית לכל DML מוגדר |
| צימוד לסכימה | נמוך — Payload נשלט על ידי המפרסם | גבוה — כל שינוי במבנה האובייקט משפיע על הצרכן |
| מתאים כש... | רוצים לפרסם כוונה עסקית ("הזמנה אושרה") | רוצים סנכרון נתונים גולמי בין מערכות |
| עלות תחזוקה | גבוהה יותר בהתחלה (בניית Payload ולוגיקה) | נמוכה בהתחלה, גבוהה כשמבנה האובייקט משתנה |
| Retention | לפי הגדרת רישיון (שעות עד ימים) | לפי הגדרת רישיון, זהה לרוב ל-Platform Events |
| נפח מומלץ | אירועי Domain בתדירות בינונית | שינויים ברמת שורה, כולל תדירות גבוהה |
הכלל המעשי: אם צרכן האירוע צריך להבין "למה" זה קרה ולא רק "מה" קרה — צריך Platform Event מותאם. אם הצרכן רק צריך עותק עדכני של הנתון — CDC חוסך שכבת פיתוח שלמה.
Ordering, Replay ו-Idempotency: שלושת המושגים שהופכים תיאוריה לייצור יציב
אלה לא נושאים לשלב מאוחר של הפרויקט — הם קובעים את מבנה הצרכן מהיום הראשון.
Ordering. Platform Events נשלחים בסדר פרסום בתוך אותו נושא, אבל עומס וכשלים חלקיים יכולים לשבש את סדר הקליטה בצד הצרכן. פתרון מעשי: לצרף לכל אירוע חותמת גרסה או Sequence Number מתוך הרשומה המקורית, ולתת לצרכן לדחות אירוע שגרסתו נמוכה מהגרסה האחרונה שכבר טופלה.
Replay. כל אירוע מקבל Replay ID. צרכן שנופל צריך לשמור את ה-Replay ID האחרון שעיבד בהצלחה — לא בזיכרון, אלא במקום עמיד (Custom Object, טבלה חיצונית) — ולהמשיך משם עם התאוששות. הסתמכות על "המערכת תתחיל מהתחלה" עובדת רק בתוך חלון ה-Retention, ומעבר לו האירועים אבודים.
Idempotency. כל צרכן צריך לזהות אירוע שכבר טופל, בדרך כלל לפי מזהה עסקה ייחודי שנשלח בתוך ה-Payload. בלי זה, Retry אוטומטי בצד השולח — או Replay ידני אחרי תקלה — הופכים לעדכון כפול, יצירת רשומה כפולה, או במקרה הגרוע חיוב כפול.
הפער הזה כמעט אף פעם לא מתגלה ב-Demo. הוא מתגלה בעומס, בכשל רשת אמיתי או בשינוי בסביבת הייצור, ואז העלות לתקן אותו כוללת כבר גם תיקון נתונים. ארגונים שנתקלים בבעיה מקבילה בשכבת האוטומציה מוצאים ניתוח משלים בחוב טכני Salesforce ב-Flow ו-Apex.
תרחיש לדוגמה: רשת קמעונאית עם 40 סניפים ומערכת מלאי נפרדת
נניח רשת קמעונאית היפותטית, "קמעונאית צפון", המפעילה Salesforce Sales Cloud מול צוותי מכירות ב-40 סניפים, ומערכת ERP נפרדת שמנהלת מלאי בזמן אמת. עד כה, כל הזמנה שנסגרה ב-Salesforce עברה ל-ERP באמצעות Job מתוזמן שרץ כל 15 דקות — פתרון שגרם לכך שנציגים ראו לפעמים מלאי לא מעודכן ואישרו הזמנות למוצר שאזל.
הצוות הארכיטקטוני בחר לפרסם Platform Event מותאם בשם Order_Confirmed__e בכל אישור הזמנה, עם Payload שכולל מזהה עסקה ייחודי, רשימת פריטים וכמויות. ה-ERP מאזין לאירוע ומעדכן מלאי תוך שניות, תוך בדיקת מזהה העסקה מול טבלת עסקאות שכבר טופלו — כדי למנוע ניכוי כפול אם האירוע יגיע פעמיים.
בנוסף, הוגדר תהליך Reconciliation לילי שמשווה בין סך ההזמנות שאושרו ב-Salesforce לסך העדכונים שנקלטו ב-ERP, ומתריע על פער מעל סף מוגדר. הסיבה: גם עם Idempotency תקין, רוצים גילוי מוקדם של תקלת רשת ממושכת ולא רק הסתמכות על כך שהאירוע "בטח הגיע". התוצאה: זמן העדכון ירד מ-15 דקות ל-פחות מדקה, ומספר אירועי המלאי השגוי ירד באופן ניתן למדידה תוך חודש מההטמעה.
התרחיש ממחיש עיקרון מרכזי: הערך לא נוצר מ"מעבר לאירועים" כשלעצמו, אלא משילוב של אירוע עסקי ברור, בדיקת כפילות בצד הצרכן, ותהליך ניטור שמזהה פער לפני שהוא הופך לתלונת לקוח.
סיכונים נפוצים ופעולות מניעה
| סיכון | איך הוא נראה בפועל | פעולת מניעה |
|---|---|---|
| פרסום אירוע על כל שינוי שדה | תקרת האירועים היומית נחצית תוך ימים ספורים | לפרסם אירועי Domain בעלי משמעות עסקית, לא אירוע טכני על כל DML |
| אין בדיקת כפילות בצד הצרכן | Retry או Replay יוצרים רשומות או עדכונים כפולים | לצרף מזהה עסקה ייחודי ולבדוק אותו לפני כל פעולה |
| הסתמכות על סדר הגעה | עדכון ישן דורס עדכון חדש יותר | לצרף חותמת גרסה ולדחות אירועים ישנים מהגרסה האחרונה שטופלה |
| אין שמירת Replay ID | אחרי נפילת הצרכן, אירועים בין הנפילה לחלון ה-Retention אבודים | לשמור Replay ID במקום עמיד ולהריץ Replay אוטומטי בעלייה מחדש |
| CDC על אובייקט שמשתנה תדיר במבנה | כל שינוי שדה שובר את הצרכן החיצוני בלי אזהרה | להגדיר חוזה נתונים מפורש ולתקשר שינויי סכימה מראש |
| אין ניטור עסקי, רק ניטור טכני | ה-Integration "ירוקה" אך מלאי או הזמנות בפועל לא תואמים | להוסיף Reconciliation יומי שמשווה תוצאה עסקית בין המערכות |
Checklist לפני שמתחילים לפתח שכבת אירועים
- ☐ לכל אירוע יש בעלים ברור: מי מפרסם ומי הבעלים העסקי של הנתון
- ☐ הוגדר Payload קבוע ומתועד, לא מבנה שמשתנה עם כל Sprint
- ☐ נבחר בין Platform Event מותאם ל-CDC לפי כוונה עסקית מול שינוי גולמי
- ☐ לכל צרכן יש מזהה עסקה ייחודי ובדיקת כפילות (Idempotency)
- ☐ מוגדר טיפול בסדר לפי חותמת גרסה, לא לפי סדר הגעה
- ☐ Replay ID נשמר במקום עמיד ותהליך התאוששות מוגדר ונבדק
- ☐ קיים ניטור עסקי (Reconciliation) בנוסף לניטור טכני של תור ההודעות
- ☐ נבדק תרחיש עומס ותרחיש כשל חלקי, לא רק Happy Path
- ☐ תקרת האירועים היומית (Publish + Delivery) נבדקה מול נפח צפוי בייצור
- ☐ הוגדר Owner תפעולי לתגובה כשמתגלה פער ב-Reconciliation
איך מודדים שהארכיטקטורה עובדת
| תחום | מה מודדים | קצב בדיקה |
|---|---|---|
| אמינות מסירה | אחוז אירועים שהושלמו בלי Retry, ואחוז שהצליחו לאחר Retry | רציף |
| פערי Reconciliation | הפרש בין רשומות שאושרו למקור לבין רשומות שנקלטו ביעד | יומי |
| Latency קצה-לקצה | זמן בין אירוע עסקי לעדכון בפועל אצל הצרכן | רציף |
| ניצול תקרת אירועים | אחוז מהמכסה היומית שנוצל בפועל | שבועי |
| כפילויות שנמנעו | מספר אירועים שזוהו ככפולים ונחסמו לפני ביצוע | שבועי |
מומלץ לבחור לא יותר משלושה עד ארבעה מדדים לגרסה הראשונה, ולמדוד אותם מול Baseline שנאסף לפני המעבר לארכיטקטורת אירועים — לא מול תחושה כללית ש"עכשיו זה מהיר יותר".
לצורך תכנון מבנה ארגוני רחב יותר של אינטגרציות מרובות, כדאי לבחון גם את דפוסי האינטגרציה של Salesforce ואת ההשלכות על ארכיטקטורת Single Org מול Multi Org, שכן החלטה על אירועים חוצה לעיתים גבולות ארגון.
סיכום
הבחירה בין Platform Events ל-CDC היא לא שאלה טכנית שנבדקת בפרק זמן קצר בתחילת פרויקט — היא קובעת מי מקור האמת, מה מותר לאבד, ואיך המערכת מתנהגת ברגע שמשהו נכשל באמצע. ארגון שמתכנן מראש Ordering, Replay ו-Idempotency, ומוסיף שכבת Reconciliation עסקית ולא רק ניטור טכני, מקבל אינטגרציה שעומדת בעומס ובכשל חלקי. ארגון שמדלג על השלבים האלה מקבל מערכת שנראית תקינה בבדיקות ונשברת בשקט בייצור, בדרך כלל בלי שאף אחד שם לב עד שהנזק כבר קרה.
ארגונים שרוצים ליווי בבניית שכבת אירועים אמינה ב-Salesforce יכולים לפנות דרך שירות ארכיטקטורת CRM.