ברוכים הבאים לפרק נוסף של Microsoft Knowledge Nuggets. אני המנחה שלכם, מירו פיטרס. אז הנה התרחיש. אתם עובדים בביזנס סנטרל וזקוקים לשינוי קטן אחד. אולי שדה נוסף ברשומת לקוח, שלב אישור שונה, או חוק שבודק הזמנה לפני שמישהו מפרסם אותה. ואז מישהו מעלה נושא של הרחבות אל, טבלאות, עמודים ויחידות קוד, ופתאום הבקשה הקטנה הזו נשמעת כמו שפה חדשה לגמרי. זו אכן שפה. ברור, אבל היא לא חייבת להרגיש מסתורית. חישבו על ביזנס סנטרל כעל בניין משרדים. אל נותנת למפתחים את ההוראות להוסיף חדר, תופס או חוק חדש מבלי לפרוץ חורים בבניין עצמו. זה הנאגת של הידע להיום. עד סוף הפרק הזה, תדעו מה פירוש פיתוח אל, מדוע הרחבות קיימות, וכיצד עבודה מותאמת אישית משתלבת בביזנס סנטרל. מדוע עסקים מבצעים התאמות אישיות בביזנס סנטרל? ביזנס סנטרל כבר מטפל בהרבה מהעבודה היומיומית, כמו פיננסים, לקוחות, הזמנות מחירה וחשבוניות מלאי, הכל במערכת מחוברת אחת במקום בערימת גיליונות אלקטרוניים וחלים נפרדים. עבור חברות רבות, ההגדרה הסטנדרטית הזו מכסה את רוב העבודה.

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

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

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

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

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

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

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

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

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

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

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

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

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

תהליך הרישום הסטנדרטי עדיין שייך ל- Business Central. ההרחבה שלך רק מוסיפה את הכלל הספציפי של החברה בנקודת החיבור הזו. לעתים קרובות תשמע שמות אירועים כמו On Before או On After. On Before אומר שהקוד שלך רץ לפני שפעולה מסתיימת. זה מושלם עבור בדיקה שיכולה למנוע את הצעד הבא. אה, כמו עצירת הזמנת מחירה אם תנאי מסוים נכשל. After אומר שהפעולה כבר התרחשה. אתה יכול להגיב לזה. צור רשומה קשורה, עד כן הערה או התחל עבודה אחרת. השמות אומרים לך את התזמון ותזמון הוא חשוב. כלל שרץ אחרי רישום לא יכול למנוע אותו. כלל שרץ מוקדם מדי עלול שלא לקבל את הנתונים הדרושים לו. לכן, מפתחים בוחרים את האירוע לפי מה שכלל העסק צריך לעשות ומתי. קוד יכול להתחיל גם מתוך פעולה. משתמש לוחץ על כפתור כמו בדוק מצב הטבע ופעולה זו קוראת להליך. קוד יכול לרוץ גם כאשר אובייקט אחד קורא לאחר דרך משתנה. זה נשמע טכני, אבל זה פשוט. חלק אחד של ההרחבה מבקש מחלק אחר לבצע עבודה. משתנים עוזרים בזה. משתנה הוא מקום בעל שם שמחזיק ערך בזמן שהקוד רץ.

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

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

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

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

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

זה יעיל. יחידת קוד התקנה מוסיפה רמות תגמול ראשוניות בפעם הראשונה שהתוסף שלכם מותקן. ומנוי אירועים, Event Subscriber, בודק את רמת התגמול שנבחרה במהלך תהליך מחירה, ומכיל את כלל החברה שלכם בדיוק ברגע הנכון. זה תוסף אחד קטן, אבל שימו לב מה הוא מכיל. טבלאות נתונים, מסקי משתמש, פעולות ניווט, לוגיקת הגדרות וכללים עסקיים הכל עובד יחד. זה הכוח האמיתי של אל. בסדר גמור, לסיכום, נקודת ההתחלה שלכם בפיתוח אל. אז הנה השורה התחתונה. פיתוח בעל מאפשר לכם להוסיף את התכונות הספציפיות שהחברה שלכם צריכה לביזנס סנטרל מבלי לגעת ביישום הליבה. ואתם לא חייבים לבנות הכל בבת אחת. התחילו עם שדה אחד, הרחבת עמוד אחת וכלל אחד ברור. זו אבן הבניין הראשונה שלכם. אם מצאתם את פיסת המידע הזו מועילה, הרשמו בפלטפורמת הפודקסטים המועדפת עליכם ושתפו אותה עם מישהו שרק מתחיל את דרכו בפיתוח ביזנס סנטרל. הצטרפו אלינו בפעם הבאה, אז נוסיף חלק נוסף לפאזל. אני מרקו פיטרס וזה היה פרק נוסף של Microsoft Knowledge Nuggets ב-M365FM.