BCCE Components

BCCE components are described here in the context of BC.

1. Components by domain

BusinessConnect components have a variety of connections.  To help plan your cloud architecture, we have broken down the BC components to show what domains they operate in.  

Messaging view

The first diagram shows the connections enabled by the message bus. At this time, BCCE supports TIBCO EMS.

The DMZ Message Bus and Interior Message Bus can be common if the Gateway Server is in the Interior zone, and protected from the external internet. 

Database view

This diagram shows the BCCE components that access the database.  The CMS server performs CRUD operations on the database. The IS and PS read the database for configuration data to perform their operations during runtime.

TCP/HTTP connections (Internal to BusinessConnect Container Edition environment)

This diagram shows the TCP connections between the various components.  The only component that is accessible from a browser (http) is the Administration Server (AS).  The Admin Server provides access to the transaction audit log via the AuditSafe Data Server and  web interface.

The IS sends transaction data to AuditSafe (TAS-DS; more below) for logging.  It also sends translation and validation requests to FSREST for processing.

AS sends authentication and user management requests to the Authentication Server (AUS) via the ConfigStore Management Server (CMS).  It also displays CMS and sends CRUD requests to the CMS.  

The CMS API Server (CAS) has a Swagger interface that allows the user to perform the management of configuration files.

Transactional / AuditSafe view

The BCCE transactions and their statuses are written by IS to AuditSafe. AuditSafe adds two additional components, the WebServer (TAS-WS) and the Data Server (TAS-DS).  The WS is responsible for displaying transactions, while the DS is responsible for accessing the searchable, in-memory data store via an API. Both ElasticSearch and OpenSearch have been certified by TIBCO for use with BCCE. 

To view, analyze, and trace transactions stored in AuditSafe, the host’s business and data analysts can use the UI in the Admin Server app, via the UI backend (AuditSafe web server). In parallel, trading partners can do the same using the Partner Management Portal module, which provides a transactions’ view - restricted to their own data.

  2. Configuration vs Runtime components

Components used during configuration

The configuration data that govern how a host (that’s your company) exchanges standardized documents with their trading partners are stored in a relational DB (supported but not included: Oracle, MySQL, and SQL Server). They include configuration information about the host, trading partners and their business agreement, i.e., the transport protocols, business protocols, and how the business documents (operations) are to be exchanged. 

The ConfigStore Management Server (CMS) is the backend server to this data set. It can be accessed from two different UIs. The host-facing UI is called the Admin Server, and the trading partner-facing UI is called the Partner Management Portal (PMP). In order to authenticate end-users on either end, the CMS consults the Auth Server. The Configuration API Server exposes the CMS backend to ease the import of configuration data , e.g., for loading trading partner data in bulk.

Once the configuration is completed, the host and the trading partners are ready to transact and exchange business documents.

Components used during runtime (HTTPS/AS2)

Here we present the components involved in exchanges requiring HTTP, including HTTPS and AS2.

Inbound

The Gateway Server (GS) acts as a proxy server for inbound (IB) HTTP requests from the trading partners, and is located in a separate Private Subnet from the rest of the BCCE components. This is akin to the practice of placing the GS in the DMZ from the on-prem version. Another reason for locating GS in a different subnet is to be closer to the trading partners in a different geography, and reduce latency in the public internet. 

Since GS to Interior Server (IS) connectivity is within the same VPC, latency is not a big factor, hence they can be on different private subnets. Connection between the GS and the Interior Server is done through the message bus (EMS is supported).

If EDI documents are involved, the IS consults FSREST (REST-enabled Foresight Instream and Foresight Translator, part of BCCE EDI Protocol, purchased separately) to validate and translate EDI into XML. FSREST consults the CMS for which guidelines and maps to use.

IS further processes the workflow by forwarding the XML to Private Process (BusinessWorks, included with TIBCO Platform, as are BC and BCCE). Connection between IS and Private Process is also done through EMS. 

IS writes all processed transactions and their interim statuses to AuditSafe, which is the backend to the search engine database (ElasticSearch and OpenSearch are supported, but must be obtained separately). 

Outbound

Private Process (BW) kicks off the process and pushes the outgoing message to EMS, which is eventually picked up by IS, which converts it into EDI and sends it to the trading partner’s gateway.

Components used during runtime (FTP and Mail)

In on-prem BusinessConnect, polling is a feature of Interior Server. In BCCE, the feature has been independently spun off as its own microservice, manifested in the Poller Server. The Poller’s job is to check for the existence of documents to be transacted, which are either in the FTP or Mail servers of the trading partner, or in the Shared File Directory (e.g., Amazon Elastic File System).

Inbound

The Poller checks for inbound (IB) documents in the trading partners’ FTP or mail servers, and retrieves the messages. The Poller connects to the Interior Server through the Message Bus, and the IS takes over from here on out. The rest of the process is the same as the one involving GS with HTTP transport.

In another case, the Poller checks for inbound documents in the Shared File Directory, to which the trading partners have been given access to and where they can post their inbound documents.

Outbound

BW in Private Process kicks off the process and pushes the outgoing message to EMS, which is eventually picked up by IS, which will then send it directly to the trading partner’s FTP or mail servers.