You are viewing the documentation for Blueriq 15. 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 codeDescription
200The job status is returned
401Provide authentication to use this endpoint
403The provided credentials don't have access to this endpoint
500Unable 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

ParameterDescriptionDefault
excludePublishedIf 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
idPublish 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.
typePublish only aggregates which correspond to the provided aggregate type.
HTTP status codeDescription
200The publish action is started and runs in the background
401Provide authentication to use this endpoint
403The provided credentials don't have access to this endpoint
500An 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 codeDescription
200The cancel result is returned
401Provide authentication to use this endpoint
403The 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 codeDescription
200Released the lock.
401Provide authentication to use this endpoint
403The provided credentials don't have access to this endpoint
500Unable 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