Gathering business process details

Step 0: Start planning this process weeks before installing SmartBridge

You will need to get information from many sources:

Your business partners.
Your IT department.
Third party services.

This part of the process often takes a very long time, so it is highly recommended to start with this weeks in advance.

Step 1: Create a lists of business partners and systems

SmartBridge will be communicating with business partners, but also with your own systems. Every system or network has their own requirements. To prepare for an efficient configuration, start with creating lists:

Create a list of business partners that SmartBridge will be communicating with.
Create a list of internal systems (like ERP sytems) that SmartBridge will be communicating with.

Step 2: Get the requirements for every business partner and system

For each business partner and system, you will need to their communication requirements.

Make sure you acquire

Their latest documentation
Sample data (e.g. EDI messages for testing)

Get information from business partners

Communication requirements

Data requirements

Communication protocols
Address details (URLs, mailboxes, etc.)
Ports
Security certificates
Access credentials (user name, password)
Communication frequency
Acknowledgements
etc.

More about communication requirements

To initiate communication

You need to know	Examples
Communication protocol - What type of protocol you need to use and therefore what communication module you need.	SMTP, FTP, AS2, OFTP
Software requirements - Whether you need specific tools or certificates, and where to get these.	X.509 certificate
Credentials - If the type of communication requires user authentication.	username, password
Ports - Which ports you need to open in your firewall.	587
Partner address - Address and/or directory location of your business partner.	partner_edi_mailbox@ example.com
Frequency - How frequently SmartBridge should check for incoming documents.	every 30 min (requirement for partners in the food sector)
Acknowledgments - Whether the business partner system sends or expects communication status acknowledgments.	Non-repudiation

Data formats
Standards used
Number of files
Data structure
etc.

More about data requirements

Document requirements

These are specifications of the documents that you will be receiving, and that your partner or ERP expects you to send.

You need to know	Examples
Document standard - If the partner uses a standard, which standard and which version of the standard they use.	EDIFACT D.96A
Document types - File types of documents that the partner sends to you, or expects from you.	TXT (ASCII)
Document formats - File format of documents that the partner sends to you, or expects from you.	ORDERS
Number of files - If your partner sends multiple files that together form a document.	1
Location of partner identifier - Where the partner identifier can be found.	Identifier in document: row 1, position 1, length 9
Type of partner identifier - Which convention (format) the partner uses for its identifier (GTIN, EAN-13 , etc).	Identifier in document: row 1, position 356, length 13 Type of identifier: EAN
Partner identifier - The actual partner identifier.	8710400000006
Acknowledgments - Whether the business partner sends or expects documented acknowledgments.	No DESADV

Get information from your colleagues

More about internal business requirements

Internal business requirements

You need to know	Examples
Recency - If you want your communication to be real-time or with intervals.	Immediately
Priorities - Whether some documents or partners have higher priority.	Orders have a higher priority than invoices.
Processing times - Whether your company has specific time frames where processes like sending, receiving, or archiving should take place.	Archive at midnight.

Step 3: Create one summary that includes all requirements

In step 4 you will need to look for patterns in your specifications. Therefore, it is better to first consolidate the specifications into one document, for instance on a Confluence page.

Step 4: Look for patterns, conflicts, and opportunities

Instead of creating a single configuration for every business partner and each type of data, it is better to create decision rules in SmartBridge that apply to more situations. Therefore, you should analyze your summary of communication specifications to:

Identify patterns that apply to every situation, for example 'only documents of partner A are of type XML'. You will later use these patterns to define generic processing rules.
Identify the exceptions. These are potential process conflicts that you need to take care of later on.

See some examples

Examples:

If all your business partners send all their documents to your FreeConnect mailbox, you can collect all documents using only one communication module.
If you found that many business partners are sending you XML documents but each send an XML with their own proprietary structure, then you know that you cannot create a generic rule for XML documents, but should define a specific rule for each XML.
you might have a conflict later on, if you use a generic workflow for all XML files. Creating an overview of all partners, document formats, and types you can quickly identify possible conflicts and solve them in your configuration.

We recommend you create a table that contains the following details per scenario:

Name of the business partner (sender) or internal system that sends you documents.
Communication Protocols that the sender or internal system permits.
Document format exchanged (XML, inhouse, ASCII, EDIFACT, etc.).
Types of documents exchanged (invoice, order, etc.).
Document subtype (which version of a standard is used, e.g. D.96A).

This makes it easier to identify exceptions or patterns.

Example of specification analysis

Example analysis

Overview of the acquired specifications

Partner	Communication Protocols	VAN service optional	Format, specific identifier	Type
A	AS2, SMTPs	yes (BT, IntercommIT, GXS, etc.)	XML, namespace xyz	order, desadv, invoice
B	FTP	no	XML, namespace xyz	order, desadv, invoice
C	FTP	no	XML, node	order, invoice
D	SMTPs	yes (BT, IntercommIT, GXS, etc.)	EDIFACT, D.96A	order, desadv, aperak, invoice
E	FileSystem	no	ASCII, term	order, invoice
F	X.400	yes (BT, GXS, etc.)	ASCII, communication attribute	order, invoice

Analysis of the data above

You could consolidate the communication channels with partners A, D, and F with one VAN entry point.
You could consolidate the XML formats from partners A and B into one document format definition.
Partners C, E and F need specific document format definitions.

In a later stage you will create filters for sending documents to the right modification process. In other words, you will use this overview to:

Configure the labeling of documents, using Document Structures.
Configure the filtering of specific combinations of recipient/format/type/sender for relevant document modifications, using Processes (i.e., which document should get what treatment).

Next step

General application settings