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

2. 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.

3. 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.

4. 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

5. 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
Get Transaction (Retain Transaction ID)
Read Transaction Message
Remove Transaction Message
Read Next
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

6. How – Alternative Options – from Gavan Hood
Extend ISA 95 to allow the representation of Profiles
Profiles allow description high level sequences of messages exchanges to meet the needs of a originating “Event” as well as other properties that clients to the service / topic must agree in order to interact in the conversation. (security, encodings etc.)
A Profile could be documented and published and / or be made available on a separate configuration interface
Add optional extra fields into the header of B2MML messages
Sequence Number (increments on each message posted by sender)
Batch number – the set of messages this message is a part of
Policy – the configured profile that this message is part of
The management of duplicates / missing messages is represented in the profile, a set of standard system level profiles may be made available for these scenarios.
Publish supported profiles on a user forum categorized by industry, vendor etc.
Consider the establishment of higher level events and similar constructs that users can use to represent these higher level work flows. These constructs would be base types that users / vendors / industry groups can extend for custom requirements.
Note, in the distributed applications in execution the sequence number and batch number in messages alongside well defined message exchange sequences were sufficient to address this issue. A standard state machine for managing this process could be published to show this approach. But different vendors may have special approaches to this.
Note: If user defined events that combine messages into an atomic bundle is utilized the ordering issue becomes less of an issue. But the failure to deliver and duplicates still exist. Again the specification of the handling of these scenarios is best represented in profiles.
Note: The profile approach is flexible and allows any number of scenarios to be captured. From simple to complex work flows where multiple publishers and subscribers are present at different levels.
Note: The events identified can be generated at any level.