This forum is dedicated to the web services provided by Avaya Aura® Application Enablement Services. Please enter a DevConnect technical support ticket for assistance with one-X Communicator.

The forum is for AES web services. For assistance with voice portal, please enter a DevConnect support ticket.

If you snapshot the device just prior to attempting to retrieve the first call, what are the results of the snapshot?

Hello,

This forum is for AE Services web service questions. We don't have a forum for the System Manager web service. Please open a DevConnect Technical Support ticket under the System Manager platform for assistance.

Best Regards.

Great... glad that's working now.

Yes, unfortunately agents will still need to log out and back in to receive the updates for any skill changes that were made while they were logged in.

In my 6.3 environment, my CM is also on SP17, so I don't believe it's an issue with the patch level. My AES is on 6.3.3 Super Patch 9.

hmm... I just tested the sample provided against my own systems and I was able to successfully remove a skill from a logged in agent. I tested in both 6.3 and 7.1 environments running the latest patches/service packs. Are you attempting the change from your own application or via the SMS Interactive Test page provided with AES (https://[AESIP]/smsxml/smsxml_test.php)? If using your own app, please attempt the change from the test page to see if your results are any different.

If you have the issue when using the test page in your lab environment, then you can open a Technical Support ticket for a more in-depth investigation including reviewing the logs. Please note, this would likely require a paid membership.

https://www.devconnectprogram.com/ticket/technicalTicket

Best Regards.

Please try the following example to remove SN and SL 2 from the agent:

Model: Agent
Operation: Change
Qualifier: 2000

<?xml version="1.0"?>
<modelFields>
<Agent>
<SL position="2"> </SL>
<SN position="2"> </SN>
</Agent>
</modelFields>

After more research, this is a known issue. There is a fix in the 7.1.2 release which is targeted to be released next week.

While investigating this issue, please note the wsdl can also be obtained from the SDK (the available releases/versions of the SDK can be downloaded from the DevConnect website.

I've tested this and I am unable to reproduce the issue against those releases. Therefore, this would require more in depth investigation with your systems. Please open a DevConnect Technical Support Request for further assistance (which would require you having technical support hours available via one of our upgraded membership levels).

Best Regards.

I'm not aware of any issues in the latest releases matching what you described. Was it your CM that was upgraded to 6.3.3 or AES? or both?

There have been 17 Service Packs released for CM 6.3 (i.e the latest CM 6.3.x release is 6.3.17).

If it was your AES that was upgraded to 6.3.3, then likewise, there have been a number of Super Patches released, with the latest being Super Patch 9.

Are your systems up to date with those latest service packs and patches?

If you're not sure, you can run the "swversion" command from the CLI of both your CM and AES.

You should not expect an event when the Do Not Disturb button is pressed. You should expect an event when Send All Calls is activated/deactivate, or an API (e.g. DMCC/TSAPI) is used to set Do Not Disturb.

What is your ASAI Link Version set to?

The samples are contained in the log4j.properties file itself (which is located in the "conf" directory of the installed JTAPI SDK). Scenario D provides a rotating log example.

# # # # # # #
# # Scenario D: trace to 16 rotating files 50MB each with fine grained logs enabled (Threshold set to ALL), errors to jtapiErrors.log, no msgs to root logger
# #
# Specify trace and error destinations
# do not permit data to flow also up to root logger.
#log4j.logger.com.avaya.jtapi=ALL, JTAPI_TRACE_APPENDER, JTAPI_ERROR_APPENDER
#log4j.additivity.com.avaya.jtapi=false
# trace data going to a set of rolling files: (1 'current' and 15 'backup'):
# current is always JTAPI_trace.txt;
# backup rolls through JTAPI_trace.txt.1, ... JTAPI_trace.txt.15
#log4j.appender.JTAPI_TRACE_APPENDER.Threshold=ALL
#log4j.appender.JTAPI_TRACE_APPENDER=org.apache.log4j.RollingFileAppender
#log4j.appender.JTAPI_TRACE_APPENDER.File=${user.home}/JTAPI_trace.txt
#log4j.appender.JTAPI_TRACE_APPENDER.layout=org.apache.log4j.PatternLayout
#log4j.appender.JTAPI_TRACE_APPENDER.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
#log4j.appender.JTAPI_TRACE_APPENDER.MaxFileSize=50MB
#log4j.appender.JTAPI_TRACE_APPENDER.MaxBackupIndex=15
# error data going to the default file.
#log4j.appender.JTAPI_ERROR_APPENDER=org.apache.log4j.FileAppender
#log4j.appender.JTAPI_ERROR_APPENDER.Threshold=ERROR
#log4j.appender.JTAPI_ERROR_APPENDER.File=jtapiErrors.log
#log4j.appender.JTAPI_ERROR_APPENDER.layout=org.apache.log4j.PatternLayout
#log4j.appender.JTAPI_ERROR_APPENDER.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
# #
# # Scenario D End
# # # # # # #

The "result_code" is 0 for success and 1 for a failure. In the case of a failure, the "message_text" will contain the protocol failure message received.