איך להגדיר Namespace עבור Packages ב-Salesforce DX

נכתב על ידי ליאור לביא, עודכן בתאריך 21/09/2022

הערה חשובה לפני שמתחילים...

שים לב! מדריך זה עוסק ברישום Namespace ויצירת סביבות לרישום Namespace והגדרת DevHub. חלק מפעולות אלו אינן הפיכות, בעלות משמעות עסקית וחשופות ללקוחות קצה! הפעל שיקול דעת בעת רישום Namespaces וזכור שמדובר בצעד לא הפיך שעשוי להגביל אותך משימוש באותו ה-Namespace בעתיד בסביבות שאינן סביבות תרגול. הדבר נכון במיוחד עבור Namespace המכילים שם בית עסק או חברה. במקרה של ספק או אי-בהירות, מומלץ לקרוא את התיעוד הרשמי של Salesforce ומכל מקום איני לוקח אחריות על כל נזק שעשוי להיגרם לך או למקום עבודתך כתוצאה מביצוע השלבים הכתובים במדריך זה.

ועכשיו, בוא נלמד קצת על Namespace ב-Salesforce.

מה זה Namespace ומתי נרצה להשתמש בו

Namespace הוא מזהה באורך של עד 15 תוים שיתווסף כקידומת לשמות הרכיבים הכלולים בחבילה שלנו.

למידע נוסף על חבילות וגרסאות אתה מוזמן לקרוא את הפוסט "איך ליצור Package ו-Versions ב-Salesforce DX" פה בבלוג.

מה היתרונות של שימוש ב-Namespace

יצירת הבחנה בין רכיבים שלנו לבין רכיבים של חבילות אחרות מ-AppExchange.
דמיין את הסיטואציה הבאה: על סביבה שלנו מותקנות שתי חבילות, אחת שאנחנו יצרנו וה-Namespace שלה הוא MyCompany, ואחת שהתקנו מה-AppExchange, חנות האפקליקציות של Salesforce, וה-Namespace שלה הוא Acme.
שתי החבילות יוצרות שדה בשם Color על האוביייקט Account. ה-Label של השדה עשוי להיות זהה, Color, אבל ה-API Name יהיה שונה. השדה שאנחנו יצרנו יקרא MyCompany__Color__c בעוד השדה שהאפליקציה שהורדנו יצרה יקרא Acme__Color__c.
מבנה שם השדה יהיה namespace__fieldName__c.
חשיפת הקוד שלנו לחבילות אחרות שיצרנו, מבלי להפוך אותו לגלובלי.
נניח ויש לנו שתי חבילות, חבילה A וחבילה B, המשתמשות באותו ה-Namespace.
תחת חבילה A ישנה מחלקה בשם MyClass ובה מתודה בשם myMethod.
```
public class MyClass{
	public void myMethod(){
		//My cool code goes here...
	}
}
```
אם נרצה ליצור מופע של המחלקה MyClass או להריץ את המתודה myMethod מתוך חבילה B, נוכל להגדיר את המחלקה MyClass כגלובלית על ידי שינוי ה-Access modifier שלה מ-public ל-global באופן הבא:
```
global class MyClass{
	global void myMethod(){
		//My cool code goes here...
	}
}
```
הבעיה בשיטה זאת היא שהיא חושפת את המחלקה MyClass והמתודה myMethod לשימוש כל מי שיש לו גישה לקוד, כולל הלקוחות והמתחרים שלנו.
דרך טובה יותר לחשוף את הרכיבים שלנו בצורה מבוקרת, היא שימוש בסימון, annotation, מסוג @namespaceAccessible בצמידות להצהרת המחלקה והמתודה שלנו באופן הבא:
```
@namespaceAccessible
public class MyClass{
	@namespaceAccessible
	public void myMethod(){
		//My cool code goes here...
	}
}
```
סימון זה יחשוף את המחלקה MyClass והמתודה myMethod כזמינות רק עבור חבילות החולקות את אותו ה-Namespace וכך יאפשר לנו לשמור על גישה בלעדית לקוד שלנו. הדבר נכון לא רק עבור מחלקות ומתודות, אלא גם עבור משתנים, ממשקים ומחלקות אבסטרקטיות.

שיקולים משמעותיים לפני שימוש ב-Namespace

Namespace הוא ייחודי עבור כל ה-Orgs ב-Salesforce. מרגע שיצרנו Namespace עבור עצמנו, אף אחד לא יכול להשתמש בו יותר, רק אנחנו. הסיבה לכך היא ש-Namespace נועד להפוך את כל הרכיבים שלנו לייחודיים ולמנוע התנגשות עם רכיבים של מפתחים או חברות אחרות.
חשוב לשים לב לזה. אנחנו לא רוצים לבצע בדיקות ב-Trailhead ולבצע רישום של Namespace עם שם מקום העבודה שלנו, למשל, רק כדי לגלות שבטעות עכשיו ה-Namespace הזה משוייך רק ל-Developer Edition שלנו ב-Trailhead וה-DevHub שיצרנו שם.
בהקשר הזה, חשוב להכיר את ההערות של Salesforce בנושא:

Use care in deciding how to utilize namespaces. For most customers, we recommend working with no namespace or a single namespace to avoid unnecessary complexity in managing components.
If you’re test-driving unlocked packages, use a test namespace.
Use real namespaces only when you’re ready to embark on a development path headed for release in a production org.
מקור: Salesforce DX Developer Guide: Best Practices for Unlocked Packages. ההדגשה הוספה על ידי.
Choose namespaces carefully. If you’re trying out this feature or need a namespace for testing purposes, choose a disposable namespace. Don’t choose a namespace that you want to use in the future for a production org or some other real use case. Once you associate a namespace with an org, you can't change it or reuse it.
מקור: Salesforce DX Developer Guide: Link a Namespace to a Dev Hub Org. ההדגשות הוספו על ידי.
Namespace מוגדר לחבילה בעת יצירתה ולא ניתן לשינוי לאחר מכן.
ניתן לשייך מספר חבילות ל-Namespace אחד, אבל לא ניתן לשייך חבילה אחת ליותר מ-Namespace אחד.
אם אתה מתכנן לעבוד עם יותר מ-Namespace אחד, ההמלצה של Salesforce היא ליצור פרויקט SFDX אחד עבור כל Namespace.

איך ליצור Namespace חדש

על מנת ליצור Namespace חדש נזדקק לשתי סביבות Salesforce: אחת מסוג Developer Edition לרישום ה-Namespace, ואחת כ-DevHub אליה נקשר את ה-Namespace החדש שלנו.

במצב אמת, נרצה להגדיר את סביבת הייצור שלנו כ-DevHub שלנו (ראה המלצה מספר 1 כאן) ונרצה להירשם לסביבת Developer Edition ב-Salesforce כאן לרישום ה-Namespace שלנו.

עם זאת, מאחר ובשלב זה אנחנו רק מתרגלים יצירה ושימוש ב-Namespace, במקום זאת נקים שתי סביבות Trailhead ונשתמש בהן כ-DevHub ולרישום Namespace.

הצעדים אותם נבצע הם:

יצירת סביבות Trailhead עבור רישום Namespace והגדרת DevHub.
הגדרת ה-Namespace החדש שלנו באחת מסביבות ה-Trailhead שיצרנו.
הגדרת סביבת ה-Trailhead השנייה שלנו כ-DevHub וקישור שלה ל-Namespace שלנו.
יצירת פרויקט SFDX עם Lightning Web Component פשוט.
שיוך הפרויקט שלנו ל-DevHub שלנו ב-Trailhead.
יצירת חבילה חדשה עם Namespace.
יצירת גרסה ראשונה עבור החבילה שלנו.
הקמת Scretch org והתקנת הגרסה שלנו עליו לבדיקה.

יצירת סביבות Trailhead עבור רישום Namespace והגדרת DevHub

ליצירת סביבת Trailhead playground בצע את השלבים הבאים:

התחבר ל-Trailhead. אם אין לך חשבון Trailhead, לחץ כאן למדריך לפתיחת חשבון ב-Trailhead וסביבת Playground ראשונה.
לחץ על השם שלך בפינה הימנית העליונה של המסך, לצד תמונת הפרופיל שלך, ומהתפריט בחר Hands-On Orgs.
לחץ על הכפתור Create Playground.
הענק שם לסביבה החדשה, למשל Namespace DevHub, ולחץ על Create.
המתן ש-Salesforce יסיימו ליצור עבור את הסביבה. זה עשוי לקחת כמה דקות.
לאחר שהסביבה נוצרה, לחץ על כפתור ה-Launch ליד שם הסביבה כדי לפתוח אותה.
לאחר שהסביבה נפתחה, לחץ על הלשונית Get Your Login Credentials.
בלשונית Get Your Login Credentials, העתק את שם המשתמש שלך ושמור אותו בצד, אנחנו נזדקק לו בהמשך.
לחץ על הכפתור Reset My Password. בחלונית שנפתחה לחץ OK.
פתח את תיבת האימייל איתה נרשמת ל-Trailhead, פתח את האימייל שכותרתו Finish resetting your Developer Edition password.
לחץ על הקישור במייל לאיפוס סיסמה.
בלשונית הדפדפן שנפתחה, לחץ על Reset Password.
במסך Change Your Password בחר סיסמה חדשה ולחץ על הכפתור Change Password.
חזור על צעדים 13-1 ליצירת סביבת Trailhead שנייה, אלא שהפעם בסעיף 4 בחר שם אחר לסביבה, למשל Namespace Register.

הגדרת ה-Namespace החדש שלנו בסביבת ה-Trailhead החדשה שלנו

לרישום ה-Namespace החדש שלנו בצע את השלבים הבאים:

לחץ על הכפתור Launch ליד הסביבה ששמה Namespace Register ברשימת הסביבות שלנו בעמוד Hand-On Orgs ב-Trailhead.
לחץ על סמל גלגל השיניים ליד סמל הפעמון ותמונת הפרופיל שלך, ובחר Setup.
בשדה Quick Find מצד שמאל, הקלד את המילה Package ובחר בתוצאה Package Manager. בעמוד שיפתח, לצד כותרת המשנה Namespace Settings לחץ על הכפתור Edit.
אם אינך רואה את הכפתור Edit, וודא שאתה בסביבה מסוג Developer Edition, ושהיא לא מוגדרת כ-DevHub.
כדי לבדוק האם הסביבה בה אנחנו נמצאים היא מסוג Developer Edition, בצע את השלבים הבאים:
1. היכנס ל-Setup.
2. בשדה Quick Find בצד שמאל, הזן את המילה Company ובחר באופציה Company Information.
3. בעמוד שנפתח, חפש את השדה Organization Edition. וודא שהערך המופיע בו הוא Developer Edition. זה ערך ברירת המחדל עבור Trailhead playgrounds.
כדי לבדוק אם הסביבה בה אנחנו נמצאים איננה DevHub, בצע את השלבים הבאים:
1. היכנס ל-Setup.
2. בשדה Quick Find בצד שמאל, הזן את המילה DevHub ובחר באופציה DevHub מהתוצאות.
3. בעמוד שנפתח וודא שהאופציה Enable Dev Hub היא Disabled.
בחזרה ל-Package Manager בסעיף 3, לאחר שלחצנו על כפתור ה-Edit, הזן את שם ה-Test namespace שלך ולחץ על הכפתור Check Availability.
זכור! אנחנו לא רוצים לרשום Namespace ב-Trailhead playground בו נרצה להשתמש בעתיד מול לקוחות, מאחר והוא יהיה מקושר לסביבת ה-Trailhead שלנו ולא לסביבה עסקית קבועה.
לצורך הדוגמה הזאת השתמשתי ב-tns1, קיצור של Test Namespace 1.
השאר את השדה Package name כ-None ולחץ על הכפתור Review.
במסך ה-Review תוכל לראות ש-Salesforce שוב מתריעים בפנינו שמרגע ששמרנו את ה-Namespace שלנו הפעולה אינה הפיכה.
After you save your namespace, or associate a namespace with a package, you can’t make changes.
לחץ על Save.
כעת במסך ה-Package Manager יופיע לנו ה-Namespace שלנו בירוק לצד הכיתוב Namespace Prefix.
מעולה! יצרנו Namespace חדש! כעת נגדיר את סביבת ה-Trailhead השנייה שלנו כ-DevHub ונחבר אותה לסביבת ה-Namespace שלנו.

הגדרת סביבת ה-Trailhead השנייה שלנו כ-DevHub וקישור שלה ל-Namespace שלנו

להגדרת סביבת ה-Trailhead השנייה שלנו, Namespace DevHub, כסביבת DevHub וקישור שלה ל-Namespace שלנו, בצע את השלבים הבאים:

היכנס לסביבה Namespace DevHub שיצרנו דרך עמוד ה-Hands-On Orgs ב-Trailhead על ידי לחיצה על כפתור ה-Launch.
היכנס ל-Setup.
בשדה Quick Find הקלד Dev Hub ולחץ על התוצאה Dev Hub תחת Development.
בעמוד ה-Dev Hub הפעל את האופציות Enable Dev Hub ו-Enable Unlocked Packages and Second-Generation Managed Packages. שים לב! פעולות אלו הן בלתי הפיכות!
מעולה! הגדרנו את הסביבה שלנו כ-Dev Hub. השלב הבא הוא לחבר אותה לסביבת ה-Namespace שלנו. קח בחשבון שעל מנת לבצע את השלבים הבאים בסביבות שאינן Trailhead, יהיה עליך לוודא שהמשתמש איתו אתה מחובר לסביבה הוא System Administrator או בעל הרשאת Salesforce DX Namespace Registry. כמו כן, מומלץ לאפשר בדפדפן Pop-ups עבור סביבת ה-Dev Hub שלנו.
לחץ על כפתור ה-App Launcher.
בשדה Search apps and items הקלד Namespace ובחר את התוצאה Namespace Registries.
בעמוד Namespace Registries לחץ על הכפתור Link Namespace בצד ימין למעלה.
בחלונית שנפתחה הקלד את שם המשתמש והסיסמה שלך לסביבה Namespace Register שיצרנו ב-Trailhead לרישום ה-Namespace שלנו ולחץ על Log In.
בחלונית ההרשאות עבור SalesforceDX Namespace Registry הקש על הכפתור Allow.
בעמוד Namespace Registries הקש על החץ למטה לצד ה-View List בשם Recently Viewed ובחר את ה-List View All Namespace Registries.
ה-Namespace החדש שלנו יופיע ברשימה עם השדות Number, Namespace Prefix, Created Date ו-Created By.
מעולה! קישרנו את ה-Namespace שלנו לסביבת ה-Dev Hub שלנו. כעת נוכל להגדיר את ה-Namespace tns1 כ-Namespace עבור חבילות שניצור ונרשום תחת ה-Dev Hub הזה.

יצירת פרויקט חדש ב-Salesforce DX עם חבילה, גרסה ו-Namespace

ליצירת פרויקט חדש ב-Salesforce DX נעתיק פרויקט קיים מ-Bitbucket, שירות אחסון מרוחק עבור Repositories בדומה ל-GitHub.
בצע את השלבים הבאים:

פתח את Visual Studio Code.
לחץ Ctrl + Shift + P לפתיחת פלטת הפקודות.
הקלד Clone בפלטת הפקודות ולחץ על הפקודה Git:Clone או לחילופין, פתח את ה-Explorer מסרגל צד שמאל (Ctrl + Shift + E) ולחץ על הכפתור Clone Repository.

הדבק את הפקודה הבאה לפלטת הפקודות:

git clone https://LiorLavi@bitbucket.org/LiorLavi/samplehelloworldlwc.git

בחר תיקיית יעד אליה יועתק ה-Repository.
לחץ על Select Repository Location.
אם Visual Studio Code מציג הודעה מצד ימין מסוג Would you like to open the cloned repository? לחץ על Open.
המתן לטעינת ה-Extensions עבור Salesforce DX ואז לחץ על התוית No Default Org Set כדי להגדיר חיבור לסביבת ה-DevHub שלנו.
לחץ על הפקודה SFDX: Authorize an Org
בחר Production.
הקלד שם, Alias, למשל Namespace DevHub, לחץ Enter.
בחלון הדפדפן שנפתח הזן את שם המשתמש והסיסמה שלך לסביבת ה-Namespace DevHub שיצרנו ב-Trailhead ולחץ על Log in.
בחלונית Allow Access לחץ על הכפתור Allow.
חזור ל-Visual Studio Code וודא שה-Alias של הסביבה שבחרת מוצג במקום No Default Org Set.
לחץ על ה-Alias של סביבת ה-Namespace DevHub.
בפלטת הפקודות לחץ על הפקודה SFDX: Authorize a Dev Hub.
בחלון הדפדפן שנפתח הזן את שם המשתמש והסיסמה שלך לסביבת ה-Namespace DevHub שיצרנו ב-Trailhead ולחץ על Log in.
אם ה-Terminal שלך לא פתוח, לחץ על קיצור הדרך Ctrl + ~ לפתיחת ה-Terminal.

כדי לבדוק שאכן Namespace DevHub הוגדרה כסביבת ה-DevHub ברירת המחדל שלנו בפרויקט הרץ ב-Terminal את הפקודה הבאה:

sfdx force:config:get defaultdevhubusername

הפלט של הפקודה אמור להיראות בערך כך:

=== Get Config

 Name                  Value              Success 
 ───────────────────── ────────────────── ─────── 
 defaultdevhubusername Namespace DevHub   true

כעת ניצור חבילה וגרסה חדשות עם Namespace. פתח את הקובץ sfdx-project.json הנמצא בתיקית ה-Root של הפרויקט שלנו, לצד הקבצים README.md ו-package.json.

שנה את הערך בשדה namespace מ-"" ל-Namespace שיצרת. בדוגמה שלנו מדובר בערך tns1. הקובץ sfdx-project.json אמור להיראות בערך ככה:

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "name": "SampleHelloWorldLWC",
  "namespace": "tns1",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "55.0"
}

שמור את השינויים שביצעת בקובץ.
עכשיו נוכל ליצור את החבילה שלנו. הרץ את הפקודה הבאה ליצירת חבילה חדשה עם Namespace:
```
sfdx force:package:create -n MyFirstPackWithNamespace -t Unlocked -r force-app -d "My awesome first package with namespace!"
```

הרץ את הפקודה הבאה כדי לראות את רשימת ה-Packages המקושרות ל-DevHub שלנו. רק רשומה אחת אמורה להופיע ברשימה, והערך בשדה Namespace Prefix אמור להיות ה-Namespace שיצרנו.

sfdx force:package:list

הפלט של הפקודה אמור להיראות בערך כך:

=== Packages [1]
 Namespace Prefix Name                     Id                 Alias                    Description                              Type     
 ──────────────── ──────────────────────── ────────────────── ──────────────────────── ──────────────────────────────────────── ──────── 
 tns1             MyFirstPackWithNamespace 0Ho***             MyFirstPackWithNamespace My awesome first package with namespace! Unlocked

הרץ את הפקודה הבאה כדי ליצור Version חדשה לגרסה:

sfdx force:package:version:create -p MyFirstPackWithNamespace -d force-app -k test1234 --wait 10

הרץ את הפקודה הבאה כדי לראות את רשימת הגרסאות על ה-DevHub שלנו. רק גרסה אחת אמורה להופיע בה. שים לב לשדה Namespace, הוא אמור להכיל את ה-Namespace שיצרנו.

sfdx force:package:version:list

פלט הפקודה אמור להיראות בערך כך:

=== Package Versions [1]
 Package Name             Namespace Version Name Version Subscriber Package Version Id Alias                            Installation Key Released Validation Skipped Ancestor Ancestor Version Branch 
 ──────────────────────── ───────── ──────────── ─────── ───────────────────────────── ──────────────────────────────── ──────────────── ──────── ────────────────── ──────── ──────────────── ────── 
 MyFirstPackWithNamespace tns1      ver 0.1      0.1.0.1 04t***                        MyFirstPackWithNamespace@0.1.0-1 true             false    false              N/A      N/A

כעת נותר לנו ליצור Scratch org, להתקין עליו את הגרסה האחרונה שלנו ולראות שאכן ה-Namespace מופיע עבור ה-Package שלנו בסביבה.
כדי ליצור Scratch org חדש, הקלד את הפקודה הבאה ב-Terminal:
```
sfdx force:org:create -s -f config/project-scratch-def.json
```
כדי לפתוח את סביבת ה-Scratch org שיצרנו בדפדפן, הקלד את הפקודה הבאה:
```
sfdx force:org:open
```
בחלון הדפדפן שנפתח עבור ה-Scratch org שלנו, גש ל-Setup וחפש ב-Quick Find את המילה Package.
מהתוצאות, בחר ב-Installed Packages כדי לראות את רשימת החבילות המותקנות בסביבה. הרשימה Installed Packages אמורה להיות ריקה בשלב זה.
גש חזרה ל-Visual Studio Code והרץ את הפקודה הבאה ב-Terminal כדי להתקין את הגרסה שלנו ב-Scratch org:
```
sfdx force:package:install --wait 10 --publishwait 10 --package MyFirstPackWithNamespace@0.1.0-1 -k test1234 --noprompt
```
כעת כל מה שנותר לנו הוא לבדוק שהגרסה שהותקנה אכן הותקנה עם ה-Namespace החדש שלנו. פתח את ה-Scratch org וגש ל-Installed Packages מה-Quick Find ב-Setup.
וודא שהחבילה החדשה שלנו הותקנה, וה-Namespace Prefix שלנו מוגדר כ-Namespace שיצרנו.

זה הכול! יצרנו Namespace, קישרנו אותו ל-Dev Hub שלנו, יצרנו חבילה וגרסה המשתמשות בו והתקנו אותן לבדיקה על Scratch Org!