Understanding the Event, Master Data, and Data Exchange Services

Event Service

In the RFID Enterprise Server, there are two types of RFID-related data: event data and master data.

Event data arises in the course of carrying out business processes, and is captured through the EPCIS capture interface and made available for query through the EPCIS query interface. An example of event data is "At Time T, Object X was observed at Location L." Event data is captured at the edge and sent (SOAP, JMS queue, or HTTP) either to an RFID Enterprise Server for storage in the event repository or directly to an application.

Event data grows in quantity as more business is transacted, and refers to things that happen at specific moments in time. There is no mechanism to delete or modify an event; events are retracted or corrected via a new event whose business meaning is to rescind or amend the effect of a prior event.

Master data is additional data that provides the necessary context for interpreting event data. It is available for filtering a query through the EPCIS Query Interface, and available as part of a report through the Reporting Service. An example of master data is "Location L refers to the distribution center located at 123 Elm Street, Anytown, US." Master data does not come from the edge; it is created and maintained through the Master Data Administration Console, which is provided with WebLogic RFID Enterprise Server.

Master data does not grow merely because more business is transacted. It is not typically tied to specific moments in time and it provides interpretation for elements of event data. For more information about the master data service, see Master Data Service.

Each event is of a specific event type, and contains event fields which provide information about the event. The following sections describe event types and fields; the last section provides an example showing how event data is formatted as XML when sending data from the edge to the enterprise:

Figure 3-1 shows that the event service receives RFID event data from an RFID Enterprise Server or a custom application, stores the data in the event repository, and interacts with the engines in other subsystems to integrate the data with master data and make the data available to the reporting and data exchange services.

Note:

There is no GUI associated with the event service because the service does not require interactive input from administrators or users. Once its database and input mechanisms are configured for the host WebLogic Server, the event service accepts properly formatted event data input from the edge, stores the data in the event repository, and interacts with the other services without further ado.

Note:

For information about sending event data from WebLogic RFID Edge Server to WebLogic RFID Enterprise Server, see the Edge Server documentation at:

Note:

http://download.oracle.com/docs/cd/E13197_01/rfid/edge_server/docs21/workflow_reference/index.html

Figure 3-1 Event Service

The remainder of this introductory section contains Listing 3-1, an XML example of data for a single event, and Figure 3-2 which shows how some event fields reference master data associated with that event.

Listing 3-1 shows data for an event of type ObjectEvent formatted as XML. This type of information is what the RFID Enterprise Server receives from the edge and stores in the event repository for later retrieval via a query.

Listing 3-1 ObjectEvent Data in XML Format

<ObjectEvent>
  <eventTime>2006-04-03T20:33:31.116-05:00</eventTime>
  <epcList>
    <epc>urn:epc:id:sgtin:0614141.100734.400.3</epc>
  </epcList>
  <action>OBSERVE</action>
  <bizStep>urn:epcglobal:epcis:bizstep:fmcg:shipped</bizStep>
  <disposition>urn:epcglobal:epcis:disp:fmcg:unknown</disposition>
  <readPoint>
    <id>urn:epc:id:sgln:0614141.07347.1234</id>
  </readPoint>
  <bizLocation>
    <id>urn:epc:id:sgln:0614141.33254.0</id>
  </bizLocation>
  <bizTransactionList>
    <bizTransaction type="urn:epcglobal:fmcg:btt:po">
       http://transaction.acme.com/po/1234
    </bizTransaction>
  </bizTransactionList>
</ObjectEvent>

The eventTime indicates that the event occurred on April 3, 2006.
Because there is only one URN in the epcList, the event contains data only for a single item.
According to the action, the item was merely observed at this location.
The elements bizStep, disposition, readPoint, bizLocation, and bizTransactionList are examples of event fields that have corresponding master data types; in this case: Business Step, Disposition, Read Point, Business Location, Business Transaction, and Business Transaction Type.

Figure 3-2 illustrates the relationship between events and master data. The name of an event field (bizLocation) can provide a reference to a master data type (Business Location), and the value of an event field (urn:epc:id:sgln:0614141.33254.0) can reference a master data entry that points to the master data attributes associated with that URN. This use of event fields and values as indexes into a master data repository is the simple mechanism that associates business-context information with a specific event. (Children are discussed in Master Data Service.)

Figure 3-2 Event and Master Data

Event Types

There are five event types, one generic event and four subclasses. Table 3-1 describes these event types.

Table 3-1 Event Types
Event Type	Description
`EPCISEvent`	A generic base class for all event types; it provides date and time fields. You cannot capture or query an EPCISEvent; you can capture and query the following four events, which inherit these two fields.
`ObjectEvent`	An event that happened to one or more entities denoted by EPCs.
`AggregationEvent`	An event that happened to one or more EPC-denoted entities that are physically aggregated (constrained to be in the same place at the same time, as when cases are aggregated to a pallet).
`QuantityEvent`	An event concerned with a specific number of objects all having the same type, but where the individual instances are not identified. For example a quantity event could report that an event happened to 200 boxes of widgets, without identifying specifically which boxes were involved. Quantity events can serve as a bridge between RFID systems and legacy inventory systems that do not identify individuals items.
`TransactionEvent`	An event in which one or more EPC-denoted entities become associated or disassociated with an identified business transaction.

The following sections provide descriptions of these event types and show the relevant portions of the XML schema (XSD):

EPCISEvent

EPCISEvent is a common base type for all EPCIS events, providing date and time information.

<xsd:complexType name="EPCISEventType" abstract="true">
  <xsd:sequence>
    <xsd:element name="eventTime" type="xsd:dateTime"/>
    <xsd:element name="recordTime" type="xsd:dateTime" minOccurs="0"/>
    ...

  </xsd:sequence>
  <xsd:anyAttribute processContents="lax"/>
</xsd:complextype>

For descriptions of the fields, see Table 3-2.

ObjectEvent

Logically, an ObjectEvent pertains to a single object identified by an EPC. However, you can specify more than one EPC in an epcList when the remaining ObjectEvent data applies to all the EPCs in the list. The ability to provide more than one EPC in an ObjectEvent is simply a shorthand to reduce the volume of data in the case where several EPCs experience an identical event.

In an ObjectEvent, no relationship among the EPCs is implied by their appearing in the same ObjectEvent, other than the coincidence of them all being captured with identical information. By contrast, an AggregationEvent or TransactionEvent conveys an implicit association among the EPCs in the event.

<xsd:complexType name="ObjectEventType">
  <xsd:complexContent>
    <xsd:extension base="epcis:EPCISEventType">
      <xsd:sequence>
        <xsd:element name="epcList" type="epcis:EPCListType"/>
        <xsd:element name="action" type="epcis:ActionType"/>
        <xsd:element name="bizStep" type="epcis:BusinessStepIDType"
          minOccurs="0"/>
        <xsd:element name="disposition" type="epcis:DispositionIDType"
          minOccurs="0"/>
        <xsd:element name="readPoint" type="epcis:ReadPointType"
          minOccurs="0"/>
        <xsd:element name="bizLocation" type="epcis:BusinessLocationType"
          minOccurs="0"/>
        <xsd:element name="bizTransactionList"
          type="epcis:BusinessTransactionListType" minOccurs="0"/>
        ...
      </xsd:sequence>
      <xsd:anyAttribute processContents="lax"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

For field descriptions, see Table 3-2.

AggregationEvent

An AggregationEvent describes events related to objects that have been physically aggregated. In such an event, there is a set of contained objects that have been aggregated within a containing entity which identifies the physical aggregation itself. An example of an aggregation is where cases are loaded onto a pallet and carried as a unit; the pallet may well have a tag, but the containing entity is not the physical pallet, it is the aggregate of the pallet and all the cases.

Because an AggregationEvent indicates aggregations among physical objects, the children are identified by EPCs. However, the parent entity is identified by an arbitrary URI (which may or may not be an EPC) because the parent is not necessarily a physical object that is separate from the aggregation itself.

For example, it is common in many manufacturing operations to create a load several steps before an EPC is assigned to that load. In such situations, an internal tracking number is assigned at the time the load is created, and this number is used up to the point of shipment. In terms of events, this flow could be modeled as separate AggregationEvents:

When the load is created, an AggregationEvent uses the internal tracking number as the parent identifier, expressed as a URI, with action equal to ADD.
At the point of shipment, the load is assigned an SSCC code, which is an EPC. A second AggregationEvent with action equal to ADD is generated at the time the SSCC is assigned. (The first association could also be invalidated by generating an AggregationEvent with action equal to DELETE at this time.)

<xsd:complexType name="AggregationEventType">
  <xsd:complexContent>
    <xsd:extension base="epcis:EPCISEventType">
      <xsd:sequence>
        <xsd:element name="parentID" type="epcis:ParentIDType"
          minOccurs="0"/>
        <xsd:element name="childEPCs" type="epcis:EPCListType"/>
        <xsd:element name="action" type="epcis:ActionType"/>
        <xsd:element name="bizStep" type="epcis:BusinessStepIDType"
          minOccurs="0"/>
        <xsd:element name="disposition" type="epcis:DispositionIDType"
          minOccurs="0"/>
        <xsd:element name="readPoint" type="epcis:ReadPointType"
          minOccurs="0"/>
        <xsd:element name="bizLocation" type="epcis:BusinessLocationType"
          minOccurs="0"/>
        <xsd:element name="bizTransactionList"
          type="epcis:BusinessTransactionListType" minOccurs="0"/>
        ...
      </xsd:sequence>
      <xsd:anyAttribute processContents="lax"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

For descriptions of the fields, see Table 3-2.

Note: In order to reset or to definitively set an aggregation, send an AggregationEvent with action DELETE and no children, followed by an AggregationEvent with action ADD and the definitive set of children.

QuantityEvent

A QuantityEvent captures an event that pertains to a specified quantity of an object class, but where the individual instances are not identified. A QuantityEvent is useful, for example, to report inventory levels of a product. In addition, quantity events can serve as a bridge between RFID systems and legacy inventory systems that do not identify individuals items.

Because an epcClass always denotes a specific packaging unit (for example, a 12-item case), there is no need for an explicit "unit of measure" field. The unit of measure is always the object class denoted by epcClass as defined in the master data for that object class.

<xsd:complexType name="QuantityEventType">
  <xsd:complexContent>
    <xsd:extension base="epcis:EPCISEventType">
      <xsd:sequence>
        <xsd:element name="epcClass" type="epcis:EPCClassType"/>
        <xsd:element name="quantity" type="xsd:int"/>
        <xsd:element name="bizStep" type="epcis:BusinessStepIDType"
          minOccurs="0"/>
        <xsd:element name="disposition" type="epcis:DispositionIDType"
          minOccurs="0"/>
        <xsd:element name="readPoint" type="epcis:ReadPointType"
          minOccurs="0"/>
        <xsd:element name="bizLocation" type="epcis:BusinessLocationType"
          minOccurs="0"/>
        <xsd:element minOccurs="0" name="bizTransactionList"
          type="epcis:BusinessTransactionListType"/>
        ...
      </xsd:sequence>
      <xsd:anyAttribute processContents="lax"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

For descriptions of the fields, see Table 3-2.

TransactionEvent

A TransactionEvent describes the association or disassociation of physical objects to one or more business transactions. While other event types have an optional bizTransactionList field that can be used to provide context for an event, the TransactionEvent is used to declare in an unequivocal way that certain EPCs have been associated or disassociated with one or more business transactions as part of the event.

<xsd:complexType name="TransactionEventType">
  <xsd:complexContent>
    <xsd:extension base="epcis:EPCISEventType">
      <xsd:sequence>
        <xsd:element name="bizTransactionList"
          type="epcis:BusinessTransactionListType"/>
        <xsd:element name="parentID" type="epcis:ParentIDType"
          minOccurs="0"/>
        <xsd:element name="epcList" type="epcis:EPCListType"/>
        <xsd:element name="action" type="epcis:ActionType"/>
        <xsd:element name="bizStep" type="epcis:BusinessStepIDType"
          minOccurs="0"/>
        <xsd:element name="disposition" type="epcis:DispositionIDType"
          minOccurs="0"/>
        <xsd:element name="readPoint" type="epcis:ReadPointType"
          minOccurs="0"/>
        <xsd:element name="bizLocation" type="epcis:BusinessLocationType"
         minOccurs="0"/>
        ...
      </xsd:sequence>
      <xsd:anyAttribute processContents="lax"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

For descriptions of the fields, see Table 3-2.

Event Fields

Table 3-2 lists each event field by its XSD name and type, describes the field's function, and, if a master data type is associated with the event field name, provides the master data type name. If the description is lengthy, the table provides a short description followed by a reference to a section containing a detailed explanation.

Table 3-2 Event Field Descriptions
Event Field (XSD name & type hierarchy)	Description, XML Example, and Associated Master Data Type
`action (ActionType)`(string)	One of `ADD`, `OBSERVE`, or `DELETE`. See action. XML example: `<action>ADD</action>` Associated master data type: none
`bizLocation (`BusinessLocationType) `(anyURI)`	The location where an object is assumed to be following an EPCIS event until the object is reported to be at a different `bizLocation` by a subsequent EPCIS event. A `bizLocation` consists of an `id` (`anyURI`). XML example: `<bizLocation> <id>urn:epc:id:sgln:0614141.33254.0</id> </bizLocation>` Associated master data type: Business Location
`bizStep (BusinessStepIDType) (anyURI)`	The business context of an event: what business process step was taking place that caused the event to be captured? An example is an identifier that means "shipped." XML example: `<bizStep> urn:epcglobal:epcis:bizstep:fmcg:shipped </bizStep>` Associated master data type: Business Step
`bizTransactionList <bizTransaction type=>` `(anyURI)`	A list describing one or more business transactions associated with the event. Each transaction (`bizTransaction`) element has an optional `type` attribute. XML example: `<bizTransactionList> <bizTransaction type="urn:epcglobal:fmcg:btt:po"> http://transaction.acme.com/po/54847 </bizTransaction> </bizTransactionList>` Associated master data types: Business Transaction, Business Transaction Type See bizTransactionList.
`childEPCs (EPCListType) (EPC)`	A list of EPCs (listEPC) represented in "pure identity" URI form as defined in Section 4.1 of the EPC Tag Data Standard Version 1.1 rev 1.27. XML example: `<childEPCs> <epc> urn:epc:id:sgtin:0614141.107346.2017 </epc> </childEPCs>` Associated master data type: none
`disposition (`DispositionIDType) `(anyURI)`	The business state of an object. An example is an identifier that means "available for sale." The disposition field of an event specifies the business condition of the event's objects, subsequent to the event. The disposition is assumed to hold true until another event indicates a change of disposition. Intervening events that do not specify a disposition field have no effect on the presumed disposition of the object. XML example: `<disposition> urn:epcglobal:epcis:disp:fmcg:unknown </disposition>` Associated master data type: Disposition
`epcClass (epcClassType) (anyURI)`	Classes of trade items. Any EPC whose structure incorporates the concept of object class can be referenced as an `epcClass`. EPCClass provides the standards for SGTIN EPCs. XML example: `<epcClass> urn:epc:idpat:sgtin:0652642.. </epcClass>` Associated master data type: EPCCLass
`epcList (EPCListType) (EPC)`	EPCs represented in "pure identity" URI form as defined in Section 4.1 of the EPC Tag Data Standard Version 1.1 rev 1.27. XML example: `<epcList> <epc> urn:epc:id:sgtin:0614141.107346.2017 </epc> </epcList>` Associated master data type: none
`eventTime (dateTime)`	The date and time at which the capturing application asserts the event occurred. XML example: `<eventTime> 2006-04-03T20:33:31.116-05:00 </eventTime>` Associated master data type: none
`parentID (ParentIDType`) `(anyURI)`	The identifier of the parent of the EPCs in `epcList` (a parent ID can be a URI that is not a URN). When the parent identifier is an EPC, it is represented in "pure identity" URI form as defined in Section 4.1 of the EPC Tag Data Standard Version 1.1 rev 1.27. XML example: `<parentID> urn:epc:id:sgtin:0614141.107346.2017 </parentID>` Associated master data type: none
`quantity (int)`	The number of objects within the class described by this event.
`readPoint (ReadPointType`) `(anyURI)`	The location that identifies the most specific place at which an EPCIS event took place. The `readPoint` for an event is determined by the capturing application, perhaps inferred as a function of logical reader if stationary readers are used, perhaps determined overtly by reading a location tag if the reader is mobile. Conceptually, `readPoint` identifies "how or where the EPCIS event was detected." A `readPoint` consists of an `id` (`anyURI`). XML example: `<readPoint> <id> urn:epc:id:sgln:0614141:07347.1234 </id> </readPoint>` Associated master data type: Read Point
`recordTime (dateTime)`	The date and time at which this event was recorded by an event repository. This field is always omitted when an event is presented to the capture interface, and always present when an event is retrieved from the query interface. The `recordTime` information is useful when interpreting results of standing queries (subscriptions). XML example: none Associated master data type: none

Table 3-3 shows which event fields are used by each event type. The R and O keys in the event type columns indicate whether a field is required (R) for that event or optional (O). The absence of a key means that the field is not used by that event type; for example, action is not used by QuantityEvent.

Table 3-3 Event Types: Required and Optional Fields
R = Required Field O = Optional Field	ObjectEvent	AggregationEvent	QuantityEvent	TransactionEvent
`action`	R	R		R
`bizLocation`	O	O	O	O
`bizStep`	O	O	O	O
`bizTransactionList`	O	O	O	R
`childEPCs`		R
`disposition`	O	O		O
`epcClass`			R
`epcList`	R			R
`eventTime`	R	R	R	R
`parentID`		R
`quantity`			R
`readPoint`	O	O	O	O
`recordTime`	¹

¹The recordTime field is omitted when an event is captured. It is supplied when an event is queried.

Each event type has event fields that represent the what, when, where, and why information for an event:

What object(s) or other entities are the subject of the event. For example, for an ObjectEvent the subject is an epcList; for a QuantityEvent the subject is an epcClass and quantity; for a TransactionEvent, the subject is a bizTransactionList.
When did the event occur: the date and time (the eventTime).
Where did the event occur: for example, readPoint and bizLocation.
Why did the event occur (the business context): for example, bizStep and disposition.

action

An action indicates how an event relates to the lifecycle of the entity.

The Action type is an enumerated type having three possible values: ADD, OBSERVE, or DELETE. Table 3-4 describes what these Action values mean for the three event types that include an action field as event data.

Table 3-4 Action Field Values
	ObjectEvent	AggregationEvent	TransactionEvent
`ADD`	EPCs in `epcList` are commissioned.	EPCs in `childEPCs` are aggregated to parent (added to the running tabulation for this aggregation). A parent identifier is required.	`EPCs` `in` `epcList` are associated with a transaction. Either with a new transaction or additional EPCs are added to existing transaction.
`OBSERVE`	Simple observation: neither a commission nor a decommission event.	Simple observation: there is no guarantee that all children are observed, or that the parent is either observed or known. A parent identifier is optional.	EPCs are confirmed as continuing to be associated with the transaction.
`DELETE`	EPCs in `epcList` are decommissioned.	EPCs in `childEPCs` are disaggregated. If `childEPCs` is omitted, all children are disaggregated. A parent identifier is required.	EPCs in `epcList` are disassociated from the transaction. If `epcList` is omitted, all children are disassociated.

For example, an AggregationEvent captures events related to physical aggregations of objects, such as cases aggregated to a pallet. Throughout its life, the pallet load participates in many business process steps, each of which may generate an EPCIS event. The action field of each event indicates how the aggregation itself has changed during the event: have objects been added to the aggregation, have objects been removed from the aggregation, or has the aggregation simply been observed without change to its membership? The action is independent of the business step, bizStep, which identifies the specific business process step in which the action took place.

bizTransactionList

A bizTransactionList identifies a particular business transaction, such as a specific purchase order. An ObjectEvent, QuantityEvent, or AggregationEvent may include bizTransactionList; a TransactionEvent must include bizTransactionList.

A business transaction is described by a pair of identifiers, bizTransaction and type. Each bizTransactionList contains one or more bizTransaction elements; each bizTransaction element may include a type attribute. Both bizTransaction and type are of type anyURI:

<bizTransactionList>
  <bizTransaction type=anyURI>anyURI</bizTransaction>
  ...  
</bizTransactionList>

If type is omitted, no information is available about the type of business transaction apart from what is implied by the value of the bizTransaction field itself.

The following XSD fragments show the relationships between bizTransactionList, bizTransaction, and type:

  <!-- bizTransactionList -->
  <xsd:element name="bizTransactionList"
     type="epcis:BusinessTransactionListType" minOccurs="0"/>

  <!-- bizTransactionListType -->
  <xsd:complexType name="BusinessTransactionListType">
    <xsd:sequence>
      <xsd:element name="bizTransaction"
         type="epcis:BusinessTransactionType" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

  <!-- BusinessTransactionType -->
  <xsd:complexType name="BusinessTransactionType">
    <xsd:simpleContent>
      <xsd:extension base="epcis:BusinessTransactionIDType">
        <xsd:attribute name="type"
          type="epcis:BusinessTransactionTypeIDType" use="optional"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>

An example of a business transaction is:

  <bizTransactionList>
    <bizTransaction type="urn:epcglobal:fmcg:btt:po">
       http://transaction.acme.com/po/54847
    </bizTransaction>
  </bizTransactionList>

The master data type associated with bizTransaction is Business Transaction. The master data type associated with type is Business Transaction Type.

EPCClass

EPCClass entries denote classes of trade items. Any EPC whose structure incorporates the concept of object class can be referenced as an EPCClass.

When an EPCClass represents a class of SGTIN EPCs, the following form is required:

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

CompanyPrefix is an EAN.UCC Company Prefix (including leading zeros)
ItemRefAndIndicator consists of the indicator digit of a GTIN followed by the digits of the item reference of a GTIN.

An EPCClass entry in this form denotes the class of objects whose EPCs are SGTINs (urn:epc:id:sgtin:...) having the same CompanyPrefix and ItemRefAndIndicator fields, and having any serial number whatsoever.

Events XML Example

The following document shows the results of a query that includes two events, one where an object (represented by EPC urn:epc:id:sgtin:0614141.107346.2017) travels from one location (represented by urn:epc:id:sgln:0614141.33254.0) to another (urn:epc:id:sgln:0614141.33482.0). The values for business step, disposition, and business transaction are all values chosen collaboratively by the implementers of the EPCIS data exchange solution. Because standards in certain industries are still under development, business partners may choose to agree on a set of values that satisfy their business needs.

<?xml version="1.0" encoding="UTF-8"?>
<epcis:EPCISDocument xmlns:epcis="urn:epcglobal:epcis:xsd:1"
 schemaVersion="1" creationDate="2006-07-11T11:30:47.0Z">

 <EPCISBody>
   <EventList>
      <ObjectEvent>
          <eventTime>2006-04-03T20:33:31.116-05:00</eventTime>
          <epcList>
              <epc>urn:epc:id:sgtin:0614141.107346.2017</epc>
          </epcList>
          <action>OBSERVE</action>
          <bizStep>urn:epcglobal:epcis:bizstep:fmcg:shipped</bizStep>
          <disposition>
             urn:epcglobal:epcis:disp:fmcg:transit
          </disposition>
          <readPoint>
              <id>urn:epc:id:sgln:0614141.07347.124</id>
          </readPoint>
          <bizLocation>
              <id>urn:epc:id:sgln:0614141.33254.0</id>
          </bizLocation>
          <bizTransactionList>
              <bizTransaction type="urn:epcglobal:fmcg:btt:po">
                  http://transaction.acme.com/po/54847
              </bizTransaction>
          </bizTransactionList>
      </ObjectEvent>
      <ObjectEvent>
          <eventTime>2006-04-04T20:33:31.116-05:00</eventTime>
          <epcList>
              <epc>urn:epc:id:sgtin:0614141.107346.2017</epc>
          </epcList>
          <action>OBSERVE</action>
          <bizStep>urn:epcglobal:epcis:bizstep:fmcg:received</bizStep>
          <disposition>
              urn:epcglobal:epcis:disp:fmcg:processing
          </disposition>
          <readPoint>
              <id>urn:epc:id:sgln:0614141.07473.384</id>
          </readPoint>
          <bizLocation>
              <id>urn:epc:id:sgln:0614141.33482.0</id>
          </bizLocation>
          <bizTransactionList>
              <bizTransaction type="urn:epcglobal:fmcg:btt:po">
                  http://transaction.acme.com/po/54847
              </bizTransaction>
          </bizTransactionList>
      </ObjectEvent>
    </EventList>
 </EPCISBody>
</epcis:EPCISDocument>