Preparing for Database Component Creation

If you are going to install ActiveTransfer Server, create the ActiveTransfer database component. ActiveTransfer Server writes listener (port), server, user configuration, and other metadata to this database component. ActiveTransfer Server also writes run-time data, such as file transfer transaction information and audit data. If you are clustering ActiveTransfer Servers, create a single ActiveTransfer database component for the cluster to share. If you are not clustering, create an ActiveTransfer database component for each ActiveTransfer Server.

If you want to archive ActiveTransfer transaction data, create a separate schema or database, as appropriate for your RDBMS, in which to store the archived data. The ActiveTransferArchive database component installs stored procedures for archiving the data. The stored procedures need access to the production database tables listed in the section on archiving the database in Managing File Transfers with webMethods ActiveTransfer. If your organization will allow access to production database tables from the schema or database where the archived data resides, install the ActiveTransferArchive database component in the archive schema or database. If your organization will not allow such access, install the ActiveTransferArchive database component in the production schema or database, and give the location of the archive schema or database during the archive process.

API Gateway comes with a data store in which it stores core data, events, and metrics. If you want to store information about runtime event invocations for analytics and auditing purposes, for either one API Gateway or a cluster of API Gateways, create one APIGatewayEvents database component.

If you are going to install CloudStreams, create the CloudStreamsEvents database component. CloudStreams Server writes lifecycle (startup/shutdown), error, policy violation, monitoring, performance metric, and, optionally, transaction events to the CloudStreamsEvents database component. CloudStreams Analytics reads the events data and displays it using the MashZone NextGen dashboard. If you have multiple CloudStreams Server instances, create a single CloudStreamsEvents database component for them to share, regardless of whether they are clustered or not clustered.

The table below describes the types of data Integration Server or Microservices Runtime can persist.

If you are going to install the Mobile Support package on Integration Server, create the MobileSupport database component. Mobile Support writes data used for synchronizing mobile solutions, and metadata about that data, to this database component.

Create the MywebMethodsServer database component if you are going to install any of the following:

• My webMethods Server, with or without Task Engine, the user interface for Monitor, Optimize, or Trading Networks, or the Central User Management package for Integration Server
• Task Engine on Integration Server
• The Central User Management package and the Common Directory Service Support runtime library for Integration Server, to use with the Integration Server Administrator user interface (preview feature).

My webMethods Server writes data about deployment, configuration, security, portal pages, and run-time operations to this database component. It uses this data to manage the My webMethods user interfaces (for example, the user interfaces for Monitor, Optimize, and Trading Networks) and to support central user management in Integration Server.

The Task Engine on My webMethods Server and the Task Engine on Integration Server write task status, task distribution, and business data. The Task Engine on My webMethods Server displays this data in its user interface in My webMethods. The Task Engine on Integration Server displays this data in its gadgets in Business Console and in a Task Engine browser-based user interface.

If you are clustering My webMethods Servers, create a single MywebMethodsServer database component for the cluster to share. If you are not clustering, create a MywebMethodsServer database component for each My webMethods Server.

The CentralConfiguration database component is automatically created when you create the MywebMethodsServer database component. If you are using Optimize, the CentralConfiguration database component stores the Optimize configuration information you enter in the Central Configurator interface in My webMethods. The CentralConfiguration database component is not automatically dropped when you drop the MywebMethodsServer database component. If you want to drop the CentralConfiguration database component, you must do so manually.

If you are going to install webMethods OneData, create the webMethods OneData database components.

• webMethodsOneDataMetadata: webMethods OneData writes internal configuration data to this database component.
• webMethodsOneDataWorkArea: webMethods OneData users create data objects and work-in-progress data values to this database component.
• webMethodsOneDataReleaseArea: Contains the same data objects as the webMethodsOneDataWorkArea database component, and approved data values. Data values are deployed from the webMethodsOneDataReleaseArea database component.

You must create each webMethods OneData database component in a separate schema or database, as appropriate for your RDBMS, and use a different database user for each database component. You must create the webMethodsOneDataMetadata database component first, then the webMethodsOneDataWorkArea database component, then the webMethodsOneDataReleaseArea database component.

If you are going to install Optimize, create the Analysis and ProcessTracker database components.

Optimize Analytic Engines write computed analytics and process and monitoring data received from Infrastructure Data Collectors and Web Service Data Collectors to the Analysis database component. The Optimize user interface displays the data. Create a single Analysis database component for all Optimize Analytic Engines to share. If you are going to use root cause analysis for business processes, install the Analysis and ProcessTracker database components in the same schema or database, as appropriate for your RDBMS.

Optimize Analytic Engines write business and process status data received from processes that are not orchestrated by the Process Engine to the ProcessTracker database component. The Optimize user interface displays the data. Monitor reads process status data from this database and displays it in the Monitor interface in My webMethods. Create a single ProcessTracker database component for all Optimize Analytic Engines to share. If you are going to use root cause analysis for business processes, install the ProcessTracker and Analysis database components in the same schema or database, as appropriate for your RDBMS.

The DataPurge and DatabaseManagement database components are automatically created when you create the Analysis or ProcessTracker database component. The DataPurge database component provides a common method for purging data from the Analysis and ProcessTracker database components. The DatabaseManagement database component provides core routines for data purge functionality.

The OperationManagement database component is automatically created when you create the Analysis or ProcessTracker database component. It provides a common method for configuration, logging, and error handling for those database components.

If you are going to install Process Engine, create the ProcessEngine and ProcessAudit database components.

Process Engines write process execution data for processes they orchestrate to the ProcessEngine database component. If you are distributing business process steps, you cluster the Process Engines that orchestrate the steps. Create a single ProcessEngine database component for the cluster to share. If you are not clustering, create a ProcessEngine database component for each Process Engine.

Process Engine and the following write to the ProcessAudit database component:

• Process Engines write process audit data for business processes they orchestrate.
• Task Engines write task audit data for task steps orchestrated by Process Engine.
• Third-party products can write process execution data.

The following read from the ProcessAudit database component:

• Optimize Analytic Engines read process data so they can analyze capabilities such as transition duration and write data about analysis-enabled processes, then displays this data in the Optimize interface in My webMethods.
• Monitor reads process data and displays it in the Monitor interface in My webMethods, where you can track the status of process instances, view logged values, and, in some cases, resubmit process instances.
• Business Console reads and displays process data so you can monitor process instances in real time.

If you are distributing business process steps, you cluster the Process Engines that orchestrate the steps. Create a single ProcessAudit database component for the cluster to share. If you are not distributing business process steps, and therefore not clustering Process Engines, you can create either a ProcessAudit database component for each Process Engine or a single ProcessAudit database component for all Process Engines to share.

If you are using Process Engines, Task Engines, Optimize Analytic Engines, or some combination of these, create a single ProcessAudit database component for all to share.

If you are going to install the Rules Engine, create the BusinessRules database component. As each Rules Engine instance starts, it registers itself in this database component and stores information about deployed projects and the state of business rules instances. When you modify a business rule, the hot deployment functionality in the Business Rules user interface enables you to deploy changes to all of the instances registered in this database component. If you install multiple Rules Engine instances, create a single BusinessRules database component for the instances to share.

If you are going to install Trading Networks Server, create the TradingNetworks database component. Trading Networks Server writes metadata (partner profiles, trading partner agreements, document types, processing rules, and partner profile groups) and run-time data (documents, document content parts, attributes, and delivery information) to the TradingNetworks database component. Trading Networks Server also logs entries about document processing steps. The Trading Networks user interface displays the data. If you are clustering Trading Networks Servers, create a single TradingNetworks database component for the cluster to share. If you are not clustering, create a TradingNetworks database component for each Trading Networks Server.

If you want to archive Trading Networks data, create the TradingNetworksArchive database component. Create the TradingNetworksArchive database component in the same schema or database, as appropriate for your RDBMS, as the source TradingNetworks database component.

Download the MySQL Community Edition driver to the Software AG_directory \IntegrationServer\lib\jars\custom directory.

For MySQL Community Edition, you must specify the useCursorFetch parameter in the URL to prevent the return of all the query results in a single batch. The MySQL JDBC driver used with the MySQL Community Edition does not honor the cursor fetch size when returning the results of an SQL query. Instead of returning the JDBC-configured number of rows for each cursor fetch to Integration Server, the MySQL JDBC driver returns all the rows for the query in a single batch. This can result in the exhaustion of the available heap memory for Integration Server. Any JDBC connection pool that connects to MySQL Community Edition must specify the following connection option in the Database URL: useCursorFetch=true

You need DBA access only if you want to use the Database Component Configurator to create the necessary database users and storage objects.

Your products are designed to use the database users you will create for the database components using the instructions in this guide.

Your products are globalized and support Unicode. Software AG strongly recommends choosing a Unicode encoding for your database and the most appropriate sort order for your environment. A database character set determines which languages a database can represent. Database sort order determines collation and comparison behavior.

The sections below list the most appropriate Unicode character encoding and sort order for each RDBMS that your products support. If you want to use a different character set or sort order than recommended below, consult your database administrator and your RDBMS vendor's documentation so you can carefully choose a database character set that supports the languages your data is in.

If you use the Database Component Configurator to create your database components, you can check whether the selected RDBMS is configured for the Unicode character set. If the RDBMS does not support Unicode, the configurator lists the character set the RDBMS does support.

The table below provides the page and block sizes specified to use for each type of RDBMS.

You must set database options for the RDBMSs below.