הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
Microsoft Power Platform מאפשר לכם להרחיב את הפונקציונליות של יישומי בד ציור של Power Apps באמצעות ממשקי REST API. כשמתמודדים עם אלגוריתמים מורכבים או עם מקורות נתונים רבים, העברת הלוגיקה מיישום בד ציור ל- RESTful API יכולה להיות בחירה טובה כדי לעזור לשמור על פשטות הנוסחאות שלכם בתוך יישום בד ציור של Power Apps תוך העברת פונקציונליות מורכבת יותר לצד השרת. מחברים מותאמים אישית של Power Platform מאפשרים ליישומי בד ציור להשתמש ב- REST API בדיוק כמו במקור נתונים אחר.
עצה
המאמר מספק תרחיש לדוגמה וייצוג חזותי של אופן השימוש בממשקי REST API כדי להרחיב את הפונקציונליות של יישומי בד ציור. פתרון זה הוא ארכיטקטורת תרחישים כללית לדוגמה, שניתן להשתמש בה עבור תרחישים ותעשיות רבים ושונים.
תרשים ארכיטקטורה
Workflow
- יישום בד ציור: יישום בד ציור של Power Apps משתמש במחבר מותאם אישית כדי לגשת לפעולות שנחשפו על-ידי הפונקציה Azure. המשתמש מבצע אימות ליישום באמצעות Entra ID והגישה לנתונים מוגבלת לנתונים שלמשתמש יש גישה אליהם.
- מחבר מותאם אישית: המחבר המותאם אישית מתאר באילו פעולות היישום יכול להשתמש מתוך ה- REST API שמיושם בדוגמה על-ידי פונקציה Azure. באמצעות מחבר מותאם אישית, יישום בד הציור של Power Apps מסוגל להשתמש בלוגיקה כמו בכל מקור נתונים אחר.
- אפליקציות Microsoft Entra ID פונקציית Azure מאובטחת באמצעות אפליקציית Microsoft Entra ID. אפליקציית Microsoft Entra ID שנייה נרשמת ומוגדרת במחבר המותאם אישית כדי לאפשר ליישום בד הציור של Power Apps לגשת לפעולות הפונקציה של Azure.
- הפונקציה של Azure: הפונקציה של Azure מיישמת את ה- RESTful API ומציעה פעולה אחת או יותר החשופות ליישום בד ציור של Power Apps על-ידי ייצוא מחבר מותאם אישית מפורטל Azure או על-ידי קביעת תצורה ידנית. הפונקציה של Azure מאובטחת על-ידי רישום לאפליקציית Entra ID כדי להבטיח קריאות רק מגורמים מורשים.
- Azure Cosmos DB: הפונקציה של Azure יכולה להשתמש ב- Azure Cosmos DB או ב- Azure SQL או בכל מאגר נתונים אחר בענן אחר הדרוש לה לניהול הנתונים. למעשה, הפונקציה יכולה לעבוד עם נתונים ב- Microsoft Dataverse באמצעות גישת הפונקציה בשל המורכבות של הלוגיקה.
רכיבים
- סביבת Power Platform: מכילה את משאבי Power Platform כגון Power Apps, שמיישמים את חוויית המשתמש באפליקציה בחנות. משאבים אלה מועברים מסביבה אחת לאחרת (לדוגמה, פיתוח לבדיקה) באמצעות פתרונות Dataverse.
- Power Apps: Power Apps ליישום חוויית המשתמש של הפתרון. היוצרים יכולים לבנות את היישום באמצעות המחבר המותאם אישית שנוצר על-ידי המפתח של פונקציית Azure כמקור נתונים של יישום.
- מחבר מותאם אישית: מחברים מותאמים אישית של Power Platform מתארים את הפעולות ומבני הנתונים של RESTful API. הם מאפשרים להשתמש ב- API בקלות ממשאבים כמו יישום בד ציור של Power Apps. כאשר משתמשים בהם מ- Power Apps, הם מאפשרים להפנות ל- API כמו לכל מקור נתונים אחר.
פרטי תרחיש
Power Apps מאפשרת לארגונים ליצור חוויית משתמש מותאמת אישית, ועל-ידי שימוש בממשקי REST API, הלוגיקה העסקית מרוכזת והיישום ניגש אליה באמצעות מחבר מותאם אישית. גישה זו יכולה גם לאפשר ליישום Power Apps לפעול כמשלב של שירותי קצה עורפי מרובים המספקים למשתמש תצוגה יחידה של נתונים ולוגיקה מכל המקורות. באמצעות גישת REST API, אפשר גם להחליף את המורכבות של אינטראקציה עם מערכות רבות אחרות לרכיב שמטמיע את ה- REST API ולפשט את ההטמעה של יישום בד הציור, ובו בזמן לספק את אותה חוויית משתמש.
בדוגמה למעלה, האפליקציה In Store נוצרת באמצעות יישום בד ציור של Power Apps. היישום מאפשר לנציג בחנות לשמור במהירות בקשת הודעה על הזמנת עיתוד עבור לקוח כאשר פריט אזל מהמלאי. היישום משתמש בפעולת RecordBackorder יחידה שתצורתה נקבעה על מחבר מותאם אישית המתאר פעולת פונקציית קצה עורפי של Azure. בדוגמה זו, הפונקציה של Azure היא היישום של REST API. ניתן להשתמש בכל טכנולוגיה המאפשרת יצירת שירות RESTful כדי ליישם דפוס זה.
ארכיטקטורה זו מציעה גמישות, אך משמעותה גם שנדרשת עבודת מפתח מקצועי נוספת לצורך פיתוח ותחזוקה של שירות RESTful ושכבת הנתונים. באופן כללי, ככל שמורכבות הנוסחאות של יישומי בד ציור עולה, מומלץ לשקול ארכיטקטורה מסוג זה. לדוגמה, כאשר יש צורך במקורות נתונים מרובים לבניית תצוגה יחידה, כדאי להשתמש בשכבת API כדי לספק חוויה ביצועית, משום שניתן לעצב את תגובת הנתונים בצד השרת ולספק אותה ללקוח ביעילות רבה יותר. השימוש בשכבה זו של רמת ביניים פירושו שבאפשרותך להוסיף שכבת אחסון במטמון בצד השרת ולהטמיע מדידת שימוש עשירה יותר עבור היישום.
שיקולים
שיקולים אלה מיישמים את עמודי התווך של Power Platform Well-Architected, מערכת של עקרונות מנחים המשפרים את איכות עומס העבודה. מידע נוסף: Microsoft Power Platform Well-Architected.
מהימנות
עצבו את עומס העבודה שלכם כך שימנע מורכבות מיותרת – שימוש בגישת REST API מיישום Power Apps באמצעות מחבר מותאם אישית מונע מורכבות מיותרת וגם מרכז את הלוגיקה במקום שבו יישומים אחרים בארגון יכולים להשתמש בה. המחבר המותאם אישית מאפשר ליוצר Power Apps להיות מסוגל להשתמש בפעולות מ- RESTFul API כמו כל פעולת מקור נתונים אחרת.
בדיקת גמישות וזמינות – על-ידי העברת הלוגיקה מיישום בד הציור ל- REST API, אתם אמורים להיות מסוגלים לבדוק באופן עצמאי את ה- API בנפרד מהאפליקציה שמשתמשת בו.
מדידה ופרסום של מדדי התקינות – יש ללכוד נתוני מדידת שימוש מרכיב REST API כדי לעקוב אחר תקינותו. לדוגמה, שימוש ב- Azure Monitor – רישום Application Insights יבטיח מעקב הולם אחר הרכיב.
אבטחה
יצירת פילוח והיקפים מכוונים – הקפדה על שימוש בסביבות Power Platform נפרדות לתמיכה בשלבי מחזור החיים של האפליקציה והבטחה שרק למשתמשים הנכונים יש גישה לכל שלב יכולות לתמוך במדיניות החלוקה למקטעים. חשוב גם שיישומי Entra ID הרשומים יהיו נפרדים בין הסביבות כדי לשמור על ההגנה על כל שלב בנתונים ולא לגרום לערבוב בסביבות.
מצוינות תפעולית
אימוץ שיטות פריסה בטוחות – תקננו את הפריסה של כל שינוי באפליקציית Power Apps באמצעות תהליכי פריסה אוטומטיים, כגון קווי צינור. העבירו את האפליקציה לייצור רק לאחר בדיקת שינויים.
הטמעת אסטרטגיה להפחתת כשלים בפריסה – עם התלות בין האפליקציה ל- REST API, עליכם לוודא שיש לכם אסטרטגיה בדוקה לצמצום פריסה של כל אחד מהם אם מתפתחות שגיאות לאחר העדכון של אחד הרכיבים.
יעילות ביצועים
עיצוב לעמידה בדרישות הביצועים – העריכו את ביצועי הפתרון ואת נפח דרישות הנתונים. הערכה צריכה לכלול את אופן הגישה לנתונים והערכה של האופן שבו Power Apps בשימוש ישיר במקורות נתונים שונים עשויה להיות 'פטפטנית' מדי עם מקורות הנתונים. הדבר עלול ליצור האטה בביצועים עקב ההשהיה של הבקשה הבודדת שנשלחת לכל מאגר נתונים. לדוגמה, אם האפליקציה שלכם כוללת לוגיקה שפעלה על פני מספר רב של שורות במקור הנתונים, ייתכן שתוכלו להעביר את כל תעבורת הרשת הזו לפונקציה העורפית Azure. צמצום לאינטראקציה אחת עם ה- REST API, אשר בתורו ינהל אינטראקציה עם מקורות נתונים מרובים אחרים שבהם ניתן לעשות זאת בצורה יעילה יותר.
מיטוב הלוגיקה – ככל שהלוגיקה הופכת למורכבת יותר ביישום בד ציור, פונקציות Azure או יישומי RESTful API עורפיים דומים יכולים להעביר לוגיקה זו לשירות מרכזי הניתן לשימוש חוזר. שימוש ביכולת המחבר המותאם אישית כדי לתאר ממשקי API אלה של RESTful מאפשר ליישומי בד ציור להשתמש בפעולות שתצורתן נקבעה כמו כל מקור נתונים אחר.
בדיקת ביצועים – לצד בדיקת פונקציונליות וכשלים, חשוב לבדוק ולפתח בסיס לביצועים ולהעריך אותו כחלק ממחזור ההפצה שלכם אם ה- API רגיש לשינויים בזמני השלמת העבודה.
מיטוב חוויה
עיצוב ליעילות – יישומים המאפשרים למשתמשים לגשת למקורות נתונים מרובים מיישום Power Apps יחיד בלי לדרוש מהם לקיים אינטראקציה עם יישומים נפרדים מרובים מאפשרים למשתמש להתייעל ומהווים שימוש טוב בחוויה חזותית מותאמת אישית יותר.
משתתפים
תחזוקת המאמר הזה מתבצעת על-ידי Microsoft. המחברים הבאים תרמו למאמר הזה.
מחברים ראשיים:
- Mehdi Slaoui Andaloussi, מנהל הנדסה ראשי