קליטת קו דסק ל-Dynamics: אשף שלושת-עשר הצעדים

קו דסק ל-Dynamics היא חלונית צד שנפתחת בתוך Microsoft Dynamics 365, כך שנציג שחי בתוך ה-CRM כל היום יכול לקחת שיחת קו בלי לצאת מהרשומה שהוא כבר עובד עליה. ההגעה לשם היא התהליך הרב-שלבי היחיד באמת בכל הסטודיו — בשום מקום אחר מסך לא דורש רצף, כי בשום מקום אחר אין צורך באחד. האשף הזה נוגע בארבעה שירותי צד-שרת נפרדים (Tenancy, Bridge, Registry, Connectors) בסדר קבוע, ולא יאפשר לדלג קדימה על מה שבאמת בוצע.

לפני שמתחילים

קו רושמת אפליקציית Entra רב-דיירית אחת לכל הלקוחות — לעולם לא רושמים אפליקציה משלכם. הכינו מראש: מזהה הדירקטוריון (tenant) של Entra של הלקוח בסביבת ה-Dynamics, כתובת הסביבה, ומנהל Power Platform שיכול להעניק הסכמה וליצור משתמש יישום.

שלושת-עשר הצעדים

קישור הדירקטוריון. מזינים את מזהה הדירקטוריון של הלקוח ב-Entra, בוחרים את רמת האמינות שהקישור הזה מעניק לצוות שנכנס דרכו, ואופציונלית מציינים GUID-ים של קבוצות JIT (הקמה אוטומטית) — משאירים ריק ואז כל איש צוות זקוק לקישור אישי במקום (ראו את המדריך הנפרד על תחזוקת משטח חי).
הסכמת מנהל. האשף בונה כתובת הסכמת-מנהל אמיתית של מיקרוסופט מול אפליקציית ה-Entra הפלטפורמתית של קו — שולחים אותה למנהל של הלקוח. לאחר שהוא מסכים, מדביקים כאן אסימון בדיקה מכניסה אמיתית; הפענוח נעשה בדפדפן בלבד (בלי בדיקת חתימה — זו אבחנה, לא האימות האמיתי) רק כדי לוודא שה-tid שלו תואם למה שהוזן בצעד 1.

צעדים 3 ו-4 הם הפעולות של הלקוח עצמו, מחוץ לסטודיו לגמרי — האשף רק מתעד שהן קרו.

ייבוא הפתרון המנוהל. מנהל ה-Dynamics של הלקוח מייבא את הפתרון המנוהל של קו לסביבת היעד. מאשרים עם תיבת הסימון לאחר שזה בוצע.
יצירת משתמש היישום. במרכז הניהול של Power Platform, הלקוח יוצר משתמש יישום עבור אפליקציית ה-Entra של קו ומקצה לו את התפקיד המובנה של קו. מאשרים עם תיבת הסימון.
רישום הסביבה. נותנים למשטח slug, את כתובת הסביבה, את ה-GUID של הסביבה עצמה, ואת מזהה הדירקטוריון (שנבדק מול הקישור בצעד 1), ובוחרים איפה החלונית עוגנת — חלונית צד או חלונית פרודוקטיביות. כאן גם מוסיפים את המקורות המורשים להטמיע את החלונית בכלל; משטח לא יכול להיות מופעל בהמשך עם אפס מקורות.
בדיקת חיבור. רשימת בדיקה חיה — הסכמה ניתנה, הפתרון הותקן, משתמש היישום קיים, התפקיד הוקצה — חלק מהשורות מוחזרות כ"לא ידוע" עד שתחובר בדיקה חיה מול Dataverse, ולכן הצעד הזה עדיין מסתיים באישור ידני "אימתתי את זה חיצונית" ולא במעבר אוטומטי. 7-8. רשימת טבלאות ופעולות מורשות, וקביעת התקרה. מסך אחד, שני נושאים: דרך איזה מופע מחבר המשטח קורא, אילו טבלאות Dataverse ופעולות מחבר הוא רשאי לגעת בהן (למשל kav_conversation, row-create) — ולצידן, תקרת רגישות הנתונים המרבית שהוא רשאי לכתוב (מ-Public ועד SpecialCategory) ומכסת בקשות יומית.
בדיקת מטא-דאטה. בדיקת סטייה חיה בסכימה עדיין לא חוברה גם היא, אז הצעד הזה הוא אישור ידני שהטבלה והעמודות בפועל תואמות למה שהמיפוי מצפה לו.
בניית מיפוי השדות. העורך האמיתי: כל עמודת Dataverse יעד מקבלת ביטוי מיפוי שנבנה מאוצר מילים סגור בן שמונה צמתים — קבוע, נתיב מקור, בירור ספק לפי מפתח חלופי, תרגום קבוצת אפשרויות, שרשור, קיצוץ, פורמט תאריך, או תבנית מתורגמת לפי שפה. זה מתקמפל לאותה שפת ביטויים של Scriban שכל תבנית בקשה של כל יכולת אחרת כבר משתמשת בה.
הגדרת היקף ההרשאה. מעניקים פרדיקט — יכול לפתוח את החלונית, יכול להיות מיוצג, יכול להחזיק ברשומות שנוצרו, יכול להריץ הקמה — לקבוצת דירקטוריון, תפקיד ספק, או צוות ספק. מוסיפים כמה הענקות שהפריסה דורשת לפני שממשיכים.
הדמיה. מפרש טהור ומקומי מריץ את המיפוי שלכם על נתוני דוגמה, בלי שום קריאה חיה ל-Dataverse. צומת של בירור לפי מפתח חלופי מדווח בכנות כלא-פתור כאן, כי הדמיית קריאת ספק חיה היא לא משהו שדפדפן יכול לעשות.
פרסום. מצמידים את גרסת הפתרון שיובאה בצעד 3 ומפעילים. זה הצעד היחיד שמרגיש בלתי-הפיך באשף — החלונית עולה לאוויר ברגע שמאשרים.

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