SergioRota | 2020-12-17 14:17:03 UTC | #1
Hi Forum,
I'm trying to enable interaction logging via custom action. I created the action using the API:
{ "requestUrlTemplate": "/api/v2/conversations/$input.IDCONVERSAZIONE/participants/$input.IDPARTICIPANT", "requestType": "PATCH", "headers": { "UserAgent": "PureCloudIntegrations / 1.0", "Cache-Control": "no-cache", "Content-Type": "application / json" }, "requestTemplate": "{\" recording \ ": true}" }
but I get the answer:
{ "message": "The request could not be understood by the server due to malformed syntax.", "code": "bad.request", "status": 400, "messageParams": {}, "contextId": "1bfb2465-4420-4a22-93c6-2bee60ea00dd", "details": [ { "errorCode": "ACTION.REMOTEENDPOINT" } ], "errors": [ { "message": "REST call for action execute failed. Message:Request to backend service failed. Response from web service: {\"message\":\"Failed to update properties on conversation participant.\",\"code\":\"conversation.participant.update.invalid\",\"status\":400,\"details\":[],\"errors\":[{\"message\":\"The participant for this request does not belong to the user making the request.\",\"code\":\"conversation.error.user.not.party\",\"status\":400,\"details\":[{\"fieldName\":\"recording\"}]}]} [1bfb2465-4420-4a22-93c6-2bee60ea00dd]", "code": "BADREQUEST", "status": 400, "messageParams": {}, "details": [], "errors": [] } ] }
I checked and the participant's conversation ID (agent) is correct
Thanks Sergio
John_Carnell | 2020-12-17 15:41:18 UTC | #2
Hi Serigo,
We do not allow OAuth Client Credentials to modify a conversation they are not part of. Data Actions use a client credential grant and do not have a user context. This is why you are getting an error.
If this is a feature, you would like to see, I would encourage you to open idea in our Aha.
Thanks, John Carnell Manager, Developer Engagement
SergioRota | 2020-12-17 17:29:57 UTC | #3
Hi John,
I can't get the action to execute even by inserting it in the script, in this case the user context is respected.
Here is the information by inspecting the network part: Request URL https://apps.mypurecloud.de/platform/api/v2/integrations/actions/custom_-_f1fb369d-ec54-497e-8fa4-f3f80295678a/execute?flatten=true equest Method: POST Status Code: 400 Remote Address: 18.185.197.48:443 Referrer Policy: strict-origin-when-cross-origin Body:
{CONVERSATIONID: "ab5fc480-ec99-44b3-afc0-9760e7ceb14c",…} CONVERSATIONID: "ab5fc480-ec99-44b3-afc0-9760e7ceb14c" PARTICIPANT_ID: "739a3a61-7564-403c-bc02-1aaa036483ab" RECORDING: true
Response: {message: "The request could not be understood by the server due to malformed syntax.",…} code: "bad.request" contextId: "384cbe7a-cbf9-47e9-b535-257f7d985353" details: [] errors: [] message: "The request could not be understood by the server due to malformed syntax." messageParams: {} status: 400
Thanks Sergio
SergioRota | 2020-12-17 17:39:10 UTC | #4
I noticed that it treats the action with the POST method although the custom action is correctly set with the PATCH method
Jerome.Saint-Marc | 2020-12-18 10:34:43 UTC | #5
Hello,
Just to clarify something about the Genesys Cloud Data Actions.
The Platform API requests that you trigger through your Genesys Cloud Data Actions will always leverage a Client Credentials grant (not a user context).
What I mean is that if you invoke the Data Action from Architect, or from a Script, or using the API - the Platform API request which is specified in your Data Action will still leverage the credentials associated/configured with your Data Action - the Client Credentials grant (not a user context).
The HTTP POST you see, being sent from your Script/web client, and using your user context/credentials, is the request to execute the Data Action. Data Action will then start its execution using the configured credentials (Client Credentials) - and executed from server-side. That's why your request also get rejected from a Script - as this API endpoint requires the user (making the request) to be a participant in the call. The identity of the user making the request is derived from the user-context credentials. So it is not possible to invoke this API request with client credentials (which do not have a user context).
Also, as a clarification on the API endpoint you are trying to use. Note that setting recording to true, for the contact center agent (agent's participant), will start a user recording. It will not trigger a "Contact Center/ACD recording". I mean a recording attached to the conversation, and available via the Interaction Details view. This type fo recording is only triggered via Policy (and configuration). It is not possible at this time to start a recording (Policy-based) using the Platform API.
If starting a user recording is indeed what you are trying to achieve, one possible way to expose such capability would be using an interaction widget integration. You could expose a webapp exposing such feature, as a custom tab in the Conversation window. Interaction Widgets support URL interpolation and can pass the related conversationId as a url query parameter - {{pcConversationId}} macro. The code (html/js) of your webapp can leverage the Platform API (this time leveraging the user credentials - user context). To do this, you would have to create and to leverage an OAuth Client (using user context this time - like Token Implicit Grant).
Regards,
system | 2021-01-18 10:33:44 UTC | #6
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 9538