Since the introduction 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 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.