No Alarm Pipeline dynamic Roster

Hi, my gateway has different projects. Every user can log in only to his project.
I’d like to have a single-general purpose pipeline, in which every alarm is switched to the correct notification block, in which i set the correct roster.

I can’t design it the smart way… I’ve noticed there’s no way to dynamically change the roster using a binding (i could use the tag path).
Any suggestion? Thank you.

Unless I am wrong, I think that because of the fact that each pipeline can have more than one notification block, it would be really difficult to make it so you could programatically change each notification block.

I too have a similar problem in that I have multiple instances of the exact same pipeline, except the roster is different in each one. Luckily, the pipeline part itself doesn’t change, or I would have to edit every instance when a change is made.

Thank you for the reply.
This wolud move the problem to the alarm confguration page, where I should set the correct pipeline using some sort of scripting. I preferred working on the pipeline (less work).

I have now partially solved making a switch with N (N=number of projects) lines, going to filter blocks that accept alarms arriving from only 1 project, and then going to the project-specific notification block (with the right roster).
Adding a project will need adding a branch.
The bad side is I have to set manually the project name in each filter block…

Roster property binding would be perfect :slight_smile: everything here is scriptable, i can’t understand this limit :stuck_out_tongue:

I think I found a better way for you to do this, and taught myself something in the process.

Use the switch in your pipeline like you are doing, but set the switch expression to the displayPath, which is a property in your alarm. See below:


Now you can set the Display Path property, via binding, to the project name of the project for which it is an alarm, and your switch will pick the notification block for that project. See below:


In this case, the switch will select the ProjectB notification block.

SQLTags aren’t part of a project, so I don’t know what you’re going to bind the Display Path to in this case. Also, the Display path is usually already take with a description of the tag. I would use the Source Path instead since the folder path is most likely how your tags are grouped anyway. That will look something like: “prov:default:/tag:Folder/tag:/alm:Alarm Name” and you can use the ‘%’ wildcard.

Mario, I want to make sure I understand you correctly. In your SQL tags, do you have separate tags, on which you are setting up alarming, for each project?

if so, then the method I described will work. I just tested it. And Robert, whenever I create a new alarm, the DisplayPath property is blank, and if you use it in the alarm email subject or message, it will show as null. So I see no reason why it couldn’t be used for a switch statement. But if that is not something we should be doing, then there is another way, which I also tested.

You can set up a custom parameter in the alarming properties of the tag on which you are setting up alarming. Below is a custom property named Project, which I have set, in this example to the expression of “ProjectB”.


Now, you can set your switch in the pipeline to switch on this Project property and it will pick the appropriate pipeline. To select the Project property in the switch block, you just put curly braces around it in the expression section, as shown below.


I tested this and if I change the Project property value to “PropertyA” or “PropertyC”, it selects the appropriate notification block via the switch.

One other thing that I could not find in the documentation anywhere is the Custom Subject and Custom Message in the alarm properties. You can set these to whatever you want, and then in the notification block, you can set the subject and/or message to use these properties by enclosing them in curly braces, making the c in custom lower case, and removing the space between words, as in {customSubject}.

The switch block using parameters helped me. Thank for your hints.
I used the tag path (substringed to have the clean project name) to switch to the correct block.

So, I am assuming that you have a separate folder in your SQL tags for each project, and you are grabbing a sub-string of the tag path to determine that folder name. Is that correct?

you’re right man :thumb_left:
thank you

Sounds like a better way to do it, Mario. That’s the thing about this software. There is often more than one way to skin the cat. Trying to find the best method can take time and experimentation, but is usually well worth it. Thanks for the clarification.