04-21-2017 04:31 AM
Hello,
I'm trying to update a callvariable within a Finesse Workflow user an HTTP Request. However I receive a "400-Invalid Input" Error but I can't say why.
Does anyone have an advise what I'm doing wrong here..?
Workflow Action is the following:
Key | Value |
---|---|
Type | HTTP Request |
Handled by | Finesse Desktop |
Method | PUT |
Location | Finesse |
Content Type | application/xml |
URL | /finesse/api/User/${dialogId} |
Body | <Dialog> <requestedAction>UPDATE_CALL_DATA</requestedAction> <mediaProperties> <callvariables> <CallVariable> <name>callVariable3</name> <value>12312412</value> </CallVariable> </callvariables> </mediaProperties> </Dialog> |
Log extract of workflow execution with error message:
Header : [WorkflowEngine:ActionExecutor] Received workflow action from the Hub. {"type":"HTTP_REQUEST","name":"Change_CallVariablesLayout"}
Header : [WorkflowEngine:ActionExecutor] Executing HTTP_REQUEST action: {"httpMethod":"PUT","url":"/finesse/api/User/16812684","contentType":"application/xml","postData":"<Dialog>\n <requestedAction>UPDATE_CALL_DATA</requestedAction>\n <mediaProperties>\n <callvariables>\n\t\t <CallVariable>\n <name>callVariable3</name>\n <value>12312412</value>\n </CallVariable>\n </callvariables>\n </mediaProperties>\n</Dialog>"}
Header : [ClientServices] RequestedScheme: undefined; Scheme: http
Header : [WorkflowEngine] ------ Event queue is empty. ------
EmbeddedWebAppGadget : ECE Gadget :: in function _dataRequestHandler
EmbeddedWebAppGadget : ECE Gadget :: message received with type: SolveCall
Header : [WorkflowEngine:ActionExecutor] Received HTTP_REQUEST action callback. {"workflowActionName":"Change_CallVariablesLayout","url":"/finesse/api/User/16812684","responseCode":400,"responseText":"<ApiErrors>\n <ApiError>\n <ErrorType>Invalid Input</ErrorType>\n <ErrorData>User</ErrorData>\n <ErrorMessage>Dialog : Dialog</ErrorMessage>\n </ApiError>\n</ApiErrors>"}
Regards
Elias
Solved! Go to Solution.
04-25-2017 10:36 AM
Hi Elias,
I tried this out on my Finesse environment and was able to reproduce the issue. It seems like UPDATE_CALL_DATA is not an allowable action for the person/agent receiving the call when the call arrives. The agent making the call has this as their allowable action:
<participants>
<Participant>
<actions>
<action>UPDATE_CALL_DATA</action>
<action>DROP</action>
</actions>
<mediaAddress>{this is the caller}</mediaAddress>
<mediaAddressType>AGENT_DEVICE</mediaAddressType>
<startTime>2017-04-25T17:26:05.367Z</startTime>
<state>INITIATED</state>
<stateCause />
<stateChangeTime>2017-04-25T17:26:05.399Z</stateChangeTime>
</Participant>
<Participant>
<actions>
<action>ANSWER</action>
</actions>
<mediaAddress>{this is the agent}</mediaAddress>
<mediaAddressType>AGENT_DEVICE</mediaAddressType>
<startTime>2017-04-25T17:26:05.399Z</startTime>
<state>ALERTING</state>
<stateCause />
<stateChangeTime>2017-04-25T17:26:05.399Z</stateChangeTime>
</Participant>
</participants>
But, after the person/agent answers the call, the UPDATE_CALL_DATA is an allowable action. So, if you change the workflow to "When a call is answered", it should work (it worked on my system).
I hope that helps!
Thanx,
Denise
04-21-2017 09:52 AM
Hi Elias,
The URL for updating the call data is: /finesse/api/Dialog/${dialogId}
Give that a shot.
Thanx,
Denise
04-23-2017 11:41 PM
Hi Denise
Thanks for your answer- I think we're one step closer But now I get the following API Error:
<data>
<apiErrors>
<apiError>
<errorData>4047</errorData>
<errorMessage>INVALID_ACTION UPDATE_CALL_DATA on extension 353992</errorMessage>
<errorType>Generic Error</errorType>
</apiError>
</apiErrors>
</data>
I couldn't find out what error data 4047 means.. any idea?
Regards
Elias
PS:
I checked the allowed actions for this user on an incoming call (Workflow is triggered "when a Call arrives") using
https://<Finesse>/finesse/api/User/<id>/Dialogs
and it's listing the UPDATE_CALL_DATA action.
<Participant><actions><action>UPDATE_CALL_DATA</action><action>DROP</action></actions>
04-24-2017 09:19 AM
Hi Elias,
Based off of the API error alone, it shows that the user with extension 353992 isn't allowed to use the UPDATE_CALL_DATA API. I see from the PS that you checked that it is allowed. So, not sure what is going on.
I would take a look at the Finesse webservices logs during this time and see if the logs have any more details. The code 4047 isn't super meaningful, so I would focus more on the error message.
Thanx,
Denise
04-25-2017 01:36 AM
Hi Denise
Hmm well that's all the logs are saying.
Any idea what "Dialog failed validation!" means resp. how to address that issue (if it's one)..?
2017-04-24T10:46:44.406 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.411 +0200: Header : [WorkflowEngine:ActionExecutor] Executing HTTP_REQUEST action: {"httpMethod":"PUT","url":"/finesse/api/Dialog/16812978","contentType":"application/xml","postData":"<Dialog>\n <requestedAction>UPDATE_CALL_DATA</requestedAction>\n <mediaProperties>\n <callvariables>\n\t\t <CallVariable>\n <name>callVariable3</name>\n <value>12312412</value>\n </CallVariable>\n\t\t <CallVariable>\n <name>user.Layout</name>\n <value>EE</value>\n </CallVariable>\n </callvariables>\n </mediaProperties>\n</Dialog>"}
2017-04-24T10:46:44.406 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.411 +0200: Header : [ClientServices] RequestedScheme: undefined; Scheme: http
2017-04-24T10:46:44.407 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.412 +0200: Header : [WorkflowEngine] ------ Event queue is empty. ------
2017-04-24T10:46:44.295 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.300 +0200: CallControl : _processCall(): Process the dialog with id: 16812978, to extension: 354902, from extension: 41319175234, call state: ALERTING, callType: PREROUTE_ACD_IN
2017-04-24T10:46:44.456 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.461 +0200: Header : [WorkflowEngine:ActionExecutor] Received HTTP_REQUEST action callback. {"workflowActionName":"Change_CallVariablesLayout","url":"/finesse/api/Dialog/16812978","responseCode":202,"responseText":""}
2017-04-24T10:46:44.347 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.352 +0200: CallControl : _processCall(): User's call state is: ALERTING, user's state cause is: null
2017-04-24T10:46:44.673 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.678 +0200: Header : [ClientServices] MasterPublisher._parseAndPublishXMLEvent() - Received XML event on node '/finesse/api/User/5234/Dialogs': <Update>
<data>
<apiErrors>
<apiError>
<errorData>4047</errorData>
<errorMessage>INVALID_ACTION UPDATE_CALL_DATA on extension 353992</errorMessage>
<errorType>Generic Error</errorType>
</apiError>
</apiErrors>
</data>
<event>put</event>
<requestId></requestId>
<source>/finesse/api/Dialog/16812978</source>
</Update>
2017-04-24T10:46:44.674 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.679 +0200: Header : [ClientServices] Dialog failed validation! Does your JS REST class return the correct string from getRestType()?
2017-04-24T10:46:44.687 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.692 +0200: TeamPerformance : [ClientServices] Dialog failed validation! Does your JS REST class return the correct string from getRestType()?
2017-04-24T10:46:44.691 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:44.696 +0200: CallControl : [ClientServices] Dialog failed validation! Does your JS REST class return the correct string from getRestType()?
2017-04-24T10:46:45.813 +02:00: 77BBAB: labdel06fi1a.lab.lan: Apr 24 2017 10:46:45.818 +0200: Header : Time Information - UTC: 'Mon, 24 Apr 2017 08:46:45 GMT'; Local Time: 'Mon Apr 24 2017 10:46:45 GMT+0200'
Regards
Elias
04-25-2017 10:36 AM
Hi Elias,
I tried this out on my Finesse environment and was able to reproduce the issue. It seems like UPDATE_CALL_DATA is not an allowable action for the person/agent receiving the call when the call arrives. The agent making the call has this as their allowable action:
<participants>
<Participant>
<actions>
<action>UPDATE_CALL_DATA</action>
<action>DROP</action>
</actions>
<mediaAddress>{this is the caller}</mediaAddress>
<mediaAddressType>AGENT_DEVICE</mediaAddressType>
<startTime>2017-04-25T17:26:05.367Z</startTime>
<state>INITIATED</state>
<stateCause />
<stateChangeTime>2017-04-25T17:26:05.399Z</stateChangeTime>
</Participant>
<Participant>
<actions>
<action>ANSWER</action>
</actions>
<mediaAddress>{this is the agent}</mediaAddress>
<mediaAddressType>AGENT_DEVICE</mediaAddressType>
<startTime>2017-04-25T17:26:05.399Z</startTime>
<state>ALERTING</state>
<stateCause />
<stateChangeTime>2017-04-25T17:26:05.399Z</stateChangeTime>
</Participant>
</participants>
But, after the person/agent answers the call, the UPDATE_CALL_DATA is an allowable action. So, if you change the workflow to "When a call is answered", it should work (it worked on my system).
I hope that helps!
Thanx,
Denise
04-26-2017 12:12 AM
Hi Denise
That's working indeed, thanks!
Unfortunately I can't use this in my case then.. because we need to modify the Call Variable User Layout (resp. change user.layout variable) for some Agent Teams because they're not allowed to see some information other teams can.. but like this, they see those information while the call is "alerting"...
Regards
Elias
04-26-2017 09:39 AM
Hi Elias,
Assuming you are setting the user.layout variable in the script itself, is it possible to have a different value for the variable depending on what team they are in? I haven't touched the script editor in a long time so I don't remember if that is possible off the top of my head.
Another idea is to flip around the scenario. By default, have the user.layout not include the restricted information. Then for the teams that can see it, change the user.layout when the call is answered. The privileged teams won't be able to see these variables when it is alerting, but it doesn't allow the privileged folks to see what they shouldn't see.
Just a few ideas I can think of.
Thanx,
Denise
04-26-2017 11:42 PM
Hi Denise
Depending on the call flow, I have no chance to differ between teams because agents get calls via a "direct agent script".
But thanks for the second hint, this may be a workable way to be discussed with the customer..
Best regards
Elias
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide