WEBVTT

00:00:00.000 --> 00:00:02.520
ברוכים הבאים לפרק נוסף של Microsoft Knowledge Nuggets.

00:00:02.660 --> 00:00:04.400
אני המנחה שלכם, מירו פיטרס.

00:00:04.500 --> 00:00:05.480
אז הנה התרחיש.

00:00:05.660 --> 00:00:08.720
אתם עובדים בביזנס סנטרל וזקוקים לשינוי קטן אחד.

00:00:08.920 --> 00:00:11.680
אולי שדה נוסף ברשומת לקוח, שלב אישור שונה,

00:00:11.920 --> 00:00:14.480
או חוק שבודק הזמנה לפני שמישהו מפרסם אותה.

00:00:14.580 --> 00:00:18.480
ואז מישהו מעלה נושא של הרחבות אל, טבלאות, עמודים ויחידות קוד,

00:00:18.640 --> 00:00:21.640
ופתאום הבקשה הקטנה הזו נשמעת כמו שפה חדשה לגמרי.

00:00:21.820 --> 00:00:22.520
זו אכן שפה.

00:00:22.520 --> 00:00:24.560
ברור, אבל היא לא חייבת להרגיש מסתורית.

00:00:24.740 --> 00:00:27.160
חישבו על ביזנס סנטרל כעל בניין משרדים.

00:00:27.320 --> 00:00:29.860
אל נותנת למפתחים את ההוראות להוסיף חדר,

00:00:30.120 --> 00:00:32.980
תופס או חוק חדש מבלי לפרוץ חורים בבניין עצמו.

00:00:33.140 --> 00:00:34.920
זה הנאגת של הידע להיום.

00:00:35.100 --> 00:00:37.540
עד סוף הפרק הזה, תדעו מה פירוש פיתוח אל,

00:00:37.540 --> 00:00:41.680
מדוע הרחבות קיימות, וכיצד עבודה מותאמת אישית משתלבת בביזנס סנטרל.

00:00:41.820 --> 00:00:44.400
מדוע עסקים מבצעים התאמות אישיות בביזנס סנטרל?

00:00:44.520 --> 00:00:46.520
ביזנס סנטרל כבר מטפל בהרבה מהעבודה היומיומית,

00:00:46.580 --> 00:00:49.000
כמו פיננסים, לקוחות, הזמנות מחירה וחשבוניות מלאי,

00:00:49.100 --> 00:00:52.040
הכל במערכת מחוברת אחת במקום בערימת גיליונות אלקטרוניים וחלים נפרדים.

00:00:52.160 --> 00:00:55.340
עבור חברות רבות, ההגדרה הסטנדרטית הזו מכסה את רוב העבודה.

00:00:55.500 --> 00:00:56.440
אבל הנה העניין.

00:00:56.600 --> 00:00:58.480
אין שתי חברות שעובדות באותה דרך.

00:00:58.480 --> 00:01:02.600
קחו למשל מפיץ מזון הזקוק לפרטי עצבה שחברה אחרת לעולם לא משתמשת בהם.

00:01:02.600 --> 00:01:06.020
עסק שירותים הזקוק לתהליך אישור מיוחד לפני החיוב.

00:01:06.200 --> 00:01:08.500
כמעוני שרוצה דרגות תגמול להנחות.

00:01:08.680 --> 00:01:13.040
ומי שהוא אחר שזקוק לתופס עם שדות מנוסחים משלו וחוקים פנימיים.

00:01:13.460 --> 00:01:16.240
העסק לא ישנה את דרכיו בשביל שדה חסר אחד.

00:01:16.240 --> 00:01:20.500
ואתם גם לא רוצים שכל בקשה קטנה תהפוך לשינוי מסוכן במערכת כולה.

00:01:20.640 --> 00:01:22.240
זו הייתה בעיה גדולה יותר בעבר.

00:01:22.440 --> 00:01:26.580
במערכות ישנות יותר, מפתחים היו פותחים את הקוד המקורי ועורכים אותו ישירות.

00:01:26.680 --> 00:01:28.560
וזה עבד עד שהגיע העדכון הבא.

00:01:28.560 --> 00:01:31.900
ואז לחברה הייתה הגרסה החדשה של מייקרוסופט מצד אחד.

00:01:32.100 --> 00:01:33.520
והשינויים שלה מהצד השני.

00:01:33.800 --> 00:01:36.940
ומי שהוא היה צריך ליישב הכל לפני שהעדכון יכול היה להתקדם.

00:01:37.100 --> 00:01:41.420
דמיינו משרד שבו כל דייר מעביר כבלים חדשים דרך הקירות ללא תוכני.

00:01:41.420 --> 00:01:42.480
זה עובד לזמן מה.

00:01:42.720 --> 00:01:46.500
אבל כשהבניין זקוק לתיקונים, אף אחד לא יודע איזה קבל שייך למי.

00:01:46.600 --> 00:01:48.680
ביזנס סנטרל נוקט בדרך אחרת.

00:01:48.840 --> 00:01:50.900
במקום לשכתב את האפליקציה הסטנדרטית,

00:01:51.120 --> 00:01:53.180
מפתחים בונים תוסף נפרד שמתחבר אליה.

00:01:53.180 --> 00:01:59.040
שומר על החלק הסטנדרטי במקומו בעוד שהשינויים של החברה יושבים לצידו ועובדים דרך נקודות נתמכות במערכת.

00:01:59.200 --> 00:02:01.020
ההפרדה הזו חשובה כשמגיעים מדכונים.

00:02:01.240 --> 00:02:05.900
מכיוון שמייקרוסופט מעדכנת את החלק שלה בבניין בעוד שהעבודה המותאמת אישית נשארת במרחב שלה.

00:02:05.900 --> 00:02:09.340
עדיין יש בדיקות ותיקונים, בכל זאת מדובר בשינויי תוכנה.

00:02:09.560 --> 00:02:14.260
אך מהמפתח לא מצופה להעתיק ולאבד מחדש כל שינוי בתוך הקוד המקורי של מייקרוסופט.

00:02:14.360 --> 00:02:15.920
אז מה עסק באמת מתאים אישית?

00:02:15.920 --> 00:02:17.780
התאמות אישיות מוסיפות נתונים.

00:02:17.980 --> 00:02:24.140
המערכת הסטנדרטית לא מאכסנת דברים כמו הוראות משלוח, ציון סיכון פנימי, רמת חברות או קישור למערכת חיצוני.

00:02:24.280 --> 00:02:27.760
והן מוסיפות מסקים שמדריכים את הצוות דרך משימה בסדר הנכון.

00:02:27.760 --> 00:02:31.300
הן גם מוכפות כללים כמו עצירת הזמנה כשחסר מסמך נדרש.

00:02:31.420 --> 00:02:34.580
עבודה מותאמת אישית גם עוזרת לאנשים להימנע משלבים ידניים.

00:02:34.580 --> 00:02:41.440
תארו לעצמכם צוות שמעתיק נתוני לקוחות מביזנס סנטרל לכלי אחר בכל יום שישי, בודק תנאים ידנית, ואז שולח דוח למנהל.

00:02:41.600 --> 00:02:48.700
שינוי שנבנה היטב שומר את המידע בביזנס סנטרל, מיישם את הכלל בעקביות, ונותן לצוות כפתור או דף שמתאימים לעבודה היומיומית שלהם.

00:02:48.700 --> 00:02:49.900
בואו נפריך מיתוס.

00:02:50.040 --> 00:02:51.680
אתם לא רוצים להתאים אישית הכל.

00:02:51.840 --> 00:02:54.680
לביזנס סנטרל הסטנדרטי כבר יש תהליכים רבים מובנים.

00:02:54.840 --> 00:02:58.500
שינוי מה שהוא רק בגלל שהוא נראה שונה ממערכת ישנה יוצר עבודה נוספת בהמשך.

00:02:58.620 --> 00:03:01.380
אז, עבודה מותאמת אישית טובה מתחילה בסיבה עסקית ברורה.

00:03:01.560 --> 00:03:02.980
באיזו בעיה אנשים נתקלים?

00:03:03.180 --> 00:03:04.460
מה צריך לקרות במקום זה?

00:03:04.640 --> 00:03:07.040
והאם המוצר הסטנדרטי כבר יכול לעשות את זה?

00:03:07.200 --> 00:03:10.640
כשהמוצר הסטנדרטי לא עונה על הצורך הזה, אל נכנסת לתמונה.

00:03:10.640 --> 00:03:19.040
אל מתמקדת בביזנס סנטרל עצמה, קוראת, מוסיפה ומשנה רשומות ברמת מסד הנתונים, תוך שליטה במה שקורה בדפים, דוחות וחלקים אחרים של היישום.

00:03:24.680 --> 00:03:34.060
עבודה רבה לשפה אחת, אבל אל היא לא כלי כללי לכל סוג של תוכנה, ולא הייתם בוחרים בה כדי לבנות אתר קניות ציבורי, משחק מובייל או אפליקציית שולחן עבודה עצמאית.

00:03:34.240 --> 00:03:41.160
אל קיימת עבור עבודה ממוקדת אחת, עיצוב הנתונים וההתנהגות בתוך ביזנס סנטרל, כך שהמערכת תתאים לאופן שבו חברה פועלת.

00:03:41.160 --> 00:03:43.160
וזה בדיוק מה שנבחן בהמשך.

00:03:43.280 --> 00:03:45.840
אל והרחבות, מודל התוספות הבטוח.

00:03:46.400 --> 00:03:49.080
אל מייצג אפליקיישון לנגוויג' שפת יישום.

00:03:49.080 --> 00:03:57.800
זוספת התכנות של מייקרוסופט עבור ביזנס סנטרל, והיא נותנת למפתחים דרך מובנת ליצור פונקציות עסקיות חדשות או לשנות את האופן שבו חלקים קיימים במערכת מתנהגים.

00:03:57.920 --> 00:04:00.520
אבל המילה, הרחבה, חשובה בדיוק כמו אל.

00:04:00.680 --> 00:04:03.740
הרחבה היא אפליקציה נפרדת שביזנס סנטרל יכולה להתקין.

00:04:03.740 --> 00:04:08.620
היא מחזיקה את העבודה המותאמת אישית של החברה בעוד יישום הביזנס סנטרל הסטנדרטי נשאר ללא שינוי.

00:04:08.620 --> 00:04:12.320
חישבו על זה פחות כמו שכתוב של מדריך ויותר כמו הוספת דפים מאושרים אליו.

00:04:12.440 --> 00:04:15.260
אה, דפים שעוקבים אחר הכללים המקוריים מבלי למחוק אותם.

00:04:15.420 --> 00:04:19.100
זה אולי נשמע כמו פרט טכני, אבל זה משנה איך עבודה מותאמת אישית חיה לאורך זמן.

00:04:19.280 --> 00:04:22.360
תארו לעצמכם שחברת צריכה חדר משרד חדש לצוות מיוחד.

00:04:22.360 --> 00:04:26.220
הגישה הישנה הייתה פריצת קיר בבניין הראשי ושינוי המבנה עצמו.

00:04:26.220 --> 00:04:32.760
זה אולי פותר את הצורך כיום, אך תיקונים עתידיים הופכים לסיוט מכיוון שהבניין המקורי כבר לא תואם את התוכניות שלו.

00:04:32.860 --> 00:04:34.140
הרחבה עובדת אחרת.

00:04:34.360 --> 00:04:37.860
בבניין כבר יש דלתות, שיקאי חשמל וכללים להוספת מרחב.

00:04:38.000 --> 00:04:40.640
אתה בונה את החדר החדש דרך אותם חיבורים מאושרים.

00:04:40.640 --> 00:04:45.320
החדר שייך לחברה, אך הבניין הראשי עדיין יכול לקבל תחזוקה מבלי להרוס כל קרמותם אישית.

00:04:45.380 --> 00:04:47.720
כך בדיוק עובדות הרחבות של ביזנס סנטרל.

00:04:47.720 --> 00:04:51.020
יישום הבסיס מכיל את העבודה הסטנדרטית שמיקרוסופט מספקת.

00:04:51.140 --> 00:04:56.120
הרחבה יכולה להוסיף שדות, מסכים, כפתורים, חוקים, דוחות ואפילו קישורים למערכות אחרות משלה.

00:04:56.260 --> 00:05:01.880
היא יכולה להגיב כאשר פעולות עסקיות מסוימות מתרחשות, אך היא עושה זאת בדרכים נתמחות לחיבור לאיסום הסטנדרטי.

00:05:01.880 --> 00:05:04.340
לכן גבולות מובנים בתוכה. זה דבר טוב.

00:05:04.500 --> 00:05:08.760
ללא גבולות, בקשה מותאמת אישית קטנה יכולה להגיע עמוק לעזורים שהיא לא אמורה לגעת בהם.

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

00:05:16.700 --> 00:05:20.200
גישה זו גם מתאימה בצורה מושלמת לגרסת הענן של ביזנס סנטרל.

00:05:20.340 --> 00:05:22.580
מייקרוסופט מעדכנת את השירות באופן קבוע.

00:05:22.580 --> 00:05:28.040
חברה עדיין צריכה לבדוק את ההרחבה שלה לאחר שינויים, במיוחד אם היא תלויה בחלקים של המוצר שהשתנו.

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

00:05:36.420 --> 00:05:40.900
ייתכן שתשמע אנשים מזכירים את CL כשהם מדברים על מערכות דיינמיקס נב ישנות יותר.

00:05:40.900 --> 00:05:46.720
CL הגיע ממודל פיתוח מוקדם יותר שבו מפתחים שינוי לעתים קרובות את אובייקטי היישום המקוריים ישירות.

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

00:05:55.380 --> 00:05:58.460
ELL העבירה את Business Central לעבר פיתוח מבוסס אפליקציות.

00:05:58.460 --> 00:06:01.120
זה לא אומר שכל הרחבה היא גדולה או מסובכת.

00:06:01.240 --> 00:06:05.600
הרחבה אחת עשויה רק להוסיף שדה לרשומת לקוח ולהציג אותו במסך מוכר.

00:06:05.720 --> 00:06:11.640
אחרת עשויה להכיל פתרון מלא עבור סוג עסק מסוים עם רשומות, תהליכים, דפים ודוחות משלה.

00:06:11.860 --> 00:06:13.880
שתיהן עוקבות אחר אותו רעיון בסיסי.

00:06:14.020 --> 00:06:18.080
האפליקציה המותאמת אישית חיה לצד Business Central במקום להסתיר שכיתוב שלו.

00:06:18.200 --> 00:06:20.200
ניתן גם להתקין יותר מהרחבה אחת.

00:06:20.200 --> 00:06:28.020
חברה עשויה להשתמש בהרחבה משותף תוכנה עבור שכר, אחרת עבור משלוחים, והרחבה פנימית קטנה עבור חוקים שחשובים רק לאותה חברה.

00:06:28.160 --> 00:06:33.840
Business Central מאחדת אותן יחד באותה מערכת עבודה כל עוד הן עוקבות אחר כללי הפלטפורמה ואינן מתנגשות.

00:06:34.020 --> 00:06:35.900
אז, ELL היא לא רק דרך לכתוב קוד.

00:06:35.900 --> 00:06:42.400
זו השפה שמפתחים משתמשים בה כדי ליצור את אפליקציות התוסף האלה, והרחבות הן המיכל שנושא את השינויים האלה לתוך Business Central.

00:06:42.400 --> 00:06:47.580
המודל הזה מאפשר לחברה להתאים אישית את המערכת תוך שמירה על המוצר הסטנדרטי מוכר וקל יותר לתחזוקה.

00:06:47.680 --> 00:06:51.420
עכשיו בואו נפתח אחת מההרחבות האלו ונתבונן באבני הבניין שבתוכה.

00:06:51.520 --> 00:06:54.480
אבני הבניין העיקריות של ELL בתוך הרחבת ELL.

00:06:54.600 --> 00:06:56.180
מפתחים עובדים עם אובייקטים.

00:06:56.180 --> 00:07:02.720
אובייקט הוא חלק בעל שם באפליקציה עם תפקיד ברור, כמו יחסון מידע, הצגת מסך, הרצת חוק או הפקת מסמך.

00:07:02.880 --> 00:07:07.160
ברגע שרואים את התפקידים האלו בנפרד, ELL מתחילה להרגיש הרבה פחות כמו קיר של קוד.

00:07:07.300 --> 00:07:09.460
נתחיל מהמקום שבו נמצא המידע העסקי.

00:07:09.580 --> 00:07:11.860
טבלעות מאחסנות נתונים בביזנס סנטרל.

00:07:12.000 --> 00:07:15.180
חישבו על טבלה כעל ארון טיוק דיגיטלי עבור סוג אחד של רשומה.

00:07:15.300 --> 00:07:19.160
ארון אחד עשוי להכיל לקוחות אחר פריטים ואחר הזמנות מחירה.

00:07:19.160 --> 00:07:21.620
כל רשומה היא קובץ אחד בתוך אותו ארון.

00:07:21.740 --> 00:07:24.580
טבלת לקוחות מכילה רשומה אחת עבור כל לקוח.

00:07:24.720 --> 00:07:27.600
טבלת פריטים מכילה רשומה אחת עבור כל מוצר.

00:07:27.720 --> 00:07:37.020
אם החברה שלכם צריכה מידע שביזנס סנטרל הסטנדרטי לא מאחסן, הרחבה יכולה ליצור טבלה משלה, אולי לרמות תגמול, בדיקות ציוד או אישורי פרויקטים.

00:07:37.200 --> 00:07:39.900
שדות הם המקומות בעלי הטבית בתוך כל רשומה.

00:07:39.900 --> 00:07:46.740
רשומת לקוח יכולה לכלול שם, כתובת, תנאי תשלום ומספר טלפון, כיוון שטבלת הלקוחות מכילה שדות לפרטים אלו.

00:07:46.900 --> 00:07:51.900
שדות יכולים להכיל טקסט, תאריכים, סכומים, תשובות, כן או לא, או בחירה מרשימה קבועה.

00:07:52.020 --> 00:07:53.980
שדה יכול גם להצביע על רשומה אחרת.

00:07:54.140 --> 00:07:56.740
לדוגמה, לקוח יכול להכיל שדה מזהה תגמול.

00:07:56.900 --> 00:08:01.040
במקום להקליד טקסט אקראי, הצוות בוחר רמת תגמול מטבלת תגמולים נפרדת.

00:08:01.040 --> 00:08:04.500
הקישור הזה שומר על הנתונים נקיים כי כולם בוחרים מאותה רשימה מוכרת.

00:08:04.600 --> 00:08:06.200
אז, טבלעות מחזיקות את העובדות.

00:08:06.340 --> 00:08:08.300
אבל איך אנשים רואים ועובדים עם העובדות האלו?

00:08:08.400 --> 00:08:09.340
דפים, פייג'ז.

00:08:09.520 --> 00:08:11.460
דף הוא המסך שאתם פותחים בביזנס סנטרל.

00:08:11.580 --> 00:08:12.800
כרטיס הלקוח הוא דף.

00:08:12.960 --> 00:08:14.700
רשימה של הזמנות מחירה היא דף.

00:08:14.880 --> 00:08:18.100
דף שולט במה שמשתמשים יכולים לראות, להזין, לחפש ולפעול לפיו.

00:08:18.240 --> 00:08:19.960
דפים שונים מתאימים לעבודות שונות.

00:08:19.960 --> 00:08:23.940
דף כרטיס מתמקד ברשומה אחת בכל פעם, כמו לקוח אחד או פריט אחד.

00:08:24.100 --> 00:08:29.680
דף רשימה מציג רשומות רבות בשורות, מה שעובד טוב כשצריך לסרוק, לסנן או למצוא משהו במהירות.

00:08:29.900 --> 00:08:34.580
דף גיליון עבודה תומך בעבודה שבה אנשים מזינים או מאבדים כמה שורות מידע יחד.

00:08:34.700 --> 00:08:36.320
הטבלה מאכסנת את המידע.

00:08:36.440 --> 00:08:38.240
הדף מציג אותו בפני המשתמש.

00:08:38.420 --> 00:08:42.680
ההפרדה הזו מועילה כי ניתן לשנות את המסך מבלי לשנות את המקום שבו הנתונים נמצאים,

00:08:42.680 --> 00:08:47.920
או לעשות שימוש חוזר באותה טבלה ביותר מדף אחד כאשר צוותים שונים זקוקים לתצוגות שונות של אותן רשומות.

00:08:48.000 --> 00:08:51.480
עכשיו, מה אם הנתונים כבר שייכים לרשומה סטנדרטית בביזנס סנטרל?

00:08:51.600 --> 00:08:54.860
בדרך כלל לא יוצרים טבלת לקוחות חלופית רק כי צריך שדה אחד נוסף.

00:08:54.980 --> 00:08:56.980
משתמשים בהרחבת טבלה, טייבל אקסטנשון.

00:08:57.140 --> 00:09:00.180
הרחבת טבלה מוסיפה את השדה שלך לטבלת הלקוחות הקיימת.

00:09:00.180 --> 00:09:05.960
רשומת הלקוח הסטנדרטית נשארת במקומה, בעוד ההרחבה מוסיפה את פרטי החברה לצד השדות הרגילים.

00:09:06.120 --> 00:09:11.280
זה יכול להיות מזהה הטבע, הערת משלוח, מנהל חשבון, או שדה שמתחבר לחלק אחר בעסק.

00:09:11.380 --> 00:09:14.280
אך הוספת השדה לטבלה לא מציגה אותו אוטומטית על המסך.

00:09:14.440 --> 00:09:16.820
לשם כך, משתמשים בהרחבת עמוד, פייג' אקסטנשון.

00:09:17.000 --> 00:09:19.880
הרחבת עמוד מוסיפה שדה, קבוצה או פעולה לעמוד קיים.

00:09:19.880 --> 00:09:23.080
אם העסק צריך שהצוות יבחר רמת הטבע בזמן צפייה בלקוח,

00:09:23.300 --> 00:09:28.020
הרחבת העמוד יכולה להציב את שדה מזהה ההטבע בחרטיס הלקוח בדיוק איפה שהצוות כבר עובד.

00:09:28.200 --> 00:09:29.640
זה שומר על חוויה מוכרת.

00:09:29.820 --> 00:09:33.180
במקום לשלוח משתמשים למסך מותאם אישית נפרד עבור פרט פשוט,

00:09:33.400 --> 00:09:35.840
ההרחבה מוסיפה את הפרט לעמוד שהם כבר מכירים.

00:09:36.020 --> 00:09:40.560
הרחבת עמוד יכולה גם להוסיף פעולה, כפתור או פקודת תפריט שמפעילה משימה.

00:09:40.560 --> 00:09:44.880
לדוגמה, כרטיס לקוח יכול לכלול פעולת הטבות שפותחת את רשימת ההטבות.

00:09:45.040 --> 00:09:47.580
מאחורי הקלעים צריך בית לכללים העסקיים.

00:09:47.760 --> 00:09:49.360
הבית הזה הוא לרוב קודונית.

00:09:49.520 --> 00:09:53.700
קודונית מכיל פרוצדורות L, שהן קטעי קוד בעלי שם שמבצעים עבודה מסוימת.

00:09:53.880 --> 00:09:59.360
תחשבו על זה כעל צוות הבק אופיס שמטפל במשימה כשעמוד, דוח או תהליך אחר מבקשים עזרה.

00:09:59.520 --> 00:10:02.860
נניח שרמת ההטבה קובעת איזו הנחה חלה על לקוח.

00:10:02.860 --> 00:10:07.140
חישוב ההנחה שייך לקודונית לא לעמוד כרטיס הלקוח עצמו.

00:10:07.300 --> 00:10:13.240
כך תהליך מחירות, דוח או עמוד עתידי יכולים להשתמש באותו כלל בלי להעתיק אותו למקומות רבים.

00:10:13.400 --> 00:10:15.360
כלל אחד, מקום אחד לתחזוקה.

00:10:15.520 --> 00:10:18.640
ביזנס סנטרל כולל גם סוגי אובייקטים אחרים לעבודות שונות.

00:10:18.860 --> 00:10:23.040
דוחות אוספים נתונים ומציגים אותם במסמך או פריסה כמו חשבונית או דוח מחירות.

00:10:23.260 --> 00:10:25.740
שאילתות, קוויריז, שואלות שאלות ממוקדות על נתונים,

00:10:25.740 --> 00:10:28.500
למשל, אילו לקוחות הזמינו פריט מסוים בתקופה מסוימת.

00:10:28.680 --> 00:10:32.440
לדוגמה, XML Ports עוזרים להכניס נתונים או להוציא אותם בפורמט מובנה,

00:10:32.640 --> 00:10:35.540
לרוב כשמערכת אחרת צריכה להחליף מידע עם ביזנס סנטרל.

00:10:35.660 --> 00:10:39.280
חברו את החלקים הללו יחד, ותוכלו לדמיין הרחבת הטוות לקוחות קטנה.

00:10:39.420 --> 00:10:42.260
טבלת הטוות מאכסן את כל רמה ואת אחוז ההנחה שלה.

00:10:42.380 --> 00:10:45.020
עמודי הטוות מאפשרים לצוות לנהל את הרמות הללו.

00:10:45.020 --> 00:10:47.860
הרחבת טבלת לקוחות מוסיפה מזהה הטווה לכל לקוח,

00:10:48.060 --> 00:10:50.040
בעוד הרחבת עמוד כרטיס לקוח מציגה אותו.

00:10:50.160 --> 00:10:52.200
פעולת דף פותחת את רשימת התגמולים,

00:10:52.400 --> 00:10:54.380
ויחידת הקוד מחשבת את כלל ההנחה.

00:10:54.480 --> 00:10:56.820
כל אובייקט מטפל בחלק אחד של המשימה.

00:10:56.960 --> 00:10:58.800
זה הופך את התוסף לקל יותר לקריאה,

00:10:58.960 --> 00:11:02.040
לבדיקה ולשינוי כאשר הכלל העסקי משתנה כעבור חצי שנה.

00:11:02.160 --> 00:11:04.880
אך כלל עסקי צריך לעיתים קרובות לרוץ בדיוק ברגע הנכון,

00:11:05.060 --> 00:11:06.480
כמו כאשר מישהו מפרסם הזמנה.

00:11:06.480 --> 00:11:08.460
כאן נכנסים לתמונת טריגרים ואירועים.

00:11:08.580 --> 00:11:10.380
אירועים, טריגרים וכללים עסקיים.

00:11:10.560 --> 00:11:12.140
אז הוספת שדה תגמול לקוח.

00:11:12.260 --> 00:11:13.920
טוב, הנה השאלה האמיתית.

00:11:14.040 --> 00:11:16.300
מתי ביזנס סנטרל אמור להשתמש בשדה הזה בפועל?

00:11:16.400 --> 00:11:18.360
תאר לעצמך שאתה עומד לפרסם הזמנת מחירה.

00:11:18.500 --> 00:11:20.260
לפני שהמערכת יוצרת את הרישומים הסופיים,

00:11:20.440 --> 00:11:21.500
אתה רוצה בדיקה אחת נוספת.

00:11:21.660 --> 00:11:25.140
אולי הלקוח זקוק לרמת תגמול מאושרת לפני שהנחה נכנסת לתוקף.

00:11:25.140 --> 00:11:29.360
או אולי מסמך משלוח נדרש חייב להיות קיים לפני שההזמנה יכולה להתקדם.

00:11:29.500 --> 00:11:31.220
אתה רוצה את הבדיקה הזו ברגע הנכון,

00:11:31.360 --> 00:11:35.560
אבל אתה לא רוצה להעתיק את כל תהליך פרסום המחירות לתוסף שלך רק כדי להוסיף כלל אחד.

00:11:35.720 --> 00:11:38.300
התהליך הזה כבר מטפל בהרבה דברים מאחורי הקלעים.

00:11:38.480 --> 00:11:42.280
אם תעתיק אותו, התוסף שלך יהיה תקוע בתחזוקת כל השינויים העתידיים האלו.

00:11:42.400 --> 00:11:43.040
לא אידיאלי.

00:11:43.140 --> 00:11:45.760
לכן אל נותנת למפתחים כמה דרכים להריץ קוד.

00:11:45.760 --> 00:11:47.840
במה שתבחר תלוי מה צריך לקרות.

00:11:47.840 --> 00:11:49.060
ראשית, טריגרים.

00:11:49.240 --> 00:11:52.680
טריגר הוא נקודה בעלת שם בתוך אובייקט R שבו קוד יכול לרוץ.

00:11:52.820 --> 00:11:56.040
כאשר מישהו משנה ערך בשדה טבלה, הטריגר מפעיל קוד.

00:11:56.180 --> 00:11:58.780
כאשר דף נפתח או נסגר, הטריגר מפעיל קוד.

00:11:58.940 --> 00:12:01.540
דוחות, שאילתות, XML Ports, טבלאות, תוספים.

00:12:01.720 --> 00:12:04.040
אאו, לכולם יש נקודות אלו שבהן מפתח יכול להוסיף כללים.

00:12:04.200 --> 00:12:05.940
כך את שדה מזהה התגמול בלקוח.

00:12:06.100 --> 00:12:09.060
כאשר משתמש בוחר רמת תגמול, טריגר עימות יכול לרוץ.

00:12:09.060 --> 00:12:11.060
הקוד בודק, האם הלקוח חסום.

00:12:11.220 --> 00:12:12.560
האם רמת התגמול קיימת?

00:12:12.700 --> 00:12:14.360
האם שדה אחר זקוק לעדכון?

00:12:14.520 --> 00:12:18.320
הבדיקה קוראת בדיוק כשהערך משתנה, לא מאוחר יותר כשמישהו מגלה טעות.

00:12:18.460 --> 00:12:21.560
טריגרים עובדים היטב כשהכלל שייך באופן הדוק לאותו אובייקט.

00:12:21.660 --> 00:12:23.860
אך Business Central משתמשת גם באירועים.

00:12:24.000 --> 00:12:25.040
אירוע הוא כמו התראה.

00:12:25.240 --> 00:12:28.060
חלק אחד של היישום שולח אותו כשמה שהוא קורה.

00:12:28.340 --> 00:12:34.020
זה עשוי להודיע שרשומה עומדת להתווסף, שמסמך עומד להתפרסם, או שתהליך יסתיים.

00:12:34.020 --> 00:12:36.580
התוסף שלך יכול להאזין להתראה הזו.

00:12:36.680 --> 00:12:38.640
הקוד שמאזין נקרא מנוי אירועים.

00:12:38.780 --> 00:12:40.740
הוא מחכה לאירוע ספציפי בעל שם.

00:12:40.900 --> 00:12:44.440
כאשר Business Central מעלה את האירוע הזה, המנוי מריץ את ההליך שלו.

00:12:44.580 --> 00:12:46.340
התהליך הסטנדרטי נשאר בשליטה.

00:12:46.460 --> 00:12:50.760
למשל, כאשר Business Central מתחילה לפרסם הזמנת מחירה, היא מעלה אירוע לפני שהיא ממשיכה.

00:12:50.880 --> 00:12:53.100
הרחבת ההטבות שלך מקבלת את ההודעה הזו.

00:12:53.200 --> 00:12:55.860
היא בודקת את מזהה ההטבה של הלקוח ואת כלל ההנחה.

00:12:55.860 --> 00:12:59.420
לאחר מכן, היא מאפשרת לתהליך להמשיך או עוצרת אותו עם הודעה ברורה.

00:12:59.540 --> 00:13:02.580
תהליך הרישום הסטנדרטי עדיין שייך ל- Business Central.

00:13:02.780 --> 00:13:06.660
ההרחבה שלך רק מוסיפה את הכלל הספציפי של החברה בנקודת החיבור הזו.

00:13:06.800 --> 00:13:09.820
לעתים קרובות תשמע שמות אירועים כמו On Before או On After.

00:13:10.000 --> 00:13:12.820
On Before אומר שהקוד שלך רץ לפני שפעולה מסתיימת.

00:13:13.020 --> 00:13:15.580
זה מושלם עבור בדיקה שיכולה למנוע את הצעד הבא.

00:13:15.680 --> 00:13:18.560
אה, כמו עצירת הזמנת מחירה אם תנאי מסוים נכשל.

00:13:18.560 --> 00:13:20.660
After אומר שהפעולה כבר התרחשה.

00:13:20.800 --> 00:13:21.840
אתה יכול להגיב לזה.

00:13:22.000 --> 00:13:24.900
צור רשומה קשורה, עד כן הערה או התחל עבודה אחרת.

00:13:25.060 --> 00:13:27.500
השמות אומרים לך את התזמון ותזמון הוא חשוב.

00:13:27.720 --> 00:13:29.780
כלל שרץ אחרי רישום לא יכול למנוע אותו.

00:13:29.960 --> 00:13:32.900
כלל שרץ מוקדם מדי עלול שלא לקבל את הנתונים הדרושים לו.

00:13:33.020 --> 00:13:36.400
לכן, מפתחים בוחרים את האירוע לפי מה שכלל העסק צריך לעשות ומתי.

00:13:36.580 --> 00:13:38.380
קוד יכול להתחיל גם מתוך פעולה.

00:13:38.500 --> 00:13:40.000
משתמש לוחץ על כפתור כמו

00:13:40.000 --> 00:13:42.620
בדוק מצב הטבע ופעולה זו קוראת להליך.

00:13:42.620 --> 00:13:45.960
קוד יכול לרוץ גם כאשר אובייקט אחד קורא לאחר דרך משתנה.

00:13:46.120 --> 00:13:47.780
זה נשמע טכני, אבל זה פשוט.

00:13:47.980 --> 00:13:50.900
חלק אחד של ההרחבה מבקש מחלק אחר לבצע עבודה.

00:13:51.080 --> 00:13:52.160
משתנים עוזרים בזה.

00:13:52.360 --> 00:13:55.580
משתנה הוא מקום בעל שם שמחזיק ערך בזמן שהקוד רץ.

00:13:55.760 --> 00:14:00.220
זה יכול להיות מספר, טקסט, תאריך או אפילו רשומת Business Central כמו הלקוח הנוכחי.

00:14:00.380 --> 00:14:02.100
בעל, אתה מצהיר עליהם עם ור.

00:14:02.100 --> 00:14:07.300
למשל, הליך הטבעות עשוי להשתמש במשתנה שנקרא Customer כדי להחזיק את רשומת הלקוח הנוכחי.

00:14:07.300 --> 00:14:10.740
משתנה אחר שנקרא Discount% מחזיק את שיעור ההנחה.

00:14:10.860 --> 00:14:14.200
אלו אינם רשומות קבועות, אלו רק ערכי עבודה עבור אותו קטע קוד.

00:14:14.340 --> 00:14:16.160
הנה העניין לגבי איפה קוד חי.

00:14:16.340 --> 00:14:19.380
אם כלל עשוי לשמש יותר ממקום אחד, שים אותו בקודונית.

00:14:19.560 --> 00:14:26.600
בדרך זו, כרטיס הלקוח, תהליך מחירה ודוח יכולים כולם לקרוא לאותו הליך הנחה במקום שלכל אחד תהיה גרסה משלו.

00:14:26.600 --> 00:14:28.280
זה מונע בעיה מוכרת.

00:14:28.400 --> 00:14:33.900
מסך אחד מכיל עשרה אחוזים הנחה, אחר מכיל חמישה אחוזים, ואף אחד לא יודע על איזה כלל לסמוך.

00:14:33.900 --> 00:14:38.880
שמירת כללים עסקיים משותפים בקודונית אחד נותנת להרחבה המקור אחד להחלטה הזו.

00:14:38.960 --> 00:14:41.520
אז, טריגרים מטפלים בכללים קרוב לאובייקט.

00:14:41.620 --> 00:14:44.940
אירועים מאפשרים להרחבה להגיב לתהליכים של ביזנס סנטרל עצמו.

00:14:45.080 --> 00:14:47.100
קודונית שומרים לוגיקה משותפת יחד.

00:14:47.300 --> 00:14:52.760
ברגע שהחלקים האלה מתחברים, השאלה הבאה היא איפה מפתחים כותבים, בודקים ובוחנים את כל קוד העל הזה?

00:14:52.760 --> 00:14:57.640
הפיתוח בעל נעשה בדרך כלל ב-Visual Studio Code, שלעיתים קרובות נקרא VS Code.

00:14:57.800 --> 00:15:00.060
זהו מרחב העבודה שלך לכתיבת קבצי אל.

00:15:00.200 --> 00:15:01.940
הוא שומר על הסיומת של איך מאורגנת.

00:15:02.120 --> 00:15:06.500
הוא עוזר לך למצוא בעיות ושולח את האפליקציה המוכנה לסביבת ביזנס סנטרל לבדיקה.

00:15:06.600 --> 00:15:09.180
אבל VS Code, שלעצמו הוא רק עורך קוד כללי.

00:15:09.320 --> 00:15:11.540
הוא זקוק להרחבת שפת אל ממיקרוסופט.

00:15:11.700 --> 00:15:14.660
ההרחבה הזו מלמדת את VS Code איך ביזנס סנטרל עובד.

00:15:14.780 --> 00:15:17.060
הוא יכול להציע שמות של אובייקטים בזמן ההקלדה.

00:15:17.060 --> 00:15:18.800
הוא מצביע על שגיאות לפני הפרסום.

00:15:18.800 --> 00:15:20.940
הוא עוזר לך לעיין בשדות ובפרוצדורות.

00:15:21.060 --> 00:15:23.580
והוא מחבר את הפרויקט שלך לסביבת ביזנס סנטרל.

00:15:23.720 --> 00:15:24.980
זה חוסך הרבה ניחושים.

00:15:25.140 --> 00:15:29.240
כשאתה מתחיל פרויקט אל חדש, אתה יכול להריץ את הפקודה אל גו בתוך VS Code.

00:15:29.400 --> 00:15:35.760
הוא יוצר את תיקיית הפרויקט הבסיסית וקובצי הגדרות כמו שם ההרחבה, המפרסם, הגרסה ואיזו סביבת ביזנס סנטרל להשתמש.

00:15:35.940 --> 00:15:38.720
חשוב על תיקיית הפרויקט הזו כשולחן העבודה של ההרחבות.

00:15:38.720 --> 00:15:40.320
כל קובץ אל שייך לשם.

00:15:40.320 --> 00:15:44.500
קובץ אחד עשוי להכיל טבלה אחר הרחבת דף, וליחידת קוד יכול להיות קובץ משלה.

00:15:44.640 --> 00:15:49.280
כך שמי שהוא פותח את הפרויקט, הוא יכול למצוא את החלק הנכון בלי לגלול במסמך ענק אחד.

00:15:49.460 --> 00:15:52.920
כשהקוד מוכן לבדיקה, VS Code מהדר אותו לחבילת אפליקציה.

00:15:53.120 --> 00:15:55.180
זו הגרסה הניתנת להתקנה של ההרחבה.

00:15:55.380 --> 00:15:58.700
ביזנס סנטרל קורא את החבילה הזו ומוסיף את ההרחבה לסביבה.

00:15:58.700 --> 00:16:02.480
אם יש שדה חסר, שגיעת כתיב, או כל בעיה שמונעת מהאפליקציה להיבנות,

00:16:02.640 --> 00:16:05.620
VS Code מודיע לך לפני שהחבילה בכלל מגיעה לביזנס סנטרל.

00:16:05.740 --> 00:16:08.400
בדיקות צריכות להתבצע תחילה בסביבת ארגז חול, סנדבוקס.

00:16:08.520 --> 00:16:13.080
ארגז חול הוא סביבת ביזנס סנטרל נפרדת שבה ניתן לנסות שינויים בלי להסתכן בעבודה עסקית חיה.

00:16:13.080 --> 00:16:18.700
אתה מפרסם את ההרחבה, פותח את הדפים, מבצע שינויים, מזין רשומות בדיקה ובודק אם הכללים עובדים כמצופה.

00:16:28.700 --> 00:16:30.800
קוד הוא לפרסם שוב בלי להשפיע על רשומות חיות.

00:16:30.940 --> 00:16:33.440
לפעמים הקוד רץ, אבל התוצאה עדיין נראית שגויה.

00:16:33.620 --> 00:16:34.900
זה המקום שבו ניפוי שגיאות.

00:16:35.060 --> 00:16:35.860
דיבאגין עוזר.

00:16:35.980 --> 00:16:40.380
אתה מציב נקודת עצירה בקוד, מתחיל את התהליך, וההרחבה מושהת בזמן שהיא רצה.

00:16:40.380 --> 00:16:47.560
בזמן ההשאיה, אתה יכול לבדוק ערכים כמו הלקוח הנוכחי, רמת התגמול שנבחרה או אחוז ההנחה שהפרוצדורה חישבה.

00:16:47.700 --> 00:16:51.260
במקום לנחש למה כלל נכשל, אתה יכול לראות בדיוק מה הקוד קיבל.

00:16:51.260 --> 00:16:54.760
צוותי פיתוח משתמשים גם בג'יט כדי לשמור היסטוריה של עבודתם.

00:16:54.960 --> 00:16:57.440
ג'יט מתעד שינויים בקובצי הפרויקט לאורך זמן.

00:16:57.620 --> 00:17:03.540
אם מישהו משנה כלל וגורם לבעיה, הצוות יכול להשוות גרסאות, לראות מה השתנה ולבצע שחזור במידת הצורך.

00:17:03.540 --> 00:17:06.920
זה גם עוזר כאשר יותר ממפתח אחד עובד על אותו תוסף.

00:17:07.020 --> 00:17:10.040
עבור מתחילים, הדרך הטובה ביותר היא להתחיל בקטן.

00:17:10.220 --> 00:17:14.200
לימדו תחילה את דרככם בביזנס סנטרל, ואז צרו טבלה אחת ועמוד אחד.

00:17:14.200 --> 00:17:20.420
לאחר מכן, הרחיבו עמוד סטנדרטי, הוסיפו כלל עסקי פשוט, ולימדו כיצד אירועים ונתוני התקנה משתלבים בפרויקט.

00:17:20.560 --> 00:17:25.660
בהמשך, בואו נחבר את החלקים הללו באמצעות תוסף קטן שעסק יכול באמת להשתמש בו.

00:17:26.340 --> 00:17:29.480
דוגמה פשוטה, בניית תוסף תגמולי לקוחות.

00:17:30.200 --> 00:17:32.340
איך נראה תוסף אל אמיתי במציאות?

00:17:32.740 --> 00:17:34.280
בואו נצלול לדוגמה פשוטה.

00:17:34.420 --> 00:17:38.720
דמיינו שהחברה שלכם רוצה רמות תגמול ללקוחות, שלכל אחת מהן הנחה משלה.

00:17:38.720 --> 00:17:40.780
מתחילים ביצירת תבלת תגמולים.

00:17:40.920 --> 00:17:45.820
חישבו על זה כעל ארון טיוק דיגיטלי שבו כל קובץ מכיל מזהה תיאור ואחוז הנחה.

00:17:45.980 --> 00:17:51.320
זהב מקבל עשרה אחוזים הנחה, לדוגמה, הצוות שלכם צריך לנהל את הרמות הללו מבלי לגעת בחלים טכניים.

00:17:51.440 --> 00:17:56.640
לכן מוסיפים שני עמודים, עמוד רשימת תגמולים כדי לראות את כל הרמות, ועמוד כרטיס תגמול כדי לערוך או ליצור רמה.

00:17:56.640 --> 00:18:01.840
הם יכולים להוסיף רמה חדשה, להתאים אחוזים או לזכור את הקיים מבלי לפתוח סביבת פיתוח כלשהי.

00:18:01.900 --> 00:18:05.520
לאחר מכן מרחיבים את טבלת הלקוחות עם שדה חדש בשם מזהה תגמול.

00:18:05.660 --> 00:18:12.060
השדה הזה מקשר כל לקוח לרשומת תגמול אחת, ואתם מציבים את השדה הזה ישירות בעמוד כרטיס הלקוח, שם הצוות כבר מנהל פרטי לקוחות.

00:18:12.220 --> 00:18:16.560
לאחר מכן מוסיפים פעולת תגמולים כדי שיוכלו לפתוח את רשימת התגמולים ישירות מאותו כרטיס.

00:18:16.560 --> 00:18:19.620
כלל ההנחה עצמו נמצא בתוך יחידת קוד, קודונית.

00:18:19.740 --> 00:18:25.480
כשבתהליך אחר נדרשת הנחת לקוח, הוא קורא ליחידת הקוד הזו במקום לחשב אותה שוב ושוב בכל עמוד.

00:18:25.660 --> 00:18:26.200
זה יעיל.

00:18:26.380 --> 00:18:30.440
יחידת קוד התקנה מוסיפה רמות תגמול ראשוניות בפעם הראשונה שהתוסף שלכם מותקן.

00:18:30.580 --> 00:18:36.940
ומנוי אירועים, Event Subscriber, בודק את רמת התגמול שנבחרה במהלך תהליך מחירה, ומכיל את כלל החברה שלכם בדיוק ברגע הנכון.

00:18:36.940 --> 00:18:39.560
זה תוסף אחד קטן, אבל שימו לב מה הוא מכיל.

00:18:39.560 --> 00:18:44.500
טבלאות נתונים, מסקי משתמש, פעולות ניווט, לוגיקת הגדרות וכללים עסקיים הכל עובד יחד.

00:18:44.660 --> 00:18:46.060
זה הכוח האמיתי של אל.

00:18:46.220 --> 00:18:49.440
בסדר גמור, לסיכום, נקודת ההתחלה שלכם בפיתוח אל.

00:18:49.560 --> 00:18:50.800
אז הנה השורה התחתונה.

00:18:50.920 --> 00:18:56.920
פיתוח בעל מאפשר לכם להוסיף את התכונות הספציפיות שהחברה שלכם צריכה לביזנס סנטרל מבלי לגעת ביישום הליבה.

00:18:57.040 --> 00:18:58.980
ואתם לא חייבים לבנות הכל בבת אחת.

00:18:59.120 --> 00:19:02.200
התחילו עם שדה אחד, הרחבת עמוד אחת וכלל אחד ברור.

00:19:02.200 --> 00:19:04.080
זו אבן הבניין הראשונה שלכם.

00:19:04.200 --> 00:19:10.740
אם מצאתם את פיסת המידע הזו מועילה, הרשמו בפלטפורמת הפודקסטים המועדפת עליכם ושתפו אותה עם מישהו שרק מתחיל את דרכו בפיתוח ביזנס סנטרל.

00:19:10.860 --> 00:19:13.660
הצטרפו אלינו בפעם הבאה, אז נוסיף חלק נוסף לפאזל.

00:19:13.800 --> 00:19:19.460
אני מרקו פיטרס וזה היה פרק נוסף של Microsoft Knowledge Nuggets ב-M365FM.