Client Transaction

בלי כתוביותעם כתוביות

מילון מושגים:

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

ממשק - נקודת מגע בין רכיבים: ממשק משתמש שבו אדם מפעיל תוכנה, או ממשק תכנותי שמגדיר אילו פעולות רכיב אחד חושף לאחר.

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

HTTP - פרוטוקול להעברת דפי אינטרנט ונתונים בין דפדפן לשרת. הגרסה המאובטחת שלו היא HTTPS.

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

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

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

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

Client Transaction

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

הגדרה בשרת

1. TransactionFlow: מעל הפונקציה בממשק מוסיפים [TransactionFlow(TransactionFlowOption.Allowed)]. יש שלוש אפשרויות: NotAllowed (ברירת המחדל, הטרנזקציה של הלקוח מתעלמת), Allowed (הלקוח יכול לפתוח טרנזקציה, אבל לא חייב), ו-Mandatory (הלקוח חייב לקרוא בטרנזקציה).

2. OperationBehavior: במחלקה השרת, מעל הפונקציה, מוסיפים [OperationBehavior(TransactionScope Required = true)], כלומר הפונקציה תפעל בתוך טרנזקציה.

הביינדינג

3. Basic HTTP לא תומך: ב-BasicHttpBinding אי אפשר להעביר טרנזקציה. מחליפים ל-WSHttpBinding, ובקונפיגורציה של הביינדינג מגדירים transactionFlow = true.

4. Endpoint: הקונפיגורציה החדשה מחוברת ל-endpoint. בלי החיבור ההגדרה לא תופיע בקובץ.

הלקוח

5. עדכון הפרוקסי: Update Service Reference. ב-app.config של הלקוח רואים את הערך transactionFlow = true.

6. הטרנזקציה: בלקוח פותחים TransactionScope, קוראים ל-DeleteOrder עבור הזמנות 10252 ו-10253, ואז קוראים ל-ts.Complete().

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

כך לקוח יכול לאגד כמה קריאות לשרת לפעולה אחת.

פרקי ההרצאה: Client Transaction

תמלול ההרצאה: Client Transaction

הטקסט המלא של הדקות הראשונות בהרצאה «Client Transaction» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

00:20
כעת אנחנו עוברים לקליינט טרנזקשן זה אומר שהקליינט מתחיל לבצע מספר פעולות לא הסרבר אלא הקליינט שכמובן הפעולות האלה זה פעולות של קריאות לפונקציות שונות שנמצאות בשרת והקליינט רוצה שכל הפעולות יצליחו או שאם אחת נכשלת כמובן שכולן יכשלו לא מעניין אותו איזה נכשלה הוא לא רוצה שאף אחד תצליח כאשר מה שעשינו מקודם זה הסדרת פעולות האלה שהיו היו בשרת זאת אומרת שהשרת בשביל לבצע
00:52
משהו לוגי מבחינת delete order פעילות לוגית של מחיקת הזמנה היה צריך לבצע כמה פעולות שונות ולכן הוא יכל לפתוח טרנזקציה בלי שום קשר לקליינט. הקליינט לא אמור לדעת בכלל שהפעילות הלוגית הזאת בנויה מכמה תתי פעולות.
01:11
אוקיי, אז מה שעשינו זה העלינו פה איזושהי חריגה. בואו נשים את החריגה כרגע בהערה ואנחנו רוצים לעשות משהו אחר. אנחנו רוצים שהקליינט יבצע סדרה של פעולות כאשר כל כל הסדרה הזאת נחשבת כטרנזקציה אחת.
01:25
לצורך כך אנחנו צריכים להגדיר כמה דברים. נתחיל מהאינטרפייס. דבר ראשון כל WCF כל השירות שאנחנו בונים צריך לתמוך בטרנזקציות וצריך להגדיר שהוא עובד עם טרנזקציות וזה מתבצע חלק על ידי אטריביוט וחלק על ידי ביינדינג קונפיגוריישן.
01:46
אז דבר ראשון אנחנו הולכים לאינטרפייס שלנו ובאינטרפייס I Northwind Service אנחנו פותחים אטריביוט שנקרא Transaction Flow ואנחנו מגדירים לטרנזקשן פלואו הזה אינאם שנקרא Transaction Flow Option והאינאם הזה מכיל שלושה חלקים או שלוש אופציות בלבד.
02:10
קודם כל יש לנו Not Allowed זה הדיפולט וזה אומר שאם הלקוח מרים את מספר קריאות לשרת בטרנזקציה המערכת מתעלמת ואומרת זה לא מעניין אותי זה שיצר את הטרנזקציה אנחנו ברגע שאנחנו מצליחים לעשות פעולה היא מצליחה לא משנה לי אם אחת אחרת נכשלת הלאוד זה אומר שאם הקליינט מריץ את המספר קריאות בטרנזקציה שתכף אנחנו
02:41
נעשה את זה בצד של הקליינט אז כמובן מבחינתנו זה אכן טרנזקציה ואנחנו מאשרים או לא מאשרים אותה כלומר, אנחנו מתייחסים אליה כטרנזקציה. זאת אומרת שאם כל הפעולות שהקליינט יזם מצליחות, מבחינתנו כולם הצליחו. אם אחת מהן נכשלת, זה בסדר, אנחנו מבטלים לו את כולם, זה ממש טרנזקציה.
03:00
מנדטורי אומר שהקליינט חייב להפעיל את הקריאות לפונקציות השונות שלנו, ספציפית כרגע זה לפונקציה הזאתי, שנקראת delete order.
03:12
הקליינט חייב לקרוא לפונקציות בטרנזקציה. מתי אנחנו משתמשים במנדטורי? רק כמובן אם אנחנו יודעים בוודאות שהפונקציה שלנו חייבת להיות חלק ממספר פונקציות שצריכים לקרוא להם אחת אחרי השנייה.
03:26
לכן אנחנו אומרים זה מחייב טרנזקציה. אז בואו נבחר כרגע ב-allowed, אם הלקוח רוצה הוא יכול לקרוא עוד טרנזקציה, אם לא זה לא חייב, אבל אם הוא כן קורא לזה בטרנזקציה השרת יכבד את הטרנזקציה שלו.
03:41
אז הדבר הראשון שעשינו זה הגדרנו transaction flow בצד של השרת בתוך האינטרפייס. הדבר הראשון שאנחנו עושים, אנחנו מגיעים למחלקה שמממשת את האינטרפייס ואנחנו מסתכלים על הפונקציה delete order ומעליה גם אנחנו מגדירים את ה-operation behavior הבא, זאת אומרת behavior עבור פונקציה.
04:07
אז בואו נגדיר operation behavior וה-operation behavior שאנחנו רוצים להגדיר זה transaction scope Required שווה true. זה אומר שאנחנו יודעים שהולכים לקרוא לפונקציה הזאת בטרנזקציה.
04:27
אז את זה ביצענו בצד של השרת במחלקה. פה סיימנו עם ה-DLL שלנו ואנחנו עוברים להוסט. בואו נבצע קונפיגורציה של ההוסט ומה שאנחנו צריכים להגדיר אנחנו צריכים להגדיר סך הכל דבר אחד ויחיד שנקרא Transaction Flow שווה True.
04:53
הדבר הזה מוגדר בביינדינג קונפיגוריישן. בואו נלך לביינדינג ונסתכל מה הבעיה כרגע להגדיר את זה. אנחנו בחרנו את הביינדינג שלנו אם נסתכל עליו נראה שהביינדינג שבחרנו זה Basic HTTP Binding.
05:12
Basic HTTP Binding לא תומך בטרנזקציות ולכן אם אני אנסה להגדיר Configuration ל-Basic HTTP Binding אני לא אמצא כאן שום דבר שקשור ל-Transaction Flow, אוקיי? אז בואו נבטל את זה, Delete Binding ואנחנו צריכים עכשיו ללכת ולהחליף את ה-Basic HTTP Binding ל-Binding שתומך בטרנזקציה.
05:39
ביינדינג כמובן מוגדר ב-Endpoint. אם אנחנו כבר כאן בואו נגדיר ל-Endpoint שם Endpoint ונסתכל על הביינדינג של ה-Endpoint ונחליף את הביינדינג ל...