Power BI על פריוריטי וחשבשבת: איך מחברים את הנתונים ושומרים עליהם מעודכנים

יש שני מסלולים מתועדים להכניס נתונים מפריוריטי ל-Power BI: ה-REST API של פריוריטי, שהוא שירות OData שהמחבר OData Feed של Power BI יודע לקרוא, ודרייבר ה-ODBC של פריוריטי, שמציג את הטפסים כטבלאות SQL. בחשבשבת השולחנית מדובר בדרך כלל בייצוא מתוזמן או בקריאה בלבד מבסיס הנתונים, ו-WizCloud מוציאה נתונים רק דרך דוחות שמעצבים מראש.

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

איזה מסלול מתאים להתקנת הפריוריטי שלכם?

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

אם מודול ה-ODBC כבר ברישיון, הוא בדרך כלל המסלול הפשוט יותר לטבלאות גדולות, כי המחבר ODBC של Power BI מקבל שאילתת SQL. ה-REST API הוא המסלול כשאין רישיון ODBC, או כשאותו משתמש API כבר משרת ממשקים אחרים.

קריאת ה-REST API של פריוריטי כ-OData feed

ה-REST API של פריוריטי מבוסס על פרוטוקול OData, ולכן המחבר OData Feed של Power BI קורא אותו בלי קוד מיוחד. כתובת השורש של השירות בנויה כך: https://<server>/odata/Priority/<tabula.ini>/<environment>, כשה-environment הוא השם הפנימי של החברה ולא שם התצוגה שלה. מנהל המערכת של פריוריטי יכול להפיק את הכתובת המדויקת בתוכנית Send Program Activation Link. המלכודות בכתובת הזו מפורטות במדריך לשגיאות של ה-REST API של פריוריטי.

• כל שאילתה מול טופס אחד, למשל ORDERS או LOGPART, ולא מול כתובת השורש, ומצמצמים אותה עם $filter. הדוגמה של פריוריטי עצמה היא LOGPART?$filter=FAMILYNAME eq '001'.
• טפסים גדולים קוראים בעמודים עם $top ו-$skip, שפריוריטי מתעדת בדיוק לשם כך.
• קודם קוראים את $metadata. טפסים ושדות מותאמים שונים מהתקנה להתקנה, ולכן שמות שדות מדוח של חברה אחרת לא יתאימו אצלכם.
• מסמנים Skip Test Connection כשמגדירים רענון בשירות של Power BI לכתובת שיש בה פרמטרים של שאילתה. התיעוד של מיקרוסופט מסביר שהשירות בודק את פרטי ההתחברות ומתעלם מהפרמטרים האלה.
• בוחרים שיטת אימות לפני שבונים. Basic עובד עם משתמש פעיל בפריוריטי שיש לו רישיון API, טוקנים אישיים (PAT) קיימים מגרסה 19.1, ו-OAuth2 דורש את מודול External ID. ברגע ש-External ID מופעל, Basic מפסיק לעבוד.

בפריוריטי בענן ה-API מוגבל ברמת הדייר: 100 קריאות בדקה למשתמש, עד 10 בקשות מטופלות במקביל ועוד 5 בתור, וכל בקשה שנמשכת יותר מ-3 דקות נזרקת. קריאה שנחסמה מקבלת HTTP 429. רענון שעובר על תריסר טפסים גדולים בעמודים קטנים מגיע למספרים האלה מהר, וזו הסיבה המעשית לסנן כל שאילתה לטווח התאריכים שהדוח מציג.

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

דרייבר ה-ODBC של פריוריטי: טפסים כטבלאות SQL

דרייבר ה-ODBC של פריוריטי מאפשר לכלי חיצוני לתשאל את פריוריטי ב-SQL. הוא לא פותח את בסיס הנתונים עצמו, MSSQL או Oracle, אלא מציג את אותם נתונים שהטפסים מראים בממשק, טבלה לכל טופס.

• כל חברה בפריוריטי היא בסיס נתונים נפרד שנקרא על שם השם הפנימי שלה, ולכן דוח על שתי חברות דורש שני חיבורים.
• לתת-טופס ניגשים דרך טופס האב, למשל ORDERS_sep_ORDERITEMS. שאילתה על ORDERITEMS לבד מחזירה שגיאה.
• רק טפסים שמופיעים בטופס Define ODBC Forms חשופים, והמשתמש המתחבר רואה רק את מה שהוא רואה בממשק.
• התוצאות מוגבלות לפי קבוע המערכת MAXFORMLINES, שברירת המחדל שלו 10,000. פריוריטי ממליצה לעבוד בעמודים במקום להגדיל את התקרה.
• בהתקנה מקומית הדרייבר דורש תיקיית BIN95 מגרסה 22.1.21 ואילך והתקנה מחדש של שרת האפליקציה; לקוחות ענן מדלגים על השלבים האלה.

מכיוון שחיבור ה-ODBC מוגדר ב-ODBC Data Source Administrator של Windows, רענון מתוזמן בשירות של Power BI עובר דרך on-premises data gateway שמותקן על מחשב שיש בו את הדרייבר.

מה האפשרויות מול חשבשבת ו-WizCloud?

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

WizCloud, חשבשבת בענן, עובדת אחרת. נקודת הקצה ExportDataApi/exportData לא מקבלת שאילתה; היא מריצה דוח שמעצבים קודם במחולל הדוחות של WizCloud ומייצאים באפשרות External. האימות עובר דרך createSession, שמחזיר wizAuthToken בתוקף ל-24 שעות. הפרטים נמצאים במדריך להוצאת דוחות מ-WizCloud דרך ה-API.

התהליך הדו-שלבי הזה לא מתאים ל-Power BI. מיקרוסופט מציינת שהשירות בדרך כלל לא יכול לרענן מקור נתונים דינמי, שפרטי החיבור שלו מחושבים בזמן הריצה, למעט חריגים צרים כמו האפשרויות RelativePath ו-Query של Web.Contents. מה שעובד בפועל הוא משימה מתוזמנת קטנה שקוראת ל-exportData, מתייחסת ל-Data not found כיום בלי תנועות ולא כתקלה, וכותבת את השורות לבסיס נתונים או לקובץ ש-Power BI קורא.

כמה פעמים ביום Power BI מרענן, ומתי צריך gateway?

מודל סמנטי בסביבת עבודה ברישיון Pro (קיבולת משותפת) מוגבל ל-8 רענונים מתוזמנים ביום. בקיבולת Premium, ב-Premium Per User או בקיבולת Fabric המגבלה היא 48. נכון לספטמבר 2026, דף התמחור האמריקאי של מיקרוסופט מציג את Power BI Pro ב-כ-40 ₪ ואת Premium Per User ב-כ-70 ₪ למשתמש לחודש, בתשלום שנתי.

• המכסה היומית מתאפסת ב-00:01 לפי אזור הזמן שנבחר בהגדרות המודל הסמנטי, ולכן כדאי לקבוע שעון ישראל לפני שמגדירים את השעות.
• השירות מכוון להתחיל רענון בתוך 15 דקות מהמועד שנקבע, וכשחסרים משאבים ההתחלה יכולה להתעכב עד שעה.
• רענון מתוזמן מושהה אחרי חודשיים שבהם אף אחד לא פתח דוח שבנוי על המודל.
• מודל סמנטי משתמש בחיבור gateway אחד. כששאילתה אחת ממזגת מקור מקומי עם מקור בענן, גם המקור בענן נקרא דרך ה-gateway.

ה-on-premises data gateway מגיע במצב standard, לחיבורים משותפים ולאשכולות, ובמצב personal, למשתמש אחד שמרענן את המודלים שלו. לדוח חברה שבנוי על פריוריטי או על חשבשבת, מצב standard על שרת שנשאר דולק הוא זה ששורד החלפת עובד.

עברית וימין-לשמאל בדוח

השירות של Power BI זמין בעברית, אבל Power BI Desktop זמין באותן שפות חוץ מעברית וערבית, ו-Desktop לא תומך בשפות מימין לשמאל. בתוך הדוחות, פריסת הוויזואלים לא משתנה בשפה מימין לשמאל כמו עברית. בפועל אתם בונים את סדר הקריאה מימין לשמאל בעצמכם: סלייסרים והמדד המרכזי בצד ימין, וטבלאות שהעמודה הראשונה בהן היא זו שקורא עברית מסתכל עליה קודם. את שדות הטקסט בעברית מפריוריטי, כמו תיאורי פריטים, כדאי לבדוק בוויזואלים עצמם לפני הפרסום.

מה משתבש, ואיך מגלים

• דוח מתחיל ליפול עם HTTP 429 אחרי שהוסיפו לו עמודים, כי הרענון חוצה עכשיו את המגבלה לדקה של פריוריטי בענן.
• טבלת ODBC נעצרת בשקט ב-10,000 שורות, וזה מתגלה כסכומים נמוכים מדי ולא כשגיאה.
• מישהו עורך דוח ב-WizCloud דרך הממשק, והייצוא השמור מתחיל להחזיר Params not found or not match.
• אף אחד לא פותח את הדוח בתקופה שקטה, הרענון המתוזמן מושהה, והמייל שנשלח לבעלים לא נקרא.

מקורות

• Priority Developer Portal - REST API: כתובת שורש, מדיניות שימוש הוגן, ספירת טרנזקציות
• Priority Developer Portal - דרייבר ODBC: דרישות, סכמה, MAXFORMLINES
• Microsoft Learn - רענון נתונים ב-Power BI: 8 ו-48 רענונים ביום, gateways, מקורות נתונים דינמיים