תיקון: תיקון חם זמין אשר מספק מאפיינים נוספים של מצב המסירה עבור פרוטוקול בשכבה התחתונה מינימלי לקבלה ושליחה של מתאמי ב- BizTalk מאיץ עבור HL7 בסביבה של BizTalk Server 2010

סיכום

המאמר מתאר תיקון חם מספק שני מאפייני מצב מסירה נוספים עבור מינימלית התחתון שכבת פרוטוקול (MLLP) לשלוח ולקבל יציאות בעת שימוש המאיץ BizTalk עבור HL7 בסביבת Microsoft BizTalk Server 2010:

השתמש אישור תעבורה MLLP

מאפיין זה זמין בשניהם חד-כיווני לקבל יציאות ויציאות שלח חד-כיוונית.
השעיה הודעת בקשה בתעבורה MLLP NAK

מאפיין זה זמין רק ביציאות שלח חד-כיוונית.

MLLP לקבל המתאם תומך בשני מצבי תגובה הבקשה חד-כיווניים לבין דו-כיווניים. אם תצורת המתאם קבלה, עיבוד HL7 נעשה שימוש בפרמטר העברה שהוזמנה . פעולה זו מבטיחה כי הסדר של מסירת ההודעה תישמר. כאשר מקבלים MLLP המתאם פועל במצב דו-כיווני, המתאם אינו מקבל הודעה חדשה מתוך המערכת במעלה עד המתאם יוצר הודעת אישור יישום (MSA) עבור ההודעה הקודמת למערכת במעלה הזרם. הודעות ACK/NAK שנוצר נשלח למסד הנתונים תיבת הודעה (MessageBoxDB). MessageBoxDB מחכה מרווח התשאול הבא לפני שהוא שולח הודעות ACK/NAK למערכת במעלה הזרם.

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

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

עבור BizTalk: העברת הודעות קטגוריה, השתמש המונה מסמכים שעובדו/שניה .
עבור BizTalk: השהיית העברת הודעות קטגוריה, השתמש כל המונים הזמינים.

אפשרות אחת כדי להגדיל את מספר המסמכים שעובדו לשניה היא להנמיך את ההגדרה MaxReceiveInterval עבור המחשב המארח של BizTalk. בהתאם לסביבת הכולל, כוונון של המחשב שבו פועל Biz לדבר Server 2010 ולאחר באמצעי האחסון של המסמכים המעובדים, להנמיך את ההגדרה MaxReceiveInterval היתה להשפיע לרעה על הביצועים של המופע של SQL Server. עבור כוונון SQL Server והן עבור כוונון BizTalk, עיין במאמרים טכני זמין כל.

מידע נוסף

הערה תיקון חם זה פותר גם בעיה ב- Microsoft BizTalk 2010 האצה עבור HL7. לקבלת מידע נוסף אודות בעיה זו, לחץ על מספר המאמר הבא כדי להציג את המאמר הרלוונטי מתוך Microsoft Knowledge Base:

2454887 אירועים עשוי להיות באופן שגוי מחובר עבור הודעת מבוסס-MLLP ב- BizTalk מאיץ 2009 עבור HL7 במחשב שבו פועל Microsoft BizTalk Server 2009 או Microsoft BizTalk Server 2010

מידע על תיקונים חמים

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

אם התיקון החם זמין להורדה, ישנו סעיף "הורדת תיקון חם זמינה" בראש מאמר Knowledge Base. אם מקטע זה אינו מופיע, פנה לשירות הלקוחות והתמיכה של Microsoft כדי לקבל את התיקון החם.

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

http://support.microsoft.com/contactus/?ws=supportהערה הטופס "הורדת תיקון חם זמינה" מציג את השפות שעבורן התיקון החם זמין. אם אינך רואה את השפה שלך, הסיבה לכך היא שהתיקון חם אינו זמין עבור שפה זו.

דרישות מוקדמות

יש ברשותך Microsoft BizTalk מאיץ HL7 (BTAHL7) מותקן כדי להחיל תיקון חם זה.

מידע על הפעלה מחדש

ייתכן שיהיה עליך להפעיל מחדש את המחשב לאחר החלת תיקון חם זה. אם לא תתבקש להפעיל מחדש, עליך להפעיל מחדש את שירותי BizTalk. לקבלת מידע נוסף אודות הליך זה, עיין בקובץ readme. txt אשר נכלל בחבילת התיקון החם הזו.

מידע על החלפות

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

פרטי קובץ

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

שם קובץ	גירסת קובץ	גודל קובץ	תאריך	שעה	פלטפורמה
Microsoft.solutions.btahl7.mllp.dll	3.9.526.2	116,608	07-Jun-2011	15:27	x86
Microsoft.solutions.btahl7.shared.dll	3.9.526.2	92,040	07-Jun-2011	15:27	x86
Mllpreceive.exe	3.9.526.2	26,456	07-Jun-2011	15:27	x86
Mllpsend.exe	3.9.526.2	26,448	07-Jun-2011	15:27	x86

אודות התיקון החם

זרימת הודעות לאחר התיקון החם מותקן ומוגדר

לאחר החלת התיקון החם לזמין, מתאם MLLP שולח כל הודעה המתקבלת על-ידי המתאם MLLP MessageBoxDB. מנהל נקודת הקצה (EPM) מתקשר חזרה המתאם יחד עם מצב השליחה בפעולת השירות BatchComplete . פעולה זו גורמת המתאם לשלוח הודעות ACK/NAK פעולת commit למערכת במעלה הזרם. בתורו, המערכת במעלה מקבל הודעות ACK/NAK ולאחר מכן שולח את ההודעה הבאה. פעולת BatchComplete אינה תלויה בהגדרה MaxReceiveInterval ונקראת מיד לאחר ההודעה נשלחת BizTalk בהצלחה.

ברגע ההודעה מוכנה לשליחה, שלח המתאם משדר את ההודעה למערכת במורד הזרם. הודעות ACK/NAK צפוי אם המאפיין אישור התעבורה של שימוש MLLP מוגדר כ- True. אם שלח ACK, BizTalk מסיים את העיבוד בהצלחה. אם הוא שלח NAK, ואם המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר כ- True, ההודעה מושעה ישירות מבלי לנסות שוב. עם זאת, אם המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר כ- False, BizTalk ינסה בהתבסס על ההגדרות מרווח זמן לניסיון חוזר יציאה שליחה. (כברירת מחדל, המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר כ- False).

הדיאגרמה הבאה מציגה את זרימת ההודעה:

Message flow

הודעה הנשלחת על-ידי היישום השולח מעובד על-ידי MLLP המערכת במעלה מקבלים מתאם.
מתאם MLLP שולח ההודעה BizTalk/EPM.
EPM מתקשר חזרה המתאם אודות מצב שליחת ההודעה. EPM עושה זאת בשיטת אצווה מלאה .
פעולת commit ACK/NAK שנוצרו על-ידי המתאם MLLP ומבוסס על מצב השליחה אצווה. הודעות ACK/NAK שנשלחו כדי שהיישום השולח.

הערה אם המצב שליחת אצווה הוא הצלחה, המתאם מחזירה את ACK. עם זאת, אם ישנו כשל או מסירה הזמן הקצוב (לדוגמה, אם הקריאה לשיטה מלאה אצווה הזמן שהוקצב), המתאם מחזירה את NAK כדי שהיישום השולח.
EPM ידיים מעל ההודעה למתאם שלח MLLP לשידור.
MLLP לשלוח מתאם שולחת את ההודעה מעובדים למערכת במורד הזרם.
מתאם השליחה של MLLP צפוי רמת תעבורה ACK/NAK כדי להשלים את התקשורת.
אם ההודעה בשלב 7 ACK, המתאם שואל EPM למחוק את ההודעה. אחרת, המתאם יש לבקש את EPM ניסיון חוזר המבוסס על הגדרת מרווח הזמן לניסיון חוזר. אפשרות חדשה מסופקת בהגדרת התצורה של יציאת שלח עבור השעיה ההודעה ישירות, ללא ניסיון חוזר, אם מתקבל NAK MLLP. כברירת מחדל, אפשרות זו מוגדרת כ- False. אם אפשרות זו מוגדרת כ- True, ההודעה מושעים ישירות, ללא ניסיון חוזר, אם מתקבל NAK MLLP.

עיצוב ACK/NACK רמת תעבורה

אתר האינטרנט מכיל את המידע הבא:

דוגמה של הודעת אישור Commit של MLLP:

<SB><ACK><EB><CR>
דוגמה שלילי MLLP לבצע אישור:

<SB><NAK><EB><CR>

הערות

בדוגמאות אלה, < SB > מתייחס לתו הפעלת בלוק (בית אחד). מספר זה תואם את התו < VT > ASCII או < 0x0B >.

פעולה זו אין לבלבל עם תווים SOH או STX ASCII.
בדוגמאות אלה, < ACK > או < NAK > עיין התו אישור (בית אחד. תואם את התו < ACK > ASCII או < 0x06 >) או תו אישור שלילי (בית אחד. תואם את התו < NAK > ASCII, או < 0x15 >).
בדוגמאות אלה, < האינטרנט > מתייחס לתו בלוק קצה (בית אחד). מספר זה תואם את התו < FS > ASCII או < 0x1C >.
בדוגמאות אלה, < CR > מתייחס התו גררה (בית אחד). מספר זה תואם את התו < CR > ASCII או < 0x0D >.
Microsoft מספקת פרטי קשר של ספקים חיצוניים כדי לסייע לך באיתור תמיכה טכנית. פרטי קשר אלה עשויים להשתנות ללא הודעה מוקדמת. Microsoft אינה ערבה למידת הדיוק של פרטי קשר של ספקים חיצוניים אלה.

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

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

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

קבלת תצורת יציאה

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

Receive port

שלח תצורת יציאה

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

Send port

אודות המאפיין "השתמש MLLP אישור של תעבורה"

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

הערות

"מערכת במעלה" מתייחס היישום השולח. היא שולחת הודעות BizTalk. הודעות אלה הם נכנסים BizTalk.
"מערכת" במורד הזרם"" מתייחס ליישום המקבל. קבלת הודעות מ- BizTalk. הודעות אלה הם יוצאים אל BizTalk.

סוג של יציאה	האפשרויות V2 של MLLP	MLLP V2 אפשרות ביטול
חד-כיווני קבלה	שלח הודעות ACK/NAK MLLP למערכת במעלה בפעולת השירות BatchComplete .	ללא שינוי בהתנהגות. במצב זה, לא ACK/NAK שנשלחו למערכת במעלה.
דו-כיווני קבלה	ללא שינוי בהתנהגות. במצב זה, ה HL7 ACK/NAK בפעולת השירות TransmitMessage נשלח למערכת במעלה הזרם. הערה אפשרות זו אינה נתמכת. לדוגמה, התעלם גם אם הערך זה מוגדר כ- True.	ללא שינוי בהתנהגות. במצב זה, ה HL7 ACK/NAK בפעולת השירות TransmitMessage נשלח למערכת במעלה הזרם.
שלח חד-כיווני	MLLP ACK/NAK מהמערכת במורד הזרם המתינה לאחר ההודעה משודר.	ללא שינוי בהתנהגות. במצב זה, ACK/NAK מהמערכת במורד הזרם הוא לא המתינה לאחר ההודעה משודר.
שלח דו-כיווני או שלח חד-כיוונית עם מצב תגובה לבקש לזמין	ללא שינוי בהתנהגות. במצב זה, ה HL7 ACK/NAK מהמערכת במורד הזרם היא המתינה לאחר ההודעה משודר. הערה אפשרות זו אינה נתמכת. לדוגמה, התעלם גם אם הערך זה מוגדר כ- True.	ללא שינוי בהתנהגות. במצב זה, ה HL7 ACK/NAK מהמערכת במורד הזרם היא המתינה לאחר ההודעה משודר.

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

לקבלת מידע נוסף, עיין בתיעוד מתאם MLLP. אם חד-כיווני לקבל ואת יציאות שלח לך את התצורה המתאים, משפר את הביצועים. אם המאפיין אישור תעבורה MLLP בשימוש של יציאה דו-כיווני או יציאה חד-כיווני מוגדר כ- false, איזה סוג ACK הנוצר ממשיך ללא שינוי. במצב זה, איזה סוג ACK שנוצר תלוי בהגדרות BTAHL7 Explorer התצורה עבור היישום השולח את ההודעה. הערך בשדות MSH 15 ו- MSH 16 של הודעה מסוימת באפשרותך לעקוף הגדרה זו. עם זאת, אם המאפיין אישור תעבורה MLLP בשימוש של יציאה דו-כיווני או יציאה חד-כיווני מוגדר כ- false, באפשרותך להגדיר את התצורה עבור יישומים המצפים Ack סטטי רק באמצעות סייר התצורה של BTAHL7. אופן הפעולה של פסק הזמן עבור היציאה נותרת ללא שינוי...

אופן הפעולה הצפוי במקרים פינה שבהם נעשה שימוש על-ידי המאפיינים הוא כדלהלן:

RECEIVE

WrongMLLPFormat: ההודעה לא נשלחת BizTalk.
WrongHL7Format: ההודעה נשלחת BizTalk ולאחר ACK/NAK MLLP משודר המבוסס על מצב אצווה השלמה.
TransmittingSocketIssue: MLLP ACK/NAK לא משודר, למרות ההודעה נשלחת BizTalk.
ReceivingSocketIssue: ההודעה לא התקבלה ולכן לא נשלח ו שידור MLLP ACK/NAK לא נשלח.
אם פריט שנשלח ל- BizTalk נכשלת, NAK משודרים.
אם מתקבל מצב שלילי של אצווה מלאה, NAK משודרים.

לשלוח ולשלוח יציאה מאפיין "הפסק שליחת ההודעות הבאות בכשל ההודעה הנוכחית" = True

WrongMLLPFormat: ההודעה הושעתה מאחר ACK/NACK של MLLP ניתן לקרוא. עיבוד לא תימשך עד הודעות מושהה אינן מסומנות.
WrongHL7Format: ההודעה נכשל לפני שהיא מגיעה המתאם. עיבוד לא תימשך עד הודעות מושהה אינן מסומנות.
TransmittingSocketIssue: ההודעה מושעה. עיבוד לא תימשך עד הודעות מושהה אינן מסומנות.
ReceivingSocketIssue: ההודעה מושעה. עיבוד לא תימשך עד הודעות מושהה אינן מסומנות.

אופן הפעולה הצפוי כאשר המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר כ- True או כ- False הוא כדלהלן:

כאשר המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר כ- True והתקבלו NAK, ההודעה מושעה ללא ניסיון חוזר כדי לשלוח אותה.
כאשר המאפיין להשעות לבקש הודעה על NAK תעבורה MLLP מוגדר להגדרת ברירת המחדל של False, נסה שנית כדי לשלוח שההודעה יופעל, בהתבסס על הגדרות מרווח זמן לניסיון חוזר היציאה שליחה.

שינויים בכלי השירות MLLP SDK

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

עבור MLLPReceive.exe, השתמש בפרמטר חדש כדי לחזור MLLP ACK/NAK לאחר קבלת ההודעה. לדוגמה:

MLLPReceive/p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
MLLPReceive/p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
עבור MLLPSend.exe, השתמש בפרמטר חדש עבור MLLP ACK/NAK להמתין. לדוגמה:

MLLPSend /sb 11 /eb 28 /cr 13 /f "C:\HL7\ls.txt" / I 127.0.0.1 /UseMLLPTransACK/p 11000

הפניות

לקבלת מידע נוסף אודות כיצד לנהל את הגדרות הביצועים ב- BizTalk server, בקר באתר האינטרנט הבא של Microsoft מפתח רשת (MSDN):

ניהול הגדרות הביצועים של שרת BizTalkלקבלת מידע נוסף אודות העברת הודעות מוני ביצועים, בקר באתר האינטרנט הבא של MSDN:

מוני ביצועים של העברת הודעותלקבלת מידע נוסף אודות הזמנת מסירה של הודעות, בקר באתר האינטרנט הבא של MSDN:

הזמנת מסירה של הודעותלקבלת מידע נוסף אודות BizTalk האצה 2010 עבור HL7 (BTAHL7), בקר באתר האינטרנט הבא של Microsoft:

האצה 2010 BizTalk עבור HL7 תיעוד (BTAHL7)לקבלת מידע נוסף אודות שיטת IBTBatchCallBack.BatchComplete , בקר באתר האינטרנט הבא של MSDN:

שיטת IBTBatchCallBack.BatchCompleteלקבלת מידע נוסף אודות תיקונים חמים של BizTalk Server, לחץ על מספר המאמר הבא כדי להציג את המאמר הרלוונטי מתוך Microsoft Knowledge Base:

מידע 2003907 אודות תיקונים חמים של BizTalk Server