You are viewing the documentation for Blueriq 14. Documentation for other versions is available in our documentation directory.

Since the introduction of Aggregate in Blueriq 9.4 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 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 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 How to create your own implementation of the persistence API.

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 (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 than usually.

We have decided to temporarily deactivate Search in structured and unstructured information in version 10.1 to increase the speed of development of the persistence API. This feature will return in a future release

The persistence API is part of the Customerdata Client component.

Didn't find the answer you were looking for? Try the advanced search!