mk_telephony | 2018-06-12 20:07:00 UTC | #1
Is it possible to have nested objects/complex json expected in the request or response body of a custom call data action? Or does the JSON schema necessarily have to be flat?
This is not a bridge action (which I understand must be flat.
Jason_Mathison | 2018-06-12 20:18:11 UTC | #2
Where are you planning to use the data action? If it is in architect or scripts the schema will have to be flattened. If you are using the API directly it does not have to be flattened.
Also, the data action service will attempt to do the flattening for you, you don't have to create a flat schema yourself.
mk_telephony | 2018-06-12 20:41:10 UTC | #3
We are planning on using the data action in IVR call flows. Will it need to be flattened for this usecase?
You mentioned that the data action service will attempt to do the flattening itself; I assume flattening the responses returned to be stored in variables. However, would the request body schema also be flattened?
Also, wanted to confirm, that returning an array as part of the response body would still be acceptable (regardless of whether the schema is flattened)
Jason_Mathison | 2018-06-13 14:47:11 UTC | #4
We are planning on using the data action in IVR call flows. Will it need to be flattened for this usecase?
Yes, architect requires that the output be flattened.
You mentioned that the data action service will attempt to do the flattening itself; I assume flattening the responses returned to be stored in variables. However, would the request body schema also be flattened?
Request bodies are expected to be just primitive key / value pairs, no objects or arrays.
Also, wanted to confirm, that returning an array as part of the response body would still be acceptable (regardless of whether the schema is flattened)
This gets a bit tricky. You can't have arrays with arrays inside of them, or arrays of objects, but arrays of primitives can work. Your best bet is probably to put together your schema and try it out with the data action test mode.
mk_telephony | 2018-06-20 03:16:03 UTC | #5
Hey Jason, could you elaborate on:
Also, the data action service will attempt to do the flattening for you, you don't have to create a flat schema yourself.
Is it possible for the response to be of the form: { "properties": { "user_id": { "type": "string" }, "subcontext1": { "type": "object", "properties": { "test1": { "type": "string" }, "test2": { "type": "string" } } }, "subcontext2": { "type": "object", "properties": { "test": { "type": "string" }, "test2": { "type": "string" } } } } }
(not sure why the above isn't correctly formatted)
Would the above schema defined as a custom action under https://apps.mypurecloud.com/directory/#/admin/integrations/actions be acceptable?
If some of the fields defined in the output contract are not returned, will they be returned as null (i.e. treated as optional)?
Jason_Mathison | 2018-06-20 18:59:40 UTC | #6
Your schema looks pretty simple, I don't see any reason it wouldn't work.
If some of the fields defined in the output contract are not returned, will they be returned as null (i.e. treated as optional)?
When you create your request or response schema you can set some or all of the fields as required. If a required field is missing, the data action will return an error. If the field is not required then the action can return success. If you are running the data action through the API I think that it will just not have the field at all. In architect I think that is represented as the variable being "not set". An example of setting a required field is included in my example below.
You can keep your formatting by selecting all of the formatted text and hitting the </> button.
{ "$schema": "http://json-schema.org/draft-04/schema#", "title": "Number of Agents On Queue Request", "description": "The number of agents with a status of On Queue in a queue.", "type": "object", "required": [ "QUEUEID" ], "properties": { "QUEUEID": { "description": "The queue ID.", "type": "string" } } }
system | 2018-07-21 18:59:23 UTC | #7
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: 2997