OASIS PPS (Production Planning and Scheduling) Standard deals with problems in all manufacturing companies who want to have a sophisticated information system for production planning and scheduling. PPS standard provides XML schema and communication protocols for information exchange among manufacturing application programs in the web-services environment. This document especially focuses on transaction messages that represent domain information in accordance with the context of the communication, as well as transaction rules for contexts such as pushing and pulling of the information required.

Status:

This document was last revised or approved by the PPS TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/pps/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/pps/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/pps/.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", PPS are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction. 7

1.1 Terminology. 7

1.2 Normative References. 7

1.3 Non-Normative References. 7

1.4 Conformance. 8

1.5 Terms and definitions. 8

2 Messaging model 9

2.1 Basic models. 9

2.2 Message classes. 9

2.3 Messaging models. 10

2.3.1 Add transaction. 10

2.3.2 Change transaction. 10

2.3.3 Remove transaction. 11

2.3.4 Notify transaction. 11

2.3.5 Sync transaction. 11

2.3.6 Get-Show transaction. 11

2.4 Procedures on responders. 12

2.4.1 Common tasks. 12

2.4.2 Confirm message. 12

2.4.3 Error handling. 12

3 Message document 14

3.1 Message Structure. 14

3.2 Transaction element 14

3.3 Multiple documents message. 16

4 Add, Change and Remove transaction. 17

4.1 Add transaction. 17

4.2 Change transaction. 18

4.2.1 Insert property. 18

4.2.2 Update property. 19

4.2.3 Delete property. 19

4.3 Remove transaction. 20

5 Notify and Sync Transactions. 21

5.1 Notify transaction. 21

5.2 Sync transaction. 21

5.2.1 Sync message. 22

5.2.2 Procedure of information owner 23

6 Information Query. 24

6.1 Target domain objects. 24

6.1.1 Selection by object IDs. 24

6.1.2 Selection by Property elements. 24

6.1.3 Disjunctive and conjunctive conditions. 25

6.1.4 Selection by wildcard. 26

6.2 Target domain property. 26

6.2.1 All available properties. 26

6.2.2 Selecting domain property. 27

6.2.3 Sorting by property value. 27

6.2.4 Calculation of property value. 28

6.3 Multiple property. 29

6.4 Using Header element 30

6.4.1 Query by header element 30

6.4.2 Count of domain objects. 31

6.5 Show message. 31

6.5.1 Structure of Show message. 31

6.5.2 Header in Show message. 31

7 XML Elements. 33

7.1 Error element 33

7.2 App element 34

7.3 Condition element 34

7.4 Selection element 35

7.5 Header element 35

7.6 Property element 36

A. Implementation level 38

B. Acknowledgements. 40

C. Revision History. 41

Figures

Figure 1 Basic types of messaging. 9

Figure 2 Add transaction. 10

Figure 3 Change transaction. 10

Figure 4 Remove transaction. 11

Figure 5 Notify transaction. 11

Figure 6 Sync transaction. 11

Figure 7 Get-Show transaction. 12

Figure 8 Add message transactions. 17

Figure 9 Change message transactions. 18

Figure 10 Remove message transactions. 20

Figure 11 Notify message transactions. 21

Figure 12 Sync message transaction. 22

Figure 13 Get -Show message transactions. 24

Figure 14 Single property and Multiple property. 29

1 Introduction

This part of PPS standard provides specifications of XML transaction elements for messaging between two application programs. XML representations of the messages consist of XML core elements that are defined in [PPS01]. This part defines additional XML elements and attributes that are needed to establish such communications.

From perspective of planning and scheduling in manufacturing management, there are many kinds of domain documents and domain objects. All of that information are sent or received in particular context such as notifying new information, requesting particular information, and so forth. This part prescribes communication protocols by categorizing such various transactions into simple models. This standard doesn’t focus on the underlying communication protocols, such as HTTP, SMTP and FTP. This standard allows all readers to select any low-level protocols to establish the communication properly in a secure way.

A transaction element corresponds to a message document which is sent or received as a message. This part does not define transaction element, but defines a data structure of transaction elements that may be created for any particular circumstances. Each transaction element has domain objects of production planning and scheduling. The domain objects are represented by nine primitive elements defined in [PPS01]. All domain objects defined in this standard are sub-classes of the primitive elements.

This part of the standard also defines messaging models of communication between two application programs, where a transaction element is sent as a message. In the messaging model, an initiator can invoke a service such as add, change and remove information of the responder. The initiator is also able to request of getting information by sending a query-like formatted message. This part of standard defines syntax and rules for such messaging models.

1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.2 Normative References

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[PPS01] PPS (Production Planning and Scheduling) Part 1: Core Elements, Version 1.0, Public Review Draft 01, http://www.oasis-open.org/committees/pps/

[PPS03] PPS (Production Planning and Scheduling) Part 3: Profile Specifications,
Version 1.0, Public Review Draft 01, http://www.oasis-open.org/committees/pps/

1.3 Non-Normative References

[PSLXWP] PSLX Consortium, PSLX White Paper - APS Conceptual definition and implementation, http://www.pslx.org/

[PSLX001] PSLX Technical Standard, Version 2, Part 1: Enterprise Model (in Japanese), Recommendation of PSLX Forum, http://www.pslx.org/

[PSLX002] PSLX Technical Standard, Version 2, Part 2: Activity Model (in Japanese), Recommendation of PSLX Forum, http://www.pslx.org/

[PSLX003] PSLX Technical Standard, Version 2, Part 3: Object Model (in Japanese), Recommendation of PSLX Forum, http://www.pslx.org/

1.4 Conformance

A document or message confirms OASIS PPS Transaction Messages if all elements in the artifact are consistent with the normative text of this specification, and the document can be processed properly with the XML schema that can be downloaded from the following URI.

http://docs.oasis-open.org/pps/v1.0/pps-transaction-messages.xsd

A Process or service conforms OASIS PPS Transaction Messages if the process or service can deal with the message that conforms OASIS PPS Transaction Messages and the process or service is consistent with the normative text of this specification

1.5 Terms and definitions

Messaging model

Simple patterns of messaging between sender and receiver, or requester and responder. The six message models are defined from an application independent perspective, by defining eight different message types as components.

Primitive element

XML element that represents a primitive object in the production planning and scheduling domain. Nine primitive elements are defined in [PPS01]. Every domain objects are represented by the primitive elements.

Transaction element

XML element that represents a message document to be sent or received between application programs. Transaction element has primitive elements to represent any objects of domain information. Transaction element may have a header information and application specific information.

Domain document

Document that is the content of message sent or received between application programs. Message document consists of a verb part and a noun part. Verbs such as add, change and remove affect the types of messages, while nouns show the classes of domain objects.

Domain object

Object that corresponds to production planning and scheduling information in manufacturing operations management. Domain objects are contents of transaction elements, and represented by primitive elements.

Domain property

Any parameters that show a property of a domain object. A domain property is represented by XML attributes of the primitive element, or XML child elements of the primitive elements. A domain object may have multiple domain properties that has same property name.

Implementation profile

Specification of capability of an application program. The profile includes a list of available documents and transactions that may be exchanged in PPS transaction messages among production planning and scheduling applicaions.

Application profile definition

Collections of profile specifications for all application programs that may be involved in the communication goup who exchanges PPS transaction messages. This provides all available domain documents, domain objects and domain peoperties.

2 Messaging model

2.1 Basic models

Two basic types of messaging are defined in this part of PPS standard. The first one is a communication between sender and receiver (Type 1), where the sender simply sends a message to the receiver without any negotiations. The second is a communication between requester and responder (Type 2), where the requester asks the responder to do some services. The responder may answer to the sender by sending appropriate message. The receiver or responder may be multiple at one transaction, so as to make broad casting.

Figure 1 Basic types of messaging

In many practical business situations, communication protocols such as customer negotiation with price and due dates, communication procedures are designed using these basic patterns as building blocks. In such cases, how to combine the component is not in the scope of this standard.

In addition, underlying communication protocols such as HTTP and TCP/IP may used to define for these simple patterns, considering security, reliability, efficiency and so forth. In such cases, messages may be sent several times for one arrow in Figure 1. This is also not in the scope of this part.

2.2 Message classes

Message documents, which represent message between sender and receiver, or requester and responder, are defined for each messaging transaction. According to the verb information of each message document, they can be categorized into 8 different classes. The table shows the message types.

Table 1 Message type in transaction models

Message classes	Description
Add	The message requests to add the specified domain objects to the database managed by the responder.
Change	The message requests to change the specified domain objects in the database managed by the responder.
Remove	The message requests to remove the specified domain objects in the database managed by the responder.
Confirm	The message is sent to the requester of request from the responder as a confirmation of the results.
Notify	The message is sent any domain objects to the receiver as information notification from the sender.
Sync	The message requests the owner of information to send notify message synchronously at the time the specified event occurs.
Get	The message asks the responder to show the specified domain objects in a specified format by sending Show message.
Show	The message has the requested information of domain objects to answer to the Get message from the responder.

In order to ask the confirmation from responders, message documents of Add, Change, Remove and Sync MAY have an attribute of the following confirmation requests.

Table 2 Confirmation request

Confirm type	Description
Never	Responder SHOULD NOT respond to the request.
OnError	Responder SHOULD respond to the request, only if any errors in processing the request occur.
Always	Responder SHOULD always respond to the request.

2.3 Messaging models

2.3.1 Add transaction

In Add transaction model, the requester sends an Add message to request responder to add the specified domain objects to the database that is managed by the responder. After making the task of adding the information, the responder can send a Confirm message depending on the confirmation request.

Figure 2 Add transaction

2.3.2 Change transaction

Change model performs when the requester tries to change the specified domain objects in the database that is managed by the responder. The requester sends a Change message to the responder as a request to change. The responder can do the task and send a Confirm massage as a result of the task.

Figure 3 Change transaction

2.3.3 Remove transaction

Remove model performs when the requester tries to delete the specified domain objects in the database managed by the responder. The requester sends a Remove message, and the responder responds a Confirm message if the Remove message has a confirmation request.

Figure 4 Remove transaction

2.3.4 Notify transaction

Basic pattern 1 performs in the Notify model. In this model, the sender sends a Notify message to the receiver. There is no obligation on the receiver to respond to the message nor make a task for the message.

Figure 5 Notify transaction

2.3.5 Sync transaction

Sync transaction performs that requester requests responder to send Notify message synchronously at the time when the specified event occurs on the domain objects owned by the responder. Responder keeps monitoring the event to send Notify messages by invoking another Notify transaction.

Figure 6 Sync transaction

2.3.6 Get-Show transaction

Get-Show transaction performs like a query-response process in the client-server database systems. The requester sends a Get message to the responder in order to get information of the specified domain objects. The responder tries to answer the request by sending Show message with corresponding information that is managed.

Figure 7 Get-Show transaction

2.4 Procedures on responders

2.4.1 Common tasks

Responders SHOULD have the capability to perform the following tasks when a massage document is received.

l The responder, who receives a proper Get message, SHOULD send a Show message to the requester. The Show message SHOULD have either error information or domain object requested by the requester in the specified forms.

l The responder, who receives a proper Add message, SHOULD add the domain objects in the message to the database that is managed by the responder, unless the ID of the object already exists.

l The responder, who receives a proper Change message, SHOULD change the target domain object in the database managed by the responder to the new data in the message, unless the ID of the object doesn’t exist.

l The responder, who receives a proper Remove message, SHOULD delete the target domain object in the database managed by the responder, unless the ID of the object doesn’t exist.

2.4.2 Confirm message

The responder of Add, Change, Remove and Sync message SHOULD have capability to make the following tasks when the message received has a confirmation request.

l The responder SHOULD send a Confirm message to the requester when the Add message received has an attribute of confirm=”Always”. The Confirm message SHOULD have either error information or the id list that shows all the objects added to the database.

l The responder SHOULD send a Confirm message to the requester when the Change message received has an attribute of confirm=”Always”. The Confirm message SHOULD have either error information or the id list that shows all the objects changed in the database.

l The responder SHOULD send a Confirm message to the requester when the Remove message received has an attribute of confirm=”Always”. The Confirm message SHOULD have either error information or the id list that shows all the objects deleted in the database.

l The responder SHOULD send a Confirm message to the requester when the Sync message received has an attribute of confirm=”Always”. The Confirm message SHOULD have either error information or the id list that shows all the objects to be monitored for synchronization.

2.4.3 Error handling

To deal with errors occurred during the process of messaging, e.g. syntax or semantic problems detected by the responder’s programs, the responder SHOULD have a capability of the following error handling:

l The responder, who receives a Get message and is hard to respond in normal processes because of errors, SHOULD send a Show message with the error information to the requester.

l The responder who receives an Add message with the attribute of confirm=”OnError” and is hard to respond in normal processes because of errors, SHOULD send a Confirm message with the error information to the requester.

l The responder who receives a Change message with the attribute of confirm=”OnError” and is hard to respond in normal processes because of errors, SHOULD send a Confirm message with the error information to the requester.

l The responder who receives a Remove message with the attribute of confirm=”OnError” and is hard to respond in normal processes because of errors, SHOULD send a Confirm message with the error information to the requester.

l The responder who receives a Sync message with the attribute of confirm=”OnError” and is hard to respond in normal processes because of errors, SHOULD send a Confirm message with the error information to the requester.

3 Message document

3.1 Message Structure

A message that is exchanged between two parties SHOULD consist of one or more message documents. When more than two message documents are sent in one message, one of those documents SHOULD be assigned as a primary message document.

A message that is not a primary message document SHOULD have relation to a primary message document or other message documents that is in the same message. This recursive relation SHOULD show the primary message document at the end of the linkage.

Since this standard doesn’t address on how to exchange messages in IP (Internet Protocol) level, data envelope mechanisms such as SOAP can be considered as well as a simple SMTP and file transfer mechanism.

3.2 Transaction element

A domain document is represented by a transaction element. This section defines the common data structure of the transaction elements. The list of the transaction elements which are necessary for production planning and scheduling are address in PPS standard profile.

The structure of the transaction element SHOULD be consistent with the following XML schema and the specifications.

<xsd:complexType name="TransactionType">

<xsd:sequence>

<xsd:element ref="Error" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="App" minOccurs="0"/>

<xsd:element ref="Spec" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Condition" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Selection" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Header" minOccurs="0"/>

<xsd:choice minOccurs="0">

<xsd:element ref="Party" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Plan" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Order" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Item" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Resource" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Process" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Lot" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Task" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Operation" minOccurs="0" maxOccurs="unbounded"/>

</xsd:choice>

</xsd:sequence>

<xsd:attribute name="id" type="xsd:string" use="required"/>

<xsd:attribute name="ref" type="xsd:string"/>

<xsd:attribute name="action" type="xsd:string"/>

<xsd:attribute name="option" type="xsd:string"/>

<xsd:attribute name="transaction" type="xsd:string"/>

<xsd:attribute name="confirm" type="xsd:string"/>

<xsd:attribute name="profile" type="xsd:string"/>

<xsd:attribute name="sender" type="xsd:string"/>

<xsd:attribute name="create" type="xsd:dateTime"/>

<xsd:attribute name="description" type="xsd:string"/>

</xsd:complexType>

l id attribute SHOULD represent the identifier of the message. Every transaction message SHOULD have a unique id in the scope of the sender or the requester.

l ref attribute SHOULD represent the identifier of a primary message document or other message document that is in the same message, when the message has more than one message document.

l action attribute SHOULD represent the type of the message, where the types correspond to verbs information for the message. Values of the attribute SHOULD be either “Add”, “Change”, “Remove”, “Confirm”, “Notify”, “Sync”, “Get”, or “Show”.

l option attribute SHOULD represent any optional information that may be interpreted by the receiver of the message.

l transaction attribute SHOULD represent the identifier of the series of a transaction. If the message has a predecessor that relates to the message, the values of this attribute in those messages SHOULD be the same. For example, messages in the same massaging model SHOULD have the same value on the transaction attribute. Re-sending messages SHOULD have the same value of transaction attribute with the original message.

l confirm attribute SHOULD represent a confirmation request. The value of the attribute MSUT be either “Never”, “OnError”, or “Always”.

l profile attribute SHOULD identify the application profile data, which describes details of domain objects and domain properties to adjust the particular business applications. The empty value of the attribute SHOULD represent the transaction follows the standard profile.

l sender attribute SHOULD represent an identifier of the sender or requester of the message. This information is not for the low-level communication programs but for application programs.

l create attribute SHOULD represent a date when the transaction document is created.

l description attribute SHOULD represent any comments or descriptions.

Elements under the transaction element SHOULD follow the sentences:

l Error element SHOULD represent error information.

l App element SHOULD represent any information for the application programs.

l Spec element SHOULD represent any particular specification of the transaction.

l Condition element SHOULD represent any condition of selecting required domain objects.

l Selection element SHOULD represent any condition of selecting required properties of a domain object.

l Header element SHOULD represent information for detailed messaging described in the section 6.

l Party, Plan, Order, Item, Resource, Process, Lot, Task, or Operation element SHOULD represent domain objects. Different type of them SHOULD NOT be specified at the same transaction element.

A message type that the transaction element is addressed determines the combination of elements available to specify. The table below shows the combination matrix. Each column shows different message transaction type, while the row shows available elements in the transaction element. The blank cell represents the corresponding element SHULD NOT be the child of the transaction element. “M” denotes that the corresponding element SHULD be defined in the parent element. And “O” denotes optional where the element may described depending on the situation.

Table 3 Structure of transaction element

	Add	Change	Remove	Confirm	Confirm (Error)	Notify	Sync	Get	Show	Show (Error)
Error element					M					M
App element	O	O	O	O	O	O	O	O	O	O
Condition element	O	O	O				O	O
Selection element		M						O
Header element						M		O	M	O
Primitive element	M			M		M			M

3.3 Multiple documents message

A message MAY consist of more than one domain documents. When one document is in a message, the type of message is the same as the type of document. When more than one documents are in the message, first, the primary message document is the same as the type of message.

For other documents in multiple documents message, the available combination of document types and message types SHOULD be in the matrix of the Table below. In the table, “Yes” denotes the combination is available.

Table 4 Available combination of multiple documents

Primary Document	Subsidiary document
Primary Document	Add	Change	Remove	Confirm	Notify	Sync	Get	Show
Add	Yes				Yes
Change		Yes			Yes
Remove			Yes		Yes
Confirm				Yes
Notify					Yes
Sync
Get					Yes		Yes
Show					Yes			Yes

4 Add, Change and Remove transaction

4.1 Add transaction

Add message requests the responder to add the specified domain objects in the message to the database managed by the responder.

If the Add message request to add domain objects with ID specified at the “id” attribute, responder SHOULD check existence of the ID in its database and reject the request when the corresponding data already exists in the database. If the message has an ID that already exists in the database, the responder SHOULD NOT add the data.

If the Add message request to add domain object without ID, the responder SHOULD create any unique ID in its database, and create a new domain object that has the specified information. The new IDs MAY return by Confirm message if the requester needs confirmation.

(a) Normal case (b) Error case

Figure 8 Add message transactions

Example 1-A: Message to add three Product Records

</ProductRecord>

When Condition element is specified in a transaction element, the Property element in the Condition element shows common property of domain objects listed in the document. The following example is the same request compare to the previous example.

Example1-B: Add message using a Condition element

</Condition>

</ProductRecord>

The response to Add message is done by sending a Confirm message that has primitive elements in its body. The primitive element represents the domain object that is successfully added, and SHOULD only have id attribute. The next example is the Confirm message as a result of the previous Add message.

Example 1-C: Confirm message as a response of an Add transaction

</ProductRecord>

4.2 Change transaction

Change message requests to change the specified information of the specified domain objects that is in the database managed by the responder. In order to identify the target domain object, Condition element has any condition to select one of more domain objects.

After selecting the target domain object, Select element SHOULD represent the values of target properties to be changed. The values SHOULD be specified in the Property element in the Selection element.

All the selected domain objects depending on the Condition element SHOULD be applied to change in the same way. ID of domain objects SHOULD NOT be changed by Change transactions.

(a) Normal case (b) Error case

Figure 9 Change message transactions

In the database managed by the responder, a property type is either single or multiple. If the property type is single, the value requested to change is applied as a new value of the property. Otherwise, in the cases of multiple properties, the property of the domain object is inserted, updated or deleted depending on the type of the Change message.

4.2.1 Insert property

For the multiple primitives that can be duplicated in the same object, an insert property message performs to add another property that has a new value. When type attribute of Selection element has “insert” value, it shows that the properties in the Selection element are requested to insert.

Example 2: Add information of new level 10 as the latest stock value.

</Selection>

</ProductRecord>

4.2.2 Update property

When the value of type attribute of Selection element is “update”, the properties in the Selection element are for updating the current properties. The target properties to be changed are selected by Condition elements which are defined under the Selection element.

If the Condition elements select more than one property instances, all values of these instances are changed to the value specified in the Property element. If the Condition elements select no property instance, nothing happens for the message.

Example 3-A: The message requests to change the usage of A001-2 from 1 to 4.

</Selection>

</ProductRecord>

Example 3-B: Initial status of the product data A001 that has A001-1, A001-2 and A001-3.

</Item>

Example 3-C: Revised status of the product data

</Item>

4.2.3 Delete property

When a value of type attribute of Selection element is “delete”, then it performs to delete particular properties that are selected by Condition elements under the Selection element. Condition element is necessary to select the target properties to be deleted.

If the Condition elements select more than one property instances, all of these instances are deleted. If the Condition elements select no property instance, nothing happens for the message.

Example 4: Usage of “Machine-1” by the process “Proc-1” is requested to delete.

</Selection>

</ProcessRecord>

Example 5: Delete all inventory records of the item “A001” that has a date before August 1st.

</Condition>

</Selection>

</InventoryRecord>

4.3 Remove transaction

Remove message requests to delete the specified domain objects in the database managed by the responder. The responder can decide either the request is accepted or rejected. If it is rejected, the responder SHOULD send error message, unless the confirm attribute is “Never”. Removing objects means that the data in the database is actually deleted, or logically deleted such that only the delete flag is marked on the object.

The target domain objects to be removed are selected by specifying Condition elements that represent the conditions of target domain objects.

(a) Normal case (b) Error case

Figure 10 Remove message transactions

Example 6: A message requesting that all the lot schedule objects of item “M001” are removed.

</Condition>

</LotSchedule>

5 Notify and Sync Transactions

5.1 Notify transaction

Notify message SHOULD have “Notify” in the action attribute. The figure shows that transaction pattern of Notify message exchange. Notify message doesn’t need its response.

Notify message MAY be sent by the sender to any information users that the sender decides as the destination of the message. If Notify message is caused by synchronization request defined by a Sync message received in advance, the message is sent when the corresponding event occurs. In Notify message for synchronization, the event attribute SHOULD show the event name.

Figure 11 Notify message transactions

Notify message SHOULD have a Header element that MAY have the number of domain objects and any aggregated information of objects. Domain objects, which are represented by primitive elements described in [PPS01], MAY be specified in the body of Notify message.

Example 7: A Notify message shows reception of customer order 001 and its detailed items.

</Header>

</CustomerOrder>

5.2 Sync transaction

In order to synchronize information of users with the information owner, the user needs to know the change of information at the time it occurs. The sync transaction allows the user to request the information owner to notify the change of domain objects synchronously.

If an information owner monitors particular property value of a domain object and tries to detect certain event occurrence such as data changes, the sync message is used to establish synchronization by requesting subscription of the event occurrence detected by the information owner.

When a synchronization request by sync a message is accepted by responder, e.g., the information owner, the responder SHOULD send a notification message by invoking another transaction when the corresponding event occurs. The notification messages are not included in this Sync transaction. Notification of change of the property value will be invoked as a different transaction independent from the sync transaction.

This transaction is similar to publish-subscription model. The sync message can be regarded as a subscription request message. If the responder has a subscription management module, then an application program sent a single Notify message to the module, which knows the subscribers and dispatch the message to all the members listed as a subscriber.

(a) Normal case (b) Error case

Figure 12 Sync message transaction

All properties of a domain object MAY NOT be available to provide this capability. In order to know the capability of application program and the name list of events that the application program can provide, an implementation profile defined in [PPS03] SHOULD specify the information.

According to the implementation profile of the responder, the responder (information owner) determines the interval of monitoring cycle, size of difference to detect changes, range of value to detect event occurrence by minimum and maximum constraints, and so forth [PPS03].

When the value of the property is changed into the range defined by maximum and minimum constraints, the information owner SHOULD send the notification. The owner SHOULD NOT send a next notification of the event unless the value will once be outside of the range.

When the size of difference to detect changes is defined, any changes of the property value less than the size SHOULD be ignored.

The changes during the monitoring cycle MAY be merged at the time of the next monitoring time. Therefore, changes during the cycle MAY NOT be detected by the requester.

5.2.1 Sync message

Sync message is a message to request synchronization of information by requester. Sync message SHOULD specify a value “Sync” at action attribute of the transaction element. Sync message SHOULD have an event name that has been defined in advance by the responder.

Sync message MAY specify particular domain objects that the responder needs to add the requester as a subscriber of the objects. Condition element allows the requester to make request of synchronization for several domain objects by sending one sync message.

When there is no available event specified by the event attribute in the suggested domain object, the responder SHOULD send a error information in Confirm message unless the request has “Never” value on the confirm attribute.

Example 8-A: To request notification when event “E01” occurs on any production order of item “A001”.

</Condition>

</ProductionOrder>

Example 8-B: The requester is registered in the subscription list of event “E01” on the three orders.

</ProductionOrder>

Once a Sync message is received without error, the request will be effective until the responder will get a cancel request of the subscription, or the responder will stop the event detection. In order to cancel the Sync request by requester, the requester SHOULD send a Sync message that has no value of event attribute. When the responder receives a Sync message with no event name, it SHOULD cancel the synchronization request sent by the requester for all domain objects specified in the message. The name of requester is removed from the list of the subscription associated with the specified domain objects.

5.2.2 Procedure of information owner

Information owner, who has a capability of event publishing services, MAY specify the available event information on the implementation profile described in [PPS03]. In accordance with the specification of the profile, the owner SHOULD perform event detection and publication.

First, the information owner SHOULD monitor the actual value of the property that the owner decides to detect the event. In every monitoring cycle, the owner SHOULD determine whether the event occurs, that is, the value of the data is changed to satisfy all the conditions defined to the event. The conditions include minimum value, maximum value, and difference of change of the domain property.

When the event occurs, the information owner SHOULD send a Notify message to all the members who are in the list of subscription. This is similar to publish-subscription mechanism, so the information owner MAY ask the publication to a middle-ware information broker.

The Notify message SHOULD have the event name at the event attribute. The transaction id SHOULD be deferent from the transaction id of the corresponding Sync message. The Notify message of this event occurrence SHOULD have the id of the domain object and the value of the property in the massage body.

Example 8-C: Notify of event “E01” that shows a change of “production result” of production orders.

</Order>

</ProductionRecord>

6 Information Query

Using a Get message, the requester MAY request particular information to the responder by specifying the