03-19-2018 05:57 AM
Hello,
I' am calling an AXL API for updateSyslogConfiguration through Python code, below is the axl api reference link
However, this API is expecting a correct value for the element "monitor",
throwing below error:
-----
FAIL: updateSyslogConfiguration<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server</faultcode><faultstring>Wrong value for Monitor</faultstring><detail><axlError><axlcode>5003</axlcode><axlmessage>Wrong value for Monitor</axlmessage><request>updateSyslogConfiguration</request></axlError></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>
-----
Not sure what would be the correct value to be passed for the element "monitor". Can someone please advise.
Thanks,
Rajesh S.
03-20-2018 11:32 AM
Did some sleuthing, and it looks like the <monitor> value is a string that matches the section headings in the web UI for each type of alarm config:
i.e. 'Local Syslogs', 'SDI Trace' and 'SDL Trace' for the Cisco CallManager service. You can see these values if you do a <getSyslogConfiguration>:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/11.5">
<soapenv:Header/>
<soapenv:Body>
<ns:getSyslogConfiguration>
<serverName>ds-ucm115-1</serverName>
<serviceGroup>CM Services</serviceGroup>
<service>Cisco CallManager</service>
</ns:getSyslogConfiguration>
</soapenv:Body>
</soapenv:Envelope>
-----------------
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:getSyslogConfigurationResponse xmlns:ns="http://www.cisco.com/AXL/API/11.5">
<return>
<syslogConfiguration>
<serverName>ds-ucm115-1</serverName>
<serviceGroup>CM Services</serviceGroup>
<service>Cisco CallManager</service>
<alarmConfigs>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>Local Syslog</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<RemoteServerName1>192.168.0.1</RemoteServerName1>
<RemoteServerName2/>
<RemoteServerName3/>
<RemoteServerName4/>
<RemoteServerName5/>
<monitor>Remote Syslog</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>SDI Trace</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>SDL Trace</monitor>
<Enable>t</Enable>
</AlarmConfig>
</alarmConfigs>
<EndPointAlarm>false</EndPointAlarm>
</syslogConfiguration>
</return>
</ns:getSyslogConfigurationResponse>
</soapenv:Body>
</soapenv:Envelope>
The values for monitor seem to vary depending on which service is being configured, but the ultimate list appears to be based on the 'typemonitor' table in the database:
admin:run sql select * from typemonitor
enum name moniker display displayservername monitorstatus tkalarmseverity
==== ================ ============================= ======= ================= ============= ===============
0 Event Log ALARM_SEVERITY_EVENT_VIEWER t f t 3
5 Data Collector ALARM_SEVERITY_SNMP f f t 7
1 Sys Log ALARM_SEVERITY_SYSLOG t t f 3
2 AST ALARM_SEVERITY_SERVICEABILITY f f t 3
3 SDI ALARM_SEVERITY_SDI t f t 3
4 SDL ALARM_SEVERITY_SDL t f t 3
6 SNMP Traps ALARM_SEVERITY_SNMP_TRAP f f t 7
7 Alert Manager ALARM_SEVERITY_ALERT_MANAGER f f t 7
8 Alternate Syslog ALARM_SEVERITY_ALTERNATELOG t f t 7
Unfortunately the actual string values used in the <monitor> element appear to be based on the UI vs. the actual 'name' field in typemonitor, which would have made the needed values a bit more predictable.
03-26-2018 01:55 AM
Thanks for this useful information.
I'll try this out and get back to you.
--
Regards,
Rajesh S.
03-26-2018 08:46 AM
Hello,
I tried posting monitor values as Remote Syslog, SDI Trace, SDL Trace, Local Syslog, however, getting same error, also tried with values based on the 'typemonitor' table in the database, getting same error. It seems like, API is not accepting these values either.
Error:
FAIL: updateSyslogConfiguration<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server</faultcode><faultstring>Wrong value for Monitor</faultstring><detail><axlError><axlcode>5003</axlcode><axlmessage>Wrong value for Monitor</axlmessage><request>updateSyslogConfiguration</request></axlError></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>
--
Thanks,
Rajesh S.
04-26-2018 12:11 PM
Can you post your request XML?
04-26-2018 12:54 PM
This really does look like it's a defect... Can a bug not be raised for this?
04-27-2018 11:54 PM
Here is the XML :
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updateSyslogConfiguration>
<serverName>xxxxxx</serverName>
<serviceGroup>CM Services</serviceGroup>
<service>Cisco CallManager</service>
<alarmConfigs>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>Local Syslog</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<RemoteServerName1>1.1.1.1</RemoteServerName1>
<RemoteServerName2/>
<RemoteServerName3/>
<RemoteServerName4/>
<RemoteServerName5/>
<monitor>Remote Syslog</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>SDI Trace</monitor>
<Enable>t</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Error</AlarmLevelEvent>
<monitor>SDL Trace</monitor>
<Enable>t</Enable>
</AlarmConfig>
</alarmConfigs>
<EndPointAlarm>false</EndPointAlarm>
</ns:updateSyslogConfiguration>
</soapenv:Body>
</soapenv:Envelope>
{'SOAPAction': '"CUCM:DB ver=10.5 updateSyslogConfiguration"', 'Content-Type': 'text/xml'}
04-30-2018 09:10 AM
This request works for me on v11.5. Note the trailing 's' on 'Local Syslogs' and 'Remote Syslogs'. I have 'true' vs 't' as well, though not sure if that should matter:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/11.5">
<soapenv:Header/>
<soapenv:Body>
<ns:updateSyslogConfiguration sequence="1">
<serverName>ds-ucm115-1</serverName>
<serviceGroup>CM Services</serviceGroup>
<service>Cisco CallManager</service>
<alarmConfigs>
<AlarmConfig>
<AlarmLevelEvent>Debug</AlarmLevelEvent>
<RemoteServerName1>192.168.0.1</RemoteServerName1>
<RemoteServerName2></RemoteServerName2>
<RemoteServerName3></RemoteServerName3>
<RemoteServerName4></RemoteServerName4>
<RemoteServerName5></RemoteServerName5>
<monitor>Remote Syslogs</monitor>
<Enable>true</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Debug</AlarmLevelEvent>
<monitor>Local Syslogs</monitor>
<Enable>true</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Debug</AlarmLevelEvent>
<monitor>SDI Trace</monitor>
<Enable>true</Enable>
</AlarmConfig>
<AlarmConfig>
<AlarmLevelEvent>Debug</AlarmLevelEvent>
<monitor>SDL Trace</monitor>
<Enable>true</Enable>
</AlarmConfig>
</alarmConfigs>
<EndPointAlarm>true</EndPointAlarm>
</ns:updateSyslogConfiguration>
</soapenv:Body>
</soapenv:Envelope>
04-30-2018 11:39 AM
OK, but then this is absolutely a bug. Is there any way to consistently determine the required values across all services? I presume not?
04-30-2018 11:46 AM
For example, its SDL Trace, not SDL Traces.
04-30-2018 02:35 PM
Unless I'm missing something, the values for <monitor> can be gathered by looking at the corresponding section headings in the CUCM UI, or by performing a <getSyslogConfiguration> for a service and inspecting the return data. The values seem to be encompassed by the below set:
SDI Trace
SDL Trace
Remote Syslogs
Local Syslogs
Are the values otherwise inconsistent in some way..?
I think there is pretty arguably a defect in that the schema does not provide the known acceptable values for <monitor>...
04-30-2018 02:42 PM
Ah, I missed that the plurals were actually in the screenshot... I didn't even pick this up when I tested, haha.
The bug is that the get/update don't match. If I'm sent values in a get response, they must be honoured in an update request. Otherwise the API just becomes completely unreliable. Including the values in the schema would certainly help as well.
05-01-2018 03:42 PM
Got it...thanks for the clarification. Defect opened: CSCvj27291
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide