(Business) Process Centric Exchanges 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 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

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.