צור תיקונים כדי לפשט עדכוני פתרון

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

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

תיקונים

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

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

  • ניתן ליצור תיקונים רק מפתרון אב באמצעות CloneAsPatchRequest אוֹ CloneAsPatch Action.

  • אב התיקון לא יכול להיות תיקון.

  • לתיקונים יכול להיות פתרון אב אחד בלבד.

  • תיקון יוצר תלות (ברמת הפתרון) בפתרון האב שלו.

  • באפשרותך להתקין תיקון רק אם פתרון האב קיים.

  • אינך יכול להתקין תיקון אלא אם כן השם הייחודי ומספר הגירסה הראשית/משנית של פתרון האב, כפי שמזוהה ב- ParentSolutionId, אינם מתאימים לאלה של פתרון האב המותקן בארגון היעד.

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

  • אם לפתרון יש תיקונים, לתיקונים הבאים מוכרח להיות מספר גירסה גבוה יותר באופן מספרי מאשר כל תיקון קיים עבור פתרון זה.

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

  • יש לייבא תיקונים המיוצאים כמנוהלים על-גבי פתרון אב מנוהל. הכלל הוא שהגנת תיקון (מנוהל או לא מנוהל) מוכרחה להתאים לאב שלו.

  • אל תשתמש בתיקונים לא מנוהלים למטרות ייצור.

  • תיקונים נתמכים רק בארגוני Dataverse בגירסה 8.0 ומעלה.

    כלי SolutionPackager ו- PackageDeployer במהדורה זו תומכים בתיקוני פתרון. עיין בעזרה המקוונת של הכלי לקבלת אפשרויות שורת פקודה הקשורות לתיקונים.

צור תיקון

צור תיקון מפתרון לא מנוהל בארגון באמצעות הודעת CloneAsPatchRequest או CloneAsPatch Action, או באמצעות יישום האינטרנט. לאחר שאתה יוצר את התיקון, הפתרון המקורי ננעל ואין אפשרות לשנות או לייצא אותו כל עוד קיימים תיקונים תלויים שקיימים בארגון ומזהים את הפתרון כפתרון האב. ניהול גירסאות של תיקון דומה לניהול גירסאות של פתרון ומצוין בתבנית הבאה: major.minor.build.release. אינך יכול לבצע שינויים בגירסאות הפתרון העיקריות או המשניות הקיימות בעת יצירת תיקון.

ייבוא וייצוא של תיקון

באפשרותך להשתמש בשירות הארגון או בממשקי ה- API שח האינטרנט, או בכלי Package Deployer כדי לייצא ולייבא תיקון. בקשות הודעת השירות של הארגון הרלוונטיות הן ImportSolutionRequest ו- ExportSolutionRequest. הפעולות הרלוונטיות עבור ממשק ה- API של האינטרנט הן ImportSolution Action וExportSolution Action.

דוגמאות תיקון

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

שם תיקון תיאור
SolutionA, גירסה 1.0 (לא מנוהל) מכיל ישותA עם 6 שדות.
SolutionA, גירסה 1.0.1.0 (לא מנוהל) מכיל ישותA עם 6 שדות (3 מעודכנים), ומוסיף ישותB עם 10 שדות.
SolutionA, גירסה 1.0.2.0 (לא מנוהל) מכיל ישותC עם 10 שדות.

תהליך הייבוא הוא כדלקמן.

  1. המפתח או האחראי על התאמה אישית מייבא תחילה את פתרון הבסיס (SolutionA 1.0) לארגון. התוצאה היא ישותA עם 6 שדות בארגון.

  2. בשלב הבא מיובא תיקון SolutionA‏ 1.0.1.0. הארגון מכיל כעת ישותA עם 6 שדות (3 עודכנו), ובנוסף ישותB עם 10 שדות.

  3. לבסוף מיובא תיקון SolutionA‏ 1.0.2.0. הארגון מכיל כעת ישותA עם 6 שדות (3 עודכנו), ישותB עם 10 שדות ובנוסף ישותC עם 10 שדות.

דוגמה נוספת לתיקון

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

שם תיקון תיאור
SolutionA, גירסה 1.0 (לא מנוהל, פתרון בסיס) מכיל את הישות Account שבה אורך השדה של מספר תיק הלקוח מותאם מ- 20 ל- 30 תווים.
SolutionB, גירסה 2.0 (לא מנוהל, ספק שונה) מכיל את הישות Account שבה אורך השדה של מספר תיק הלקוח מותאם ל- 50 תווים.
SolutionA, גירסה 1.0.1.0 (לא מנוהל, תיקון) מכיל עדכון לישות Account שבה אורך השדה של מספר תיק הלקוח מותאם ל- 35 תווים.

תהליך הייבוא הוא כדלקמן:

  1. המפתח או האחראי על התאמה אישית מייבא תחילה את פתרון הבסיס (SolutionA 1.0) לארגון. התוצאה היא ישות Account עם שדה מספר תיק לקוח של 30 תווים.

  2. SolutionB מיובא. הארגון מכיל כעת ישות Account עם שדה מספר תיק לקוח של 50 תווים.

  3. תיקון SolutionA‏ 1.0.1.0 מיובא. הארגון עדיין מכיל ישות Account עם שדה מספר תיק לקוח של 50 תווים, כפי שהוחל על-ידי SolutionB.

  4. מתבצעת הסרת התקנה של SolutionB. הארגון מכיל כעת ישות Account עם שדה מספר תיק לקוח של 35 תווים, כפי שהוחל על-ידי תיקון SolutionA‏ 1.0.1.0.

מחיקת תיקון

באפשרותך למחוק פתרון תיקון או בסיס (אב) באמצעות DeleteRequest, או עבור ה- API של האינטרנט, להשתמש בפעולת השירות HTTP DELETE. תהליך המחיקה שונה עבור פתרון מנוהל או לא מנוהל שיש בו תיקון אחד או יותר שקיימים בארגון.

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

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

עדכן פתרון

עדכון פתרון כרוך בסיכום (מיזוג) של כל התיקונים בפתרון זה לגירסה חדשה של הפתרון. לאחר מכן, נעילת הפתרון מתבטלת וניתן שוב לשנות אותו (פתרון לא מנוהל בלבד) או לייצא אותו. עבור פתרון מנוהל, אין לבצע שינויים נוספים בפתרון למעט יצירת תיקונים מהפתרון המעודכן החדש. כדי לסכם תיקונים לפתרון לא מנוהל, השתמש ב- CloneAsSolutionRequest או CloneAsSolution Action. שכפול פתרון יוצר גירסה חדשה של הפתרון הלא מנוהל, אשר משלבת את כל התיקונים שלו, עם מספר גירסה ראשית.משנית גבוה יותר, אותו שם ייחודי ושם תצוגה.

עבור פתרון מנוהל הדברים מטופלים מעט אחרת. עליך תחילה לשכפל את הפתרון הלא מנוהל (A), תוך שילוב כל התיקונים שלו ולאחר מכן ייצוא שלו כפתרון מנוהל (B). בארגון היעד שמכיל את הגירסה הלא מנוהלת של הפתרון (A) והתיקונים שלו, עליך לייבא פתרון מנוהל (B) ולאחר מכן לבצע DeleteAndPromoteRequest או DeleteAndPromote Action כדי להחליף פתרון מנוהל (A) ואת התיקונים שלו בפתרון המנוהל המשודרג (B) שהוא בעל מספר גירסה גבוה יותר.

למידע נוסף

שימוש בפתרונות מחולקים למקטעים