It looks like an instance of EWS server not supported GetAlarmEvents method. Please check it in your EWS server configuration or allow by the method:
AcknowledgeAlarmEvents = false,
ForceValues = false,
GetAlarmEventTypes = true,
GetAlarmEvents = true,
GetAlarmHistory = false,
GetEnums = false,
GetHierarchicalInformation = false,
GetUpdatedAlarmEvents = true,
GetHistory = false,
UnforceValues = false,
GetContainerItems = true,
GetItems = true,
GetNotification = true,
GetValues = true,
GetWebServiceInformation = true,
Renew = true,
SetValues = true,
Subscribe = true,
Unsubscribe = true
thank you for your answer.
I can't find the setting you mentioned.
Where is the location for this?
Looking at your logs, I see no reason why SmartConnector itself should stop working (or even that it has). Can you explain in more detail what you mean by SmartConnector stops working? Does the Service stop running? Or does an extension stop working?
I do see what Ilja is mentioning, but it may be that this specific EWS server doesn't support GetAlarmEvents because it doesn't actually do anything with it. If you are connected to a SmartConnector EWS Server from EBO, then this error is likely in the logs because the EWS Interface in SBO still has Alarm Polling set to enabled when it really shouldn't.
it is the FIAS extension which stops working.
I'm a newbee, but I found this place which could be the setting mentioned above, maybe thats useful
For setting GetAlarmEvents to enabled for a Smart Connector EWS Server instance, you are on the right track! You actually need to select the 'Edit' button while clicked in the root of the EWS Server. This will bring up a dialog where you choose which methods are supported by the EWS Server.
Of course, in general if a Smart Connector EWS Server has a specific EWS Method as disabled, it is likely because the EWS Server instance doesn't support this. Enabled/Disabled methods can be set programatically as well (see Ilja's message above for how this is done).
Hi Jeff, I'll have a look with Stefan to see if we can get to root cause. - Stefan Enser can you explain what is happening with the processors as per Jeff's comments? - There are 2 processors, one should stop and start as it's a scheduled processor. The other should run permanently as it is a long runner connected to the PMS maintaining a socket connection.
If you are just seeing the error for Alarm Poll Failed, I think this is a bug in SBO, what version of SBO/EBO are you using? - Jeff Bowman I recall this was an issue, I can't seem to replicate in 2.0 but not sure when it got corrected... tell me if I'm wrong but as has been pointed out in the thread, our PMS Integration does not do alarms so we set it to not support alarms. I think older version of SBO always tried to get alarms and if the EWS Server did not support it then it would generate the alarm poll error.
By default when a user created an EWS Interface in SBO, SBO sets Alarm Polling to 'True'. Whomever creates this EWS Interface needs to set Alarm Polling to false, or SBO will continually send a GetAlarmEvents request and this error will be displayed in the log.
Of course, SBO could always receive the 'Operation Not Supported' response and automatically turn off the requests (since logic dictates that if something isn't supported and explicitly declares that, they should probably stop trying ).. but they don't do this as far as I know (unless perhaps they did something in 2.0 as you have mention, but I am not aware of this at this point).
Hi Jeff - I had a feeling even if you disabled alarm polling it still tried... that could have been way back in 1.6 or something. Just one of those things that sticks in my mind. I'll find out what versions Stefan is using and see if I can replicate anything this end.