אינטגרציה בסגנון BPM

Привет, האבר!

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

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

כתב ויתור

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

מה הקשר ל-BPM?

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

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

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

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

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

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

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

כך נראה התהליך בתחילת הפרויקט

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

כך נראה התהליך לאחר מספר איטרציות של בירור הדרישות

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

חלק קטן מתהליך עסקי מורכב

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

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

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

חסרונות של שיחות סינכרוניות כדפוס אינטגרציה

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

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

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

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

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

הדברים נעשים מעניינים אפילו יותר אם תת-המערכות המשולבות נמצאות ביישומים שונים ויש צורך לבצע שינויים סינכרוניים משני הצדדים. כיצד להפוך את השינויים הללו לעסקאות?

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

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

"סאגה" כפתרון לבעיית העסקאות

עם הפופולריות הגוברת של שירותי מיקרו, יש ביקוש הולך וגובר עבור דפוס סאגה.

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

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

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

אבל לפתרון הזה יש גם "מחיר" משלו:

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

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

אנקפסולציה של היגיון עסקי בשירותי מיקרו

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

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

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

מחקר מפורט יותר גילה חסרונות משמעותיים של גישה זו:

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

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

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

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

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

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

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

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

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

כללי המשחק:

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

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

באפליקציה app1, התהליך העסקי של השחקן הראשון (הוא גם היוזם של המשחק) יעבוד:

class InitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

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

app2 יכלול תהליך עסקי של שחקן אחר:

מחלקה RandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

תרשים:

באפליקציית app3 נהפוך את השחקן להתנהגות קצת שונה: במקום לבחור אקראית את השחקן הבא, הוא יפעל לפי האלגוריתם round robin:

class RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

אחרת, התנהגות השחקן אינה שונה מהקודמת, כך שהתרשים אינו משתנה.

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

testGame()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

הרץ את הבדיקה, הסתכל ביומן:

פלט קונסולה

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

מכל זה ניתן להסיק מספר מסקנות חשובות:

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

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

כל ההודעות בתור אחד

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

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

הבטחת האמינות של אפיק האינטגרציה

אמינות מורכבת מכמה דברים:

• מתווך ההודעות הנבחר הוא מרכיב קריטי בארכיטקטורה ונקודת כשל אחת: עליו להיות מספיק סובלני לתקלות. עליך להשתמש רק ביישומים שנבדקו בזמן עם תמיכה טובה וקהילה גדולה;
• יש צורך להבטיח זמינות גבוהה של מתווך ההודעות, שעבורו יש להפריד אותו פיזית מהיישומים המשולבים (זמינות גבוהה של אפליקציות עם לוגיקה עסקית יישומית היא הרבה יותר קשה ויקרה לספק);
• המתווך מחויב לספק ערבויות מסירה "לפחות פעם אחת". זוהי דרישה חובה לפעולה אמינה של אפיק האינטגרציה. אין צורך בהבטחות ברמה של "פעם אחת בדיוק": תהליכים עסקיים לרוב אינם רגישים להגעת הודעות או אירועים חוזרות ונשנות, ובמשימות מיוחדות שבהן זה חשוב, קל יותר להוסיף בדיקות נוספות להיגיון העסקי מאשר להשתמש כל הזמן ערבויות "יקרות" למדי;
• שליחת הודעות ואותות חייבת להיות מעורבת בעסקה משותפת עם שינוי במצב התהליכים העסקיים ונתוני התחום. האפשרות המועדפת תהיה להשתמש בתבנית תיבת דואר עסקית, אבל זה ידרוש טבלה נוספת במסד הנתונים וממסר. ביישומי JEE, ניתן לפשט זאת על ידי שימוש במנהל JTA מקומי, אך החיבור למתווך שנבחר חייב להיות מסוגל לעבוד במצב XA;
• מטפלים של הודעות ואירועים נכנסים חייבים לעבוד גם עם העסקה של שינוי מצב התהליך העסקי: אם עסקה כזו מתגלגלת לאחור, אזי יש לבטל גם את קבלת ההודעה;
• הודעות שלא ניתן היה להעביר עקב שגיאות יש לאחסן בחנות נפרדת D.L.Q. (תור אותיות מתות). לשם כך, יצרנו מיקרו-שירות פלטפורמה נפרד המאחסן הודעות כאלה באחסון שלו, מוסיף אותן לפי תכונות (לקיבוץ וחיפוש מהיר), וחושף את ה-API לצפייה, שליחה מחדש לכתובת היעד ומחיקת הודעות. מנהלי מערכת יכולים לעבוד עם שירות זה דרך ממשק האינטרנט שלהם;
• בהגדרות המתווך, אתה צריך להתאים את מספר ניסיונות המסירה והעיכובים בין משלוחים כדי להפחית את הסבירות של הודעות להיכנס ל-DLQ (כמעט בלתי אפשרי לחשב את הפרמטרים האופטימליים, אבל אתה יכול לפעול באופן אמפירי ולהתאים אותם במהלך מבצע);
• יש לנטר את חנות DLQ באופן רציף, ומערכת הניטור צריכה להודיע ​​למנהלי המערכת כדי שיוכלו להגיב במהירות האפשרית כאשר מתרחשות הודעות שלא נמסרו. זה יקטין את "אזור הנזק" של כשל או שגיאת לוגיקה עסקית;
• אפיק האינטגרציה חייב להיות חסר רגישות להיעדר זמני של אפליקציות: מנויי נושא חייבים להיות עמידים, ושם הדומיין של האפליקציה חייב להיות ייחודי כדי שמישהו אחר לא ינסה לעבד את ההודעה שלו מהתור בזמן היעדר האפליקציה.

הבטחת בטיחות החוטים של ההיגיון העסקי

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

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

• השקת מופע תהליך עסקי;
• פעולת משתמש הקשורה לפעילות בתוך התהליך העסקי;
• קבלת הודעה או אות שאליהם מנוי מופע של תהליך עסקי;
• תפוגה של הטיימר שנקבע על ידי מופע התהליך העסקי;
• פעולת בקרה באמצעות API (למשל הפסקת תהליך).

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

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

באמצעות מנעולים פסימיים בצד DBMS, אנו עומדים בכל הדרישות הנדרשות ACID, וגם לשמור על היכולת לשנות את היישום עם היגיון עסקי על ידי הגדלת מספר המופעים הפועלים.

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

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

בדוגמאות שלנו, התהליך העסקי של InitialPlayer מכיל הצהרה

uniqueConstraint = UniqueConstraints.singleton

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

בעיות בתהליך עסקי עם מצב מתמשך

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

בהתאם לעומק השינוי, תוכל לפעול בשתי דרכים:

1. ליצור סוג חדש של תהליך עסקי כדי לא לבצע שינויים לא תואמים לישן, ולהשתמש בו במקום הישן בעת ​​הפעלת מופעים חדשים. מופעים ישנים ימשיכו לעבוד "בדרך הישנה";
2. העבר את המצב המתמשך של תהליכים עסקיים בעת עדכון ההיגיון העסקי.

הדרך הראשונה פשוטה יותר, אך יש לה מגבלות וחסרונות, למשל:

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

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

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

האם אני צריך עוד מסגרת לתהליכים עסקיים?

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם אני צריך עוד מסגרת לתהליכים עסקיים?

• 18,8%כן, אני מחפש משהו כזה כבר הרבה זמן.

• 12,5%מעניין ללמוד עוד על היישום שלך, זה עשוי להיות שימושי2

• 6,2%אנו משתמשים באחת מהמסגרות הקיימות, אך אנו שוקלים להחליף אותה1

• 18,8%אנו משתמשים באחת מהמסגרות הקיימות, הכל מתאים3

• 18,8%התמודדות ללא מסגרת3

• 25,0%כתוב בעצמך 4

16 משתמשים הצביעו. 7 משתמשים נמנעו.

מקור: www.habr.com