I'm having trouble getting started with the WTI APIs. All I want to do for starters is change an agent's state to "notReady". I'm using the documentation located here: https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/releases/10_1_3/api_refs/index.gsp

So, far, I can:

Create a session: https://aes-fqdn/api/session - This successfully returns the bearer token I use for the other commands.

Get the device ID for the station and the agent: https://aes-fqdn/api/fe/v1/GetDeviceId - This returns something like:

{
"GetDeviceIdResponse": {
"device": "1111:CMName:0.0.0.0:1"
}
}

I feel this should be all I need to use this command to change the agent state: https://aes-fqdn/api/fe/v1/SetAgentState which requires a JSON body similar to:

{
"device": "1111:CMName:0.0.0.0:1",
"requestedAgentState": "ready",
"agentID": 2222,
"password": 1234
}

When I issue this command the AES returns a 400 bad request with a response body of:

{
"systemResourceAvailibility": "otherResourceOutOfService"
}

The station is registered and the agent is logged into the station and available.

What am I missing? Are there other docs or a sample app available that explains how this API should be properly used?

Thanks for any help you can provide!

What state is the agent in when you send in the request? (use a FAC or similar to force it to a ready state before changing it to not ready).
Is there a call active at the station when you send the request? (try it with the station being idle).
Is 1111 the agent-ID or the station? I think it is the station
What happens if you use the DeviceID of the agent Agent-ID in the request as opposed to the station extension of 1111

Take a look at the TSAPI trace from AE Services and see if you can get more detail of what is actually occurring with your requests when they are being processed.

WTI piggy-backs on DMCC and DMCC Call Control is basically a wrapper for TSAPI. So, for anyone working with WTI, the following docuemnts and tools will be invaluable:

Documents:
1. Avaya Aura® Application Enablement Services Device, Media and Call Control .NET API Programmer’s Guide

There is also an XML and Java guide which give the same information.

2. Avaya Aura® Application Enablement Services TSAPI for Avaya Communication Manager Programmer’s Reference

This gives the most information for Call Control features. It is absolutely necessary for understanding that are valid values for paramaters, how requests interact with CM features and the meaning of many of the error codes.

You can download all of these documents from the Devconnect website.

Tracing:
Enable DMCC and TSAPI traces on AES. From the AES Web Manager use the "Status -> Log Manager -> Trace Logging Levels" menu to get to the Trace Logging Levels page. Set "TSAPI Service" to "Everything on". Set all DMCC levels to "FINEST".

AES traces are stored in /var/log/avaya/aes/. WTI traces are telrestsvc.log and DMCC traces are dmcc-trace.log (they both rollover). TSAPI traces are in the TSAPI folder. csta_trace.out shows messages between TSAPI & DMCC. g3trace.out shows the messages to/from CM.

Test Tool:
I would encourage you to download the DMCC .Net SDK from the Devconnect website. This includes the DMCC Dashboard which allows you to easily send & receive DMCC messages to/from AES. This bi-passes WTI and auto-generates the DMCC XML messages. The data in these messages matches almost exactly the data in the WTI JSON messages so you can easily see what data AES expects and what data you can expect to receive.

Martin

BTW, that error may indicate that the one of the TSAPI service, TSAPI link to CM or Switch Connection to CM is down. For example, see the following thread:
https://www.devconnectprogram.com/forums/posts/list/3269.page#p51032

Martin