Overview

This article describes the 360Suite architecture: the application components, the databases and file storage they depend on, and how they connect to SAP BusinessObjects (BOBJ) and SAP Data Services (BODS - 360Eyes for DS only). It covers both a standard single-node deployment and a two-node cluster (high-availability) deployment.

Use this article to understand which components are required versus optional, which databases and folders each 360Suite module uses, and how a clustered deployment differs from a single-node deployment.

Key Concepts & Strategy

• 360Suite runs as a web application on a Tomcat server. A single 360Suite installation hosts all modules, albeit depending on your licences: 360View, 360Plus, 360Eyes, 360Cast, 360Bind, 360Vers etc..

• 360Suite connects to SAP BusinessObjects through the REST API and the Java SDK. This connection is required.

• Some modules use optional external data sources: the BOBJ Audit database (used by 360Eyes) and BODS repositories (used by 360Eyes for Data Services). These connections are only needed if the corresponding module/feature is deployed.

• 360Suite stores its own data in a repository database (metadata, license, configuration) and, depending on the modules enabled, in additional databases and file folders.

• In a cluster deployment, two or more 360Suite nodes share the same database stack and the same file stores, and synchronize with each other (node sync). This provides high availability: if one node goes down, the other continues serving requests.

Common Questions

What does a standard (single-node) 360Suite deployment look like?

In a single-node deployment, one Tomcat server hosts 360Suite and its modules. The diagram below shows how this server connects to SAP BusinessObjects, to optional external systems, and to its databases and file folders.

Diagram description: 360Suite (Tomcat web server, App Layer) connects to:

• SAP BusinessObjects (required) - via REST API / Java SDK

• 360Suite repo (required) - stores metadata, license, and config

• BOBJ Audit DB (optional) - 360Eyes only

• BODS Repositories (optional) - 360Eyes DS only

• 360Suite Audit database (optional) - 360Cast and 360Eyes activity

• 360Eyes DB (optional) - Eyes extraction task data

• 360Eyes DS DB (optional) - Data Services extraction data

Three file folders sit below their related databases:

• 360Plus folder - backup data generated by 360Plus

• 360Bind folder - extracts and comparisons

• 360Vers folder - object versions managed by 360Vers

Which components are required, and which are optional?

Only two connections are mandatory in any 360Suite deployment:

• The connection from 360Suite to SAP BusinessObjects (REST API / Java SDK).

• The connection from 360Suite to its own 360Suite repo (metadata, license, configuration).

All other databases and folders shown in the diagram are optional and only apply if the related module is deployed:

• BOBJ Audit DB and 360Eyes DB - used only if 360Eyes is deployed.

• BODS Repositories and 360Eyes DS DB - used only if the 360Eyes Data Services add-on is deployed.

• 360Suite Audit database - used only if 360Cast and/or 360Eyes activity logging is enabled.

• 360Plus folder, 360Bind folder, 360Vers folder - used only if 360Plus, 360Bind, or 360Vers respectively are deployed.

What is the 360Suite repository used for?

The 360Suite repository is the core repository database. It stores the application's metadata, license information, and configuration. It is the only database connection that is always required, regardless of which 360Suite modules are enabled.

What are the 360Plus, 360Bind, and 360Vers folders for?

These are file folders, not databases. They can be local to the 360Suite server or a shared network path:

• 360Plus folder: stores backup data generated by 360Plus.

• 360Bind folder: stores extracts and comparisons generated by 360Bind.

• 360Vers folder: stores the object versions managed by 360Vers.

How does a clustered (high-availability) deployment differ from a single-node deployment?

In a cluster deployment, two Tomcat servers (Node A and Node B) each run a full 360Suite installation with the same modules. Instead of each node keeping its own database and file storage, both nodes connect to the same shared database stack and the same shared file stores. The two nodes also communicate directly with each other through node sync.

Diagram description: Two Tomcat servers, Node A and Node B, each run 360Suite with the same modules (360View, 360Plus, 360Eyes, 360Cast, 360Bind, 360Vers). Each node connects to:

• SAP BusinessObjects (required) - via REST API / Java SDK

• BOBJ Audit DB (optional)

• BODS Repositories (optional)

• The other node (required) - via node sync, always active in a cluster deployment

Both nodes also connect to two shared blocks instead of keeping separate storage:

• 360Suite databases (required connection) - a single shared database stack grouping the Repo, Audit, 360Eyes, and 360Eyes DS databases. The connection to this stack is always required, but within the stack, only the Repo database is always required - Audit, 360Eyes, and 360Eyes DS still depend on which modules are deployed, same as in the single-node deployment.

• 360Suite file stores (optional connection) - a single shared folder stack containing the 360Plus folder, 360Bind folder, and 360Vers folder.

Why do cluster nodes need to share the same databases and file stores?

Sharing the database stack and file stores keeps data consistent between nodes. If each node kept its own separate storage, data created or modified on Node A (for example, a 360Vers object version, or a 360Cast activity log entry) would not be visible from Node B, defeating the purpose of high availability.

What is node sync used for in a cluster deployment?

Node sync is the direct communication link between cluster nodes. It allows the nodes to coordinate with each other in addition to the data consistency already provided by the shared database stack and file stores.