Skip to main content

Configure Additional Request Queues

Overview​

With Atria, you can now configure additional Request Queues to isolate certain requests down their own queue.

This is useful when certain types of requests are log running, and are likely to hold up more important provisioning tasks or other customer's requests, or if certain customers need isolated provisioning.

To Create an additional Queue​

  1. Determine which Provisioning Engine is to process the requests from this queue
  2. Configure the appSettings.config file of the Provisioning Engine
  3. Add rules to route the messages to the correct queue
  4. Restart Services

Determine which Provisioning Engine is going to consume the contents of the Queue:

  • Primary Location
  • Remote Location

The configuration is slightly different for each of these choices.

Configure the Queue​

On the Provisioning Server of that particular location, edit the appsettings.config file within the root of the AtriaProvisioningService installation folder.

Add the following values:

<!-- Add Custom Queues:  Format = RequestQueueName,Type; -->
<add key="Queues" value="QueueName,EnvironmentType;QueueName,EnvironmentType"/>

The EnvironmentType is either Platform or Remote

You can add multiple queues by separating each with a semicolon.

For example, to Create a Queue Called "Bluth" that will be consumed by the Provisioning Server in a Remote Environment, you would add an entry like this:

<add key="Queues" value="Bluth,Remote;"/>

Currently the Remote or Platform value is required, although this should really be determined by where the Provisioning Engine is located. It just happens to be how the code is structured, and for simplicity of implementing this feature it was left like this.

This will create a Queue called: Atria_Request_Bluth_environment_15f1d24a-ce64-461b-9bb1-ffbb509763af

IF THERE IS ONLY ONE VALUE, YOU MUST STILL TERMINATE WITH A SEMICOLON OR IT WILL NOT WORK!!!

Add the Routing Rule​

Depending on the type of requests that you want to channel down the new queue, you might be able to add your new rule to "Before" or "After" Event rule sets. This would mean that the rule persists on Upgrade. But if you cannot, then you might need to add it to the main PreRequest section.

Warning

Rules in the Main PreRequest section will be replaced on upgrading the platform.

It is important that the rule is added so that it is processed BEFORE the request message is sent to the Request queue for processing.

The rule action should set the RequestQueue property to the name of the queue. Here is an example of a rule that will re-reoute all messages for customer Bluth:

KB00004-img1

Restart Services​

In the Primary Environment (Platform), restart the AtriaConfigService service (this should restart the Agent, PlaformApi, and the Provisioning Service as well) to pick up the new rules for routing.

If the configuration was done on a Remote Environment, then restart the AtriaProvisioningService service there to create the queue and let the Provisioning Engine know to consume messages from that queue.