ISA 95 Working Group (Business) Process Centric Exchanges Dennis Brandl A Modest Proposal July 22, 2015

What is the problem As ISA 95 and B2MML are being increasingly used in the entire supply chain, not just within companies, there is a need to ensure that all distributed information is handled in a consistent manner. The ISA 95 transaction model, and corresponding B2MML message exchange, is based on simple one message exchange transactions, with no message sequencing constraints. When using B2MML across the internet, and even in large intranets, the order of message delivery is not always guaranteed. There is no way in the current models to define a sequence, or bundle, of related messages, and have them processed in the correct sequence.

Why is this a problem When related information must be exchanged, such as sending new information (such as a SYNC ADD message defining new material) followed by a use of the new information (such as PROCESS message referencing the new material), then the order of message arrival is important. If messages are received out of sync, this leads to the situation where valid messages are not processed, and invalid errors are generated. For example the messages may be a collection of PROCESS messages for materials, followed by PRCOESS messages with operations schedules that reference the materials. Since there is no way to ensure the order of receipt of messages the operations schedule could arrive before the PROCESS messages are received to add the materials. What is needed to support the multiple company supply chain, using standard intranet protocols, is a way to define a set of messages as a single transaction.

Requirements for Extensions There should be a method to handle a bundle of messages Either all are received, or none are received Messages must be handled in specific order in a bundle, as defined by the sender The solution should not require all applications to parse all messages to determine if there is something the application cares about Messages should be in B2MML format for consistency with existing work Applications should not require internal logic to manage queueing of messages in a bundle until all are received (minimal app code required) The method should handle failures: Sender fails in middle of send Receiver detects error and must stop processing rest of bundle

How – Modest Proposal Create a new channel type (ISA 95 Part 6) “Transaction” channel Sender services on channel Open Transaction Session Start Transaction Post Message End Transaction Cancel Transaction Close Transaction Session Receiver services on channel Open Transaction Session Get Transaction (Retain Transaction ID) Read Transaction Message Remove Transaction Message Read Next Cancel Transaction Close Transaction Session The Sender specifies the topics to be sent when opening the transaction session Topics as defined in ISA 95 Part 6 The receiver specifies the topics to be read when opening the transaction session The receiver only receives messages from the bundle that match their specified topics The Get Transaction only returns a transaction ID (indicating a transaction is ready) when all messages in the bundle have been received Any PUSH or PUBLISH message type is allowed in the transaction channel (SYNC, PROCESS,, …) however error response method must be discussed MSM Service Providers may chose to queue messages at the sender side or receiver side, allowing for flexible implementation patterns