Hi Dev,
I am trying to do the wrapup through this api 'patchConversationIdParticipantsParticipantId'. The api retrun HTTP code 403 but the wrapup is sucessully happend in purecloud.
Below are my request and response
After Call Work Setting : Mandatory, Discretionary
13:38:39.304 [main] DEBUG com.mypurecloud.sdk.SLF4JInterceptor - >>>> PATCH /api/v2/conversations/1a0069b0-a05e-4750-8d9c-9e7ebeaa3d1e/participants/0d8e8fab-03ea-4310-b7db-64ca4bf6c685 >>>>
---- HEADERS ----
Accept: application/json
Authorization: Bearer token
Content-Type: application/json
User-Agent: PureCloud SDK/0.38.3.110/java
---- BODY (201 bytes) ----
{"wrapup":{"code":"7fb334b0-0e9e-11e4-9191-0800200c9a66","notes":"TEST wrap from API","tags":[],"provisional":false},"recording":false,"muted":false,"confined":false,"held":false,"wrapupSkipped":false}
>>>> END >>>>
13:38:39.443 [main] DEBUG com.mypurecloud.sdk.SLF4JInterceptor - <<<< PATCH /api/v2/conversations/1a0069b0-a05e-4750-8d9c-9e7ebeaa3d1e/participants/0d8e8fab-03ea-4310-b7db-64ca4bf6c685 <<<<
403 Forbidden (140 ms)
---- HEADERS ----
Cache-Control: no-cache, no-store, must-revalidate
Connection: keep-alive
Content-Length: 195
Content-Type: application/json
Date: Thu, 10 Nov 2016 19:38:39 GMT
Expires: 0
ININ-Correlation-Id: e599a46b-3cdf-42d1-b48d-76e89953187b
Pragma: no-cache
inin-ratelimit-allowed: 300
inin-ratelimit-count: 2
inin-ratelimit-reset: 60
---- BODY (195 bytes) ----
{"status":403,"code":"forbidden","message":"Access to Conversation 1a0069b0-a05e-4750-8d9c-9e7ebeaa3d1e is forbidden.","contextId":"e599a46b-3cdf-42d1-b48d-76e89953187b","details":[],"errors":[]}
<<<< END <<<<
Code snippet:
try {
ConversationsApi apiInstance = new ConversationsApi();
MediaParticipantRequest body = new MediaParticipantRequest();
Wrapup wrapup = new Wrapup();
wrapup.setCode("7fb334b0-0e9e-11e4-9191-0800200c9a66"); // Default wrapup code ID
wrapup.setNotes("TEST wrap from API");
body.setWrapup(wrapup);
apiInstance.patchConversationIdParticipantsParticipantId(conversationId, participantId, body);
} catch(Exception e) {
e.printStackTrace();
}
Thanks,
Murugan D
This is due to API-2017. If you look at the request body, it's sending all the fields. The Java SDK currently has a bug where it's sending parameters that you didn't specify, don't have a default value, and are optional. This isn't a problem most of the time, but it causes an issue with this resource because every property in the request causes PureCloud to try and perform an action on the conversation (unhold, unmute, unconfine, stop user recording). If the call isn't connected, it's going to throw an error because you can't unhold a disconnected call (one of multiple errors).
To answer your next question: it has a high priority to be worked on. I'm hoping tomorrow or Monday as this is impacting several people.
Thanks tim for quick response.
@tim.smith i am getting a 403 too every time I try to accept a call.
Are you able to comment on whether it is the same issue i am experiencing or is it something else?
com.mypurecloud.sdk.ApiException: {"status":403,"code":"forbidden","message":"Access to Conversation 32760e62-9f60-4a37-abaa-1874a524537e is forbidden.","contextId":"be0dff9a-1a17-4029-9976-8e646a88af94","details":[],"errors":[]}
Also, has this issue been introduced in the last couple of weeks or exacerbated by some other changes?
It looks like it's probably the same from a cursory review. If you're able to make subsequent API calls after getting this error, I'd say it's the same root cause.
I honestly don't know when this issue started, but I'd say it's probably been around forever as the root cause is rooted in how the SDK handles object serialization. Unfortunately, I didn't get it resolved today, but I hope to be able to get the code checked in tomorrow.
I've been looking at this and the issue is deeper than I expected. It's actually a problem with the swagger definition, not the SDK; the SDK is wrong because the swagger definition it's generated from is wrong.
You should be able to work around this by setting all of the properties on the request to null to clear the default value of false.
After setting null for rest of the properties working as expected 
We already handling wrap-up in our application. So i want to set by default wrap-up code/custom wrapup code for all conversation while invoking this api. Is there any api available to get wrap-up code based on wrapup-code name ?
1 Like
No, you have to get the wrap up codes for the conversation via GET /api/v2/conversations/callbacks/{callbackId}/participants/{participantId}/wrapupcodes (or the appropriate media-specific resource) and filter the list. You could alternatively use GET /api/v2/routing/queues/{queueId}/wrapupcodes to get the list of codes configured for a given queue.
By default Default Wrap-up Code is available for all participant(Agent) and all queues ?
The default wrap-up code will only be returned if there aren't any wrap-up codes defined for the queue. However, if you know the ID, you can always use it even if that one isn't included in the results.
The default wrap-up code will only be returned if there aren't any wrap-up codes defined for the queue
Just tested this scenario, yes, it's working as described above
However, if you know the ID, you can always use it even if that one isn't included in the results.
- Is Default Wrap-up Code id is common for all region(NA,JP and EU, etc..) and all environment ?
- How do I get Default Wrap-up Code id through pure-cloud ui.
I believe that is the case.
The PureCloud UI will only show the wrap-up codes returned by the API. So if you have wrap-up codes defined for the queue, the PC UI won't show the default option. To get that ID, just create a new queue with no wrap-up codes assigned and get the list for that queue. Because of the answer above, you can hardcode that ID in your application.
To get that ID, just create a new queue with no wrap-up codes assigned and get the list for that queue
Created new queue and invoked the following api, but the api does not return Default Wrap-up Code
https://api.{{environment}}/api/v2/routing/queues/2322c25e-cb86-4448-9067-ae22e728da0b/wrapupcodes
Response:
{
"entities": [],
"pageSize": 25,
"pageNumber": 1,
"total": 0,
"selfUri": "/api/v2/routing/queues/2322c25e-cb86-4448-9067-ae22e728da0b/wrapupcodes?pageSize=25&pageNumber=1",
"firstUri": "/api/v2/routing/queues/2322c25e-cb86-4448-9067-ae22e728da0b/wrapupcodes?pageSize=25&pageNumber=1",
"lastUri": "/api/v2/routing/queues/2322c25e-cb86-4448-9067-ae22e728da0b/wrapupcodes?pageSize=25&pageNumber=1",
"pageCount": 0
}
You should be able to work around this by setting all of the properties on the request to null to clear the default value of false.
@tim.smith when is the fix for this planned to be released?
I don't have an ETA yet. The issue has been reassigned for further investigation.
@Murugan_Duraisamy sorry, I assumed it would be returned with that resource. It's only returned from the conversation wrapupcodes resource:
{
"id": "7fb334b0-0e9e-11e4-9191-0800200c9a66",
"name": "Default Wrap-up Code",
"selfUri": "/api/v2/routing/wrapupcodes/7fb334b0-0e9e-11e4-9191-0800200c9a66"
}
It's only returned from the conversation wrapupcodes resource
I don't have access to take call other than NA env for now. In this case still Default Wrap-up Code id is common for all region(NA, JP and EU, etc..) and all environment ?. If so i can hard code Default Wrap-up Code id in our application
Yes, the ID for the default wrap-up code is the same across all orgs and all regions.
Great. Thanks Tim for your quick response
