מבנה חיוב בשימוש ב-API

This topic has 32 תגובות, 3 משתתפים, and was last updated לפני 6 שנים, 2 חודשים by PriorityDev.

Post

- אוגוסט 21, 2018 בשעה 12:52 pm
- Quote
אלמוני
אורח

שלום חברים וסליחה מראש אם נדמה שאני לא ממש יודע על מה אני מדבר… זה כי אני באמת לא יודע על מה אני מדבר.

אנו עומדים לקראת פיתוח אתר חדש, כאשר על האתר "לדבר" עם הפריוריטי, לצורך בדיקות מלאי, הפקת הצעות מחיר והזמנות.
נתבקשנו ע"י מפתחי האתר לבדוק אפשרות של עבודה מול ה-API של פריוריטי ולהבניות את מבנה העלויות.
נאמר לנו שיש חיוב חודשי קבוע לכל 10,000 שורות / טרנזקציות (או כל כמות אחרת שנראה), רק שאנו לא מצליחים לקבל תשובה ברורה – מה נחשב שורה?

נשמח ללמוד מחוכמת ההמונים.

מוצגות 15 תגובות – 1 עד 15 (מתוך 32 סה״כ)

1 2 3 ←

Replies

- ספטמבר 3, 2018 בשעה 11:57 pm
- Quote
אלמוני
אורח

בס"ד

שלום רב ,

בניתי כמה מערכות ווב WEB מתממשקות לפריורטי ללא ה API המובנה (ללא צורך ברישוי מיוחד וללא הגבלה במספר הרשומות להצגה וכו )
תוכל להתרשם מאחד האתרים שנבנו עבור אחד מלקוחותנו , אשמח להסביר למתכנת שלך מה צריך לעשות , מצ"ב קישור ל סרטון שמראה על מתחם הלקוח (דרך אגב , האתר נבדק גם ברמה אבטחה מול חברה חצונית ל חדירות / PT).

קישור לסרטון המציג את האתר

הרבה הצלחה !
taub5bs@gmail.com
- ספטמבר 4, 2018 בשעה 10:45 am
- Quote
ariel
משתתף

אשמח גם לשמוע, האם מדובר על WCF?

תודה רבה
- ספטמבר 4, 2018 בשעה 6:50 pm
- Quote
אלמוני
אורח

בשמחה , ניתן ליצור קשר 0584960970 או לראות בלינק
http://www.info.knightltd.co.il/

ניתן גם ב WCF מה שמוצג בסרטון נבנה ב MVC
תוכל להתרשם גם מהאפלקצית מובייל מול פריורטי שעשינו בגוגל PLAY
https://play.google.com/store/apps/details?id=xdk.intel.sport.center.app

ועוד ….
בברכה ,
- ספטמבר 5, 2018 בשעה 10:52 am
- Quote
PriorityDev
משתתף

בן שטרית כתב:

בס"ד

שלום רב ,

בניתי כמה מערכות ווב WEB מתממשקות לפריורטי ללא ה API המובנה (ללא צורך ברישוי מיוחד וללא הגבלה במספר הרשומות להצגה וכו )
תוכל להתרשם מאחד האתרים שנבנו עבור אחד מלקוחותנו , אשמח להסביר למתכנת שלך מה צריך לעשות , מצ"ב קישור ל סרטון שמראה על מתחם הלקוח (דרך אגב , האתר נבדק גם ברמה אבטחה מול חברה חצונית ל חדירות / PT).

קישור לסרטון המציג את האתר

הרבה הצלחה !
taub5bs@gmail.com

שלום,
נראה שמה שאתה כותב קצת מטעה.
למיטב ידיעתי, מגרסה 18 צריך לשלם על כל טרנזקציה, גם אם זה נבנה בממשקים הישנים (לא ב-API).

יש רק 3 אפשרויות שלא צריכים לשלם:
א. הממשק היה קיים לפני עלייה ל-18.
אזי בעלייה ל-18 צריכים לדווח לפריוריטי סופטוור על כל ממשק כזה וכמה טרנזקציות חודשיות הוא עושה.
כל מה שמעבר לזה – בתשלום.
ב. לא להשתמש בממשקים כלל, אלא לכתוב ישירות לטבלאות של מסכים – שיטה לא נכונה ומסוכנת בעליל.
ג. האתר שלך רק קורא מפריוריטי (ישירות מ-DB) ולא כותב כלום בחזרה.
- ספטמבר 5, 2018 בשעה 10:59 am
- Quote
אלמוני
אורח

תודה על התגובות.

michaelm,
אשמח אם תוכל לפרט:

כתבת:
[b]א. הממשק היה קיים לפני עלייה ל-18.
אזי בעלייה ל-18 צריכים לדווח לפריוריטי סופטוור על כל ממשק כזה וכמה טרנזקציות חודשיות הוא עושה.
כל מה שמעבר לזה – בתשלום.[/b]

– מהי טרנזקציה? כיצד סופרים אותן? (אנחנו מנסים להבין מה יהיו העלויות שלנו, אבל באמת מבולבלים)

כתבת:
[b]ב. לא להשתמש בממשקים כלל, אלא לכתוב ישירות לטבלאות של מסכים – שיטה לא נכונה ומסוכנת בעליל.
[/b]- נראה לי שזה מה שאנו עושים היום. תוכל להסביר למה זו שיטה לא נכונה ומסוכנת?

המון תודה
- ספטמבר 5, 2018 בשעה 1:22 pm
- Quote
אלמוני
אורח

בס"ד

שלום רב ,

בכל החברות בהם כתבתי ל ממשקים שאנו יצרנו ו API שהפעיל ממשקי פריורטי ב שרת ועדכנו חזרה בטבלאות ולא דרך משפטי UPDATE או INSERT בהתאמה בוצעו דרך הממשקים שבנינו בפריורטי כמובן והם התיחסו גם לחוקים העסקים והקמנו לא מעט כאלו גם מול אתרי סחר של מגינטו לגבי גרסא 18 וצפונה אני לא מכיר את מודול התמחורים של פריורטי / אשבל צריך לברר מולם , אבל כל בר דעת שרוכש תוכנה דואג שבמסגרת החוזה שלו לא יהיה הגבלה על מספר עדכונים במסד הנתונים ואני יכול לתת לך מספר חברות גם בגרסאות 17 ו 16 שעשינו להם אתר יעודי להכנסה של סחורות ל איתורים במחסנים דרך טבלטים שישבו על המלגזות ונחסמנו כאשר עדכנו את המסד הנתונים דרך הממשקים הגענו עד שאול (העו"ד של אשבל ) ופתיחת החוזה ואושר / עודכן הרישוי שכן בחוזה של הלקוח היה רשום שאין הגבלה (דבר שהוא דרש ברכישה )

לגבי לא להשתמש בממשקים , אם אלו שדות פרטים אין שום בעייה כמובן מומלץ לא לבצע זאת ללא ידעה אנו השתמשנו בכלי ETL לעושת ERD על מסד הנתונים של פריורטי , כאשר הם לא חושפים את מבנה הבטבלאות לכן אדם שלא מכיר חושש לבצע גם על שדות פרטים מנסיון רק והסמכות של DBA והכרות מעולה עם מבני הנתונים לאחר reverse engineer על מסד הנתונים אומר לך באחריות ועם קבלות שבוצע ועובד .

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

play.google.com/store/apps/details?id=xd…tel.sport.center.app

כמו כן אתר https://www.sk-all4u.com/presents-sites
שבנינו להם ממשקים לפריוטי באותה צורה בדיוק עם WS/API יעודי שלנו

בברכה ,
- ספטמבר 5, 2018 בשעה 1:30 pm
- Quote
אלמוני
אורח

ראשית קשה לי להמין שזה מה שאתם עושים היום , מאחר ומדובר על ישמומים צד שלישי לפריורטי כלומר מתי אתה אולי תשתמש בהכנסת ערכים ישרות למסד הנתונים ?
כאשר יש לך ישום חיצוני שאתה רוצה לעדכן שם את הרשומות שלא דרך הממשקים בפריורטי דבר שלא מומלץ ויכול לגרום לך צרות … במיוחד אם נעשה שלא בצורה ברורה וידועה ,
אם במקרה יש לך את הידע וחקרת ונכנסת לעובי הקורה ואתה מבין את היחסים בין הטבלאות השונות והסכימות (ויש הרבה כאלו ) ואתה מכיר את הפונקציות השונות ל היפוך עברית למשל או ל תצוגות של תאריכים וכו (שבמקור אלו פונקציות סטנדרטיות של MSSQL ברובן ) אז אתה יכול בקלות יתרה לעושת עדכונים שוב בשדות פרטים שאין עלהם חוקים עסקים דרך ישירות מסד הנתונים ….. עכשיו מי יזכור בעתיד שבשדה X יש עדכון חוק עסקי למשל ? לכן מלכתחילה לא מומלץ לעושת כזה עדכון ישירות ל מסד הנתונים אך אם אתה זה שאחרי בלבד על המערכת וזה שדה פרטי ואתה הוא היחידי שמכניס חוקים עסקים או שימוש ב BPM וכדומה אזי בשיקולי עלות תועלת אתה תראה שהרבה יותר זול וקל להכניס ישירות עדכון לשדה פרטי זה .

מה שחשוב לומר .. שבמסך סטנדרטי וכו לא כדאי ומסוכן לעשות זאת , וכדאי להשקיע את הטיפול בממשקים הכנתם ובניית/הרחבה סביבת IIS בשרת הפריורטי ולפתוח את השרת (כמובן לבדוק שזה נעשה בצורה מאובטחת FW וכו ) לעלום מבחוץ לאתר / WS / API שתכתוב עבור צד שלישי (אפלקציה יעודית בנייד / אתר ווב / מערכת WCF / DESKTP APP ועוד …)

שיהיה לכם בהצלחה מרובה
- ספטמבר 5, 2018 בשעה 1:53 pm
- Quote
PriorityDev
משתתף

בס"ד

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

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

אני לא מפקפק ביכולות של הפיתוחים שלך.
רק חשוב לא להטעות את הלקוח לפני שנכנס לפיתוח כה גדול.
- ספטמבר 5, 2018 בשעה 3:04 pm
- Quote
אלמוני
אורח

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

כמו כן רק לידעה כלי ETL לא נועדו לעדכון רשומות (זה אפשרי אבל אף אחד לא ישקיע סכומים עבור עדכון ) אלה יותר לתחקור מסד הנתונים ללמוד עליו ולראות את המבנה והקשרים ERD.

אני מאוד דואג לעלות את כל הנקודות ללקוח לפני בחירת פתרון כדי שיהיה לו תמונה רחבה ככול האפשר ושיוכל לעלות לבורד (מקבלי ההחלטות ) לשם קבלת ההחלטה הנכונה לעסק שלהם .
- ספטמבר 6, 2018 בשעה 12:04 am
- Quote
yitzchok
משתתף

michaelm כתב:

שלום,
נראה שמה שאתה כותב קצת מטעה.
למיטב ידיעתי, מגרסה 18 צריך לשלם על כל טרנזקציה, גם אם זה נבנה בממשקים הישנים (לא ב-API).

יש רק 3 אפשרויות שלא צריכים לשלם:
א. הממשק היה קיים לפני עלייה ל-18.
אזי בעלייה ל-18 צריכים לדווח לפריוריטי סופטוור על כל ממשק כזה וכמה טרנזקציות חודשיות הוא עושה.
כל מה שמעבר לזה – בתשלום.
ב. לא להשתמש בממשקים כלל, אלא לכתוב ישירות לטבלאות של מסכים – שיטה לא נכונה ומסוכנת בעליל.
ג. האתר שלך רק קורא מפריוריטי (ישירות מ-DB) ולא כותב כלום בחזרה.

מיכאל, אני חושב שיש לך שם טעויות אבל התחלת ממשהו שקיים.

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

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

[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
- ספטמבר 6, 2018 בשעה 12:50 pm
- Quote
PriorityDev
משתתף

בס"ד

יצחק,
כשעלינו ל-18 ביקשו מאיתנו רשימה של כל הממשקים הקיימים עם הערכת מספר טרנזקציות.
היום עם 18 אנחנו ממשיכים לעבוד עם הממשקים האלה בחינם.
הובהר לנו שכל ממשק חדש שנעשה או העלאת סדרי גודל של טרנזקציות בממשקים הישנים יהיו בתשלום (נדמה לי לפי מנות של 10K טרנזקציות).
המדיניות הנ"ל כוללת הרצת ממשקים שמופעלים ע"י ה-scheduler של פריוריטי.
- ספטמבר 6, 2018 בשעה 1:00 pm
- Quote
PriorityDev
משתתף
- ספטמבר 6, 2018 בשעה 1:11 pm
- Quote
אלמוני
אורח

עדין מבחינה משפטית זה נשמע מעניין, במקרה גם, בוגר החוג למשפטים של בר אילן, בכל אופן לגבי ה etl תראה את הלינק הזה תוכל ללמוד על השוני המהותי בין bi לתצוגת נתונים וכו מול מניפולציות יקרות ולחקור מבנה הנתונים בטבלאות השונות כולל אפשרות לטיוב ה מבני הנתונים ולמידה הקשרים erd מה שלא ניתן לעשות ב bi https://www.google.co.il/url?sa=t&source=web&rct=j&url=https://www.ibm.com/support/knowledgecenter/en/SS4QMC_9.5.0/com.ibm.help.sbi.install.doc/installation/ETL_tool.html&ved=2ahUKEwjlqvTRgqbdAhVMhiwKHaqlBWoQFjABegQIBxAB&usg=AOvVaw37ihnIzVWED2iQLnwBL-rG
- ספטמבר 6, 2018 בשעה 3:14 pm
- Quote
אלמוני
אורח

בן שטרית כתב:

ראשית קשה לי להמין שזה מה שאתם עושים היום , מאחר ומדובר על ישמומים צד שלישי לפריורטי כלומר מתי אתה אולי תשתמש בהכנסת ערכים ישרות למסד הנתונים ?
כאשר יש לך ישום חיצוני שאתה רוצה לעדכן שם את הרשומות שלא דרך הממשקים בפריורטי דבר שלא מומלץ ויכול לגרום לך צרות … במיוחד אם נעשה שלא בצורה ברורה וידועה ,
אם במקרה יש לך את הידע וחקרת ונכנסת לעובי הקורה ואתה מבין את היחסים בין הטבלאות השונות והסכימות (ויש הרבה כאלו ) ואתה מכיר את הפונקציות השונות ל היפוך עברית למשל או ל תצוגות של תאריכים וכו (שבמקור אלו פונקציות סטנדרטיות של MSSQL ברובן ) אז אתה יכול בקלות יתרה לעושת עדכונים שוב בשדות פרטים שאין עלהם חוקים עסקים דרך ישירות מסד הנתונים ….. עכשיו מי יזכור בעתיד שבשדה X יש עדכון חוק עסקי למשל ? לכן מלכתחילה לא מומלץ לעושת כזה עדכון ישירות ל מסד הנתונים אך אם אתה זה שאחרי בלבד על המערכת וזה שדה פרטי ואתה הוא היחידי שמכניס חוקים עסקים או שימוש ב BPM וכדומה אזי בשיקולי עלות תועלת אתה תראה שהרבה יותר זול וקל להכניס ישירות עדכון לשדה פרטי זה .

מה שחשוב לומר .. שבמסך סטנדרטי וכו לא כדאי ומסוכן לעשות זאת , וכדאי להשקיע את הטיפול בממשקים הכנתם ובניית/הרחבה סביבת IIS בשרת הפריורטי ולפתוח את השרת (כמובן לבדוק שזה נעשה בצורה מאובטחת FW וכו ) לעלום מבחוץ לאתר / WS / API שתכתוב עבור צד שלישי (אפלקציה יעודית בנייד / אתר ווב / מערכת WCF / DESKTP APP ועוד …)

שיהיה לכם בהצלחה מרובה

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

אני שמח על הדיון הפורה שנוצר כאן, אבל זה ממש סינית עבורי.
אשמח מאוד להסבר בשפת הדיוטות – מהי טרנזקציה? כיצד היא נספרת?
- ספטמבר 6, 2018 בשעה 3:41 pm
- Quote
PriorityDev
משתתף

אמיתי כתב:

תודה על התגובות.

michaelm,
אשמח אם תוכל לפרט:

כתבת:
[b]א. הממשק היה קיים לפני עלייה ל-18.
אזי בעלייה ל-18 צריכים לדווח לפריוריטי סופטוור על כל ממשק כזה וכמה טרנזקציות חודשיות הוא עושה.
כל מה שמעבר לזה – בתשלום.[/b]

– מהי טרנזקציה? כיצד סופרים אותן? (אנחנו מנסים להבין מה יהיו העלויות שלנו, אבל באמת מבולבלים)

כתבת:
[b]ב. לא להשתמש בממשקים כלל, אלא לכתוב ישירות לטבלאות של מסכים – שיטה לא נכונה ומסוכנת בעליל.
[/b]- נראה לי שזה מה שאנו עושים היום. תוכל להסביר למה זו שיטה לא נכונה ומסוכנת?

המון תודה

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

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