מיפוי מקורות
אילו מערכות מחזיקות אילו ישויות, ומי המקור הקובע.
אינטגרציות ומיגרציית נתונים
מערכת מרכזית לא יכולה לעבוד לבד - ולא יכולה לעבוד על מידע שאי אפשר לסמוך עליו.
אנחנו מחברים את Salesforce למערכות שהארגון כבר משתמש בהן, מגדירים חוזי ממשק ברורים, ומעבירים נתונים היסטוריים בתהליך מבוקר עם Reconciliation מלא.
Data Flow Topology
איך מידע נכנס, נשלט ומוצג
כל אינטגרציה יציבה מתחילה בהחלטה מי המקור הקובע לכל ישות. השאר — פרוטוקול, תדירות וכלי — הוא נגזרת.
Data Flow Topology
מערכות מקור
מהיכן מגיע המידע
- ERP ומערכות כספים
- אתר, טפסים וקמפיינים
- מוקד וערוצי שירות
- מערכות תפעוליות
שכבת חוזה ובקרה
מה נשלט לפני הכניסה
- חוזה ממשקשדות, פורמט, בעלות
- מפתח זיהוי ו-Idempotency
- אימות ואיכות מידע
- Retry, Logging וניטור
Salesforce וצריכה
היכן המידע הופך להחלטה
- מודל נתונים ליבה
- אוטומציה ותהליכים
- דוחות ודשבורדים
- Agentforce על מידע נשלט
סוגי מערכות
מה אפשר לחבר
- ERP
- מערכות כספים והנהלת חשבונות
- אתרי אינטרנט וטפסים
- מערכות דיוור
- מוקדי טלפוניה ו-CTI
- WhatsApp וערוצי הודעות
- מערכות שירות
- BI ו-Data Warehouse
- מערכות תפעוליות
- מערכות HR
- מערכות מסמכים וחתימה
- APIs פנימיים
- Webhooks
החיבור עצמו כמעט אף פעם אינו האתגר. האתגר הוא להחליט מי הבעלים של כל שדה, מה קורה כששתי מערכות מעדכנות אותו נתון, ואיך מזהים כשל לפני שהמשתמשים מזהים אותו.
דפוסי אינטגרציה
בוחרים לפי סבילות לכשל, לא לפי נוחות
| דפוס | מתי מתאים | דוגמה טיפוסית | מה לשים לב |
|---|---|---|---|
| Request–Reply | צריך תשובה מיידית לפני שממשיכים בתהליך | בדיקת מלאי או אשראי בזמן יצירת הזמנה | תלות ישירה בזמינות מערכת היעד |
| Fire and Forget | עדכון חשוב אך אינו חוסם את התהליך | עדכון סטטוס למערכת דיווח | צריך מנגנון Retry וניטור |
| Batch Sync | נפח גדול ורגישות נמוכה לעדכניות | סנכרון לילי של קטלוג או תמחור | פערי עדכניות בין המערכות |
| Event-Driven | כמה צרכנים לאותו אירוע עסקי | פרסום ״הזמנה אושרה״ לכמה מערכות | דורש ניהול סכמה וסדר אירועים |
| Data Virtualization | צפייה בנתון בלי להעתיק אותו | הצגת היסטוריית חיובים ממערכת חיצונית | ביצועים תלויים במקור החיצוני |
Request–Reply
- מתי מתאים
- צריך תשובה מיידית לפני שממשיכים בתהליך
- דוגמה טיפוסית
- בדיקת מלאי או אשראי בזמן יצירת הזמנה
- מה לשים לב
- תלות ישירה בזמינות מערכת היעד
Fire and Forget
- מתי מתאים
- עדכון חשוב אך אינו חוסם את התהליך
- דוגמה טיפוסית
- עדכון סטטוס למערכת דיווח
- מה לשים לב
- צריך מנגנון Retry וניטור
Batch Sync
- מתי מתאים
- נפח גדול ורגישות נמוכה לעדכניות
- דוגמה טיפוסית
- סנכרון לילי של קטלוג או תמחור
- מה לשים לב
- פערי עדכניות בין המערכות
Event-Driven
- מתי מתאים
- כמה צרכנים לאותו אירוע עסקי
- דוגמה טיפוסית
- פרסום ״הזמנה אושרה״ לכמה מערכות
- מה לשים לב
- דורש ניהול סכמה וסדר אירועים
Data Virtualization
- מתי מתאים
- צפייה בנתון בלי להעתיק אותו
- דוגמה טיפוסית
- הצגת היסטוריית חיובים ממערכת חיצונית
- מה לשים לב
- ביצועים תלויים במקור החיצוני
מיגרציית נתונים
עשרה שלבים מבוקרים
Data Profiling
מדידת שלמות, כפילות, פורמטים חריגים והיסטוריה חסרה.
כללי ניקוי
מה מתקנים אוטומטית, מה דורש הכרעה עסקית ומה לא עובר.
Mapping
שדה מול שדה, כולל טרנספורמציות וערכי ברירת מחדל.
מפתח זיהוי
מפתח עסקי ייחודי לכל ישות למניעת כפילות בטעינות חוזרות.
טעינת ניסיון
טעינה מלאה לסביבת בדיקות עם אותם היקפים.
Validation
בדיקות ספירה, סכומים ודגימות מול המקור.
Reconciliation
השוואה רשמית ורשימת פערים מאושרת.
טעינה סופית
חלון Cutover מתוכנן עם נקודת חזרה מוגדרת.
בקרה שוטפת
מדדי איכות מידע שממשיכים לרוץ אחרי העלייה לאוויר.
חיים אחרי החיבור
אינטגרציה היא מערכת שצריך לתפעל
Integration Operations Loop
- 01
ניטור
מדידת הצלחות, כשלים וזמני תגובה לכל ממשק.
- 02
התראה
כשל חוצה סף מייצר התראה לבעל תהליך מוגדר.
- 03
טיפול ותיקון
Retry מבוקר, תיקון ידני מתועד וניתוח שורש.
- 04
התאמה
עדכון חוזה הממשק או הכלל העסקי, ותיעוד השינוי.
↻ המחזור חוזר — כל סבב מזין את התעדוף של הסבב הבא
להמשיך מכאן
שירותים ומדריכים קשורים
שאלות נפוצות
אינטגרציות ודאטה — שאלות שחוזרות
מתי בוחרים אינטגרציה בזמן אמת ומתי Batch?
השאלה המכריעה היא מה קורה אם הנתון מגיע באיחור של שעה. אם ההשלכה היא החלטה שגויה מול לקוח — נדרש זמן אמת. אם ההשלכה היא דוח מעט פחות עדכני — Batch זול יותר, יציב יותר וקל יותר לתחזוקה. שילוב נפוץ הוא זמן אמת לישויות ליבה ו-Batch להשלמות ולתיקונים.
מהו חוזה ממשק ולמה הוא קריטי?
חוזה ממשק מגדיר בכתב מי המקור, אילו שדות עוברים, באיזה פורמט, מה קורה בכשל, מה מזהה רשומה כייחודית ומי אחראי לשינוי. בלעדיו כל עדכון בצד אחד שובר את הצד השני, ואף אחד לא יודע למה. זה המסמך שמונע את רוב תקלות האינטגרציה בפועל.
איך מונעים כפילויות במיגרציה?
מגדירים מפתח זיהוי עסקי לכל ישות לפני הטעינה, מריצים Data Profiling כדי לראות את היקף הכפילות האמיתי, מחליטים כלל מיזוג מפורש, ומבצעים טעינת ניסיון לסביבת בדיקות. רק אחרי שהניסיון עובר Reconciliation מלא מתבצעת הטעינה הסופית.
מה עושים כשמערכת המקור אינה אמינה?
לא מסתירים את הבעיה מאחורי אינטגרציה. קובעים מהו טווח האיכות המקובל, מסננים או מסמנים רשומות שאינן עומדות בו, ומגדירים תהליך תיקון בצד המקור. העברת מידע פגום ל-Salesforce רק מעבירה את חוסר האמון למערכת החדשה.
כמה זמן לוקחת מיגרציית נתונים?
משך המיגרציה נגזר מאיכות המקור ולא מהנפח. מיליון רשומות נקיות עם מפתח ברור מהירות בהרבה ממאה אלף רשומות עם כפילויות והיסטוריה חלקית. לכן שלב ה-Profiling נעשה מוקדם, לפני קביעת לוח זמנים.
האם צריך פלטפורמת אינטגרציה ייעודית?
לא תמיד. כשמדובר בכמה ממשקים יציבים, פתרון מבוסס API ו-Platform Events מספיק. פלטפורמה ייעודית מצדיקה את עצמה כשיש ריבוי מערכות, טרנספורמציות מורכבות, דרישות ניטור מרוכזות או צורך בשימוש חוזר בין תהליכים.
השלב הבא
תכנון אינטגרציה או מיגרציה
נמפה את המערכות, מקורות האמת ורמת האיכות הנדרשת — ונבנה תכנית שאפשר לעמוד בה.