Database

Some parts of the CIB seven webclient keep data of their own: the modeler stores the diagrams and forms you create, and the enterprise chat stores the messages written next to them. Everything the webclient stores lives in one persistence unit, named cibseven, whatever feature the tables belong to.

That unit is the webclient’s, not the application’s around it. The webclient is embedded into applications that bring their own JPA setup, so it never attaches itself to the beans an embedding application already has — those hold the host’s own persistence unit and, quite possibly, a different database.

Its tables are created by the parent application (CIB seven Run, for instance), not by the webclient: see Database schema for the tables and Modeler / Database for the JDBC settings.

Which database the tables go into

By default the webclient stores its data in the application’s own datasource, configured through spring.datasource.*. A standalone webclient needs nothing more.

An application that embeds the webclient can put those tables somewhere else — typically in the engine database, next to the process data — by declaring a DataSource bean under the name the webclient looks for:

import org.cibseven.persistence.CibsevenJpa;

@Configuration
public class WebclientDataSourceConfig {

  /** The webclient's tables live in the engine database. */
  @Bean(CibsevenJpa.DATA_SOURCE)
  public DataSource cibsevenDataSource(@Qualifier("camundaBpmDataSource") DataSource dataSource) {
    return dataSource;
  }
}

Without such a bean the webclient follows the application’s primary DataSource, where its tables may not exist. The application’s own entityManagerFactory and transactionManager stay untouched either way.

Neither of the last two is @Primary, and neither is reachable by type — only by the names above. That is what keeps them out of an embedding application’s autowiring.

Storing data in the unit from your own code

This concerns code built into a CIB seven distribution — not plugins, which are frontend only and reach data through the webclient’s REST API.

A feature that stores data joins this unit rather than opening a second one, so that its work shares the webclient’s transactions. It does three things:

@Configuration
@Import(CibsevenPersistenceConfiguration.class)          // (1)
@EnableJpaRepositories(
    basePackages = "com.example.reporting.repository",
    entityManagerFactoryRef = CibsevenJpa.ENTITY_MANAGER_FACTORY,   // (3)
    transactionManagerRef = CibsevenJpa.TRANSACTION_MANAGER)
public class ReportingJpaConfiguration {

  @Bean
  CibsevenEntityPackages reportingEntityPackages() {     // (2)
    return () -> List.of("com.example.reporting.model");
  }
}

1. Importing CibsevenPersistenceConfiguration is what brings the unit up. There is no unit without a feature that needs one, and importing it from several features is harmless — Spring registers it once.
2. The CibsevenEntityPackages bean adds the feature’s entity package to the unit.
3. The feature’s repositories and its @Transactional methods name the webclient’s beans explicitly, rather than the application’s.

Table names are yours to choose, but a prefix of your own keeps them apart from the webclient’s MOD_ and CHAT_ tables and from the engine’s.