Notification and Rule Services

Owned by Lisa Foster
Last updated: Jun 19, 2023

HTTP Call Rules and Notification Queueing

OneVizion allows administrators to manage multiple Services for processing HTTP Call Rule and Notification instances. Services are configured using parameters. Administrators can then assign individual HTTP Call Rules and Notifications to different Services allowing for prioritized processing. The HTTP Call Rule and Notifications instances that are ready to be processed are assigned to respective Queues that are being worked on by the configured Services.

OneVizion platform comes installed with a ‘Default’ Rule Service and ‘Default’ Notification Service.

  • Administer Services – for creating/editing services

  • Admin Rule Queue - for monitoring and re-assigning Services

  • Notification Queue - for monitoring notification instances

  • Rule - creating/editing HTTP Call Rule. Rules can be assigned to Services here

  • Notification - creating/editing Notifications. Notifications can be assigned to Services here

Queue Creation

Setting up additional queues is a two-step process that requires Services (for Rules or Notifications) to be created and deployed.

  • Create a Service

Services can be created and edited in the ‘Administer Services’ page. Access to this page is managed by ‘ADMIN_SERVICES’ security group.

In order to create a Service, Administrators can ‘Add Service’ by providing a ‘Name’ and selecting ‘Service Type’ – based on which the parameters can be set. The parameters for Rule Service and Notification Service are different and can be seen in the screenshots below.



Field

Description

Service Type

Notif Service ID [R]

ID of Service

Both

Is Default?

Default service

Both

Name*

Unique Name that identifies the Service

Both

Enabled?

Checkbox for enabling Service

Both

Queue Polling Interval*

Time in seconds when the Queue is processed for new instances by the Service

Both

Service Type*

Rule, Notification

Both

Service Status [R]

Active, Not started

Both

Last Sync Date [R]

Timestamp when last synched with the process on the server

Both

Active Threads [R]

Number of threads assigned to this Service

Rule

Execution Queue Size [R]

Number of Rule instances current being processed

Rule

Max Concurrency*

Number of Rule instances to run concurrently

Rule

SMTP Host*

Mail settings

Notification

SMTP Port*

Mail settings

Notification

Sender E-Mail*

Mail settings

Notification

Sender User*

Mail settings

Notification

Sender Password*

Mail settings

Notification

Max Attempts*

Number of retries

Notification










Two new parameters have been added to expose notification service settings so that Vizion Platform Administrators can set the number of seconds for Read and Connection timeouts. The default value for the new Read Timeout parameter (time to receive a response from the server) is 60 seconds and for the
new Connection Timeout parameter (time to establish the connection) is 30 seconds.


These default settings can be adjusted to optimize notification service and queue performance. Your mail server administrators should be able to advise setting adjustments to optimize performance in your specific environment





Deploy Service

For each Service that is created in step #1, it has to be deployed with a matching ‘Name’ on the App Server. This requires access to the App Server. Customers on hosted installation, contact OneVizion Support (support@oneVizion.com) for deploying additional Services or your OneVizion Administrator for on-premise installations. Commands for deploying services are below:

java -jar mail-service.jar owner_schema_connection_string [service_name]

java -jar rule-service.jar owner_schema_connection_string user_schema_connection_string [serviceName]



Queue Assignment & Monitoring

Rules and Notifications can be assigned to their respective Services as part of the Rule or Notification definition. See the screenshots below. The assignment here implies that all new instances of the specific Rule or Notification will be executed by the selected Service.





Rule Queue and Notification Queue pages give users access to monitor the status of the Rule/Notification instances that are being processed by the Services.

In the case of Rule Queue, Administrators (with privileges) have the ability to re-assign Services to Rule instances, if they have not been executed (Status – Scheduled or Queued)  yet.

Individual Rule instances can be re-assigned to a different Service/Queue by clicking the ‘Details’ button and changing the ‘Service’ dropdown value.

Multiple Rule instances can be reassigned by using the form button rule provided as well. This will affect all the rule instances in the Grid.



Re-assigning Rule instances will only impact the specific instances and not subsequent instances that get created. For example, if Rule ‘getGeoCode’ is assigned to Service ‘Low’ and there are currently 5 instances of this rule in ‘Rule Queue’ – re-assigning will only impact these specific 5 instances. Any newer instance of this Rule will continue to get assigned to service ‘Low’ as defined in the Rule.

Notification instances cannot be re-assigned to different queues.


Notif-221898 Add ability to specify read and connection timeouts for email connections