Architecting B2B Data Exchange Entities

Challenge

Setting up Partners, Accounts, User Groups and Roles in DX requires careful consideration; it is essential to determine the definition of these objects and how they will be used before the implementation phase begins.

Description

A partner represents an external or internal entity that sends documents to be processed or receives documents processed in B2B Data Exchange. A partner can be an organization, such as a vendor, customer or an internal system (e.g., an accounting application or an ERP system).

Accounts are sub-entities of partners. In a customer organization, an account can be a unit, such as a division, department or subsidiary. For an internal system, an account can be a unit, such as a customer ID or vendor code.

Often, DX handles a data integration solution which encompasses the exchange of information with both external and internal entities. Setting up the definition of partners inside of DX should be completed in advance in order to avoid costly changes in the future. Examples of partners include:

• Different banks with which an organization exchanges electronic payment information.
• Different hospitals with which an organization exchanges patient health records.
• Various vendors from which an organization receives customer invoices in various different formats.

Categorize Partners Early

Partners can be identified as: an external entity/organization with whom information or documents are exchanged or an entity internal to the organization. Another classification can be based on Partners required for internal document processing. Categorize partners early in the discovery process in order to identify opportunities for reuse and to prevent duplication of information.

Create multiple partners representing the various banks to which an organization might send payments, but it is not recommended to create multiple partners representing a file processing endpoint.

Partners should at least be split into Internal and External; further classifications can be created as needed(e.g., a category called Internal Processing can be made to classify all partners created to handle internal processing by DX, such as those needed by Endpoints).

Also, it is recommended to control the access to partners belonging to different categories (i.e., have specific user groups assigned to each partner category). For example, consider splitting the operators in an organization by geographical region; if partners are categorized into East and West, then create two categories: East and West. Additionally, create an East and West user group which will be assigned privileges only on the respective category. In other words, the west operator group will only Read/Write privileges to West region partners; if necessary, they may be granted read access to East region partners.

Identify Users Groups

In advance, identify the different users who will be accessing DX and the typical workflow that they will follow to perform their daily activities. This can be useful in defining the necessary privilege levels.

By default, DX is equipped with the following roles, and it is recommended to use these to classify the users. For example, a business user will not need the same level of privileges as a system administrator or an operator.

• System administrator (Sysadmin)
• Administrator or admin
• Operator
• Developer
• Analyst

Each role has its own default privileges which can be controlled through the DX console.

The privileges assigned to a specific user can be further refined by using the checkboxes above. The following actions should be limited in order to prevent unnecessary disruptions:

• Reprocess events
• Resend events
• Run monitors
• Change event status
• Run profile

Reprocessing events and resending events are of special importance; if these are used without proper care, then it might result in unnecessary use of system resources and erroneous results.

Access Control using Event Type

In B2B DX, each processed document creates an event but these might not be relevant to all users. For instance, consider a payment processing system which monitors payments sent to banks and their status in the form of acknowledgements, negative acknowledgements and statements received from the bank. Mainly, a business user will be interested in seeing the following:

• Status of payments sent
• Whether they were acknowledged
• Whether they failed acknowledgement
• Whether statements were received for them

In DX, an event will be created for the arrival of an acknowledgement of a payment, a statement and several other events (e.g., system events). The business user needs to be shielded from these event types to prevent them from being overwhelmed. The following DX screen assigns the privileges to a business user so that they only view specific types of events.