You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
This feature is available from Customerdata Service version 2.0.0 and up.
The Administrative endpoints of the Customerdata service can be used to (re-)publish aggregate information on the message queue, so that applications listening on the queue will be able to process the messages. The publish endpoint enables you to publish all existing aggregates to the queue, so the applications that are listening on the queue will be able to process the existing aggregates.
You need this endpoint when for example you have an existing BI-tool attached to the message queue and due to failures this BI-tool is missing some events. With the Administrative endpoint you can republish some or all the events again.
If the entity-event-manager profile is enabled, the Customerdata service exposes management endpoints,that are protected by administrative credentials.
For publishing of events to the queue, the entity-event-publisher-amqp also needs to be active. For more details on how to configure this, see Configure Customerdata service as Queue Producer
The endpoints are accessible using HTTP/HTTPS, depending on your configuration.
GET /api/v1/management/aggregates/jobStatus
Returns if a job is already running or not. In case a job is running, the time when the job is started (acquired a lock) is shown.
| HTTP status code | Description |
|---|---|
| 200 | The job status is returned |
| 401 | Provide authentication to use this endpoint |
| 403 | The provided credentials don't have access to this endpoint |
| 500 | Unable to get the status. Check the log file for more information |
GET /api/v1/management/aggregates/publish
Publishes aggregates that are in the database to the message queue. Publishing happens asynchronously, meaning that the endpoint will return immediately, but the publish job will run in the background until all aggregates are on the message queue.
Publish jobs are not allowed to run simultaneously. To enfore this, a publish job locks the database when it is started. When another publish job is started, it will not start publishing if the database is locked.
Once an aggregate is published to the queue, it is marked as "published" in the database. By default, published aggregates are not published again when a new publish job is started. This behavior can be controlled by parameters, as well as filtering on the aggregates in the database to publish.
Parameters
| Parameter | Description | Default |
|---|---|---|
| excludePublished | If this parameter is true (which is the default), aggregates which were published before will not be published again. Set this to false to force publishing aggregates again. | true |
| id | Publish only aggregates which correspond to the provided aggregate id. If aggregates are versioned, this can result in multiple versions of the same aggregate, which are all published individually. | |
| type | Publish only aggregates which correspond to the provided aggregate type. |
| HTTP status code | Description |
|---|---|
| 200 | The publish action is started and runs in the background |
| 401 | Provide authentication to use this endpoint |
| 403 | The provided credentials don't have access to this endpoint |
| 500 | An error occurred starting the publish action. Check the log file for more information |
Please be advised that for a large database, publishing all the aggregates to the queue can take a lot of time and consume a lot of resources. If filtering on aggregate type still results in a large number of aggregates to publish, please contact us to help you out.
GET /api/v1/management/aggregates/cancel
When a publish job needs to be stopped, this endpoint can cancel it. This endpoint returns whether the cancel operation succeeded, or that it failed to cancel the job (because no job was running or something went wrong).
| HTTP status code | Description |
|---|---|
| 200 | The cancel result is returned |
| 401 | Provide authentication to use this endpoint |
| 403 | The provided credentials don't have access to this endpoint |
GET /api/v1/management/aggregates/releaseLock
When a publish job ends unexpectedly for some reason, it can happen that the lock on the database is not released, meaning that no new jobs can be started. This endpoint forces releasing the lock for that particular situation.
| HTTP status code | Description |
|---|---|
| 200 | Released the lock. |
| 401 | Provide authentication to use this endpoint |
| 403 | The provided credentials don't have access to this endpoint |
| 500 | Unable to release the lock. Check the log file for more information |
Authentication
The management endpoints require basic authentication to use them. The username and password can be provided in the blueriq-customerdata-odata-service-v1-entity-event-manager.yml file. This file can be found at <Blueriq installation folder>\Services\blueriq-customerdata\conf.
blueriq-customerdata-odata-service-v1-entity-event-manager.yml
# Use for administrative tasks endpoints see: https://my.blueriq.com/pages/viewpage.action?pageId=61669842
blueriq:
customerdata:
management:
user:
name: <username>
password: '{noop}<password>'
Jdbc resource configuration
blueriq-customerdata-odata-service-v1-entity-event-manager.yml
blueriq:
customerdata:
datasource:
entity-event-manager:
url: <url>
username: <username>
password: <password>
driver-class-name: org.h2.Driver
Jndi resource configuration
Please note that when Jndi is your preferrd resource configuration, the Customerdata Service needs differently named jndi resource for the customer-sql-store on the one hand, and the entity-event-manager on the other hand.
blueriq-customerdata-odata-service-v1-entity-event-manager.yml
blueriq:
customerdata:
datasource:
entity-event-manager:
jndi-name: java:/comp/env/jdbc/myEntityEventManagerJndiName
Overview
Content Tools