Configurable interoperability -- the ability to set-up and execute an interoperable relationship without the constraints of programming or re-programming – is made possible by ‘splitting’ the logic between the application and messages that drive that application. The degree to which it is split depends on the situation. As humans, for example, the more (of the logic) we know in advance, the fewer the words needed in conversation. We say "I know what you mean." The conversation is short and inflexible. However, when we say "I don’t understand", the logical center-of-gravity shifts to the messages being exchange. Although it takes longer, the conversation is more flexible and the exchange is more configurable.

The ability to use semantic messaging to distribute logic is at the heart of configurability. Consider, for example, how the ability to split logic adds excitement to the game of football. The players have to be ‘programmed’ in advance by studying (loading) the play book and participating in practice. During a game, the quarterback decides (in the huddle) which play the team will execute on a down (he selects the correct program) and the call number to execute it. At the line of scrimmage, the quarterback says "Hut 1,2,3.." and the play is executed. Almost all of the logic is in the pre-selected play. His message, the ‘hut 1, 2, 3,’ is just data that executes the logic. However, if after calling the play in the huddle, the quarterback decides at the line of scrimmage to change the play, he calls out what is known as an ‘audible.’ He says "California, six-right, 1,2,3…" He has sent a semantic message that gives new instructions, that has new meaning, that reconfigures the down and the game. He uses the audible because it is more efficient - less time consuming. Otherwise, without this capability (messaging), he would have to call time-out, return to the huddle, and reprogram the down.

With manufacturing systems, configurable interoperability is achieved with the tantalizing combination of semantic messaging, electronic commerce, and object technology.

Semantic Messaging Although applications can ‘interoperate’ with complex, code-based programming, it is the semantic messaging that gives it its configurability. Once in place, configurable interoperability enables businesses to be more agile, more efficient, more independent, and more interdependent. It helps them to ‘interoperate’ with many more and different trading partners in a many-to-many environment. Implementation time frames are shorter and completed with much less effort. With the help of agile messaging tools that are designed to meet these new requirements, configurable interoperability enables the implementation of business relationships in near real-time. What once took hours now only takes minutes or even seconds with the end users do it all by themselves. Thus, the increased benefit for the added configurability is not as a matter of degree, but one of orders-of-magnitude.

Electronic Commerce Semantic messaging can not do it all by itself. Although it can take care of the content and intent, there is still the requirement for message delivery from one location to another. This is the responsibility of Electronic Commerce or EC.

EC is what enables ‘paperless’ business, a requirement for existence in today’s fast-paced world. Through a series of agreed upon standards and protocols, EC resolves technical differences, crosses international communications boundaries, and overcomes other barriers to the easy and ubiquitous interchange of information and data.

EC comes in a variety of forms ranging from the highly structured Electronic Data Interchange (EDI) for direct transfer from application-to-application, to the free form e-mail for human-to-human communications. Somewhere in between is the Internet, FAX, point-of-sale, and direct links for programmable logical control devices such a bar-code scanners and label printers.

A more detailed discussion of Electronic Commerce and the Internet can be found in Appendix B of this document.

Object Technology Today’s rules-based Object-Oriented architecture can enable supply chain players to divide the business logic between the applications and the ‘connecting’ messages just as is human conversation. Achieving ‘mutual application behavior’ is now becoming a reality - even for the most disparate systems. Properly designed systems can be configured in minutes and hours, a process that once took weeks and months. This is possible because the legacy hard-code custom programming, conversion tables, and centralized processing is being replaced with object and rules-based distributed environments. As a consequence, the control of the business process can now be placed in the hands of those in the front lines - those who make the everyday decisions, not the MIS department.

Distributing or ‘splitting’ of the logic is the essence of SSA’s BPCS Client/Server V6.0. With help from SSA’s Semantic Messaging Gateways (SMGs) and the Electronic Commerce Manager (ECM), the dynamic duo of its configurable, rules-based, Distributed Object Computing Architecture (DOCA), BPCS Client/Server V6.0 delivers the best in configurable interoperability – worldwide. Users are in control as they provide their instructions to ‘run’ their businesses their way. If business relationships change, they only need to change the existing instructions or prove new ones. This is in direct contrast with traditional code-based architectures where users are controlled by their business systems -- by the coded architecture permits the delivery of information only according to ‘rules’ of the application.

SMGs use a language-like way of communication, called semantic messaging, to send requests or orders to and from BPCS Client/Server. Using semantic messaging reduces the brittleness often associated with traditional interfaces, reduces the time and impact analysis associated with determining what needs to be done, and simplifies what has to be done to implement an interface.

Also, because SMGs represent the behaviors and characteristics of business-recognizable things such as orders, warehouses, and invoices, they also reduce errors introduced when business requirements must be translated into non-business things called programs and databases.

SMGs are Business Objects (not programs or databases). Under the covers, SMGs are implementations organized to represent business objects. In so doing, they are exceptionally well suited to naturally representing those things businesses must manipulate. The closer system components can come to representing either the real assets of a business such as Items, warehouses, or locations, or the products of business activity such as customer orders or customer invoices, the easier it will be to support and represent the every day process of conducting business. On the other hand, programs, databases, interfaces, files, APIs, and even to some extent, screens, are technical compromises that obscure and sometimes hide business meaning.

SMGs are Messages (not APIs). Traditional interfaces or APIs between system components are data-centric and very brittle. They are also limited to a pre-defined collection of contexts usually represented by some kind of transaction code. Both the sender and receiver have to share quite a bit of information about the interface and agree on it all before the interface can be used.

Semantic Messaging eliminates the problems with traditional APIs and other types of data-centric interface techniques. Semantic Messaging works on the principle that the message should contain all the information necessary to interpret what it means and what context it represents, just like a conversation between two people. But like a conversation, the only thing that has to be agreed to up front is the language and the dictionary of terms that the two programs will share.

SMGs are the key to interoperability. Using SMGs assures that changes that inevitably occur to BPCS Client/Server or to the external application do not affect each other. In fact, as long as SMGs are used to implement business processes from external and BPCS Client/Server system components, then change can be applied without worrying about the impact on other system components using SMGs.

The Electronic Commerce Manager (ECM), one of the core BPCS Client/Server V6.0 products, was developed specifically to manage information that is transmitted between BPCS Client/Server and user trading partners. ECM creates a seamless connection that is capable of resolving differences between internal BPCS Client/Server application and external business information. ECM enables the transparent exchange of business data such as Electronic Data Interchange (EDI), Internet, FAX, and E-Mail without the need for in-depth knowledge of the host application, the standards, custom programming, or manual intervention.

ECM’s Windows™ graphical interface can be used to configure and manage trading partner specific information including data which is not part of the BPCS Client/Server process. Additionally, ECM also provides for prioritization of transaction processing, archiving activity history, and validating trading partner identities and contact information. ECM has an extensive trading partner classification model including both inter and intra-enterprise options such as customer, vendor, bank, carrier, warehouse, and company.

ECM is event driven. That means end-to-end communication controls can be automated. The ‘feeding’ of message to BPCS Client/Server can be managed - high priority messages can be moved ahead of those with lower priority, time consuming high volume messages can be scheduled for off-peak times, etc. (The Semantic Message Gateways (SMG) have no mechanism to perform this function.)

ECM replaces the need for API’s and associated hard-code with instructions based on BPCS Client/Server V6.0 logic, EDI and other messaging standards, and trading partner business rules. Creating new instructions only requires the selection of the right rules. Making a change only requires a change in the rules.

ECM cannot act alone but must have help from the host application and the external interchange software. This is where the Semantic Messaging Gateway (SMG) and EC translation software or the Internet play an important role.

The ECM and the SMGs are integral parts of BPCS Client/Server that work together to enable the interoperable interchange of data with any external source. The process works (in either direction) like this...

• ECM receives an EC message from a trading partner, looks-up the business rules for the unique message type/trading partner relationship and prepares the data for BPCS Client/Server.
• ECM then ‘packages’ the data with delivery instructions that route the data to the appropriate SMG.
• The assigned SMG delivers the data to the prescribed BPCS Client/Server programs for processing.

ECM can provide the end-to-end rules-based or semantic integration because ...

• it is highly configurable (there is no programming or code, only rules and business semantics)
• it can deliver data objects anywhere in BPCS Client/Server (a purchase order)
• it can initiate processes (order fulfillment)
• it can make queries (order status)
• it can initiate event driven responses (advance ship notice)
• all of the above is independent of host platform, database, or target file structure.