TIÊU CHUẨN QUỐC GIA TCVN 12345:2019 VỀ TIÊU CHUẨN VỀ DỊCH VỤ THÔNG TIN EPC

TIÊU CHUẨN QUỐC GIA

TCVN 12345:2019

TIÊU CHUẨN VỀ DỊCH VỤ THÔNG TIN EPC

EPC information Services (EPCIS) Standard

Lời nói đầu

TCVN 12345:2019 tương đương có sửa đổi với ISO/IEC 19987:2017.

TCVN 12345:2019 do Tiểu Ban kĩ thuật tiêu chuẩn quốc gia TCVN/JTC1/SC31 Thu thập dữ liệu tự động biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

 

Lời giới thiệu

Mục đích của EPCIS là nhằm cho phép các ứng dụng khác nhau thiết lập và chia sẻ dữ liệu về sự kiện có khả năng hiển thị cả bên trong doanh nghiệp cũng như thông qua các doanh nghiệp. Tóm lại, sự chia sẻ này nhằm cho phép người sử dụng đạt được sự thấu hiểu về đối tượng vật lý hoặc đối tượng số hóa trong điều kiện kinh doanh thích hợp

“Đối tượng” trong khuôn khổ của EPCIS bao gồm các đối tượng vật lý, các đối tượng này được xác định bởi loại hay cấp độ cá thể và chúng được xử lý trong các công đoạn xử lý của toàn bộ quá trình kinh doanh liên quan đến một hay nhiều tổ chức. Ví dụ về đối tượng vật lý gồm các thương phẩm (sản phẩm), đơn vị hậu cần (logistic), tài sản lưu động và tài sản cố định, tài liệu dạng cứng, v.v… “Đối tượng” cũng có thể là đối tượng số hóa và cũng được xác định bởi loại và cấp độ cá thể mà chúng tham gia vào các công đoạn của quá trình kinh doanh có thể so sánh được. Ví dụ về đối tượng số hóa gồm các thương phẩm số hóa (nhạc phẩm tải về, sách điện tử, v. v…), các tài liệu số hóa (phiếu điện tử, v.v…) và tương tự. Trong toàn bộ tiêu chuẩn này, từ “đối tượng” được sử dụng để chứng tỏ một đối tượng vật lý hay đối tượng số hóa được xác định bởi loại hay cấp độ cá thể là đối tượng công đoạn của quá trình kinh doanh. Dữ liệu EPCIS bao gồm “các sự kiện rõ ràng” trong đó mỗi sự kiện là một hồ sơ hoàn thành một công đoạn của quá trình kinh doanh cụ thể diễn ra trước một hay nhiều đối tượng.

Tiêu chuẩn EPCIS này nhằm tăng cường sự hợp tác giữa các đối tác thương mại thông qua sự chia sẻ các thông tin cụ thể về các đối tượng vật lý hay đối tượng số hóa. Tên của EPCIS phản ánh nguồn gốc về sự nỗ lực phát triển mã điện tử sản phẩm (EPC). Tuy nhiên, cần lưu ý rằng EPCIS không yêu cầu việc sử dụng mã điện tử sản phẩm cũng như nhà cung cấp dữ liệu mã tần số radio (FRID), và giống như EPCIS phiên bản 1.2 thậm chí không yêu cầu việc xác định cấp độ cá thể (mà mã điện tử sản phẩm đã được thiết kế ban đầu). Tiêu chuẩn EPCIS này áp dụng cho tất cả các tình huống mà dữ liệu về các sự kiện rõ ràng được truy cập và chia sẻ, và sự hiện diện của “EPC” với cái tên này chỉ có ý nghĩa về mặt lịch sử

EPCIS cung cấp các giao diện mở, được tiêu chuẩn hóa cho phép tích hợp liên tục các dịch vụ được thiết kế tốt trong các môi trường liên công ty cũng như trong nội bộ các công ty. Các giao diện chuẩn được xác định trong tiêu chuẩn EPCIS này cho phép truy cập và phân tích các dữ liệu về sự kiện rõ ràng nhờ sử dụng bộ tiêu chuẩn về hoạt động dịch vụ và các dữ liệu tập hợp được, tất cả được kết hợp với bộ máy an ninh thích hợp mà nó thỏa mãn nhu cầu sử dụng của các công ty. Trong nhiều trường hợp hay hầu hết các trường hợp điều này liên quan đến việc sử dụng một hay nhiều cơ sở dữ liệu vững chắc có dữ liệu về sự kiện rõ ràng, mặc dù các thành phần tiếp cận dịch vụ có thể được sử dụng để chia sẻ trực tiếp ứng dụng lẫn nhau mà không có cơ sở dữ liệu vững chắc

Dù có hay không có cơ sở dữ liệu vững chắc, EPCIS chỉ quy định một giao diện dữ liệu tiêu chuẩn chung giữa các ứng dụng truy cập dữ liệu về sự kiện rõ ràng và các dữ liệu cần tiếp cận đến. EPCIS không quy định cách thức mà các hoạt động dịch vụ hay chính bản thân các cơ sở dữ liệu sẽ được thực hiện. Điều này bao gồm việc không xác định cách thức dịch vụ EPCIS này có được và/hoặc tính toán được các dữ liệu mà các dịch vụ cần, ngoại trừ việc mở rộng dữ liệu truy cập có sử dụng các hoạt động truy cập EPCIS tiêu chuẩn. Giao diện này cần thiết cho khả năng tương tác, còn việc thực hiện là để cho phép cạnh tranh giữa các nhà cung cấp công nghệ và người thực hiện tiêu chuẩn.

EPCIS dự kiến sử dụng kết hợp với tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính (CBV) của GS1 (CVB1.2). Tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính cung cấp các định nghĩa về giá trị các dữ liệu mà chúng có thể dùng để phổ biến cấu trúc dữ liệu được xác định trong tiêu chuẩn EPCIS. Việc sử dụng từ vựng tiêu chuẩn cho trong tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính là quan trọng cho khả năng tương tác và quan trọng cho việc phân tích/truy vấn dữ liệu để giảm thiểu sự khác biệt mà các tổ chức kinh doanh khác nhau thể hiện cùng một ý định. Chính vì vậy các ứng dụng cần sử dụng tiêu chuẩn CBV tối đa đến mức có thể khi xây dựng dữ liệu EPCIS.

Phần hướng dẫn thực hiện đồng thời EPCIS và CBV cung cấp hướng dẫn bổ sung cho việc xây dựng các hệ thống rõ ràng/ xác thực khi sử dụng EPCIS và CBV, kể cả việc thảo luận kỹ lưỡng cách mô hình hóa các tình huống kinh doanh cụ thể khi sử dụng dữ liệu EPCIS / CBV và phương pháp chia sẻ dữ liệu giữa các đối tác thương mại.

Về khái niệm và các quy ước về chữ in: Toàn bộ các phần của tiêu chuẩn này cùng với ngoại lệ của phần 3, 4, 4.5 đều là bắt buộc trừ khi có ghi không bắt buộc.

Các kí hiệu quy ước in được sử dụng xuyên suốt tiêu chuẩn này:

– Toàn bộ chữ IN HOA được sử dụng cho các thuật ngữ đặc thù trong (ISODir2) được liệt kê ở trên.

– Kiểu đơn cách được sử dụng để chỉ rõ ngôn ngữ lập trình, mã phân định UML, và XML cũng như đối với phần nội dung của tài liệu XML.

Các phần giữ chỗ để thay đổi mà cần được thực hiện cho tiêu chuẩn này trước giai đoạn tiêu chuẩn GS1 được thông qua được bắt đầu bằng mũi tên hướng về phía trước như ở đoạn này.

 

TIÊU CHUẨN VỀ DỊCH VỤ THÔNG TIN EPC

EPC information Services (EPCIS) Standard

1  Phạm vi áp dụng

Tiêu chuẩn này là nhằm cho phép các ứng dụng khác nhau thiết lập và chia sẻ dữ liệu về sự kiện có khả năng hiển thị cả bên trong doanh nghiệp cũng như thông qua các doanh nghiệp. Sự chia sẻ này nhằm cho phép người sử dụng đạt được sự thấu hiểu về đối tượng vật lý hoặc đối tượng số hóa trong điều kiện kinh doanh thích hợp.

2  Tài liệu viện dẫn

Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

TCVN 8656 Công nghệ thông tin – Kĩ thuật phân định và thu nhận dữ liệu tự động (AIDC) – Thuật ngữ hài hòa;

TCVN 9086 Mã số mã vạch GS1 – Thuật ngữ và định nghĩa;

EPC Global Architecture Framework (EPCAF) (Khung kiến trúc toàn cầu EPC);

GS1 Architecture (Kiến trúc GS1);

GS1 General Specification (Quy định kĩ thuật chung của GS1).

3  Thuật ngữ và định nghĩa

Trong tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa quy định trong TCVN 8656 và TCVN 9086.

4  Mối quan hệ với cấu trúc hệ thống GS1 và nguyên tắc về các quy định của EPCIS

Tiêu chuẩn này phần lớn được trích dẫn từ (EPCAF) và (GS1Arch) và cho thấy mối quan hệ của EPCIS với các tiêu chuẩn GS1 khác.

4.1  Tổng quan về tiêu chuẩn GS1

Tiêu chuẩn GS1 hỗ trợ những thông tin cần thiết cho những người sử dụng cuối cùng có tương tác với nhau trong chuỗi cung cấp, đặc biệt những thông tin được yêu cầu hỗ trợ trong quá trình kinh doanh mà thông qua các thông tin này các bên tham gia trong chuỗi cung cấp tương tác. Các đối tượng thông tin này bao gồm các thực thể là một phần của các quá trình kinh doanh. Các thực thể gồm những thứ được mua bán giữa các công ty như sản phẩm, bán sản phẩm, vật liệu thô, bao gói, v.v… Các thực thể khác phù hợp với các đối tác thương mại gồm các thiết bị, phương tiện vận chuyển, máy móc; thực thể tương ứng với địa điểm có thực mà ở đó các quá trình kinh doanh được thực hiện; các pháp nhân như các công ty, phòng ban; bộ phận quan hệ dịch vụ; các bộ phận giao dịch và tài liệu kinh doanh; và những thực thể khác. Các thực thể có thể tồn tại trong thế giới hữu hình, hoặc dạng số hóa hoặc dạng khái niệm. Ví dụ 8 về các đối tượng vật lý gồm sản phẩm điện tử dân dụng, công-ten-nơ vận chuyển và mặt bằng sản xuất. Ví dụ về các đối tượng dạng số hóa gồm phần mềm âm nhạc điện tử, sách điện tử và phiếu điện tử. Ví dụ về các thực thể dạng khái niệm gồm loại thương phẩm, loại sản phẩm và pháp nhân.

Các tiêu chuẩn GS1 có thể chia theo các nhóm dưới đây căn cứ vào vai trò của chúng trong việc hỗ trợ nhu cầu về thông tin liên quan đến các thực thể trong chuỗi cung cấp của các quá trình kinh doanh:

– Các tiêu chuẩn cung cấp công cụ để phân định các thực thể theo cách mà chúng có thể trở thành đối tượng thông tin điện tử được người sử dụng cuối cùng lưu trữ và/hoặc truyền đạt, trao đổi. Các tiêu chuẩn về phân định của GS1 gồm các tiêu chuẩn để xác định mã phân định đơn nhất (còn gọi là các chìa khóa phân định GS1).

– Các tiêu chuẩn cung cấp công cụ để truy cập tự động dữ liệu được thực hiện trực tiếp tại đối tượng vật lý, nó kết nối thế giới vật chất với thế giới thông tin điện tử. Các tiêu chuẩn truy cập dữ liệu của GS1 gồm các định nghĩa về mã vạch và nhà cung cấp dữ liệu phân định bằng tần số radio (FRID), điều này cho phép dán mã phân định trực tiếp lên đối tượng vật lý, và các tiêu chuẩn quy định các giao diện thích hợp cho máy đọc, máy in, và các phần cứng và phần mềm khác mà chúng kết nối nhà cung cấp dữ liệu với các ứng dụng kinh doanh.

– Các tiêu chuẩn cung cấp công cụ để chia sẻ thông tin trong nội bộ các đối tác thương mại và giữa các đối tác thương mại đồng thời cung cấp nền tảng cho các giao dịch kinh doanh điện tử, khả năng hiển thị điện tử của thế giới vật lý/vật chất hoặc thế giới số hóa, và các ứng dụng thông tin khác. Các tiêu chuẩn của GS1 để chia sẻ thông tin bao gồm tiêu chuẩn EPCIS này, nó là tiêu chuẩn về dữ liệu sự kiện rõ ràng. Các tiêu chuẩn khác trong nhóm “chia sẻ” này là các tiêu chuẩn về dữ liệu chủ và tiêu chuẩn về dữ liệu giao dịch kinh doanh, cũng như tiêu chuẩn có tính khám phá giúp cho việc xác định nơi các dữ liệu có liên quan trong suốt chuỗi cung ứng và các tiêu chuẩn về độ tin cậy giúp thiết lập các điều kiện để chia sẻ dữ liệu với độ an toàn cao.

Tiêu chuẩn EPCIS này phù hợp với nhóm “chia sẻ”, nó cung cấp tiêu chuẩn dữ liệu đối với các dữ liệu về sự kiện rõ ràng và các tiêu chuẩn giao diện nhằm truy cập thông tin từ cơ sở dữ liệu truy cập (sử dụng các tiêu chuẩn từ nhóm “truy cập”) và để chia sẻ chính những thông tin này với các ứng dụng kinh doanh và các đối tác thương mại.

4.2  EPCIS trong mối quan hệ với các tầng “Truy cập” và “Chia sẻ”

Sơ đồ dưới đây chỉ ra mối quan hệ giữa EPCIS và các tiêu chuẩn GS1 khác trong các nhóm “Truy cập” và “Chia sẻ”, (nhóm tiêu chuẩn về “Phân định” có rất nhiều dữ liệu ở các cấp độ của cấu trúc này, và vì vậy không thể thể hiện hết ra được).

Hình 1 – Mối quan hệ giữa EPCIS và các tiêu chuẩn GS1 khác

Như mô tả ở hình trên, giao diện truy vấn EPCIS tồn tại như một cầu nối giữa các tiêu chuẩn về “truy cập” và “chia sẻ”. Giao diện truy vấn/phân tích của tiêu chuẩn này cung cấp các dữ liệu rõ ràng cho các ứng dụng nội bộ và để chia sẻ với các đối tác thương mại.

Tại trung tâm của ứng dụng truy cập dữ liệu là lưu đồ hoạt động truy cập dữ liệu, nó giám sát quá trình kinh doanh mà việc truy cập dữ liệu diễn ra. Đây là lôgic mang tính tập quán/tùy chỉnh điển hình dành riêng cho ứng dụng này. Phía dưới lưu đồ hoạt động truy cập dữ liệu trong sơ đồ là đường truyền dữ liệu giữa lưu đồ hoạt động và nhà cung cấp dữ liệu GS1: mã vạch và RFID. Các vạch màu xanh trên sơ đồ có nghĩa là các tiêu chuẩn GS1 có thể sử dụng làm giao diện cho nhà cung cấp dữ liệu. Phía trên lưu đồ hoạt động truy cập dữ liệu là giao diện giữa lưu đồ hoạt động truy cập dữ liệu và các ứng dụng có quy mô lớn của các doanh nghiệp. Nhiều những giao diện này là ứng dụng hoặc đặc thù của doanh nghiệp, mặc dù sử dụng dữ liệu GS1 như là building blocks (làm nền tảng), tuy nhiên, giao diện EPCIS là tiêu chuẩn GS1. Lưu ý rằng giao diện phía trên của sơ đồ, kể cả EPCIS là độc lập với nhà cung cấp dữ liệu sử dụng ở phía dưới của sơ đồ.

Mục đích của các giao diện và lý do vì sao cấu trúc truy cập dữ liệu có nhiều tầng là để tạo sự khác biệt giữa các mức trừu tượng khác nhau. Nhìn từ quan điểm của một doanh nghiệp (cụ thể từ hộp màu xanh trên cùng trong hình), toàn bộ ứng dụng truy cập dữ liệu bảo vệ các ứng dụng của doanh nghiệp tránh những chi tiết/tiểu tiết một cách chính xác cách thức truy cập dữ liệu đã diễn ra. Thông qua giao diện mức ứng dụng (các thanh màu xanh lá cây phía trên cùng) một ứng dụng của doanh nghiệp tương tác với lưu đồ hoạt động truy cập dữ liệu thông qua dữ liệu độc lập với nhà cung cấp dữ liệu và trong đó tất cả các tương tác giữa các thành phần truy cập dữ liệu đã được hợp nhất vào dữ liệu đó. ở một mức thấp hơn, lưu đồ hoạt động truy cập dữ liệu là để phát hiện/nhận biết xem nó có tương tác với máy quét mã vạch, bộ dò tín hiệu, đầu vào của con người, v.v. hay không, còn các giao diện truyền này (các vạch màu xanh lá cây ở giữa) bảo vệ quy trình hoạt động truy cập dữ liệu tránh những chi tiết/tiểu tiết của phần cứng có mức thấp một cách chính xác cách thức các nhà cung cấp dữ liệu làm việc. Các giao diện có mức thấp nhất (vạch màu xanh lá cây ở phía dưới cùng) thể hiện những chi tiết của nhà cung cấp dữ liệu nội bộ đó. EPCIS và tầng “chia sẻ” này nhìn chung khác với các phần tử trong tầng truy cập ở ba khía cạnh chính:

1. EPCIS đề cập một cách rõ ràng những dữ liệu có tính lịch sử (bổ sung cho dữ liệu hiện tại). Tầng truy cập này, ngược lại được định hướng riêng cho việc xử lý theo thời gian thực của dữ liệu truy cập.

2. EPCIS thường đề cập không chỉ dữ liệu thô truy cập từ nhà cung cấp dữ liệu như mã vạch và thẻ FRID, mà còn trong các tình huống thấy rõ những phát hiện có ý nghĩa liên quan đến thế giới thực hoặc thế giới số hóa và các bước cụ thể trong quá trình hoạt động hoặc phân tích các quá trình kinh doanh. Các tầng truy cập thường phát hiện thấy thuần túy / purely hơn về bản chất. Một sự kiện EPCIS chứa nhiều dữ liệu “phân định” như nhau như sự kiện sàng lọc và thu thập hoặc quét mã vạch ở mức cao hơn bởi vì nó kết hợp sự thông hiểu về bối cảnh kinh doanh mà trong bối cảnh đó các dữ liệu mã phân định đã nhận được. Hơn nữa không có yêu cầu nêu rằng một sự kiện EPCIS là liên quan trực tiếp đến phát hiện của nhà cung cấp dữ liệu vật lý cụ thể. Ví dụ một sự kiện EPCIS có thẻ chỉ ra rằng một thương phẩm dễ bị hư hỏng chỉ sau ngày hết hạn: một sự kiện như vậy có thể phát sinh thuần túy bởi phần mềm.

3. EPCIS hoạt động trong môi trường IT của doanh nghiệp ở mức độ dạng hơn nhiều và đa mục đích hơn so với nó tồn tại trong tầng truy cập, ở đây hệ thống điển hình là độc lập và tồn tại để phục vụ mục đích kinh doanh. Một phần và cũng là điều quan trọng nhất đó là do mong muốn chia sẻ các dữ liệu EPCIS giữa các doanh nghiệp mà họ có thể có các giải pháp khác nhau để thực hiện nhiệm vụ tương tự. Một phần, cũng là do bản chất kiên định/ổn định / persistent của dữ liệu EPCIS. Và cuối cùng là do EPCIS tồn tại ở mức cao nhất trong cấu trúc tổng thể, và vì vậy điểm tự nhiên xâm nhập vào hệ thống doanh nghiệp khác sẽ khác xa giữa một doanh nghiệp với doanh nghiệp tiếp theo (hoặc thậm chí trong các bộ phận của cùng doanh nghiệp).

4.3  EPCIS trong mối quan hệ với các đối tác thương mại

Tiêu chuẩn GS1 trong tầng “Chia sẻ” liên quan đến ba loại dữ liệu mà nó được chia sẻ giữa những người sử dụng cuối cùng:

Bảng 1 – Các loại dữ liệu được chia sẻ giữa những người sử dụng cuối cùng

Dữ liệu	Mô tả	Tiêu chuẩn GS1
Dữ liệu chủ	Dữ liệu được chia sẻ bởi một đối tác thương mại với nhiều đối tác thương mại mà nó cung cấp các thuộc tính mô tả về các thực thể của thế giới thực được phân định bởi những mã khóa nhận dạng của GS1, bao gồm những thương phẩm, các bên và vị trí vật lý	GDSN
Dữ liệu giao dịch	Các giao dịch thương mại kích hoạt hoặc xác nhận kích hoạt của một chức năng nào đó trong quá trình kinh doanh như được xác định bởi một thỏa thuận kinh doanh rõ ràng (ví dụ, một hợp đồng cung cấp) hoặc một thỏa thuận kinh doanh rõ ràng (ví dụ, xử lý của hải quan), từ khi bắt đầu quá trình kinh doanh (ví dụ, đặt hàng) đến khi kết thúc (ví dụ, thanh quyết toán) đều sử dụng mã khóa nhận dạng của GS1	GS1 XML EANCOM
Dữ liệu sự kiện rõ ràng	Chi tiết về hoạt động vật lý và số hóa trong chuỗi cung cung cấp sản phẩm và các tài sản khác được xác định bởi các mấu chốt/chìa khóa, cụ thể nơi chúng đến đúng giờ, và vì sao không ở tại một nơi của bốn tổ chức mà dàn trải ra các tổ chức	EPCIS

Dữ liệu giao dịch và dữ liệu về sự kiện rõ ràng có đặc tính là các tài liệu mới của loại này liên tục được tạo ra khi nhiều doanh nghiệp được giao dịch trong chuỗi cung cấp một cách ổn định, thậm chí khi không có thực thể của thế giới thực được tạo ra. Dữ liệu chủ, ngược lại thường tĩnh hơn: Dữ liệu chủ đối với một thực thể đã cho/nhất định thay đổi rất chậm (nếu ở tất cả), và lượng dữ liệu chủ chỉ tăng khi các thực thể mới được tạo ra, không chỉ đơn thuần vì các thực thể đang tồn tại tham gia vào quá trình kinh doanh. Ví dụ khi một ý đồ của thương phẩm nhất định xuyên suốt chuỗi cung cấp, thì dữ liệu giao dịch mới và dữ liệu về sự kiện rõ ràng được tạo ra khi cá thể đó trải qua các giao dịch kinh doanh (như mua và bán) và các quá trình vận chuyển vật lý/vật chất (đóng gói, bốc, dỡ v. v…). Thế nhưng dữ liệu chủ mới chỉ được tạo ra khi thương phẩm mới hoặc vị trí được bổ sung vào chuỗi cung cấp

Hình dưới đây minh họa luồng dữ liệu giữa các đối tác thương mại nhấn mạnh vào các phần của tiêu chuẩn EPCIS có liên quan đến luồng dữ liệu về sự kiện rõ ràng

Hình 2 – Giao diện truy vấn/phân tích

Ngoài việc sử dụng giao diện truy vấn/phân tích minh họa ở trên, các đối tác thương mại thông qua các thỏa thuận lẫn nhau có thể sử dụng cấu trúc tài liệu EPCIS được xác định ở phần 9.3 làm phương tiện để truyền tải một tập hợp sự kiện EPCIS tùy chọn kèm theo dữ liệu chủ có liên quan dưới dạng một tài liệu điện tử duy nhất.

4.4  EPCIS trong mối quan hệ với các thành phần cấu trúc của hệ thống GS1 khác

Sau đây là các nét chính về trách nhiệm đối với từng phần tử của cấu trúc hệ thống GS1 như đã minh họa trên hình trong phần trước.

– Máy đọc RFID và mã vạch phát hiện thẻ RFID khi nó ở vùng đọc và phát hiện mã vạch khi máy đọc kích hoạt.

– Giao diện theo chương trình của máy đọc (RFID) mức thấp (LLRP) xác định việc kiểm soát và phân phối nội dung đọc thô của thẻ FRID từ máy đọc đến bộ phận chức năng lọc và tập hợp. Sự kiện tại giao diện này nêu “Máy đọc A đã thấy EPC X vào thời điểm T”

– Lọc & thu thập. Vai trò này lọc và thu thập nội dung đọc thô của thẻ RFID, sau những khoảng thời gian được giới hạn bởi các sự kiện được xác định bởi ứng dụng truy cập EPCIS (ví dụ kích hoạt một máy dò chuyển động). Không có vai trò so sánh nào tồn tại cho việc đọc mã vạch, bởi vì máy đọc mã vạch thường chỉ đọc một mã vạch duy nhất khi nó được kích hoạt

– Giao diện lọc & thu thập (ALC) xác định việc kiểm soát và phân phối dữ liệu đọc đã được lọc và thu thập của thẻ FRID từ bộ phận chức năng lọc và tập hợp đến bộ phận chức năng trong lưu đồ hoạt động truy cập dữ liệu. Sự kiện tại giao diện nêu “Tại máy đọc logic L, giữa thời điểm T1 và T2, các EPC sau đây đã được phát hiện”, ở đây danh sách các EPC không có bản sao và đã từng được lọc theo tiêu chí được xác định bởi ứng dụng truy cập EPCIS. Trong trường hợp mã vạch, dữ liệu so sánh được phân phối trực tiếp đến bộ phận chức năng trong lưu đồ truy cập dữ liệu từ máy đọc mã vạch dưới dạng chuỗi phần tử GS1.

– Lưu đồ hoạt động truy cập dữ liệu giám sát hoạt động của các phần tử cấu trúc mức thấp hơn và cung cấp bối cảnh kinh doanh bằng cách kết hợp với các nguồn thông tin khác liên quan đến việc thực hiện một bước cụ thể của quá trình kinh doanh. Lưu đồ hoạt động truy cập dữ liệu có thể, ví dụ kết hợp hệ thống băng tải với sự kiện lọc & thu thập và đọc mã vạch, có thể kiểm tra đối với trường hợp ngoại lệ và thực hiện các hành động khắc phục (ví dụ: chuyển đối tượng xấu vào khu vực làm lại), có thể trình bày thông tin với người phụ trách nhân sự v.v… Lưu đồ hoạt động truy cập dữ liệu làm rõ bước của quá trình kinh doanh hoặc các bước mà việc truy cập dữ liệu về sự kiện EPCIS diễn ra. Vai trò này có thể phức tạp liên quan đến sự kết hợp của nhiều sự kiện lọc và thu thập và/ hoặc đọc mã vạch với một hay nhiều sự kiện kinh doanh như khi bốc xếp một lô hàng. Hoặc nó có thể được chuyển thẳng như trong quá trình kinh doanh hàng tồn kho mà ở đây có thể có máy đọc được triển khai để phát hiện về các đối tượng xâm nhập hoặc di dời khỏi giá để hàng. Tại đây, sự kiện lọc, sự kiện mức thu thập hoặc dọc mã vạch và sự kiện mức EPCIS có thể quá giống nhau dẫn đến rất ít quá trình xử lý thực tế ở mức quy trình hoạt động truy cập dữ liệu là cần thiết, và quy trình hoạt động truy cập dữ liệu này đơn thuần là định cấu hình, định tuyến các sự kiện từ giao diện lọc và thu thập và/ hoặc các máy đọc mã vạch trực tiếp thông qua giao diện truy vấn EPCIS đến một kho lưu trữ EPCIS hoặc một ứng dụng kinh doanh nào đó. Một lưu đồ hoạt động truy cập dữ liệu có đầu ra ban đầu gồm các sự kiện EPCIS được gọi là một “ứng dụng truy cập EPCIS” trong tiêu chuẩn này.

– Giao dịch EPCIS. Giao dịch thông qua chúng dữ liệu EPCIS được phân phối đến các cấp của doanh nghiệp theo vai trò (phòng ban chức năng của doanh nghiệp), gồm kho lưu trữ EPCIS, ứng dụng truy cập EPCIS, and trao đổi dữ liệu với các đối tác. Các sự kiện giao diện này nêu, ví dụ, “Tại địa điểm X, vào thời điểm T, các đối tượng chứa sau đây (thùng) đã được kiểm tra xác nhận là được tập hợp đến đối tượng để chứa sau đây (pallet)”. Trên thực tế có ba giao diện EPCIS. Giao diện truy vấn EPCIS xác định sự phân bố các sự kiện EPCIS từ ứng dụng truy cập EPCIS đến các vai trò khác sử dụng trong thời gian thực, gồm kho lưu trữ EPCIS và thời gian thực “thúc đẩy” ứng dụng truy cập EPCIS và các đối tác thương mại. Giao diện kiểm soát truy vấn EPCIS xác định cách thức ứng dụng truy cập EPCIS và các đối tác thương mại để nhận dữ liệu EPCIS phụ thuộc vào truy cập, thường bởi giao dịch với kho lưu trữ EPCIS. Giao diện kiểm soát truy vấn EPCIS xác định hai phương thức giao dịch. Trong phương thức “đúng nhu cầu” hoặc “đồng bộ”, một khách hàng đưa ra một yêu cầu thông qua Giao diện kiểm soát truy vấn EPCIS và ngay lập tức nhận được đáp ứng. Trong phương thức “yêu cầu đứng” hay “không đồng bộ” một khách hàng lập một đăng kí truy vấn/tư vấn định kì. Mỗi lần truy vấn định kì được thực hiện, kết quả được phân bổ một cách không đồng bộ (hoặc “thúc đẩy”) đến người nhận thông qua giao diện gọi lại truy vấn EPCIS. giao diện gọi lại truy vấn EPCIS có thể được sử dụng để phân bổ thông tin ngay khi truy cập; điều này tương ứng với mũi tên “có thể bỏ qua để đẩy thời gian thực” trong sơ đồ. Tất cả ba giao diện EPCIS này thường được quy định trong tiêu chuẩn này.

– Ứng dụng truy cập EPCIS: Trách nhiệm thực hiện các quá trình kinh doanh tổng thể của doanh nghiệp, như quản lý kho, giao nhận, phân tích các nguồn thông tin có tính lịch sử, nhờ vậy mà được hỗ trợ bởi các dữ liệu EPC-liên quan.

– Kho lưu trữ EPCIS-kích hoạt: Ghi lại những sự kiện EPCIS-mức được tạo ra bởi một hay nhiều ứng dụng truy cập EPCIS, và sẵn có cho truy vấn về sau nhờ các ứng dụng truy cập EPCIS.

– Ứng dụng đối tác: Hệ thống đối tác thương mại thực hiện cùng một vai trò như ứng dụng truy cập EPCIS, mặc dù từ bên ngoài mạng phản hồi của các bên. Ứng dụng đối tác có thể cho truy cập vào một tập hợp thông tin con có sẵn trong ứng dụng truy cập EPCIS hoặc trong kho lưu trữ EPCIS.

Giao diện trong ngăn xếp này được thiết kế để cách ly những tầng cao hơn của cấu trúc với những chi tiết không cần thiết sao cho các tầng thấp hơn được thực hiện. Có một cách để hiểu điều này đó là xem điều gì sẽ xảy ra nếu thực hiện một vài thay đổi nhất định:

– Giao thức đọc (LLRP) tầng thấp (RFID) và chuỗi các phần tử GS1 cách ly các tầng cao hơn khỏi việc nhận biết giao thức RF nào hoặc Kí hiệu mã vạch nào đang được sử dụng, và những gì máy đọc làm/mô hình đã được chọn. Nếu một máy đọc khác được thay thế thì thông tin gửi qua giao diện này vẫn giữ nguyên.

– Trong trường hợp sử dụng RFID, giao diện lọc & thu thập cách ly tầng cao hơn với các lựa chọn thiết kế về mặt vật lý được thực hiện liên quan đến cách thẻ FRID cảm nhận và tích hợp và cách ranh giới thời gian của sự kiện được kích hoạt. Nếu máy đọc FRID một anten-bốn hướng được thay thế bằng một tổ hợp năm máy đọc anten-đơn hướng “anten thông minh”, thì các sự kiện tại tầng lọc & thu thập vẫn dữ nguyên, ngược lại, nếu một cơ chế kích hoạt khác được sử dụng để đánh dấu khoảng thời gian bắt đầu và kết thúc mà các lần đọc được ghi lại, thì sự kiện lọc và thu thập vẫn dữ nguyên.

– EPCIS cách ly ứng dụng của doanh nghiệp với những nhận thức chi tiết về cách các bước cụ thể riêng biệt trong quá trình kinh doanh được thực hiện ở mức chi tiết. Ví dụ, sự kiện EPCIS điển hình “tại khu vực X, vào thời điểm T, các đối tượng chứa sau đây (thùng) đã được kiểm tra xác nhận đang có mặt trên pallet sau đây. Trong khi triển khai kinh doanh theo băng chuyền, điều này có thể tương ứng với một sự kiện lọc & thu thập mà các lần đọc được ghi lại trong khoảng thời gian bắt đầu và kết thúc được kích hoạt bởi tình huống đi ngang qua mắt điện tử ở xung quanh máy đọc được lắp đặt trên băng chuyền. Nhưng một triển khai khác có thể liên quan đến ba người khỏe mạnh đi lại xung quanh và sử dụng máy đọc cầm tay để đọc thẻ. Tại tầng lọc & thu thập, điều này trông rất khác (mỗi kích hoạt máy đọc cầm tay giống như một sự kiện lọc & thu thập riêng biệt), và việc xử lý bởi ứng dụng truy cập EPCIS là hoàn toàn khác (có lẽ liên quan đến bàn điều khiển tương tác mà người ta sử dụng để kiểm tra công việc của họ), Thế nhưng các sự kiện EPCIS vẫn như vậy đối với tất cả các triển khai.

Tóm lại, dữ liệu EPCIS-tầng khác với dữ liệu sử dụng tại tầng truy cập trong cấu trúc hệ thống của GS1 bởi sự kết hợp thông tin về quá trình kinh doanh mà ở đó dữ liệu được thu thập, và cung cấp các phát hiện có tính lịch sử. Trong cách làm như vậy, EPCIS cách ly các ứng dụng có sử dụng thông tin này tránh việc biết những chi tiết tầng thấp một cách chính xác cách một bước quá trình kinh doanh nhất định được thực hiện.

4.5  Nguyên tắc về các quy định của EPCIS

Việc xem xét ở trên các yêu cầu đối với tiêu chuẩn tại tầng EPCIS phức tạp hơn nhiều tại tầng truy cập của cấu trúc hệ thống GS1. Bản chất có tính lịch sử của dữ liệu EPCIS hàm ý rằng giao diện EPCIS cần một bộ/tệp kĩ thuật truy cập phong phú hơn ALE hoặc RFID và giao diện máy đọc mã vạch. Sự kết hợp bối cảnh của quá trình hoạt động hay kinh doanh vào EPCIS ngụ ý rằng các giao dịch EPCIS trong tệp dữ liệu phong phú hơn, và hơn nữa cần mở rộng hơn nhằm quy tụ sự đa dạng của quá trình kinh doanh trên thế giới. Cuối cùng, môi trường đa dạng mà EPCIS hoạt động ngụ ý rằng tiêu chuẩn EPCIS được xếp tầng cẩn thận để ngay cả khi EPCIS được sử dụng giữa các hệ thống bên ngoài khác biệt nhiều về, các chi tiết hoạt động, có tính thống nhất và tính tương tác ở mức độ cấu trúc trừu tượng của dữ liệu như thế nào và dữ liệu đó có nghĩa gì.

Đáp lại các yêu cầu này, EPCIS được mô tả bởi một quy định khung và những quy định hẹp hơn, chi tiết hơn mà ở trong quy định khung đó. Khung này được thiết kế để:

– Được phân tầng: Cụ thể, cấu trúc và nghĩa của dữ liệu được quy định một cách trừu tượng riêng biệt với các chi tiết cụ thể của dịch vụ truy cập dữ liệu và các ràng buộc với các giao thức của giao diện cụ thể. Điều này cho phép thay đổi những chi tiết cụ thể theo thời gian và giữa các doanh nghiệp trong khi vẫn giữ được ý nghĩa chung của chính dữ liệu này. Nó cũng cho phép những quy định về dữ liệu EPCIS được tái sử dụng trong các phương pháp tiếp cận ngoài phương pháp tiếp cận theo định hướng dịch vụ của quy định hiện hành. Ví dụ, định nghĩa dữ liệu có thể được tái sử dụng trong khuôn khổ EDI.

– Khả năng mở rộng: Các quy định cốt lõi cung cấp tệp cốt lõi của các loại dữ liệu và các hoạt động nhưng cũng cung cấp một vài phương tiện nhờ vậy mà tệp cốt lõi có thể được mở rộng cho các mục đích đặc thù đối với ngành công nghiệp nhất định hoặc khu vực ứng dụng. Sự mở rộng không những cung cấp các yêu cầu về quyền sở hữu được giải quyết theo cách thúc đẩy càng nhiều khung tiêu chuẩn càng tốt, mà còn cung cấp cách thức để phát triển các tiêu chuẩn theo thời gian.

– Môđun hóa: Cơ cấu phân tầng và mở rộng cho phép các phần khác nhau của khung EPCIS hoàn chỉnh được quy định bởi các tài liệu khác nhau, đồng thời thúc đẩy sự gắn kết trên toàn khung. Điều này cho phép quá trình tiêu chuẩn hóa (cũng như thực hiện) mở rộng.

Phần còn lại của tiêu chuẩn này quy định khung EPCIS. Nó cũng gắn kết khung đó cùng với một tệp các loại dữ liệu và giao diện dữ liệu. Tiêu chuẩn cùng với từ vựng kinh doanh cốt lõi của GS1, cung cấp các định nghĩa dữ liệu bổ sung mà tầng trên cùng của nó được cung cấp bởi tiêu chuẩn EPCIS.

5  Khung quy định kĩ thuật EPCIS

Quy định kĩ thuật EPCIS này được thiết kế để phân tầng, mở rộng và môđun hóa

5.1  Tầng

Hình 3 – Khung quy định kĩ thuật EPCIS

Các tầng này được mô tả dưới đây:

– Tầng môđun dữ liệu trừu tượng: Tầng môđun dữ liệu trừu tượng này quy định cấu trúc tổng thể của dữ liệu EPCIS. Đây chỉ là tầng mà không thể mở rộng bởi cơ cấu nếu không soát xét lại chính dữ liệu EPCIS. Tầng môđun dữ liệu trừu tượng này quy định các yêu cầu để tạo ra các định nghĩa về dữ liệu trong tầng định nghĩa dữ liệu.

– Tầng xác định /định nghĩa dữ liệu: Tầng xác định /định nghĩa dữ liệu này quy định dữ liệu nào được trao đổi thông qua EPCIS, cấu trúc trừu tượng của nó là gì, và nó có ý nghĩa gì. Một môđun xác định dữ liệu được xác định trong quy định hiện hành được gọi là môđun kiểu sự kiện chủ chốt /cốt lõi. Các định nghĩa dữ liệu trong tầng định nghĩa dữ liệu được quy định một cách trừu tượng theo quy tắc được xác định bởi tầng môđun dữ liệu trừu tượng.

– Tầng dịch vụ: Tầng dịch vụ xác định giao diện dịch vụ trong đó các khách hàng của EPCIS thực hiện giao dịch. Trong quy định hiện hành có hai môđun tầng dịch vụ được xác định. Môđun hoạt động truy cập cốt lõi xác định giao diện dịch vụ (giao diện truy vấn EPCIS) thông qua nó các ứng dụng truy cập EPCIS sử dụng để phân phối các kiểu sự kiện cốt lõi đến các bên quan tâm. Môđun hoạt động truy vấn cốt lõi xác định hai giao diện dịch vụ (giao diện kiểm soát truy vấn EPCIS và giao diện gọi lại truy vấn EPCIS) mà các ứng dụng truy cập EPCIS sử dụng để nhận dữ liệu được truy cập trước đó. Các định nghĩa giao diện trong tầng dịch vụ được quy định một cách trừu tượng với việc sử dụng UML.

– Các ràng buộc: Các ràng buộc quy định việc hiện thực hóa cụ thể tầng xác định dữ liệu và tầng dịch vụ. Có thể có nhiều ràng buộc được xác định cho định nghĩa dữ liệu đã cho và môđun dịch vụ. Trong quy định này, tổng cộng có chín ràng buộc được quy định cho ba môđun được xác định trong định nghĩa dữ liệu và các tầng dịch vụ. Các định nghĩa dữ liệu trong môđun xác định dữ liệu kiểu sự kiện cốt lõi được đưa ra một ràng buộc cho một lược đồ XML. Giao diện truy vấn EPCIS trong môđun hoạt động truy cập cốt lõi đưa ra những ràng buộc đối với hàng/thứ tự thông điệp và HTTP. Giao diện kiểm soát truy vấn EPCIS trong môđun hoạt động truy vấn cốt lõi đưa ra một ràng buộc đối với SOAP trên HTTP thông qua một mô tả dịch vụ mạng WSDL, và một ràng buộc thứ hai đối với AS2. Giao diện gọi lại truy vấn EPCIS trong môđun hoạt động truy vấn cốt lõi đưa ra các ràng buộc đối với HTTP, HTTPS và AS2.

– Tiêu chuẩn từ vựng về kinh doanh cốt lõi của GS1: Tiêu chuẩn từ vựng về kinh doanh cốt lõi của GS1 (CB1.2) luôn đồng hành với tiêu chuẩn EPCIS. Nó xác định các thành phần từ vựng đặc thù có thể được sử dụng để gắn kết với các định nghĩa dữ liệu được quy định trong tầng xác định dữ liệu của tiêu chuẩn EPCIS. Trong khi EPCIS có thể sử dụng mà không có CBV do sử dụng giá trị dữ liệu tư nhân hoặc độc quyền, điều này rất có lợi đối với ứng dụng EPCIS để sử dụng tiêu chuẩn CBV càng nhiều càng tốt.

5.2  Khả năng mở rộng

Kĩ thuật phân tầng đối với quy định kĩ thuật thúc đẩy khả năng mở rộng, vì một tầng có thể tái sử dụng bởi nhiều hơn một lần thực hiện ở tầng khác. Ví dụ, trong khi tiêu chuẩn này bao gồm một ràng buộc XML của môđun xác định dữ liệu kiểu sự kiện cốt lõi thì quy định kĩ thuật khác có thể định nghĩa một ràng buộc của cùng một môđun với một cú pháp khác nhau, ví dụ tệp CSV.

Ngoài khả năng mở rộng vốn có trong việc phân tầng, quy định kĩ thuật EPCIS bao gồm một vài cơ cấu đặc thù đối với khả năng mở rộng:

– Sự phân tầng: Các định nghĩa dữ liệu trong tầng xác định dữ liệu có sử dụng UML, cho phép giới thiệu một định nghĩa dữ liệu mới bằng cách tạo ra một phân tầng của một tầng đang có sẵn. Một phân tầng là một loại mới, loại này gồm toàn bộ lĩnh vực của loại đang tồn tại đồng thời được mở rộng sang lĩnh vực mới. Một thể hiện về một phân tầng có thể được sử dụng trong bất kì ngữ cảnh nào mà ở đó một thể hiện tầng bố được kì vọng.

– Điểm mở rộng: Các định nghĩa về dữ liệu và các quy định kĩ thuật về dịch vụ cũng bao gồm những điểm mở rộng mà các nhà cung cấp có thể sử dụng để cung cấp chức năng mở rộng mà không phải lập các phân tầng

5.3  Khả năng môđun hóa

Khung quy định kĩ thuật EPCIS được thiết kế để trở thành môđun. Điều đó có nghĩa là nó không chỉ gồm một quy định kĩ thuật duy nhất mà còn là một bộ sưu tập các quy định kĩ thuật cụ thể có liên quan với nhau. Điều này cho phép EPCIS phát triển và cải tiến trong hệ thống phân phối. Cấu trúc phân tầng và cơ chế mở rộng cung cấp các hợp phần quan trọng để đạt được khả năng mở rộng, như gộp nhóm vào những môđun.

Khi quy định kĩ thuật EPCIS là môđun, không có quy định giới hạn môđun của các quy định kĩ thuật phải chi tiết hay rõ ràng trong quá trình thực hiện EPCIS. Ví dụ, có thể có sản phẩm phần mềm cụ thể mà nó thực hiện trên nền tảng SOAP/HTTP một dịch vụ của liên kết thùng- pallet và một dịch vụ catalo sản phẩm mà lưu lượng dữ liệu được xác định trong các môđun xác định dữ liệu liên quan, sản phẩm này có thể phù hợp với sáu môđun khác nhau của tiêu chuẩn dữ liệu liên quan; môđun xác định dữ liệu mô tả dữ liệu catalo sản phẩm, môđun xác định dữ liệu xác định liên kết thùng – pallet, các quy định kĩ thuật đối với các dịch vụ tương ứng, và các ràng buộc SOAP/HTTP tương ứng. Tuy nhiên mã nguồn sản phẩm không có dấu vết về danh giới và dĩ nhiên lược đồ cơ sở dữ liệu cụ thể sử dụng cho sản phẩm có thể làm sai lệch dữ liệu sao cho catalo sản phẩm và dữ liệu về liên kết thùng – pallet trở lên gắn bó chặt chẽ. Tuy nhiên chỉ cần kết quả thực phù hợp với các quy định kĩ thuật thì việc thực hiện này là cho phép.

6  Tầng mô hình dữ liệu trừu tượng

Phần này đưa ra các mô tả có tính bắt buộc về mô hình dữ liệu trừu tượng mà nó nhấn mạnh EPCIS.

6.1  Dữ liệu về sự kiện và dữ liệu chủ

Nhìn chung, EPCIS đề cập hai loại dữ liệu: dữ liệu về sự kiện và dữ liệu chủ. Dữ liệu về sự kiện phát sinh trong trường hợp thực hiện các quá trình kinh doanh, và được truy cập thông qua giao dịch truy cập EPCIS và sẵn có cho truy vấn thông qua giao diện truy vấn EPCIS. Dữ liệu chủ là dữ liệu bổ sung nó cung cấp điều kiện cần thiết để diễn giải dữ liệu về sự kiện. Nó có ích cho việc truy vấn xuyên suốt giao diện kiểm soát truy vấn EPCIS, nhưng các phương tiện mà dữ liệu chủ nhập vào hệ thống không được quy định trong tiêu chuẩn EPCIS này.

Tầng mô hình dữ liệu trừu tượng không nhằm xác định nghĩa của các thuật ngữ “dữ liệu về sự kiện” hay “dữ liệu chủ” ngoài việc cung cấp các định nghĩa chính xác về cấu trúc dữ liệu như được sử dụng bởi quy định kĩ thuật EPCIS. Việc mô hình thông tin kinh doanh của thế giới thực như dữ liệu về sự kiện và dữ liệu chủ là trách nhiệm của tầng xác định dữ liệu, của ngành công nghiệp và các thỏa thuận của người sử dụng cuối cùng được xây dựng ở phần đầu của tiêu chuẩn này.

Không bắt buộc/ không quy định: Giải thích: Trong khi với mục đích của tiêu chuẩn này thì thuật ngữ “dữ liệu về sự kiện” và “dữ liệu chủ” chẳng có nghĩa gì ngoài “dữ liệu thích hợp với cấu trúc được cho ở đây,” cấu trúc này được xác định trong tầng mô hình dữ liệu trừu tượng và được thiết kế để mô tả thích hợp đối với dữ liệu thông thường được giao dịch thông qua EPCIS. Một cách không chính thức thì hai loại dữ liệu này có thể hiểu như sau. Dữ liệu về sự kiện phát triển về số lượng khi công việc kinh doanh được giao dịch nhiều hơn, và đề cập đến những gì xảy ra tại những thời điểm cụ thể về thời gian. Một ví dụ cho dữ liệu về sự kiện là “Vào lúc 1h 23min ngày 15 tháng 3 năm 2004, EPC X được phát hiện tại khu vực L”. Dữ liệu chủ, nhìn chung không phát triển chỉ là vì nhiều công việc kinh doanh được giao dịch (mặc dù dữ liệu chủ không có xu hướng phát triển khi các tổ chức phát triển về cỡ), không bị trói buộc vào những thời điểm cụ thể về thời gian (mặc dù dữ liệu chủ có thể thay đổi chậm theo thời gian), và diễn giải các phần tử dữ liệu về sự kiện. Một ví dụ cho dữ liệu chủ là “khu vực L liên quan đến trung tâm phân phối ở 123 phố Elm, thị trấn Any, US,”. Toàn bộ dữ liệu trong tập các trường hợp sử dụng được xem xét trong quá trình tạo ra tiêu chuẩn EPCIS có thể mô hình hóa như một tổ hợp các dữ liệu về sự kiện và dữ liệu chủ của loại này.

Cấu trúc dữ liệu về sự kiện và dữ liệu chủ trong EPCIS được minh họa dưới đây. (lưu ý rằng đây chỉ là một minh họa; các phần tử từ vựng đặc thù và tên thuộc tính của dữ liệu chủ trên hình này không được xác định trong tiêu chuẩn này.)

Hình 4 – Cấu trúc dữ liệu về sự kiện và dữ liệu chủ trong EPCIS

Các thành phần của mô hình dữ liệu trừu tượng EPCIS được xác định dưới đây:

– Dữ liệu về sự kiện: Một tập hợp các sự kiện.

– Sự kiện: Một cấu trúc gồm một loại sự kiện và một hoặc nhiều trường sự kiện được đặt tên.

– Loại sự kiện: Một miền tên – tên đầy đủ (qname), nó cho biết sự kiện đã cho phù hợp với cấu trúc nào trong một vài cấu trúc sự kiện có thể (như được định nghĩa bởi tầng xác định dữ liệu).

– Trường sự kiện: Một trường được đặt tên trong phạm vi của một sự kiện. Tên trường này được cho bởi (qname), liên quan đến tên của trường được quy định bởi tầng xác định dữ liệu hoặc tên trường được xác định là một phần mở rộng thêm của tiêu chuẩn này. Giá trị của trường có thể là một kiểu nguyên thủy (như chữ số nguyên hoặc dấu hiệu về thời gian), phần tử từ vựng, hoặc danh mục các kiểu nguyên thủy hoặc phần tử từ vựng.

– Dữ liệu chủ: Một tập hợp từ vựng, cùng với thộc tính của dữ liệu chủ liên kết với các thành phần của từ vựng đó.

– Từ vựng: Một tập hợp được đặt tên cho các mã phân định. Tên của từ vựng là một qname mà có thể sử dụng làm tên cho kiểu trường sự kiện. Mã phân định thuộc phạm vi từ vựng được gọi là các thành phần từ vựng. Từ vựng đại diện cho một tập hợp các giá trị lựa chọn, nó có thể xuất hiện dưới dạng các giá trị của trường sự kiện đặc thù. Từ vựng trong EPCIS được sử dụng làm các tập hợp mô hình như tập hợp tên các khu vực có sẵn, tập hợp tên các bước của quá trình kinh doanh có sẵn v.v…

– Thành phần từ vựng: Mã phân định mà nó đặt tên cho sự lựa chọn được mô hình bởi từ vựng. Giá trị của trường sự kiện có thể là một thành phần từ vựng. Các thành phần của từ vựng được đại diện cho mã phân định nguồn đồng dạng (URIs). Mỗi thành phần từ vựng có thể có các thuộc tính dữ liệu chủ liên kết.

– Thuộc tính của dữ liệu chủ: Một tập hợp các cặp tên/ giá trị không có thứ tự liên kết với thành phần từ vựng riêng biệt. Phần tên của một cặp là qname. Phần giá trị của một cặp có thể là giá trị kiểu tùy ý. Thuộc tính đặc thù (có thể trống) là danh mục trẻ em, mỗi em là thành phần từ vựng khác của cùng từ vựng. Xem phần 6.5.

Các sự kiện EPCIS mới tạo ra ở rìa và được phân phối đến hạ tầng EPCIS thông qua giao diện truy vấn EPCIS, sau đó chúng có thể được phân phối đến các ứng dụng được quan tâm thông qua giao diện truy vấn EPCIS. Không có một cơ chế nào được cung cấp trong cả hai giao diện mà ứng dụng có thể xóa hoặc làm thay đổi sự kiện EPCIS. Chỉ có một cách “rút lại/đính chính” hoặc “làm chính xác” sự kiện EPCIS là tạo ra sự kiện tiếp theo có ý nghĩa kinh doanh để hủy bỏ hoặc sửa đổi sự ảnh hưởng của sự kiện trước (phần 7.4.1.3 thảo luận về cách thức có thể thực hiện).

Trong khi giao diện truy vấn EPCIS và giao diện truy vấn EPCIS không cung cấp phương tiện cho ứng dụng để yêu cầu xóa một sự kiện một cách rõ ràng thì các kho lưu trữ EPCIS có thể thực hiện chính sách giữ lại tài liệu làm cho sự kiện EPCIS cũ trở lên không tiếp cận được sau một khoảng thời gian.

Dữ liệu chủ, ngược lại có thể thay đổi theo thời gian, mặc dù các thay đổi này được yêu cầu là không thường xuyên liên quan đến tốc độ mà ở đó dữ liệu về sự kiện mới được tạo ra. Phiên bản hiện hành của tiêu chuẩn này không quy định cách dữ liệu chủ thay đổi (như nêu ở trên (cũng không quy định cách dữ liệu chủ nhập vào nơi đầu tiên).

6.1.1  Truyền dữ liệu chủ trong EPCIS

Truy cập EPCIS và giao diện truy vấn EPCIS chủ yếu quan tâm đến việc truyền sự kiện EPCIS. Phương tiện nhờ nó mà dữ liệu chủ nhập vào hệ thống để thực hiện giao diện này không được quy định trong tiêu chuẩn EPCIS này. Tuy nhiên tiêu chuẩn EPCIS không cung cấp cơ chế đề truyền dữ liệu chủ mà việc thực hiện có thể sử dụng nó để đảm bảo rằng người nhận dữ liệu về sự kiện EPCIS có quyền truy cập vào dữ liệu chủ cần thiết để giải thích dữ liệu về sự kiện đó. Nói một cách khác là dữ liệu chủ có thể truyền bằng phương tiện hoàn toàn nằm ngoài tiêu chuẩn EPCIS. Tiêu chuẩn EPCIS không áp đặt bất kì yêu cầu nào về việc liệu dữ liệu về sự kiện EPCIS có kèm theo dữ liệu chủ hay không ngoài việc yêu cầu dữ liệu chủ kèm theo dữ liệu về sự kiện phải nhất quán với tất cả dữ liệu chủ trong phần ILMD của các sự kiện đó.

Tiêu chuẩn EPCIS cung cấp bốn cơ chế để truyền dữ liệu chủ, được tóm tắt trong bảng dưới đây:

Bảng 2 – Các cơ chế truyền dữ liệu chủ

Cơ chế	Điều	Mô tả	Hạn chế
Truy vấn dữ liệu chủ	8.2.7.2	Khách hàng truy vấn EPCIS có thể truy vấn việc thực hiện giao diện truy vấn EPCIS về sự phù hợp của dữ liệu chủ với các tiêu chí quy định.	Dữ liệu chủ trở về từ hoạt động truy vấn PHẢI phản ánh giá trị hiện tại đối với thuộc tính dữ liệu chủ được biết đến với người trả lời truy vấn vào thời điểm truy vấn được tạo ra.
IlMD	7.3.6	Sự kiện EPCIS đánh dấu sự khởi đầu của cuộc đời cho một mã phân định cấp độ cá thể hoặc nhiều cấp có thể bao gồm dữ liệu chủ tương ứng trực tiếp trong sự kiện	Dữ liệu chủ trong sự kiện PHẢI phản ánh giá trị hiện tại đối với thuộc tính dữ liệu chủ được biết đến với người tạo ra sự kiện vào thời điểm của sự kiện. Lưu ý rằng, bởi vì dữ liệu này lồng trực tiếp vào sự kiện, thông thường một phần của sự kiện đó, và sẽ luôn luôn bao gồm khi sự kiện này được truy vấn (chịu sự điều chỉnh như quy định tại điều 8.2.2)
Tiêu đề tài liệu EPCIS	9.5	Tài liệu EPCIS được sử dụng cho việc truyền điểm đến điểm một tập hợp các sự kiện EPCIS nằm ngoài giao diện có thể bao gồm dữ liệu chủ liên quan trong tiêu đề của tài liệu	Dữ liệu chủ trong tiêu đề của tài liệu PHẢI phản ánh những giá trị hiện tại của thuộc tính dữ liệu chủ được biết đến với người tạo ra tài liệu vào thời điểm tài liệu được tạo ra. Dữ liệu chủ trong tiêu đề của tài liệu EPCIS KHÔNG ĐƯỢC quy định những giá trị thuộc tính mà nó xung đột với phần ILMD của bất kì sự kiện nào chứa trong nội dung của tài liệu EPCIS.
Tài liệu dữ liệu chủ EPCIS	9.7	Tài liệu chủ EPCIS có thể được sử dụng cho việc truyền điểm-tới-điểm dữ liệu chủ nằm ngoài giao diện truy vấn EPCIS.	Dữ liệu chủ trong tài liệu PHẢI phản ánh những giá trị hiện tại của thuộc tính dữ liệu chủ được biết đến với người tạo ra tài liệu vào thời điểm tài liệu được tạo ra.

6.2  Loại từ vựng

Từ vựng được sử dụng sâu rộng trong EPCIS cho mô hình vật lý, số hóa, và các thực thể mang tính khái niệm mà nó tồn tại trong thế giới thực. Ví dụ về từ vựng được định nghĩa trong tầng xác định dữ liệu EPCIS cốt lõi là tên các tên vị trí, tên loại đối tượng (tên loại đối tượng là những thứ gì đó như “Acme Deluxe Widget” trái lại EPC có tên là một ví dụ cụ thể của Acme Deluxe Widget), và tên các bước kinh doanh. Trong mỗi trường hợp một từ vựng đại diện cho một tập hợp các lựa chọn hữu hạn (mặc dù mở) mà nó có thể xuất hiện trong các trường đặc thù của sự kiện.

Cần phân biệt hai loại từ vựng, theo các mẫu khác nhau theo cách chúng được định nghĩa và mở rộng theo thời gian:

– Từ vựng tiêu chuẩn: Từ vựng tiêu chuẩn diễn tả một tập hợp các phần tử của từ vựng mà định nghĩa và ý nghĩa của chúng phải được đồng thuận trước đó bởi các đối tác thương mại, họ là những người sẽ trao đổi sự kiện có sử dụng từ vựng. Ví dụ, tầng xác định dữ liệu cốt lõi EPCIS định nghĩa từ vựng được gọi là “bước kinh doanh,“ có các phần tử của nó là mã phân định dùng để chỉ những thứ như “giao hàng”, “nhận hàng” và v.v. Một đối tác thương mại có thể tạo ra sự kiện có bước kinh doanh “giao hàng”, còn đối tác khác nhận sự kiện đó thông qua truy vấn có thể giải thích điều này bởi vì thỏa thuận trước đó “giao hàng” có nghĩ là gì.

– Các phần tử của từ vựng tiêu chuẩn được định nghĩa bởi các tổ chức có nhiều người sử dụng cuối cùng, như GS1, ngành công nghiệp hiệp hội nằm ngoài GS1, các tập đoàn đối tác thương mại tư nhân v.v… Dữ liệu chủ kết hợp với các phần tử của từ vựng tiêu chuẩn được định nghĩa bởi chính các tổ chức đó, và mong muốn được chia sẻ với người sử dụng như một phần của quy định kĩ thuật hoặc bằng một số phương tiện tương tự. Các phần tử của từ vựng mới trong từ vựng tiêu chuẩn đã cho mong muốn được sử dụng vào quá trình một cách thận trọng và không thường xuyên, như khi phê chuẩn một phiên bản tiêu chuẩn mới hay thông qua bỏ phiếu của tập đoàn công nghiệp. Khi một tổ chức của người sử dụng cuối cùng riêng biệt hoạt động độc lập, họ có thể đưa vào sử dụng phần tử từ vựng mới, nhất là phần tử ít được sử dụng khi thiết lập trao đổi dữ liệu và hầu như chỉ sử dụng trong phạm vi bốn bức tường của tổ chức.

– Từ vựng của người sử dụng: Từ vựng của người sử dụng diễn tả một tập hợp các thành phần của từ vựng mà định nghĩa và ý nghĩa của chúng chịu sự kiểm soát của một tổ chức duy nhất. Ví dụ, tầng xác định dữ liệu cốt lõi EPCIS định nghĩa từ vựng được gọi là “địa điểm kinh doanh” có các phần tử của nó là mã phân định dùng để chỉ những thứ như “Acme Corp, Trung tâm phân phối 3,“ Acme Corp có thể tạo ra sự kiện có địa điểm kinh doanh “Acme Corp, Trung tâm phân phối 3,” còn đối tác khác nhận sự kiện đó thông qua truy vấn có thể giải thích điều này bởi vì hoặc là nó tương quan với các sự kiện khác mang tên cho cùng địa điểm, hoặc nhìn vào thuộc tịnh của dữ liệu chủ kết hợp với địa điểm, hoặc cả hai.

– Các phần tử từ vựng của người sử dụng ban đầu được định nghĩa bởi tổ chức sử dụng cuối cùng riêng biệt hoạt động độc lập. Dữ liệu chủ liên kết với Các phần tử từ vựng của người sử dụng được định nghĩa bởi chính các tổ chức đó, và thường được chia sẻ với các đối tác thương mại thông qua giao diện kiểm soát truy vấn EPCIS hoặc cơ cấu trao đổi dữ liệu/cơ cấu đồng bộ dữ liệu. Phần tử từ vựng mới trong từ vựng của người sử dụng đã cho được đưa vào sử dụng theo quyết định riêng của người sử dụng cuối cùng, và các đối tác thương mại phải sẵn sàng đáp ứng một cách phù hợp. Tuy nhiên thông thường các quy tắc để xây dựng các phần tử từ vựng của người sử dụng mới được thiết lập bởi các tổ chức của nhiều người sử dụng cuối cùng và trong mọi trường hợp phải theo các quy tắc được xác định trong 6.4 dưới đây.

Các dòng giữa hai loại từ vựng này có phần chủ quan. Tuy nhiên cơ cấu xác định trong quy định kĩ thuật EPCIS hoàn toàn không gây ra sự phân biệt giữa hai loại từ vựng, và vì vậy hoàn toàn không cần thiết phải định nghĩa từ vựng cụ thể khi nó thuộc loại này hay loại kia. Thuật ngữ “từ vực tiêu chuẩn” và “từ vựng của người sử dụng” được nêu ra chỉ vì chúng có lợi như gợi ý về cách thức từ vựng nhất định kì vọng được định nghĩa và mở rộng.

Tiêu chuẩn từ vựng kinh doanh cốt lõi của GS1 (CBV) [CBV1.2] cung cấp các thành phần từ vựng tiêu chuẩn cho nhiều loại từ vựng sử dụng trong các loại sự kiện EPCIS. Đặc biệt CBV định nghĩa thành phần từ vựng cho các loại từ vựng tiêu chuẩn EPCIS sau đây: Bước kinh doanh, cách bố trí, loại giao dịch kinh doanh và nguồn/loại điểm đến. CBV cũng định nghĩa bản mẫu để xây dựng các thành phần từ vựng đối với các loại từ vựng của người sử dụng EPCIS sau đây: Đối tượng (EPC, cấp đối tượng (EPCclass), địa điểm (điểm đọc và địa điểm kinh doanh), ID giao dịch kinh doanh, ID nguồn/ID điểm đến và ID biến đổi.

6.3  Cơ chế mở rộng

Đặc tính chính của EPCIS là khả năng mở rộng bởi các tổ chức khác nhau nhằm thích ứng với các tình huống kinh doanh cụ thể. Tóm lại, tầng mô hình dữ liệu trừu tượng cung cấp năm phương pháp nhờ đó mà dữ liệu được xử lý bởi EPCIS có thể được mở rộng (ngoài ra tầng dịch vụ còn cung cấp cơ chế thêm các dịch vụ bổ sung) được liệt kê ở đây từ các loại xâm nhập/xâm lấn nhiều nhất đến loại ít xâm nhập/ xâm lấn nhất:

– Loại sự kiện mới: Loại sự kiện mới có thể được bổ sung vào tầng xác định dữ liệu. Việc bổ sung loại sự kiện mới đòi hỏi mỗi ràng buộc định nghĩa dữ liệu được mở rộng và có thể cũng đòi hỏi việc mở rộng giao diện truy cập và truy vấn cùng các ràng buộc của chúng.

– Trường sự kiện mới: Trường sự kiện mới có thể được bổ sung vào loại sự kiện hiện hành trong tầng định nghĩa dữ liệu. Các ràng buộc, giao diện truy cập, và giao diện truy vấn được định nghĩa trong tiêu chuẩn này được thiết kế để cho phép loại mở rộng này mà không yêu cầu phải thay đổi quy định kĩ thuật (điều tương tự có thể không đúng với các ràng buộc khác hoặc ngôn ngữ truy vấn được định nghĩa ở ngoài tiêu chuẩn này).

– Loại từ vựng mới: Loại từ vựng mới có thể bổ sung vào các điều khoản của loại từ vựng đang có sẵn. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện

– Thuộc tính dữ liệu chủ mới: Tên thuộc tính mới có thể được định nghĩa cho từ vựng hiện hành. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện

– Thực thể mới/Thuộc tính dữ liệu chủ của lô hàng (ILMD): Tên thuộc tính mới có thể được định nghĩa để sử dụng trong thể/dữ liệu chủ của lô hàng (ILMD); xem 7.3.6.

– Thành phần từ vựng mới: Thành phần mới được bổ sung vào từ vựng hiện hành. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện.

Tầng mô hình dữ liệu trừu tượng đã từng được thiết kế sao cho hầu hết các mở rộng/tiện ích phát sinh từ việc áp dụng bởi các ngành công nghiệp khác nhau hoặc do sự gia tăng hiểu biết trong ngành công nghiệp nhất định có thể được cung cấp bởi các phương pháp ở cuối danh sách nêu trên, mà không yêu cầu phải soát xét lại chính tiêu chuẩn này. Các phương pháp xâm nhập/ xâm lấn nhiều hơn ở phía đầu của danh sách cho sẵn, tuy nhiên, trong trường hợp có tình huống phát sinh mà không thể được cung cấp bởi các phương pháp ở cuối danh sách.

Một số cách khác nhau để mở rộng quy định kĩ thuật EPCIS như được tóm tắt dưới đây:

Bảng 3 – Các cách mở rộng quy định kĩ thuật EPCIS

Cách mở rộng được phổ biến	Tổ chức có trách nhiệm	Phương pháp mở rộng
		Loại sự kiện mới	Trường sự kiện mới	Loại từ vựng mới	Dữ liệu chủ mới/ thuộc tính ILMD (7.3.6)	Phần tử từ vựng mới
Phiên bản tiêu chuẩn EPCIS mới	Nhóm công tác GS1 EPCIS	có	có	có	Thỉnh thoảng	Hiếm khi
Phiên bản tiêu chuẩn CBV mới	Nhóm công tác về từ vựng kinh doanh cốt lõi của GS1	Không	Không	Không	Có	Có (từ vựng tiêu chuẩn, bản mẫu từ vựng của người sử dụng)
Tiêu chuẩn ứng dụng GS1 đối với ngành công nghiệp đặc thù	Nhóm công tác tiêu chuẩn ứng dụng GS1 đối với ngành công nghiệp đặc thù	Hiếm khi	Hiếm khi	Thỉnh thoảng	Có	Có (từ vựng tiêu chuẩn)
Tài liệu khuyến cáo của tổ chức GS1 thành viên nước sở tại cho ngành công nghiệp đặc thù trong vùng địa lý đặc thù	Tổ chức GS1 thành viên	Hiếm khi	Hiếm khi	Thỉnh thoảng	Có	Có (từ vựng tiêu chuẩn)
Quy định kĩ thuật về khả năng tương tác của tập đoàn tư nhân	Hiệp hội công nghiệp hoặc tập đoàn người sử dụng cuối cùng tư nhân nằm ngoài GS1	Hiếm khi	Hiếm khi	Thỉnh thoảng	Có	Có (từ vựng tiêu chuẩn)
Dữ liệu chủ đã cập nhật qua truy vấn EPCIS hoặc đồng bộ hóa dữ liệu khác	Người sử dụng cuối cùng cá thể	Hiếm khi	Hiếm khi	Hiếm khi	Hiếm khi	Có (sử dụng từ vựng)

6.4  Mô tả mã phân định

Tầng mô hình dữ liệu trừu tượng giới thiệu một số loại mã phân định, bao gồm tên loại sự kiện, tên trường sự kiện, tên từ vựng, thành phần từ vựng và tên thuộc tính dữ liệu chủ. Vì tất cả miền tên này được tự do mở rộng, tiêu chuẩn này áp đặt một vài quy tắc khi đặt tên sao cho các tổ chức độc lập có thể kiến tạo các mở rộng mà không sợ bị trùng tên.

Thành phần từ vựng phải tuân thủ các quy tắc sau đây. Trong trường hợp thành phần từ vựng được biểu thị dưới dạng mã phân định tài nguyên/nguồn thống nhất (URI) với cú pháp chung được định nghĩa trong (RFC2396). Các loại URIs có thể chấp nhận là thành phần từ vựng là những URIs có chủ sở hữu. Điều này bao gồm:

– Các biểu thị URI đối với mã EPC (TDS1.9, điều 6). Chủ sở hữu đối với EPC URI cụ thể là tổ chức có mã doanh nghiệp GS1 được thừa nhận (hoặc cơ quan có thẩm quyền phát hành theo quy trình EPC).

– Định vị nguồn thống nhất tuyệt đối (URLs) (RFC1738). Chủ sở hữu đối với URI cụ thể là tổ chức sở hữu tên miền internet trong phần quyền hạn URL.

– Tên nguồn thống nhất (URNs) (RFC2141) trong miền tên oid bắt đầu bằng mã số doanh nghiệp (PEN). Chủ sở hữu đối với OID-URN là tổ chức mà PEN được ban hành.

– Tên nguồn thống nhất (URNs) (RFC2141) trong miền tên epc hoặc epc toàn cầu không kể URIs được sử dụng để biểu thị EPCs (TDS1.9). Chủ sở hữu đối với URNs là GS1.

Tên loại sự kiện và tên trường sự kiện được biểu thị dưới dạng miền tên- tên đầy đủ (qname), bao gồm một miền tên URI và một cái tên. Điều này được biểu thị đơn giản trong ràng buộc XML và thuận lợi cho việc mở rộng.

6.5  Từ vựng phân cấp

Một số từ vựng có phân cấp hoặc cấu trúc đa cấp. Ví dụ, từ vựng tên của của vị trí có thể có thành phần có nghĩa “Acme corp. cửa hàng bán lẻ # 3 cũng như thành phần khác có nghĩa “Acme corp. cửa hàng bán lẻ # 3 phòng cuối” và “Acme corp. cửa hàng bán lẻ # 3 tầng giảm giá”. Trong ví dụ này có mối quan hệ phân cấp tự nhiên, trong đó mã phân định đầu là bố và hai mã phân định tiếp theo là con.

Mối quan hệ phân cấp giữa các thành phần từ vựng được biểu thị qua dữ liệu chủ. Đặc biệt, ngoài các thuộc tính dữ liệu chủ, mã phân định bố chứa danh sách các mã phân định con. Mỗi mã phân định con PHẢI thuộc về cùng từ vựng như bố. Ở ví dụ trên thành phần mang nghĩa “Acme corp. trung tâm phân phối # 3” sẽ có danh sách các con bao gồm thành phần mang nghĩa “Acme corp. trung tâm phân phối # 3 cửa # 5.”

Ở phần khác trong tiêu chuẩn này, thuật ngữ “thế hệ con cháu trực tiếp hay gián tiếp” được sử dụng để ám chỉ tập hợp các thành phần từ vựng bao gồm con của thành phần từ vựng đã cho, con của những đứa con đó v.v. Điều đó có nghĩa là “thế hệ con cháu trực tiếp hay gián tiếp” của thành phần từ vựng là tập hợp các thành phần từ vựng nhận được bằng cách đóng mối quan hệ “con cái” bắt đầu với thành phần từ vựng đã cho.

Thành phần từ vựng đã cho CÓ THỂ là con của nhiều bố. Điều này cho phép có nhiều cách nhóm các thành phần từ vựng; ví dụ các vị trí có thể nhóm theo đặc điểm địa lý và chức năng. Tuy nhiên, một thành phần PHẢI KHÔNG là con của chính nó kể cả trực tiếp hay gián tiếp.

Không bắt buộc: Giải thích: Trong phiên bản hiện hành của tiêu chuẩn này chỉ có một mối quan hệ phân cấp được cung cấp, lấy tên mối quan hệ mã hóa trong danh sách “con” đặc thù. Các phiên bản trong tương lai của tiêu chuẩn này có thể phát sinh điều này nhằm cho phép nhiều hơn mối quan hệ, dĩ nhiên việc lập mã cho mỗi mối quan hệ thông qua thuộc tính dữ liệu chủ khác nhau.

Mối quan hệ phân cấp được nghiên cứu đặc biệt khi truy vấn (8.2) và có thể có vai trò khi thực hiện các chính sách ủy quyền (8.2.2) nhưng không được tạo thêm bất kì sự phức tạp hay cơ chế nào cho tầng mô hình dữ liệu trừu tượng.

7  Tầng định nghĩa dữ liệu

7.1  Quy tắc chung đối với quy định mô đun tầng định nghĩa dữ liệu

Quy tắc chung đối với quy định mô đun trong tầng định nghĩa dữ liệu được cho tại đây. Các quy tắc này sau đây được áp dụng ở 7.2 nhằm xác định mô dun loại sự kiện cốt lõi. Quy định này cũng được áp dụng cho các tổ chức mong muốn tạo tầng cho quy định kĩ thuật phía trên cùng của tiêu chuẩn này.

7.1.1  Nội dung

Nhìn chung, quy tắc đối với quy định mô đun trong tầng định nghĩa dữ liệu có các thành phần này, nó gắn kết với khung mô hình dữ liệu trừu tượng được quy định ở điều 6:

– Loại giá trị: Các định nghĩa về loại dữ liệu được sử dụng để mô tả các giá trị của trường sự kiện và các thuộc tính dữ liệu chủ. Mô đun loại sự kiện cốt lõi định nghĩ loại nguyên thủy có ích cho tất cả các mô đun định nghĩa dữ liệu sử dụng. Mỗi từ vựng được định nghĩa cũng ngầm hiểu là loại giá trị.

– Loại sự kiện: Các định nghĩa loại sự kiện, mỗi định nghĩa cho một cái tên loại sự kiện (nó phải duy nhất cho toàn bộ các loại sự kiện) và danh sách các trường sự kiện tiêu chuẩn cho loại đó. Một loại sự kiện có thể được định nghĩa như là một phân tầng của loại sự kiện hiện hành, có nghĩa là loại sự kiện mới bao gồm tất cả các trường sự kiện của sự kiện hiện hành cộng với bất kì trường sự kiện bổ sung nào với điều kiện là một phần của tiêu chuẩn này.

– Trường sự kiện: Định nghĩa trường sự kiện cùng với loại sự kiện. Mỗi định nghĩa trường sự kiện quy định một cái tên cho trường này (nó phải duy nhất cho tất cả các trường loại sự kiện đóng) và loại dữ liệu về giá trị trong trường đó. Các định nghĩa trường dữ liệu cùng với mô đun định nghĩa dữ liệu có thể là bộ phận của loại sự kiện mới được đưa vào bởi mô đun đó, hoặc có thể mở rộng loại sự kiện được định nghĩa ở mô đun khác.

– Loại từ vựng: Định nghĩa loại từ vựng, mỗi định nghĩa cho một cái tên từ vựng (nó phải duy nhất cho toàn bộ các từ vựng), danh sách các thuộc tính dữ liệu chủ tiêu chuẩn đối với các thành phần từ vựng và các quy tắc kiến tạo thành phần từ vựng mới cho từ vựng. (Bất kì quy tắc nào được quy định để kiến tạo thành phần từ vựng trong loại từ vựng phải thích hợp với quy tắc chung cho ở 6.1).

– Thuộc tính dữ liệu chủ: Định nghĩa thuộc tính dữ liệu chủ đối với loại từ vựng. Mỗi định nghĩa thuộc tính dữ liệu chủ quy định một cái tên cho thuộc tính (nó phải duy nhất cho tất cả các thuộc tính loại từ vựng đóng) và loại dữ liệu giá trị của thuộc tính đó. Định nghĩa dữ liệu chủ cùng với mô đun định nghĩa dữ liệu có thể thuộc về loại từ vựng mới được đưa vào bởi mô đun đó, hoặc có thể mở rộng loại từ vựng được định nghĩa ở mô đun khác.

– Thành phần từ vựng: Định nghĩa thành phần từ vựng, mỗi định nghĩa quy định một cái tên (nó phải duy nhất cho tất cả các thành phần trong từ vựng và phù hợp với quy tắc chung đối với các thành phần từ vựng cho ở 6.4 cũng như các quy tắc đặc thù được quy định trong định nghĩa loại từ vựng), và quy định có tính lựa chọn dữ liệu chủ (giá trị thuộc tính đặc thù) đối với thành phần đó.

Không bắt buộc: Sự mở rộng: Như đã giải thích ở 6.3, mô đun định nghĩa dữ liệu được định nghĩa trong tiêu chuẩn này và các quy định kĩ thuật đồng hành được xây dựng bởi nhóm công tác EPCIS dự kiến sẽ gồm các định nghĩa về loại giá trị, loại sự kiện, trường sự kiện, và loại từ vựng, trong khi đó các mô đun được định nghĩa bởi các nhóm công tác khác dự kiến sẽ gồm các định nghĩa về trường sự kiện mà nó mở rộng cho các loại sự kiện hiện tại, thuộc tính dữ liệu chủ mà nó mở rộng cho các loại từ vựng hiện tại và các thành phần từ vựng mà nó đưa vào từ vựng hiện tại. Các nhóm khác đôi khi cũng có thể định nghĩa các loại từ vựng.

Từ “từ vựng” được sử dụng không chính thức nhằm ám chỉ loại từ vựng và tập hợp toàn bộ các thành phần từ vựng mà chúng có.

7.1.2  Kí hiệu

Trong các phần dưới đây, các loại sự kiện và trường sự kiện được quy định có sử dụng mẫu Kí hiệu sơ đồ cấp/loại UML. Sơ đồ cấp/loại UML sử dụng cho mục đích này có thể chứa các cấp/loại có các thuộc tính (trường) và sự liên kết, nhưng không hoạt động. Đây là một ví dụ:

Hình 5 – Sơ đồ cấp/loại UML cho các loại sự kiện

Sơ đồ này diễn tả định nghĩa dữ liệu cho hai loại sự kiện, EventType1 và EventType2. Các loại sự kiện này tận dụng bốn loại giá trị: Type1, Type2, DataClass3 và DataClass4. Typel và Type2 là các loại gốc/nguyên thủy, còn DataClass3 và DataClass4 là loại phức hợp, cấu trúc của chúng cũng được quy định tại UML.

Loại sự kiện EventType1 ở ví dụ này có bốn trường, Field1 và Field2 là loại gốc Type1, và Type2 theo trình tự. EventType1 có Fields của trường khác, loại của nó là DataClass3. Cuối cùng, EventType1 có Field4 của trường khác, nó chứa danh sách gồm zero hoặc nhiều hơn các trường hợp của loại DataClass4 (“0..*” kí hiệu cho “zero hoặc nhiều hơn”).

Sơ đồ này cũng diễn tả định nghĩ: dữ liệu cho EventType2. Mũi tên có đầu hình tam giác mở biểu thị rằng EventType2 là phân cấp của EventType1. Điều này có nghĩa là EventType2 thực chất có năm trường: bốn trường được thừa hưởng từ EventType1 cộng với Field5 thứ năm của loại Type1.

Trong mô tả UML, kí hiệu <<điểm mở rộng>> (<<extension point>>) định nghĩa là nơi việc thực hiện PHẢI cung cấp khả năng mở rộng thông qua việc bổ sung các thành viên dữ liệu mới. (Khi một loại có điểm mở rộng, và loại khác được định nghĩa là phân cấp của loại thứ nhất và cũng có điểm mở rộng, nó không có nghĩa là loại thứ hai có hai điểm mở rộng, ngược lại nó đơn thuần chỉ nhấn mạnh rằng loại thứ hai cũng được mở để mở rộng.) Cơ chế mở rộng PHẢI cung cấp cả việc mở rộng quyền sở hữu bởi nhà cung cấp sản phẩm phù hợp EPCIS, và mở rộng được định nghĩa bởi GS1 thông qua các phiên bản trong tương lai của tiêu chuẩn này hoặc thông qua quy định kĩ thuật mới.

Trong trường hợp xây dựng tiêu chuẩn XML, các điểm mở rộng được thực hiện theo sơ đồ XML và theo phương pháp mô tả ở 9.1.

Tất cả các định nghĩa về loại sự kiện PHẢI bao gồm điểm mở rộng để cung cấp khả năng mở rộng được định nghĩa ở 6.3 (“trường sự kiện mới”). Các loại giá trị CÓ THỂ bao gồm một điểm mở rộng.

7.1.3  Ngữ nghĩa

Mỗi sự kiện (ví dụ về loại sự kiện) mã hóa cho một số xác nhận, nó định nghĩa đúng ngữ nghĩa của sự kiện. Một vài xác nhận nêu đâu là sự thật tại thời điểm sự kiện được truy cập. Các xác nhận khác nêu điều gì được mong đợi sẽ là sự thật tiếp theo sự kiện này trước khi bị vô hiệu bởi sự kiện đến sau. Điều này được gọi là ngữ nghĩa trong quá khứ và ngữ nghĩa trong tương lai của sự kiện, theo trình tự. Ví dụ; nếu tiện ích # 23 vào tòa nhà # 5 qua cửa # 6 lúc 11:23 tối sau đó một xác nhận trong quá khứ là “tiện ích # 23 đã được phát hiện thấy tại cửa # 6 lúc 11:23 tối”, trong khi đó một xác nhận trong tương lai lại là “tiện ích # 23 ở trong tòa nhà # 5.” Sự khác biệt mấu chốt ở đây là xác nhận trong quá khứ ám chỉ thời điểm cụ thể trong quá khứ (“tiện ích # 23 đã phát hiện thấy …”) trong khi đó một xác nhận trong tương lai lại công bố về điều kiện hiện tại của đối tượng (“ ’’tiện ích # 23 ở…” ) Sự xác nhận trong tương lai lại phỏng đoán rằng nếu tiện ích # 23 chưa bao giờ rời khỏi tòa nhà # 5, sự kiện truy cập EPCIS khác sẽ được ghi lại để thay thế sự kiện trước.

Nhìn chung, ngữ nghĩa hồi tưởng/ trong quá khứ là những gì không thể đảo ngược, được hiểu là sự thật tại thời điểm truy cập sự kiện và thông thường có thể tin cậy dựa vào các ứng dụng truy cập EPCIS như là những công bố chính xác về thực tế lịch sử. Ngữ nghĩa trong tương lai, vì chúng cố gắng nêu đâu là sự thực sau sự kiện đã từng xảy ra, phải được coi là tốt nhất để được công bố “điều gì nên” hơn là “điều gì là”. Một xác nhận trong tương lai có thể không đúng nếu thiết bị truy cập thực hiện chức năng không hoàn hảo, hoặc nếu mô hình/kiến trúc hệ thống hoặc quá trình kinh doanh không được thiết kế để truy cập các sự kiện EPCIS trong tất cả các tình huống. Hơn nữa để tận dụng sự xác nhận trong tương lai tiềm ẩn trong sự kiện, ứng dụng truy cập EPCIS phải chắc chắn rằng nó có quyền truy cập vào bất kì sự kiện tiếp theo mà nó có thể thay thế cho sự kiện đang đề cập đến.

Việc phân đôi quá khứ/tương lai đóng vai trò quan trọng cho việc định nghĩa về vị trí EPCIS ở 7.3.4.

Trong các tình huống nhất định, một sự kiện trước đó được phát hiện sau đó có lỗi (các xác nhận ngữ nghĩa của nó phát hiện thấy không đúng), và lỗi đó không thể sửa được bằng cách ghi lại một sự kiện mới mà nó bổ sung thêm những xác nhận thông qua chính ngữ nghĩa của nó. Đối với những trường hợp này cơ chế được cung cấp để ghi lại sự kiện mà ngữ nghĩa của nó xác nhận rằng các xác nhận được thực hiện trước đó bởi sự kiện mắc lỗi là có lỗi. Xem 7.4.1.2.

7.2  Mô đun loại sự kiện cốt lõi – Tổng quan

Mô đun định nghĩa dữ liệu Loại Sự kiện Cốt lõi quy định Loại Sự kiện để biểu thị sự kiện truy cập dữ liệu EPCIS. Các sự kiện này thông thường được tạo ra bởi ứng dụng Truy cập EPCIS và cung cấp cho hạ tầng EPCIS có sử dụng các hoạt động truy cập dữ liệu được định nghĩa ở 8.1. Các sự kiện này cũng được đáp ứng để truy vấn các hoạt động truy xuất các sự kiện theo tiêu chí truy vấn.

Các thành phần của mô đun này, theo nội dung ở 7.1.1 như sau:

– Loại Giá trị: Thành phần gốc được định nghĩa ở 2.3.1 và 2.3.2.

– Loại Sự kiện: Loại sự kiện được chỉ ra trong sơ đồ UML dưới đây và được định nghĩa ở 7.4.1 đến 7.4.5.

– Trường Sự kiện: Bao gồm một phần các định nghĩa về Loại Sự kiện.

– Loại Từ vựng: Các Loại được định nghĩa ở 7.3.2 đến 7.3.5 và tổng hợp ở 7.2.

– Thuộc tính dữ liệu chủ: Bao gồm một phần các định nghĩa về Loại từ vựng. Điều mong đợi là các nhóm công tác của ngành dọc công nghiệp sẽ định nghĩa thêm các thuộc tính dữ liệu chủ cho các từ vựng được định nghĩa tại đây.

– Thành phần Từ vựng: Không được cung cấp như là một phần của tiêu chuẩn này. Điều mong đợi là các nhóm công tác của ngành dọc về công nghiệp sẽ định nghĩa các thành phần từ vựng cho từ vựng của các Bước Kinh doanh.

(7.3.5), từ vựng Bố trí (7.3.5.2), và từ vựng Loại Giao dịch Kinh doanh (7.3.5.3.1)

Mô đun này định nghĩa sáu loại sự kiện, trong đó một sự kiện rất chung và năm phân tầng (một trong số đó không được chấp nhận của EPCIS 1.1) mà nó có thể diễn tả các sự kiện phát sinh từ hoạt động của chuỗi cung cấp của nhiều ngành công nghiệp khác nhau:

– Sự kiện EPCIS (7.4.1) là tầng nền tảng chung cho tất cả các loại sự kiện trong mô đun này cũng như mô đun khác.

– Sự kiện Đối tượng (7.4.1.2) diễn tả một sự kiện xảy ra đối với một hay nhiều đối tượng vật lý hoặc đối tượng số hóa.

– Sự kiện Tổ hợp (7.4.3) diễn tả một sự kiện xảy ra đối với một hay nhiều đối tượng tổ hợp cùng nhau về mặt vật lý (bị hạn chế về mặt vật lý tại cùng một nơi, cùng thời điểm như khi các thùng hàng được tập hợp đến palet).

– Sự kiện Số lượng (7.4.4) diễn tả một sự kiện liên quan đến số lượng các đối tượng đặc thù cùng chia sẻ một tầng EPC chung nhưng tại đây các danh tính cá nhân của các thực thể không quy định. Xét đến EPCIS 1,1 thì sự kiện này không được chấp nhận; Sự kiện Đối tượng (7.4.1.2) cùng với một hoặc nhiều Phần tử số lượng (7.3.3.3) phải được sử dụng thay thế.

– Sự kiện Giao dịch (7.4.5) diễn tả một sự kiện trong đó một hay nhiều đối tượng sẽ liên kết hoặc tách ra khỏi một hay nhiều giao dịch kinh doanh đã được định nghĩa.

– Sự kiện chuyển giao (7.4.6) diễn tả một sự kiện trong đó đối tượng đầu vào được tiêu thụ toàn bộ hoặc một phần và đối tượng đầu ra được sản xuất sao cho bất kì đối tượng đầu vào nào có thể góp phần với tất cả đối tượng đầu ra.

Sơ đồ UML chỉ ra các Loại Sự liện này như ở dưới đây:

CHÚ THÍCH Trong sơ đồ này, những cái tên nhất nào đó được viết tắt do không gian hạn chế ví dụ Bizlocation ID được sử dụng trên sơ đồ khi đó loại thực sự được gọi là BusinessLocation ID. Xem nội dung của quy định kĩ thuật đối với các tên quy định của các trường sự kiện và các loại của chúng.

Hình 6 – Sơ đồ UML cho các loại sự kiện

Mỗi loại sự kiện cốt lõi (không tính Sự kiện EPCIS chung) có trường diễn tả bốn kích thước chính cho mỗi sự kiện EPCIS. Bốn kích thước này là: (1) các đối tượng hoặc thực thể là đối tượng của sự kiện; (2) ngày và tháng; (3) địa điểm sự kiện hiện diện; (4) bối cảnh kinh doanh. Bốn kích thước này có thể dễ nhớ như, “cái gì, khi nào, ở đâu và vì sao” (một cách lần lượt) Kích thước, “cái gì” đa dạng phụ thuộc vào loại sự kiện (ví dụ, đối với một sự kiện đối tượng kích thước, “cái gì” gồm một hay nhiều EPCs; đối với Sự kiện Tổ hợp kích thước, “cái gì” gồm ID của thế hệ bố và banh sách các EPCs thế hệ con). Các kích thước, “ở đâu” và, “tại sao”có cả khía cạnh trong quá khứ và trong tương lai (xem 7.1.3) được diễn tả bởi các trường khác nhau.

Bảng dưới đây tổng hợp các trường loại sự kiện liên quan đến bốn kích thước chính

Bảng 4 – Các trường loại sự kiện liên quan đến bốn kích thước chính

	Trong quá khứ	Trong tương lai
Cái gì/thế nào	EPC Tầng EPC + số lượng
Khi nào	Thời gian
Ở đâu	ID Điểm đọc	ID nơi kinh doanh
Vì sao (bối cảnh kinh doanh)	ID bước kinh doanh	ID bố trí
	Danh sách giao dịch kinh doanh Nguồn/nơi đến ILMD

Ngoài trường thuộc bốn kích thước chính này các sự kiện có thể mang thông tin mô tả ở các trường khác. Hy vọng rằng phần lớn các trường thông tin mô tả được định nghĩa bởi các quy định kĩ thuật của ngành công nghiệp đặc thù được bố trí phía trên.

Bảng dưới đây tổng hợp các loại từ vựng được định nghĩa ở mô đun này. Cột URI đưa ra tên chính thức đối với từ vựng được dùng khi từ vựng phải tham chiếu đến nhờ tên qua giao diện EPCIS.

Bảng 5 – Các loại từ vựng

Loại từ vựng	Điều khoản	Người sử dụng/ tiêu chuẩn	URI
ID Điểm Đọc	7.3.4	Người sử dụng	urn: epcis toàn cầu: loại v: Điểm Đọc
ID vị trí Kinh doanh	7.3.4	Người sử dụng	urn: epcis toàn cầu: loại v: Khu vực Kinh doanh
ID Bước Kinh doanh	7.3.5	Tiêu chuẩn	urn: epcis toàn cầu: loại v: bước kinh doanh
ID Bố trí	7.3.5.2	Tiêu chuẩn	urn: epcis toàn cầu: loại v: bố trí
Giao dịch Kinh doanh	7.3.5.3.2	Người sử dụng	urn: epcis toàn cầu: loại v: Giao dịch Kinh doanh
ID Loại Giao dịch Kinh doanh	7.3.5.3.1	Tiêu chuẩn	um: epcis toàn cầu: loại v: Loại Giao dịch Kinh doanh
Tầng EPCC	7.3.5.4	Người sử dụng	urn: epcis toàn cầu: loại v: tầng EPCC
ID Loại Nguồn Đến	7.3.5.4.1	Tiêu chuẩn	urn: epcis toàn cầu: loại v: Loại nguồn đến
ID Nguồn Đến	7.3.5.4.2	Người sử dụng	urn: epcis toàn cầu: loại v: nguồn đến
ID vị trí	Xem ở dưới	Người sử dụng	urn: epcis toàn cầu: loại v: khu vực
ID Lý do Lỗi	7.4.1.2	Tiêu chuẩn	urn: epcis toàn cầu: loại v: Lý do Lỗi

Loại ID vị trí là siêu loại của ID Điểm Đọc, ID Bước Kinh doanh, ID Nguồn Đến. Trong tài liệu dữ liệu chủ EPCIS (hoặc tiêu đề dữ liệu chủ cùng với tài liệu EPCIS hoặc tài liệu truy vấn EPCIS), urn: epcis toàn cầu: loại v: URI khu vực có thể sử dụng để quy định một từ vựng duy nhất có chứa mã phân định mà có thể xuất hiện tại điểm đọc, bước kinh doanh, nguồn hoặc trường nơi đến của các sự kiện EPCIS liên kết.

7.3  Mô đun loại sự kiện cốt lõi – khối cấu trúc

Điều này quy định khối cấu trúc cho các loại sự kiện được định nghĩa ở 7.3.5.4.

7.3.1  Loại nguyên thủy

Các loại nguyên thủy sau đây được sử dụng cùng với mô đun Loại sự kiện cốt lõi

Bảng 6 – Các môđun loại nguyên thủy

Loại	Mô tả
Số nguyên	Một số nguyên, các khoảng giới hạn được ghi ở nơi cần ghi
Thời gian	Dấu thời gian cung cấp ngày và thời gian theo cách không phụ thuộc vào múi giờ, đối với các ràng buộc mà trường của loại này được trình bày bằng văn bản thì PHẢI trình bày phù hợp với ISO 8601
EPC	Mã Điện tử Sản phẩm, như định nghĩa trong [TDS1.9], Nếu không có ghi chép nào khác EPCs được trình bày dưới dạng URI “danh tính thuần khiết” như định nghĩa trong [TDS1.9], điều 7.

Loại EPC được định nghĩa là loại nguyên thủy để sử dụng trong các sự kiện khi tham chiếu đến EPCs mà chúng không là một phần của loại từ vựng, ví dụ: một SGTIN EPC được sử dụng để thể hiện một trường hợp của một thương phẩm trong trường danh mục epc của một sự kiện đối tượng là sự thể hiện của loại EPC nguyên thủy. Tuy nhiên một SGLN EPC được sử dụng như là mã phân định điểm đọc (7.3.4) trong trường điểm đọc của một sự kiện đối tượng là một thành phần từ vựng chứ không là sự thể hiện loại EPC nguyên thủy.

Không bắt buộc: Giải thích: Điều này phản ánh một quyết định về thiết kế mà không xét đến các trường hợp thương phẩm cá thể như các thành phần từ vựng có dữ liệu chủ, do thực tế là các trường hợp thương phẩm liên tục được tạo ra và vì vậy các EPCs mới đại diện cho các thương phẩm liên tục được đặt mua. Một phần, quyết định về thiết kế này phần ánh việc xử lý nhất quán dữ liệu chủ như loại trừ dữ liệu phát triển khi hoạt động kinh doanh có nhiều giao dịch hơn (xem bình luận ở 6.1), và một phần phản ánh thực tế hữu dụng là dữ liệu thể hiện thương phẩm có khả năng được quản lý như dữ liệu sự kiện hơn là dữ liệu chủ khi nói đến lão hóa, thiết kế cơ sở dữ liệu, v. v.

7.3.2  Loại hành động

Loại hành động nêu cách một sự kiện liên quan đến chu trình sống của thực thể đang được mô tả như thế nào. Ví dụ Sự kiện Tổ hợp (7.4.3) được sử dụng để truy cập sự kiện liên quan đến sự tập hợp các đối tượng lại, như các thùng hàng được tập hợp đến một palet. Trong suốt vòng đời của mình palet tham gia vào nhiều bước của quá trình kinh doanh, mỗi bước đó có thể phát sinh một sự kiện EPC. Trường hành động của mỗi sự kiện nêu tổ hợp bản thân tự thay đổi trong suốt sự kiện như thế nào: liệu các đối tượng đã được bổ sung vào tổ hợp này chưa, liệu các đối tượng đã được loại ra khỏi tổ hợp này chưa, hoặc tổ hợp này đơn giản đã từng được phát hiện mà không làm thay đổi thành viên của nó? Hành động độc lập với bước kinh doanh (ID loại Bước Kinh doanh), nó phân định bước của quá trình kinh doanh đặc thù mà hành động xảy ra

Loại hành động là loại được đánh số có ba giá trị có thể:

Bảng 7 – Giá trị hành động

Giá trị hành động	Ý nghĩa
ADD	Thực thể ở đây đã từng được kiến tạo hoặc bổ sung vào
Phát hiện	Thực thể ở đây chưa bị thay đổi: nó chưa được kiến tạo, bổ sung vào, triệt tiêu cũng như loại bỏ ra.
Hủy	Thực thể ở đây đã từng bị loại ra hoặc đồng triệt tiêu tất cả

Mô tả dưới đây đối với từng loại sự kiện bao gồm cả giá trị hành động nêu một cách chính xác hơn là hành động nào có ý nghĩa trong bối cảnh của sự kiện đó

Lưu ý là ba giá trị ở trên chỉ là ba giá trị có thể đối với hành động. Không như các loại khác được định nghĩa dưới đây, Hành động không là loại từ vựng, và KHÔNG ĐƯỢC mở rộng bởi các nhóm công nghiệp.

7.3.3  Kích thước “Cái gì”

Phần này định nghĩa các loại dữ liệu được sử dụng trong kích thước “Cái gì” đối với các loại sự kiện quy định ở 7.3.5.4.

7.3.3.1  Cấp độ – cá thể với Nhận dạng cấp độ – tầng

Kích thước “Cái gì” đối với sự kiện EPC quy định các đối tượng vật lý hay số hóa nào tham gia vào sự kiện. EPCIS cung cấp các đối tượng để nhận dạng theo hai cách:

– Cấp độ – cá thể: Mã phân định được nêu đến là mã phân định cấp độ – cá thể nếu mã phân định như vậy được cấp sao cho nó là đơn nhất cho một đối tượng duy nhất. Điều đó có nghĩa là không có hai đối tượng nào được mang cùng một mã phân định cấp độ – cá thể.

– Cấp độ – tầng: Mã phân định được nêu đến là mã phân định cấp độ – tầng nếu nhiều đối tượng có thể mang cùng một mã phân định

– Nhìn chung, mã phân định cấp độ – cá thể cho phép các sự kiện EPCIS chuyền tải nhiều thông tin hơn vì có thể tương quan nhiều sự kiện EPCIS có kích thước “cái gì” có cùng mã phân định cấp độ – cá thể. Ví dụ, nếu sự kiện EPCIS chứa mã phân định cấp độ – cá thể đã cho, và sự kiện EPCIS tiếp theo chứa cùng mã phân định thì đó chắc chắn là cùng một đối tượng đã tham gia vào cả hai sự kiện. Ngược lại, nếu cả hai sự kiện chứa các mã phân định cấp độ – tầng thì nó không chắc chắn rằng cùng một đối tượng đã tham gia vào cả hai sự kiện bởi vì sự kiện thứ hai không thể là trường hợp khác cùng tầng (có nghĩa là một đối tượng khác mang cùng mã phân định cấp độ – tầng như đối tượng ban đầu ). Mã phân định cấp độ – tầng thường chỉ sử dụng khi việc cấp mã phân định cấp độ – cá thể đơn nhất cho từng đối tượng là không thực tế

Không bắt buộc: Ví dụ: Trong hệ thống GS1, ví dụ về mã phân định cấp độ – cá thể gồm GTIN + xê-ri, SSCC, GRAI kể cả xê-ri, GIAI, GSRN, và GDTI kể cả xê-ri. Ví dụ mã phân định cấp độ-tầng gồm GTIN, GTIN + lot, GRAI không có xê-ri, và GDTI không có xê-ri

7.3.3.2  EPC

Mã điện tử sản phẩm (EPC) là một cấu trúc của mã phân định cấp độ – cá thể được định nghĩa trong tiêu chuẩn dữ liệu thẻ EPC [TDS1.9], Trong kích thước “Cái gì” của sự kiện EPCIS, giá trị của thành phần epc PHẢI là URI [RFC2396] biểu thị danh tính đơn nhất của cấp độ – cá thể cho đối tượng. Khi danh tính đơn nhất là mã điện tử sản phẩm thì thành phần của danh mục PHẢI là URI “danh tính thuần khiết” đối với EPC như quy định ở [TDS1.9], điều 6. Việc triển khai có thể chấp nhận mã định dạng URI khác với EPCs làm giá trị thành phần epc.

7.3.3.3  Thành phần số lượng

Thành phần số lượng là cấu trúc định dạng các đối tượng được phân định bởi mã phân định cấp độ – tầng riêng biệt, cũng như số lượng riêng biệt hoặc số lượng không xác định. Nó có cấu trúc như sau:

Bảng 8 – Cấu trúc định dạng của đối tượng

Trường	Loại	Mô tả
Tầng epc	Tầng EPC	Mã phân định cấp độ-tầng đối với tầng có số lượng đối tượng quy định trực thuộc
Số lượng	Số thập phân	(tự chọn) con số quy định xem bao nhiêu tầng EPC được biểu thị bởi phần tử số lượng này Số lượng này có thể khuyết để chỉ ra rằng số lượng không rõ, hoặc không quy định, nếu khuyết số lượng thì uom cũng PHẢI khuyết, nếu không thì số lượng đã được quy định. Nếu thành phần số lượng thiếu trường uom (dưới đây) thì số lượng PHẢI có giá trị nguyên dương và biểu thị một số lượng các cá thể của tầng EPC quy định được biểu thị bởi thành phần số lượng này. Nếu thành phần số lượng có uom thì số lượng PHẢI có giá trị dương (nhưng không nhất thiết là số nguyên) và biểu thị độ lớn của số đo vật lý mà nó quy định xem bao nhiêu tầng EPC quy định được biểu thị bởi thành phần số lượng này.
uom	UOM	(tự chọn) Nếu hiện tại quy định đơn vị đo theo đó số lượng quy định được diễn giải là thước đo vật lý và quy định bao nhiêu tầng EPC quy định được biểu thị bởi thành phần số lượng này. Uom PHẢI khuyết nếu số lượng khuyết.

Tầng EPC là một từ vựng mà các thành phần của nó biểu thị các tầng đối tượng. Tầng EPC là từ vựng của người sử dụng như định nghĩa ở 6.2. Bất kì EPC nào có cấu trúc kết hợp với khái niệm tầng đối tượng có thể tham chiếu như một tầng EPC. Tiêu chuẩn cho GTIN EPCs được nghiên cứu dưới đây.

Một tầng EPC có thể nhằm vào một tầng có số đo cố định hoặc số đo biến thiên. Tầng số đo cố định có các trường hợp có thể đếm được; ví dụ GTIN nhằm vào hộp cát tông có kích cỡ cố định của sản phẩm. Tầng số đo biến thiên có các trường hợp không thể tính được và vì vậy số lượng được quy định như là thước đo vật lý; GTIN nhằm vào dây đồng được bán theo độ dài, còn thảm thì bán theo diện tích của tấm, dầu số lượng lớn lại bán theo dung tích, hoặc sản phẩm tươi sống được bán theo trọng lượng. Bảng sau đây tóm tắt cách các trường số lượng và uom được sử dụng trong mỗi trường hợp:

Bảng 9 – Cách sử dụng các trường số lượng và uom

Tầng EPC	Trường số lượng	Trường uon	Nghĩa
Số đo cố định	Số nguyên dương	Đã bỏ	Trường số lượng quy định số lượng của tầng được quy định.
Số đo biến thiên	Số dương, không nhất thiết là số nguyên	Đang hiện hành	Trường số lượng quy định độ lớn và trường uom của đơn vị vật lý, của số đo vật lý mô tả số lượng của tầng được quy định.
Số đo cố định hoặc biến thiên	Đã bỏ	Đã bỏ	Số lượng không xác định hoặc không quy định.

Các thuộc tính dữ liệu chủ đối với từ vựng tầng EPC chứa bất kì dữ liệu chủ nào được định nghĩa cho các đối tượng được tham chiếu độc lập với EPCIS (ví dụ, dữ liệu danh mục sản phẩm); các định nghĩa của chúng nằm ngoài phạm vi của tiêu chuẩn này.

7.3.3.3.1  UOM

Như quy định ở trên, trường uom của thành phần số lượng có mặt khi nó sử dụng số đo vật lý để xác định số lượng của tầng EPC được quy định. Khi có trường uom, giá trị của nó PHẢI là mã 2 hoặc 3 kí tự cho một đơn vị vật lý được quy định trong cột “Mã chung” của Khuyến nghị UN / CEFACT 20 [CEFACT20], Hơn nữa, mã này PHẢI là mã chứa trong một hàng [CEFACT20] đáp ứng tất cả các tiêu chí sau:

– Cột “Số lượng” chứa một trong các đại lượng sau: chiều dài, diện tích, thể tích hoặc khối lượng.

– Cột “Tình trạng” không chứa “X” (đã hủy) hoặc “D” (không được chấp nhận).

Đối với mục đích của tiêu chí đầu tiên, số lượng phải xuất hiện dưới dạng cụm từ hoàn chỉnh. Ví dụ: “Mét” (MTR) được cho phép, bởi vì số lượng bao gồm chiều dài (trong số các đại lượng khác như chiều rộng, chiều cao, vv). Nhưng không được phép “pound-force per foot” (F17), bởi vì số lượng là lực chia cho chiều dài, không chỉ là chiều dài.

7.3.3.3.2  Giá trị của tầng EPC đối với GTIN

Khi một phần tử từ vựng trong EPCCIass đại diện cho tầng SGTIN EPC được biểu thị bằng một GTIN cụ thể, nó PHẢI là một URI theo dạng sau, như được định nghĩa trong Phiên bản 1.3 và sau này của các tiêu chuẩn dữ liệu thẻ EPC:

urn: epc: idpat: sgtin: CompanyPrefix.ltemRefAndlndicator. *

Khi CompanyPrefix là tiền tố doanh nghiệp GS1 của GTIN (bao gồm cả số 0 đứng đầu) và ItemRefAndlndicator bao gồm chữ số chỉ thị của GTIN theo sau là các chữ số tham chiếu vật phẩm của GTIN.

Phần tử từ vựng EPCCIass trong biểu mẫu này biểu thị tầng đối tượng có EPC là SGTIN (urn: epc: id: sgtin:…) có cùng trường CompanyPrefix và temRefAndIndicator và có bất kì số sê-ri nào (hoặc không có số sê-ri nào).

7.3.3.3.3  Giá trị của tầng EPC đối với GTIN + lô hàng

Khi một phần tử từ vựng trong EPCCIass đại diện cho tầng SGTIN EPC được biểu thị bằng một GTIN cụ thể và lô / đợt, nó PHẢI là một URI ở dạng sau, như được định nghĩa trong [TDS1.9, Phần 6]:

urn: epc: class: Igtin: CompanyPrefix.ltemRefAndlndicator.Lot

Khi CompanyPrefix là tiền tố doanh nghiệp GS1 của GTIN (kể cả số 0 đứng đầu), ItemRefAndlndicator bao gồm chữ số của chỉ số GTIN theo sau là các chữ số tham chiếu vật phẩm của GTIN và Lot là số lô / đợt của lô/đợt cụ thể.

Phần tử từ vựng EPCCIass trong biểu mẫu này biểu thị tầng đối tượng có EPC là SGTIN (urn: epc: id: sgtin:…) có cùng trường CompanyPrefix và ItemRefAndlndicator và thuộc về lô / đợt quy định, bất kể số sê-ri (nếu có).

7.3.3.3.4  Tóm tắt các loại mã phân định (không bắt buộc)

Phần này tóm tắt các mã phân định có thể được sử dụng trong kích thước thứ nguyên “cái gì” của các sự kiện EPCIS. Các quy định kĩ thuật tiêu chuẩn của các mã phân định nằm trong Tiêu chuẩn dữ liệu thẻ EPC [TDS1.9] và từ vựng doanh nghiệp cốt lõi EPC [CBV1.2].

Bảng 10 – Tóm tắt các mã phân định

Loại mã phân định	Cấp độ – cá thể (EPC)	Cấp độ – tầng (EPCClass)	Tiền tố URI	Chuẩn tham chiếu
GTIN		□	urn:epc:idpat:sgtin:	[TDS1.9, Section 8]
GTIN + lô/đợt		□	urn:epc:class:lgtin:	[TDS1.9, Section 6]
GTIN + sê-ri	□		urn:epc:id:sgtin:	[TDS1.9, Section 6.3.1]
SSCC	□		urn:epc:id:sscc:	[TDS1.9, Section 6.3.2]
GRAI (không sê-ri)		□	urn:epc:idpat:grai:	[TDS1.9, Section 8]
GRAI (có sê- ri)	□		urn:epc:id:grai:	[TDS 1.9, Section 6.3.4]
GRAI	□		urn:epc:id:giai:	[TDS1.9, Section 6.3.5]
GDTI (không sê-ri)		□	urn:epc:idpat:gdti:	[TDS1.9, Section 8]
GDTI (có sê-ri)	□		urn:epc:id:gdti:	[TDS1.9, Section 6.3.7]
GSRN (người nhận)	□		urn:epc:id:gsrn:	[TDS1.9, Section 6.3.6]
GSRN (người cung cấp)	□		urn:epc:id:gsrnp:	[TDS1.9, Section 6.3.6]
GCN (không sê- ri)		□	urn:epc:idpat:sgcn:	[TDS1.9, Section 8]
GCN (có sê- ri)	□		urn:epc:id:sgcn:	[TDS1.9, Section 6]
CPI		□	urn:epc:idpat:cpi:	[TDS1.9, Section 8]
CPI + sê – ri	□		urn:epc:id:cpi:	[TDS1.9, Section 6.3.11]
GID	□		urn:epc:id:gid:	[TDS1.9, Section 6.3.8]
USDoD	□		urn:epc:id:usdod:	[TDS1.9, Section 6.3.9]
ADI	□		urn:epc:id:adi:	[TDS1.9, Section 6.3.10]
Không phải mã phân định GS1	□	□	Bất kì URI – xem CBV để khuyến cáo	[CBV1.2, Section 8.2]

7.3.4  Kích thước “ở đâu” – điểm đọc và vị trí kinh doanh

Phần này định nghĩa bốn loại liên quan đến khái niệm về thông tin vị trí như được sử dụng trong EPCIS. Hai trong số các loại này là cách đề cập đến “máy đọc” hoặc các thiết bị cảm nhận sự hiện diện của các đối tượng được gắn thẻ EPC bằng cách sử dụng RFID hoặc các phương tiện khác. Điều này thực sự hoàn toàn không được coi là loại “vị trí” đối với mục đích của EPCIS. Chúng được đưa vào tiêu chuẩn này chủ yếu để đối chiếu chúng với các loại vị trí thực (mặc dù một số ứng dụng có thể muốn sử dụng chúng như các trường mở rộng về mặt quan sát, cho mục đích đánh giá/kiểm toán). Hai loại khác là các loại vị trí thực, và được định nghĩa là các loại từ vựng EPCIS.

Các loại máy đọc / vị trí như sau:

Bảng 11 – Các loại máy đọc và vị trí thực

Loại	Mô tả
Loại máy đọc nguyên thủy	không phải loại vị trí cho EPCIS
ID máy đọc vật lý	Đây là danh tính duy nhất hoặc tên của nguồn thông tin cụ thể (ví dụ: một máy đọc vật lý RFID) báo cáo kết quả của sự kiện đọc EPC. ID máy đọc vật lý được định nghĩa thêm trong [ALE1.0].
ID máy đọc kiểu logic	Đây là danh tính hoặc tên được gán cho nguồn thông tin sự kiện đọc EPC độc lập với thiết bị vật lý hoặc thiết bị được sử dụng để thực hiện sự kiện đọc. ID máy đọc logic được được định nghĩa thêm trong [ALE1.0]. Lý do để giới thiệu khái niệm máy đọc Logic như được nêu trong [ALE1.0], bao gồm cho phép các máy đọc vật lý được thay thế mà không yêu cầu thay đổi đối với ứng dụng truy cập EPCIS, cho phép nhiều máy đọc vật lý được cung cấp một tên khi chúng luôn được sử dụng đồng thời để phủ một vị trí duy nhất và (ngược lại) cho phép một máy đọc vật lý duy nhất ánh xạ tới nhiều máy đọc logic khi một máy đọc vật lý có nhiều anten được sử dụng độc lập để phủ các vị trí khác nhau.
Loại vị trí thực
ID điểm đọc	Điểm đọc là một vị trí được ghi lại một cách rời rạc nhằm xác định vị trí cụ thể nhất mà tại đó một sự kiện EPCIS đã diễn ra. Các điểm đọc được xác định bởi ứng dụng truy cập EPCIS, có thể suy ra như một hàm của máy đọc logic nếu máy đọc cố định được sử dụng, có thể được xác định công khai bằng cách đọc thẻ vị trí nếu máy đọc là thiết bị di động hoặc được xác định bằng bất kì phương tiện nào khác mà ứng dụng truy cập EPCIS chọn để sử dụng, về mặt khái niệm, điểm đọc được thiết kế để xác định “các đối tượng ở thời điểm xảy ra sự kiện EPCIS”.
ID vị trí kinh doanh	Vị trí kinh doanh là một vị trí được xác định duy nhất và được ghi lại một cách rời rạc nhằm xác định vị trí cụ thể mà đối tượng được giả định tuân theo sự kiện EPCIS cho đến khi được báo cáo ở một Vị trí kinh doanh khác bằng sự kiện EPCIS tiếp theo. Cùng với điểm đọc, ứng dụng truy cập EPCIS xác định Vị trí kinh doanh dựa trên bất kì cách thức nào mà nó chọn, về mặt khái niệm, Vị trí kinh doanh được thiết kế để xác định “nơi các đối tượng đang theo dõi sự kiện EPCIS”.

ID điểm đọc và ID điểm kinh doanh là các từ vựng người dùng như được định nghĩa trong Phần 6.2. Một số ngành công nghiệp có thể muốn sử dụng EPC như là các thành phần từ vựng, trong trường hợp này danh tính thuần túy URI như được định nghĩa trong [TDS1.9] PHẢI được sử dụng.”

Không quy định: Minh họa: Ví dụ: trong các ngành công nghiệp được điều hành bởi các quy định kĩ thuật chung của GS1, ID điểm đọc và ID vị trí kinh doanh có thể là SGLN-URI [TDS1.9, Phần 6.3.3] và ID máy đọc vật lý có thể là SGTIN-URI [TDS1.9, Mục 6.3.1].

Nhưng trong mọi trường hợp, các thành phần từ vựng vị trí không yêu cầu phải là EPC.

Không quy định: Giải thích: Cho phép URI không phải EPC đối với các vị trí cho phép các tổ chức tự do sử dụng lại cách đặt tên vị trí hiện tại.

Đối với tất cả các loại sự kiện EPCIS được định nghĩa trong phần 7.2 này, các sự kiện truy cập bao gồm các trường riêng biệt cho Điểm đọc và Vị trí kinh doanh . Trong hầu hết các trường hợp, cả hai trường hợp đều là tùy chọn, do đó vẫn có thể để một ứng dụng truy cập EPCIS chứa một phần thông tin nếu cả hai đều không được biết.

Không quy định: Giải thích: Máy đọc logic và máy đọc vật lý được bỏ qua ở các định nghĩa về các sự kiện EPCIS trong tiêu chuẩn này. Máy đọc vật lý thường không phải là thông tin hữu ích để trao đổi giữa các đối tác. Ví dụ: nếu máy đọc bị trục trặc và được thay thế bằng một máy đọc khác được sản xuất và kiểu giống hệt nhau, thì ID máy đọc vật lý đã thay đổi. Thông tin này ít được các đối tác thương mại quan tâm. Tương tự như vậy, ID máy đọc logic có thể thay đổi nếu tổ chức truy cập thay đổi cách thức thực hiện quy trình kinh doanh cụ thể; một lần nữa, không thường xuyên quan tâm đến một đối tác.

Sự khác biệt giữa Điểm đọc và vị trí kinh doanh có liên quan rất nhiều đến sự phân đôi giữa ngữ nghĩa hồi cứu/hồi tưởng/quá khứ và ngữ nghĩa tiềm năng/viễn cảnh/ tương lai được thảo luận ở trên. Nói chung, Điểm đọc đóng một vai trò trong ngữ nghĩa hồi cứu, trong khi Địa điểm kinh doanh có liên quan đến các báo cáo về tiềm năng. Điều này được thực hiện rõ ràng theo cách mỗi loại vị trí nhập vào các mô tả ngữ nghĩa được cho ở cuối mỗi phần bên dưới xác định một sự kiện truy cập EPCIS.

7.3.4.1  Ví dụ về sự khác biệt giữa điểm đọc và vị trí kinh doanh (Không quy định)

CHÚ DẪN

Thẻ	Thời gian	Điểm đọc	Vị trí kinh doanh	Bình luận
# 123	7: 00	“RP-DC#88-A”	nhận và nhập kho DC # 88	Sản phẩm vào DC qua cửa bến tàu # R1
# 123	9: 00	“RP-DC#88-K”	Gửi đi từ DC # 88	Sản phẩm trên băng tải để gửi đi
# 123	9: 30	“RP-DC#88-N”	Bỏ qua	Sản phẩm đã gửi đi qua cửa bến tàu # S2

Hình 7 – Ví dụ về điểm đọc và vị trí kinh doanh

Hình trên cho thấy một trường hợp sử dụng điển hình bao gồm các phòng có cửa cố định ở ranh giới của các phòng. Trong trường hợp này, các điểm Đọc tương ứng với các cửa ra vào (với thiết bị đo lường RFID) và Vị trí kinh doanh tương ứng với các phòng. Lưu ý rằng các Điểm Đọc và Vị trí kinh doanh không tương ứng một – một; tình huống duy nhất mà Điểm Đọc và Vị trí kinh doanh có thể có mối quan hệ 1: 1 là trường hợp bất thường của một căn phòng có một cánh cửa duy nhất, như một buồng kho nhỏ.

Tiếp tục xem xét ví dụ về phòng và cửa, Vị trí kinh doanh thường là loại vị trí quan tâm nhất đối với một ứng dụng kinh doanh, vì nó cho biết căn phòng nào là đối tượng đang ở. Vì vậy, nó có ý nghĩa để yêu cầu kiểm kê một địa điểm kinh doanh như kho phụ Ngược lại, Điểm đọc chỉ ra cửa mà qua đó đối tượng đi vào phòng. Nó không có ý nghĩa để yêu cầu kiểm kê một ô cửa. Mặc dù đôi khi không liên quan đến ứng dụng kinh doanh nhưng Điểm đọc vẫn quan tâm đến phần mềm cấp cao hơn để hiểu quy trình kinh doanh và trạng thái cuối cùng của đối tượng, đặc biệt với tỷ lệ đọc dưới 100%. Lưu ý rằng việc chỉ định đúng vị trí kinh doanh đòi hỏi cả đối tượng được gắn thẻ phải được quan sát tại điểm đọc và hướng chuyển động được xác định chính xác – một lần nữa báo cáo Điểm đọc trong sự kiện sẽ rất có giá trị đối với phần mềm cấp cao hơn.

Một chuỗi cung ứng giống như ví dụ phòng và cửa có thể được biểu diễn bằng biểu đồ trong đó mỗi nút trong biểu đồ biểu diễn một căn phòng có thể tìm thấy đối tượng và mỗi cung đại diện cho một cửa nối hai phòng. Do đó, vị trí kinh doanh tương ứng với các nút của biểu đồ này và các điểm Đọc tương ứng với các cung tròn. Nếu biểu đồ là một chuỗi thẳng, đơn hướng, các vòng cung đi qua bởi một đối tượng nhất định có thể được xây dựng lại từ việc biết các nút; nghĩa là thông tin về Điểm Đọc sẽ không cần thiết cho thông tin Vị trí kinh doanh. Tuy nhiên, trong các tình huống của thế giới thực, các đối tượng có thể theo nhiều đường và di chuyển “ngược” trong chuỗi cung ứng. Trong những tình huống thực tế này, việc cung cấp thông tin Điểm đọc ngoài thông tin Địa điểm kinh doanh có giá trị đối với phần mềm cấp cao hơn.

7.3.4.2  Giải thích các loại máy đọc so với loại vị trí (Không quy định)

Trong bối cảnh EPC, vị trí thuật ngữ đã được sử dụng để biểu thị nhiều điều khác nhau và điều này đã dẫn đến sự nhầm lẫn về ý nghĩa và cách sử dụng thuật ngữ, đặc biệt khi được xem từ góc độ kinh doanh. Sự nhầm lẫn này xuất phát từ một số nguyên nhân:

1. Trong những tình huống mà máy đọc EPC là dạng thiết bị văn phòng, có khuynh hướng tự nhiên để đánh giá máy đọc vị trí, mặc dù điều đó có thể không phải lúc nào cũng hợp lệ nếu có nhiều máy đọc ở một vị trí;

2. Có những tình huống mà máy đọc là dạng thiết bị văn phòng được đặt giữa những gì người kinh doanh sẽ xem xét là các địa điểm khác nhau (chẳng hạn như ở cửa giữa phòng sau và tầng bán hàng của cửa hàng bán lẻ) và do đó không xác định vị trí mà không có chỉ dẫn hướng mà đối tượng được gắn thẻ đang di chuyển;

3. Một máy đọc vật lý đơn có nhiều ăng-ten độc lập, có khả năng định vị địa chỉ có thể được sử dụng để phát hiện các đối tượng được gắn thẻ ở nhiều vị trí được người kinh doanh xem xét;

4. Ngược lại, nhiều hơn một máy đọc có thể được sử dụng để phát hiện các đối tượng được gắn thẻ trong những gì người kinh doanh sẽ xem xét một vị trí duy nhất;

5. Với máy đọc di động, một máy đọc đã cho có thể đọc các đối tượng được gắn thẻ ở nhiều vị trí, có thể sử dụng thẻ “vị trí” hoặc các phương tiện khác để xác định vị trí cụ thể được liên kết với một sự kiện đọc đã cho ;

6. Và cuối cùng, các vị trí mà một bên quan tâm (đối tác thương mại hoặc ứng dụng) có thể không được quan tâm hoặc ủy quyền để xem xét bởi một bên khác, thúc đẩy sự quan tâm bằng cách phân biệt các vị trí.

Chìa khóa để cân bằng các yêu cầu dường như xung đột này là xác định và liên kết các loại vị trí khác nhau, sau đó dựa vào ứng dụng truy cập Chụp EPCIS để ghi lại chúng đúng cách cho một sự kiện truy cập đã cho. Đây là lý do tại sao các sự kiện EPCIS chứa cả một ID điểm đọc và một ID vị trí kinh doanh (hai kiểu vị trí nguyên thủy).

Ngoài ra, trong lịch sử đã có nhiều nhầm lẫn xung quanh sự khác biệt giữa “vị trí” khi cần thiết bởi các ứng dụng cấp độ-EPCIS và nhận dạng của máy đọc. Quy định kĩ thuật EPCIS này xác định vị trí như một cái gì đó khá khác biệt với nhận dạng của máy đọc. Để giúp làm rõ điều này, các loại nhận dạng của máy đọc được xác định ở trên để cung cấp sự tương phản với các định nghĩa về các loại vị trí EPCIS thực. Ngoài ra, các loại nhận dạng của máy đọc có thể tham gia vào EPCIS như “các thuộc tính quan sát” khi một ứng dụng mong muốn giữ lại một bản ghi về những gì máy đọc đóng vai trò quan sát; ví dụ: cho mục đích kiểm toán, (truy cập và chia sẻ “các thuộc tính quan sát” sẽ yêu cầu việc sử dụng các trường mở rộng không được định nghĩa trong tiêu chuẩn này).

7.3.5  Tham số “Tại sao”

Phần này định nghĩa các loại dữ liệu được sử dụng trong tham số “Tại sao” của các loại sự kiện được quy định trong Phần 7.3.5.4.

7.3.5.1  Bước kinh doanh

ID bước kinh doanh là một từ vựng có các thành phần biểu thị các bước trong quy trình kinh doanh. Ví dụ là một mã phân định biểu thị “gửi hàng”. Trường bước kinh doanh của một sự kiện xác định bối cảnh kinh doanh của một sự kiện: bước nào trong quá trình kinh doanh đang diễn ra khiến cho sự kiện đó phải truy cập? ID bước kinh doanh là một ví dụ về từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định bước kinh doanh cho phép các tiêu chuẩn GS1 (bao gồm và đặc biệt là Từ vựng kinh doanh cốt lõi GS1) để xác định một số thuật ngữ phổ biến như “gửi hàng” hoặc “nhận hàng”, trong khi đó cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ riêng của họ. Dữ liệu chủ cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định bước kinh doanh.

7.3.5.2  Bố trí

ID bố trí là một từ vựng có các thành phần biểu thị trạng thái kinh doanh của một đối tượng. Ví dụ là mã phân định biểu thị “thu hồi”. Trường bố trí sự kiện quy định điều kiện kinh doanh của các đối tượng sự kiện, tiếp sau sự kiện. Việc bố trí được giả định là đúng cho đến khi một sự kiện khác biểu thị sự thay đổi của bố trí. Các sự kiện can thiệp không quy định trường bố trí không làm ảnh hưởng đến bố trí của đối tượng. ID bố trí là một ví dụ về từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định bố trí cho phép các tiêu chuẩn GS1 (bao gồm và đặc biệt là Từ vựng kinh doanh cốt lõi GS1) đề định nghĩa một số thuật ngữ phổ biến như “thu hồi” hoặc “quá cảnh”. ”, trong khi đó cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ riêng của họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định việc bố trí.

7.3.5.3  Giao dịch kinh doanh

Giao dịch kinh doanh xác định một giao dịch kinh doanh cụ thể. Ví dụ về giao dịch kinh doanh là một đơn đặt hàng cụ thể. Thông tin giao dịch kinh doanh có thể được đưa vào trong sự kiện EPCIS để lưu lại sự tham gia của sự kiện trong các giao dịch kinh doanh cụ thể.

Giao dịch kinh doanh được mô tả trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định như sau.

Bảng 12 – Giao dịch kinh doanh trong EPCIS theo cấu trúc bao gồm một cập mã phân định

Trường	Loại	Mô tả
Loại	ID loại giao dịch kinh doanh	(Tùy chọn) Mã phân định cho biết loại giao dịch kinh doanh nào mà Giao dịch kinh doanh này biểu thị. Nếu bỏ qua, không có thông tin về loại giao dịch kinh doanh ngoài những gì được ngụ ý bởi giá trị của chính trường Giao dịch kinh doanh B
Giao dịch B	ID giao dịch kinh doanh	Mã phân định biểu thị giao dịch kinh doanh cụ thể.

Hai loại từ vựng ID loại giao dịch kinh doanh và ID giao dịch kinh doanh được định nghĩa trong các phần bên dưới

7.3.5.3.1  Loại giao dịch kinh doanh

ID Loại giao dịch kinh doanh là một từ vựng có các thành phần biểu thị một loại giao dịch kinh doanh cụ thể. Ví dụ là mã phân định biểu thị “đơn đặt hàng”. ID Loại giao dịch kinh doanh là ví dụ về Từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định loại giao dịch kinh doanh cho phép các tiêu chuẩn GS1 định nghĩa một số thuật ngữ phổ biến như “đơn đặt hàng” trong khi cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ của riêng họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định giao dịch kinh doanh.

7.3.5.3.2  ID giao dịch kinh doanh

ID giao dịch kinh doanh là một từ vựng có các thành phần biểu thị các giao dịch kinh doanh cụ thể. Ví dụ là mã phân định biểu thị “Số đơn đặt hàng của Acme Corp 12345678.” ID giao dịch kinh doanh là Từ vựng người sử dụng như được định nghĩa trong 6.2.

Không quy định: Giải thích: URI được sử dụng để cung cấp khả năng mở rộng và cách thức thuận tiện để các tổ chức phân biệt một loại mã phân định giao dịch với một loại khác. Ví dụ: nếu Công ty Acme có đơn đặt hàng (một loại giao dịch kinh doanh) được xác định bằng số gồm 8 chữ số cũng như lô hàng (một loại giao dịch kinh doanh khác) được phân định bằng chuỗi 6 kí tự và hơn nữa. Công ty PostHaste Shipping sử dụng 12 ID theo dõi số, sau đó các ID giao dịch kinh doanh sau đây có thể được liên kết với một EPC cụ thể theo thời gian:

http://transaction.acme. com/po/12345678

http://transaction.acme.com/shipment/34ABC8

urn:posthaste:tracking: 123456789012

(Trong ví dụ này, giả định rằng PostHaste Shipping đã đăng kí tên miền “posthaste” của URN với IANA.) Ứng dụngTruy cập EPCIS có thể truy vấn EPCIS và khám phá cả ba ID giao dịch; sử dụng các URI cung cấp cho ứng dụng một cách để hiểu ID nào quan tâm đến nó.

7.3.5.4  Nguồn và đích

Nguồn hoặc Đích được sử dụng để cung cấp bối cảnh kinh doanh bổ sung khi sự kiện EPCIS là một phần của việc chuyển giao kinh doanh; có nghĩa là, một quá trình trong đó có sự chuyển giao quyền sở hữu, trách nhiệm và / hoặc quyền nuôi đối tượng vật lý hoặc đối tượng số hóa.

Trong nhiều trường hợp việc chuyển giao kinh doanh đòi hỏi một số bước kinh doanh riêng lẻ (và vì vậy một số sự kiện EPCIS) để thực thi; ví dụ, vận chuyển tiếp theo là nhận hoặc một chuỗi phức tạp hơn như xếp tải → khởi hành → vận chuyển → đến nơi → dỡ tải → nhận hàng. Điểm đọc (ReadPoint) và vị trí kinh doanh (BusinessLocation) trong tham số “ở đâu” của các sự kiện EPCIS này chỉ ra vị trí vật lý đã biết tại mỗi bước của quá trình. Ngược lại, nguồn và đích có thể được sử dụng để chỉ ra các bên và / hoặc vị trí là điểm cuối dự định của việc chuyển giao kinh doanh. Trong chuyển giao kinh doanh đa bước, một số hoặc tất cả các sự kiện EPCIS có thể mang Nguồn và Đích, và thông tin sẽ giống nhau đối với tất cả các sự kiện trong một lần chuyển nhất định.

Nguồn và Đích cung cấp cách thức được tiêu chuẩn hóa để cho biết các bên và / hoặc vị trí thực tế có liên quan đến việc chuyển giao, bổ sung thông tin giao dịch kinh doanh (ví dụ: đơn đặt hàng, hóa đơn, v.v.) có thể được giới thiệu bởi các thành phần giao dịch kinh doanh.

Nguồn hoặc đích được mô tả trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định, như sau.

Bảng 13 – Nguồn hoặc đích trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định

Trường	Loại	Mô tả
Loại	SourceDestTypeID	Số nhận dạng cho biết loại nguồn hoặc đích nào Nguồn hoặc đích (tương ứng) biểu thị.
Nguồn hoặc đích đến	SourceDestID	Một mã định danh biểu thị một nguồn hoặc đích cụ thể.

Hai loại từ vựng ID loại nguồn đích và ID nguồn đích được định nghĩa trong các phần bên dưới.

7.3.5.4.1  ID loại nguồn / đích

ID loại nguồn đích là một từ vựng có các thành phần biểu thị một loại nguồn hoặc đích chuyển giao kinh doanh cụ thể. Ví dụ là một mã phân định biểu thị “bên sở hữu”. Id loại nguồn đích là một ví dụ về Từ vựng tiêu chuẩn như được định nghĩa trong Phần 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định loại nguồn / đích cho phép các tiêu chuẩn GS1 định nghĩa một số thuật ngữ phổ biến như “bên sở hữu” trong khi cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ của riêng họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không quy định các thuộc tính dữ liệu chủ cho các mã phân định loại nguồn / đích.

7.3.5.4.2  ID nguồn / đích

ID nguồn đích là một từ vựng có các yếu tố biểu thị các nguồn và đích cụ thể. Một ví dụ là mã phân định biểu thị “công ty Acme (một bên sở hữu)” ID nguồn đích là một từ vựng người sử dụng như được định nghĩa trong phần 6.2.

Không quy định: Giải thích: URI được sử dụng để cung cấp khả năng mở rộng và cách thức thuận tiện cho các tổ chức phân biệt một loại mã phân định nguồn hoặc đích với một loại khác.

7.3.6  Dữ liệu thực thể / Lô chủ (ILMD)

Dữ liệu thực thể / Lô chủ (ILMD) là dữ liệu mô tả một thực thể cụ thể của đối tượng vật lý hoặc số hóa hoặc một lô / lô cụ thể của đối tượng được sản xuất trong theo mẻ / lô. ILMD bao gồm một tệp các thuộc tính được mô tả nhằm cung cấp thông tin về một hoặc nhiều đối tượng hoặc lô cụ thể. Nó tương tự như dữ liệu chủ thông thường, cũng bao gồm một tệp các thuộc tính được mô tả nhằm cung cấp thông tin về các đối tượng. Nhưng trong khi các thuộc tính dữ liệu chủ có cùng giá trị cho một tầng đối tượng lớn (ví dụ, đối với tất cả các đối tượng có GTIN), giá trị của các thuộc tính ILMD có thể khác nhau đối với nhiều nhóm đối tượng nhỏ hơn (ví dụ: một mẻ duy nhất hoặc lô), và có thể khác nhau cho mỗi đối tượng (ví dụ, khác nhau cho từng trường hợp).

Ví dụ về thuộc tính dữ liệu chủ là trọng lượng và kích thước vật lý của các thương phẩm được phân định bằng GTIN cụ thể. Các giá trị này giống nhau đối với tất cả các vật phẩm dùng chung GTIN đó. Một ví dụ về ILMD là ngày hết hạn của một thương phẩm dễ hư hỏng. Không giống như dữ liệu chủ, ngày hết hạn không giống nhau đối với tất cả các thương phẩm có cùng GTIN; về nguyên tắc, mỗi vật phẩm có thể có ngày hết hạn khác nhau tùy thuộc vào thời điểm sản xuất. Các ví dụ khác về ILMD bao gồm ngày sản xuất, nơi sản xuất, trọng lượng và các kích thước vật lý khác của thương phẩm có số đo thay đổi, thông tin thu hoạch cho các sản phẩm nông nghiệp, v.v.

ILMD, giống như dữ liệu chủ thông thường, được dự định là tĩnh tại trong suốt vòng đời của đối tượng. Ví dụ, ngày hết hạn của một mặt hàng dễ hư hỏng hoặc trọng lượng của một mặt hàng có số đo biến đổi không thay đổi trong suốt vòng đời của thương phẩm, mặc dù các thương phẩm khác nhau có cùng GTIN có thể có giá trị khác nhau về ngày hết hạn và trọng lượng. HMD không được sử dụng để biểu diễn thông tin thay đổi trong vòng đời của một đối tượng, ví dụ, nhiệt độ hiện tại của một vật thể khi nó di chuyển qua chuỗi cung ứng.

Mặc dù có các tiêu chuẩn (như GDSN) cho việc đăng kí và phổ biến dữ liệu chủ thông thường thông qua chuỗi cung ứng, nhưng các tiêu chuẩn và các hệ thống phổ biến ILMD chưa có. Vì lý do này, EPCIS cho phép ILMD được thực hiện trực tiếp trong một số sự kiện EPCIS nhất định. Tính năng này chỉ nên được sử dụng khi không có hệ thống riêng biệt để phổ biến ILMD.

ILMD cho một đối tượng cụ thể được xác định khi đối tượng đó tồn tại. Do đó, HMD chỉ có thể được đưa vào trong ObjectEvents với ADD hành động (Mục 7.4.1.2) và trong TranstormationEvents (Mục 7.4.6). Trong trường hợp TransformationEvent, ILMD áp dụng cho các đầu ra biến đổi, không áp dụng cho các đầu vào.

Cấu trúc của ILMD được định nghĩa trong tiêu chuẩn EPCIS này bao gồm một tập các thuộc tính được đặt tên, có các giá trị thuộc bất kì loại nào. Trong liên kết XML (Phần 9.5), lược đồ XML cung cấp một danh sách các phần tử XML không giới hạn có tên và nội dung của bất kì phần tử nào. Các tài liệu khác được xếp chồng lên trên EPCIS có thể xác định các phần từ dữ liệu ILMD cụ thể; xem Phần 6.3. Theo cách này, ILMD tương tự như các phần mở rộng EPCIS cấp độ- sự kiện, nhưng tách biệt để nhấn mạnh rằng ILMD áp dụng cho toàn bộ vòng đời của các đối tượng, trong khi phần mở rộng EPCIS cấp độ – sự kiện chỉ áp dụng cho sự kiện cụ thể đó.

7.4  Mô-đun loại sự kiện cốt lõi – sự kiện

7.4.1  EPCISEvent

EPCISEvent là một loại cơ sở chung cho tất cả các sự kiện EPCIS. Tất cả các loại sự kiện cụ thể hơn trong các phần sau là các tầng con của EPCISEvent. Loại cơ sở chung này chỉ có các trường sau đây.

Bảng 14 – Các trường cho loại cơ sở chung

Trường	Loại	Mô tả
eventTime	Time	Ngày và thời gian mà các ứng dụng truy cập EPCIS khẳng định sự kiện đã xảy ra.
recordTime	Time	(Tùy chọn) Ngày và thời gian mà sự kiện này được ghi lại vào một Kho lưu trữ EPCIS. Trường này PHẢI được bỏ qua khi một sự kiện được trình bày cho Giao diện truy vấn EPCIS và PHẢI hiện diện khi một sự kiện được truy xuất thông qua Giao diện Truy vấn EPCIS. RecordTime không mô tả bất cứ điều gì về sự kiện trong thế gió’i thực, mà đúng hơn là một cơ chế kế toán giữ vai trò trong việc giải thích các truy vấn thường trực được quy định trong Mục 8.2.5.2.
eventTimeZoneOffset	String	Việc bù đắp múi giờ có hiệu lực tại thời điểm và địa điểm sự kiện xảy ra, được biểu thị dưới dạng một khoảng bù từ UTC. Giá trị của trường này PHẢI là một chuỗi kí tự ‘+’ hoặc kí tự ‘-‘, theo sau là hai chữ số có giá trị nằm trong khoảng từ 00 đến 14 (bao gồm cả 14), theo sau là kí tự dấu hai chấm ‘:’, theo sau bởi hai chữ số có giá trị nằm trong khoảng từ 00 đến 59 (bao gồm cả 59), ngoại trừ việc giá trị của hai chữ số đầu tiên là 14, giá trị của hai chữ số thứ hai phải là 00. Ví dụ: giá trị +05: 30 quy định khi sự kiện xảy ra, giờ địa phương là năm giờ và 30 phút chậm sau giờ UTC (nghĩa là, nửa đêm UTC là 5:30 sáng theo giờ địa phương).
eventID	EventID	(Tùy chọn) Mã phân định cho sự kiện này như được quy định bởi ứng dụng truy cập, duy nhất toàn cầu trên tất cả các sự kiện ngoài khai báo lỗi. “duy nhất Toàn cầu” có nghĩa khác với eventID trên bất kì sự kiện EPCIS nào khác trên bất kì việc triển khai EPCIS nào, không chỉ qua các sự kiện được truy cập bởi một ứng dụng truy cập duy nhất hoặc bởi một máy chủ truy cập duy nhất. (Tiêu chuẩn từ vựng kinh doanh cốt lõi [CBV1.2] quy định việc sử dụng URI UUID cho mục đích này.) Lưu ý rằng trong trường hợp khai báo lỗi, ID sự kiện sẽ bằng ID sự kiện của sự kiện sai (hoặc null nếu ID sự kiện của sự kiện sai lõi là null), và theo nghĩa đó không phải là duy nhất. Xem Phần 7.4.1.2.
errorDeclaration	ErrorDeclaraíion	(Tùy chọn) Nếu có, chỉ ra rằng sự kiện này phục vụ để khẳng định rằng các xác nhận được thực hiện bởi một sự kiện trước là do lỗi. Xem Phần 7.4.1.2.

7.4.1.1  Giải thích về eventTimeZoneOffset (không quy định)

Trường eventTimeZoneOffset không cần thiết để hiểu tại thời điểm nào một sự kiện xảy ra. Điều này là do trường eventTime là loại Time, được định nghĩa trong Mục 7.3 là “ngày và thời gian theo cách không phụ thuộc múi giờ”. Ví dụ, trong liên kết XML (Phần 9.5) trường eventTime được biểu diễn như một thành phần của loại xsd: dateTime và phần 9.5 hơn nữa quy định rằng XML phải bao gồm một bộ định thời gian vùng. Vì vậy, XML cho eventTime rõ ràng phân định một cách rõ ràng thời điểm theo thời gian tuyệt đối, và nó không cần thiết phải tham khảo eventTimeZoneOffset để hiểu những gì thời điểm đó là.

Mục đích của eventTimeZoneOffset là cung cấp bối cảnh kinh doanh bổ sung về sự kiện, cụ thể là để xác định chênh lệch múi giờ nào có hiệu lực vào thời điểm đó và địa điểm đã truy cập. Ví dụ: thông tin này có thể hữu ích để xác định xem một sự kiện có diễn ra trong giờ làm việc hay không, để trình bày sự kiện cho một người theo định dạng phù hợp với giờ địa phương, v.v. Thông tin bù giờ múi giờ địa phương không nhất thiết có sẵn từ eventTime, bởi vì không có yêu cầu rằng người quy định múi giờ trong trình diễn XML của eventTime là bù trừ múi giờ địa phương nơi sự kiện được truy cập. Ví dụ: sự kiện diễn ra lúc 8 giờ sáng theo Giờ chuẩn miền Đông Hoa Kì có thể có trường XML eventTime được viết 08: 00-05: 00 (sử dụng Giờ chuẩn miền Đông Hoa Kỳ) hoặc 13: 00Z (sử dụng UTC) hoặc thậm chí 07: 00-06: 00 (sử dụng Giờ chuẩn Trung tâm Hoa Kỳ). Hơn nữa, các bộ xử lý XML không được yêu cầu bởi [XSD2] để giữ lại và trình bày cho các ứng dụng bộ định thời gian múi giờ là một phần của trường xsd: dateTime, và do đó, người quy định múi giờ trong trường eventTime có thể không có sẵn cho các ứng dụng. Các cân nhắc tương tự sẽ áp dụng cho các ràng buộc khác (không phải XML) của mô-đun Các loại sự kiện cốt lõi. Ví dụ, một liên kết nhị phân giả định có thể đại diện cho các giá trị Thời gian dưới dạng mili giây tương đối so với nửa đêm UTC vào ngày 1 tháng 1 năm 1970 – một lần nữa, xác định rõ ràng một khoảnh khắc trong thời gian tuyệt đối, nhưng không cung cấp bất kì thông tin nào về múi giờ địa phương. Vì những lý do này, eventTimeZoneOffset được cung cấp dưới dạng trường sự kiện bổ sung.

7.4.1.2  ErrorDeclaration

Khi một sự kiện có chứa một phần tử ErrorDeclaration, nó chỉ ra rằng sự kiện này có ngữ nghĩa đặc biệt: thay vì các ngữ nghĩa thông thường, khẳng định rằng nhiều thứ khác nhau đã xảy ra và những điều khác nhau là đúng theo sau sự kiện này, ngữ nghĩa của sự kiện này khẳng định rằng những xác nhận trước đó là lỗi. Một sự kiện có chứa thành phần ErrorDeclaration PHẢI không giống với một sự kiện nào trước đó, “không giống hệt” nghĩa là tất cả các trường của sự kiện khác với thành phần ErrorDeclaration và giá trị của recordTime chính xác bằng với sự kiện trước đó. (Lưu ý rằng nó bao gồm trường eventID: eventID khai báo lỗi sẽ bằng với eventID của sự kiện trước hoặc null nếu eventID của sự kiện trước là null. Đây là trường hợp duy nhất mà cùng một eventID non-null có thể xuất hiện trong hai sự kiện.) Ngữ nghĩa của một sự kiện chứa phần tử ErrorDeclaration là tất cả các xác nhận được ngụ ý bởi sự kiện trước được coi là sai, như khai báo được quy định. Sự kiện trước đó không được sửa đổi bằng bất kì cách nào và các truy vấn tiếp theo sẽ trả lại cả sự kiện trước và khai báo lỗi.

Một phần tử ErrorDeclaration chứa các trường sau:

Bảng 15 – Các trường trong phần tử ErrorDeclaration

Trường	Loại	Mô tả
declarationTime	Timestamp	Ngày và giờ khai báo lỗi. (Lưu ý rằng eventTime của sự kiện này phải khớp với eventTime của sự kiện trước đó được khai báo sai, do đó trường declarationTime được yêu cầu để chỉ ra thời gian sự kiện này được xác nhận.)
reason	ErrorReasonID	(Tùy chọn) Một phần tử của từ vựng tiêu chuẩn quy định lý do sự kiện trước được coi là sai.
correctiveEventIDs	List<EventID>	(Tùy chọn) Nếu có, thì chỉ ra rằng các sự kiện có các URI được quy định làm giá trị của các trường EventID của chúng được coi là “sửa lỗi” cho sự kiện được khai báo sai sự kiện này. Điều này cung cấp một phương tiện để liên kết một sự kiện khai báo lỗi cho một hoặc nhiều sự kiện được dự định để thay thế sự kiện sai.

Một phần tử ErrorDeclaration KHÔNG được sử dụng nếu có một cách để mô hình hóa tình huống thực tế như một sự kiện bình thường (có nghĩa là, sử dụng một sự kiện không chứa một phần tử ErrorDeclaration).

7.4.1.3  Sử dụng các khai báo lỗi (Không bắt buộc)

Sự kiện EPCIS ghi lại việc hoàn thành một bước của quá trình kinh doanh. Một quá trình kinh doanh được mô hình hóa bằng cách chia nhỏ nó thành một loạt các bước, và mô hình hóa từng bước như một sự kiện EPCIS. Hiệu ứng ròng là tập hợp tất cả các sự kiện liên quan đến một đối tượng cụ thể (thường được gọi là “dấu vết”) phải chỉ rõ lịch sử và trạng thái hiện tại của đối tượng đó, bằng cách diễn giải các sự kiện theo ngữ nghĩa được quy định trong tiêu chuẩn này và các tiêu chuẩn từ vựng có liên quan.

Đôi khi, nó được phát hiện ra rằng một sự kiện được ghi lại trước đó không phản ánh chính xác những gì đã xảy ra trong thế giới thực. Trong các trường hợp như vậy, như đã nêu trong 6.1, các sự kiện trước đó sẽ không bao giờ bị xóa hoặc sửa đổi. Thay vào đó, các sự kiện bổ sung được ghi lại có hiệu lực là dấu vết hoàn chỉnh (bao gồm các sự kiện mới và tất cả các sự kiện trước đó kể cả sự kiện không chính xác) phản ánh chính xác lịch sử và trạng thái hiện tại, như đã nêu trong nguyên tắc trên.

Ưu tiên đến với các sự kiện bổ sung là công nhận rằng việc phát hiện ra một sự kiện sai và sửa chữa nó chính là một quá trình kinh doanh có thể được mô hình hoá bằng cách tạo ra các sự kiện EPCIS phù hợp. Trong hầu hết các trường hợp, điều này được thực hiện bằng cách sử dụng các sự kiện EPCIS từ Mô-đun các loại sự kiện cốt lõi như được quy định từ 7.4.1 đến 7.4.6, sử dụng từ vựng phù hợp.

Ví dụ 1: Công ty X ghi lại sự kiện EPCIS khẳng định rằng số sê-ri 101, 102 và 103 của một số sản phẩm đã được chuyển đến Công ty Y. Công ty Y nhận lô hàng và tìm số sê-ri 104 cùng với số sê-ri 101, 102, 103. khi thảo luận với Công ty X, đã được sự đồng ý là nối tiếp 104 đã thực sự được vận chuyển và sự kiện vận chuyển bị lỗi. Xử lý: Công ty X ghi lại một sự kiện EPCIS mới khẳng định rằng số sê-ri 104 đã được chuyển đi, với thông tin theo ngữ cảnh tương tự như sự kiện ban đầu.

Ví dụ 2: Công ty X ghi lại sự kiện EPCIS khẳng định rằng số sê-ri 101, 102 và 103 của một số sản phẩm đã được chuyển đến Công ty Y. Công ty Y nhận lỗ hàng và chỉ tìm thấy số sê-ri 101, 102. Khi thảo luận với Công ty X, đã được sự đồng ý là 103 nối tiếp đã không được giao mà vẫn nằm trong kho hàng tồn của Công ty X. Họ đồng ý trả lại tiền thanh toán cho sản phẩm thứ ba.

Xử lý: Công ty X ghi lại một sự kiện EPCIS mới khẳng định rằng lô hàng nối tiếp 103 bị hủy.

Trong ví dụ đầu tiên, sự kiện bổ sung sử dụng cùng một từ vựng kinh doanh như là từ đầu tiên. Trong ví dụ thứ hai, từ vựng đặc biệt liên kết với quá trình làm mất hiệu lực một lô hàng được sử dụng, nhưng nó vẫn là ngữ nghĩa EPCIS “bình thường” theo nghĩa là nó mô hình sự hoàn thành một bước của quá trình kinh doanh được xác định rõ. Điều này phản ánh thực tế rằng hành động khắc phục hậu quả chính nó là một quá trình kinh doanh, và do đó có thể được mô hình hóa như một sự kiện EPCIS.

Trong một số trường hợp, hoặc là không thể (hoặc là không mong muốn) để khắc phục lịch sử của một đối tượng bằng cách tạo ra một sự kiện EPCIS mới với ngữ nghĩa thông thường (nghĩa là, với ngữ nghĩa được quy định trong 7.4.1 đến 7.4.6).

Ví dụ 3: Công ty X ghi lại một sự kiện EPCIS để khẳng định rằng số sê-ri 101 của sản phẩm X đã bị hủy. Sự kiện này là một sự kiện đối tượng như được quy định trong phần 7.4.2 với hành động = HỦY/DELETE. Sau đó nó được phát hiện ra rằng nối tiếp 101 vẫn còn trong kho, không bị phá hủy. Một sự kiện bình thường không thể được sử dụng để sửa đổi lịch sử, bởi vì ngữ nghĩa của hành động HỦY/DELETE cho một sự kiện đối tượng xác định rằng “các đối tượng … không nên xuất hiện trong các sự kiện tiếp theo.”

Ví dụ 4: Công ty X ghi lại sự kiện EPCIS khẳng định rằng một số sản phẩm đã được giao, cho biết Đơn đặt hàng 123 là giao dịch kinh doanh theo tham số “tại sao”. Công ty Y nhận được sản phẩm và ghi lại một sự kiện tiếp nhận. Ngay sau đó, người ta phát hiện ra rằng tham chiếu đơn đặt hàng trong sự kiện vận chuyển là sai: PO 456 thay vì 123. Điều này có thể được khắc phục bằng sự kiện EPCIS thông thường bởi Công ty X ghi lại sự kiện “hủy lô hàng” và sau đó là sự kiện “giao hàng”, với PO # chính xác. Nhưng điều này là không mong muốn từ quan điểm của dấu vết tổng thể, đặc biệt là cho rằng đã có một sự kiện tiếp nhận.

Để phù hợp với các tình huống như vậy, Mô-đun các loại sự kiện cốt lõi cung cấp một cơ chế để khẳng định rằng các xác nhận được thực hiện bởi một sự kiện trước là do lỗi. Các ngữ nghĩa này chỉ có thể được sử dụng khi một sự kiện quy định chính xác các điều kiện giống như một sự kiện thông thường trước đó, để xác nhận lỗi có thể liên quan đến sự kiện trước đó. Sự kiện như vậy được gọi là “sự kiện khai báo lỗi”.

Trong Ví dụ 3 ở trên, sự kiện khai báo lỗi có nghĩa là số sê-ri 101 của sản phẩm X không bị hủy. Trong Ví dụ 4 ở trên, sự kiện khai báo lỗi có nghĩa là một lô hàng có PO 123 là bối cảnh không xảy ra và một sự kiện bổ sung (“sự kiện khắc phục”) sẽ cho biết rằng lô hàng có PO 456 đã xảy ra. Điều này khá giống với mô hình Ví dụ 4 sử dụng một sự kiện “hủy bỏ”, ngoại trừ việc xác nhận một lô hàng được thực hiện theo PO 123 sau đó bị hủy bỏ, sự kiện khai báo lỗi chỉ xác nhận rằng xác nhận PO 123 là sai.

Một sự kiện khai báo lỗi được cấu tạo bằng cách gộp một phần ErrorDeclaration. Cụ thể, với sự kiện E1, một sự kiện khai báo lỗi E2 có hiệu lực là khai báo các xác nhận của E1 có lỗi là một cấu trúc sự kiện có nội dung giống với E1, nhưng với thành phần ErrorDeclaration được gộp vào. Ví dụ, khai báo lỗi cho sự kiện “hủy bỏ” trong Ví dụ 3 cũng là một sự kiện đối tượng với hành động = HỦY/DELETE, nhưng với thành phần ErrorDeclaration được gộp vào. Nói chung, để khai báo sự kiện E bị lỗi, một sự kiện mới được ghi lại giống với sự kiện E ngoại trừ thành phần ErrorDeclaration cũng được gộp vào (và thời gian ghi sẽ khác nhau).

Có ba lý do tại sao các sự kiện khai báo lỗi trong EPCIS được biểu diễn theo cách này. Thứ nhất, một ID sự kiện không được yêu cầu để biểu thị sự kiện sai lỗi, điều này có nghĩa là không cần phải có một ID sự kiện cho mọi sự kiện để cung cấp cho việc khai báo lỗi có thể xảy ra trong tương lai. ID sự kiện có sẵn để liên kết sự kiện khai báo lỗi với một sự kiện khắc phục, nhưng không bao giờ cần thiết để sử dụng ID sự kiện. Thứ hai, bất kì truy vấn EPCIS nào khớp với một sự kiện cũng sẽ khớp với khai báo lỗi cho sự kiện đó, nếu nó tồn tại. Điều này có nghĩa là các ứng dụng truy cập EPCIS không yêu cầu logic đặc biệt để nhận biết các khai báo lỗi, nếu chúng tồn tại. Thứ ba, nếu một ứng dụng truy cập EPCIS nhận được một sự kiện khai báo lỗi và vì một lý do nào đó không có một bản sao của sự kiện ban đầu (sai), thì không cần phải lấy lại sự kiện ban đầu vì mọi thông tin trong sự kiện đó cũng có mặt trong sự kiện khai báo lỗi.

7.4.1.4  Khớp khai báo lỗi với sự kiện ban đầu (không bắt buộc)

Như đã thảo luận trong 7.4.1.2, một sự kiện khai báo lỗi có nội dung giống hệt với sự kiện ban đầu (sai), ngoại trừ chính thành phần ErrorDeclaration và thời gian ghi. Một trong những lợi ích của phương pháp này là khi một ứng dụng truy cập EPCIS gặp phải một khai báo lỗi, không cần thiết phải truy xuất sự kiện ban đầu (sai), vì tất cả thông tin trong sự kiện đó cũng có mặt trong sự kiện khai báo lỗi ứng dụng Truy cập EPCIS đã có.

Tuy nhiên, có thể có các tình huống trong đó một ứng dụng Truy cập EPCIS hoặc ứng dụng truy cập EPCIS mong muốn xác nhận sự tồn tại của sự kiện ban đầu (sai) bằng cách truy vấn nó. Cách duy nhất để nhận ra rằng một sự kiện là sự kiện ban đầu phù hợp với một khai báo lỗi là xác nhận rằng tất cả các phần tử dữ liệu trong các sự kiện (lưu thành phần ErrorDeclaration và thời gian ghi) phù hợp. Xem [EPCISGuideline] để biết các phương pháp được đề xuất để truy vấn trong trường hợp này.

7.4.2  ObjectEvent (phân tầng của EPCISEvent)

Một ObjectEvent truy cập thông tin về một sự kiện liên quan đến một hoặc nhiều đối tượng vật lý hoặc số hóa được xác định bởi các mã phân định cấp độ cá thể (EPC) hoặc cấp độ – tầng (tầng EPC). Hầu hết các ObjectEvents được hình dung để đại diện cho các quan sát thực tế của các đối tượng, nhưng nó có thể được sử dụng cho bất kì sự kiện nào mà ứng dụng truy cập muốn xác nhận về các đối tượng, bao gồm, ví dụ truy cập thực tế rằng một quan sát dự kiến không xảy ra.

Mặc dù có nhiều hơn một EPC và / hoặc EPC Class có thể xuất hiện trong một ObjectEvent, không có mối quan hệ hay liên kết nào giữa các đối tượng đó được ngụ ý ngoài sự trùng hợp ngẫu nhiên khi có các sự kiện giống nhau trong thế giới thực.

Trường hành động của ObjectEvent mô tả mối quan hệ của sự kiện với vòng đời của các đối tượng và mã phân định của chúng được đặt tên trong sự kiện. Đặc biệt:

Bảng 16 – Ý nghĩa của giá trị hành động của ObjectEvent

Giá trị hành động	Ý nghĩa
BỔ SUNG	Các đối tượng được xác định trong sự kiện này đã được đưa vào hoạt động như một phần của sự kiện này. Đối với các đối tượng được xác định bởi các EPC (các mã phân định mức cá thể), các EPC (s) đã được ban hành và liên kết với một đối tượng lần đầu tiên. Đối với các đối tượng được xác định bởi các tầng EPC (mã phân định cấp độ – tầng), số lượng các tầng EPC được xác định trong sự kiện đã được tạo (mặc dù các trường hợp khác cùng một tầng đó có thể tồn tại trước sự kiện này, và các trường hợp BỔ SUNG có thể được tạo sau sự kiện này).
QUAN SÁT	Sự kiện này thể hiện một quan sát đơn giản về các đối tượng được xác định trong sự kiện, chứ không phải việc đưa vào hoặc ngừng hoạt động của chúng.
HỦY BỎ	Các đối tượng được xác định trong sự kiện này đã được ngừng hoạt động như là một phần của sự kiện này. Đối với các đối tượng được xác định bởi các EPC (các mã phân định mức cá thể), các EPC (s) không tồn tại sau sự kiện và không phải quan sát lại nữa. Đối với các đối tượng được xác định bởi các tầng EPC (số phân định cấp độ-tầng), số lượng các tầng EPC được xác định trong sự kiện đã ngừng tồn tại (mặc dù các trường hợp khác cùng các tầng đó có thể tiếp tục tồn tại sau sự kiện này và các trường hợp BỔ SUNG có thể đã ngừng tồn tại trước sự kiện này).

Bảng 17 – Mô tả trường

Trường	Loại	Mô tả
eventTime recordTime eventTimeZoneOffset		(Theo EPCISEvent; xem 7.4.1)
epcList	List<EPC>	(Tùy chọn) Một danh sách không có thứ tự của một hoặc nhiều EPC đặt tên cho các đối tượng cụ thể mà sự kiện liên quan đến. Xem 7.3.3.2. ObjectEvent PHẢI chứa hoặc epclist không để trống, hoặc quantityList không để trống, hoặc cả hai.
quantityList	List<QuantityElement>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều QuantityElements phân định (ở cấp độ – tầng) các đối tượng mà sự kiện liên quan đến. ObjectEvent PHẢI chứa hoặc epclist không để trống, hoặc quantityList không để trống, hoặc cả hai.
action	Action	Sự kiện này liên quan đến vòng đời của các EPC được đặt tên trong sự kiện này như thế nào. Xem ở trên để biết thêm chi tiết.
bizStep	BusinessStepID	(Tùy chọn) Bước kinh doanh mà sự kiện này là một phần.
disposition	DispositionID	(Tùy chọn) Điều kiện kinh doanh của các đối tượng liên kết với EPC, được cho là giữ đúng cho đến khi mâu thuẫn với một sự kiện tiếp theo.
readPoint	ReadPointID	(Tùy chọn) Điểm đọc tại đó sự kiện diễn ra
bizLocation	BusinessLocationID	(Tùy chọn) Vị trí doanh nghiệp nơi các đối tượng liên kết với EPC có thể được tìm thấy, cho đến khi mâu thuẫn với một sự kiện tiếp theo.
bizTransactionList	Unordered list of zero or more BusinessTransaction instances	(Tùy chọn) Danh sách giao dịch kinh doanh không theo thứ tự xác định ngữ cảnh của sự kiện này.
sourceList	List<Source>	(Tùy chọn) Danh sách các thành phần Nguồn không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối có nguồn gốc của một chuyển giao kinh doanh mà sự kiện này là một phần.
destinationList	List<Destination>	(Tùy chọn) Danh sách các thành phần Đích không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối kết thúc của việc chuyển giao kinh doanh mà sự kiện này là một phần.
ilmd	ILMD	(Tùy chọn) Dữ liệu chủ của trường hợp / Lô (7.3.6) mô tả các đối tượng được tạo trong sự kiện này. Một ObjectEvent KHÔNG được chứa ilmd nếu Hành động là QUAN SÁT hoặc HỦY BỎ.

Lưu ý rằng trong liên kết XML (9.3), quantityList, sourceList, destinationList và ilmd xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích về trong tương lai với EPCIS 1.0.

Ngữ nghĩa trong quá khứ

– Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra đối với các đối tượng được xác định bởi epcList và quantityList tại eventTime tại vị trí readPoint.

– (Nếu hành động là BỔ SUNG) Các EPC trong epcList được ủy nhiệm (ban hành lần đầu tiên).

– (Nếu hành động là BỔ SUNG) Số lượng quy định của các trường hợp EPC Class trong quantityList được tạo ra (hoặc một số lượng chưa biết, cho mỗi QuantityElement trong đó bỏ qua giá trị đại lượng được).

– (Nếu hành động là HỦY BỎ) Các EPC trong epcList đã được ngừng hoạt động (đã ngừng hoạt động sau này).

– (Nếu hành động là HỦY BỎ) Số lượng quy định của các trường hợp EPC Class trong quantityList không còn tồn tại (hoặc một số lượng chưa biết, cho mỗi QuantityElement trong đó giá trị số lượng bị bỏ qua).

– (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được chỉ định) Một hiệp hội tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và các đối tượng được xác định trong epcList và quantityList.

– (Nếu hành động là QUAN SÁT và một bizTransactionList không trống được chỉ định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu hành động là HỦY BỎ và một bizTransactionList không trống được chỉ định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

– (Nếu danh sách đích không trống) Sự kiện này diễn ra trong ngữ cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa kì vọng:

– (Nếu hành động là BỔ SUNG) Các đối tượng được phân định bởi các mã phân định mức – cá thể trong epcList có thể xuất hiện trong các sự kiện tiếp theo.

– (Nếu hành động là BỔ SUNG) Các đối tượng được phân định bởi các mã phân định cấp độ – tầng trong quantityList có thể xuất hiện trong các sự kiện tiếp theo.

– (Nếu hành động là HỦY BỎ) Các đối tượng được phân định bởi các mã phân định mức – cá thể trong epcList sẽ không xuất hiện trong các sự kiện tiếp theo.

– (Nếu hành động là HỦY BỎ) Tổng số các đối tượng được phân định bởi các mã phân định mức – tầng trong quantityList có thể xuất hiện trong các sự kiện tiếp theo đã được giảm theo số lượng được quy định trong quantityList (hoặc bởi một đại lượng chưa biết, cho mỗi QuantityElement giá trị bị bỏ qua).

– (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng được phản định bởi epcList và quantityList được mô tả bằng cách sắp xếp.

– (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết được phân định bởi epcList và quantity List không thay đổi.

– (Nếu bizLocation được quy định) Các đối tượng được phân định bởi epcList và quantityList đang ở vị trí kinh doanh bizLocation.

– (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng được phân định bởi epcList và quantityList không xác định.

– (Nếu hành động là BỔ SUNG và ilmd không trống) Các đối tượng được phân định bởi epcList và quantityList được mô tả bởi các thuộc tính trong ilmd.

– (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một sự kết hợp tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và các đối tượng được phân định trong epListListand quantity List.

Không bắt buộc: Giải thích: Trong trường hợp hành động là BỔ SUNG và một bizTransactionList không trống được quy định, hiệu ứng ngữ nghĩa tương đương với việc có một ObjectEvent không có bizTransactionList cùng với một ransactionEvent có bizTransactionList và tất cả các giá trị trường giống như ObjectEvenf. Tuy nhiên, lưu ý rằng một ObjectEvent với một bizTransactionList không trống không gây ra một TransactionEvent được trả về từ một truy vấn.

7.4.3  AggregationEvent (tầng con của EPCISEvent)

Loại sự kiện AggregationEvent mô tả các sự kiện áp dụng cho các đối tượng đã được tổ hợp với nhau. Trong một sự kiện như vậy, có một tập hợp các đối tượng “chứa” đã được tổ hợp trong thực thể “chứa” có nghĩa là để phân định tổ hợp chính nó.

Loại sự kiện này được dự định sẽ sử dụng để “tổ hợp”, nghĩa là một liên kết có mối quan hệ vật lý mạnh mẽ giữa các đối tượng chứa và thực thể chứa các đối tượng đó, tất cả chúng sẽ chiếm cùng một vị trí, cùng một lúc, cho đến khi chúng phân tách. Một ví dụ về một tổ hợp là nơi các trường hợp được nạp vào một pallet và được thực hiện như một đơn vị. Loại AggregationEvent không dành cho các liên kết yếu hơn như hai pallet là một phần của cùng một lô hàng, nhưng các pallet có thể không luôn ở đúng vị trí giống nhau tại cùng một thời điểm. (TransactionEvent có thể thích hợp cho các trường hợp như vậy.) Ngữ nghĩa cụ thể hơn có thể được quy định tùy thuộc vào Bước kinh doanh.

Trường hành động của một AggregationEvent mô tả mối quan hệ của sự kiện với vòng đời của tổ hợp.

Bảng 18 – Ý nghĩa của giá trị hành động của AggregationEvent

Giá trị hành động	Ý nghĩa
BỔ SUNG	Các đối tượng được phân định trong danh sách con được tổ hợp cho cha mẹ trong sự kiện này. Điều này bao gồm các tình huống trong đó tổ hợp được tạo lần đầu tiên, cũng như khi những đứa con mới được bổ sung vào tổ hợp hiện có.
QUAN SÁT	Sự kiện này không đại diện cho việc bổ sung và loại bỏ đứa con khỏi tổ hợp. Quan sát có thể không đầy đủ: có thể có đứa con là một phần của tổ hợp nhưng không được quan sát thấy trong sự kiện này và do đó không được đưa vào trường ChildEPC hoặc childQuantityList của AggregationEvent; tương tự như vậy, việc phân định cha mẹ có thể không được quan sát hoặc biết đến trong sự kiện này và do đó trường parentID được bỏ qua khỏi AggregationEvent.
LOẠI BỎ	Các đối tượng được phân định trong danh sách những đứa con đã được phân tách khỏi cha mẹ trong sự kiện này. Điều này bao gồm các tình huống mà một tổ hợp những đứa con được loại bỏ khỏi tổ hợp, cũng như khi toàn bộ tổ hợp được tháo dỡ. Cả hai childEPC và trường childQuantityList có thể được bỏ qua khỏi AggregationEvent, có nghĩa là tất cả những đứa con đã được phân tách. (Điều này cho phép phân tách khi phần mềm truy cập sự kiện không biết sự phân định của tất cả những con.)

Kiểu AggregationEventEvent bao gồm các trường tham chiếu đến một “cha mẹ” đơn (thường là thực thể “chứa”) và một hoặc nhiều “đứa con” (thường là các đối tượng “chứa”). Yêu cầu mã phân định cha mẹ khi hành động là BỔ SUNG hoặc LOẠI BỎ, nhưng tùy chọn khi hành động là QUAN SÁT.

Không bắt buộc: Giải thích: Mã phân định cha mẹ được sử dụng khi hành động là BỔ SUNG để có cách đề cập đến liên kết trong các sự kiện tiếp theo khi hành động bị LOẠI BỎ. Mã phân định cha mẹ là tùy chọn khi hành động là QUAN SÁT vì cha mẹ không phải lúc nào cũng được biết trong quá trình quan sát trung gian. Ví dụ, một quá trình nhận pallet có thể dựa vào các thẻ RFID để xác định EPC của các trường hợp trên pallet, nhưng có thể không có thẻ RFID cho pallet (hoặc nếu có, nó có thể không đọc được).

AggregationEvent được dự định để chỉ ra tổ hợp giữa các đối tượng, và do đó các đứa con được phân định bởi các tầng EPC và / hoặc EPC. Tuy nhiên, thực thể cha mẹ không nhất thiết là một đối tượng vật lý hoặc số hóa tách biệt với bản thân tổ hợp và do đó cha mẹ được xác định bởi một URI tùy ý, có thể là EPC, nhưng CÓ THỂ là một mã phân định khác được rút ra từ một từ vựng riêng phù hợp.

Không bắt buộc: Giải thích: Trong nhiều hoạt động sản xuất, ví dụ, thông thường khi tạo một tải một vài bước trước EPC để giao tải. Trong những tình huống như vậy, mã số theo dõi nội bộ (thường được gọi là “mã số tấm giấy phép” hoặc LPN) được thừa nhận tại thời điểm tải được tạo và điều này được sử dụng cho đến điểm giao hàng. Tại điểm giao hàng, mã SSCC (là một EPC) được thừa nhận. Trong EPCIS, điều này sẽ được mô hình hóa bởi (a) một AggregateEvent có hành động như là BỔ SUNG tại thời điểm tải được tạo ra, và (b) một AggregationEvent thứ hai với hành động như là BỔ SUNG tại thời điểm SSCC được thừa nhận (liên kết đầu tiên cũng có thể bị vô hiệu hóa thông qua một AggregationEvent với hành động như là LOẠI BỎ tại thời điểm này). AggregationEvent đầu tiên sẽ sử dụng LPN làm mã phân định cha mẹ (được thể hiện bằng cách mô tả URI phù hợp; xem 6.4), trong khi đó AggregationEvent thứ hai sẽ sử dụng SSCC (một loại EPC) làm mã phân định cha mẹ, bằng cách thay đổi parentID.

Bảng 19 – Các trường của AggregationEvent

Trường	Loại	Mô tả
eventTime recordTime eventTimeZoneOffset	(Thừa kế từ EPCISEvent; xem 7.4.1)
parentID	URI	(Tùy chọn khi hành động là QUAN SÁT, nếu không có yêu cầu nào khác) Mã phân định cha mẹ của liên kết. Khi mã phân định cha mẹ là EPC, trường này PHẢI chứa URI “thuần khiết” cho EPC như được quy định trong [TDS1.9], Điều 7
childEPCs	List<EPC>	(Tùy chọn) Một danh sách không theo thứ tự các EPC của các đối tượng chứa được xác định bởi mã phân định mức độ – cá thể. Xem 7.3.3.2.
		Một AggregationEvent PHẢI chứa một childEPC không rỗng, một childQuantityList không rỗng, hoặc cả hai, ngoại trừ cả childEPC và childQuantityList CÓ thể rỗng nếu hành động là LOẠI BỎ, chỉ ra rằng tất cả các đứa con đều được phân tách khỏi cha mẹ.
childQuantityList	List<QuantityElement>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều QuantityElements phân định (ở mức tầng) chứa các đối tượng. Xem 7.3.3.2. Một AggregationEvent PHẢI chứa một childEPC không rỗng, một childQuantityList không rỗng, hoặc cả hai, ngoại trừ cả childEPC và childQuantityList có thể rỗng nếu hành động là LOẠI BỎ, chỉ ra rằng tất cả các đứa con đều được phân tách khỏi cha mẹ.
action	Action	Mức độ sự kiện này liên quan đến vòng đời của tổ hợp được đặt tên trong sự kiện này. Xem ở trên để biết thêm chi tiết.
bizStep	BusinessStepID	(Tùy chọn) Bước kinh doanh mà sự kiện này là một phần.
disposition	DispositionID	(Tùy chọn) Điều kiện kinh doanh của các đối tượng liên kết với EPC, được cho là giữ đúng cho đến khi mâu thuẫn với một sự kiện tiếp theo.
readPoint	ReadPointID	(Tùy chọn) Điểm đọc tại đó sự kiện diễn ra.
bizLocation	BusinessLocationID	(Tùy chọn) Vị trí kinh doanh nơi có thể tìm thấy các đối tượng liên kết với các EPC chứa và để chứa, cho đến khi mâu thuẫn với một sự kiện tiếp theo.
bizTransactionList	Unordered list of zero or more BusinessTransaction instances	(Tùy chọn) Danh sách giao dịch kinh doanh không theo thứ tự xác định bối cảnh của sự kiện này.
sourceList	List<Source>	(Tùy chọn) Danh sách các thành phần Nguồn không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối có nguồn gốc của một chuyển giao kinh doanh mà sự kiện này là một phần.
destinationList	List<Destination>	(Tùy chọn) Một danh sách các thành phần đích không theo thứ tự (7.3.5.4) cung cấp bối cảnh về endpoint đích của việc chuyển giao kinh doanh mà sự kiện này là một phần.

Lưu ý rằng trong liên kết XML (9.3), childQuantityList, sourceList và destinationList xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích trong tương lai với EPCIS 1.0.

Ngữ nghĩa hồi tưởng:

– Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra liên quan đến việc chứa thực thể parentID và các đối tượng chứa trong childEPCs và childQuantityList, tại eventTime và location readPoint.

– (Nếu hành động là BỔ SUNG) Các đối tượng được phân định trong childEPC và childQuantityList được tổ hợp với parentID của thực thể chứa.

– (Nếu hành động là LOẠI BỎ và childEPC hoặc childQuantityList không trống) Các đối tượng được phân định trong childEPC và childQuantityList được phân tách khỏi parentID.

– (Nếu hành động là LOẠI BỎ và cả childEPC và childQuantityList đều trống) Tất cả các đối tượng chứa được phân tách khỏi parentID của thực thể chứa.

– (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng được phân định trong childEPC và childQuantityList, và parentID của thực thể chứa.

– (Nếu hành động là QUAN SÁT và một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu hành động là LOẠI BỎ và một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

– (Nếu destinationList không trống) Sự kiện này diễn ra trong bối cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn cảnh:

– (Nếu hành động là BỔ SUNG) Một tổ hợp tồn tại giữa parentID của thực thể chứa và các đối tượng được chứa trong childEPCs và childQuantityList.

– (Nếu hành động là LOẠI BỎ và childEPC hoặc childQuantityList không trống) Một tổ hợp không còn tồn tại giữa parentID của thực thể chứa và các đối tượng được chứa được xác định trong childEPCs và childQuantityList.

– (Nếu hành động là LOẠI BỎ và cả childEPC và childQuantityList đều trống) Một tổ hợp không còn tồn tại giữa parentID của thực thể chứa và bất kì đối tượng được chứa nào.

– (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng được phân định trong parentID, childEPC và childQuantityList được mô tả bằng cách bố trí.

– (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList không thay đổi.

– (Nếu bizLocation được quy định) Các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList đang ở bizLocation của vị trí kinh doanh.

– (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList không xác định.

(Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một sự liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong childEPCs và childQuantityList và parentID của thực thể chứa (nếu được quy định).

Không quy định: Giải thích: Trong trường hợp hành động là BỔ SUNG và một bizTransactionList không rỗng được quy định, hiệu ứng ngữ nghĩa tương đương với việc có một AggregationEvent không có bizTransactionList cùng với một TransactionEvent có bizTransactionList và tất cả các giá trị trường giống như AggregationEvent. Tuy nhiên, lưu ý rằng một AggregationEvent với một bizTransactionList không rỗng không gây ra TransactionEvent được trả về từ một truy vấn.

Không quy định: Lưu ý: Nhiều tình huống ngữ nghĩa không hợp lệ có thể được thể hiện bằng cách sử dụng không đúng tổ hợp. Ví dụ, các đối tượng tương tự có thể được cung cấp cho nhiều cha mẹ trong cùng một khoảng thời gian bởi các hoạt động BỔ SUNG riêng biệt mà không có sự loại bỏ xen kẽ. Tương tự như vậy một đối tượng có thể được xác định là một đứa con của ông bà hoặc thậm chí của chính nó. Một tổ hợp không tồn tại có thể bị LOẠI BỎ. Các tình huống này không thể được phát hiện về mặt cú pháp và nói chung một kho lưu trữ EPCIS riêng lẻ có thể không có đủ thông tin để phát hiện chúng. Do đó, tiêu chuẩn này không đưa ra các điều kiện lỗi này.

7.4.4  QuantityEvent (phân tầng của EPCISEvent) – KHÔNG DÙNG

Một QuantityEvent truy cập sự kiện diễn ra liên quan đến một số lượng quy định của một tầng đối tượng. Loại sự kiện này có thể được sử dụng, ví dụ, để báo cáo mức tồn kho của sản phẩm.

Kể từ EPCIS 1.1, QuantityEvent không được chấp nhận. Thay vào đó, các ứng dụng sử dụng một ObjectEvent có chứa một hoặc nhiều QuantityListElements. Một QuantityEvent tương đương với một ObjectEvent có chứa một EPCList rỗng và một QuantityListElement duy nhất chứa một số lượng và không có uom.

Bảng 20 – Các trường trong phần tử QuantityEvent

Trường	Loại	Mô tả
eventTime recordTime eventTimeZoneOffset		(Kế thừa EPCISEvent; xem 7.4.1)
epcClass	EPCCIass	Mã phân định quy định tầng đối tượng mà sự kiện liên quan đến.
quantity	Int	Số lượng đối tượng trong tầng được mô tả bởi sự kiện này.
bizStep	BusinessStepID	(Tùy chọn) Bước kinh doanh mà sự kiện này là một phần.
disposition	DispositionID	(Tùy chọn) Điều kiện kinh doanh của các đối tượng liên kết với EPC, được cho là giữ đúng cho đến khi mâu thuẫn với một sự kiện tiếp theo.
readPoint	ReadPointID	(Tùy chọn) Điểm đọc tại đó sự kiện diễn ra.
bizLocation	BusinessLocationID	(Tùy chọn) Địa điểm kinh doanh nơi các đối tượng có thể được tìm thấy, cho đến khi mâu thuẫn với một sự kiện tiếp theo.
bizTransactionList	Unordered list of zero or more BusinessTransaction instances	(Tùy chọn) Danh sách giao dịch kinh doanh không theo thứ tự xác định bối cảnh của sự kiện này.

Lưu ý rằng bởi vì EPCCIass luôn biểu thị đơn vị đóng gói cụ thể (ví dụ: trường hợp 12 thương phẩm), không cần trường “đơn vị đo lường” rõ ràng. Đơn vị đo luôn là tầng đối tượng được biểu thị bằng epcClass như được định nghĩa trong dữ liệu chính cho tầng đối tượng đó.

Ngữ nghĩa hồi tưởng

– Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra liên quan đến đối tượng về số lượng của tầng EPC epcClass tại eventTime tại vị trí readPoint.

– (Nếu một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

Ngữ nghĩa viễn cảnh:

– (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng được mô tả bởi bố trí.

– (Nếu bố trí bị bỏ qua) Tình trạng kinh doanh của các đối tượng không thay đổi.

– (Nếu bizLocation được quy định) Các đối tượng đang ở vị trí kinh doanh bizLocation.

– (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng không xác định.

7.4.5  TransactionEvent (phân tầng của EPCISEvent)

Loại sự kiện TransactionEvent mô tả sự kết hợp hoặc phân tách các đối tượng vật lý hoặc số hóa cho một hoặc nhiều giao dịch kinh doanh. Mặc dù các loại sự kiện khác có trường bizTransactionList tùy chọn có thể được sử dụng để cung cấp bối cảnh cho một sự kiện, TransactionEvent được sử dụng để khai báo một cách rõ ràng rằng các đối tượng nhất định đã được liên kết hoặc hủy liên kết với một hoặc nhiều giao dịch kinh doanh là một phần của sự kiện.

Trường hành động của TransactionEvent mô tả mối quan hệ của sự kiện với vòng đời của giao dịch.

Bảng 21 – Ý nghĩa của giá trị hành động của TransactionEvent

Giá trị hành động	Ý nghĩa
BỔ SUNG	Các đối tượng được quy định trong sự kiện này có liên quan đến (các) giao dịch kinh doanh trong sự kiện này. Điều này bao gồm các tình huống mà (các) giao dịch được tạo lần đầu tiên, cũng như khi các đối tượng mới được BỔ SUNG vào (các) giao dịch hiện tại.
QUAN SÁT	Các đối tượng có tên trong sự kiện đã được xác nhận là tiếp tục liên kết với (các) giao dịch kinh doanh trong sự kiện này. Giải thích (không bắt buộc): Một TransactionEvent với hành động QUAN SÁT khá giống với một ObjectEvent bao gồm một trường bizTransactionList không rỗng. Khi một nhóm người dùng cuối đồng ý sử dụng cả hai loại sự kiện, nhóm nên xác định rõ ràng khi nào nên sử dụng. Ví dụ trong trường hợp TransactionEvent có hành động QUAN SÁT có thể thích hợp là lô hàng quốc tế có ID giao dịch xxx di chuyển qua cổng và có mong muốn ghi lại các EPC được quan sát tại thời điểm đó trong việc xử lý giao dịch đó. Các truy vấn tiếp theo sẽ tập trung vào truy vấn ID giao dịch để tìm các EPC, chứ không phải trên các EPC để tìm ID giao dịch.
LOẠI BỎ	Các đối tượng có tên trong sự kiện đã bị hủy liên kết khỏi (các) giao dịch kinh doanh trong sự kiện này. Điều này bao gồm các tình huống mà một tập hợp con của các đối tượng bị hủy liên kết khỏi (các) giao dịch kinh doanh cũng như khi toàn bộ (các) giao dịch kinh doanh đã kết thúc. Để thuận tiện, cả danh sách EPC và QuantityElements có thể được bỏ qua khỏi TransactionEvent, điều đó có nghĩa là tất cả các đối tượng đã bị hủy liên kết.

Bảng 22 – Các trường của TransactionEvent

Trường	Loại	Mô tả
eventTime recordTime eventTimeZoneOffset	(Kế thừa EPCISEvent; xem 7.4.1)
bizTransactionList	Danh sách không có thứ tự của một hoặc nhiều trường hợp giao dịch kinh doanh	(Các) giao dịch kinh doanh.
parentID	URI	(Tùy chọn) Mã phân định của cha mẹ các đối tượng được đưa ra trong epcList và quantityList. Khi mã phân định của cha mẹ là một EPC, trường này PHẢI chứa URI “thuần khiết” cho EPC như được quy định trong [TDS1.9], điều 7. Xem thêm ghi chú sau bảng.
epcList	List<EPC>	(Tùy chọn) Một danh sách không theo thứ tự các EPC của các đối tượng được quy định bởi các mã phân định mức cá thể được kết hợp với giao dịch kinh doanh. Xem 7.3.3.2. TransactionEvent PHẢI chứa một epcList không trống, một số lượng không rỗng, hoặc cả hai, ngoại trừ cả hai epcList và quantityList CÓ THỂ trống nếu hành động là LOẠI BỎ, chỉ ra rằng tất cả các đối tượng được tách ra khỏi (các) giao dịch kinh doanh.
quantityList	List<QuantityElement>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều đối tượng phân định QuantityElements (ở cấp độ tầng) mà sự kiện liên quan đến. TransactionEvent PHẢI chứa một epcList không trống, một số lượng không rỗng, hoặc cả hai, ngoại trừ cả hai epcList và quantityList CÓ THỂ trống nếu hành động là LOẠI BỎ, chỉ ra rằng tất cả các đối tượng được tách ra khỏi (các) giao dịch kinh doanh.
action	Action	Sự kiện này liên quan đến vòng đời của giao dịch kinh doanh có tên trong sự kiện này như thế nào. Xem ở trên để biết thêm chi tiết.
bizStep	BusinessStepID	(Tùy chọn) Bước kinh doanh mà sự kiện này là một phần.
disposition	DispositionID	(Tùy chọn) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng, được cho là giữ đúng cho đến khi mâu thuẫn với một sự kiện tiếp theo.
readPoint	ReadPointID	(Tùy chọn) Điểm đọc tại đó sự kiện diễn ra.
bizLocation	BusinessLocationID	(Tùy chọn) Vị trí kinh doanh nơi các đối tượng liên kết với các đối tượng chứa và được chứa có thể được tìm thấy, cho đến khi mâu thuẫn với một sự kiện tiếp theo.
sourceList	List<Source>	(Tùy chọn) Danh sách các thành phần Nguồn không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối có nguồn gốc của một chuyển giao kinh doanh mà sự kiện này là một phần.
destinationList	List<Destination>	(Tùy chọn) Một danh sách các phần tử Đích không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối kết thúc của việc chuyển giao kinh doanh mà sự kiện này là một phần.

Lưu ý rằng trong liên kết XML (9.3), quantityList, sourceList và destinationList

xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích sau này với EPCIS 1.0.

Không bắt buộc: Giải thích: Việc sử dụng tên trường parentID trong cả TransactionEvent và AggregationEvent (7.2.10) không biểu thị sự giống nhau về chức năng hoặc ngữ nghĩa. Nói chung, một TransactionEvent mang cùng một thông tin phân định đối tượng như một ObjectEvent, đó là một danh sách các EPC và / hoặc QuantityElements. Tất cả các trường thông tin khác (bizTransactionList, bizStep, bizLocation, vv) áp dụng như nhau và thống nhất cho tất cả các đối tượng được quy định có hay không các đối tượng được quy định trong trường epcList và quantitylist hoặc nếu trường parentID tùy chọn cũng được cung cấp.

Không bắt buộc: TransactionEvent cung cấp cách thức mô tả sự liên kết hoặc phân tách các giao dịch kinh doanh với các đối tượng. Trường parentID trong TransactionEvent làm rõ một EPC cụ thể hoặc mã phân định khác như là đối tượng ưu tiên hoặc ban đầu nhưng không hàm ý mối quan hệ vật lý của bất kì loại nào, cũng như bất kì huyết thống hoặc thế hệ nào được ngụ ý bởi chính TransactionEvent. Chỉ các cá thể AggregationEvent mô tả các mối quan hệ cha-con thực sự và các mối quan hệ cha-con có huyết thống. Điều này có thể được thấy bằng cách so sánh ngữ nghĩa của AggregationEvent trong 7.2.10 với ngữ nghĩa của TransactionEvent dưới đây.

Ngữ nghĩa hồi tưởng

– Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) diễn ra liên quan đến các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định), tại eventTime và readPoint vị trí.

– (Nếu hành động là BỔ SUNG) Các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) được liên kết với các giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu hành động là LOẠI BỎ và epcList hoặc quantityList không trống) Các đối tượng trong epcList, quantityList, và parentID thực thể chứa (nếu có quy định) đã bị hủy liên kết khỏi các giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu hành động là LOẠI BỎ, cả hai epcList và quantityList đều trống, và parentID bị bỏ qua) Tất cả các đối tượng đã bị hủy liên kết khỏi các giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

– (Nếu danh sách đích không trống) Sự kiện này diễn ra trong bối cảnh cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn cảnh:/kì vọng.

– (Nếu hành động là BỔ SUNG) Một liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định).

– (Nếu hành động là LOẠI BỎ và epcList hoặc quantityList không trống) Một liên kết không còn tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định).

– (Nếu hành động là LOẠI BỎ, cả epcList và quantity List đều trống, và parentID bị bỏ qua) Một liên kết không còn tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và bất kì đối tượng nào.

– (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) được mô tả theo bố trí.

– (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) là không thay đổi.

– (Nếu bizLocation được quy định) Các đối tượng liên kết với các đối tượng trong epcList, quantityList, và chứa parentID thực thể chứa (nếu có quy định) đang ở bizLocation vị trí kinh doanh.

– (Nếu bizLocation bị bỏ qua) Vị trí doanh nghiệp của các đối tượng liên kết với các đối tượng trong epcList và quantityList và chứa thực thể parentID (nếu có quy định) là không xác định.

7.4.6  TransformationEvent (phân tầng của EPCISEvent)

Một TransformationEvent truy cập thông tin về một sự kiện trong đó một hoặc nhiều đối tượng vật lý hoặc số hóa được quy định bởi các mã phân định cấp độ-cá thể (EPC) hoặc cấp độ- tầng (EPC Class) được tiêu thụ toàn bộ hoặc một phần như đầu vào và một hoặc nhiều đối tượng được phân định bởi mã phân định cấp độ-cá thể (EPC) hoặc cấp độ – tầng (EPC Class) được tạo thành đầu ra. TranstormationEvent truy cập mối quan hệ giữa các đầu vào và đầu ra, sao cho bất kì đầu vào nào có thể đã đóng góp theo một cách nào đó cho mỗi đầu ra.

Một số quá trình chuyển đổi kinh doanh diễn ra trong một thời gian dài, và do đó, nó phù hợp hơn để đại diện cho chúng như một loạt các sự kiện EPCIS. Một TransfomationID có thể được bao gồm trong hai hoặc nhiều TransformationEvents để liên kết chúng lại với nhau. Khi các sự kiện chia sẻ một TranstormationID giống hệt nhau, ý nghĩa là các đầu vào cho bất kì sự kiện nào trong số những sự kiện đó có thể đã đóng góp theo một cách nào đó cho mỗi đầu ra trong bất kì sự kiện tương tự nào.

Bảng 23 – Các trường của TransformationEvent

Trường	Loại	Mô tả
eventTime recordTime eventTimeZoneOffset	(Kế thừa kế từ EPCISEvent; xem 7.4.1)
inputEPCList	List<EPC>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều đối tượng EPC phân định (ở cấp độ cá thể) là các đầu vào của chuyển đổi. Xem 7.3.3.2. Xem bên dưới để biết các ràng buộc khi inputEPCList có thể bị bỏ qua.
inputQuantityList	List<QuantityElement>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều đối tượng QuantityElements phân định (ở cấp độ- tầng) là các đầu vào của chuyển đổi. Xem bên dưới để biết các ràng buộc khi inputQuantityList có thể bị bỏ qua.
outputEPCList	List<EPC>	(Tùy chọn) Một danh sách không có thứ tự của một hoặc nhiều đối tượng đặt tên EPC (ở cấp độ- cá thể) là đầu ra của chuyển đổi. Xem 7.3.3.2. Xem bên dưới để biết các ràng buộc khi outputEPCList có thể bị bỏ qua.
outputQuantityList	List<QuantityElement>	(Tùy chọn) Một danh sách không theo thứ tự của một hoặc nhiều đối tượng QuantityElements phân định (ở cấp độ- tầng) là đầu ra của chuyển đổi. Xem bên dưới để biết các ràng buộc khi outputQuantityList có thể bị bỏ qua.
transformationID	TransformationID	(Tùy chọn) Mã phân định duy nhất liên kết sự kiện này với các TransformationEvents khác có giá trị giống hệt nhau của conversionID. Khi được quy định, tất cả các yếu tố đầu vào cho tất cả các sự kiện chia sẻ cùng một giá trị của conversionID có thể đóng góp cho tất cả đầu ra của tất cả sự kiện chia sẻ giá trị của conversionID đó. Nếu TransformationID bị bỏ qua, thì đầu vào của sự kiện này có thể đóng góp vào đầu ra của sự kiện này, nhưng đầu vào và đầu ra của các sự kiện khác không được kết nối với sự kiện này.
bizStep	BusinessStepID	(Tùy chọn) Bước kinh doanh mà sự kiện này là một phần.
disposition	DispositionID	(Tùy chọn) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng đầu ra, được cho là giữ đúng cho đến khi mâu thuẫn với một sự kiện tiếp theo.
readPoint	ReadPointID	(Tùy chọn) Điểm đọc tại đó sự kiện diễn ra.
bizLocation	BusinessLocationID	(Tùy chọn) Vị trí kinh doanh nơi các đối tượng đầu ra của sự kiện này có thể được tìm thấy, cho đến khi mâu thuẫn với một sự kiện tiếp theo.
bizTransactionList	Danh sách không theo thứ tự từ zero hoặc nhiều hơn các trường hợp BusinessTransaction	(Tùy chọn) Danh sách giao dịch kinh doanh không theo thứ tự xác định bối cảnh của sự kiện này.
sourceList	List<Source>	(Tùy chọn) Danh sách các thành phần Nguồn không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối có nguồn gốc của một chuyển giao kinh doanh mà sự kiện này là một phần.
destinationList	List<Destination>	(Tùy chọn) Một danh sách các thành phần Đích không theo thứ tự (7.3.5.4) cung cấp bối cảnh về điểm cuối kết thúc của việc chuyển giao kinh doanh mà sự kiện này là một phần.
ilmd	ILMD	(Tùy chọn) Dữ liệu chủ cá thể / Lô (7.3.6) mô tả các đối tượng đầu ra được tạo ra trong sự kiện này.

Nếu conversionID bị bỏ qua, thì một TransformationEvent PHẢI gồm ít nhất một đầu vào (tức là, ít nhất một inputEPCList và inputQuantityList không rỗng) VÀ ít nhất một đầu ra (tức là, ít nhất một outputEPCList và outputQuantityList không rỗng). Nếu kể cả transformationID, thì một TranstormationEvent PHẢI bao gồm ít nhất một đầu vào HOẶC ít nhất một đầu ra (hoặc cả hai). Vế sau cung cấp khả năng về sự chuyển đổi được mô tả bởi một số sự kiện liên kết bởi một transformationID chung, bất kì một sự kiện nào cũng chỉ có thể BỔ SUNG cho đầu vào hoặc trích xuất khỏi đầu ra.

Ngữ nghĩa hồi tưởng:

– Một chuyển đổi được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra với các đối tượng đầu vào được phân định bởi inputEPCList và inputQuantityList và các đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList, tại eventTime tại vị trí readPoint.

– Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

– (Nếu transformationID bị bỏ qua ) Bất kì đối tượng đầu vào nào được phân định bởi inputEPCList và inputQuantityList của sự kiện này có thể đã đóng góp cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của sự kiện này.

– (Nếu bao gồm cả transformationID) Bất kì đối tượng đầu vào nào được phân định bởi inputEPCList và inputQuantityList của sự kiện này, cùng với các đối tượng đầu vào được phân định bởi inputEPCList và inputQuantityList của các sự kiện khác có cùng giá trị transformationID, có thể đã đóng góp cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của sự kiện này, cũng như cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của các sự kiện khác có cùng giá trị trasformationID.

– (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

– (Nếu danh sách đích không trống) Sự kiện này diễn ra trong bối cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn tưởng/kì vọng:

– Các đối tượng được phân định bởi các mã phân định mức- cá thể trong outputEPCList có thể xuất hiện trong các sự kiện tiếp theo.

– Các đối tượng được phân định bởi các mã phân định cấp độ-mức trong outputQuantityList có thể xuất hiện trong các sự kiện tiếp theo.

– (Nếu disposition được quy định) Điều kiện kinh doanh của các đối tượng được phân định bởi outputEPCList và outputQuantityList được mô tả bởi disposition.

– (Nếu disposition bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết được phân định bởi outputEPCList và outputQuantityList không xác định.

– (Nếu bizLocation được quy định) Các đối tượng được phân định bởi outputEPCList và outputQuantityList đang ở bizLocation vị trí kinh doanh.

– (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng được phân định bởi outputEPCList và outputQuantityList không xác định.

– (Nếu ilmd không trống) Các đối tượng được phân định bởi outputEPCList và outputQuantityList được mô tả bởi các thuộc tính trong ilmd.

8  Tầng dịch vụ

Điều này bao gồm các quy định kĩ thuật tiêu chuẩn của các mô-đun trong tầng dịch vụ. Đồng thời, các mô-đun này xác định ba giao diện: Giao diện truy vấn EPCIS, Giao diện kiểm soát truy vấn EPCIS và Giao diện gọi lại truy vấn EPCIS. (Hai giao diện sau được gọi chung là Giao diện Truy vấn EPCIS.) Sơ đồ dưới đây minh họa mối quan hệ giữa các giao diện này, mở rộng theo sơ đồ trong điều 2 (sơ đồ này là không bắt buộc):

Hình 8 – Mối quan hệ giữa các giao diện

Dưới đây, các dịch vụ được quy định định bằng cách sử dụng Kí hiệu sơ đồ tầng UML Các sơ đồ tầng UML được sử dụng cho mục đích này có thể chứa các giao diện có các hoạt động, chứ không phải các trường hoặc các liên kết.

VÍ DỤ Biểu đồ định nghĩa dịch vụ cho Service 1

Biểu đồ này cho thấy một định nghĩa dịch vụ cho Service1, cung cấp ba hoạt động. Operation1 lấy hai đối số, arg11 và arg12, có các kiểu ArgType11 và ArgType12, tương ứng, và trả về một giá trị kiểu ReturnType1. Operation2 lấy một đối số nhưng không trả lại kết quả. Operations không nhận bất kì đối số nào nhưng trả về một giá trị kiểu ReturnType3.

Trong các mô tả UML, Kí hiệu << điểm mở rộng >> phân định một nơi mà các triển khai PHẢI cung cấp khả năng mở rộng thông qua việc bổ sung các hoạt động mới.

Cơ chế mở rộng PHẢI cung cấp cho cả hai phần mở rộng được ủy quyền bởi các nhà cung cấp các sản phẩm tuân thủ EPCIS và các phần mở rộng do GS1 quy định thông qua các phiên bản tương lai của tiêu chuẩn này hoặc thông qua các quy định kĩ thuật mới.

Trong trường hợp các ràng buộc WSDL tiêu chuẩn, các điểm mở rộng được thực hiện đơn giản bằng cách cho phép bổ sung các hoạt động bổ sung.

8.1  Mô đun hoạt động chụp lõi

Môđune hoạt động Capture Core cung cấp các hoạt động mà các sự kiện cốt lõi có thể được gửi từ một ứng dụng Capture EPCIS. Trong phần này, từ “khách hàng” đề cập đến một ứng dụng truy cập EPCIS và “dịch vụ EPCIS” đề cập đến một hệ thống triển khai giao diện truy vấn EPCIS.

8.1.1  Xác nhận và ủy quyền

Một số ràng buộc của Giao diện truy vấn EPCIS cung cấp phương tiện, đối với Dịch vụ EPCIS để xác nhận số phân định của khách hàng, đối với khách hàng để xác nhận số phân định của Dịch vụ EPCIS hoặc cả hai. Quy định kĩ thuật của các phương tiện để xác nhận được cho trong quy định kĩ thuật của từng ràng buộc. Nếu Dịch vụ EPCIS xác nhận số phân định của khách hàng, việc thực hiện CÓ THỂ sử dụng số phân định khách hàng để đưa ra các quyết định ủy quyền như được mô tả bên dưới. Hơn nữa, việc thực hiện CÓ THỂ ghi lại số phân định khách hàng với dữ liệu đã thu thập, để sử dụng trong các quyết định ủy quyền tiếp theo nhờ hệ thống thực hiện các Giao diện Truy vấn EPCIS, như được mô tả trong 8.2.2.

Do sự đơn giản của Giao diện truy vấn EPGIS, các điều khoản ủy quyền rất đơn giản để nêu rõ: cụ thể là, một triển khai có THỂ sử dụng số phân định khách hàng đã được xác nhận để quyết định liệu hoạt động truy cập có được phép hay không.

Không bắt buộc: Giải thích: Các đối tác thương mại sẽ luôn sử dụng các ràng buộc cung cấp xác nhận số phân định khách hàng hoặc xác nhận lẫn nhau khi sử dụng các giao diện EPCIS để chia sẻ dữ liệu qua các ranh giới của tổ chức. Các ràng buộc không cung cấp xác nhận được dự kiến sẽ chỉ được sử dụng trong một tổ chức duy nhất trong các tình huống mà không cần xác nhận để đáp ứng các yêu cầu bảo mật nội bộ.

8.1.2  Dịch vụ truy cập

Giao diện truy cập chỉ chứa một phương pháp duy nhất, truy cập, lấy một đối số duy nhất và không trả về kết quả nào. Việc triển khai giao diện truy vấn EPCIS PHẢI chấp nhận từng thành phần của danh sách đối số là một EPCISEvent còn hiệu lực hoặc loại phụ của chúng theo quy định kĩ thuật này.Việc triển khai CÓ THỂ chấp nhận các loại sự kiện khác thông qua việc mở rộng của nhà cung cấp. Sự đơn giản của giao diện này thừa nhận một loạt các ràng buộc, bao gồm các ràng buộc kiểu hàng đợi tin nhắn đơn giản.

Không bắt buộc: Giải thích: “Các ràng buộc loại hàng đợi của tin nhắn” có nghĩa như sau. Các doanh nghiệp thường sử dụng công nghệ “bus tin nhắn” để kết nối các thành phần hệ thống phản tán khác nhau. Một bus tin nhắn cung cấp một kênh đáng tin cậy để giao hàng trong các tin nhắn từ một người gửi đến một người nhận. (Mối quan hệ giữa người gửi và người nhận có thể là điểm-điểm (một tin nhắn “xếp hàng”) hoặc một người đến nhiều người thông qua cơ chế xuất bản / đăng kí (một tin nhắn “chủ đề”).) Giao diện truy vấn EPCIS chỉ đơn giản là chỉ định một kênh bus tin nhắn cụ thể cho mục đích cung cấp các sự kiện EPCIS từ một ứng dụng truy cập EPCIS đến một Kho lưu trữ EPCIS hoặc đến một ứng dụng Truy cập EPCIS theo Giao diện Gọi lại Truy vấn EPCIS. Mỗi tin nhắn sẽ có một dung lượng chứa một hoặc nhiều sự kiện EPCIS (được tuần tự hóa thông qua một số ràng buộc ở Tầng Định nghĩa Dữ liệu, ví dụ: một liên kết XML). Do đó, mỗi lần truyền / phân phối một tin nhắn tương ứng với một hoạt động “truy cập” duy nhất.

Thao tác truy cập ghi lại một hoặc nhiều sự kiện EPCIS, thuộc bất kì loại nào.

Bảng 24 – Mô tả đối số

Đối số	Loại	Mô tả
event	Danh sách EPCISEvent	(Các) sự kiện để truy cập. Tất cả các thông tin liên quan như thời gian sự kiện, EPC, vv, được chứa trong mỗi sự kiện. Ngoại lệ: recordTime CÓ THỂ được bỏ qua. Cho dù recordTime được bỏ qua hay không trong đầu vào, theo sau hoạt động truy cập, thời gian ghi lại của sự kiện được ghi lại bởi Kho lưu trữ EPCIS hoặc ứng dụng Truy cập EPCIS là thời gian truy cập. Lưu ý rằng eventID tùy chọn không được xử lý như recordTime; giống như bất kì trường EPCIS nào khác, eventID sẽ được truy cập mà không cần sửa đổi bởi giao diện truy cập. Giải thích (không bắt buộc): việc xử lý recordTime này là cần thiết để các truy vấn thường trực được xử lý đúng cách. Xem 8.2.5.2.

Giá trị trả về:

(không có)

Các ràng buộc cụ thể của Giao diện truy vấn EPCIS trong điều 10 sử dụng cấu trúc tài liệu EPCIS được định nghĩa trong 9.5 để mang danh sách các sự kiện EPCIS được truy cập. Một tài liệu EPCIS có thể chứa dữ liệu chủ trong tiêu đề tài liệu. Việc thực hiện Giao diện truy vấn EPCIS phù hợp với tiêu chuẩn này CÓ THỂ chọn để lưu lại dữ liệu chủ hoặc CÓ THỂ chọn để bỏ qua nó – việc bố trí dữ liệu chủ nhận được thông qua Giao diện truy vấn EPCIS không được quy định theo tiêu chuẩn EPCIS. Tương tự như vậy, một hệ thống thực hiện Giao diện truy vấn EPCIS có thể cung cấp phương tiện để truy cập dữ liệu chủ bằng cách nhận một tài liệu dữ liệu chủ EPCIS (9.7) nhưng tiêu chuẩn EPCIS không yêu cầu sự hỗ trợ này.

Mặt khác, bất kì dữ liệu chủ của cá thể / lô nào được thực hiện trong phần ILMD của sự kiện PHẢI được truy cập như một phần của sự kiện, như là sự thật cho bất kì thành phần dữ liệu nào trong sự kiện EPCIS. Dữ liệu chủ như vậy PHẢI có khả năng truy vấn được bằng cách sử dụng các tham số truy vấn của SimpleEventQuery được quy định trong 8.2.7.1, nhưng không yêu cầu thực hiện để làm cho dữ liệu chủ trong phần HMD của sự kiện có sẵn cho truy vấn bằng SimpleMasterDataQuery được quy định trong 8.2.7.2.

Triển khai giao diện truy cập PHẢI hoặc truy cập tất cả các sự kiện được quy định trong hoạt động truy cập đã cho hoặc không truy cập tất cả các sự kiện trong hoạt động đó. Đó là, việc thực hiện KHÔNG ĐƯỢC có khả năng thành công một phần mà một số sự kiện trong danh sách được truy cập còn những những sự kiện khác thì không.

Lý do tại sao hoạt động truy cập bị lỗi là vệc thực hiện cụ thể. Ví dụ về các lý do lỗi có thể xảy ra bao gồm:

– Đầu vào cho hoạt động truy cập không được định dạng tốt hoặc không phù hợp với các yêu cầu cú pháp của ràng buộc cụ thể đang được sử dụng, bao gồm cả tính hợp lệ của lược đồ cho các ràng buộc cụ thể sử dụng các lược đồ XML được định nghĩa trong điều 9.

– Khách hàng không được phép thực hiện thao tác truy cập.

– Các giới hạn triển khai cụ thể được vượt quá về số lượng sự kiện trong một thao tác truy cập, tổng số sự kiện được lưu trữ, tần suất truy cập v.v…

– Các quy tắc cụ thể về thực thi liên quan đến nội dung của các sự kiện, hoặc trong sự cô lập hoặc có tham chiếu đến các sự kiện đã truy cập trước đó, đều bị vi phạm. Lưu ý rằng các quy tắc như vậy có thể phù hợp trong một hệ thống khép kín khi sử dụng EPCIS được điều chỉnh bởi một tiêu chuẩn ứng dụng cụ thể, nhưng có thể không phù hợp trong một hệ thống mở được thiết kế đề xử lý bất kì dữ liệu EPCIS nào. Quy tắc loại này có thể giới hạn khả năng tương tác nếu chúng quá hẹp.

– Lỗi tạm thời, chẳng hạn như tạm thời không có máy chủ hoặc mạng.

8.2  Mô-đun hoạt động truy vấn cốt lõi

Mô đun hoạt động truy vấn cốt lõi cung cấp hai giao diện, được gọi là Giao diện kiểm soát truy vấn EPCIS và Giao diện gọi lại truy vấn EPCIS, theo đó dữ liệu EPCIS có thể được truy xuất bằng một ứng dụng truy cập EPCIS. Giao diện kiểm soát truy vấn EPCIS xác định phương tiện đối với ứng dụng truy cập EPCIS và đối tác thương mại để thu thập dữ liệu EPCIS sau khi truy cập từ bất kì nguồn nào, thường là bằng cách tương tác với một kho lưu trữ EPCIS. Nó cung cấp phương tiện cho ứng dụng truy cập EPCIS để truy xuất dữ liệu theo yêu cầu và cũng có thể nhập đăng kí cho truy vấn thường trực. Các kết quả truy vấn thường trực được gửi đến ứng dụng truy cập EPCIS thông qua Giao diện gọi lại truy vấn EPCIS. Trong phần này, từ “khách hàng” đề cập đến một ứng dụng truy cập EPCIS và “dịch vụ EPCIS“ đề cập đến một hệ thống thực hiện Giao diện kiểm soát truy vấn EPCIS, và ngoài ra cung cấp thông tin cho khách hàng thông qua Giao diện gọi lại truy vấn EPCIS.

8.2.1  Xác nhận

Một số ràng buộc của Giao diện kiểm soát truy vấn EPCIS cung cấp phương tiện đối với Dịch vụ EPCIS để xác nhân số phân định của khách hàng, đối với khách hàng để xác nhận số phân định của Dịch vụ EPCIS hoặc cả hai. Quy định kĩ thuật của các phương tiện để xác nhận được cho trong quy định kĩ thuật của từng ràng buộc. Nếu Dịch vụ EPCIS xác nhận số phân định của khách hàng, việc thực hiện CÓ THỂ sử dụng số phân định khách hàng để đưa ra các quyết định ủy quyền như được mô tả trong phần tiếp theo.

Không bắt buộc: Giải thích: Các đối tác thương mại sẽ luôn sử dụng các ràng buộc cung cấp xác nhận số phân định khách hàng hoặc xác nhận lẫn nhau khi sử dụng các giao diện EPCIS để chia sẻ dữ liệu qua các ranh giới của tổ chức. Các ràng buộc không cung cấp xác nhận cho dự kiến sẽ chỉ sử dụng trong một tổ chức duy nhất trong các tình huống mà không cần xác nhận để đáp ứng các yêu cầu bảo mật nội bộ.

8.2.2  Ủy quyền

Dịch vụ EPCIS có thể chỉ muốn cung cấp quyền truy cập vào một tập hợp con thông tin, tùy thuộc vào số phân định của khách hàng yêu cầu. Tình huống này thường xảy ra trong các trường hợp giữa các doanh nghiệp mà khách hàng yêu cầu thuộc về một tổ chức khác với tổ chức có dịch vụ EPCIS, nhưng cũng có thể phát sinh trong các tình huống nội bộ doanh nghiệp.

Với truy vấn EPCIS, một dịch vụ EPCIS CÓ THỂ thực hiện bất kì hành động nào sau đây khi xử lý truy vấn, dựa trên số phân định được xác nhận của khách hàng:

– Dịch vụ CÓ THỂ từ chối, thực hiện toàn bộ các yêu cầu bằng cách trả lời

SecurityException như được định nghĩa bên dưới.

– Dịch vụ CÓ THỂ đáp ứng với ít dữ liệu hơn so với yêu cầu. Ví dụ, nếu một khách hàng trình bày một truy vấn yêu cầu tất cả các cá thể ObjectEvent trong một khoảng thời gian xác định, dịch vụ biết 100 sự kiện phù hợp, dịch vụ có thể chọn trả lời ít hơn 100 sự kiện (ví dụ, chỉ trả lời những sự kiện có EPC là SGTIN tiền tố công ty được quy định để được chỉ định cho khách hàng).

– Dịch vụ CÓ THỂ đáp ứng thông tin chi tiết hơn. Đặc biệt, khi phản hồi truy vấn bao gồm một loại vị trí (như được định nghĩa trong 7.3.4), dịch vụ có thể thay thế vị trí tổ hợp thay cho vị trí nguyên thủy.

– Dịch vụ CÓ THỂ ẩn thông tin. Ví dụ, nếu một khách hàng trình bày một truy vấn yêu cầu các cá thể ObjectEvent, dịch vụ có thể chọn loại bỏ các trường bizTransactionList trong phản hồi của nó. Tuy nhiên, thông tin được trả lại là các sự kiện EPCIS được định dạng phù hợp với các quy định kĩ thuật và hướng dẫn của ngành này. Ngoài ra, nếu ẩn thông tin, nếu không sẽ dẫn đến thông tin mơ hồ hoặc gây nhầm lẫn, thì toàn bộ sự kiện NÊN được giữ lại. Điều này áp dụng cho dù thông tin ban đầu đã được truy cập thông qua Giao diện truy vấn EPCIS hay được cung cấp bởi một số phương tiện khác. Ví dụ, với một AggregationEvent có hành động BỔ SUNG, một nỗ lực để ẩn trường parentID sẽ dẫn đến một sự kiện không được định dạng tốt, vì parentID được yêu cầu khi hành động là BỔ SUNG; trong trường hợp này, do đó, toàn bộ sự kiện sẽ phải được giữ lại.

– Dịch vụ CÓ THỂ giới hạn phạm vi của truy vấn đối với dữ liệu ban đầu được truy cập bởi số phân định khách hàng cụ thể. Điều này cho phép một dịch vụ EPCIS duy nhất được “phân đoạn” để sử dụng bơi các nhóm người dùng không liên quan có dữ liệu cần được giữ riêng biệt.

Việc triển khai EPCIS là miễn phí để xác định xem có bất kì hành động nào trong số này thực hiện bất kì truy vấn nào, sử dụng bất kì phương tiện nào mà nó chọn. Quy định kĩ thuật của các quy tắc ủy quyền nằm ngoài phạm vi của tiêu chuẩn này.

Không bắt buộc: Giải thích: Bởi vì quy định kĩ thuật EPCIS có liên quan đến các giao diện truy vấn trái ngược với bất kì triển khai cụ thể nào, cho nên quy định kĩ thuật EPCIS không có vị trí như thế nào về các quyết định ủy quyền được thực hiện như thế nào. Việc triển khai cụ thể EPCIS có thể có các quy tắc kinh doanh phức tạp tùy ý để ủy quyền. Điều đó nêu rằng, quy định kĩ thuật của EPCIS có thể chứa dữ liệu chuẩn cần thiết đề ủy quyền, cho dù có dành riêng cho mục đích đó hay không.

8.2.3  Truy vấn cho số lượng lớn dữ liệu

Nhiều hoạt động truy vấn được xác định bên dưới cho phép khách hàng thực hiện yêu cầu về số lượng dữ liệu có khả năng không giới hạn. Ví dụ, phản hồi cho một truy vấn yêu cầu tất cả các cá thể ObjectEvent trong một khoảng thời gian nhất định có thể trả về một, một nghìn, một triệu hoặc một tỷ sự kiện tùy thuộc vào khoảng thời gian và số lượng sự kiện đã được truy cập. Điều này có thể trình bày các vấn đề thực hành đối với việc triển khai dịch vụ.

Để giảm thiểu vấn đề này, một dịch vụ EPCIS CÓ THỂ từ chối bất kì yêu cầu nào bằng cách đưa ra một ngoại lệ QueryTooLarge. Ngoại lệ này chỉ ra rằng lượng dữ liệu được yêu cầu lớn hơn dịch vụ sẵn sàng cung cấp cho khách hàng. Ngoại lệ QueryTooLarge là một gợi ý cho khách hàng rằng khách hàng có thể thành công bằng cách thu hẹp phạm vi truy vấn ban đầu hoặc bằng cách trình bày truy vấn vào một thời điểm khác (ví dụ, nếu dịch vụ chấp nhận hoặc từ chối truy vấn dựa trên tải tính toán hiện tại trên dịch vụ).

Không bắt buộc: Lộ trình: Dự kiến các phiên bản tương lai của tiêu chuẩn này sẽ cung cấp các cách phức tạp hơn để giải quyết vấn đề truy vấn lớn, chẳng hạn như phân trang, cursoring, v.v. Không có gì phức tạp hơn đã được đồng ý trong phiên bản này.

8.2.4  Truy vấn quá phức tạp

Việc triển khai dịch vụ EPCIS có thể muốn hạn chế các loại truy vấn có thể được xử lý, để tránh chi phí cho xử lý các truy vấn sẽ nhiều hơn cả chi phí cho dịch vụ. Ví dụ: truy vấn tìm kiếm sự kiện có giá trị cụ thể trong trường sự kiện cụ thể có thể yêu cầu nhiều hoặc ít nguồn lực hơn để xử lý tùy thuộc vào việc triển khai dự kiến tìm kiếm ở trường đó (ví dụ: tùy thuộc vào cột cơ sở dữ liệu tương ứng với trường đó xem có đáng lập chỉ số mục lục đó hay không). Như với các truy vấn cho quá nhiều dữ liệu (8.2.3), điều này có thể trình bày các vấn đề về hiệu quả cho việc triển khai dịch vụ.

Để giảm thiểu vấn đề này, một dịch vụ EPCIS CÓ THỂ từ chối bất kì yêu cầu nào bằng cách đưa ra một ngoại lệ QueryTooComplex. Ngoại lệ này chỉ ra rằng cấu trúc của truy vấn là như vậy mà dịch vụ không muốn thực hiện cho khách hàng. Không giống như QueryTooLarge ngoại lệ (8.2.3), QueryTooComplex cho biết chỉ thu hẹp phạm vi truy vấn (ví dụ: bằng cách yêu cầu giá trị của một tuần thay vì một tháng) sẽ không làm cho truy vấn thành công.

Một ngôn ngữ truy vấn cụ thể có thể quy định các điều kiện theo đó một dịch vụ EPCIS không được phép từ chối truy vấn với một ngoại lệ QueryTooCompIex. Điều này cung cấp mức độ tối thiểu của khả năng tương tác.

8.2.5  Khung truy vấn (giao diện kiểm soát truy vấn EPCIS)

Giao diện kiểm soát truy vấn EPCIS cung cấp một khung chung mà các ứng dụng khách hàng có thể truy vấn dữ liệu EPCIS. Giao diện cung cấp cả truy vấn theo yêu cầu, trong đó yêu cầu rõ ràng từ khách hàng khiến truy vấn được thực thi và kết quả được trả về trong phản hồi và truy vấn thường trực, trong đó khách hàng đăng kí lãi suất liên tục trong truy vấn và sau đó nhận kết quả định kì qua Giao diện gọi lại truy vấn EPCIS mà không yêu cầu thêm. Hai chế độ này được gọi chính thức là “kéo” và “đẩy” tương ứng.

Giao diện kiểm soát truy vấn EPCIS được định nghĩa bên dưới. Triển khai giao diện điều khiển truy vấn PHẢI thực hiện tất cả các phương pháp được định nghĩa bên dưới.

Truy vấn thường trực được thực hiện bằng cách thực hiện một hoặc nhiều đăng kí cho truy vấn được xác định trước bằng cách sử dụng phương pháp đăng kí. Kết quả sẽ được gửi định kì qua Giao diện gọi lại truy vấn đến một điểm đến cụ thể, cho đến khi đăng kí bị hủy bằng phương pháp hủy đăng kí. Các truy vấn theo yêu cầu được thực hiện bằng cách thực hiện truy vấn được xác định trước bằng phương thức thăm dò ý kiến. Mỗi lời gọi của phương pháp thăm dò sẽ trả lại kết quả trực tiếp cho người gọi. Trong cả hai trường hợp, nếu truy vấn được tham số hóa, các cài đặt cụ thể cho các tham số có thể được cung cấp làm đối số để đăng kí hoặc thăm dò ý kiến.

Việc triển khai CÓ THỂ cung cấp một hoặc nhiều truy vấn “được xác định trước”. Truy vấn được xác định trước có sẵn để sử dụng bằng cách đăng kí hoặc thăm dò ý kiến và được trả về trong danh sách tên truy vấn được trả về bởi getQueryNames, mà trước đó khách hàng đã thực hiện bất kì hành động nào để xác định truy vấn. Đặc biệt, EPCIS 1.0 không hỗ trợ bất kì cơ chế nào mà một khách hàng có thể định nghĩa một truy vấn mới, và do đó các truy vấn được xác định trước là các truy vấn duy nhất có sẵn. Xem 8.2.7 cho các truy vấn được xác định trước cụ thể mà nó PHẢI được cung cấp bởi việc triển khai Giao diện truy vấn EPCIS 1.0.

Việc triển khai CÓ THỂ cho phép một truy vấn nhất định được sử dụng có sự thăm dò ý kiến nhưng không đăng kí. Nói chung, các truy vấn cho dữ liệu sự kiện có thể được sử dụng có cả thăm dò ý kiến và đăng kí, nhưng các truy vấn cho dữ liệu chủ có thể chỉ được sử dụng có sự thăm dò ý kiến. Điều này là do đăng kí thiết lập lịch biểu định kì để thực hiện truy vấn nhiều lần, mỗi lần hạn chế sự chú ý đến các sự kiện mới được ghi lại kể từ lần truy vấn cuối cùng được thực hiện. Cơ chế này không thể áp dụng cho các truy vấn cho dữ liệu chủ, vì dữ liệu chủ được coi là bán tĩnh và không có bất kì thứ gì tương ứng với thời gian lưu.

Bảng 25 – Quy định kĩ thuật của các phương pháp truy vấn

Phương pháp	Mô tả
subscribe	Đăng kí người đăng kí cho truy vấn được xác định trước có tên được quy định. Đối số param cung cấp các giá trị được sử dụng cho bất kì tham số nào được đặt tên do truy vấn xác định. Tham số dest xác định đích đến nơi các kết quả từ truy vấn sẽ được gửi, thông qua Giao diện gọi lại truy vấn. Tham số dest là một URI, cả hai đều xác định một ràng buộc cụ thể của Giao diện gọi hại truy vấn để sử dụng và quy định thông tin địa chỉ. Tham số điều khiển kiểm soát cách xử lý đăng kí; cụ thể, nó quy định các điều kiện mà theo đó truy vấn sẽ được gọi (ví dụ: quy định lịch biểu định kỳ). ID đăng kí là một chuỗi tùy ý được sao chép vào mọi phản hồi được gửi đến đích đã quy định và nếu không dịch vụ EPCIS không giải thích được. Khách hàng có thể sử dụng subscriptionID để xác định đăng kí nào đã tạo ra kết quả nhất định, đặc biệt khi một số đăng kí được thực hiện cho cùng một đích. Đối số dest có thể là không hoặc rỗng, trong trường hợp này việc thực thi EPCIS PHẢI gửi kết quả đến đích được sắp xếp trước dựa trên số phân định được xác nhận của người gọi; tuy nhiên, nếu việc triển khai không có điểm đến được sắp xếp trước cho người gọi hoặc không cho phép sử dụng này, thì thay vào đó, PHẢI tăng thêm InvalidURIException.
unsubscribe	Xóa đăng kí đã đăng kí trước đó, đăng kí subscriptionID. theo quy định.
poll	Gọi một truy vấn được xác định trước có tên được quy định, trả lại kết quả. Đối số param cung cấp các giá trị được sử dụng cho bất kì tham số nào được đặt tên do truy vấn xác định.
getQueryNames	Trả lại danh sách tất cả các tên truy vấn có sẵn để sử dụng cho các phương pháp đăng kí và thăm dò ý kiến. Điều này bao gồm tất cả các truy vấn được xác định trước do triển khai cung cấp, bao gồm các truy vấn được quy định trong 8.2.7.
getSubscriptionIDs	Trả lại danh sách tất cả các subscriptionIDs hiện đã đăng kí với truy vấn có tên được quy định.
getStandardVersion	Trả lại chuỗi phân định phiên bản nào của quy định kĩ thuật triển khai này tuân thủ. Các giá trị có thể cho chuỗi này được xác định bởi GS1. Việc thực hiện PHẢI trả lại một chuỗi tương ứng với một phiên bản của tiêu chuẩn này mà việc thực hiện hoàn toàn tuân thủ, và NÊN trả lại chuỗi tương ứng với phiên bản mới nhất mà nó tuân thủ. Để chỉ ra sự tuân thủ với Phiên bản 1.2 của quy định kĩ thuật EPCIS, việc thực hiện PHẢI trả lại chuỗi 1.2.
getVendorVersion	Trả lại chuỗi phân định những phần mở rộng của nhà cung cấp mà triển khai này cung cấp. Các giá trị có thể có của chuỗi này và ý nghĩa của chúng được định nghĩa bởi nhà cung cấp, ngoại trừ chuỗi rỗng PHẢI chỉ ra rằng triển khai chỉ thực hiện chức năng tiêu chuẩn mà không có phần mở rộng của nhà cung cấp. Khi triển khai chọn để trả lại chuỗi không trống, giá trị trả lại PHẢI là một URI nơi nhà cung cấp là cơ quan sở hữu. Ví dụ, đây có thể là URL HTTP có phần thẩm quyền là tên miền do nhà cung cấp sở hữu, URN có mã phân định tên miền tên URN được IANA cung cấp, một URID OID có đường dẫn ban đầu là mã số doanh nghiệp được quy định cho nhà cung cấp, v.v.

Khung này áp dụng bất kể nội dung của truy vấn nào. Nội dung chi tiết của truy vấn và kết quả được trả về từ cuộc thăm dò hoặc được gửi tới người đăng kí qua Giao diện gọi lại truy vấn, được xác định trong các phần sau của tiêu chuẩn này. Cấu trúc này được thiết kế để tạo thuận lợi cho khả năng mở rộng, vì các loại truy vấn mới có thể được quy định và phù hợp với khung chung này.

Viêc triển khai CÓ THỂ hạn chế hành vi của bất kì phương pháp nào theo quyết định ủy quyền dựa trên số phân định khách hàng đã được xác nhận của khách hàng thực hiện yêu cầu. Ví dụ: triển khai có thể giới hạn ID được trả về bởi getSubscriptionID và được nhận dạng bằng cách hủy đăng kí chỉ với những người đăng kí trước đây đã được đăng kí bởi cùng một số phân định khách hàng. Điều này cho phép dịch vụ EPCIS duy nhất được “phân đoạn” để sử dụng bởi các nhóm người dùng không liên quan có dữ liệu cần được giữ riêng biệt.

Nếu truy vấn xác định trước định nghĩa các tham số có tên, các giá trị cho các tham số đó có thể được cung cấp khi truy vấn sau đó được gọi bằng cách sử dụng thăm dò ý kiến hoặc đăng kí. Một cá thể QueryParams chì đơn giản là một tập hợp các cặp tên / giá trị, trong đó các tên tương ứng với các tên tham số được xác định bởi truy vấn, và các giá trị là các giá trị cụ thể được sử dụng cho yêu cầu (thăm dò) hoặc đăng kí (đăng kí) truy vấn. Nếu một cá thể QueryParams bao gồm một cặp tên / giá trị trong đó giá này trị rỗng, nó sẽ được diễn giải như thể thông số truy vấn đó bị bỏ qua hoàn toàn.

Phương pháp thăm dò ý kiến hoặc đăng kí PHẢI đưa ra một QueryParameterException trong bất kì trường hợp nào sau đây:

– Một tham số được yêu cầu bởi truy vấn được quy định bị bỏ qua hoặc được cung cấp với một giá trị rỗng

– Một tham số được cung cấp có tên không tương ứng với bất kì tên tham số nào được xác định bởi truy vấn được quy định

– Hai tham số được cung cấp có cùng tên

– Bất kì ràng buộc nào khác do truy vấn được quy định áp đặt đều bị vi phạm. Những ràng buộc như vậy có thể bao gồm các hạn chế về phạm vi giá trị được phép cho một tham số cụ thể, các yêu cầu mà hai hoặc nhiều tham số loại trừ lẫn nhau hoặc phải được cung cấp cùng nhau, v.v. Các ràng buộc cụ thể được áp đặt bởi một truy vấn đã cho được quy định trong tài liệu cho truy vấn đó.

8.2.5.1  Kiểm soát đăng kí

Truy vấn thường trực được đăng kí thông qua phương pháp đăng kí. Đối với mỗi đăng kí, cá thể

SubscriptionControls xác định cách xử lý truy vấn.

Các trường của một cá thể SubscriptionControls được định nghĩa dưới đây.

Bảng 26 – Các trường của cá thể SubscriptionControls

Đối số	Loại	Mô tả
schedule	QuerySchedule	(Tùy chọn) Xác định lịch trình định kì mà truy vấn sẽ được thực thi. Xem 8.2.5.3. Chính xác một trong những lịch trình hoặc kích hoạt là bắt buộc; nếu cả hai được quy định hoặc cả hai được bỏ qua,thì sự thực hiện PHẢI gây ra SubscriptionControlsException.
trigger	URI	(Tùy chọn) QUY định một sự kiện kích hoạt được biết đến với dịch vụ EPCIS sẽ phục vụ để kích hoạt thực hiện truy vấn này. URI kích hoạt có sẵn phụ thuộc vào dịch vụ. Chính xác một trong những lịch trình hoặc kích hoạt là bắt buộc; nếu cả hai được quy định hoặc cả hai được bỏ qua, thì sự thực hiện PHẢI gây ra SubscriptionControlsException.
initialRecordTime	Time	(Tùy chọn) Quy định thời gian sử dụng để hạn chế những sự kiện nào được xem xét khi xử lý truy vấn khi nó được thực thi lần đầu tiên. Xem 8.2.5.2. Nếu bị bỏ qua, mặc định là thời điểm tạo đăng kí.
reportlfEmpty	boolean	Nếu đúng, một cá thể QueryResults luôn được gửi đến người đăng kí khi truy vấn được thực hiện. Nếu sai, một cá thể QueryResults chì được gửi tới người đăng kí khi kết quả không trống.

8.2.5.2  Giới hạn tự động dựa trên thời gian lưu trữ sự kiện

Mỗi đăng kí truy vấn dẫn đến kết quả truy vấn được thực hiện nhiều lần liên tiếp, thời gian của mỗi lần thực hiện được kiểm soát theo lịch được quy định hoặc được kích hoạt bởi điều kiện kích hoạt được quy định bởi lịch kích hoạt. Việc thực thi nhiều truy vấn giống nhau chỉ là hợp lý nếu mỗi lần thực thi được hạn chế trong phạm vi dữ liệu sự kiện mới được tạo ra kể từ lần thực thi cuối cùng – nếu không, các sự kiện tương tự sẽ được trả về nhiều lần. Tuy nhiên, các ràng buộc về thời gian khống thể được chỉ ra một cách rõ ràng trong các tham số truy vấn hoặc truy vấn, bởi vì các tham số này không thay đổi từ một lần thực hiện đến tiếp theo.

Vì lý do này, một dịch vụ EPCIS PHẢI hạn chế phạm vi của mỗi lần thực thi truy vấn cho một truy vấn đã đăng kí theo cách sau. Lần đầu tiên truy vấn được thực hiện cho một thuê bao đã cho, các sự kiện duy nhất được xem xét là những sự kiện có trường recordTime lớn hơn hoặc bằng initialRecordTime được quy định khi lập đăng kí. Đối với mỗi lần thực hiện truy vấn sau lần đầu tiên, các sự kiện duy nhất được xem xét là những trường có trường recordTime lớn hơn hoặc bằng thời gian truy vấn được thực hiện lần cuối. Việc triển khai phụ thuộc vào mức độ không cung cấp kết quả truy vấn cho người đăng kí ảnh hưởng đến tính toán này; Việc triển khai NÊN cố gắng đảm bảo phân phối tin cậy các kết quả truy vấn để người đăng kí không bỏ lỡ bất kì dữ liệu nào. Các tham số truy vấn hoặc truy vấn có thể quy định định các ràng buộc BỔ SUNG khi ghi lại thời gian; chúng được áp dụng sau khi hạn chế không gian của các sự kiện như mô tả ở trên.

Không bắt buộc: Giải thích: có thể thực hiện yêu cầu này là dịch vụ EPCIS duy trì giá trị minRecordTime cho mỗi thuê bao tồn tại. Thời gian minRecordTime cho một thuê bao đã cho ban đầu được đặt thành initialRecordTime và được cập nhật đến thời điểm hiện tại mỗi khi truy vấn được thực hiện cho đăng kí đó. Mỗi lần truy vấn được thực thi, các sự kiện duy nhất được xem xét là những sự kiện có recordTime lớn hơn hoặc bằng minRecordTime cho đăng kí đó.

8.2.5.3  Lịch trình truy vấn

Một QuerySchedule có thể được quy định để quy định một lịch trình định kì cho việc thực hiện truy vấn cho một thuê bao cụ thể. Mỗi trường QuerySchedule là một chuỗi quy định mẫu cho phù hợp với một số phần thời gian hiện tại. Truy vấn sẽ được thực hiện mỗi khi ngày và giờ hiện tại khớp với quy định kĩ thuật trong QuerySchedule.

Mỗi trường QuerySchedule là một chuỗi, giá trị của nó phải phù hợp với cú pháp sau:

Mỗi Số là một phân của giá trị trường lịch trình truy vấn và phải nằm trong phạm vi pháp lý cho trường đó như được quy định trong bảng bên dưới. Việc triển khai EPCIS PHẢI tạo ra SubscriptionControlsException nếu bất kì giá trị trường lịch trình truy vấn nào không tuân theo ngữ pháp ở trên hoặc chứa số nằm ngoài phạm vi pháp lý hoặc bao gồm Phạm vi trong đó số đầu tiên lớn hơn Số thứ hai.

QuerySchedule quy định một chuỗi các giá trị thời gian định kì (“thời gian truy vấn”). Thời gian truy vấn là bất kì giá trị thời gian nào khớp với QuerySchedule, theo quy tắc sau:

– Đưa ra một giá trị thời gian, trích xuất giây, phút, giờ (từ 0 đến 23,kể cả 23), dayOfMonth (từ 1 đến 31, kể cả 31), và dayOfWeek (từ 1 đến 7, kể cả 7, biểu thị từ thứ Hai đến Chủ Nhật). Tính toán này được thực hiện liên quan đến múi giờ được chọn bởi Dịch vụ EPCIS.

– Giá trị thời gian khớp với QuerySchedule nếu mỗi giá trị được trích xuất ở trên (như được định nghĩa bên dưới) khớp với trường tương ứng của QuerySchedule, cho tất cả các trường QuerySchedule không bị bỏ qua.

– Một giá trị được trích xuất từ giá trị thời gian khớp với một trường của QuerySchedule nếu nó khớp với bất kì thành phần được phân cách bằng dấu phẩy nào của trường lịch trình truy vấn.

– Giá trị được trích xuất từ giá trị thời gian khớp với thành phần của trường lịch trình truy vấn nếu

– Thành phần là một Số và giá trị được trích xuất từ giá trị thời gian bằng với số đó; hoặc là

– Thành phần là một dãy và giá trị được trích ra từ giá trị thời gian lớn hơn hoặc bằng số đầu tiên trong dãy và nhỏ hơn hoặc bằng số thứ hai trong dãy.

Xem ví dụ sau bảng bên dưới.

Việc triển khai EPCIS PHẢI diễn giải QuerySchedule dưới dạng tuyên bố của khách hàng về thời điểm muốn truy vấn được thực thi và NÊN thực hiện các nỗ lực hợp lý để tuân thủ lịch trình đó. Tuy nhiên, việc triển khai EPCIS CÓ THỂ đi chệch khỏi lịch trình được yêu cầu theo chính sách riêng của mình liên quan đến máy chủ,sự ủy quyền hoặc bất kì lý do nào khác. Nếu việc thực hiện EPCIS biết được thời điểm phương pháp đăng kí được gọi, rằng nó sẽ không thể thực hiện QuerySchedule được quy định mà không bị lệch khỏi yêu cầu, thì việc thực hiện EPCIS NÊN có một SubscriptionControlsException thay thế.

Không bắt buộc: Giải thích: QuerySchedule, được thực hiện theo nghĩa đen, quy định thời gian thực hiện truy vấn chính xác xuống thứ hai. Trong thực tế, việc triển khai có thể không muốn hoặc không thể thực hiện yêu cầu đó một cách chính xác, nhưng có thể thực hiện ý định chung. Ví dụ, một QuerySchedule có thể quy định rằng một truy vấn được thực hiện mỗi giờ trên giờ, trong khi thực hiện có thể chọn để thực hiện truy vấn mỗi giờ cộng hoặc trừ năm phút từ đầu giờ. Đoạn trên được thiết kế để đưa ra độ rộng triển khai cho loại độ lệch này.

Trong bất kì trường hợp nào, việc xử lý tự động của recordTime như được quy định trước đó sẽ được dựa trên thời gian thực tế truy vấn được thực hiện, cho dù có khớp một cách chính xác với QuerySchedule hay không.

Trường của một cá thể QuerySchedule như sau.

Bảng 27 -Trường của cá thể QuerySchedule

Đối số	Loại	Mô tả
second	Chuỗi	(Tùy chọn) Quy định thời gian truy vấn phải có giá trị giây phù hợp. Phạm vi cho tham số này là từ 0 đến 59, kể cả 59.
minute	Chuỗi	(Tùy chọn) Quy định rằng thời gian truy vấn phải có giá trị phút phù hợp. Phạm vi cho tham số này là từ 0 đến 59, kể cả 59.
hour	Chuỗi	(Tùy chọn) Chỉ định rằng thời gian truy vấn phải có giá trị giờ phù hợp. Phạm vi cho tham số này là từ 0 đến 23, kể cả 23, với 0 biểu thị giờ bắt đầu lúc nửa đêm và 23 cho biết giờ kết thúc lúc nửa đêm.
dayOfMonth	Chuỗi	(Tùy chọn) Quy định rằng thời gian truy vấn phải có ngày phù hợp với giá trị của tháng. Phạm vi cho tham số này là từ 1 đến 31, kể cả 31. (Giá trị 29, 30 và 31 sẽ chỉ khớp với các tháng có ít nhất là nhiều ngày.)
month	Chuỗi	(Tùy chọn) Quy định rằng thời gian truy vấn phải có giá trị tháng phù hợp. Phạm vi cho tham số này là từ 1 đến 12, kể cả 12.
dayOfWeek	Chuỗi	(Tùy chọn) Quy định thời gian truy vấn phải có giá trị ngày trong tuần phù hợp. Phạm vi cho tham số này là từ 1 đến 7, kể cả 7 với 1 biểu thị Thứ Hai, 2 biểu thị Thứ Ba, v.v., tối đa 7 biểu thị Chủ Nhật. Giải thích (không bắt buộc): lược đồ đánh số này phù hợp với ISO-8601.

8.2.5.3.1  Ví dụ về lịch trình truy vấn (Không bắt buộc)

Dưới đây là một số ví dụ về QuerySchedule và ý nghĩa của chúng.

VÍ DỤ 1

QuerySchedule

second =“0”

minute = “0”

Tất cả các trường khác trống

Điều này có nghĩa là “thực hiện truy vấn một lần mỗi giờ, ở đầu giờ”. Nếu đối số reportlfEmpty đăng kí là sai, thì điều này không nhất thiết phải gửi báo cáo mỗi giờ – một báo cáo sẽ được gửi trong vòng một giờ bất kì dữ liệu sự kiện mới nào có sẵn phù hợp với truy vấn.

VÍ DỤ 2

QuerySchedule

second = “0”

minute = “30”

hour = “2”

Tất cả các trường khác trống

Điều này có nghĩa là “thực hiện truy vấn một lần mỗi ngày, lúc 2:30 sáng”.

VÍ DỤ 3

QuerySchedule

second = “0”

minute = “0”

dayOfWeek = “[1-5]”

Điều này có nghĩa là “thực hiện truy vấn một lần mỗi giờ ở đầu giờ, nhưng chỉ vào các ngày trong tuần”.

VÍ DỤ 4

QuerySchedule

hour = “2”

Tất cả các trường khác trống

Điều này có nghĩa là “thực hiện truy vấn một lần mỗi giây từ 2:00:00 đến 2:59:59 mỗi ngày.” Ví dụ này minh họa rằng thường không muốn bỏ qua một trường chi tiết mịn hơn các trường được quy định.

8.2.5.4  QueryResults

Một cá thể QueryResults được trả về đồng bộ từ phương pháp thăm dò của Giao diện kiểm soát truy vấn EPCIS, và cũng được gửi không đồng bộ đến người đăng kí của một truy vấn thường trực thông qua giao diện gọi lại truy vấn EPCIS

Các trường của một cá thể QueryResults được định nghĩa dưới đây.

Bảng 28 – Các trường của cá thể QueryResults

Trường	Loại	Mô tả
queryName	String	Trường này PHẢI chứa tên của truy vấn (đối số của queryName được quy định trong cuộc gọi để thăm dò ý kiến hoặc đăng kí).
subscriptionID	string	(Có điều kiện) Khi một cá thể QueryResults được gửi đến người đăng kí như là kết quả của một truy vấn thường trực, subscriptionID PHẢI chứa cùng một chuỗi được cung cấp như đối số của subscriptionID cuộc gọi để đăng kí. Khi một cá thể QueryResults được trả về như là kết quả của biện pháp thăm dò ý kiến, trường này PHẢI được bỏ qua.
resultsBody	QueryResultsBody	Thông tin được trả lại là kết quả của truy vấn. Loại chính xác của trường này phụ thuộc vào truy vấn nào được thực hiện. Mỗi truy vấn được xác định trước trong 8.2.7 quy định loại tương ứng cho trường này.

8.2.6  Điều kiện lỗi

Các phương pháp của các điều kiện lỗi tín hiệu API kiểm soát truy vấn EPCIS đối với khách bằng cách ngoại lệ. Các trường hợp ngoại lệ sau được xác định. Tất cả các loại ngoại lệ trong bảng sau là các phần mở rộng của một loại cơ sở EPCISException chung, chứa một thành phần chuỗi bắt buộc cho lý do ngoại lệ.

Bảng 29- Phần mở rộng của cơ sở EPCISException chung

Tên ngoại lệ	Ý nghĩa
SecurityException	Hoạt động này không được phép do vi phạm kiểm soát truy cập hoặc mối quan tâm bảo mật khác. Điều này bao gồm trường hợp dịch vụ muốn từ chối ủy quyền để thực hiện một hoạt động cụ thể dựa trên số phân định khách hàng được xác nhận. Các trường hợp cụ thể có thể gây ra ngoại lệ này được thực hiện cụ thể và nằm ngoài phạm vi của tiêu chuẩn này.
DuplicateNameException	(Không được triển khai trong EPCIS 1.2) Tên truy vấn được quy định đã tồn tại.
QueryValidationException	(Không được triển khai trong EPCIS 1.2) Truy vấn được quy định không hợp lệ; ví dụ: nó chứa lỗi cú pháp.
QueryParameterException	Một hoặc nhiều tham số truy vấn không hợp lệ, bao gồm bất kì tình huống nào sau đây: • tên tham số không phải là tham số được công nhận cho truy vấn được quy định • giá trị của tham số là sai loại hoặc nằm ngoài phạm vi • hai hoặc nhiều tham số truy vấn có cùng tên tham số
QueryTooLargeException	Nỗ lực thực thi truy vấn dẫn đến nhiều dữ liệu hơn dịch vụ sẵn sàng cung cấp.
QueryTooComplexException	Các tham số truy vấn được quy định, trong khi không hợp lệ, ngụ ý một truy vấn phức tạp hơn dịch vụ sẵn sàng thực hiện.
InvalidURIException	URI được quy định cho người đăng kí không phân tích cú pháp được, không đặt tên lược đồ được công nhận bởi việc triển khai hoặc vi phạm các quy tắc được áp đặt bởi một lược đồ cụ thể.
SubscriptionControlsException	Các điều khiển đăng kí được quy định không hợp lệ; ví dụ: tham số lịch trình nằm ngoài phạm vi, URI kích hoạt không thể phân tích được cú pháp hoặc không đặt tên cho kích hoạt được công nhận, v.v…
NoSuchNameException	Tên truy vấn được quy định không tồn tại.
NoSuchSubscriptionException	subscriptionID đã quy định không tồn tại.
DuplicateSubscriptionException	subscriptionID được quy định giống với đăng kí trước đã được tạo mà chưa được hủy đăng kí.
SubscribeNotPermittedException	Tên truy vấn được quy định có thể không được sử dụng với đăng kí, chỉ với cuộc thăm dò ý kiến.
ValidationException	Đầu vào cho hoạt động không hợp lệ theo cú pháp được xác định bởi ràng buộc. Mỗi ràng buộc quy định các trường hợp cụ thể theo đó ngoại lệ này được nêu ra.
ImplementationException	Ngoại lệ chung được đưa ra bởi việc thực hiện vì các lý do chúng là trường hợp thực hiện đặc thù. Ngoại lệ này chứa một thành phần bổ sung: thành viên mức độ nghiêm trọng có giá trị là LỖI hoặc LỖI NGHIÊM TRỌNG chỉ ra rằng việc thực hiện EPCIS còn lại trong cùng một trạng thái mà nó có trước khi thực hiện thao tác. Sự NGHIÊM TRỌNG chỉ ra rằng việc thực hiện EPCIS được để lại ở trạng thái không xác định.

Các ngoại lệ có thể được bỏ qua bởi từng phương pháp Giao diện kiểm soát truy vấn EPCIS được chỉ ra trong bảng bên dưới:

Bảng 30 – Phương pháp Giao diện kiểm soát truy vấn EPCIS

Phương pháp EPCIS	Ngoại lệ
getQueryNames	SecurityException ValidationException ImplementationException
subscribe	NoSuchNameException InvalidURIException DuplicateSubscriptionException QueryParameterException QueryTooComplexException SubscriptionControlsException SubscribeNotPermittedException SecurityException ValidationException ImplementationException
unsubscribe	NoSuchSubscriptionException SecurityException ValidationException ImplementationException
poll	NoSuchNameException QueryParameterException QueryTooComplexException QueryTooLargeException SecurityException ValidationException ImplementationException
getSubscriptionIDs	NoSuchNameException SecurityException ValidationException ImplementationException
getStandardVersion	SecurityException ValidationException ImplementationException
getVendorVersion	SecurityException ValidationException ImplementationException

Ngoài các ngoại lệ được bỏ qua từ các phương pháp của Giao diện kiểm soát truy vấn EPCIS như liệt kê ở trên, một nỗ lực thực hiên truy vấn thường trực có thể dẫn đến QueryTooLargeException hoặc ExceptionException được gửi tới người đăng kí qua Giao diện gọi lại truy vấn EPCIS thay vì kết quả truy vấn thông thường. Trong trường hợp này, QueryTooLargeException hoặc ImplementationException PHẢI bao gồm, ngoài chuỗi lý do, tên truy vấn và subscriptionID như được quy định trong cuộc gọi đăng kí đã tạo ra truy vấn thường trực.

8.2.7  Truy vấn được xác định trước cho EPCIS

Trong EPCIS, không có ngôn ngữ truy vấn nào được cung cấp do đó khách hàng có thể thể hiện một truy vấn tùy ý cho dữ liệu. Thay vào đó, việc triển khai EPCIS PHẢI cung cấp các truy vấn được xác định trước, mà khách hàng có thể gọi bằng cách sử dụng các phương thức thăm dò và đăng kí của Giao diện kiểm soát truy vấn EPCIS. Mỗi cuộc thăm dò hoặc cuộc gọi đăng kí có thể bao gồm các tham số thông qua đối số params. Các truy vấn được xác định trước được định nghĩa trong phần này, mỗi truy vấn có một số lượng lớn các tham số tùy chọn; bằng cách lựa chọn các tham số thích hợp, khách hàng có thể đạt được nhiều hiệu quả khác nhau.

Các tham số cho mỗi truy vấn được xác định trước và kết quả trả về được quy định trong phần này. Việc triển khai EPCIS là miễn phí để sử dụng cho bất kì đại diện nội bộ nào đối với dữ liệu mong muốn và triển khai các truy vấn được xác định trước này bằng bất kì cơ sở dữ liệu hoặc công nghệ truy vấn nào, miễn là kết quả mà khách hàng nhìn thấy phù hợp với tiêu chuẩn này.

8.2.7.1  SimpleEventQuery

Truy vấn này được gọi bằng cách quy định chuỗi SimpleEventQuery làm đối số queryName để thăm dò ý kiến hoặc đăng kí. Kết quả là một cá thể QueryResults mà cơ thể của nó chứa một danh sách các cá thể EPCISEvent (có thể trống). Trừ khi bị ràng buộc bởi tham số eventType, mỗi thành phần của danh sách kết quả có thể thuộc bất kì loại sự kiện nào; tức là, ObjectEvent, AggregationEvent, QuantityEvent, TransactionEvent hoặc bất kì loại sự kiện mở rộng nào là tầng con của EPCISEvent.

SimpleEventQuery PHẢI có sẵn thông qua cả thăm dò và đăng ký; đó là,việc thực hiện KHÔNG ĐƯỢC gây ra SubscribeNotPermittedException khi SimpleEventQuery được quy định làm đối số của queryName để đăng kí.

SimpleEventQuery được xác định để trả về một tập hợp các sự kiện phù hợp với các tiêu chí được quy định trong các tham số truy vấn (như được chỉ ra bên dưới). Khi trả về các sự kiện đã được truy cập qua Giao diện truy vấn EPCIS, mỗi sự kiện được chọn sẽ được trả về PHẢI giống hệt với sự kiện được truy cập ban đầu, theo các điều khoản của ủy quyền (8.2.2), bao gồm trường recordTime và bất kì chuyển đổi cần thiết nào và từ một đại diện nội bộ trừu tượng nào. Tuy nhiên, đối với bất kì trường sự kiện nào được xác định để lưu giữ một danh sách không có thứ tự, việc triển khai EPCIS KHÔNG CẦN duy trì trật tự.

Các tham số cho truy vấn này như sau. Không có tham số nào là bắt buộc (mặc dù trong hầu hết các trường hợp, truy vấn sẽ bao gồm ít nhất một thông số truy vấn).

Bảng 31 – Các tham số cho truy vấn SimpletventQuery

Tên các tham số	Loại giá trị của tham số	Ý nghĩa
eventType	Danh sách chuỗi	Nếu được quy định, kết quả sẽ chỉ bao gồm các sự kiện có loại khớp với một trong các loại quy định trong giá trị tham số. Mỗi thành phần của giá trị tham số có thể là một trong các chuỗi sau: ObjectEvent, AggregationEvent, QuantityEvent, TransactionEvent hoặc TransformationEvent. Thành phần của giá trị tham số cũng có thể là tên của loại sự kiện mở rộng. Nếu không có quy định, tất cả các loại sự kiện sẽ được xem xét để đưa vào kết quả.
GE_eventTime	Thời gian	Nếu có quy định, chỉ các sự kiện có thời gian sự kiện lớn hơn hoặc bằng giá trị quy định sẽ được đưa vào trong kết quả. Nếu không có quy định, các sự kiện được đưa vào bất kể EventTime của chúng (trừ khi bị ràng buộc bởi tham số LT_eventTime).
LT_eventTime	Thời gian	Nếu có quy định, chỉ các sự kiện có eventTime nhỏ hơn giá trị quy định sẽ được đưa vào trong kết quả. Nếu không có quy định, các sự kiện được đưa vào bất kể EventTime của chúng (trừ khi bị ràng buộc bởi tham số GE_eventTime).
GE_recordTime	Thời gian	Nếu được cung cấp, chỉ các sự kiện có thời gian ghi lớn hơn hoặc bằng giá trị quy định sẽ được trả lại. Giới hạn tự động dựa trên thời gian ghi sự kiện (8.2.5.2) có thể ngầm cung cấp một ràng buộc tương tự như tham số này. Nếu không được cung cấp, các sự kiện sẽ trả lại bất kể recordTime của chúng, ngoài giới hạn tự động dựa trên thời gian ghi sự kiện (8.2.5.2).
LT_recordTime	Thời gian	Nếu được cung cấp, chỉ các sự kiện có recordTime nhỏ hơn giá trị quy định sẽ được trả về. Nếu không được cung cấp, các sự kiện được trả về bất kể recordTime của chúng (trừ khi bị ràng buộc bởi tham số GE_recordTime hoặc giới hạn tự động dựa trên thời gian ghi sự kiện).
EQ_action	Danh sách chuỗi	Nếu có quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có một trường hành động; và ở đó (b) giá trị của trường hành động khớp với một trong các giá trị quy định. Các thành phần của giá trị tham số này phải là một trong các chuỗi BỔ SUNG, QUAN SÁT hoặc LOẠI BỎ; nếu không, việc thực hiện PHẢI tạo ra QueryParameterException. Nếu bỏ qua, các sự kiện được bao gồm bất kể trường hành động của chúng.
EQ_bizStep	Danh sách chuỗi	Nếu có quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường bizStep non-null; ở đó (b) giá trị của trường bizStep khớp với một trong các giá trị quy định. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể giá trị của trường bizStep hoặc liệu trường bizStep có tồn tại hay không.
EQ_disposition	Danh sách chuỗi	Giống như tham số EQ_bizStep, nhưng đối với trường bố trí.
EQ_readPoint	Danh sách chuỗi	Nếu có quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường readPoint non-null; và ở đó (b) giá trị của trường readPoint khớp với một trong các giá trị quy định. Nếu tham số này và WD_readPoint đều bị bỏ qua, các sự kiện được trả về bất kể giá trị của trường readPoint hoặc liệu trường readPoint có tồn tại hay không.
WD_readPoint	Danh sách chuỗi	Nếu có quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường readPoint non-null; và ở đó (b) giá trị của trường readPoint khớp với một trong các giá trị quy định, hoặc là thế hệ con cháu trực tiếp hoặc gián tiếp của một trong các giá trị quy định. Ý nghĩa của “thế hệ con cháu trực tiếp hoặc gián tiếp” được xác định bởi dữ liệu chủ, như được mô tả trong 6.5. (WD là tên viết tắt của “với thế hệ con cháu.”) Nếu tham số này và EQ_readPoint đều bị bỏ qua, các sự kiện được trả về bất kể giá trị của trường readPoint hoặc liệu trường readPoint có tồn tại hay không.
EQ_bizLocation	Danh sách chuỗi	Giống như tham số EQ_readPoint, nhưng đối với trường bizLocation.
WD_bizLocation	Danh sách chuỗi	Giống như tham số WD_readPoint, nhưng đối với trường bizLocation.
EQ_bizTransaction_type	Danh sách chuỗi	Đây không phải là tham số duy nhất, mà là một họ các tham số. Nếu một tham số của biểu này được quy định, thì kết quả sẽ chỉ gồm các sự kiện (a) gồm một bizTransactionList; (b) trong đó danh sách giao dịch kinh doanh gồm một mục nhập có trường con loại của nó bằng loại được trích xuất từ tên của tham số này; và (c) trong đó trường con bizTransaction của mục nhập đó bằng một trong các giá trị quy định trong tham số này.
EQ_source_type	Danh sách chuỗi	Đây không phải là một tham số duy nhất, mà là một họ các tham số. Nếu một tham số của biểu này được quy định, thì kết quả sẽ chỉ bao gồm các sự kiện (a) bao gồm một danh sách nguồn; (b) trong đó danh sách nguồn chứa mục có trường con loại của nó bằng loại được trích xuất từ tên của tham số này; và (c) trong đó trường con nguồn của mục nhập đó bằng với một trong các giá trị quy định trong tham số này.
EQ_destination_type	Danh sách chuỗi	Đây không phải là một tham số duy nhất, mà là một họ các tham số. Nếu một tham số của biểu này được quy định, thì kết quả sẽ chỉ bao qồm các sự kiện (a) bao gồm một DestinationList; (b) trong đó danh sách đích bao gồm một mục nhập có trường con loại của nó bằng loại được trích xuất từ tên của tham số này; và (c) trong đó trường con đích của mục nhập đó bằng một trong các giá trị quy định trong tham số này.
EQ_transformationID	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có một trường biến đổi (đó là, TransformationEvents hoặc kiểu sự kiện mở rộng mà nó mở rộng TransformationEvent); và ở đó (b) trường conversionID bằng một trong các giá trị quy định trong tham số này.
MATCH_epc	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường epcList hoặc childEPCs (có nghĩa là, ObjectEvent, AggregationEvent, TransactionEvent hoặc các loại sự kiện mở rộng mà nó mở rộng một trong ba); và (b) một trong các EPC được liệt kê trong trường epcList hoặc childEPCs (tùy thuộc vào loại sự kiện) khớp với một trong các dạng EPC hoặc URI quy định trong tham số này, ý nghĩa của “matches” được quy định trong 8.2.7.1.1. Nếu tham số này bị bỏ qua, các sự kiện được đều đưa vào kết quả bất kể trường epcList hoặc childEPC của họ hoặc liệu trường tồn tại epcList hoặc childEPC có tồn tại hay không.
MATCH_parentID	Danh sách chuỗi	Giống như MATCH_epc, nhưng hợp với trường parentID của AggregationEvent, trường parentID của TransactionEvent và các loại sự kiện mở rộng mà nó mở rộng hoặc là AggregationEvent hoặc TransactionEvent. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1.
MATCH_inputEPC	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có một inputEPCList (có nghĩa là, TransformationEvent hoặc một kiểu sự kiện mở rộng mà nó mở rộng TransformationEvent); và (b) một trong các EPC được liệt kê trong trường inputEPCList hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1. Nếu tham số này bị bỏ qua, các sự kiện đều được đưa vào kết quả bất kể trường inputEPCList hoặc liệu trường inputEPCList có tồn tại hay không.
MATCH_outputEPC	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có outputEPCList (nghĩa là, TransformationEvent hoặc một kiểu sự kiện mở rộng mà nó mở rộng TransformationEvent); và (b) một trong các EPC được liệt kê trong trường outputEPCList hợp với một trong các mẫu EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1. Nếu tham số này bị bỏ qua, các sự kiện đều được đưa vào kết quả bất kể trường outputEPCList hoặc liệu trường outputEPCList có tồn tại hay không.
MATCH_anyEPC	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường epcList, trường childEPCs, trường parentID, trường inputEPCList hoặc trường outputEPCList (đó là, ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent hoặc các loại sự kiện mở rộng mà nó mở rộng một trong bốn loại sự kiện đó); và (b) trường parentID hoặc một trong các EPC được liệt kê trong trường epcList, childEPCs, inputEPCList hoặc outputEPCList (tùy thuộc vào loại sự kiện) hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1.
MATCH_epcClass	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có một quantityList hoặc một trường childQuantityList (có nghĩa là, ObjectEvent, AggregationEvent, TransactionEvent hoặc các loại sự kiện mở rộng mà nó mở rộng một trong ba); và (b) một trong các tầng EPC được liệt kê trong trường quantityList hoặc childQuantityList (tùy thuộc vào loại sự kiện) hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Kết quả cũng sẽ bao gồm QuantityEvents có trường epcClass hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “hợp” được quy định trong 8.2.7.1.1.
MATCH_inputEPCCIass	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường inputQuantityList (có nghĩa là, các loại sự kiện TransformationEvent hoặc các loại sự kiện mở rộng, mở rộng nó); và (b) một trong các tầng EPC được liệt kê trong trường inputQuantityList (tùy thuộc vào loại sự kiện) hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1.
MATCH_outputEPCCIass	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường outputQuantityList (có nghĩa là, TransformationEvent hoặc các loại sự kiện mở rộng, mở rộng nó); và (b) một trong các tầng EPC được liệt kê trong trường outputQuantityList (tùy thuộc vào loại sự kiện) hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “hợp” được quy định trong 8.2.7.1.1.
MATCH_anyEPCCIass	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường quantityList, childQuantityList, inputQuantityList hoặc outputQuantityList (có nghĩa là, ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent hoặc các loại sự kiện mở rộng, mở rộng một trong bốn); và (b) một trong các tầng EPC được liệt kê trong bất kì trường nào trong số các trường đó hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Kết quả cũng sẽ bao gồm QuantityEvents có trường epcClass hợp với một trong các dạng EPC hoặc URI được quy định trong tham số này. Ý nghĩa của “matches” được quy định trong 8.2.7.1.1.
EQ_quantity	int	(DEPCRECATED trong EPCIS 1.1) Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường số lượng (nghĩa là QuantityEvents hoặc loại sự kiện mở rộng, mở rộng QuantityEvent); và ở đây (b) trường số lượng bằng với tham số quy định.
GT_quantity	int	(DEPCRECATED trong EPCIS 1.1) Giống như EQ_quantity, nhưng bao gồm các sự kiện có trường số lượng lớn hơn tham số quy định.
GE_quantity	int	DEPCRECATED trong EPCIS 1.1) Giống như EQ_quantity, nhưng bao gồm các sự kiện có trường số lượng lớn hơn hoặc bằng tham số quy định.
LT_quantity	int	(DEPCRECATED trong EPCIS 1.1) Giống như EQ_quantity, nhưng bao gồm các sự kiện có trường số lượng nhỏ hơn tham số quy định.
LE_quantity	int	(DEPCRECATED trong EPCIS 1.1) Giống như EQ_quantity, nhưng bao gồm các sự kiện có trường số lượng nhỏ hơn hoặc bằng tham số quy định.
EQ_fieldname	Danh sách chuỗi	Đây không là tham số duy nhất, mà là một họ tham số. Nếu một tham số của biểu này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường mở rộng cấp độ- cao nhất có tên fieldname, loại của nó, hoặc là chuỗi hoặc là loại từ vựng; và trong đó (b) giá trị của trường đó hợp với một trong các giá trị được quy định trong tham số này. Fieldname là tên đủ điều kiện của trường mở rộng cấp độ- cao nhất. Tên của một trường mở rộng là một qname XML; có nghĩa là, một cặp bao gồm một URI tên miền XML và một cái tên. Tên của tham số truy vấn tương ứng được xây dựng bằng cách nối các phần sau: chuỗi EQ_, URI tên miền cho trường mở rộng, dấu thăng (#) và tên của trường mở rộng. “Cấp độ- cao nhất” có nghĩa là thành phần mở rộng phù hợp phải là con trực hệ của sự kiện EPCIS chứa, không phải là thành phần được lồng trong thành phần mở rộng sự kiện cấp độ- cao nhất. Xem EQ_INNER_fieldname để truy vấn các thành phần mở rộng bên trong.
EQ_fieldname	Int Float Thời gian	Giống như EQ_fieldname như mô tả ở trên, nhưng có thể được áp dụng cho một trường kiểu Int, Float hoặc Time. Kết quả sẽ bao gồm các sự kiện (a) có một trường có tên fieldname; và (b) loại trường hợp với loại tham số này (Int, Float hoặc Time); và ở đây (c) giá trị của trường lớn hơn giá trị được định. fieldname là + onstLu + ted là foL
GT_fieldname	Int Float Thời gian	Giống như EQ_fieldname được mô tả ở trên, nhưng có thể được áp dụng cho một trường kiểu Int, Float hoặc Time. Kết quả sẽ bao gồm các sự kiện (a) có một trường có tên fieldname; và (b) loại trường hợp với loại tham số này (Int, Float hoặc Time); và trong đó (c) giá trị của trường bằng giá trị chỉ định. Tên trường là + onstLu + ted là foL EQ_fieldname.
GE_fieldname LT_fieldname LE_fieldname	Int Float Thời gian	Tương tự như GT_fieldname
EQ_ILMD_fieldname	Danh sách chuỗi	Tương tự như EQ_fieldname, nhưng hợp với các sự kiện có vùng ILMD (7.3.6) chứa trường cấp cao nhất có tên trường được quy định có giá trị hợp với một trong các giá trị quy định. “Cấp cao nhất” có nghĩa là thành phần ILMD phù hợp phải là thành phần con trực hệ của thành phần <ilmd>, không phải là thành phần được lồng trong thành phần như vậy. Xem EQ_INNER_ILMD_fieldname để truy vấn các thành phần mở rộng bên trong.
EQ_ILMD _fieldname GT_ILMD_fieldname GE_ILMD_fieldname LT_ILMD_fieldname LE_lLMD_fieldname	Int Float Thời gian	Tương tự như EQ_fieldname, GT_fieldname, GE_fieldname, GE_fieldname, LT_fieldname và LE_fieldname, tương ứng, nhưng hợp với các sự kiện có vùng ILMD (7.3.6) chứa trường có tên trường quy định có giá trị nguyên, float hoặc giá trị thời gian phù hợp với giá trị được quy định theo toán tử quan hệ được quy định.
EQ_lNNER_fieldname	Danh sách chuỗi	Tương tự như EQ_fieldname, nhưng khớp với các phần tử mở rộng bên trong; có nghĩa là, bất kì phần tử XML nào được lồng vào bất kì cấp nào trong phần tử mở rộng cấp cao nhất. Lưu ý rằng một phần tử bên trong phù hợp có thể tồn tại trong nhiều hơn một phần tử cấp cao nhất hoặc có thể xảy ra nhiều lần trong một phần tử cấp cao nhất; tham số này phù hợp nếu ít nhất một lần xuất hiện trùng khớp được tìm thấy ở bất kì đâu trong sự kiện (ngoại trừ ở cấp cao nhất). Lưu ý rằng không giống như phần tử mở rộng cấp cao nhất, phần tử mở rộng bên trong có thể có một không gian tên XML trống. Để khớp với phần tử bên trong như vậy, chuỗi rỗng được sử dụng thay cho không gian tên XML khi xây dựng tên tham số truy vấn. Ví dụ, để so khớp phần tử bên trong <elt1> với không có vùng tên XML, tham số truy vấn sẽ là EQ_INNER_ # elt1.
EQ_INNER_fieldname GT_INNER_fieldname GE_lNNER_fieldname LT_INNER_fieldname LE_INNER_fieldname	Int Float Thời gian	Giống như EQ_INNER_fieldname như được mô tả ở trên, nhưng có thể được áp dụng cho trường loại Int, Float hoặc Time.
EQ_INNER_ILMD_fieldname	Danh sách chuỗi	Tương tự EQ_ILMD_fieldname, nhưng hợp với các thành phần HMD bên trong; tức là, bất kì thành phần XML nào được lồng vào bất kì cấp độ nào trong thành phần ILMD cấp độ cao nhất. Lưu ý rằng thành phần bên trong phù hợp có thể tồn tại trong nhiều hơn một thành phần cấp độ cao nhất hoặc có thể xảy ra nhiều lần trong thành phần cấp độ cao nhất; tham số này phù hợp nếu có ít nhất một lần xuất hiện trùng hợp được tìm thấy ở bất kì đâu trong phần ILMD (ngoại trừ ở cấp độ cao nhất).
EQ_INNER_ILMD_fieldname GT_INNER_ILMD_fieldname GE_INNER_ILMD_fieldname LT_INNER_ILMD_fieldname LE_INNER_ILMD_fieldname	Int Float Thời gian	Giống như EQ_INNER_ILMD_fieldname như mô tả ở trên, nhưng có thể được áp dụng cho một trường loại Int, Float hoặc Time.
EXISTS_fieldname	Bỏ trống	Giống như EQ_fieldname như mô tả ở trên, nhưng có thể được áp dụng cho trường thuộc bất kì loại nào (bao gồm các loại phức tạp). Kết quả sẽ bao gồm các sự kiện có một trường không có tên là fieldname. Tên trường là + onstLu + ted dưới dạng foL EQ_fieldname. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua.
EXISTS_INNER_fieldname	Bỏ trống	Giống như EXISTS_fieldname như mô tả ở trên, nhưng bao gồm các sự kiện có trường mở rộng bên trong không trống có tên fieldname. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua.
EXISTS_ILMD_fieldname	Bỏ trống	Giống như EXISTS_fieldname như mô tả ở trên, nhưng các sự kiện có trường không có tên là fieldname trong vùng ILMD (7.3.6). Tên trường là + onstLu + ted dưới dạng foL EQ_ILMD_fieldname. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua.
EXISTS_INNER_ILMD_fieldname	Bỏ trống	Giống như EXISTS_ILMD_fieldname như mô tả ở trên, nhưng bao gồm các sự kiện có trường mở rộng bên trong không trống có tên là fieldname trong vùng ILMD. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua.
HASATTR_fieldname	Danh sách chuỗi	Đây không phải là một tham số duy nhất, mà là một họ các tham số. Nếu tham số của dạng này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường mang tên fieldname, có loại là loại từ vựng; và (b) trong đó giá trị của trường đó là thành phần từ vựng có sẵn dữ liệu chủ; và (c) dữ liệu chủ có thuộc tính non-null có tên trùng hợp với một trong các giá trị được quy định trong tham số này. Fieldname là tên đầy đủ của một trường. Đối với trường chuẩn, đây chỉ đơn giản là tên trường; ví dụ: bizLocation. Đối với một trường mở rộng, tên của trường mở rộng là một tên qq XML; có nghĩa là, một cặp bao gồm một URI mang tên miền XML và một cái tên nào đó. Tên của tham số truy vấn tương ứng được xây dựng bằng cách nối chuỗi sau: chuỗi HASATTR_, URI mang tên miền đối với trường mở rộng, dấu thăng (#) và tên của trường mở rộng.
EQATTR_fieldname_attrname	Danh sách chuỗi	Đây không phải là một tham số duy nhất, mà là một họ tham số. Nếu một tham số của biểu này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có một trường có tên fieldname thuộc loại là loại từ vựng; và (b) trong đó giá trị của trường đó là thành phần từ vựng có sẵn dữ liệu chủ; và (c) dữ liệu chủ có thuộc tính non-null tên attrname; và (d) trong đó giá trị của thuộc tính đó khớp với một trong các giá trị được quy định trong tham số này. Fieldname được xây dựng như cho HASATTR_fieldname. Việc thực hiện CÓ THỂ thiết lập QueryParameterException nếu fieldname hoặc attrname bao gồm kí tự gạch dưới. Giải thích (không quy định): bởi vì sự có mặt của dấu gạch dưới trong tên trường hoặc tên hiển thị thể hiện sự mơ hồ về việc phân chia giữa tên trường và tên người nhận, việc triển khai thực hiện tự do từ chối tham số truy vấn nếu nó không thể phân biệt.
EQ_eventID	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) có trường không có giá trị eventID; và trong đó (b) trường eventID bằng một trong các giá trị quy định trong tham số này. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể giá trị của trường eventID hoặc liệu trường eventID có tồn tại không.
EXISTS_errorDeclaration	Bỏ trống	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện có chứa ErrorDeclaration. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể chúng có chứa ErrorDeclaration hay không.
GE_errorDeclaration Time	Thời gian	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) chứa một ErrorDeclaration; và trong đó (b) giá trị của trường errorDeclarationTime lớn hơn hoặc bằng giá trị quy định. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể chúng có chứa ErrorDeclaration hay giá trị của trường errorDeclarationTime.
LT_errorDeclaration Time	Thời gian	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) chứa một ErrorDeclaration; và trong đó (b) giá trị của trường errorDeclarationTime nhỏ hơn giá trị quy định. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể chúng có chứa ErrorDeclaration hay giá trị của trường errorDeclarationTime.
EQ_errorReason	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) chứa một ErrorDeclaratiòn; và trong đó b) khai báo lỗi có chứa trường lý do non-null; và trong đó (c) trường lý do bằng một trong các giá trị quy định trong tham số này. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể chúng có chứa ErrorDeclaration hay giá trị của trường lý do nào.
EQ_correctiveEventID	Danh sách chuỗi	Nếu tham số này được quy định, kết quả sẽ chỉ bao gồm các sự kiện (a) chứa một ErrorDeclaration; và (b) một trong các thành phần của danh sách correctiveEventIDs bằng một trong các giá trị quy định trong tham số này. Nếu tham số này bị bỏ qua, các sự kiện được trả về bất kể chúng có chứa ErrorDeclaration hoặc nội dung của danh sách correctiveEventIDs hay không.
EQ_ERROR_DECLARATION_fieldname	Danh sách chuỗi	Tương tự như EQ_fieldname, nhưng khớp với các sự kiện có chứa ErrorDeclaration và nơi ErrorDeclaration chứa một trượng có tên trường được quy định có giá trị khớp với một trong các giá trị quy định.
EQ_ERROR_DECLARATION_fieldname GT_ERROR_DECLARATION_fieldname GE_ERROR_DECLARATION_Fieldname LT_ERROR_DECLARATION_Fieldname LE_ERROR_DECLARATION_fieldname	Int Float Thời gian	Tương tự như EQ_fieldname, GT_fieldname, GE_fieldname, GE_fieldname, LT_fieldname và LE_fieldname, tương ứng, nhưng khớp với các sự kiện có chứa ErrorDeclaration và vị trí ErrorDeclaration chứa trường fieldname quy định mà các giá trị nguyên, trôi nổi/float hoặc giá trị thời gian khớp với giá trị quy định theo cơ cấu điều hành liên quan quy định.
EQ_INNER_ERROR_DECLARATION_fieldname	Danh sách chuỗi	Tương tự như EQ_ERROR_DECLARATION_fieldname, nhưng khớp với các thành phần mở rộng bên trong; nghĩa là bất kì thành phần XML nào được lồng trong thành phần mở rộng cấp độ-cao nhất. Lưu ý rằng thành phần bên trong phù hợp có thể tồn tại trong nhiều hơn một thành phần cấp độ- cao nhất hoặc có thể xảy ra nhiều lần trong thành phần cấp độ- cao nhất; tham số này khớp với nhau nếu có ít nhất một lần xuất hiện trùng khớp được tìm thấy ở bất kì đâu trong sự kiện (ngoại trừ ở cấp độ- cao nhất) …
EQ_INNER_ERROR_DECLARATION_fieldname GT_INNER_ERROR_DECLARATION_fieldname GE_INNER_ERROR_DECLARATION_fieldname LT_INNER_ERROR_DECLARATION_fieldname LE_INNER_ERROR_DECLARATION_fieldname	Int Float Thời gian	Giống như EQ_INNER_ERROR_DECLARATION_fieldname như mô tả ở trên, nhưng có thể được áp dụng cho trường loại Int, Float hoặc Time.
EXISTS_ERROR_DECLARATION_fieldname	Bỏ trống	Giống như EXISTS_fieldname như mô tả ở trên, nhưng các sự kiện có khai báo lỗi chứa một trường mở rộng không có tên là fieldname. Tên trường là + onstLu + ted dưới dạng foL EQ_ERROR_DECLARATION_fieldname. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua
EXISTS_INNER_ERROR_DECLARATION_fieldname	Bỏ trống	Giống như EXISTS_ERROR_DECLARATION_fieldname như mô tả ở trên, nhưng bao gồm các sự kiện có khai báo lỗi chứa trường mở rộng bên trong không trống có tên là fieldname. Lưu ý rằng giá trị cho tham số truy vấn này bị bỏ qua.
orderBy	chuỗi	Nếu có quy định, hãy đặt tên một trường trường này sẽ được sử dụng để sắp xếp thứ tự các kết quả. Trường orderDirection quy định thứ tự nào nằm trong chuỗi tăng dần hoặc chuỗi giảm dần. Các sự kiện được bao gồm trong kết quả thiếu trường được quy định hoàn toàn có thể xảy ra ở bất kì vị trí nào trong danh sách sự kiện kết quả. Giá trị của tham số này PHẢI là một trong: eventTime, recordTime hoặc tên đầy đủ của một trường mở rộng thuộc loại Int, Float, Time hoặc String. Một fieldname đủ điều kiện được xây dựng như đối với tham số EQ_fieldname. Trong trường hợp của một trường loại String, thứ tự NÊN theo thứ tự từ vựng dựa trên mã hóa Unicode của các chuỗi, hoặc trong một số chuỗi đối chiếu khác phù hợp với ngôn ngữ. Nếu bỏ qua, không có thứ tự nào được quy định. Việc thực hiện CÓ THỂ ra lệnh cho các kết quả theo bất kì thứ tự nào mà nó chọn, và thứ tự đó có THỂ khác nhau ngay cả khi cùng một truy vấn được thực thi hai lần trên cùng một dữ liệu. (Trong EPCIS 1.0, số lượng giá trị cũng được cho phép, nhưng việc sử dụng nó không được chấp nhận trong EPCIS 1.1.)
orderDirection	chuỗi	Nếu có quy định và orderBy cũng được quy định, thi xác định xem các kết quả được sắp xếp theo thứ tự tăng dần hay giảm dần theo vấn đề chính được quy định bởi orderBy. Giá trị của tham số này phải là một trong số ASC (cho thứ tự tăng dần) hoặc DESC (cho thứ tự giảm dần); nếu không, việc thực hiện PHẢI đưa ra QueryParameterException. Nếu bỏ qua, mặc định là DESC.
eventCountLimit	int	Nếu có quy định, kết quả sẽ chỉ bao gồm các sự kiện N đầu tiên phù hợp với các tiêu chí khác, trong đó N là giá trị của tham số này. Thứ tự được xác định bởi các tham số orderBy và orderDirection xác định ý nghĩa của “đầu tiên” cho mục đích này. Nếu bỏ qua, tất cả sự kiện phù hợp với tiêu chí được quy định sẽ được đưa vào kết quả. Tham số này và maxEventCount loại trừ lẫn nhau; nếu cả hai được quy định, một QueryParameterException PHẢI được thiết lập. Tham số này chỉ có thể được sử dụng khi orderBy được quy định; nếu orderBy bị bỏ qua và eventCountLimit được quy định, một QueryParameterException PHẢI được thiết lập. Tham số này khác với maxEventCount trong đó tham số này giới hạn số lượng dữ liệu được trả về, trong khi maxEventCount gây ra một ngoại lệ được bỏ đi nếu giới hạn bị vượt quá. Giải thích (không quy định): Việc sử dụng phổ biến các tham số orderBy, orderDirection và eventCountLimit dành cho các truy vấn cực trị. Ví dụ, để chọn sự kiện gần đây nhất phù hợp với một số tiêu chí, truy vấn sẽ bao gồm các tham số, chọn các sự kiện phù hợp với tiêu chí mong muốn và đặt orderBy thành eventTime, orderDirection thành DESC và eventCountLimit thành chính nó.
maxEventCount	int	Nếu được quy định, tối đa lượng sự kiện trong trường hợp này sẽ được đưa vào kết quả truy vấn. Nếu không truy vấn sẽ trả về nhiều hơn số lượng sự kiện này, một QueryTooLargeException PHẢI được nâng lên thay vì kết quả truy vấn thông thường. Tham số này và eventCountLimit loại trừ lẫn nhau; nếu cả hai được quy định, QueryParameterException PHẢI được nâng lên. Nếu tham số này bị bỏ qua, bất kì số lượng sự kiện nào có thể được đưa vào kết quả truy vấn. Tuy nhiên, lưu ý rằng việc triển khai EPCIS là miễn phí để nâng cao QueryTooLargeException bất kể cài đặt của tham số này (8.2.3).

Như mô tả gợi ý ở trên, nếu nhiều tham số được quy định, sự kiện phải đáp ứng tất cả các tiêu chí để đưa vào tập kết quả. Nói cách khác, nếu mỗi tham số được coi là thuộc tính (predicate), tất cả các thuộc tính như vậy được ngầm liên đới như một toán tử AND. Ví dụ, nếu một cuộc gọi đến để thăm dò xác định giá trị cho cả tham số EQ_bizStep và EQ_disposition, thì sự kiện phải khớp với một trong các giá trị bizStep được quy định và khớp với một trong các giá trị disposition được quy định để đưa vào kết quả.

Mặt khác, đối với các tham số có giá trị là một danh sách, sự kiện phải khớp với ít nhất một trong các thành phần của danh sách để đưa vào tập kết quả. Nói cách khác, nếu mỗi phần tử của danh sách được coi là một thuộc tính, tất cả các thuộc tính như vậy đối với một danh sách đã cho sẽ được loại bỏ hoàn toàn như một toán tử (operator) OR. Ví dụ, nếu giá trị của tham số EQ_bizStep là một danh sách gồm hai thành phần (“bs1”, “bs2”), thì một sự kiện được đưa vào nếu trường bizStep của nó chứa giá trị bs1 HOẶC trường bizStep của nó chứa giá trị bs2.

Một ví dụ khác, nếu giá trị của tham số EQ_bizStep là một danh sách gồm hai thành phần (“bs1”, “bs2”) và tham số EQ_disposition là một danh sách gồm hai thành phần (“d1”, “d2”) thì kế quả gồm các sự kiện thỏa mãn a predicate sau:

((bizStep = “bs1″ OR bizStep = “bs2”)

AND (bố trí = “d1” HOẶC bố cục = “d2”))

8.2.7.1.1  Xử lý các tham số truy vấn MATCH

Danh sách tham số cho MATCH_epc, MATCH_parentID, MATCH_inputEPC, MATCH_outputEPC và MATCH_anyEPC SHALL được xử lý như sau. Mỗi thành phần của danh sách tham số có thể là một mẫu phận định thuần túy như quy định trong [TDS1.9] hoặc bất kì URI nào khác. Nếu thành phần là một mẫu phân định thuần túy, nó được so khớp với các giá trị trường sự kiện bằng cách sử dụng quy trình cho phù hợp với các mẫu phân định được quy định trong [TDS1.9, điều 8]. Nếu thành phần là bất kì URI nào khác, nó được so khớp với các giá trị trường sự kiện bằng cách kiểm tra chuỗi bình đẳng.

Danh sách tham số cho MATCH_epcClass, MATCH_inputEPCCIass, MATCH_outputEPCCIass và MATCH_anyEPCCIass PHẢI được xử lý như sau. Gọi P là một trong các mẫu được quy định trong giá trị cho tham số này và để C là giá trị của trường epcClass trong danh sách số lượng thích hợp của sự kiện đang được xem xét để đưa vào kết quả. Sau đó, sự kiện được bao gồm nếu mỗi thành phần Pi của P khớp với thành phần tương ứng Ci của C, trong đó “khớp”” được định nghĩa trong [TDS1.9, Điều 8].

Không quy định: Giải thích: Sự khác biệt giữa MATCH_epcClass và MATCH_epc, và các tham số tương tự chính là, đối với MATCH_epcClass giá trị trong sự kiện (trường epcClass trong danh sách số lượng) có thể là mẫu, như được chỉ rõ trong 7.3.3.3). Điều này có nghĩa là giá trị trong sự kiện có thể chứa thành phần ‘*’. Quy định kĩ thuật ở trên cho biết rằng ‘*’ trong trường EPCCIass của sự kiện chỉ được khớp với dấu ‘*’ trong thông số truy vấn. Ví dụ: nếu trường epcClass trong một sự kiện là urn: epc: idpat: sgtin: 0614141.112345. *, Thì sự kiện này sẽ khớp bởi thông số truy vấn urn: epc: idpat: sgtin: 0614141. *.* Hoặc bởi urn: epc: idpat: sgtin: 0614141.112345. *, nhưng không phải bởi urn: epc: idpat: sgtin: 0614141.112345.400.

8.2.7.2  SimpleMasterDataQuery

Truy vấn này được gọi bằng cách quy định chuỗi SimpleMasterDataQuery làm đối số queryName cho cuộc thăm dò. Kết quả là một cá thể QueryResults có thành phần từ vựng (có thể trống) cùng với các thuộc tính đã chọn.

SimpleMasterDataQuery PHẢI có sẵn thông qua cuộc thăm dò ý kiến nhưng không qua đăng ký; đó là, một thực hiện PHẢI tạo ra SubscribeNotPermittedException khi SimpleMasterDataQuery được quy định làm đối số queryName để đăng kí.

Các tham số cho truy vấn này như sau:

Bảng 32 – Các tham số cho truy vấn SimpleMasterDataQuery

Tên các tham số	Loại giá trị của tham số	Yêu cầu	Ý nghĩa
vocabularyName	Danh sách chuỗi	Không	Nếu có chỉ định, chỉ các phần tử từ vựng được rút ra từ một trong các từ vựng được quy định sẽ được đưa vào kết quả. Mỗi thành phần của danh sách được quy định là tên URI chính thức cho một từ vựng; ví dụ: một trong các URI được quy định trong bảng ở cuối 7.2. Nếu bỏ qua, tất cả các từ vựng sẽ được xem xét.
includeAttributes	boolean	Có	Nếu đúng, kết quả sẽ gồm tên, giá trị thuộc tính đối với các thành phần từ vựng phù hợp. Nếu sai, tên và giá trị thuộc tính sẽ không được đưa vào kết quả.
includeChildren	boolean	Có	Nếu đúng, kết quả sẽ bao gồm danh sách trẻ em đối với các yếu tố từ vựng phù hợp. Nếu sai, danh sách trẻ em sẽ không được đưa vào trong kết quả.
attributeNames	Danh sách chuỗi	Không	Nếu có quy định, chỉ những thuộc tính có tên khớp với một trong các tên được quy định sẽ được đưa vào trong kết quả. Nếu bỏ qua, tất cả các thuộc tính đối với từng thành phần từ vựng phù hợp sẽ được bao gồm. (Để có được danh sách các tên thành phần từ vựng không có thuộc tính, hãy quy định sai lỗi đối với includeAttributes.) Giá trị của tham số này PHẢI bỏ qua nếu includeAttributes là sai. Lưu ý rằng tham số này không ảnh hưởng đến yếu tố từ vựng nào được đưa vào trong kết quả; nó chỉ giới hạn các thuộc tính nào sẽ được đưa vào trong mỗi thành phần từ vựng.
EQ_name	Danh sách chuỗi	Không	Nếu có quy định, kết quả sẽ chỉ gồm các thành phần từ vựng có tên bằng một trong các giá trị được quy định. Nếu tham số này và WD_name đều bị bỏ qua, các yếu tố từ vựng đều được đưa vào bất kể tên của chúng.
WD_name	Danh sách chuỗi	Không	Nếu có quy định, kết quả sẽ chỉ bao gồm các thành phần từ vựng khớp với một trong các tên được quy định hoặc là con cháu trực tiếp hoặc gián tiếp của thành phần từ vựng khớp với một trong các tên được quy định. Ý nghĩa của “con cháu trực tiếp hoặc gián tiếp” được mô tả trong 6.5. (WD là tên viết tắt của “với con cháu.”) Nếu tham số này và EQ_name đều bị bỏ qua, các yếu tố từ vựng được đưa vào bất kể tên của chúng.
HASATTR	Danh sách chuỗi	Không	Nếu có quy định, kết quả sẽ chỉ bao gồm các thành phần từ vựng có thuộc tính non-null có tên khớp với một trong các giá trị được quy định trong tham số này.
EQATTR_attrname	Danh sách chuỗi	Không	Đây không phải là một tham số duy nhất, mà là một họ các tham số. Nếu một tham số của dạng này được quy định, kết quả sẽ chỉ bao gồm các thành phần từ vựng có thuộc tính non-null có tên attrname và giá trị của thuộc tính đó khớp với một trong các giá trị quy định trong tham số này.
maxElementCount	Int	Không	Nếu có quy định, tối đa số yếu tố từ vựng này sẽ được đưa vào kết quả truy vấn. Nếu không truy vấn sẽ trả về nhiều hơn số lượng các thành phần từ vựng này, một QueryTooLargeException PHẢI được tạo ra thay vì kết quả truy vấn thông thường. Nếu tham số này bị bỏ qua, bất kì số lượng yếu tố từ vựng nào đều có thể được đưa vào trong kết quả truy vấn. Tuy nhiên, lưu ý rằng việc triển khai EPCIS là miễn phí để tạo ra QueryTooLargeException bất kể việc cài đặt của tham số này (xem 8.2.3).

Như mô tả gợi ý ở trên, nếu nhiều tham số được quy định, sự kiện phải đáp ứng tất cả các tiêu chí đề đưa vào tập kết quả. Nói cách khác, nếu mỗi tham số được coi là thuộc tính, tất cả các thuộc tính như vậy được ngầm liên đới như một toán tử AND. Ví dụ, nếu một cuộc gọi đến để thăm dò xác định giá trị cho cả tham số WD_name và HASATTR, thì thành phần từ vựng phải là hậu duệ của thành phần được quy định VÀ có một trong các thuộc tính được quy định để được đưa vào kết quả.

Mặt khác, đối với các tham số có giá trị là danh sách, thành phần từ vựng phải khớp với ít nhất một trong các thành phần của danh sách để được đưa vào trong tập kết quả. Nói cách khác, nếu mỗi thành phần của danh sách được coi là một thuộc tính, tất cả các thuộc tính như vậy đối với một danh sách đã cho sẽ được loại bỏ hoàn toàn như một toán tử OR. Ví dụ, nếu giá trị của tham số EQATTR_sample là một danh sách gồm hai thành phần “s1”, “s2”), thì thành phần từ vựng được đưa vào nếu nó có thuộc tính mẫu có giá trị bằng s1 HOẶC bằng s2.

Một ví dụ khác, nếu giá trị của tham số EQ_name là một danh sách gồm hai thành phần (“ve1”, “ve2”) và tham số EQATTR_sample là một danh sách gồm hai thành phần (“s1”, “s2”), thì kết quả sẽ bao gồm các sự kiện thỏa mãn thuộc tính sau:

((tên = “ve1” HOẶC tên = “ve2”)

VÀ (mẫu = “s1” HOẶC mẫu = “s2”))

trong đó tên không chính thức đề cập đến tên của thành phần từ vựng và mẫu không chính thức đề cập đến giá trị của thuộc tính mẫu.

8.2.8  Giao diện gọi lại truy vấn

Giao diện gọi lại truy vấn là đường dẫn mà dịch vụ EPCIS cung cấp các kết quả truy vấn thường trực cho khách hàng.

Mỗi khi dịch vụ EPCIS thực hiện truy vấn thường trực theo QuerySchedule, nó PHẢI cố gắng phân phối kết quả cho người đăng kí bằng cách gọi một trong ba phương thức của Giao diện gọi lại truy vấn. Nếu truy vấn được thực hiện bình thường, dịch vụ EPCIS sẽ gọi bằng phương thức callbackResults. Nếu truy vấn dẫn đến QueryTooLargeException hoặc ImplementationException, dịch vụ EPCIS sẽ gọi bằng phương thức tương ứng của Giao diện gọi lại truy vấn.

Lưu ý rằng “ngoại lệ” trong Giao diện gọi lại truy vấn không phải là ngoại lệ theo nghĩa thông thường của ngoại lệ API, vì chúng không được nêu ra như là kết quả của một khách hàng gọi phương thức. Thay vào đó, ngoại lệ được gửi đến người nhận theo cách tương tự với kết quả bình thường, như một đối số cho một phương thức giao diện.

9  Các ràng buộc XML đối với các môđune xác định/định nghĩa dữ liệu

Phần này quy định ràng buộc XML tiêu chuẩn đối với các môđune xác định/định nghĩa dữ liệu loại sự kiện cốt lõi, sử dụng ngôn ngữ lược đồ XML W3C [XSD1, XSD2], Các mẫu cũng được hiển thị.

Lược đồ dưới đây tuân theo các quy tắc thiết kế lược đồ chuẩn GS1. Lược đồ dưới đây theo lược đồ cơ sở tiêu chuẩn EPCglobal, theo quy định của các quy tác thiết kế [XMLDR].

9.1  Cơ chế mở rộng

Lược đồ XML trong phần này thực hiện << điểm mở rộng >> được đưa ra trong UML ở điều 6 bằng cách sử dụng một phương pháp được mô tả trong [XMLVersioning]. Phương pháp này cung cấp cho cả tiện ích mở rộng của nhà cung cấp / người dùng và mở rộng bởi GS1 trong các phiên bản tương lai của tiêu chuẩn này hoặc trong các phần số bổ sung. Các phần mở rộng được giới thiệu thông qua cơ chế này sẽ tương thích ngược, trong các tài liệu phù hợp với các phiên bản cũ hơn của lược đồ cũng sẽ phù hợp với các phiên bản mới hơn của lược đồ chuẩn và lược đồ chứa các phần mở rộng dành riêng cho nhà cung cấp.

Các tiện ích mở rộng cũng sẽ tương thích trong tương lai, trong các tài liệu chứa tiện ích mở rộng của nhà cung cấp / người dùng hoặc tuân theo các phiên bản mới hơn của lược đồ chuẩn cũng sẽ phù hợp với các phiên bản cũ hơn của lược đồ.

Khi một tài liệu chứa các phần mở rộng (nhà cung cấp / người dùng cụ thể hoặc được tiêu chuẩn hóa trong các phiên bản lược đồ mới hơn), nó có thể phù hợp với nhiều hơn một lược đồ. Ví dụ, một tài liệu chứa các mở rộng của nhà cung cấp cho lược đồ GS1 Phiên bản 1.0 sẽ phù hợp với cả lược đồ GS1 Phiên bản 1.0 và lược đồ cụ thể của nhà cung cấp bao gồm các phần mở rộng của nhà cung cấp. Trong ví dụ này, khi tài liệu được phân tích cú pháp bằng lược đồ chuẩn, sẽ không có xác nhận hợp lệ các thành phần và thuộc tính mở rộng, nhưng khi tài liệu được phân tích bằng lược đồ dành riêng cho nhà cung cấp thì các phần mở rộng sẽ được xác nhận hợp lệ. Tương tự, một tài liệu chứa các tính năng mới được giới thiệu trong lược đồ GS1 phiên bản 1.2 sẽ phù hợp với lược đồ GS1 Phiên bản 1.0, lược đồ GS1 phiên bản 1.1 và lược đồ GS1 phiên bản 1.2, nhưng tính xác thực của các tính năng mới sẽ chỉ có sẵn khi sử dụng lược đồ của Phiên bản 1.2.

Các quy tắc thiết kế cho mẫu mở rộng này được đưa ra trong [XMLVersioning]. Tóm lại, nó tính theo các quy tắc sau:

– Đối với mỗi loại trong đó << điểm mở rộng >> xảy ra, bao gồm công bố xsd: anyAttribute. Công bố này cung cấp cho việc bổ sung các thuộc tính XML mới, hoặc trong các phiên bản tiếp theo của lược đồ chuẩn hoặc trong lược đồ nhà cung cấp / người dùng cụ thể.

– Đối với mỗi loại trong đó << điểm mở rộng >> xảy ra, bao gồm thành phần tùy chọn (minOccurs = 0) có tên là phần mở rộng. Loại được công bố cho thành phần mở rộng sẽ luôn như sau:

Công bố này cung cấp khả năng tương thích về sau này với các thành phần mới được đưa vào các phiên bản tiếp theo của lược đồ chuẩn.

– Đối với mỗi loại trong đó << điểm mở rộng >> xảy ra, bao gồm công bố ở phần cuối của thành phần liệt kê

<xsd: any processContents = “lax” minOccurs = “0” maxOccurs = “không bị chặn” namespace = “## other” />

Công bố này cung cấp khả năng tương thích về sau này với các phần tử mới được giới thiệu trong lược đồ nhà cung cấp / người dùng cụ thể.

Các quy tắc để thêm tiện ích mở rộng của nhà cung cấp / người dùng cụ thể vào lược đồ như sau:

– Các thuộc tính của nhà cung cấp / người dùng cụ thể có thể được thêm vào bất kì loại nào trong đó << điểm mở rộng >> xảy ra. Các thuộc tính của người bán / người dùng cụ thể KHÔNG được nằm trong vùng tên miền EPCIS của EPCglobal (urn: epcglobal: epcis: xsd: 1) cũng như trong tên miền bỏ trống. Các thuộc tính của người bán / người dùng cụ thể PHẢI nằm trong tên miền có URI tên miền có nhà cung cấp làm quyền sở hữu. (Trong phần lời của lược đồ, điều này có nghĩa là tất cả các thuộc tính của nhà cung cấp / người dùng cụ thể đều phải đủ điều kiện như dạng mẫu của chúng.) Ví dụ, URI tên miền có thể là một URL HTTP có một phần thẩm quyền là tên miền thuộc sở hữu của nhà cung cấp/ người dùng, URN có mã phân định tên miền URN được cấp cho nhà cung cấp/ người dùng bởi IANA, một URID OID có đường dẫn ban đầu là một số doanh nghiệp riêng được gán cho nhà cung cấp/ người dùng, vv Công bố thuộc tính nhà cung cấp/ người dùng cụ thể PHẢI quy định use = “optional”.

– Các thành phần của nhà cung cấp / người dùng cụ thể có thể được thêm vào bất kì loại nào trong đó << điểm mở rộng >> xảy ra. Các thành phần của nhà cung cấp / người dùng cụ thể KHÔNG được nằm trong vùng tên EPCIS EPCIS (um: epcglobal: epcis: xsd: 1) cũng như trong tên miền bỏ trống. Các thành phần của nhà cung cấp / người dùng cụ thể PHẢI nằm trong tên miền có URI tên miền có nhà cung cấp / người dùng làm chủ sở hữu (như được mô tả ở trên). (Trong phần lời của lược đồ, điều này có nghĩa là tất cả các thành phần của nhà cung cấp / người dùng cụ thể đều phải đủ điều kiện như dạng mẫu của chúng.)

Để tạo một lược đồ chứa các phần mở rộng của nhà cung cấp / người dùng, hãy thay thế công bố <xsd: any… namespace = ”## other” /> bằng tham chiếu nhóm nội dung tới một nhóm được định nghĩa trong tên miền của nhà cung cấp / người dùng; ví dụ: <xsd: group ref = “vendor: VendorExtension”>.

Trong tệp lược đồ xác định các thành phần cho tên miền của nhà cung cấp / người dùng, hãy định nghĩa một nhóm nội dung bằng cách sử dụng một công bố dưới dạng mẫu sau:

Các định nghĩa hoặc tham chiếu đến các thành phần của nhà cung cấp sẽ xuất hiện ở đây. Mỗi định nghĩa PHẢI quy định minOccurs = “0”.

(Trong các hình minh họa nêu trên, nhà cung cấp và VendorExtension có thể là bất kì chuỗi nào mà nhà cung cấp / người dùng chọn.)

Không quy định: Giải thích: Vì các thành phần của nhà cung cấp / người dùng cụ thể phải là tùy chọn, bao gồm tham chiếu đến các định nghĩa của chúng trực tiếp vào lược đồ EPCIS sẽ vi phạm ràng buộc phân bổ thành phần tử của Lược đồ XML duy nhất, bởi vì thành phần <xsd: any…> trong lược đồ EPCIS cũng có thể khớp với các thành phần của nhà cung cấp / người dùng cụ thể. Di chuyển <xsd: any…> vào lược đồ của nhà cung cấp / người dùng tránh được vấn đề này, vì ## khác trong lược đồ đó có nghĩa là “Khớp một thành phần có tên miền khác với tên miền của nhà cung cấp / người dùng.”Điều này không xung đột với các thành phần tiêu chuẩn, bởi vì dạng thành phần mặc định cho lược đồ EPCIS chuẩn không đủ điều kiện tiêu chuẩn, và do đó ## khác trong lược đồ của nhà cung cấp / người dùng không phù hợp với các thành phần EPCIS chuẩn.

Các quy tắc để thêm thuộc tính hoặc thành phần vào các phiên bản trong tương lai của lược đồ chuẩn GS1 như sau:

– Các thuộc tính chuẩn có thể được thêm vào bất kì loại nào trong đó << điểm mở rộng >> xuất hiện. Các thuộc tính tiêu chuẩn SALL KHÔNG ở trong bất kì vùng tên nào (tức là, S SH nằm trong vùng tên trống), và S SH KHÔNG xung đột với bất kì tên thuộc tính chuẩn hiện có nào.

– Các thành phần chuẩn có thể được thêm vào bất kì loại nào trong đó << điểm mở rộng >> xuất hiện. Các yếu tố mới được thêm vào bằng các quy tắc sau:

□ Tìm loại thành phần mở rộng bên trong nhất.

□ Thay thế công bố <xsd: any… namespace = “## local” /> bằng (a) các thành phần mới (KHÔNG được ở trong bất kì tên miền nào; tương đương, PHẢI nằm trong tên miền bỏ trống); tiếp theo là (b) thành phần mở rộng mới có loại được xây dựng như được mô tả trước đây. Trong các phiên bản tiếp theo của lược đồ chuẩn, các thành phần chuẩn mới sẽ được thêm vào trong thành phần mở rộng mới này chứ không phải trong thành phần này.

Không quy định: Giải thích: lý do các thuộc tính và các thành phần tiêu chuẩn mới được quy định ở trên không nằm trong bất kì tên miền nào là để nhất quán với thuộc tính và thành phần của lược đồ EPCIS mặc định không đủ điều kiện.

Khi được áp dụng cho lược đồ XML EPCIS 1.2 cho các sự kiện cốt lõi (9.5), điều này dẫn đến:

Các loại sự kiện được xác định trong EPCIS 1.0 xuất hiện trong thành phần tử <EventList>.

Các loại sự kiện được xác định trong EPCIS 1.1 (nghĩa là, TransformationEvent) mỗi loại xuất hiện trong một <extension> trong thành phần <EventList>.

Đối với các loại sự kiện được xác định trong EPCIS 1.0, các trường mới được thêm vào trong EPCIS 1.1 xuất hiện trong thành phần <extension> theo các trường EPCIS 1.0. Nếu các trường bổ sung được thêm vào cùng một vị trí trong phiên bản tương lai của EPCIS, chúng sẽ xuất hiện trong thành phần <extension> thứ hai được lồng trong thành phần <extension> đầu tiên, sau các trường EPCIS 1.1. Các trường mới được thêm vào trong EPCIS 1.2 tại một nơi không có trường mới được thêm vào trong EPCIS 1.1 (tức là, errorDeclaration) xuất hiện trong thành phần <extension> theo sau các trường EPCIS 1.0.

Đối với các loại sự kiện được xác định trong EPCIS 1.1, không có thành phần <extension> nào vì toàn bộ loại sự kiện này là mới trong EPCIS 1.1. Nếu các trường BỔ SUNG được thêm vào trong một phiên bản tương lai của EPCIS, chúng sẽ xuất hiện trong thành phần <extension> sau các trường được xác định trong EPCIS 1.1.

Tiện ích mở rộng cấp độ – sự kiện của người bán / người dùng luôn xuất hiện ngay trước thẻ đóng cho sự kiện (tức là sau bất kì trường chuẩn nào và bất kì thành phần <extension> nào) và luôn nằm trong vùng tên XML không trống. Trong mọi trường hợp, các tiện ích mở rộng của nhà cung cấp / người dùng xuất hiện trong thành phần <extension>; thành phần <extension> được dành riêng cho các trường được xác định trong chính tiêu chuẩn EPCIS.

Xem các ví dụ ở 9.6.

9.2  Tiêu đề tài liệu kinh doanh chuẩn

Liên kết XML cho mô-đun định nghĩa dữ liệu Các loại sự kiện cốt lõi bao gồm thành phần EPCISHeader tùy chọn, có thể được các nhóm ngành sử dụng để kết hợp thông tin bổ sung cần thiết để xử lý trong ngành đó. Lược đồ lõi bao gồm “Tiêu đề tài liệu kinh doanh chuẩn” (SBDH) như được định nghĩa trong [SBDH] như là một thành phần bắt buộc của thành phần EPCISHeader. Các nhóm ngành cũng có thể yêu cầu một số loại tiêu đề khác trong thành phần EPCISHeader ngoài SBDH.

Lược đồ XSD cho Tiêu đề tài liệu kinh doanh chuẩn có thể lấy từ trang web của UN / CEFACT; xem [SBDH]. Lược đồ này được kết hợp trong tiêu chuẩn này làm tham chiếu.

Khi Tiêu đề tài liệu kinh doanh chuẩn được đưa đưa ra, các giá trị sau sẽ được sử dụng cho các thành phần của lược đồ SBDH quy định dưới đây.

Bảng 33 – Các thành phần của lược đồ SBDH

Trường SBDH (đường X)	Giá trị
HeaderVersion	1.0
DocumentIdentification/standard	EPCglobal
DocumentIdentification/TypeVersion	1.0
DocumentIdentification/Type	Như được quy định dưới đây.

Giá trị cho DocumentIdentification / Type PHẢI được thiết lập theo bảng sau, trong đó xác định một giá trị cho trường này dựa trên loại tài liệu EPCIS và ngữ cảnh mà nó được sử dụng.

Bảng 34 – Giá trị cho DocumentIdentification / Type

Loại tài liệu và bối cảnh	Giá trị cho DocumentIdentification / Type
EPCISTài liệu được sử dụng trong bất kì bối cảnh nào	Events
EPCISMasterData được sử dụng trong mọi bối cảnh	MasterData
EPCISQueryDocument được sử dụng làm bên yêu cầu liên kết trong 11.3	QueryControl-Request
EPCISQueryDocument được sử dụng làm bên đáp ứng liên kết trong 11.3	QueryControl-Response
EPCISQueryDocument được sử dụng trong bất kì liên kết XML nào của truy vấn	QueryCallback
EPCISQueryDocument được sử dụng trong bất kì bối cảnh nào	Query

Liên kết AS2 cho Giao diện kiểm soát truy vấn (11.3) cũng quy định các trường Tiêu đề Tài liệu kinh Doanh Chuẩn BỔ SUNG phải có mặt trong một cá thể EPCISQueryDocument được sử dụng như một thông điệp phản hồi của Giao diện Kiểm soát Truy vấn. Xem 11.3 để biết chi tiết.

Ngoài các trường được quy định ở trên, Tiêu đề Tài liệu kinh Doanh Chuẩn bao gồm tất cả các trường khác được yêu cầu bởi lược đồ SBDH và CÓ THỂ bao gồm các trường SBDH bổ sung. Trong mọi trường hợp, các giá trị cho các trường đó PHẢI được đặt theo [SBDH]. Một nhóm ngành công nghiệp CÓ THỂ quy định các ràng buộc bổ sung đối với các nội dung SBDH được sử dụng trong nhóm ngành đó, nhưng các ràng buộc như vậy PHẢI phù hợp với các tiêu chuẩn này.

9.3  Giản đồ cơ sở EPCglobal

Liên kết XML cho mô-đun định nghĩa dữ liệu Các loại sự kiện cốt lõi, cũng như các ràng buộc XML khác trong tiêu chuẩn này, tham chiếu đến lược đồ cơ sở EPCglobal. Giản đồ này được sao chép dưới đây.

9.4  Dữ liệu chủ trong liên kết XML

Như đã lưu ý trong 6.1.1, EPCIS cung cấp bốn cách để truyền dữ liệu chủ. Bốn cách này được hỗ trợ bởi các phần khác nhau của lược đồ XML được quy định trong phần còn lại của phần này, như được tóm tắt trong bảng sau:

Bảng 35 – Cơ chế truyền dữ liệu chủ

Cơ chế	Giản đồ Hỗ trợ
Truy vấn dữ liệu chủ	VocabularyElement trong VocabularyList, như được chứa trong epcisq: QueryResults
ILMD	Thành phần XML chứa trong thành phần ILMD
Tiêu đề tài liệu EPCIS	VocabularyElement trong VocabularyList, như được chứa trong EPCISHeader
Tài liệu dữ liệu chủ EPCIS	VocabularyElement trong VocabularyList, như được chứa trong EPCISBody trong epcismd: PCISMasterDataDocument

Mỗi thuộc tính dữ liệu chủ là một cặp tên / giá trị, trong đó phần tên là một tên đủ điều kiện bao gồm một URI tên miền và một tên cục bộ, và giá trị là bất kì loại dữ liệu nào thể hiện trong XML. Bất kể trong số bốn cơ chế ở trên được sử dụng để truyền dữ liệu chủ, dữ liệu được truyền PHẢI luôn sử dụng cùng một URI tên miền và tên địa phương cho một thuộc tính đã cho. Cách mà URI tên miền và tên địa phương được mã hóa thành XML, tuy nhiên, khác nhau tùy thuộc vào cơ chế:

– Đối với các thành phần ILMD, thuộc tính dữ liệu chủ PHẢI là thành phần XML có tên thành phần là một tên đủ điều kiện, trong đó tiền tố của tên đủ điều kiện được gắn với URI tên miền của thuộc tính dữ liệu chủ và tên địa phương của tên đủ điều kiện là tên địa phương của thuộc tính dữ liệu chủ Nội dung của thành phần PHẢI là giá trị của thuộc tính dữ liệu chủ.

– Đối với các cơ chế sử dụng VocabularyElement, thuộc tính id của thành phần VocabularyElement PHẢI là một chuỗi chứa URI tên miền, một pound (đơn vị đo lường của Anh) kí tự (#) và tên địa phương. Nội dung của thành phần VocabularyElement PHẢI là giá trị của thuộc tính dữ liệu chủ.

Không quy định: Ví dụ: Hãy xem xét thuộc tính dữ liệu chính có tên miền URI là http://epcis.example.com/ns/md, có tên vị trí là myAttrName và giá trị của nó là chuỗi myAttrValue. Đây là cách thuộc tính đó sẽ xuất hiện trong phần ILMD:

Và đây là cách mà thuộc tính đó sẽ xuất hiện trong một VocabularyElement:

(Các dòng mới và khoảng trắng đã được thêm vào ở hai bên của myAttrValue để rõ ràng, nhưng chúng sẽ không xuất hiện trong XML trên thực tế.)

KHÔNG ĐƯỢC SỬ DỤNG: Ràng buộc XML cho mô đun định nghĩa dữ liệu Core Event Types là cơ sở để đưa vào các thông tin bổ sung trong các trường readPoint và bizLocation của tất cả các loại sự kiện bằng cách đưa vào các thành phần phụ bổ sung trong các trường sau subelement id được yêu cầu. Cơ sở này ban đầu được hình thành như một phương tiện để truyền dữ liệu chủ cho các đối với mã phân định vị trí. Tuy nhiên, cơ sở này KHÔNG ĐƯỢC SỬ DỤNG kể từ EPCIS 1.2 và KHÔNG được sử dụng trong dữ liệu EPCIS phù hợp với EPCIS 1.2 hoặc mới hơn. Một hoặc nhiều cơ chế khác để truyền dữ liệu chủ nên được sử dụng thay thế.

9.5  Lược đồ cho các loại sự kiện cốt lõi

Sau đây là một Lược đồ XML (XSD) cho mô-đun định nghĩa dữ liệu Các loại sự kiện cốt lõi. Giản đồ này nhập các lược đồ BỔ SUNG như được hiển thị trong bảng sau:

Bảng 36 – Lược đồ XML (XSD) cho mô-đun định nghĩa dữ liệu các loại sự kiện cốt lõi

Tên miền	Tham chiếu vị trí	Nguồn
urn:epcglobal:xsd:1	EPCglobal.xsd	9.3
http://www.unece.org/cefact/ namespaces/StandardBusiness DocumentHeader	StandardBusinessDocumentHeader.xsd	Trang web của UN / CEFACT; xem 9,2

Ngoài các ràng buộc ngụ ý bởi lược đồ, bất kì giá trị nào của loại xsd: dateTime trong tài liệu cá thể PHẢI bao gồm việc quy định múi giờ (hoặc là “Z” cho UTC hoặc một khoảng bù rõ ràng từ UTC).

Đối với bất kì thành phần XML nào chỉ rõ minOccurs = “0” thuộc loại xsd: anyURI, xsd: string hoặc loại bắt nguồn từ một trong số đó, việc thực hiện EPCIS PHẢI xử lý cá thể có chuỗi rỗng làm giá trị của nó theo đúng cách giống như nó sẽ xảy ra nếu thành phần bị bỏ qua hoàn toàn. Điều này cũng đúng với bất kì thuộc tính XML nào thuộc loại tương tự quy định sử dụng = “tùy chọn”.

Lược đồ này cũng bao gồm sự ràng buộc XML của dữ liệu chủ cho mô-đun định nghĩa dữ liệu Các loại sự kiện cốt lõi. Các phần dữ liệu chủ của lược đồ được sử dụng (a) để trả về các kết quả từ loại truy vấn SimpleMasterDataQuery (8.2.7.2); (b) để cung cấp cho nội dung của một tài liệu dữ liệu chủ như được định nghĩa trong 9.7; và (c) cung cấp phần dữ liệu chủ tùy chọn của tiêu đề EPCIS có thể được sử dụng trong tài liệu EPCIS hoặc tài liệu truy vấn EPCIS.

Thành phần cấp cao nhất EPCISDocument được định nghĩa trong lược đồ được sử dụng bởi các ràng buộc cụ thể của Giao diện truy vấn EPCIS được quy định trong điều 10. Ngoài ra, các đối tác thương mại có thể thỏa thuận lẫn nhau sử dụng Tài liệu EPCIS như một phương tiện để truyền tải một tập hợp các sự kiện EPCIS, tùy chọn đi kèm với dữ liệu chủ có liên quan, dưới dạng một tài liệu điện từ duy nhất.

Tài liệu EPCIS CÓ THỂ bao gồm dữ liệu chính trong tiêu đề của nó. Điều này nhằm mục đích cho phép tác giả của một tài liệu EPCIS chứa dữ liệu chủ mà người nhận tài liệu có thể cần truy vấn bằng cách sử dụng Giao diện truy vấn EPCIS. Không bắt buộc phải có tài liệu EPCIS chứa dữ liệu chủ trong tiêu đề, cũng không yêu cầu dữ liệu chủ trong tiêu đề chứa dữ liệu chủ cho mỗi mã phân định được sử dụng trong phần nội dung của tài liệu EPCIS, hoặc dữ liệu chủ trong tiêu đề được giới hạn mã phân định được sử dụng trong phần nội dung của tài liệu EPCIS. Nếu dữ liệu chủ trong tiêu đề liên quan đến mã phân định trong nội dung, tuy nhiên, nó PHẢI là dữ liệu chủ hiện tại cho mã phân định đó tại thời điểm tài liệu EPCIS được tạo ra. Người nhận tài liệu EPCIS, bao gồm cả việc triển khai giao diện truy vấn EPCIS, có thể sử dụng hoặc bỏ qua dữ liệu chủ như vậy khi nó phù hợp. Dữ liệu chủ trong tiêu đề của tài liệu EPCIS KHÔNG được quy định các giá trị thuộc tính xung đột với phần ILMD của bất kì sự kiện nào có trong nội dung tài liệu EPCIS.

Lược đồ XML (XSD) cho mô-đun định nghĩa dữ liệu Các loại sự kiện cốt lõi được đưa ra dưới đây.

Tiêu chuẩn này được cung cấp “nguyên trạng” không có sự bảo đảm nào, kể cả bất kì bảo đảm khả năng buôn bán, không phù hợp, phù hợp cho mục đích cụ thể, hoặc bất kì bảo đảm nào khác phát sinh ngoài tiêu chuẩn này. GS1 từ chối mọi trách nhiệm pháp lý đối với mọi thiệt hại phát sinh từ việc sử dụng hoặc sử dụng sai tiêu chuẩn này, cho dù thiệt hại đặc biệt, gián tiếp, hậu quả hoặc bồi thường, và bao gồm trách nhiệm vi phạm bất kì quyền sở hữu trí tuệ nào liên quan đến việc sử dụng thông tin hoặc dựa vào tiêu chuẩn này.

GS1 giữ quyền thay đổi tiêu chuẩn này bất kì lúc nào mà không cần thông báo. GS1 không bảo hành cho việc sử dụng tiêu chuẩn này và không chịu trách nhiệm về bất kì lỗi nào có thể xuất hiện trong tài liệu, cũng như không cam kết cập nhật thông tin trong tiêu chuẩn này.

Trong phương pháp này, thành phần <extension> tùy chọn được định nghĩa cho từng loại thành phần có thể mở rộng, trong đó thành phần <extension> có thể chứa các thành phần tương lai được xác định trong tên miền mục tiêu.

Ngoài thành phần <extension> tùy chọn, các loại thành phần mở rộng được công bố với xsd cuối cùng: bất kì kí tự đại diện nào để chứa các thành phần tương lai được xác định bởi bên thứ ba (được biểu thị bằng ## tên miền khác).

Cuối cùng, cơ sở xsd: anyAttribute được sử dụng để cho phép các thuộc tính tùy ý được thêm vào các kiểu phần tử mở rộng. ->

9.6  Các loại sự kiện cốt lõi – ví dụ (Không quy định)

Phần này cung cấp các ví dụ về các tài liệu EPCISDocuments, được đưa vào XML [XML1.0].

9.6.1  Ví dụ 1 – Các sự kiện đối tượng với số phân định mức – cá thể

Ví dụ trong phần này chứa hai ObjectEvents, mỗi đối tượng chứa số phân định mức-cá thể (instance-level). Ví dụ này chỉ sử dụng các tính năng từ EPCIS 1.0 và từ vựng từ CBV 1.1. Sự kiện thứ hai cho thấy một thành phần mở rộng nhà cung cấp / người dùng mức-sự kiện (event-level) có tên myField, theo phương thức cho các phần mở rộng nhà cung cấp / người dùng được quy định trong 9.1.

9.6.2  Ví dụ 2 – Sự kiện đối tượng với mã phân định cấp- tầng

Ví dụ trong phần này gồm một ObjectEvent, chỉ chứa số phân định cấp – tầng. Lưu ý rằng thành phần <epcList> vẫn còn hiện diện, mặc dù trống rỗng, vì điều này được yêu cầu bởi lược đồ XML để duy trì tính tương thích ngược với EPCIS 1.0. Danh sách QuantityList, cùng với các thành phần khác mới trong EPCIS 1.1, đều được tìm thấy trong vùng <extension> được dành riêng cho các tính năng mới trong EPCIS 1.1 (xem 9.1). Tiện ích mở rộng của nhà cung cấp / người dùng có tên myField cũng bao gồm.

9.6.3  Ví dụ 3 – Sự kiện tập hợp với mã phân định tổ hợp

Ví dụ trong phần này gồm một AggregationEvent, chứa các con có cả số phân định cấp – cá thể và cấp – tầng. ChildQuantityList được tìm thấy trong

Vùng <extension> được dành riêng cho các tính năng mới trong EPCIS 1.1 (xem 9.1). Tiện ích mở rộng của nhà cung cấp / người dùng có tên myField cũng được bao gồm.

l

9.6.4  Ví dụ 4 – Sự kiện chuyển đổi

Ví dụ trong phần này gồm một TransformationEvent, chứa các con có cả mã phân định cấp – cá thể và cấp – tầng. Dữ liệu tổng thể thể hiện / lô (ILMD) cũng được bao gồm, trong đó mô tả các kết quả đầu ra của phép biến đổi. Tiện ích mở rộng của nhà cung cấp / người dùng có tên myField cũng được bao gồm. Toàn bộ sự kiện được bao bọc trong thành phần <extension> của EventList được dành riêng cho các loại sự kiện mới trong EPCIS 1.1 (xem 9.1).

9.7  Lược đồ đối với tài liệu dữ liệu chủ

Sau đây là một lược đồ XML (XSD) định nghĩa tài liệu dữ liệu chủ EPCIS. Tài liệu dữ liệu chủ EPCIS có thể được sử dụng để truyền dữ liệu chủ theo thỏa thuận chung. Lược đồ này nhập các lược đồ bổ sung được hiển thị trong bảng sau:

Bảng 37 – Lược đồ XML (XSD) định nghĩa tài liệu dữ liệu chủ EPCIS

Tên miền	Tham chiếu vị trí	Nguồn
urn:epcglobal:xsd:1	EPCglobal.xsd	9.3
http://www.unece.org/cefact/namespaces/ StandardBusinessDocumentHeader	StandardBusinessDocument Header.xsd	Trang web của UN / CEFACT; xem 9.2
urn:epcglobal:epcis:xsd:1	EPCglobal-epcis-1_2.xsd	9.5

Ngoài các ràng buộc ngụ ý bởi lược đồ, bất kì giá trị nào của loại xsd: dateTime trong tài liệu cá thể PHẢI bao gồm quy định về múi giờ (hoặc là “Z” cho UTC hoặc một khoảng bù rõ ràng từ UTC).

Đối với bất kì thành phần XML nào thuộc loại xsd: bất kì URI hoặc xsd: string quy định minOccurs = “0”, việc thực hiện EPCIS PHẢI xử lý thực thể có chuỗi rỗng như giá trị của nó theo cùng cách giống như nếu thành phần bị bỏ qua hoàn toàn.

Lược đồ này bao gồm tiêu đề EPCIS từ lược đồ loại sự kiện cốt lõi được quy định trong 9.5. Tiêu đề đó cho phép đưa vào tùy chọn dữ liệu chủ. Tuy nhiên, một tài liệu dữ liệu chủ EPCIS (một tài liệu XML có thành phần gốc là PCISMasterD EPCISMasterData tùy chọn trong tiêu đề EPCIS của nó.

Lược đồ XML (XSD) đối với dữ liệu chủ được đưa ra dưới đây:

Tiêu chuẩn này được cung cấp “nguyên trạng” không có sự bảo đảm nào, kể cả bất kì bảo đảm khả năng buôn bán, không phù hợp, phù hợp cho mục đích cụ thể, hoặc bất kì bảo đảm nào khác phát sinh ngoài tiêu chuẩn này. GS1 từ chối mọi trách nhiệm pháp lý đối với mọi thiệt hại phát sinh từ việc sử dụng hoặc sử dụng sai tiêu chuẩn này, cho dù thiệt hại đặc biệt, gián tiếp, hậu quả hoặc bồi thường, và bao gồm trách nhiệm vi phạm bất kì quyền sở hữu trí tuệ nào liên quan đến việc sử dụng thông tin hoặc dựa vào tiêu chuẩn này.

GS1 giữ quyền thay đổi tiêu chuẩn này bất kì lúc nào mà không cần thông báo. GS1 không bảo hành cho việc sử dụng tiêu chuẩn này và không chịu trách nhiệm về bất kì lỗi nào có thể xuất hiện trong tài liệu, cũng như không cam kết cập nhật thông tin trong tiêu chuẩn này.

9.8  Dữ liệu chủ – ví dụ (phi quy chuẩn)

Đây là một ví dụ về EPCISMasterDataDocument chứa dữ liệu chủ cho BusinessLocation và các từ vựng của ReadPoint, được biểu hiện thành XML [XML1.0]:

10  Ràng buộc đối với mô-đun hoạt động truy cập cốt lõi

Phần này định nghĩa các ràng buộc đối với Mô đun Hoạt động truy cập cốt lõi. Tất cả các ràng buộc được quy định ở đây đều dựa trên biểu diễn XML của các sự kiện được xác định trong 9.5. Việc triển khai EPCIS CÓ THỂ cung cấp hỗ trợ cho một hoặc nhiều ràng buộc đối với Mô-đun hoạt động truy cập cốt lõi như được quy định bên dưới.

10.1  Ràng buộc xếp hàng tin nhắn

Phần này định nghĩa ràng buộc của Mô-đun hoạt động truy vấn cốt lõi cho hệ thống xếp hàng tin nhắn, như thường được triển khai trong các doanh nghiệp lớn. Một hệ thống xếp hàng tin nhắn được định nghĩa cho mục đích của phần này là bất kì hệ thống nào cho phép một ứng dụng gửi một tin nhắn XML đến một ứng dụng khác. Hệ thống xếp hàng tin nhắn thường hỗ trợ cả việc gửi tin nhắn điểm-điểm và xuất bản / đăng kí gửi tin nhắn. Hệ thống xếp hàng thông báo thường bao gồm các tính năng đảm bảo phân phối đáng tin cậy và đảm bảo chất lượng dịch vụ (QoS) khác.

Vì không có hệ thống xếp hàng tiêu chuẩn công nghiệp được chấp nhận phổ biến, tiêu chuẩn này được thiết kế để áp dụng cho bất kì hệ thống nào như vậy. Do đó, nhiều chi tiết triển khai thực sự nằm ngoài phạm vi của tiêu chuẩn này. Các chi tiết như vậy bao gồm hệ thống xếp hàng tin nhắn để sử dụng, giải quyết, giao thức, sử dụng QoS hoặc các tham số hệ thống cụ thể khác, v.v.

Việc triển khai EPCIS CÓ THỂ cung cấp một ràng buộc xếp hàng tin nhắn của Mô-đun Hoạt động truy vấn cốt lõi theo cách sau. Với mục đích của ràng buộc này, một “khách hàng truy cập” là một ứng dụng truy cập EPCIS muốn cung cấp một sự kiện EPCIS thông qua giao diện truy vấn EPCIS, và một “máy chủ truy cập” là một kho lưu trữ EPCIS hoặc ứng dụng truy cập EPCIS nhận sự kiện từ một khách hàng truy cập.

Một máy chủ truy cập PHẢI cung cấp một hoặc nhiều điểm cuối xếp hàng tin nhắn qua đó một khách hàng truy cập có thể cung cấp một hoặc nhiều sự kiện EPCIS. Mỗi điểm cuối của xếp hàng tin nhắn CÓ THỂ là xếp hàng điểm-điểm, chủ đề xuất bản / đăng kí hoặc một số kênh địa chỉ thích hợp khác được cung cấp bởi hệ thống xếp hàng tin nhắn; các chi tiết cụ thể nằm ngoài phạm vi của tiêu chuẩn này.

Một khách hàng truy cập PHẢI thực hiện thao tác truy cập được xác định trong 8.1.2 bằng cách gửi một tin nhắn đến điểm cuối được cung cấp bởi máy chủ truy cập. Tin nhắn PHẢI là một trong những điều sau đây:

– một tài liệu XML có thành phần gốc phù hợp với thành phần EPCISDocument như được định nghĩa bởi lược đồ của 9.5; hoặc là

– một tài liệu XML có thành phần gốc phù hợp với thành phần EPCISQueryDocument như được định nghĩa bởi lược đồ của 11.1, trong đó thành phần được lồng trong thành phần EPCISBody là thành phần QueryResults và thành phần resultsBody trong thành phần QueryResults chứa thành phần EventList.

Việc triển khai giao diện truy cập PHẢI chấp nhận biểu mẫu EPCISDocument và NÊN chấp nhận biểu mẫu EPCISQueryDocument. Việc triển khai giao diện truy cập KHÔNG được chấp nhận các tài liệu không hợp lệ như được định nghĩa ở trên. Sự chấp nhận thành công tin nhắn này bởi máy chủ PHẢI cấu thành sự truy cập tất cả các sự kiện EPCIS có trong tin nhắn.

Hệ thống xếp hàng tin nhắn khác nhau về khả năng của chúng để cung cấp sự thừa nhận tích cực và tiêu cực cho người gửi tin nhắn. Khi một tính năng xác nhận tích cực có sẵn từ hệ thống xếp hàng tin nhắn, một xác nhận tích cực có THỂ được sử dụng để chỉ ra truy cập đã thành công bởi máy chủ truy cập. Khi một tính năng xác nhận tiêu cực có sẵn từ hệ thống xếp hàng tin nhắn, một sự thừa nhận tiêu cực CÓ THỂ được sử dụng để chỉ ra một sự thất bại để hoàn thành hoạt động truy cập.

Thất bại có thể do tài liệu không hợp lệ, lỗi ủy quyền như được mô tả trong 8.1.1 hoặc vì một lý do nào khác. Các trường hợp cụ thể mà theo đó một xác nhận tích cực hoặc tiêu cực được quy định phụ thuộc vào việc thực hiện. Tất cả các triển khai, tuy nhiên PHẢI chấp nhận tất cả các sự kiện trong thư hoặc từ chối tất cả các sự kiện.

10.2  Ràng buộc HTTP

Phần này định nghĩa ràng buộc của Mô-đun hoạt động truy cập cốt lõi với HTTP [RFC2616].

Việc triển khai EPCIS CÓ THỂ cung cấp một ràng buộc HTTP của Mô-đun Hoạt động truy cập cốt lõi theo cách sau. Với mục đích của ràng buộc này, “khách hàng truy cập” là ứng dụng truy cập EPCIS muốn cung cấp một sự kiện EPCIS thông qua giao diện truy vấn EPCIS, và một “máy chủ truy cập” là kho lưu trữ EPCIS hoặc ứng dụng truy cập EPCIS nhận sự kiện từ khách hàng truy cập.

Một máy chủ khách hàng truy cập PHẢI cung cấp URL HTTP thông qua đó khách hàng khách hàng truy cập có thể cung cấp một hoặc nhiều sự kiện EPCIS.

Khách hàng khách hàng truy cập PHẢI thực hiện thao tác khách hàng truy cập được định nghĩa trong 8.1.2 bằng cách gọi hoạt động HTTP POST trên URL được cung cấp bởi máy chủ khách hàng truy cập. Tải lượng tin nhắn PHẢI là một trong những điều sau đây:

– một tài liệu XML có thành phần gốc phù hợp với phần tử EPCISDocument như được định nghĩa bởi lược đồ của Phần 9.5; hoặc là

– một tài liệu XML có thành phần tử gốc phù hợp với thành phần EPCISQueryDocument như được định nghĩa bởi lược đồ của 11.1, trong đó thành phần được lồng trong thành phần EPCISBody là thành phần QueryResults và thành phần resultsBody trong thành phần QueryResults chứa thành phần EventList.

Việc triển khai giao diện truy cập PHẢI chấp nhận biểu mẫu EPCISDocument và NÊN chấp nhận biểu mẫu EPCISQueryDocument. Việc triển khai giao diện truy cập KHÔNG được chấp nhận các tài liệu không hợp lệ như được định nghĩa ở trên. Sự chấp nhận thành công tin nhắn này bởi máy chủ PHẢI cấu thành việc truy cập tất cả các sự kiện EPCIS có trong tin nhắn.

Mã trạng thái được trả về bởi máy chủ truy cập PHẢI phù hợp với [RFC2616], điều 10. Đặc biệt, máy chủ truy cập PHẢI trả lại mã trạng thái 200 để cho biết hoàn thành hoạt động truy cập và bất kì mã trạng thái 3xx, 4xx hoặc 5xx PHẢI chỉ ra xem hoạt động truy cập nào không được hoàn tất thành công. Các trường hợp cụ thể mà mã trả về thành công hay thất bại phụ thuộc vào việc thực hiện. Tất cả các triển khai, tuy nhiên, PHẢI chấp nhận tất cả các sự kiện trong tin nhắn hoặc từ chối tất cả các sự kiện.

11  Các ràng buộc đối với môđun hoạt động truy vấn cốt lõi

Phần này định nghĩa các ràng buộc cho Mô đun hoạt động truy vấn cốt lõi, như sau:

Bảng 38 – Các ràng buộc cho Mô đun hoạt động truy vấn cốt lõi

Giao diện	Ràng buộc	Điều khoản của tiêu chuẩn
Giao diện điều khiển truy vấn	SOAP over HTTP (WSDL)	11.2
	XML over AS2	11.3
Giao diện gọi lại truy vấn	XML over HTTP	11.4.2
	XML over HTTP+TLS (HTTPS)	11.4.3
	XML over AS2	11.4.4

Tất cả các ràng buộc này chia sẻ một cú pháp XML chung, được quy định trong 11.1. Lược đồ XML có các thành phần sau:

– Các thành phần XML cho đối số và trả về chữ kí của từng phương thức trong Giao diện kiểm soát truy vấn như được định nghĩa trong 8.2.5

– Các loại XML cho mỗi loại dữ liệu được sử dụng trong các đối số và trả về chữ ký

– Các thành phần XML cho mỗi ngoại lệ được định nghĩa trong 8.2.6

– Các thành phần XML cho Giao diện gọi lại truy vấn như được định nghĩa trong 8.2.8. (Đây thực sự chỉ là một tập hợp con của ba viên đạn trước.)

– Thành phần EPCISQueryDocument, được sử dụng như một “phong bì/vỏ bọc” bởi các ràng buộc có công nghệ cơ bản không cung cấp cơ chế tiêu đề hoặc phong bì/vỏ bọc riêng của nó (cụ thể là tất cả các ràng buộc ngoại trừ ràng buộc SOAP). Liên kết AS2 sử dụng tính năng này để cung cấp tiêu đề khớp với yêu cầu và phản hồi. Thành phần EPCISQueryDocument chia sẻ loại EPCISHeader được định nghĩa trong 9.5. Mỗi ràng buộc quy định quy tắc riêng của nó để sử dụng tiêu đề này, nếu áp dụng.

11.1  Lược đồ XML cho mô đun hoạt động truy vấn lõi

Lược đồ sau định nghĩa các trình diễn XML của các loại dữ liệu, các yêu cầu, các đáp ứng và các ngoại lệ được sử dụng bởi Giao diện kiểm soát truy vấn EPCIS và Giao diện gọi lại truy vấn EPCIS trong Mô đun hoạt động truy vấn cốt lõi. Lược đồ này được kết hợp bằng cách tham chiếu vào tất cả các ràng buộc cho hai giao diện này được quy định trong phần còn lại của điều 11. Lược đồ này NÊN được sử dụng cho bất kì ràng buộc mới nào của bất kì giao diện nào trong Mô-đun hoạt động truy vấn cốt lõi sử dụng XML như định dạng tin nhắn cơ bản.

Loại QueryParam được định nghĩa trong lược đồ dưới đây được sử dụng để biểu diễn tham số truy vấn được sử dụng bởi các thăm dò và các phương thức đăng kí của giao diện truy vấn được định nghĩa trong 8.2.5. Tham số truy vấn bao gồm tên và giá trị. Lược đồ XML quy định xsd: anyType đối với giá trị, sao cho giá trị tham số của bất kì loại nào có thể được biểu diễn. Khi tạo một cá thể tài liệu, giá trị thực PHẢI phù hợp với loại thích hợp cho tham số truy vấn, như được định nghĩa trong bảng sau:

Bàng 39 – Loại QueryParam biểu diễn tham số truy vấn

Loại tham số	Loại XML cho thành phần giá trị
Int	xsd:integer
Phao	xsd:double
Thời gian	xsd:dateTime
Chuỗi	xsd:string
Danh sách chuỗi	epcisq:ArrayOfString
Bỏ trống	epcisq:VoidHolder

Cụ thể, bảng trên PHẢI được sử dụng để ánh xạ các loại tham số được quy định cho các truy vấn được xác định trước của 8.2.7 vào các loại XML tương ứng.

Mỗi thành phần <value> quy định một giá trị tham số truy vấn trong tài liệu cá thể CÓ THỂ bao gồm thuộc tính xsi: type như được quy định trong [XSD1], Các quy tắc sau quy định cách xử lý giá trị tham số truy vấn:

– Khi thành phần <value> không bao gồm thuộc tính xsi: type, phương thức đăng kí hoặc thăm dò của Giao diện kiểm soát truy vấn PHẢI đưa ra QueryParameterException nếu giá trị được quy định không phải là cú pháp hợp lệ cho loại được yêu cầu bởi tham số truy vấn.

– Khi thành phần <value> bao gồm thuộc tính xsi: type, các quy tắc sau sẽ áp dụng:

□ Nếu thành phần <value> không phải là cú pháp hợp lệ cho loại được quy định bởi thuộc tính xsi: type, yêu cầu EPCISQueryDocument hoặc SOAP CÓ THỂ bị từ chối bởi việc phân tích cú pháp thực hiện XML.

□ Nếu giá trị của thuộc tính xsi: type không phải là loại chính xác cho tham số truy vấn đó như được quy định trong cột thứ hai của bảng trên, phương thức đăng ki hoặc thăm dò của Giao diện kiểm soát truy vấn CÓ THỂ đưa ra QueryParameterException, ngay cả khi phần nội dung của các thành phần <value> là cú pháp hợp lệ cho loại được yêu cầu bởi tham số truy vấn.

□ Nếu thành phần <value> không phải là cú pháp hợp lệ cho loại được yêu cầu bởi tham số truy vấn, phương thức đăng kí hoặc thăm dò của Giao diện kiểm soát truy vấn PHẢI đưa ra QueryParameterException trừ khi yêu cầu EPCISQueryDocument hoặc SOAP bị từ chối bởi việc phân tích cú pháp thực hiện XML theo quy tắc trên.

Lược đồ này đưa ra các lược đồ BỔ SUNG được cho trong bảng sau:

Bảng 40 – Các lược đồ bổ sung

Tên miền	Địa chỉ tham chiếu	Nguồn
urn:epcglobal:xsd:1	EPCglobal.xsd	9.3
http://www.unece.org/cefact/namespaces/ StandardBusinessDocumentHeader	StandardBusinessDocumentHeader.xsd	UN/CEFACT web site; xem 9.2
urn:epcglobal:epcis:xsd:1	EPCglobal-epcis-1_0.xsd	9.5
urn:epcglobal:epcis-masterdata:xsd:1	EPCglobal-epcis-masterdata-1_0.xsd	9.7

Ngoài các ràng buộc ngụ ý bởi lược đồ, bất kì giá trị nào của loại xsd. dateTime trong tài liệu cá thể PHẢI bao gồm quy định múi giờ (hoặc là “Z” cho UTC hoặc một khoảng bù rõ ràng từ UTC).

Đối với bất kì thành phần XML nào thuộc loại xsd: anyURI hoặc xsd: string quy định minOccurs = “0”, việc thực hiện EPCIS PHẢI xử lý một thực thể có chuỗi rỗng làm giá trị của nó theo cùng cách giống như trước nếu thành phần bị bỏ qua hoàn toàn.

Lược đồ XML (XSD) cho Mô đun hoạt động truy vấn cốt lõi được đưa ra dưới đây:

 

Tiêu chuẩn này được cung cấp “nguyên trạng” không có sự bảo đảm nào, kể cả bất kì bảo đảm khả năng buôn bán, không phù hợp, phù hợp cho mục đích cụ thể, hoặc bất kì bảo đảm nào khác phát sinh ngoài tiêu chuẩn này. GS1 từ chối mọi trách nhiệm pháp lý đối với mọi thiệt hại phát sinh từ việc sử dụng hoặc sử dụng sai tiêu chuẩn này, cho dù thiệt hại đặc biệt, gián tiếp, hậu quả hoặc bồi thường, và bao gồm trách nhiệm vi phạm bất kì quyền sở hữu trí tuệ nào liên quan đến việc sử dụng thông tin hoặc dựa vào tiêu chuẩn này.

GS1 giữ quyền thay đổi tiêu chuẩn này bất kì lúc nào mà không cần thông báo. GS1 không bảo hành cho việc sử dụng tiêu chuẩn này và không chịu trách nhiệm về bất kì lỗi nào có thể xuất hiện trong tài liệu, cũng như không cam kết cập nhật thông tin trong tiêu chuẩn này.

11.2  Ràng buộc SOAP / HTTP đối với giao diện kiểm soát truy vấn

Sau đây là quy định kĩ thuật dịch vụ Web (WSDL) 1.1 [WSDL1.1] xác định ràng buộc SOAP / HTTP chuẩn của Giao diện kiểm soát truy vấn EPCIS. Việc triển khai EPCIS CÓ THỂ cung cấp một liên kết SOAP / HTTP của Giao diện kiểm soát truy vấn EPCIS; nếu ràng buộc SOAP / HTTP được cung cấp, nó PHẢI phù hợp với WSDL sau đây. Liên kết SOAP / HTTP này tuân thủ với WS-I hồ sơ cơ bản phiên bản 1.0 [WSI]. Ràng buộc này xây dựng dựa trên lược đồ được định nghĩa trong 11.1.

Nếu việc triển khai EPCIS cung cấp ràng buộc SOAP tiếp nhận đầu vào không hợp lệ theo cú pháp của WSDL này, thì việc thực hiện PHẢI chỉ ra điều này theo một trong hai cách sau đây: việc thực hiện CÓ THỂ đưa ra ValidationException, hoặc nó CÓ THỂ đưa ra một ngoại lệ chung chung hơn được cung cấp bởi bộ xử lý SOAP đang được sử dụng.

Tiêu chuẩn này được cung cấp “nguyên trạng” không có sự bảo đảm nào, kể cả bất kì bảo đảm khả năng buôn bán, không phù hợp, phù hợp cho mục đích cụ thể, hoặc bất kì bảo đảm nào khác phát sinh ngoài tiêu chuẩn này. GS1 từ chối mọi trách nhiệm pháp lý đối với mọi thiệt hại phát sinh từ việc sử dụng hoặc sử dụng sai tiêu chuẩn này, cho dù thiệt hại đặc biệt, gián tiếp, hậu quả hoặc bồi thường, và bao gồm trách nhiệm vi phạm bất kì quyền sở hữu trí tuệ nào liên quan đến việc sử dụng thông tin hoặc dựa vào tiêu chuẩn này.

GS1 giữ quyền thay đổi tiêu chuẩn này bất kì lúc nào mà không cần thông báo. GS1 không bảo hành cho việc sử dụng tiêu chuẩn này và không chịu trách nhiệm về bất kì lỗi nào có thể xuất hiện trong tài liệu, cũng như không cam kết cập nhật thông tin trong tiêu chuẩn này.

11.3  Ràng buộc AS2 đối với giao diện kiểm soát truy vấn

Phần này định nghĩa ràng buộc đối với Giao diện kiểm soát truy vấn EPCIS với AS2 [RFC4130], Việc triển khai EPCIS có THỂ cung cấp liên kết AS2 đối với giao diện kiểm soát truy vấn EPCIS; nếu liên kết AS2 được cung cấp, nó sẽ tuân theo các điều khoản của phần này. Với mục đích của ràng buộc này, “khách truy vấn” là một Ứng dụng Truy cập EPCIS muốn phát hành các hoạt động truy vấn EPCIS như được định nghĩa trong 8.2.5 và “máy chủ truy vấn” là một Kho lưu trữ EPCIS hoặc hệ thống khác thực hiện các hoạt động đó thay cho ứng dụng khách hàng truy vấn.

Máy chủ truy vấn PHẢI cung cấp URL HTTP mà qua đó nó nhận các tin nhắn từ máy khách hàng truy vấn theo [RFC4130], Tin nhắn được gửi bởi máy khách hàng truy vấn tới máy chủ truy vấn PHẢI là một tài liệu XML có thành phần gốc phù hợp với thành phần EPCISQueryDocument như được định nghĩa bởi lược đồ trong 11.1. Thành phần này ngay lập tức được lồng trong thành phần EPCISBody PHẢI là một trong các thành phần tương ứng với yêu cầu của phương thức Giao diện kiểm soát truy vấn EPCIS (nghĩa là, một trong các Đăng kí, Hủy đăng kí, Thăm dò ý kiến, v.v.). Các yếu tố cho phép được liệt kê trong bảng bên dưới. Nếu tin nhắn được gửi bởi ứng dụng khách hàng truy vấn không tuân thủ các yêu cầu trên, máy chủ truy vấn PHẢI trả lời với ValidationException (có nghĩa là, trả về một cá thể EPCISQueryDocument trong đó thành phần được lồng ngay trong EPCISBody là một ValidationException).

Khách truy vấn PHẢI cung cấp URL HTTP mà máy chủ truy vấn sẽ sử dụng để gửi tin nhắn phản hồi. URL này thường được trao đổi ngoài băng, như là một phần của việc thiết lập thỏa thuận đối tác thương mại song phương (xem [RFC4130] 5.1).

Cả máy khách hàng truy vấn lẫn máy chủ truy vấn PHẢI thực hiện theo các Yêu cầu và NÊN tuân thủ các Khuyến nghị được liệt kê trong tài liệu GS1 “EDIINT AS1 và Hướng dẫn truyền thông vận tải AS2” [EDICG]. Để tham khảo, các phần liên quan của tiêu chuẩn này được sao chép dưới đây.

Ứng dụng khách hàng truy vấn PHẢI bao gồm Tiêu đề tài liệu kinh doanh chuẩn trong thành phần EPCISHeader. Khách hàng truy vấn PHẢI đưa mã phân định duy nhất làm giá trị của thành phần InstanceIdentifier vào trong tiêu đề tài liệu kinh doanh chuẩn, ứng dụng khách hàng truy vấn CÓ THỂ đưa các mã phân định duy nhất làm giá trị của thành phần InstanceIdentifier khác vào trong Tiêu đề tài liệu kinh doanh chuẩn như lược đồ cung cấp. Mã phân định cá thể do khách hàng truy vấn cung cấp NÊN là duy nhất đối với tất cả các tin nhắn khác mà khách hàng truy vấn chưa nhận được phản hồi tương ứng. Như được mô tả bên dưới, mã phân định cá thể được sao chép vào tin nhắn trả lời để hỗ trợ ứng dụng khách trong tương quan phản hồi với các yêu cầu.

Máy chủ truy vấn PHẢI trả lời từng tin nhắn được gửi bởi ứng dụng khách truy vấn bằng cách gửi tin nhắn phản hồi đến URL được cung cấp bởi ứng dụng khách truy vấn, theo [RFC4130], Tin nhắn phản hồi được gửi bởi máy chủ truy vấn PHẢI là tài liệu XML có thành phần gốc phù hợp với thành phần EPCISQueryDocument như được định nghĩa bởi lược đồ trong 11.1. Thành phần này ngay lập tức được lồng trong thành phần EPCISBody PHẢI là một trong các thành phần được cho trong bảng sau, theo thành phần được cung cấp trong yêu cầu tương ứng:

Bảng 41 – Thành phần được lồng trong EPCISBody

Thành phần yêu cầu	Các thành phần trả về được phép
GetQueryNames	GetQueryNamesResult SecurityException ValidationException Implementation Exception
Subscribe	SubscribeResult NoSuchNameException InvalidURIException DuplicateSubscriptionException QueryParameterException QueryTooComplexException SubscriptionControlsException SubscribeNotPermittedException SecurityException ValidationException ImplementationException
Unsubscribe	UnsubscribeResult NoSuchSubscriptionException SecurityException ValidationException ImplementationException
GetSubscriptionIDs	GetSubscriptionIDsResult NoSuchNameException Security Exception ValidationException ImplementationException
Poll	QueryResults QueryParameterException QueryTooLargeException QueryTooComplexException NoSuchNameException SecurityException ValidationException ImplementationException
GetStandardVersion	GetStandardVersionResult SecurityException ValidationException ImplementationException
GetVendorVersion	GetVendorVersionResult SecurityException ValidationException ImplementationException

Máy chủ truy vấn PHẢI bao gồm Tiêu đề tài liệu kinh doanh chuẩn trong thành phần EPCISHeader. Máy chủ truy vấn PHẢI bao gồm trong tiêu đề tài liệu kinh doanh chuẩn thành phần BusinessScope chứa thành phần Phạm vi và chứa thành phần CorrelationInformation chứa thành phần RequestingDocumentInstanceIdentifier; giá trị của thành phần sau PHẢI là giá trị của thành phần InstanceIdentifier từ Tiêu đề tài liệu kinh doanh chuẩn của yêu cầu tương ứng. Trong thành phần Phạm vi, thành phần phụ PHẢI được đặt thành EPCISQuery và thành phần InstanceIdentifier PHẢI được đặt thành EPCIS. Máy chủ truy vấn CÓ THỂ bao gồm các thành phần khác trong Tiêu đề tài liệu kinh doanh chuẩn như được lược đồ cung cấp.

11.3.1  Hướng dẫn AS2 của GS1 (Không bắt buộc)

Như đã nêu ở trên, khách hàng truy vấn và máy chủ truy vấn PHẢI thực hiện theo các Yêu cầu và NÊN tuân thủ các Khuyến nghị được liệt kê trong tài liệu GS1 “EDIINT AS1 và AS2 Transport Communications Guidelines” [EDICG] Để tham khảo, các phần liên quan của tiêu chuẩn này được sao chép bên dưới. Trích xuất này được đánh dấu không bắt buộc; trong trường hợp xung đột giữa [EDICG] và nội dung được viết bên dưới, [EDICG] sẽ được áp dụng.

Yêu cầu chứng chỉ số hóa

Yêu cầu 1

Dữ liệu tải lượng PHẢI được mã hóa và số hóa bằng, sử dụng quy định kĩ thuật S / MIME (xem RFC 3851).

Yêu cầu 2

Độ dài của mã khóa một lần (đối xứng) PHẢI là 128 bit hoặc lớn hơn.

Yêu cầu 3

Độ dài của mã khóa công khai / riêng tư PHẢI là 1024 bít hoặc lớn hơn.

Yêu cầu 4

Độ dài của mã khóa công khai / chữ kí riêng PHẢI là 1024 bit hoặc lớn hơn.

Yêu cầu 5

Thuật toán Hash của Chữ kí được sử dụng PHẢI là SHA1.

Yêu cầu về cấu hình

Yêu cầu 6

Biên lai đã kí số hóa (Thông báo bố trí tin nhắn đã kí (MDN)) PHẢI được yêu cầu bởi Người gửi tin nhắn.

khuyến nghị

Khuyến nghị 1 – Tùy chọn yêu cầu MDN

Hoặc MDN không đồng bộ hoặc đồng bộ CÓ THỂ được sử dụng với EDIINT AS2. Có các vấn đề tiềm năng với cả MDN đồng bộ và không đồng bộ và Đối tác thương mại cần cùng xác định tùy chọn nào là tốt nhất dựa trên môi trường hoạt động và đặc điểm tin nhắn của chúng.

Khuyến nghị 2 – Phân phối MDN

Người nhận NÊN truyền MDN sớm nhất có thể để đảm bảo rằng người gửi tin nhắn nhận ra rằng tin nhắn đã được nhận và xử lý bằng phần mềm nhận EDIINT kịp thời. Điều này áp dụng như nhau cho AS1 và AS2 cũng như các yêu cầu MDN không đồng bộ và đồng bộ.

Khuyến nghị 3 – Chuyển phát lại với MDN không đồng bộ được yêu cầu

Khi một tin nhắn được gửi thành công, nhưng một MDN không đồng bộ chưa được nhận một cách kịp thời, Người gửi tin nhắn cần đợi một khoảng thời gian có thể cấu hình và sau đó tự động gửi lại tin nhắn gốc với cùng nội dung và cùng giá trị ID tin nhắn như tin nhắn ban đầu. Khoảng thời gian chờ MDN và sau đó tự động gửi lại tin nhắn gốc dựa trên nhu cầu kinh doanh và kĩ thuật, nhưng nói chung KHÔNG được ít hơn một giờ. KHÔNG NÊN quá hai lần tự động gửi lại tin nhắn trước khi liên hệ trực tiếp với người liên hệ hỗ trợ kĩ thuật tại trang Người nhận tin nhắn.

Khuyến nghị 4 – Chuyển phát lại cho AS2

Chuyển phát lại NÊN được thực hiện khi bất kì phản hồi HTTP nào khác với “200 OK” được nhận (ví dụ: 401, 500, 502, 503, thời gian chờ, v.v.). Sự xuất hiện này cho thấy việc truyền dữ liệu thực tế không thành công. Chuyển phát lại tin nhắn PHẢI có nội dung giống nhau và cùng giá trị ID- tin nhắn như tin nhắn ban đầu. Thử lại NÊN diễn ra trên một lịch trình cấu hình.

Việc thử lại PHẢI ngừng khi một tin nhắn được gửi thành công (được báo bằng cách nhận mã trạng thái HTTP 200) hoặc NÊN dừng lại khi vượt quá giới hạn thử lại.

Khuyến nghị 5 – Gửi lại tin nhắn

Nếu cả chuyển phát lại tự động lẫn gửi lại tự động không thành công, Người gửi tin nhắn có thể chọn gửi lại dữ liệu tải lượng trong một tin nhắn mới sau đó. Người nhận tin nhắn CÓ THỂ cũng yêu cầu gửi lại tin nhắn nếu một tin nhắn bị mất sau khi nhận được thành công. Nếu tin nhắn được gửi lại, một ID tin nhắn mới phải được sử dụng. Việc gửi lại thường là bồi thường thủ công.

Khuyến nghị 6 – HTTP so với HTTP / S (SSL)

Đối với EDIINT AS2, giao thức truyền tải HTTP NÊN được sử dụng. Tuy nhiên, nếu có nhu cầu bảo mật AS2- đến và các địa chỉ AS2- từ và thông tin tiêu đề AS2 khác, HTTPS CÓ THỂ được sử dụng ngoài mã hóa tải lượng được cung cấp bởi AS2. Mã hóa do HTTPS cung cấp chỉ đảm bảo kênh truyền thông trực tiếp điểm đến điểm giữa khách hàng và máy chủ.

Khuyến nghị 7 – Tiêu đề AS2

Đối với EDIINT AS2, các giá trị được sử dụng trong các trường AS2-Từ và AS2-đến trong tiêu đề NÊN là mã số địa điểm toàn cầu GS1 (GLN).

Khuyến nghị 8 – SMTP [không áp dụng]

Khuyến nghị 9 – Nén

Nén EDIINT CÓ THỂ được sử dụng tùy chọn, đặc biệt nếu dung lượng tin nhắn lớn hơn 1MB. Mặc dù các phiên bản hiện tại của phần mềm EDIINT tự động xử lý nén, nhưng việc này NÊN được thỏa thuận song phương giữa người gửi và người nhận.

Khuyến nghị 10 – Đặc điểm chứng chỉ số hóa

Giấy chứng nhận số hóa CÓ THỂ là từ bên thứ ba đáng tin cậy hoặc tự kí nếu thỏa thuận song phương giữa các đối tác thương mại. Nếu giấy chứng nhận từ bên thứ ba được sử dụng, mức độ tin cậy NÊN ở mức tối thiểu được gọi là ‘cấp 2’ để đảm bảo rằng việc xác thực cá nhân và tổ chức đã được thực hiện.

Khuyến nghị 11- Giấy chứng nhận số hóa chung cho mã hóa & chữ ký

Giấy chứng nhận số hóa duy nhất CÓ THỂ được sử dụng cho cả mã hóa và chữ kí, tuy nhiên nếu quy trình kinh doanh bắt buộc, hai giấy chứng nhận riêng biệt CÓ THỂ được sử dụng. Mặc dù các phiên bản hiện tại của phần mềm EDIINT tự động xử lý hai giấy chứng nhận, nhưng việc này NÊN được thỏa thuận song phương giữa người gửi và người nhận.

Khuyến nghị 12 – Thời hạn hiệu lực của giấy chứng nhận số hóa

Thời hạn hiệu lực tối thiểu đối với giấy chứng nhận NÊN là 1 năm. Thời hạn hiệu lực tối đa NÊN là 5 năm.

Khuyến nghị 13 – Giấy chứng nhận số hóa – Trao đổi Tự động

Phương thức trao đổi giấy chứng nhận PHẢI được thỏa thuận song phương. Khi quy định kĩ thuật về “Trao đổi giấy chứng nhận nhắn tin cho EDIINT” được triển khai rộng rãi bởi các nhà cung cấp phần mềm, việc sử dụng nó sẽ được khuyến khích mạnh mẽ. Quy định kĩ thuật IETF này sẽ cho phép trao đổi tự động giấy chứng nhận khi mối quan hệ tin cậy ban đầu được thiết lập và sẽ làm giảm đáng kể gánh nặng hoạt động trao đổi thủ công giấy chứng nhận trước khi hết hạn.

Khuyến nghị 14 – Số cổng HTTP và HTTP / S cho AS2

Nhận tin nhắn AS2 trên một cổng (cho mỗi giao thức) giảm thiểu đáng kể các phức tạp hoạt động như thiết lập tường lửa cho cả đối tác gửi và nhận. Lý tưởng nhất, tất cả các đối tác AS2 sẽ nhận được tin nhắn bằng cách sử dụng cùng một số cổng. Tuy nhiên, một số đối tác AS2 trước đây đã chuẩn hóa để sử dụng một số cổng khác với số cổng khác và thay đổi thành số cổng mới sẽ thêm chi phí mà không có lợi ích tương xứng.

Do đó các đối tác AS2 CÓ THỂ chuẩn hóa việc sử dụng cổng 4080 để nhận các tin nhắn HTTP và sử dụng cổng 5443 để nhận các tin nhắn HTTP / S (SSL).

Khuyến nghị 15 – Tin nhắn trùng lặp AS2

Triển khai phần mềm AS2 NÊN sử dụng giá trị ‘ID tin nhắn AS2’ để phát hiện các tin nhắn trùng lặp và tránh gửi tải lượng từ tin nhắn trùng lặp đến các ứng dụng kinh doanh nội bộ. Người nhận tin nhắn PHẢI trả lại MDN phù hợp ngay cả khi một tin nhắn được phát hiện là trùng lặp. Lưu ý: nguồn lực về kĩ thuật Internet (IETF) đang phát triển quy định kĩ thuật về “Độ tin cậy hoạt động cho EDIINT AS2” xác định các quy trình để tránh trùng lặp và đảm bảo độ tin cậy.

Khuyến nghị 16 – Hỗ trợ kĩ thuật

NÊN có một liên hệ hỗ trợ kĩ thuật cho mỗi Người gửi tin nhắn và người nhận tin nhắn. Thông tin liên hệ NÊN bao gồm tên, địa chỉ email và số điện thoại. Đối với hoạt động 24x7x365, thông tin về máy nhắn tin hoặc bàn trợ giúp NÊN cũng được cung cấp.

11.4  Các ràng buộc đối với giao diện gọi lại truy vấn

Phần này quy định các ràng buộc cho Giao diện gọi lại truy vấn. Mỗi liên kết bao gồm một quy định kĩ thuật cho một URI có thể được sử dụng làm tham số dest cho phương thức subscribe của 8.2.5.

Mỗi tiểu mục dưới đây quy định yêu cầu về sự phù hợp (CÓ THỂ, NÊN, PHẢI) cho mỗi ràng buộc.

Việc triển khai CÓ THỂ hỗ trợ các ràng buộc bổ sung của Giao diện gọi lại truy vấn. Bất kì ràng buộc bổ sung nào KHÔNG sử dụng lược đồ URI đã được sử dụng bởi một trong các ràng buộc được quy định ở đây.

Tất cả URI đích, cho dù được chuẩn hóa như một phần của tiêu chuẩn này hay không, đều tuân theo cú pháp chung cho URI như được định nghĩa trong [RFC2396], Mỗi ràng buộc của Giao diện gọi lại truy vấn có thể áp đặt các ràng buộc bổ sung theo cú pháp của URI để sử dụng với ràng buộc đó.

11.4.1  Cân nhắc chung cho tất cả các ràng buộc dựa trên XML

Các điều sau áp dụng cho tất cả các ràng buộc dựa trên XML của Giao diện gọi lại truy vấn bao gồm các ràng buộc được quy định trong 11.4.2, 11.4.3 và 11.4.4.

Tải lượng được gửi đến người nhận PHẢI là tài liệu XML phù hợp với lược đồ được quy định trong 11.1. Cụ thể, tải lượng PHẢI là một cá thể EPCISQueryDocument có thành phần EPCISBody chứa một trong ba thành phần được nêu trong bảng bên dưới, theo phương thức của Giao diện gọi lại truy vấn đang được gọi:

Bảng 42 – Thành phần trong cá thể EPCISQueryDocument có EPCISBody

Phương thức giao diện gọi lại truy vấn	Nội dung tải lượng
callbackResults	QueryResults
callbackQueryTooLargeException	QueryTooLargeException
callbackImplementationException	ImplementationException

Trong mọi trường hợp, các trường queryName và subscriptionID của thành phần bodyload PHẢI chứa giá trị queryName và subscriptionID, theo trình tự tương ứng, được cung cấp trong cuộc gọi để đăng kí tạo truy vấn thường trực.

11.4.2  Liên kết HTTP của giao diện gọi lại truy vấn

Liên kết HTTP cung cấp cho việc phân phối các kết quả truy vấn thường trực trong XML thông qua giao thức HTTP bằng cách sử dụng thao tác POST. Việc triển khai CÓ THỂ cung cấp hỗ trợ cho sự ràng buộc này.

Cú pháp cho URI đích HTTP được sử dụng bởi EPCIS PHẢI được định nghĩa trong [RFC2616], 3.2.2. Thông thường, URI HTTP có một trong hai dạng sau:

http://host:port/remainder-of-URL

http://host/remainder-of-URL

Trong đó:

– host là tên của DNS hoặc địa chỉ IP của host nơi người nhận đang lắng nghe các kết nối HTTP đến.

– port là cổng TCP mà người nhận đang nghe các kết nối HTTP đến. Cổng và kí tự dấu hai chấm trước đó có thể bị bỏ qua, trong trường hợp này cổng PHẢI mặc định là 80.

– remainder-of-URL là URL mà thao tác HTTP POST sẽ được hướng dẫn.

Việc triển khai EPCIS PHẢI cung cấp kết quả truy vấn bằng cách gửi yêu cầu HTTP POST tới người nhận được quy định trong URI, trong đó remainder-of-URL được bao gồm trong HTTP request-line (như được định nghĩa trong [RFC2616]), và tải lượng là tài liệu XML như được quy định trong 11.4.1.

Sự giải thích bằng cách thực hiện EPCIS có mã phản hồi được trả bởi người nhận nằm ngoài phạm vi của tiêu chuẩn này; tuy nhiên, tất cả các triển khai PHẢI giải thích mã phản hồi 2xx (tức là, bất kì mã phân hồi nào trong khoảng từ 200 đến 299, kể cả 299) là phản hồi bình thường, không phải là dấu hiệu của bất kì lỗi nào.

11.4.3  Kết nối HTTPS của giao diện gọi lại truy vấn

Kết nối HTTPS cung cấp cho việc phân phối kết quả truy vấn thường trực trong XML thông qua giao thức HTTP bằng cách sử dụng thao tác POST, được bảo mật qua TLS. Việc triển khai có THỂ cung cấp hỗ trợ cho sự ràng buộc này.

Cú pháp cho các URI đích HTTPS khi được sử dụng bởi EPCIS PHẢI như được định nghĩa trong [RFC2818], 2.4; lần lượt giống với cú pháp được định nghĩa trong [RFC2616], 3.2.2, với sự thay thế https cho http. Thông thường, URI HTTPS có một trong hai dạng sau:

https://host:port/remainder-of-URL

https://host/remainder-of-URL

Trong đó:

– host là tên của DNS hoặc địa chỉ IP của host nơi người nhận đang lắng nghe các kết nối HTTP đến.

– port là cổng TCP mà người nhận đang nghe các kết nối HTTP đến. Cổng và kí tự dấu hai chấm trước đó có thể bị bỏ qua, trong trường hợp này cổng PHẢI mặc định là 80.

– remainder-of-URL là URL mà thao tác HTTP POST sẽ được hướng dẫn.

Việc triển khai EPCIS PHẢI cung cấp kết quả truy vấn bằng cách gửi yêu cầu HTTP POST tới người nhận được quy định trong URI, trong đó remainder-of-URL được bao gồm trong HTTP request-line (như được định nghĩa trong [RFC2616]), và tải lượng là tài liệu XML như được quy định trong 11.4.1.

Đối với kết nối HTTPS, HTTP PHẢI được sử dụng trên TLS như được định nghĩa trong [RFC2818]. TLS cho mục đích này PHẢI được thực hiện như được định nghĩa trong [RFC2246] ngoại trừ bộ mật mã quy định là TLS_RSA_WITH_AES_128_CBC_SHA, như được định nghĩa trong [RFC3268] với Compression Method, null.

Việc triển khai CÓ THỂ hỗ trợ thêm các thuật toán mã hóa và thuật toán nén như mong muốn

Sự giải thích bằng cách thực hiện EPCIS có mã phản hồi được trả bởi người nhận nằm ngoài phạm vi của tiêu chuẩn này; tuy nhiên, tất cả các triển khai PHẢI giải thích mã phản hồi 2xx (tức là, bất kì mã phản hồi nào trong khoảng từ 200 đến 299, kể cả 299) là phản hồi bình thường, không phải là dấu hiệu của bất kì lỗi nào.

11.4.4  Ràng buộc AS2 của giao diện gọi lại truy vấn

Ràng buộc AS2 cung cấp cho việc phân phối các kết quả truy vấn thường trực trong XML thông qua AS2 [RFC4130]. Việc triển khai CÓ THỂ cung cấp hỗ trợ cho sự ràng buộc này.

Cú pháp cho các URI đích AS2 được sử dụng bởi EPCIS PHẢI như sau:

as2:remainder-of-URI

Trong đó:

– remainder-of-URI xác định cấu hình giao tiếp AS2 cụ thể sẽ được Dịch vụ EPCIS sử dụng để cung cấp thông tin cho người đăng kí. Cú pháp của remainder-of-URI là đặc thù cho Dịch vụ EPCIS cụ thể mà đã được đăng kí, tùy thuộc vào ràng buộc rằng URI hoàn chỉnh PHẢI phù hợp với cú pháp URI như được định nghĩa bởi [RFC2396].

Thông thường, giá trị của remainder-of-URI là một chuỗi đặt tên cho một cấu hình giao tiếp AS2 cụ thể, trong đó cấu hình ngụ ý những thứ như URL HTTP mà các tin nhắn AS2 sẽ được gửi đi, các chứng chỉ bảo mật để sử dụng, v.v … Giao diện truy vấn EPCIS muốn sử dụng AS2 để phân phối kết quả truy vấn thường trực phải được sắp xếp trước với nhà cung cấp Dịch vụ EPCIS giá trị cụ thể của remainder-of-URI để sử dụng.

Không bắt buộc: Giải thích: Việc sử dụng AS2 thường yêu cầu sắp xếp trước giữa các bên giao tiếp, vì mục đích trao đổi giấy chứng nhận và thương lượng ngoài băng tần khác như là một phần của thỏa thuận đối tác thương mại song phương (xem [RFC4130] 5.1). Phần remainder-of-URI của AS2 URI về cơ bản là một tên đề cập đến kết quả của một sắp xếp trước cụ thể của loại này.

Việc triển khai EPCIS PHẢI cung cấp kết quả truy vấn bằng cách gửi tin nhắn AS2 theo [RFC4130]. Tải lượng tin nhắn AS2 PHẢI là một tài liệu XML như được chỉ ra trong 11.4.1.

Cả hai dịch vụ EPCIS và người nhận kết quả truy vấn thường trực đều tuân thủ các yêu cầu và NÊN tuân thủ các khuyến nghị được liệt kê trong tài liệu GS1 “EDIINT AS1 và Hướng dẫn truyền thông vận tải AS2” [EDICG] Để tham khảo, các phần liên quan của tiêu chuẩn này được cho trong 11.3.

12  Sự phù hợp

Tiêu chuẩn EPCIS định nghĩa cả dữ liệu sự kiện chuẩn và giao diện chuẩn giữa các thành phần hệ thống truyền dữ liệu sự kiện. Cả hai định dạng dữ liệu và các giao diện có thể được thực hiện bởi nhiều thành phần của phần mềm và dữ liệu trong bất kì hệ thống nào.

Phần này xác định ý nghĩa của việc tuân theo tiêu chuẩn EPCIS. Vì có nhiều loại thành phần hệ thống có khả năng tương thích với các phần khác nhau của tiêu chuẩn EPCIS, chúng được liệt kê dưới đây. Trong văn bản theo sau, bất kì tham chiếu nào đến một phần của tiêu chuẩn EPCIS phải được hiểu để tham khảo toàn bộ phần đó, bao gồm các phần phụ.

12.1  Sự phù hợp của dữ liệu EPCIS

Tài liệu điện tử tuân theo tiêu chuẩn EPCIS khi tất cả các điều sau là đúng:

– Tài liệu là một tài liệu XML đúng ngữ pháp phù hợp với [XML1.0].

– Tài liệu phù hợp với lược đồ XML cho EPCISDocument được chỉ rõ trong 9.5, lược đồ XML cho EPCISMasterDataDocument được chỉ rõ trong 9.7 hoặc lược đồ XML cho EPCISQueryDocument được chỉ định trong 11.1, cũng như tất cả các ràng buộc bổ sung được quy định trong phần tương ứng.

– Tất cả dữ liệu sự kiện EPCIS trong tài liệu (nếu có) phù hợp với các định nghĩa của dữ liệu sự kiện EPCIS được quy định trong điều 7 và các điều nhỏ của nó.

– Tất cả dữ liệu chủ trong tài liệu (nếu có) phù hợp với các ràng buộc khi dữ liệu chủ được xác định trong 6.1.1, 6.5 và 9.4.

– Tất cả việc sử dụng cơ chế mở rộng (nếu có) phù hợp với các ràng buộc được quy định trong 9.1.

– Nếu có một Tiêu đề Tài liệu kinh doanh Chuẩn, thì nó phù hợp với các ràng buộc được quy định trong 9.2.

Nhiều ứng dụng của EPCIS sẽ yêu cầu, ngoài sự phù hợp với tiêu chuẩn EPCIS, dữ liệu đó tuân theo tiêu chuẩn từ vựng kinh doan cốt lõi EPCIS [CBV1.2]. Tiêu chuẩn CBV định nghĩa hai mức độ phù hợp được gọi là “sự phù hợp CBV” và “Tương thích CBV”. Xem tiêu chuẩn CBV để biết chi tiết.

12.2  Sự phù hợp của các khách hàng giao diện truy vấn EPCIS

Một hệ thống phù hợp với tiêu chuẩn EPCIS là khách giao diện truy cập khi tất cả các điều sau là đúng:

– Hệ thống phù hợp với tất cả các tuyên bố xuất hiện trong 10.1 hoặc 10.2 được quy định là liên quan đến “khách hàng truy cập”.

Một hệ thống như vậy được cho là phù hợp với ràng buộc cụ thể của giao diện truy cập (hoặc nhiều hơn một liên kết) phụ thuộc vào tiểu mục nào của 10 nó phù hợp.

12.3  Sự phù hợp của các máy chủ giao diện truy vấn EPCIS

Một hệ thống phù hợp với tiêu chuẩn EPCIS là máy chủ giao diện truy cập khi tất cả các nội dung sau là đúng:

– Hệ thống phù hợp với các tuyên bố nêu trong 8.1.

– Hệ thống phù hợp với tất cả các tuyên bố nêu trong 10.1 hoặc 10.2 được quy định là liên quan đến “máy chủ chụp”.

– Hệ thống xử lý trường recordTime trong các sự kiện EPCIS như được quy định trong bảng trong 7.4.1.

Một hệ thống như vậy được cho là phù hợp với một ràng buộc cụ thể của giao diện truy cập (hoặc nhiều hơn một kết nối) tùy thuộc vào điều mà nó phù hợp của điều 10.

12.4  Sự phù hợp của các khách hàng giao diện truy vấn EPCIS

Một hệ thống phù hợp với tiêu chuẩn EPCIS là khách giao diện truy vấn khi một trong hai hoặc cả hai điều sau là đúng:

– Hệ thống phù hợp với định nghĩa của một “người gửi” như được quy định trong [WSI] và gửi các tin nhắn phù hợp với quy định kĩ thuật WSDL trong 11.2.

– Hệ thống phù hợp với tất cả các tuyên bố nêu trong 11.3 được chỉ ra là liên quan đến “ứng dụng khách truy vấn”.

Một hệ thống như vậy được cho là phù hợp với một ràng buộc cụ thể của giao diện truy vấn (hoặc nhiều hơn một ràng buộc) tùy thuộc vào điều mà nó phù hợp của điều 11.

12.5  Sự phù hợp của các máy chủ giao diện truy vấn EPCIS

Một hệ thống phù hợp với tiêu chuẩn EPCIS là máy chủ giao diện truy vấn khi tất cả các điều sau là đúng:

– Hệ thống phù hợp với các tuyên bố nêu trong 8.2.

– Khi hệ thống xử lý truy vấn dữ liệu chủ, dữ liệu chủ được trả về phù hợp với các ràng buộc khi dữ liệu chủ được xác định trong hàng đầu tiên của bảng trong 6.1.1.

– Hệ thống bao gồm trường recordTime trong tất cả các sự kiện EPCIS được trả lại dưới dạng kết quả truy vấn, như được chỉ rõ trong bảng trong 7.4.1.

– Một hoặc cả hai điều sau là đúng:

– Hệ thống phù hợp với định nghĩa của “người nhận” như được quy định trong [WSI], nhận các tin nhắn phù hợp với quy định kĩ thuật WSDL trong 11.2, và cũng tuân theo các ràng buộc bổ sung được quy định trong 11.2.

– Hệ thống phù hợp với tất cả các tuyên bố nêu trong 11.3 được chỉ ra là liên quan đến “máy chủ truy vấn”.

Một hệ thống như vậy được cho là phù hợp với một ràng buộc cụ thể của giao diện truy vấn (hoặc nhiều hơn một ràng buộc) tùy thuộc vào điều mà nó phù hợp của điều 11.

12.6  Sự phù hợp của việc triển khai giao diện gọi lại truy vấn EPCIS

Một hệ thống phù hợp với tiêu chuẩn EPCIS về việc triển khai giao diện gọi lại truy vấn khi nó tuân theo các tuyên bố nêu trong một hoặc nhiều điều khoản thuộc điều 11.4. Một hệ thống như vậy được cho là phù hợp với một ràng buộc cụ thể của giao diện gọi lại truy vấn (hoặc nhiều hơn một ràng buộc) tùy thuộc vào điều khoản nào mà nó phù hợp.

 

Thư mục tài liệu tham khảo

[ALE1.0] EPCglobal, “The Application Level Events (ALE) Specification, Version 1.0,” EPCglobal Standard Specification, September2005, http://www.gs1.org/ale.

[ALE1.0] EPCglobal, “Quy định kĩ thuật về sự kiện mức ứng dụng (ALE), Phiên bản 1.0,” Quy định kĩ thuật đối với tiêu chuẩn EPCglobal, tháng 9 năm 2005, http://www.gs1.org/ale.

[CBV1.2] GS1, “GS1 Core Business Vocabulary (CBV) Version 1.2 Standard,” GS1 Standard, June 2016, http://www.gs1.org/epcis. CBV1.2] GS1, “Từ vựng kinh doanh coota lõi GS1 (CBV) phiên bản 1.2”, tiêu chuẩn GS1, tháng 6 năm 2016, http://www.gs1.org/epcis.

[CEFACT20] United Nations Economic Commission for Europe, “Recommendation 20: Codes for Units of Measure Used in International Trade,” September 2010, http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_Rev7e_2010.zip.

[CEFACT20] Ủy ban kinh tế Liên Hợp Quốc ở Châu Âu, “Đề xuất 20: Mã cho các đơn vị đo lường được sử dụng trong thương mại quốc tế”, tháng 9 năm 2010, http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_Rev7e_2010.zip.

[EDICG] GS1, “EDIINT AS1 and AS2 Transport Communications Guidelines,” GS1 Technical Document, February 2006, http://www.gs1.org/gs1-xml/guideline/ediint-as1-and-as2-transport-communication-guidelines. [EDICG] GS1, “EDIINT AS1 và Hướng dẫn truyền thông vận tải AS2”, Tài liệu kĩ thuật GS1, tháng 2 năm 2006, http://www.gs1.org/gs1-xml/guideline/ediint-as1-and-as2-transport-communication-guidelines.

[ISODir2] ISO, “Rules for the structure and drafting of International Standards (ISO/IEC Directives, Part 2, 2001, 4th edition),” July 2002. [ISODir2] ISO, “Quy tắc về cấu trúc và soạn thảo các tiêu chuẩn quốc tế (Chỉ thị ISO / IEC, Phần 2, 2001, phiên bản lần thứ 4),” tháng 7 năm 2002.

[RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, “Uniform Resource Locators (URL),” RFC 1738, December 1994, http://www.ietf.org/rfc/rfc1738. [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill “Các nhà định vị tài nguyên đồng nhất (URL),” RFC 1738, tháng 12 năm 1994, http://www.ietf. org/rfc/rfc1738.

[RFC2141] R. Moats, “URN Syntax,” Internet Engineering Task Force Request for Comments RFC-2141, May 1997, http://www.ietf.org/rfc/rfc2141.txt. [RFC2141] R. Moats, “Cú pháp URN”, Các yêu cầu nhận xét của nhóm kĩ thuật internet đặc biệt [RFC-2141], tháng 5 năm 1997, http://www.ietf.org/rfc/rfc2141.txt.

[RFC2246] T. Dierks, C. Allen, “The TLS Protocol, Version 1.0,” RFC2246, January 1999, http://www.ietf.org/rfc/rfc2246. [RFC2246] T. Dierks, C. Allen, “Giao thức TLS Phiên bản 1.0,” RFC2246, tháng 1 năm 1999, http://www.ietf.org/rfc/rfc2246.

[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” RFC2396, August 1998, http://www.ietf.org/rfc/rfc2396. [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, “Mã phân định tài nguyên đồng nhất (URI): Cú pháp chung,” RFC2396, tháng 8 năm 1998, http://www.ietf.org/rfc/rfc2396.

[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” RFC2616, June 1999, http://www.ietf.org/rfc/rfc2616. [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, “Giao thức truyền siêu văn bản – HTTP/1.1,” RFC2616, tháng 6 năm 1999, http://www.ietf.org/rfc/rfc2616.

[RFC2818] E. Escorla, “HTTP Over TLS,” RFC2818, May 2000, http://www.ietf.org/rfc/rfc2818. [RFC2818] E. Escorla, “HTTP qua TLS”, RFC2818, tháng 5 năm 2000, http://www.ietf.org/rfc/rfc2818.

[RFC3268] P. Chown, “Advanced Encryption Standard (AES) Cipersuites for Transport Layer Security (TLS),” RFC3268, June 2002, http://www.ietf.org/rfc/rfc3268. [RFC3268] P. Chown, “Cipersuites tiêu chuẩn mã hóa nâng cao (AES) cho bảo mật tầng truyền tải (TLS),” RFC3268, tháng 6 năm 2002, http://www.ietf.org/rfc/rfc3268.

[RFC4130] D. Moberg and R. Drummond, “MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2),” RFC4130, July 2005, http://www.ietf.org/rfc/rfc4130. [RFC4130] D. Moberg và R. Drummond, “Trao đổi dữ liệu kinh doanh ngang hàng dựa trên MIME dựa trên dữ liệu sử dụng HTTP, Tuyên bố về khả năng áp dụng 2 (AS2),” RFC4130, tháng 7 năm 2005, http://www.ietf.org/rfc/rfc4130 ..

[SBDH] United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), “Standard Business Document Header Technical Specification, Version 1.3,” June 2004, http://www.gs1.org/services/gsmp/kc/ecom/xml/xml_sbdh.html [SBDH] Trung tâm hỗ trợ thương mại và kinh doanh điện tử của Liên hợp quốc (UN / CEFACT), “Quy định kĩ thuật về tiêu đề tài liệu tiêu chuẩn, Phiên bản 1.3,” tháng 6 năm 2004, http://www.gs1.org/services/gsmp/kc/ecom/xml/xml_sbdh.html

[TDS1.9] GS1, “GS1 EPCglobal Tag Data Standards Version 1.9,” GS1 Standard, June 2014, http://www.gs1.org/epc/tag-data-standard [TDS1.9] GS1, “Tiêu chuẩn dữ liệu thẻ EPCglobal GS1 phiên bản 1.9,” tiêu chuẩn GS1, tháng 6 năm 2014, http://www.gs1.org/epc/tag-data-standard

[WSDL1.1] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services Description Language (WSDL) 1.1,” W3C Note, March 2001, http://www.w3.org/TR/2001/NOTE-wsdl-20010315. [WSDL1.1] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Ngôn ngữ mô tả dịch vụ web (WSDL) 1.1,” W3C Note, March 2001, http://www.w3.org/TR/ 2001/NOTE-wsdl-20010315.

[WSI] K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, “Basic Profile Version 1.0,” WS-i Final Material, April 2004, http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html. [WSI] K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, “Hồ sơ cơ bản Phiên bản 1.0,” Tài liệu cuối cùng của WS-i, tháng 4 năm 2004, http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html.

[XML1.0] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, “Extensible Markup Language (XML) 1.0 (Third Edition),” W3C Recommendation, February 2004, http://www.w3.org/TR/2004/REC-xml-20040204/. [XML1.0] T. Bray, J. Paoli, CM Sperberg-McQueen, E. Maler, F. Yergeau, “Ngôn ngữ đánh dấu mở rộng (XML) 1.0 (Ấn bản thứ ba),” Khuyến cáo của W3C, tháng 2 năm 2004, http://www.w3.org/TR/2004/REC-xml-20040204/.

[XMLDR] “XML Design Rules for EAN.UCC, Version 2.0,” February 2004. [XMLVersioning] D. Orchard, “Versioning XML Vocabularies,” December 2003, http://www.xml.com/pub/a/2003/12/03/versioning.html. [XMLDR] “Quy tắc thiết kế XML cho EAN.UCC, Phiên bản 2.0,” tháng 2 năm 2004. [XMLVersioning] D. Orchard, “Phiên bản từ vựng XML”, tháng 12 năm 2003, http://www.xml.com/pub/a/2003/12/03/versioning.html.

[XSD1] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “XML Schema Part 1: Structures,” W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/. [XSD1] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “Lược đồ XML Phần 1: Các cấu trúc,” Khuyến nghị của W3C, tháng 5 năm 2001, http://www.w3.org/TR/xmlschema-1/.

[XSD2] P. Biron, A. Malhotra, “XML Schema Part 2: Datatypes,” W3C Recommendation, May 2001, http://www,w3.org/TR/xmischema– [XSD2] P. Biron, A. Malhotra, “Lược đồ XML Phần 2: Các loại dữ liệu.” Khuyến cáo của W3C, tháng 5 năm 2001,

Non-normative references:

[GSIArch] “The GS1 System Architecture,” GS1 technical document, April 2015,

http://www.gs1.org/docs/gsmp/architecture/GS1_System_Architecture.pdf Tham chiếu không bắt buộc:[GS1Arch] “Cấu trúc hệ thống GS1,” tài liệu kĩ thuật GS1, tháng 4 năm 2015, http://www.gs1.org/docs/gsmp/architecture/GS1_System_Architecture.pdf

[EPCAF] K. R. Traub et al, “EPCglobal Architecture Framework,” EPCglobal technical document July 2005, http://www.epcglobalinc.org/standards/architecture/architecture_1_0-standard- 20050701.pdf[EPCAF] K. R. Traub và cộng sự, “Khung cấu trúc EPCglobal,” Tài liệu kĩ thuật EPCglobal, tháng 7 năm 2005, http://www.epcglobalinc.org/standards/architecture/architecture_1_0-standard-20050701.pdf

[EPCISGuideline] GS1, “EPCIS and CBV Implementation Guideline,” GS1 Guideline, October 2015, http://www.gs1.org/docs/epc/EPCIS_Guideline.pdf. [EPCISGuideline] GS1, “Hướng dẫn triển khai EPCIS và CBV,” Hướng dẫn GS1, tháng 10 năm 2015, http://www.gs1.org/docs/epc/EPCIS_Guideline.pdf.

 

MỤC LỤC

Lời nói đầu

Lời giới thiệu

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ và định nghĩa

4  Mối quan hệ với cấu trúc hệ thống GS1 và nguyên tắc về các quy định của EPCIS

4.1  Tổng quan về tiêu chuẩn GS1

4.2  EPCIS trong mối quan hệ với các tầng “Truy cập” và “Chia sẻ”

4.3  EPCIS trong mối quan hệ với các đối tác thương mại

4.4  EPCIS trong mối quan hệ với các thành phần cấu trúc của hệ thống GS1 khác

4.5  Nguyên tắc về các quy định của EPCIS

5  Khung quy định kĩ thuật EPCIS

5.1  Tầng

5.2  Khả năng mở rộng

5.3  Khả năng môđun hóa

6  Tầng mô hình dữ liệu trừu tượng

6.1  Dữ liệu về sự kiện và dữ liệu chủ

6.2  Loại từ vựng

6.3  Cơ chế mở rộng

6.4  Mô tả mã phân định

6.5  Từ vựng phân cấp

7  Tầng định nghĩa dữ liệu

7.1  Quy tắc chung đối với quy định mô đun tầng định nghĩa dữ liệu

7.2  Mô đun loại sự kiện cốt lõi – Tổng quan

7.3  Mô đun loại sự kiện cốt lõi – khối cấu trúc

7.4  Mô-đun loại sự kiện cốt lõi – sự kiện

8  Tầng dịch vụ

8.1  Mô đun hoạt động chụp lõi

8.2  Mô-đun hoạt động truy vấn cốt lõi

9  Các ràng buộc XML đối với các môđune xác định/định nghĩa dữ liệu

9.1  Cơ chế mở rộng

9.2  Tiêu đề tài liệu kinh doanh chuẩn

9.3  Giản đồ cơ sở EPCglobal

9.4  Dữ liệu chủ trong liên kết XML

9.5  Lược đồ cho các loại sự kiện cốt lõi

9.6  Các loại sự kiện cốt lõi

9.7  Lược đồ đối với tài liệu dữ liệu chuẩn

10  Ràng buộc đối với mô-đun hoạt động truy cập cốt lõi

10.1  Ràng buộc xếp hàng tin nhắn

10.2  Ràng buộc HTTP

11  Các ràng buộc đối với môđune hoạt động truy vấn cốt lõi

11.1  Lược đồ XML cho mô đun hoạt động truy vấn lõi

11.2  Ràng buộc SOAP / HTTP đối với giao diện kiểm soát truy vấn

11.3  Ràng buộc AS2 đối với giao diện kiểm soát truy vấn

11.4  Các ràng buộc đối với giao diện gọi lại truy vấn

12  Sự phù hợp

Thư mục tài liệu tham khảo