Page History
...
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.
...
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. |
...
| UI Text Box | ||
|---|---|---|
| ||
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.
...
| Code Block | ||
|---|---|---|
| ||
# 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
| Code Block | ||
|---|---|---|
| ||
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.
...
Overview
Content Tools