Automating data sharing between trading partners

Object Exchanges (OEs) are used to clone (copy) document (data) objects between workspaces. These exchanges utilize Exchange Objects (a type of Business Object) with configurable mappings for matching object attributes sent, to object attributes received. It is an important mechanism for automating data sharing between trading partners. A new blockchain-controlled framework distributed over a network of nodes, each  permitting secure object exchanges between workspaces on the same or different Bizcloud Domains will be released soon. Besides managing inter-workspace object exchanges, with the new version of the Exchange the network nodes also act as the blockchain storage nodes for a distributed workspace and user registry, and permitting access to the shared ontology made available through the blockchain

There are 5 aspects to Object Exchanges, namely:

1. Definition of the OE Object (the content structure) - what the data “package” would consist of, if and when it is exchanged (in other words, the metadata that specifies the source and destination objects with their attributes as well as the mapping between source and destination attributes), and other properties such as sending and recipient messages, an “include-sender-profile” indicator, processing life cycle statuses, etc.

2. The Web service that executes the exchange - Morpheus, Bizcloud’s run-time core that manages interactions between different workspaces, facilitating collaboration and secure data exchanges between workspaces within and across Bizcloud domains. In other words, the service that executes the transfers based on specified conditions and rules that govern the particular exchange.

3. The established object exchange agreement between the exchanging parties, where one party mandates the other party to execute the object exchange; the authorizing party provides the other party the ability to trigger the execution of the Object Exchange under certain conditions and rules; the mandate specifies the rules and conditions - when, how often, the scope, etc. - for the exchange. On the receiving side the agreement reflects as a mandate; on the giving side it reflects as a policy (i.e., “we have a data exchange policy in place whereby we authorize a certain external party to access specific workspace content - objects - on a specified basis”).

4. Exchange templates are defined using the Object Exchange Mandate Templates function of the Templates workbench in the Workspace Control portal of the party that sets up the exchange. These become the predefined templates are used as “pro-forma” (standard?) contracts that are then presented by the receiving party to the “giving” party as the basis of a proposed agreement. In other words, they are presented as part of a proposed agreement to the party that will be providing the data (the “giver”).  If the giving party agrees, this template content is copied to create an actual digitally-signed agreement instance that govern subsequent object exchanges as described in III above. Templates specify what can be exchanged, the frequency with which it can be done, and so forth.

5. The actual agreement event (and the corresponding creation of the agreement instance) is usually part of a subscription process where the “giving” party subscribes to an offering/programme provided by the receiving party, and accepts the terms and conditions of such subscription (which would include the proposed mandate stipulations). These offerings that are subscribed to are usually provided to the members of managed communities, where members gain access to certain offerings by enrolling to their communities and subscribing to community programmes and offerings. There is a special portal called CMP (Community Management Portal) where user organizations can setup and manage their own online communities. See CMP documentation for more information.