Objective:

To bundle the client groups' database accesses and to manage and distribute all system files

During document searches, the obligatory Broker Server takes over the client's database queries and directs them to appropriate Database servers or a full-text database and sends the query results back to the client.

-> This reduces the quantity of data transmitted through the network during document searches to a minimum.

• The Broker manages all trays for all users. This allows trouble-free exchange of documents among any users' trays within the network. Documents are transferred to the Document Server to be saved.
• Access to databases is managed via ODBC.
• Cursor caching for combined queries between SQL and full-text or KM.

• Minimum features: Up-to-date standard PC with at least 128 MB of RAM and 2 GB of free hard-drive space. We generally calculate as follows: 1 GB plus number of users x (sum of all objects in these trays plus 1 KB per object)

Example: 100 users x 200 pages per user = 100 x 200 x (70 KB + 1 KB)

>> Total required space = 1.420 GB plus 1 GB general reserve

• State-of-the-Art server with dual Pentium 4 CPU, 1.7 GHz each or better, 256 MB of RAM, disc/raid array for data with a capacity of 20 GB or more depending on requirements.

• Fastest possible CPUs, 512 MB of RAM, fast drives

• For the server, use Windows 2000 or XP in the appropriate server version. Windows NT 4.0 Server is also supported, but not actively.
• System messages are generally entered in the Event Log. They can also be sent via a MAPI-compatible e-mail system.
• High performance and trouble-free operation can best be ensured if no other powerdemanding processes are running on the same Windows Server.

• Installation is possible without special preparation in Windows 2000/XP, Novell, and UNIX networks. SAPERION® supports common network protocols such as TCP/IP, IPX, and Named Pipes. Adequate network connections are required.
• The computer must be properly integrated in the network and must support at least one of the following protocols: IPX, Named Pipes, or TCP/IP (Winsockets).

• An ODBC connection is required for databases under Unix or a Unix-compatible full-text database. A Windows Broker is required for rendering.
• Linux on Intel/AMD: Hardware requirements are the same as for Windows; Distribution SuSE 7.3 or higher or RedHat 7.2 or higher; Kernel release 2.4 or higher.
• Solaris on SPARC: For Sun computers that run under Solaris, the processor and memory requirements are the same as for Windows. Due to the system architecture typical in this environment, however, a suitable number of processors are used in the appropriate server process rather than several different computers.

• Generally, numerous databases are supported, independently of the platform, by ODBC. This requires released and tested drivers. These include MS SQL Server, SyBase, Oracle, Informix, DB2, UDB, and others. (See Compatibility List >> Databases for details).
• High-capacity, ODBC connection required—usually supplied by database manufacturers such as Microsoft, Oracle, SyBase, etc.
• DtSearch and Verity are supported as full-text databases. Currently, no full-text database is available under SOLARIS/LINUX.

• As a service, the Broker can take on tasks in the area of format conversion. This can involve, for example, the conversion of Word documents into long-term formats such as TIFF or PDF.
• If there is a high volume of documents in the rendering area, separate Brokers can be configured to handle them. Specifically, Windows Brokers can be used for rendering in what is otherwise a Unix environment.
• Applications required for rendering must, where applicable, be available on the Broker. This is especially important for Unix.

1. Rule of thumb for drive size:

Size of the table space in GB = (size of a record x 3) x (number of records x 1.4)

Total size of the DB Server =

x GB size of the table space

+ 5-20 GB space for temporary operations

+ 5-10 GB space for tests

To calculate costs, the table space is generally multiplied by two to provide space for temporary storage.

2. Computing performance

Influencing factors: Number of active users and complexity of queries.

i) Each active user requires a working set in the main memory. 2 to 4 MB are required for each user. The minimum total is 256 MB.

ii) A high volume of queries per unit time and/or time-consuming, complex queries require maximum processor speed as well as 2 to 4 processors. More processors are required for certain kinds of system architecture.

• The Business Broker Server is single-threaded, while the Enterprise Broker Server is multithreaded.
• Furthermore, the Enterprise Broker has extensive capacity to take over the tasks of other Broker Servers as a Failover Server.

• The Enterprise Broker Server permits simultaneous operation of several Broker Servers at different locations. If one of them fails, all of that server's essential functions (except access to local tray data) can be taken over temporarily.
• The Cluster Broker runs on a Windows Cluster System in active/passive mode and common drive storage. If the primary cluster computer fails, the secondary cluster computer starts and automatically takes over all tasks, including tray access.

• The Document Server is used to archive and distribute data.
• The Broker Server is responsible for administration and the management of access to the databases.

• One Broker is used as a master for the administration data. This Broker sends copies to all other Brokers.

• The Broker Server manages the user profiles; it also manages and evaluates rights profiles / access control lists.
• The Broker Server manages user and Server Licenses.

• Tray management: A large number of high-end clients can have a significant influence. The decisive factor is the quantity of transported data.
• Managed database queries: Since the Database Server usually handles the greatest part of the query load, the Broker Server, where applicable, handles many different users simultaneously (500 to 1,000). If a full-text database is operated locally and a large volume of full-text data is indexed or queried, this also causes a heavy load on the system.
• Rendering: The rendering of a large volume of documents causes a heavy load on the system. We recommend using a separate Broker under Windows to absorb this load.

• The Enterprise Broker Server serves as a failover system and takes over all services except the current tray data.
• Multi-thread capacity: allows many simultaneous queries. Because the SAPERION® server processes are multi-thread capable, it is possible to employ high-performance server computers with multiple processors, if required, in Linux (Intel®) or SUN® Solaris® (SPARC) systems. Multi-thread capacity requires the use of the appropriate ODBC driver.
• It is easy to reduce load at any location by employing additional Broker Servers.