For anyone else running into this, the parenthesis are required. So when I added the parenthesis around the name of the attribute it started working.
Returns the agent objects that have the attributes in the list.
... View more
I'm attempting to use the advanced search capability documented on page 20 of the 11.6 UCCE Developper Reference for the Agent API:
Advanced search parameters There are several advanced searches you can perform on the Agent API, including supervisor, attributes, skillgroups, team, and include and exclude (agentId). • supervisor: (true/false) Find agents that are (or are not) supervisors. ◦q=supervisor:true Returns all agents who are supervisors. ◦q=supervisor:false Returns all agents who are not supervisors.Contact Center, • attributes: (attr1 & attrt2 & attr3, ...) find all agents that have all the specified attributes. Up to ten attributes can be specified. The attribute names are fully matched.
skillgroups: (skill1 & skill2 & skill3,...) find all agents that have all the specified skillgroups. Up to ten skillgroups can be specified. The skillgroup names are fully matched. • team: (team1|team2|team3, ...) find all agents who belong to any of the specified teams. Up to ten team names can be specified. The team name is fully matched. • include: (ID1 & ID2 & ID3, ...) find all specified agents even if they do not meet other search criteria. Each agentId is fully matched. • exclude:(ID1 & ID2 & ID3, ...) exclude all specified agents from the results even if they meet all other search criteria. Each agentId is fully matched.
I'm attempting to narrow down the list of agents which contain a specific attribute. Here's my query:
I'm doing this as a GET using Postman, using the administrator user account.
I get back a 200ok, but my list of agents is empty. I've tried double quotes and single quotes, etc... Nothing seems to work.
Also team and skillgroup don't seem to work.
Does anyone know if this works with UCCE? Is this only implemented in PCCE? I would appreciate any and all help.
... View more
We have a customer that is wanting to use SSO with a custom thick client Finesse desktop client that will consume the REST API and BOSH interfaces directly. I understand that 11.6+ of Finesse now supports sending SSO access token instead of AgentID and Password on the REST API and BOSH connection. The Client would embed the SSO SDK to enable the SSO login to retrieve the access token and would then use the token on the REST and BOSH HTTP connection. There are code examples on the SSO SDK site that shows how to do this: https://developer.cisco.com/site/contact-center-express/docs/#cisco-identity-service-client-sdk-overview https://developer.cisco.com/site/contact-center-express/docs/#cisco-identity-service-client-sdk-guide https://developer.cisco.com/site/contact-center-express/docs/#cisco-identity-service-client-sdk However, their isn't an example of how you would do the Login to Finesse using the REST API, that I can find anywhere. The 11.6 Web Service guide doesn't mention anything about SSO. I understand that you can use the SSO SDK to get an access token, and then send the SSO access token on the REST API Requests instead of the AgentID/Password with basic authentication. But what I don’t understand is how to get the AgentID for the resource ID beforehand? The OOTB Desktop is doing this in the Shindig container with a dip to the AWDB. It then preforms the REST API call to Tomcat using the AgentID it retrieved to perform the actual login to UCCE. The only way that I can see the customer being able to use SSO would be to prompt the Agent for both the SSO Login ID and the AgentID, Right? For example, when you issue the Login request to the REST API you have to have the AgentID in the ResourceID of the URL. PUT to http:// <FQDN>/finesse/api/User/ <id> with body: <User> <state>LOGIN</state> <extension>1001001</extension> </User> There must be a step that I am missing here? In my opinion, there is a missing component. A Web Service call that the client can make using the SSO access token for authentication, and the Agent Login Name (i.e. SSO User Name) to retrieve the User object including the AgentID. Once the client has the AgentID then, it is business as usual, except using the SSO Access Token instead of the AgentID/Password and basic authentication. Loyd Vest, Senior Custom Software Engineer, AS Custom Application and Integration Team.
... View more