Versions Compared

Old Version 1

changes.mady.by.user Geert Graat

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrate text box

 

 

Since the introduction of Aggregates in Blueriq 9.4 a of Aggregate a lot has happened. These successes have led to the demand of new features for the Aggregates. The most prominent of these features is the functionality to connect aggregates to an existing data store. This data store could be a relational database or a a System of Record.

Conceptually, the runtime now creates a call to the API for any aggregate action. The implementation of the API then handles the call to perform an action. The implementation of the aggregates that you know from versions 10.0 and earlier is the default implementation of the API. By creating a custom implementation of the API, you are able to store the data in any manner you want, as long as you are able to handle the calls of the runtime. You can configure basic authentication in the service properties. These variants can be realized by using the persistence API.

  • Create your complete own implementation as OData web service
    When the default programming language within an organization is different from Java it may not be desirable to obtain and maintain Java knowledge. This could be a reason to implement a complete custom Persistence API implementation in the desired programming language. Besides the OLingo (Java) library which is used by Blueriq, libraries are available are available for at least .Net, Javascript, C++ and Python.
  • Implement the database translation using our API and OData\OLingo implementation\translators modules
    This gives you the possibility for using a different database or a different database schema, while still being based on Blueriq's Odata libraries. This has the advantage that the impact of changes in the Persistence API is smaller.

For more information on how you can create your own implementation, see see How to create your own implementation of the persistence API.

Table of Contents
maxLevel2

 

 

UI Text Box
type
Info

When a custom implementation is created, please keep in mind that Blueriq upgrades may lead to changes in the persistence API, which should be implemented in the custom implementation to avoid loss of functionality functionality (eq. Blueriq plugins who call the API). Where possible we will try to be backwards compatible, but if not possible it may be that the impact of an upgrade is larger then than usually.

UI Text Box
type
Info

We have decided to

temporarily deactivate

deactivate Search in structured and unstructured information in version 10.1 to increase the speed of development of the persistence API. This feature

will

may return in a future release

The persistence API is part of the Customerdata SQL Store Component.

System requirements

Minimal

2 CPU cores
256 MB Heap

2 CPU cores
512 MB Heap

Configuration

The Persistence API is required by the Customerdata SQL Store Component, so when this component is used the following needs to be configured first.

Table of Contents
maxLevel3
minLevel3

Runtime properties

The following properties need to be set in the  Include Page_PropertiesFileJava_PropertiesFileJava:
Code Block
languagetext
titleapplication.properties
blueriq.customerdata-sql-store.odata-server.url=http://localhost:10097/customerdata/api/v1
blueriq.customerdata-sql-store.odata-server.username=blueriq
blueriq.customerdata-sql-store.odata-server.password=welcome
UI Text Box
typenote

The properties above contain the default settings, which are set by the Installer. If afterwards these settings are customized in the persistence API they need to be changed in the Runtime as well. 

Persistence API properties

For the Persistence API to work the application.yml needs to be configured. This file is placed in the following folder by the installer: <Blueriq installation folder>\Services\blueriq-customerdata\conf.

UI Text Box
typewarning

When using H2, which is not suitable for production environments, the hbm2ddl-auto setting needs to be set to none, as validate does not work for H2. Again, in production environments this setting should always be on validate.

UI Text Box
typenote

We recommend setting a validation query so that when a database connection is lost due to a network failure for instance, it can be recovered once the network is restored. The validation query is database specific, the query below works with SQL Server (and H2), for Oracle use SELECT 1 FROM DUAL. For more information on configuring datasources, see How to configure BasicDataSource Configuration Parameters.

Code Block
languagetext
titleapplication.yml or application.properties
#######################################################################
## datasource configuration                                          ##
##                                                                   ##
## Note: this configuration should be the same as the configuration  ##
## of the customerdata-sql-store component in the runtime            ##
## (see application-externaldatasources.properties)                  ##
#######################################################################

spring:
  datasource:
    url: <url>
    username: <username>
    password: <password>
    driver-class-name: org.h2.Driver
    validation-query: SELECT 1

hibernate:
  dialect: org.hibernate.dialect.H2Dialect
  hbm2ddl:
    auto: validate
  id:
    new_generator_mappings: true
  show_sql: false
  use_nationalized_character_data: true

#######################################################################
## Security configuration                                            ##
##                                                                   ##
## Here you can override the default username/password               ##
#######################################################################

security:
  user:
    name: <username> 
    password: <password>

Database drivers

Depending on the underlying database, a specific driver needs to be installed on the application server as described on Configuring JDBC database drivers.

Start the customerdata service

The installer installs the customerdata service, but does not start it because the configuration above is required. After this has been completed, you can start itClient component.