Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Khắc phục: Một hotfix có sẵn mà cung cấp các thuộc tính bổ sung chế độ giao hàng cho các giao thức lớp tối thiểu thấp hơn gửi và nhận các adapter BizTalk Accelerator cho HL7 trong một môi trường BizTalk Serv...

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

2564013
TÓM TẮT
Bài viết này mô tả một hotfix cung cấp thuộc tính hai bổ sung chế độ giao hàng cho tối thiểu thấp lớp giao thức (MLLP) gửi và nhận cổng khi bạn sử dụng máy gia tốc BizTalk cho HL7 trong một môi trường Microsoft BizTalk Server 2010:
  • Sử dụng xác nhận vận chuyển MLLP
    Tài sản này có sẵn trong cả hai một cách nhận được cảng và một cách gửi cổng.
  • Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK
    Tài sản này có sẵn chỉ trong một cách gửi cổng.
MLLP nhận được bộ điều hợp hỗ trợ cả chế độ phản ứng yêu cầu một chiều và hai cách. Nếu các adapter nhận được cấu hình, chế biến HL7 sử dụng các Đặt hàng giao hàng tham số. Điều này đảm bảo rằng thứ tự thông báo giao hàng được duy trì. Khi nhận được MLLP bộ điều hợp hoạt động ở chế độ hai chiều, các adapter không nhận được một tin nhắn mới từ hệ thống Thượng lưu cho đến khi các bộ chuyển đổi tạo ra một ứng dụng (MSA) ghi nhận cho thư trước đó với hệ thống thượng nguồn. ACK/NAK được tạo ra sẽ được gửi đến cơ sở dữ liệu hộp thư (MessageBoxDB). MessageBoxDB chờ đợi cho khoảng thời gian bỏ phiếu tiếp theo trước khi nó sẽ gửi ACK/NAK hệ thống thượng nguồn.

Thượng lưu hệ thống sẽ gửi thông điệp duy nhất tại một thời điểm và chỉ sau khi nó nhận được một ACK/NAK. Ngoài ra, khoảng thời gian bỏ phiếu BizTalk được cấu hình, và các Đặt hàng giao hàng tham số được thiết lập để Sự thật. Điều này có nghĩa rằng số lượng tin nhắn được thực hiện cho mỗi thứ hai là hạn chế. Hotfix này cung cấp cho cấu hình bổ sung cho một cách gửi và nhận được cảng. Nó không ảnh hưởng ACK/NAK. Tuy nhiên, nó đáng kể làm tăng số lượng các tài liệu được chế biến / giây.

Bạn nên sử dụng hiệu suất quầy để có một đường cơ sở trước khi và sau khi bạn áp dụng hotfix này. Khi bạn điểm chuẩn, bạn nên gửi một số lượng hợp lý của tin nhắn trong một khoảng thời gian hợp lý. Ví dụ, bạn có thể sử dụng sau đây:
  • Đối với các BizTalk: nhắn tin thể loại, sử dụng các Tài liệu chế biến/giây Số lượt truy cập.
  • Đối với các BizTalk: nhắn tin độ trễ thể loại, sử dụng tất cả các quầy có sẵn.

Một tùy chọn để tăng số lượng các tài liệu được thực hiện cho mỗi thứ hai là để hạ thấp các MaxReceiveInterval thiết lập cho máy chủ lưu trữ BizTalk. Tùy thuộc vào môi trường tổng thể, những điều chỉnh của máy tính đang chạy Biz nói chuyện Server 2010, và tập tài liệu được chế biến, hạ thấp các MaxReceiveInterval thiết lập có thể có một ảnh hưởng hiệu suất của trường hợp của SQL Server. Cho SQL Server điều chỉnh và điều chỉnh BizTalk, đề cập đến tất cả các bài viết có sẵn kỹ thuật.
THÔNG TIN THÊM
Chú ý Hotfix này cũng giải quyết một vấn đề trong Microsoft BizTalk 2010 Accelerator cho HL7. Để có thêm thông tin về vấn đề này, bấm số bài viết sau đây để xem bài viết trong Cơ sở Kiến thức Microsoft:
2454887Các sự kiện có thể không chính xác đăng cho một MLLP dựa trên thông báo trong BizTalk 2009 Accelerator cho HL7 trên một máy tính đang chạy Microsoft BizTalk Server 2009 hay Microsoft BizTalk Server 2010

Thông tin hotfix

Hotfix được hỗ trợ đang được Microsoft cung cấp. Tuy nhiên, hotfix này là nhằm khắc phục chỉ sự cố được mô tả trong bài viết này. Chỉ áp dụng bản vá nóng này cho các hệ thống đang gặp sự cố như đã mô tả trong bài viết này. Hotfix này có thể nhận được thử nghiệm bổ sung. Vì vậy, nếu bạn không bị ảnh hưởng bởi vấn đề này, chúng tôi đề nghị bạn đợi cho Cập Nhật tiếp theo của phần mềm có chứa hotfix này.

Nếu hotfix này sẵn có để tải xuống, có phần "Tải xuống hotfix sẵn có" ở đầu bài viết trong Cơ sở Kiến thức này. Nếu phần này không xuất hiện, liên hệ với Phòng Hỗ Trợ và Dịch vụ Khách hàng của Microsoft để lấy hotfix này.

Chú ý Nếu vấn đề khác xảy ra hoặc nếu bất cứ xử lý sự cố là cần thiết, bạn có thể phải tạo một yêu cầu dịch vụ riêng biệt. Các chi phí hỗ trợ thông thường sẽ áp dụng để hỗ trợ thêm câu hỏi và vấn đề này không đủ điều kiện cho hotfix này cụ thể. Để biết danh sách đầy đủ về các số điện thoại của Phòng Hỗ trợ và Dịch vụ Khách hàng của Microsoft hoặc để tạo yêu cầu dịch vụ riêng, hãy truy cập web site sau của Microsoft: Chú ý Các hình thức "Hotfix download available" hiển thị các ngôn ngữ mà các hotfix có sẵn. Nếu bạn không thấy ngôn ngữ của mình thì đó là do hotfix này hiện không có ngôn ngữ đó.

Điều kiện tiên quyết

Bạn phải có gia tốc Microsoft BizTalk cho HL7 (BTAHL7) cài đặt để áp dụng hotfix này.

Khởi động lại thông tin

Bạn có thể phải khởi động lại máy tính của bạn sau khi bạn áp dụng hotfix này. Nếu bạn không được nhắc khởi động lại, bạn phải khởi động lại dịch vụ BizTalk. Để biết thêm chi tiết về thủ tục này, tham khảo các tập tin Readme.txt được bao gồm trong gói hotfix này.

Thay thế thông tin

Bản sửa lỗi khẩn cấp này không thay thế bản sửa lỗi khẩn cấp đã phát hành trước đó.

Thông tin về tệp

Phiên bản tiếng Anh của hotfix này có các thuộc tính tệp (hoặc sau này tập tin thuộc tính) mà được liệt kê trong bảng sau. Ngày tháng và thời gian cho những tập tin được liệt kê trong giờ phối hợp quốc tế (UTC). Khi bạn xem chi tieát taäp tin, nó được chuyển đổi thành giờ cục bộ. Để biết sự khác nhau giữa UTC và local time, sử dụng các Múi giờ thẻ tab trong các Ngaøy giôø mục trong bảng điều khiển.

Tên tệpPhiên bản tệpKích thước tệpNgàyGiờNền tảng
Microsoft.Solutions.btahl7.mllp.dll3.9.526.2116,60807-Jun-201115: 27x86
Microsoft.Solutions.btahl7.Shared.dll3.9.526.292,04007-Jun-201115: 27x86
Mllpreceive.exe3.9.526.226.456 người07-Jun-201115: 27x86
Mllpsend.exe3.9.526.226,44807-Jun-201115: 27x86


Về các hotfix

Dòng chảy thông báo sau khi các hotfix cài đặt và cấu hình

Sau khi bạn áp dụng và cho phép hotfix này, các bộ chuyển đổi MLLP nộp bất kỳ thư nào đó được nhận bởi các bộ chuyển đổi MLLP để MessageBoxDB. Quản lý điểm kết thúc (EPM) các cuộc gọi trở lại các adapter cùng với trạng thái trình trong các BatchComplete phương pháp. Điều này gây ra các adapter để soạn ACK/NAK cam kết cho hệ thống thượng nguồn. Lần lượt, Thượng lưu hệ thống nhận được ACK/NAK và sau đó gửi thư tiếp theo. Các BatchComplete phương pháp là độc lập với các MaxReceiveInterval thiết lập và được gọi là ngay lập tức sau khi tin nhắn được gửi đến BizTalk thành công.

Ngay sau khi thông báo đã sẵn sàng để gửi, gửi adapter truyền thông điệp hệ thống hạ nguồn. ACK/NAK dự kiến nếu các Sử dụng xác nhận vận chuyển MLLP tài sản được thiết lập để Sự thật. Nếu gửi một ACK, BizTalk kết thúc việc xử lý thành công. Nếu gửi một NAK, và nếu các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để Sự thật, thư bị đình chỉ trực tiếp mà không có cách. Tuy nhiên, nếu các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để SaiBizTalk sẽ thử lại dựa trên cổng gửi thử lại khoảng thời gian cài đặt. (Theo mặc định, các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để Sai.)

Biểu đồ sau đây cho thấy dòng tin nhắn:
Thông báo dòng chảy
  1. Thư được gửi bởi hệ thống Thượng lưu ứng dụng gửi được xử lý bởi MLLP nhận được bộ điều hợp.
  2. Bộ điều hợp MLLP nộp của thư BizTalk/EPM.
  3. EPM cuộc gọi trở lại các adapter về trạng thái gửi tin nhắn. EPM thực hiện điều này các Hàng loạt hoàn chỉnh phương pháp.
  4. Một cam kết ACK/NAK được tạo ra bởi các adapter MLLP và được dựa trên tình trạng lô trình. ACK/NAK được gửi tới các ứng dụng gửi.

    Chú ý Nếu tình trạng Batch Submission Thành công, bộ điều hợp trả về ACK. Tuy nhiên, nếu có một sự thất bại, hoặc nếu trình thời gian (ví dụ, nếu các Hàng loạt hoàn chỉnh phương pháp gọi lần), bộ điều hợp trả về NAK cho các ứng dụng gửi.

  5. EPM tay qua tin nhắn để gửi MLLP adapter cho truyền dẫn.
  6. MLLP gửi bộ điều hợp sẽ gửi một thông báo chế biến hệ thống hạ nguồn.
  7. Vận chuyển cấp ACK/NAK dự kiến các bộ chuyển đổi gửi MLLP để hoàn thành việc giao tiếp.
  8. Nếu tin nhắn trong bước 7 là một ACK, bộ điều hợp yêu cầu EPM để xóa các tin nhắn. Nếu không, các bộ chuyển đổi đã yêu cầu EPM cho một thử lại dựa trên các thiết lập thời đoạn thử lại. Một lựa chọn mới được cung cấp trong thiết lập cấu hình cổng gửi cho đình chỉ thư trực tiếp, mà không có một thử lại, nếu một NAK MLLP là đã nhận được. Theo mặc định, tùy chọn này được thiết lập để Sai. Nếu tùy chọn này được thiết lập để Sự thật, thông báo sẽ bị đình chỉ trực tiếp, mà không có một thử lại, nếu một NAK MLLP là đã nhận được.

Định dạng cấp ACK/NACK vận tải

Để biết thêm chi tiết về đặc tả vận chuyển, truy cập vào trang web HL7 sau đây:Trang web có chứa các thông tin sau:
  • Ví dụ về một MLLP cam kết ghi nhận:
    <SB><ACK><EB><CR></CR></EB></ACK></SB>
  • Ví dụ của một âm tính MLLP cam kết ghi nhận:
    <SB><NAK><EB><CR></CR></EB></NAK></SB>
Chú ý
  • Trong những ví dụ này, <SB>đề cập đến các nhân vật bắt đầu khối (1 byte). Điều này tương ứng với các <VT>ký tự ASCII, hay <0x0B>.<b00> </b00> </0x0B> </VT> </SB>

    Điều này không nên nhầm lẫn với các nhân vật SOH hoặc STX ASCII.
  • Trong những ví dụ này, <ACK>hoặc <NAK>đề cập đến các ký tự xác nhận (1 byte. Tương ứng với ký tự <ACK>ASCII hoặc <0x06>) hoặc nhân vật tiêu cực xác nhận (1 byte. Tương ứng với các <NAK>ký tự ASCII, hay <0x15>).<b00> </b00> </0x15> </NAK> </0x06> </ACK> </NAK> </ACK>
  • Trong những ví dụ này, <EB>đề cập đến các nhân vật kết thúc khối (1 byte). Điều này tương ứng với các <FS>ký tự ASCII, hay <0x1C>.</0x1C> </FS> </EB>
  • Trong những ví dụ này,<CR>đề cập đến các nhân vật trở về vận chuyển (1 byte). Điều này tương ứng với các<CR>Ký tự ASCII, hay <0x0D>.</0x0D></CR></CR>
  • Microsoft cung cấp thông tin liên hệ của bên thứ ba để giúp bạn tìm kiếm trợ giúp kỹ thuật. Thông tin liên hệ này có thể thay đổi mà không thông báo. Microsoft không bảo đảm độ chính xác về thông tin liên hệ của bên thứ ba này.

Làm thế nào để cấu hình nhận và gửi cổng để sử dụng các thuộc tính mới

Cấu hình nhận và gửi cổng như sau.

Chú ý Thiết đặt cổng nhận và gửi có thể được sử dụng một cách độc lập hay với nhau.

Nhận được cấu hình cổng
  • Cổng phải là một cảng một chiều.
  • Các Đặt hàng giao hàng tham số phải được bật.
  • Bạn phải thiết lập các Sử dụng xác nhận vận chuyển MLLP bất động sản để Sự thật để cho phép sự thừa nhận cấp vận tải. Theo mặc định, tài sản này được thiết lập để Sai hiện có cảng hoặc mới cảng.
Nhận được cảng
Gửi cho cấu hình cổng
  • Cổng phải là một cảng một chiều.
  • Chế độ solicit phản ứng phải được thiết lập Không.
  • Các Đặt hàng giao hàng tham số phải được bật.
  • Bạn phải thiết lập các Sử dụng xác nhận vận chuyển MLLP bất động sản để Sự thật để cho phép sự thừa nhận cấp vận tải. Theo mặc định, tài sản này được thiết lập để Sai hiện có cảng hoặc mới cảng.
  • Bạn phải thiết lập các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK bất động sản để Sự thật Nếu các thư cần phải bị đình chỉ trực tiếp mà không được thử lại khi một vận tải NAK nhận được từ một hệ thống hạ nguồn. Nếu không, thông báo sẽ thử lại cho số lần được thiết lập trong vận tải tùy chọn gửi cổng chuyên sâu. Theo mặc định, tài sản này được thiết lập để Sai hiện có cảng hoặc mới cảng.
Gửi cổng

Về bất động sản "Ghi nhận vận tải sử dụng MLLP"

Bảng sau miêu tả hành vi dự kiến của một cách hoặc hai cách cổng đó sử dụng các Sử dụng xác nhận vận chuyển MLLP bất động sản. Sự kết hợp yêu cầu cài đặt này phải được áp dụng như mô tả trong phần "Làm thế nào để kích hoạt các hotfix".

Chú ý
  • "Hệ thống Thượng lưu" đề cập đến các ứng dụng gửi. Nó sẽ gửi tin nhắn đến BizTalk. Các thư này được gửi đến để BizTalk.
  • "Hệ thống hạ lưu" đề cập đến các ứng dụng nhận tin nhắn. Nó nhận được tin nhắn từ BizTalk. Các thư này gửi đi để BizTalk.


Loại cổngMLLP V2 tùy chọn trênMLLP V2 tùy chọn tắt
Một cách nhận đượcGửi MLLP ACK/NAK cho hệ thống thượng nguồn trong các BatchComplete phương pháp.Không có thay đổi trong hành vi. Trong tình huống này, không có ACK/NAK được gửi đến hệ thống thượng nguồn.
Hai cách nhận đượcKhông có thay đổi trong hành vi. Trong tình huống này, HL7 ACK/NAK trong những TransmitMessage phương pháp được gửi đến hệ thống thượng nguồn.

Chú ý Tùy chọn này không được hỗ trợ. Chẳng hạn, bỏ qua ngay cả khi giá trị được thiết lập để Sự thật.
Không có thay đổi trong hành vi. Trong tình huống này, HL7 ACK/NAK trong những TransmitMessage phương pháp được gửi đến hệ thống thượng nguồn.
One-Way gửiMLLP ACK/NAK từ hệ thống hạ nguồn đợi sau khi tin nhắn được truyền đi.Không có thay đổi trong hành vi. Trong tình huống này, ACK/NAK từ hệ thống hạ nguồn không đợi sau khi tin nhắn được truyền đi.
Hai cách gửi hoặc một cách gửi với chế độ thu hút phản ứng được kích hoạtKhông có thay đổi trong hành vi. Trong tình huống này, HL7 ACK/NAK từ hệ thống hạ nguồn đợi sau khi tin nhắn được truyền đi.

Chú ý Tùy chọn này không được hỗ trợ. Chẳng hạn, bỏ qua ngay cả khi giá trị được thiết lập để Sự thật.
Không có thay đổi trong hành vi. Trong tình huống này, HL7 ACK/NAK từ hệ thống hạ nguồn đợi sau khi tin nhắn được truyền đi.


Hai cách nhận và gửi hành vi cổng là không thay đổi. Một cách nhận và gửi cổng hành vi cũng không thay đổi trừ khi các Sử dụng xác nhận vận chuyển MLLP tài sản được thiết lập đúng sự thật.

Để biết thêm chi tiết, xem tài liệu hướng dẫn điều hợp MLLP. Nếu một cách nhận và gửi cổng có các cấu hình thích hợp, hiệu suất cải thiện. Nếu Sử dụng xác nhận vận chuyển MLLP tài sản của một cổng hai chiều hoặc một cổng chiều được đặt thành false, loại ACK được tạo tiếp tục mà không cần thay đổi. Trong tình huống này, loại ACK được tạo phụ thuộc vào các cài đặt BTAHL7 cấu hình Explorer cho ứng dụng là gửi thư. Giá trị trong các lĩnh vực MSH 15MSH 16 của một thông báo cụ thể có thể ghi đè thiết đặt này. Tuy nhiên, nếu các Sử dụng xác nhận vận chuyển MLLP tài sản của một cổng hai chiều hoặc một cổng một chiều được đặt thành false, bạn có thể đặt cấu hình cho các ứng dụng mong đợi tĩnh ACKs chỉ bằng cách sử dụng nhà thám hiểm cấu hình BTAHL7. Hành vi gian chờ cho cổng vẫn không thay đổi...

Các hành vi mong đợi trong góc trường hợp khi các thuộc tính được sử dụng là như sau:

NHẬN ĐƯỢC
  • WrongMLLPFormat: thông điệp không nộp cho BizTalk.
  • WrongHL7Format: thư được gửi đến BizTalk, và một MLLP ACK/NAK được truyền mà dựa trên tình trạng Batch hoàn thành.
  • TransmittingSocketIssue: MLLP ACK/NAK không truyền, mặc dù thông báo đã nộp để BizTalk.
  • ReceivingSocketIssue: thư chưa nhận được và do đó không được gửi, và không có MLLP ACK/NAK truyền được gửi.
  • Nếu một trình BizTalk thất bại, một NAK được truyền đi.
  • Nếu tình trạng tiêu cực của hàng loạt hoàn chỉnh được nhận, một NAK được truyền đi.
GỬI và gửi cổng bất động sản "ngừng gửi thư tiếp sau đến về hiện tại tin nhắn thất bại" = True
  • WrongMLLPFormat: thư bị ngưng vì không thể đọc được MLLP ACK/NACK. Xử lý sẽ không tiếp tục cho đến khi bị đình chỉ các tin nhắn được xóa.
  • WrongHL7Format: thông điệp không trước khi nó đạt đến các bộ chuyển đổi. Xử lý sẽ không tiếp tục cho đến khi bị đình chỉ các tin nhắn được xóa.
  • TransmittingSocketIssue: thư bị đình chỉ. Xử lý sẽ không tiếp tục cho đến khi bị đình chỉ các tin nhắn được xóa.
  • ReceivingSocketIssue: thư bị đình chỉ. Xử lý sẽ không tiếp tục cho đến khi bị đình chỉ các tin nhắn được xóa.

Hành vi mong đợi khi các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để Sự thật hoặc đến Sai là như sau:
  • Khi các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để Sự thật và một NAK nhận được, thư bị đình chỉ mà không có một thử lại để gửi nó.
  • Khi các Đình chỉ yêu cầu thông báo trên MLLP vận tải NAK tài sản được thiết lập để thiết lập mặc định của Sai, một thử lại để gửi thông điệp bắt đầu, dựa trên cổng gửi thử lại khoảng thời gian cài đặt.

Thay đổi đối với các tiện ích MLLP SDK

MLLP SDK hữu ích bao gồm các thông số mới sau đây. Tất cả các thông số khác vẫn không thay đổi. Để biết thêm thông tin, tham khảo tài liệu sản phẩm.
  • Đối với MLLPReceive.exe, sử dụng tham số mới để trở về MLLP ACK/NAK sau khi nhận được tin nhắn. Ví dụ:
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
  • Đối với MLLPSend.exe, sử dụng tham số mới phải chờ đợi cho MLLP ACK/NAK. Ví dụ:
    MLLPSend /sb 11 /eb 28 /cr 13 /f "C:\HL7\ls.txt" / i 127.0.0.1 /p 11000 /UseMLLPTransACK
THAM KHẢO
Để biết thêm chi tiết về làm thế nào để quản lý các thiết đặt hiệu năng trong BizTalk server, truy cập vào trang web Microsoft Developer Network (MSDN) sau đây:Để biết thêm chi tiết về tin nhắn hiệu suất quầy, truy cập trang web MSDN sau đây:Để biết thêm chi tiết về đặt hàng giao hàng của thư, truy cập trang web MSDN sau đây:Để biết thêm về BizTalk 2010 họa cho HL7 (BTAHL7), truy cập vào trang web của Microsoft sau đây:Để biết thêm thông tin về các IBTBatchCallBack.BatchComplete phương pháp, truy cập vào trang web MSDN sau đây:Để biết thêm chi tiết về máy chủ BizTalk hotfixes, nhấp vào số bài viết sau đây để xem bài viết trong cơ sở kiến thức Microsoft:
2003907 Thông tin về máy chủ BizTalk hotfixes

Cảnh báo: Bài viết này đã được dịch tự động

Thuộc tính

ID Bài viết: 2564013 - Xem lại Lần cuối: 11/01/2011 07:53:00 - Bản sửa đổi: 2.0

  • Microsoft BizTalk Server Branch 2010
  • Microsoft BizTalk Server Developer 2010
  • Microsoft BizTalk Server Enterprise 2010
  • Microsoft BizTalk Server Standard 2010
  • kbautohotfix kbqfe kbhotfixserver kbfix kbsurveynew kbexpertiseinter kbbug kbmt KB2564013 KbMtvi
Phản hồi