Can we have multiple authentication profiles mixed into one on call roster? This presents a problem for me as my systems have a mix od ad and db authentication profiles.
I went back and forth on this one. I think it’s a good idea to have rosters not tied to any particular user source, and add a dropdown to the top left of the roster management UI to pick which user source you’re pulling users from. I’ll make a note to change that.
Sorry, I didnt want to clog the forum up with my banter, but where do I add the pipelines?
Pipelines are created in the designer.
Each alarm is assigned a pipeline to evaluate one.
[quote=“Kevin.Herron”]Pipelines are created in the designer.
Each alarm is assigned a pipeline to evaluate one.[/quote]
sorry I hadnt even looked there.
Whats the chances of being able to create or modify these pipelines thru scripting from the clients instead of the designer? is that something that is even possible?
[quote=“diat150”][quote=“Kevin.Herron”]Pipelines are created in the designer.
Each alarm is assigned a pipeline to evaluate one.[/quote]
sorry I hadnt even looked there.
Whats the chances of being able to create or modify these pipelines thru scripting from the clients instead of the designer? is that something that is even possible?[/quote]
No, not right now.
Ok thats kind of depressing for me.
Can you give me some kind of idea as far as if it is doable? is it something you guys even want to do? My customers want that type of functionality, so Ill have to look at using a different solution if it isnt on the table.
It’s not something that’s possible right now, and it’s not something we really had in mind while building the pipeline system, but I wouldn’t rule it out completely for the future.
Can you explain why this would be necessary?
so end users can manage their own alarming without going into the designer. with 1000’s of devices and hundreds of users in a system with a good bit of stuff changing around, its just alot of work to keep up with alarming.
I was hoping for something that would be similar to the old alarming system, where everything could be done from the client, but with the group notifications and stuff built in.
I dont want to sound like I am complaining because I know you guys put alot of work into this and I can see where it would work great for most people and I can even see being able to do some other cool stuff. Ive been working on a plan B so I think I can design something that will work using topview sql. Id prefer to keep it in Ignition if I could, though.
Im still not 100% sure on how the pipeline thing works. have you put together a how to yet?
I think we should tackle this problem before we worry too much about scriptable pipeline config.
Much of alarming is client-configurable (or will be soon).
- Alarm config itself. Everything there is dynamic/bindable
- Schedules. (this part is not done yet - users will have their own schedule adjustments that alter the global schedules)
- Rosters (Who gets notified and in what order)
The pipelines are very configurable, and in some sense are dynamic, in that logic can be chosen based an changing conditions (expression block, jump block). Having users configure pipelines sounds like a bad idea to me. Too complex for them, too much likelihood of screwing something up.
is it 1 pipeline per every alarm? can 1 pipeline loop thru multiple alarms? perhaps there is a way to make it more dynamic that I am not seeing.
as far as end users configuring it, thats my goal and what most customers want. With the old notification system, we can put a pretty face on whats too complicated for them to do and make it work(although without voice and escalation, its not what customers really want).
Our alarming is pretty repetitive, only like 4-5 different tagnames per device, potentially. but with hundreds to thousands of devices per system that adds up. so help me better understand this new architecture. can I setup 1 pipeline and notification profile per device that will handle multiple tags? Maybe I am jumping the gun a little and I can make this work using some workarounds like creating the pipeline and notification profile for each device.
Documentation is coming, but real quick overview so you better understand what’s going on here.
Each alarm has an Active Pipeline and Clear Pipeline setting. These are the names of the pipelines to put those events into for notification.
Pipelines are logic graphs that define what (re notification) after an event occurs. Pipelines can handle multiple alarms, for sure. You could have all alarms going into one pipeline, for example. An alarm event goes into a block when the event occurs (active or clear) after the alarm’s configured time deadbands (if any). The alarm event then goes through the pipeline according to the logic blocks defined. The alarm drops out of the pipeline when the pipeline’s dropout conditions are met or when they drop out of a logic block and there is nowhere else to go (dead end).
Overview of the blocks:
Notification: The main purpose of the pipeline is to deliver events into one or more of these blocks. These are the blocks that actually send out messages. You pick the notification profile and call roster here. Throttling mode allows a notification block to coalesce multiple events that in receives in a time window into a single digested message.
Delay: Events going into this block will sit there for the specified time. Upon coming out of the block (like any block) the pipeline’s dropout conditions will be evaluated. For example, if your pipeline drops out on acknowledge, if the event was acked during the delay block, it’ll drop out of the pipeline after the delay.
Expression: Based upon a boolean expression involving the alarm’s properties, split off onto one of two logic branches. For example, “{priority} >= 3” will put all High or Critical alarms on one branch, other alarms on another branch.
Splitter: Splits an alarm putting it on multiple branches at once. For example, if you wanted to email one group but call another, you could split and do both at once.
Jump: Jumps the alarm to another pipeline. Lets you treat pipelines somewhat like function blocks.
Let me know if you have any questions.
I get an internal error when I click on the On-Call Roster from the gateway. Did I install something incorrectly. EVerything else seems to be working.
Is there an error in your system console you can share with us?
Yes - see below:
Time Logger Message
4:40:41 PM DefaultExceptionMapper Unexpected error occurred
org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = table]]
Caused by: java.lang.RuntimeException: An error occurred while getting the model object for Component: [ListView [Component id = rows, page = com.inductiveautomation.ignition.gateway.web.pages.Config, path = 6:config-contents:table:rows.ListView, isVisible = true, isVersioned = true]]
Caused by: java.lang.NullPointerException
we’re so close to having something useful! Does that null pointer exception have a stack trace below it?
How about this:
12:28:30 PM DefaultExceptionMapper Unexpected error occurred
org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = table]]
at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1692)
at org.apache.wicket.Component.onBeforeRender(Component.java:3830)
at org.apache.wicket.Component.internalBeforeRender(Component.java:922)
at org.apache.wicket.Component.beforeRender(Component.java:990)
at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1680)
at org.apache.wicket.Component.onBeforeRender(Component.java:3830)
at com.inductiveautomation.ignition.gateway.web.components.RecordActionTable.onBeforeRender(RecordActionTable.java:294)
at org.apache.wicket.Component.internalBeforeRender(Component.java:922)
at org.apache.wicket.Component.beforeRender(Component.java:990)
at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1680)
at org.apache.wicket.Component.onBeforeRender(Component.java:3830)
at org.apache.wicket.Page.onBeforeRender(Page.java:802)
at com.inductiveautomation.ignition.gateway.web.pages.BasePage.onBeforeRender(BasePage.java:144)
at com.inductiveautomation.ignition.gateway.web.pages.AuthenticatedPage.onBeforeRender(AuthenticatedPage.java:91)
at org.apache.wicket.Component.internalBeforeRender(Component.java:922)
at org.apache.wicket.Component.beforeRender(Component.java:990)
at org.apache.wicket.Component.internalPrepareForRender(Component.java:2204)
at org.apache.wicket.Page.internalPrepareForRender(Page.java:247)
at org.apache.wicket.Component.render(Component.java:2289)
at org.apache.wicket.Page.renderPage(Page.java:1021)
at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:116)
at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:244)
at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:165)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:814)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:253)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:210)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:281)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:245)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: An error occurred while getting the model object for Component: [ListView [Component id = rows, page = com.inductiveautomation.ignition.gateway.web.pages.Config, path = 5:config-contents:table:rows.ListView, isVisible = true, isVersioned = true]]
at org.apache.wicket.Component.getDefaultModelObject(Component.java:1620)
at org.apache.wicket.markup.html.list.ListView.getViewSize(ListView.java:219)
at org.apache.wicket.markup.html.list.ListView.onPopulate(ListView.java:473)
at org.apache.wicket.markup.repeater.AbstractRepeater.onBeforeRender(AbstractRepeater.java:116)
at org.apache.wicket.Component.internalBeforeRender(Component.java:922)
at org.apache.wicket.Component.beforeRender(Component.java:990)
at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1680)
… 41 more
Caused by: java.lang.NullPointerException
at com.inductiveautomation.ignition.gateway.localdb.LocalDBManagerImpl.findRecordMeta(LocalDBManagerImpl.java:281)
at com.inductiveautomation.ignition.gateway.web.models.RecordListModel.load(RecordListModel.java:36)
at com.inductiveautomation.ignition.gateway.web.models.RecordListModel.load(RecordListModel.java:24)
at org.apache.wicket.model.LoadableDetachableModel.getObject(LoadableDetachableModel.java:121)
at org.apache.wicket.Component.getDefaultModelObject(Component.java:1615)
… 47 more
Any ideas on how to fix this issue yet?
Same error here too since beta 2.