External RDBMS versus Embedded Database

Edit online

You must use an external RDBMS with Integration Server or Microservices Runtime if you are going to:

  • Cluster server instances.
  • Install in a production environment with high transaction volumes or large datasets. The definition of "high" and "large" depends on the amount of memory available to your JVM, the speed of your CPU, and the kind of work your application is doing (for example, more processing intensive, or more IO intensive).
  • Need a database that is scalable, visible, and highly reliable, and that has robust management and recovery tools.
  • Write document history data.
  • Have services log their input pipelines.
  • Use triggers for joins.
  • Use pub.storage for high-volume storage.
  • Write Process Audit Log and Process Engine data for business processes.
  • Use Business Rules with Auditing or Hot Deployment.
  • Use Monitor.

If you are not going to do any of the above, and your database demands are low, your needs might be met by using the embedded database. For example, you can use the embedded database when you are using Integration Server or Microservices Runtime as a runtime for adapters, eStandards Modules, webMethods API Gateway, or Deployer.

Using the Embedded Database

Integration Server and Microservices Runtime use Derby, a file-based database, as their embedded database. When you use the embedded database, Integration Server or Microservices Runtime writes IS Internal and Cross Reference data to that database, and writes IS Core Audit Log data to files.

Important: If one database file gets corrupted, the entire database might become unusable. IBM therefore recommends backing up the \IntegrationServer\instances\instance_name\db directory for Integration Server or the Software AG_directory\db directory for Microservices Runtime periodically so you will be able to return to the last known good state if necessary.

If you later want to write these types of data to an external RDBMS instead, you will need to create the necessary database components in the RDBMS (see Database Component Descriptions and Installation Requirements) and configure Integration Server or Microservices Runtime to write to them (see Connecting Products to Database Components). You must also complete the steps for switching from the embedded database to an external RDBMS (see IBM webMethods Integration Server Administrator’s Guide).

Using the External RDBMS

When you use an external RDBMS, create the ISCoreAudit, ISInternal, and DistributedLocking database components in the RDBMS. You must create the ISInternal and DistributedLocking database components in the same schema or database, as appropriate for your RDBMS. Also create other database components as needed. For example, if you are using publish-and-subscribe solutions and exactly-once processing, you will need the CrossReference and DocumentHistory database components; if you are running business processes, you will need the ProcessAudit and ProcessEngine database components. For complete information about the database components you will need to create, see Database Component Descriptions and Installation Requirements.

If you are clustering server instances, create an ISCoreAudit database component, an ISInternal database component, and a DistributedLocking database component in the same schema or database, as appropriate for your RDBMS, for the cluster to share. Also create a CrossReference database component and a DocumentHistory database component for the cluster to share.

If you are not clustering server instances, create an ISInternal database component and a Distributed Locking database component for each server instance. Also create the ISCoreAudit, CrossReference, and DocumentHistory database components; you can create one of each of those database components for all server instances to share, or you can create each of those database components for each server instance.